Aplicativos de Alta Disponibilidade no IBM Cloud

Como proteger um aplicativo de nível de produção ativado para nuvem contra falha em qualquer nó

Os novos recursos do IBM® Cloud permitem que desenvolvedores e arquitetos de aplicativos eliminem pontos únicos de falhas em aplicativos. Este artigo fornece um guia detalhado desses recursos. Ele inclui uma discussão sobre a abordagem que o IBM Cloud usa (suporte agregado para endereços IP virtuais), sobre como preparar suas instâncias de nuvem para aproveitar esse recurso, sobre como configurar um Web site altamente disponível e como testar esse site.

Dima Rekesh, IT Architect, IBM w3 Architecture and Development

Dima Rekesh é membro da equipe estratégica IBM Cloud Computing Enterprise Initiatives. No passado, ele trabalhou em diversas plataformas de aplicativos da Web de grande escala e tecnologias emergentes, bem como na liderança de datacenters e estratégias de datacenters verdes.



Alan Robertson, High Availability Consultant, IBM Australia

Alan fundou o projeto de software livre Linux-HA e é um especialista conhecido internacionalmente de sistemas de alta disponibilidade. Ele é um palestrante solicitado com frequência para alta disponibilidade e Linux.



27/Jan/2011

O IBM® Smart Business Development and Test on the IBM Cloud é um ambiente elástico provisionado e escalado dinamicamente que fornece a clientes corporativos tudo que precisam para desenvolver, testar e hospedar aplicativos. Ele inclui um portal da Web para configurar e gerenciar recursos de nuvem, imagens de software de produtos IBM que iniciam esforços de desenvolvimento e teste e APIs que permitem que usuários controlem recursos de nuvens e software programaticamente. E equipes da IBM incluem recursos desde o início do IBM Cloud que são projetados para fornecerem flexibilidade e resiliência adicionais.

Essa maior agilidade e essa elasticidade muito melhorada — que ajudam a ajustar a topologia de seu aplicativo às demandas dos negócios em tempo real — vêm com uma compensação: uma redução em compatibilidade com ambientes em nuvem de recursos como alta disponibilidade (HA).

Alta disponibilidade, o requisito para proteger um aplicativo de nível de produção contra uma falha de qualquer nó, não é um novo conceito por nenhum padrão. Muitos produtos de software abordam esse desafio. Mas a maioria desses produtos é, em geral, incompatível com a nuvem. A maior parte dos provedores de nuvem pública não fornece a funcionalidade necessária.

Com isso em mente, clientes precisam suplementar suas implementações em nuvem com construções de HA que existem fora da nuvem. Neste artigo, você verá o que a IBM tem feito com sua nuvem para abordar esse problema e como aproveitar esse recurso:

  • Vamos discutir a abordagem que o IBM Cloud usa (suporte agregado para endereços IP virtuais).
  • Vamos mostrar como preparar suas instâncias de nuvem para aproveitar esse recurso.
  • Em um exemplo, vamos mostrar como configurar um Web site altamente disponível.
  • E vamos mostrar como testar esse site.

Suporte a endereço IP virtual seguro e oportuno

Para abordar as questões de HA de forma segura e oportuna, os engenheiros do IBM Cloud agregaram suporte para endereços IP virtuais (vIPs) nas instâncias virtuais do IBM Cloud. Apesar de haver diversos métodos para fornecer serviços altamente disponíveis (consulte Recursos), o mais popular e robusto desses métodos é usar IPs virtuais.

Além de um endereço IP estático regular (cada instância obtém um quando é provisionado e nunca é alterado), uma instância pode assumir dinamicamente um ou diversos endereços IP virtuais adicionais. Como é o código do aplicativo em execução nas instâncias que controla a associação entre os vIPs e as instâncias, a topologia do aplicativo pode se ajustar a uma falha de nó muito rapidamente, no intervalo de subsegundo.

Considere este simples exemplo. Há um par de máquinas virtuais VM A e VM B com endereços IP estáticos 192.168.1.101 e 192.168.1.102, respectivamente. Além disso, ambas as VMs são configuradas para permitir a designação dinâmica do vIP 192.168.1.10 (Figura 1).

Figura 1. VM A e B têm IPs estáticos individuais e podem assumir um vIP
VM A e B têm IPs estáticos individuais e podem assumir um vIP

Nesta configuração, os endereços IP estáticos são usados para administrar e manter as instâncias. Em contraste, o endereço IP virtual é exposto aos clientes como o endereço IP do servidor.

Inicialmente, a VM A retém o vIP e, consequentemente, trata de todo o tráfego de serviço. A VM B está ativa e em execução, mas não tem o vIP e age como uma espera passiva (Figura 2).

Figura 2. Configuração ativa/passiva: a VM A retém o vIP e atende todo o tráfego. A VM B age como uma espera passiva
Configuração ativa/passiva: a VM A retém o vIP e atende todo o tráfego. A VM B age como uma espera passiva

Vamos imaginar agora que o aplicativo detecte um problema na VM A. Possivelmente, ela está lenta ou com falha. O aplicativo decide transferir o controle do vIP para a outra VM. Agora, a VM B atende todo o tráfego enquanto a VM A, uma vez reparada, deixa o vIP e torna-se a espera passiva (Figura 3).

Figura 3. Configuração ativa/passiva: VMs trocam de funções
Configuração ativa/passiva: VMs trocam de funções

Como o endereço IP virtual pode ser transferido entre as VMs no intervalo de subsegundo, com programação cuidadosa, é possível reduzir de forma significativa ou praticamente eliminar qualquer indisponibilidade em potencial, movendo o endereço IP ao primeiro sinal de problema. Apesar de parecer tão simples, esse é um método comprovado e que o ambiente IBM Cloud suporta.

Agora, vamos dar olhada na preparação de suas instâncias para tirar proveito disso.


Preparando suas instâncias para HA

A seguir, estão três etapas para preparar uma instância no IBM Cloud para aproveitar o método de endereço IP virtual de fornecimento de alta disponibilidade.

Obter um endereço IP reservado não anexado

Certifique-se de que você tenha um endereço IP reservado livre não anexado. Efetue login no portal do IBM Cloud e clique na Account Tab. Role para baixo até a seção Your IPs para ver uma lista de IPs reservados. Certifique-se de que haja pelo menos um endereço livre no datacenter de sua opção. Caso contrário, clique em Add IP e espere até um novo endereço IP ficar disponível (Figura 4).

Figura 4. O painel de endereço IP reservado do portal do IBM Cloud
O painel de endereço IP reservado do portal do IBM Cloud

Provisão de suas instâncias

Agora, você provisiona suas instâncias de forma simples. Selecione a imagem de sua opção e, na próxima tela, clique no botão Add IP , próximo à seção Virtual IP e selecione um dos endereços IP livres (Figura 5).

Figura 5. Este diálogo de provisão de instância do IBM Cloud permite designar um vIP à sua instância
Este diálogo de provisão de instância do IBM Cloud permite designar um vIP à sua instância

Observe que o endereço IP virtual precisa estar no mesmo datacenter que a instância que está sendo designada a ele. Clique em Close e conclua a solicitação de fornecimento.

Uma vez fornecido, cada uma das instâncias assumirá inicialmente somente seu endereço IP estático. Observe que o endereço IP estático de uma instância está ligado à interface de rede eth0 enquanto que os IPs virtuais, se escolhidos durante o fornecimento, são designados às interfaces eth0, eth1, etc., na ordem de seleção.

Associar um vIP a uma instância

A qualquer tempo durante o ciclo de vida de uma instância, você pode usar sudo /sbin/ifup <interface name> para associar um endereço IP virtual a uma instância. O comando sudo /sbin/ifdown <interface name> irá desassociá-lo.

Por falar nisso, somente uma instância por vez pode possuir um endereço IP virtual. O IBM Cloud não suporta multicasting, portanto, designar um endereço IP a diversas VMs resultaria apenas em conflitos.

Por exemplo, vamos dizer que uma instância recebeu um endereço IP estático designado pelo sistema 170.224.163.231 e um endereço IP virtual 170.224.163.161. /etc/sysconfig/network-scripts/ifcfg-eth0 vai lhe dar mais informações sobre a configuração da interface principal:

                DEVICE=eth0
                TYPE=Ethernet
                BOOTPROTO=static
                HWADDR=DE:AD:BE:A7:13:52
                IPADDR=170.224.163.231
                NETMASK=255.255.240.0
                ONBOOT=yes
                GATEWAY=170.224.160.1

Compare isso ao conteúdo do arquivo /etc/sysconfig/network-scripts/ifcfg-eth1:

            DEVICE=eth1
            TYPE=Ethernet
            BOOTPROTO=static
            HWADDR=DE:AD:BE:C8:25:20
            IPADDR=170.224.163.161
            NETMASK=255.255.240.0
            ONBOOT=no

Emita sudo /sbin/ifup eth1 para associar 170.224.163.161 à instância e sudo /ifdown eth1 para desassociá-lo. Se quiser obter esse endereço IP no tempo de inicialização, você simplesmente altera a cláusula ONBOOT para yes no arquivo /etc/sysconfig/network-scripts/ifcfg-eth1.


Configurando um Web site de HA

Neste exemplo, vamos formar uma topologia simples que consiste em dois servidores proxy configurados na configuração ativa/passiva de HA e três servidores da Web/de aplicativos (conforme mostrado na Figura 6):

Figura 6. Uma topologia simples na qual um par de proxies reversos, configurados na configuração ativa/passiva, distribui tráfego por três servidores da Web
Uma topologia simples na qual um par de proxies reversos, configurados na configuração ativa/passiva, distribui tráfego por três servidores da Web

A configuração de software a seguir é usada para este exemplo:

  • Os proxies estão executando nginx.
  • Alta disponibilidade para os proxies é fornecida por Linux HA e o software Pacemaker.
  • Os servidores da Web estão executando Apache (pré-instalado como parte da imagem OS Base).
  • Todas as instâncias do IBM Cloud usam a imagem bronze de 64 bits do RHEL 5.4.
  1. Usando o portal do IBM Cloud, é necessário provisionar todas as cinco instâncias. Certifique-se de reservar e designar um vIP para o par dos nós de proxy, conforme descrito anteriormente neste artigo.
  2. Configure as instâncias de proxy. Todos os downloads estão disponíveis a partir da seção Recursos .
  3. Você precisa de alguns pré-requisitos:
    sudo yum -y install glib2-devel libxml2 libxml2-devel bzip2 bzip2-devel pcre-devel
  4. Instale nginx (semelhante a isto):
                        wget http://nginx.org/download/nginx-0.8.53.tar.gz
                        tar -xvfz nginx-0.8.53.tar.gz
                        cd nginx-0.8.53
                        ./configure -with-http_ssl_module
                        make
                        sudo make install
  5. Para incluir as regras básicas de proxy em nginx, edite o arquivo /usr/local/nginx/conf/nginx.conf e, sob a diretiva do servidor, inclua o seguinte (use os endereços IP reais dos appservers):
                        upstream appservers {
                           ip_hash;
                           server appserver1_ip;
                           server appserver2_ip;
                           server appserver3_ip;
                                }
  6. É importante ter tempo consistente em todos os servidores, então, certifique-se de que ntpd seja iniciado automaticamente:
                            sudo /sbin/chkconfig --level 2345 ntpd on
                            sudo /sbin/service ntpd start
  7. Instale os pacotes do Pacemaker e Linux-HA. Certifique-se de que os repositórios Clusterlabs (Pacemaker) e EPEL estão disponíveis. Para o RHEL 5.4, emita estes dois comandos:
    sudo rpm -Uvh \
    http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
    sudo wget -O \
    /etc/yum.repos.d/pacemaker.repo http://clusterlabs.org/rpm/epel-5/clusterlabs.repo

    Em seguida, instale o Pacemaker e os pacotes necessários:
    sudo yum install -y pacemaker
                            heartbeat
  8. É necessário ter um script compatível para gerenciar o servidor nginx, portanto, instale o agente de recurso nginx. Esse script foi enviado ao projeto Linux-HA e eventualmente será fornecido de maneira automática. Até isso ocorrer, use este comando:
        sudo wget -O /usr/lib/ocf/heartbeat/resource.d/nginx \
        http://lists.linux-ha.org/pipermail/linux-ha-dev/attachments/20101206/3c141ea6/
        attachment.txt
  9. Você deve fornecer a configuração adequada para o software Heartbeat a partir do projeto Linux-HA. Para o IBM Cloud, é necessário configurar toda a comunicação para que ela ocorra usando transmissão unicast (o envio de mensagens a um único destino de rede identificado por um endereço exclusivo). Por isso você instalou a camada de comunicação Heartbeat.

    Para configurar a camada de comunicação Heartbeat, há três diferentes arquivos que devem ser configurados: /etc/ha.d/ha.cf, /etc/ha.d/authkeys e /etc/logd.cf.

    • Todas as máquinas devem ter uma cópia exata do arquivo /etc/ha.d/ha.cf. Para configurar, inclua estas linhas:
                      use_logd yes
                      ucast eth0 cluster1-fixed-ip
                      ucast eth0 cluster2-fixed-ip # repeat for all cluster nodes
                      autojoin any
                      crm on

      Vale a pena observar que você deve usar o método de comunicação ucast ao executar o IBM Cloud já que ele não suporta transmissão nem multicast. Isso o impede de usar Corosync como sua camada de comunicação. Ele requer multicast ou transmissão. Os endereços "IP fixos" que precisam ser incluídos são os endereços reais (não virtuais) dos servidores. Coloque uma linha para cada servidor.
    • Cada máquina também precisa de uma cópia do arquivo /etc/ha.d/authkeys. Ela deve ser modo 0600. Use esse método para gerar a primeira cópia. Em seguida, copie esse arquivo para todos os outros nós no cluster:
                  cat <<-!AUTH >/etc/ha.d/authkeys
                  auth 1 1 sha1 'dd
                           if=/dev/urandom count=4 2>/dev/null | openssl dgst -sha1` 
                           !AUTH
    • Por fim, configure /etc/ha.d/logd.cf com esta linha: logfacility daemon.
  10. Como é mais simples configurar o Pacemaker após estar em execução, vamos adiar essa configuração.
  11. Certifique-se de que o heartbeat seja iniciado automaticamente com este código:
    sudo /sbin/chkconfig --levels 345 heartbeat on
  12. A configuração inicial do firewall é um tanto quanto restritiva, portanto, inclua algumas regras para /etc/sysconfig/iptables:
            # allow pings
            -A INPUT -p icmp --icmp-type any -j ACCEPT
            # on the virtual IP address, allow only ports 80 and 443.  
            -A INPUT -d virtual_ip -m tcp -p tcp --dport 80 -j ACCEPT
            -A INPUT -d virtual_ip -m tcp -p tcp --dport 443 -j ACCEPT
            -A INPUT -d virtual_ip  -j REJECT --reject-with icmp-host-prohibited
            
            # allow ssh on the service IPs
            -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
            
            # allow heartbeat port
            -A INPUT -p udp -m udp --dport 694 -j ACCEPT
  13. Quando as edições forem concluídas, reinicie o firewall:
    sudo
                            /sbin/service iptables restart

    .
  14. Os servidores da Web requerem um pouco de atenção na configuração. Primeiro, certifique-se de que o Apache seja iniciado automaticamente:
    sudo
    /sbin/chkconfig -level 345 httpd on sudo /sbin/service httpd start

    Agora, abra as portas 80 e 443 em /etc/sysconfig/iptables:

                -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p
                tcp -m tcp --dport 80 -j ACCEPT

    Após fazer isso, reinicie o firewall: sudo /sbin/service iptables restart. Certifique-se de que ntpd seja iniciado automaticamente nestes nós também:

     sudo /sbin/chkconfig --level 2345 ntpd on sudo
                            /sbin/service ntpd start

Tudo deve estar configurado. Agora, vamos testar o sistema.


Testando o sistema

Para testar o sistema:

  1. Inicie o Heartbeat (que iniciará o Pacemaker) em todo nó do cluster.
  2. Configure o Pacemaker usando o comando crm .
  3. Verifique se tudo foi iniciado corretamente.
  4. Teste a configuração. Execute algumas transferências básicas de recursos de failover.

Iniciar o Heartbeat

Para iniciar o Heartbeat, emita um comando service heartbeat start . Após iniciá-lo, você verá um grande número de processos semelhantes a este:

                ha_logd: read process
                ha_logd: write process
                heartbeat: master control process
                heartbeat: FIFO reader
                heartbeat: write: ucast some-ip-address
                heartbeat: read: ucast some-ip-address
                /usr/lib/heartbeat/ccm
                /usr/lib/heartbeat/cib
                /usr/lib/heartbeat/lrmd -r
                /usr/lib/heartbeat/stonithd
                /usr/lib/heartbeat/attrd
                /usr/lib/heartbeat/crmd
                /usr/lib/heartbeat/pengine

Ao ver esses processos, você saberá que o Heartbeat e o Pacemaker estão em execução.

Configurar o Pacemaker

Para configurar o Pacemaker, edite a configuração de produção usando o comando crm configure edit , que abre um editor de texto. Insira as seguintes linhas no arquivo de configuração antes da instrução property na parte inferior do arquivo:

                primitive nginx-primitive ocf:heartbeat:nginx \
                  op monitor interval="5s" timeout="120s" \
                  OCF_CHECK_LEVEL="0" \
                  op monitor interval="10s" timeout="120s" \ 
                  OCF_CHECK_LEVEL="10" \
                  params configfile="/etc/nginx/stci.d/nginx.conf"
                primitive nginx-ipaddr ocf:heartbeat:IPaddr2 \
                  op monitor interval="5s" timeout="120s"\
                  params ip="NGINX-IP-ADDRESS"
                primitive NFS-server lsb:nfs-kernel-server
                primitive NFS-ipaddr ocf:heartbeat:IPaddr2 \
                  op monitor interval="5s" timeout="120s"\
                  params ip="NFS-IP-ADDRESS"
                group nginx-group nginx-primitive nginx-ipaddr
                group NFS-group NFS-server NFS-ipaddr
                clone nginx-clone nginx-group \
                      meta clone-max="1"

Verificar a inicialização

Após salvar a configuração do Pacemaker, o sistema deve ter iniciado seus recursos e propagado essa nova configuração para todos os nós do sistema. Essa é a parte interessante. Se você verificar os logs do sistema, deverá ver mensagens sobre serviços que estão sendo iniciados, entre outras coisas. Para ver o status do sistema de HA, execute o comando sudo crm_mon . Isso mostra quais recursos estão em execução, quais nós estão ativos ou inativos no cluster, etc.

Testar a configuração

O comando crm_mon mostrou qual nó está executando nginx. Há diversas abordagens para testar essa configuração. Sugerimos testar todas elas. Um cluster que não é completamente testado não estará altamente disponível:

  • Emita um sudo service heartbeat stop no nó ativo. Veja para onde as coisas se moveram, em seguida, reinicie-o.
  • Execute um sudo reboot -f no nó ativo, em seguida, acompanhe (de outro nó) para onde os recursos são movidos.
  • Emita um comando sudo crm node standby no nó ativo, consulte para onde o serviço foi, em seguida, emita um sudo crm node online.

Isso conclui o processo de configuração e teste de seu serviço proxy nginx. Linux também fornece um balanceador de carga integrado no nível do kernel que pode ser usado e altamente disponibilizado no lugar de nginx.


Conclusão

O mesmo conjunto de técnicas apresentadas neste artigo pode ser usado para tornar praticamente qualquer serviço altamente disponível na nuvem. Por exemplo, um servidor NFS altamente disponível no IBM Cloud que inclui replicação e dados entre servidores virtuais de nuvem.

Este artigo detalhou a abordagem que o IBM Cloud usa para alta disponibilidade (suporte agregado para endereços IP virtuais). Também explicou como preparar suas instâncias de nuvem para aproveitar recursos vIP e forneceu um exemplo de como configurar um Web site altamente disponível. Por fim, descreveu como testar esse site.

Recursos

Aprender

Obter produtos e tecnologias

  • HA para os proxies neste artigo é fornecida por:

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Cloud computing, Software livre
ArticleID=620508
ArticleTitle=Aplicativos de Alta Disponibilidade no IBM Cloud
publish-date=01272011