Ativar Gerenciamento em Nuvem Centralizado em Aplicativo

Três etapas para automatizar a implementação e o gerenciamento de aplicativos e cargas de trabalho

Gerenciar cargas de trabalho e aplicativos complexos na nuvem requer automação da reconfiguração da infraestrutura em momento oportuno. O gerenciamento centralizado em aplicativo — em que os esforços de gerenciamento são enfocados no controle de todos os recursos necessários como um sistema unificado e nos parâmetros para todos os serviços em tempo de execução como uma única definição de sistema — pode fornecer uma maneira alternativa, mas igualmente efetiva, de manter o nível de desempenho da nuvem o melhor possível. Este artigo apresenta uma definição de gerenciamento de estilo centralizado em aplicativo, as 3 etapas principais para alcançá-lo e demonstra como automatizar a implementação de um aplicativo J2EE de duas camadas no IBM® Cloud. Você vai praticar a criação de ações, a ligação de ações a eventos e a manipulação de eventos.

Joydeep Biswas, Senior Software Developer, Kaavo

Joydeep Biswas é desenvolvedor de software senior em Kaavo e trabalha no produto IMOD. Possui mais de 5 anos de experiência no desenvolvimento de aplicativos Enterprise Java. Joydeep possui bacharelado e mestrado em Engenharia e Ciência da Computação pela Universidade de Jadavpur, uma das dez principais universidades da Índia. Na Universidade de Jadavpur, recebeu uma medalha de ouro por ter se graduado em primeiro lugar de sua classe.



05/Nov/2010

As implementações estão ficando mais complexas, com necessidades crescentes de recursos de computação. Gerenciar essas cargas de trabalho e aplicativos complexos na nuvem sem algum nível de automação da configuração da infraestrutura em tempo hábil pode ser quase impossível para o atarefado departamento de TI. Para não mencionar que os provedores de nuvem precisam da habilidade de tratar exceções de produção, gerenciar recursos e níveis de serviço de cargas de trabalho e aplicativos e programar atividades sem intervenção humana.

Os provedores de serviços de infraestrutura prometem economias de custo através da implementação em nuvem. Para alcançar isso são necessárias ferramentas complementares de gerenciamento do ciclo de vida para gerenciar os aplicativos de maneira apropriada de modo a alcançar eficiências. Os usuários finais precisam ser capazes de configurar firewalls, implementar e configurar software automaticamente na infraestrutura em nuvem para executar e gerenciar seus aplicativos e cargas de trabalho. Gerenciamento centralizado em aplicativo— uma abordagem descendente para computação em nuvem que significa gerenciar os serviços, o software, a infraestrutura, o middleware, a rede e o armazenamento requeridos para executar aplicativos e cargas de trabalho na nuvem na perspectiva do proprietário do aplicativo — permite que o usuário gerencie todos os recursos requeridos como um sistema unificado de um aplicativo determinado.

Neste artigo é descrito o gerenciamento centralizado em aplicativo e você pode ver como automatizar a implementação e o gerenciamento de qualquer aplicativo ou carga de trabalho em nuvens públicas, privadas e híbridas através do gerenciamento centralizado em aplicativo. Como exemplo, é oferecido um caso de uso que implementa um aplicativo J2EE de duas camadas com um balanceador de carga e servidores J2EE, juntamente com automação de escala automática, recuperação automática, etc., para gerenciar níveis de serviço em tempo de execução. Nosso exemplo é implementado no IBM Smart Business Development and Test Cloud e o processo pode ser aplicado a qualquer ambiente de nuvem. O exemplo usa IMOD (consulte a barra lateral). IMOD é uma estrutura baseada em tecnologia com patente pendente desenvolvida pela Kaavo que automatiza a implementação e o gerenciamento em tempo de execução de qualquer carga de trabalho ou aplicativo complexo multicamada e multisservidor.

Centricidade de aplicativo é uma abordagem universal

Em um ambiente de nuvem centralizado em aplicativo o usuário está gerenciando sistemas de aplicativos específicos em vez de gerenciar servidores e roteadores. Todos os recursos requeridos por um aplicativo determinado são gerenciados como um sistema unificado: todas as informações para implementar e gerenciar níveis de serviços em tempo de execução para os recursos requeridos por um aplicativo determinado são capturadas em uma única definição de sistema. Isso é denominado abordagem descendente.

Em contraste, em uma abordagem descendente ou centralizada em infraestrutura, os recursos (servidores, armazenamento e recursos de rede) são gerenciados individualmente.

O gerenciamento centralizado em aplicativo dá aos proprietários do aplicativo mais flexibilidade, controle, visibilidade, automação e segurança dos recursos de infraestrutura usados pelos aplicativos.

Embora um aplicativo Java™ específico seja usado através do software IMOD para ilustrar uma abordagem de gerenciamento de rede centralizada em aplicativo, os conceitos e as técnicas podem ser aplicados a outros aplicativos e sistemas. Por exemplo:

  • O arquivo de definição do sistema (usado para definir o aplicativo multicamada) é um arquivo XML.
  • Os exemplos de código fornecidos neste artigo estão em XML e shell scripts.
  • Há assistentes gráficos para gerar automaticamente o XML sem os usuários precisarem escrevê-lo.
  • Os conceitos de componente definidos no arquivo de definição do sistema deste artigo — ação, evento, camada, etc., — são todos partes genéricas de um aplicativo da Web multicamada, neste caso um aplicativo J2EE.
  • O próprio software IMOD é projetado para fazer interface com qualquer plataforma em nuvem e atualmente está integrado com cinco nuvens diferentes.

Há três elementos chave para estabelecer gerenciamento centralizado em aplicativo no IMOD

Há três etapas principais para construir um sistema de gerenciamento centralizado em aplicativo na nuvem:

  1. Definir o aplicativo. Isso inclui:
    • Definir a estrutura do sistema.
    • Configurar grupos de servidores.
    • Definir ações.
    • Definir ganchos para eventos padrão.
    • Definir eventos customizados.
  2. Configurar o Autopilot.
  3. Iniciar/implementar o sistema.

Mais adiante neste artigo será mostrado como usar essa abordagem para automatizar a implementação de um aplicativo J2EE de duas camadas no IBM Cloud.


Sobre a linguagem de script

Os exemplos de código neste artigo são scripts de linha de comando padrão, basicamente, comandos que um administrador do sistema usará ao executar manualmente as etapas nos exemplos. Scripts proprietários ou linguagens de programação não são usados.

Os scripts são uma sequência de comandos para os servidores de destino. Podem ser shell scripts, script Perl, Python scripts, etc. Quando os scripts precisam de informações disponíveis somente em tempo de execução, usam modelos Apache Velocity para gerar dinamicamente esses scripts.

O corpo da ação install-jdk é um shell script que consiste em chamadas de comandos Linux padrão como wget, tar etc., como mostrado no código a seguir. Qualquer outra linguagem de script pode ser usada.

Amostra de shell script
/usr/bin/wget -O /opt/jdk1.6.tar.gz http://SOURCE.com/jdk1.6.0_16.tar.gz
cd /opt/
 tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

Os arquivos de configuração são tratados de maneira semelhante. A ação configure-apache-balancer tem um corpo como mostrado neste código:

Amostra de arquivo de configuração
<Proxy balancer://mycluster>
                    #foreach ($node in $AppNodes)
                    BalancerMember http://$node.publicIP:8080
                   #end
        </Proxy>
           ProxyPass /app balancer://mycluster
        <Location /balancer-manager>
                     SetHandler balancer-manager
                     Order Deny,Allow
                     Allow from all
         </Location>

Quando esse modelo é renderizado, gera um arquivo de configuração para apache mod_proxy. Arquivos de definição do sistema baseados em XML não são usados para descrever aplicativo, mas são usados principalmente para representação interna.

Existem vários assistentes de GUI para arquivos de definição do sistema de geração automática. O fragmento de XML a seguir é gerado pelo assistente.

Fragmento de XML gerado pelo assistente
          <serverType role="ndbd" min="1" max="6">
           <ibmServer>
            <name>AppNode</name>
            <ibmAccount>xxxx</ibmAccount>
            <keypair>yyyy</keypair>
            <imageIdentifier>20001150</imageIdentifier>
            <instanceType>BRZ32.1/2048/175</instanceType>
            <location>41</location>
            ..........//Event and other information
            <startupCount>2</startupCount>
          </ibmServer>
         </serverType>

Exemplo: Definindo o aplicativo

A primeira etapa na direção de uma abordagem de gerenciamento centralizada em aplicativo para gerenciar aplicativos é definir o aplicativo, por isso vamos definir os componentes do IMOD e o que cada um executa.

IMOD da Kaavo

O IMOD da Kaavo usa tecnologia com patente pendente para fornecer gerenciamento centralizado em aplicativo de recursos virtuais nas nuvens. O IMOD fornece uma interface da Web fácil de usar para implementar, executar e gerenciar aplicativos complexos de n camadas e de multisservidor em nuvens públicas, privadas e híbridas. Para obter mais informações, consulte os produtos e a tecnologia da Kaavo.

No IMOD, um aplicativo (ou um sistema) multicamada completo é definido usando um arquivo XML chamado System Definition (consulte a wiki N-Tier Guide System Definition em Recursos para obter mais informações). Após o sistema ser definido, um único clique implementa o aplicativo inteiro.

O arquivo de definição do sistema tem dois componentes: tempo de implementação e tempo de execução:

  • O componente de implementação transporta todas as informações sobre o fornecimento de recursos e implementa e configura o middleware e os componentes do aplicativo para colocar o aplicativo on-line.
  • O componente de tempo de execução tem os fluxos de trabalho para serem executados em resposta a eventos definidos para garantir que os níveis de serviço do aplicativo sejam atendidos automaticamente durante o tempo de execução sem intervenção humana.

Após o sistema ser implementado, haverá a funcionalidade "autopilot" que permitirá agilizar e automatizar o suporte de produção do aplicativo.

Alguns dos outros blocos de construção do IMOD incluem

  • Server
  • Tipo de servidor, grupo de servidores
  • Camada
  • N-camadas
  • Ação: ações executáveis e não executáveis
  • Eventos: eventos customizados e padrão

Vamos olhar cada um em detalhes.

Server

Um servidor representa diretamente um servidor virtual ou instância na nuvem. Um servidor é especificado por um número de parâmetros — contas de serviços em nuvem para usar para fornecer a instância ibmAccount), imagens para criar a instância (imageIdentifier), tipos da instância (instanceType) e muito mais. A Listagem 1 mostra como especificar uma instância no IBM Cloud usando XML.

Listagem 1. Especificar uma instância no IBM Cloud usando XML
<ibmServer>
  <name>AppNode</name>
  <ibmAccount>xxxx</ibmAccount>
  <keypair>yyyy</keypair>
  <imageIdentifier>20001150</imageIdentifier>
  <instanceType>BRZ32.1/2048/175</instanceType>
  <location>41</location>

  ..........//Event and other information
  <startupCount>2</startupCount>
</ibmServer>

Tipo de servidor, grupo de servidores

No IMOD, os servidores são organizados em grupos. Um grupo pode ter qualquer tamanho dentro de um intervalo especificado. O tamanho do grupo depende da escala da implementação.

Cada grupo começa com um tamanho inicial e pode variar no tempo de execução dependendo da carga de tempo de execução e da configuração do autopilot. Todos os membros do grupo são criados da mesma maneira, mas a configuração dos diferentes servidores dentro de um grupo pode ser um pouco diferente.

Exemplos de grupos de servidores são grupos de nós ndbd em um cluster mysql, grupos de nós de gerenciador em um cluster mysql, grupos de nós jboss em um cluster jboss, etc.

A Listagem 2 mostra um fragmento de XML que descreve um tipo de servidor. A opção role identifica de maneira exclusiva um tipo de servidor. Os atributos min e max representam o tamanho de grupo mínimo e máximo. A tag startupCount representa o tamanho de grupo inicial.

Listagem 2. Fragmento de XML que descreve o tipo de servidor
<serverType role="ndbd" min="1" max="6">
          <ibmServer>
            <name>AppNode</name>
            <ibmAccount>xxxx</ibmAccount>
            <keypair>yyyy</keypair>
            <imageIdentifier>20001150</imageIdentifier>
            <instanceType>BRZ32.1/2048/175</instanceType>
            <location>41</location>
            ..........//Event and other information
            <startupCount>2</startupCount>
          </ibmServer>
</serverType>

Arquitetura n-camadas

Arquitetura multicamada ou n-camadas é uma arquitetura cliente/servidor em que apresentação, processamento do aplicativo e gerenciamento de dados são processos separados logicamente. O principal benefício da arquitetura n-camadas é que ela permite aos desenvolvedores construir aplicativos que são mais flexíveis e reutilizáveis porque é necessário modificar somente a camada de destino ao fazer alterações ou atualizações. Um bom exemplo de um aplicativo n-camadas é o que usa middleware para atender pedidos de dados entre usuários e um banco de dados. A arquitetura de três camadas é a mais usada.

Camada

Camada representa diretamente uma camada em um aplicativo multicamada. Uma camada é composta de vários grupos de servidores. Por exemplo, uma camada de banco de dados baseada em cluster mysql seria composta de dois grupos de servidores, um grupo ndbd e um grupo de gerenciadores. Quando um aplicativo multicamada é implementado, suas camadas são implementadas em sequência seguindo uma ordem de inicialização especificada para as camadas. A Listagem 3 mostra o fragmento de XML de uma camada de banco de dados com dois grupos de servidores.

<tier displayindex="3">
      <name>db_tier</name>
      .....//Event and other information
      <serverTypes>

	   <serverType role="manager" min="1" max="1">
          <ibmServer>
            ....
          </ibmServer>
        </serverType>

        <serverType role="ndbd" min="2" max="2">
          <ibmServer>
            ...
          </ibmServer>
        </serverType>

      </serverTypes>
</tier>

N-camadas

Isso representa o aplicativo multicamada e inclui várias camadas. A Listagem 4 mostra o fragmento de XML de uma n-camadas.

Listagem 4. Fragmento de XML de uma n-camadas
<ntier>
    .../Event and other information
    <tier displayindex="1">
     ...
    </tier>

    <tier displayindex="2">
     ...
    </tier>

    <tier displayindex="3">
     ...
    </tier>

</ntier>

Ação

Ações são como procedimentos reutilizáveis. São usadas para gerar scripts executáveis e arquivos de configuração de modelos de velocidade e copiá-los para servidores de destino e, opcionalmente, executá-los (no caso de scripts executáveis). Há dois tipos de ações:

  • Executáveis
  • Não executáveis

Ações executáveis
As ações executáveis geram um script executável e copiam o script para um local especificado no conjunto de servidores especificado. A Listagem 5 é um exemplo de uma ação executável.

Listagem 5. Uma ação executável
<action name="start-apache" execute="true"
 target="[tier=web_tier][serverrole=default]">
       <scriptName>apache.sh</scriptName>
       <scriptPath>/root</scriptPath>
       <scriptTemplate type="inline">
       <![CDATA[
               /etc/init.d/httpd start
               ]]>
       </scriptTemplate>

</action>
  • O atributo execute especifica se a ação é executável ou não. Neste exemplo, execute="true" especifica que a ação é executável.
  • O atributo target representa o conjunto de servidores em que o script será executado. A expressão [tier=web_tier][serverrole=default] retorna o conjunto de servidores na camada (web_tier) denominada e com o tipo de servidor (padrão) denominado.
  • O elemento scriptPath especifica o diretório no qual o script gerado será copiado; scriptName especifica o nome de arquivo com o qual o script será salvo.
  • O elemento scriptTemplate contém o corpo da ação. O corpo de uma ação é um modelo Velocity (Velocity é um mecanismo de modelo baseado em Java que permite ao designer da Web referenciar métodos definidos em código Java). Mas, neste exemplo trivial, é um texto estático.

As ações podem ser chamadas dentro de manipuladores de eventos usando a seguinte sintaxe:

<command type="action" name="action-name" />

É fácil ver que quando essa ação (ou qualquer outra ação executável nesse sentido) é executada, as três etapas seguintes são executadas para cada servidor de destino:

  1. O modelo Velocity é renderizado usando o mecanismo de modelo Velocity. Neste exemplo o modelo é texto estático, assim o conteúdo gerado é o mesmo que o modelo (por exemplo, /etc/init.d/httpd start).
  2. Um arquivo com o conteúdo gerado é criado no caminho /root/apache.sh no servidor de destino.
  3. O script /root/apache.sh é executado no servidor de destino.

A figura 1 demonstra como a execução de ações é registrada centralmente para auditoria e depuração.

Figura 1. Amostra de log de ações
Amostra de log de ações

A listagem 6 mostra um outro exemplo com um modelo Velocity não trivial.

Listagem 6: Outro exemplo de modelo Velocity não trivial
      <scriptName>GrantPhpDbAccess.sh</scriptName>
      <scriptPath>/root</scriptPath>
      <scriptTemplate type="inline">

        <![CDATA[
#!/bin/sh
#foreach ($clientNode in $SqlClientNodes)
mysql -uroot -p${mysqladminpassword} -e "GRANT ALL PRIVILEGES ON ${appdb}.*
   TO '${appdbuser}'@'${clientNode.publicIP}' IDENTIFIED BY '${appdbpassword}'"
#end	
        ]]>
      </scriptTemplate>
      <parameters>
        <parameter name="mysqladminpassword" type="literal" value="kaavo"/>
        <parameter name="appdb" type="literal" value="php_collab"/>
        <parameter name="appdbuser" type="literal" value="phpcollab"/>
        <parameter name="appdbpassword" type="literal" value="admin"/>
        <parameter name="SqlClientNodes" type="serverref"
         value="[tier=app_tier][serverrole=default]"/>
      </parameters>
 </action>

O corpo da ação agora contém conteúdo dinâmico. Essa ação aceita cinco parâmetros: mysqladminpassword, appdb, etc. Eles têm valores padrão especificados com o uso do atributo value .

Os quatro primeiros parâmetros (type="literal") são inicializados para cadeias de caracteres especificadas usando o atributo value . O último (SqlClientNodes) é reinicializado para uma coleção de objetos do servidor retornados pela expressão [tier=app_tier][serverrole=default]. Quando essa ação é executada na etapa 1 anterior ("O modelo Velocity é renderizado usando o mecanismo de modelo Velocity"), as referências a esses parâmetros são resolvidas enquanto o modelo é renderizado.

Cada objeto do servidor tem várias propriedades (por exemplo, publicIP) que podem ser acessadas no modelo. O loop foreach itera na coleção $SqlClientNodes com o $clientNode como a variável de loop. Em cada iteração do loop, ${clientNode.publicIP} busca o IP público do objeto do servidor. Essa ação gera o seguinte script:

Listagem 7. Cada iteração de loop busca o IP público do objeto do servidor
#!/bin/sh
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP1' IDENTIFIED BY 'admin'
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP2' IDENTIFIED BY 'admin'
...
...
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIPn' IDENTIFIED BY 'admin'

ondepublicIP1, publicIP2, ..., publicIPn representam os IPs públicos de todos os servidores na coleção SqlClientNodes (em outras palavras, os IPs públicos de todos os servidores na camada, app_tier, e server type=default.)

Os parâmetros recém-definidos são parâmetros definidos pelo usuário. Além desses, há três parâmetros implícitos que podem ser referenciados no modelo:

  • CurrentTarget (o nó no qual o script está sendo criado).
  • AllTargets (conjunto de todos os nós que são destinos da ação).
  • OtherTargets (conjunto de todos os nós exceto o CurrentTarget).

(O N-Tier Guide disponível em Recursos pode fornecer uma lista abrangente de propriedades do objeto do servidor e parâmetros implícitos.)

Ações podem ser incluídas em um sistema e também editadas em qualquer fase de vida do sistema usando um assistente (Figura 2).

Figura 2. Incluindo uma ação usando um assistente
Incluindo uma ação usando um assistente

Ações não executáveis
Ações não executáveis são semelhantes às ações executáveis, a única diferença é que essas ações geram arquivos não executáveis nas etapas 1 e 2 anteriores. E a etapa 3 não existe para esses tipos de ações porque para essas ações o atributo execute está definido para false.

Eventos

Uma n-camada, uma camada, um Grupo de Servidores ou cada um dos servidores individuais em um grupo são controlados enviando eventos a eles. Um evento tem um destino especificado. Os eventos podem ser disparados de diferentes maneiras:

  • Manualmente: os usuários podem disparar eventos usando a interface com o usuário.
  • Pelo planejador de eventos.
  • Fazendo uma chamada de serviço da Web (o que permite aos usuários interagir de maneira programática com o IMOD via SOAP usando um documento/estilo literal com wrap).
  • Configurando um acionador no sistema de monitoramento (consulte o N-Tier Guide).

Há dois tipos de eventos: eventos customizados e padrão.

Eventos padrão
Os eventos padrão são eventos predefinidos. Esses eventos são definidos toda vez que um sistema é definido no IMOD.

Há dois tipos de eventos padrão: Start eStop. Todas as n-camadas, Camada e Servidor (Grupo) podem ser um destino desses eventos, por isso para cada um haverá um evento de início e um evento de parada. Por exemplo, start ntier, start tier1, start tier2, start server1, start server2, stop tier1 etc.

Cada evento tem um manipulador que é um bloco de código que é executado em resposta à ocorrência do evento. Para eventos padrão, os manipuladores de eventos são predefinidos. Mesmo assim, o comportamento padrão desses manipuladores de eventos pode ser customizado implementando ganchos predefinidos a eles. Os eventos de início têm ganchos pós-inicialização. Os eventos de parada têm ganchos pré-encerramento. A listagem 8 demonstra a estrutura desses manipuladores de eventos.

Listagem 8. A estrutura dos manipuladores de eventos em pseudocódigo
Proc Start-server-handler
  Begin
       Execute start-server-default-logic
       Execute post-startup hook
  END

Proc Stop-server-handler
  Begin
       Execute pre-shutdown hook
       Execute stop-server-default-logic
  END

A lógica padrão do servidor de partida (denominada de start-server-default-logic na listagem 8) é prover um servidor na nuvem de backend. A lógica padrão do servidor de parada é desprover o servidor. Os ganchos de pós-inicialização e pré-encerramento estão em branco por padrão.

Eventos customizados
Além dos eventos padrão que estão disponíveis por padrão, os usuários podem definir seus próprios eventos. A listagem 9 é um exemplo de evento customizado.

Listagem 9. Um evento customizado definido pelo usuário
<event name="system-scaleup" description="App system scaleup" type="custom">
      <handler timeout="6000">
        <pre-process>
          	<startServers>
            	       <serverType role="[tier=app_tier][serverrole=default]" count="1"
                          addToEvent="true"/>
          	</startServers>
        </pre-process>
        <process>
         	 <command type="action" name="start-app"
              target="[tier=app_tier][serverrole=default][scaleupserver]"/>
          <command type="action" name="configure-apache-balancer"/>
          <command type="action" name="reset-apache"/>
        </process>
     </handler>
 </event>

Um evento é identificado por um nome, pelo manipulador do evento e é definido junto com o evento. Assim, se o evento na listagem 9 for definido em um sistema toda vez que um evento com o nome system-scaleup acontecer, o manipulador especificado é executado.

O manipulador de eventos inicia um novo servidor e o configura executando nele uma sequência de comandos. Esse tipo de manipuladores de eventos pode ser usado para escalar um sistema existente por mais instâncias.

De modo semelhante, eventos podem ser definidos para recuperar um servidor inativo (Listagem 10).

Listagem 10. Eventos definidos para recuperar servidores inativos
<event name="server-recovery" description="App server recovery" type="custom">
      <handler timeout="6000">
        <pre-process>
          <recoverServers>
            		<server server-to-recover="[context=event][param=instanceid]"/>
          </recoverServers>
        </pre-process>
        <process>
         	 <command type="action" name="start-app"
              target="[tier=app_tier][serverrole=default][recoveringserver]"/>
          	<command type="action" name="configure-apache-balancer"/>
          	<command type="action" name="reset-apache"/>
        </process>
      </handler>
 </event>

Elementos como startServers, recoverServers, e stopServers estão disponíveis somente no manipulador de eventos de eventos customizados.

Novamente, consulte o N-Tier Guide em Recursos para obter uma descrição mais detalhada de eventos customizados.


Exemplo: Projetando o sistema

Um único servidor executando o aplicativo seria suficiente para esta demonstração, mas para ilustrar determinados recursos é projetado como múltiplos servidores com balanceamento de carga executando o aplicativo (ao que iremos nos referir com o nome de app). O sistema é projetado como um sistema de duas camadas com uma camada app executando o aplicativo J2EE e uma camada de balanceador de carga. A figura 3 ilustra a arquitetura da implementação da maneira mais simples possível.

Figura 3. A arquitetura da implementação de duas camadas
A arquitetura da implementação de duas camadas

A lógica para usar duas camadas separadas é que o mecanismo N-camada do IMOD permite definir a ordem de implementação entre as camadas. O arquivo de configuração do balanceador de carga encaminha aos endereços IP dos servidores de aplicativos, por isso o balanceador de carga não pode ser configurado antes dos servidores de aplicativos estarem ativos e em execução e terem recebido a designação dos seus endereços IP.

Essa arquitetura deve ser mapeada em um sistema N-camada do IMOD. Os principais elementos requeridos em um nutshell são:

  1. Duas camadas.
  2. Dois grupos de servidores.
  3. Várias ações (instalar, configurar, inicializar e reinicializar).
  4. Ganchos para eventos padrão.
  5. Vários eventos customizados (escalar para cima e para baixo e recuperar um servidor inativo).
  6. Acionar condições e parâmetros para eventos customizados.

Vamos observar cada um com mais detalhe.

1. Duas camadas

Vamos chamar as duas camadas de app-tier (a camada do aplicativo) e lb-tier (a camada do balanceador de carga). App-tier contém um grupo de servidores (app-group) e lb-tier contém um grupo de servidores (lb-group).

2. Dois grupos de servidores

Os dois grupos de servidores, app-group e lb-group, apresentados na última seção, serão realizados por diferentes conjuntos de servidores. App-group é realizado pela imagem base do IBM SUSE Linux Enterprise Server 11 (x86); lb-group é realizado pela imagem base do Red Hat Enterprise Linux 5.4 (32-bit).

3. Várias ações

As ações que são requeridas tratam da instalação, configuração, inicialização e reinicialização de servidores e abertura de portas.

Executando instalação do Apache em servidores lb-group
Vamos chamar isso de install-apache. Esse é um script estático e já serve como o modelo Velocity necessário. Isso é feito como no código a seguir.

Tipo de ação: executável
Script a ser executado:

wget http://3rdparty-tools.s3.amazonaws.com/apache/httpd-2.2.14.tar.gz
 tar -xzvf  httpd-2.2.14.tar.gz
 cd httpd-2.2.14
 export CFLAGS=-O2
 ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
  --enable-proxy_balancer=shared --enable-proxy_http=shared --enable-rewrite=shared
  --enable-proxy=shared
 make
 make install
 echo "Include conf/extra/httpd-IMOD.conf" >> /usr/local/apache2/conf/httpd.conf

Configurando o balanceador de carga do Apache em servidores lb-group
Chamemos este de configure-apache-balancer.

Tipo de ação: não executável
Arquivo de configuração a ser copiado:
<Proxy balancer://mycluster>
                    	
        BalancerMember http://publicIP1:8080
        BalancerMember http://publicIP2:8080
        ....
        ....
        BalancerMember http://publicIPn:8080
                   	
</Proxy>
ProxyPass /app balancer://mycluster
<Location /balancer-manager>
        SetHandler balancer-manager
        Order Deny,Allow
        Allow from all
</Location>

Nesse, publicIP1, publicIP2, ...., e publicIPn são IPs públicos de servidores com carga balanceada. Em outras palavras, os servidores app-group na app-tier.

Evidentemente, será necessária uma ação dinâmica parametrizada aqui para gerar linhas BalancerMember que dependem de publicIPs de todos os [tier=app-tier][serverrole=app-group] . Essas informações não são conhecidas até esses servidores estarem ativos e em execução.

O modelo Velocity necessário para essa ação é mostrado aqui:

<Proxy balancer://mycluster>
       #foreach ($node in $appNodes)
       BalancerMember http://$node.publicIP:8080
       #end
</Proxy>
  ProxyPass /app balancer://mycluster
<Location /balancer-manager>
       SetHandler balancer-manager
       Order Deny,Allow
       Allow from all
</Location>

Aqui as linhas BalancerMember são geradas por um loop foreach que faz iteração na coleção de servidores requeridos ( $appNodes). Essa coleção deve ser passada como um parâmetro.

Iniciando o Apache em servidores lb-group e abrindo portas
Vamos chamar isso de start-apache. Esse é um script estático.

Tipo de ação: executável
Script a ser executado:

cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start
sed -i 's/COMMIT/-A INPUT -p tcp -m tcp --dport 80
  -j ACCEPT\n-A INPUT -p tcp -m
    tcp --dport 10050 -j ACCEPT\nCOMMIT/g' /etc/sysconfig/iptables
/etc/init.d/iptables restart

Instalando e iniciando o aplicativo em servidores app-group e abrindo portas
Esta é chamada start-app. As informações detalhadas — nome do arquivo tar do software, destino da URL do arquivo tar, etc., — irão variar de acordo com o aplicativo J2EE que estiver usando.

Tipo de ação: executável
Script a ser executado:

/usr/bin/wget -O /opt/ APP .tar.gz
http:// SOURCE .com/ APP .tar.gz
cd /opt
tar -xzvf  APP .tar.gz
ln  -s /opt/ APP  /usr/local/ APP
export JAVA_HOME=/usr/local/java;
/usr/local/ APP /bin/startup.sh
sed -i 's/^.*FW_SERVICES_EXT_TCP=".*".*$/FW_SERVICES_EXT_TCP="8080 10050"/g'
 /etc/sysconfig/SuSEfirewall2
/etc/init.d/SuSEfirewall2_setup reload

Instalando o Java Development Kit
Ou install-jdk.

Tipo de ação: executável
Script a ser executado:

/usr/bin/wget -O /opt/jdk1.6.tar.gz http://SOURCE.com/jdk1.6.0_16.tar.gz
cd /opt/
 tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

Reiniciando o Apache após alterar o arquivo de configuração do balanceador de carga
Chamado restart-apache.

Tipo de ação: executável
Script a ser executado:

/usr/local/apache2/bin/apachectl stop
sleep 5
rm -rf /usr/local/apache2/conf/extra/httpd-IMOD.conf
cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start

4. Ganchos para eventos padrão

Esses ganchos tratam principalmente de eventos de início.

Gancho pós-inicialização para evento de início de servidores lb-group
Para chamada sequencial de ações denominadas:

{install-apache->configure-apache-balancer->start-apache}

Ganchos pós-inicialização para evento de início de servidores app-group

{install-jdk}

Gancho pós-inicialização para evento de início de app-tier

{start-app}

5. Vários eventos customizados

Os eventos customizados requeridos serão para:

  • App-group de escala para cima (app-group-scaleup; listagem 9).
  • Recuperando um servidor inativo no app-group (app-group-recovery; A listagem 10).
  • App-group de escala para baixo (app-group-scaledown).

6. Acionar condições e parâmetros para eventos customizados

E é necessário decidir os parâmetros e as condições acionadoras de cada um dos eventos customizados da seção anterior:

  • A métrica a medir (por exemplo, CPU Utilization:User).
  • O(s) grupo(s) de servidores no(s) qual(is) medir essa métrica.
  • A condição do acionador: >, <, =, != threshold.
  • O tipo de acionador: agregado ou não agregado.
  • O valor do limite (N).
  • O intervalo de tempo (T).

Exemplo: Implementando o sistema

Após a fase de projeto estar concluída, é hora de transformar o projeto no papel em um sistema n-camada. Com IMOD isso é feito usando diferentes assistentes gráficos. Uma implementação prática manual está além do escopo deste artigo.

A opção fase de projeto descrita neste artigo indica as ações para start-app, install-apache, configure-apache-balancer, etc. Na fase de implementação do Kaavo IMOD tudo que será necessário fazer é dar entrada dessas ações nos assistentes gráficos.


Conclusão

Não importa quanto esforço seja colocado para simplificá-los, os ambientes em nuvem serão sempre compostos de aplicativos complexos de gerenciar e uma array de cargas de trabalho para balancear. A capacidade de reconfigurar automaticamente a infraestrutura de maneira oportuna é uma chave para tornar o gerenciamento de nuvem gerenciável.

Um componente crítico para recuperação automática instantânea é o gerenciamento centralizado em aplicativo — Trazer o controle dos parâmetros e recursos requeridos para os serviços de tempo de execução em uma única definição de sistema pode fornecer uma maneira eficiente de gerenciar o desempenho do sistema em nuvem.

Neste artigo foi apresentado o gerenciamento centralizado em aplicativo junto com uma explicação dos seus benefícios. As três etapas para alcançá-lo foram cobertas:

  1. Como definir o aplicativo (o que inclui definir a estrutura do sistema, configurar grupos de servidores e definir ações, ganchos para eventos padrão e eventos customizados).
  2. Como configurar o autopilot.
  3. Como iniciar e implementar o sistema.

Vimos alguns códigos XML para automatizar a implementação de um aplicativo J2EE de duas camadas no IBM Cloud. O código detalha criação de ação, enganchamento de ações em eventos e tratamento de eventos. Esses exemplos de código vêm de uma experiência no mundo real no desenvolvimento e implementação do Kaavo IMOD.

Espero que estas técnicas (ou os conceitos que elas representam) sejam aplicadas para facilitar a implementação e o gerenciamento de aplicativos e serviços à nuvem no seu próximo projeto.

Recursos

Aprender

Obter produtos e tecnologias

  • É possível fazer o download do Apache Velocity, o mecanismo de modelo baseado em Java que permite aos projetistas de página da Web referenciar métodos definidos em código Java.
  • pora versão de teste do software da IBM, disponível para download diretamente no developerWorks, construa seu próximo projeto de desenvolvimento.

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=Cloud computing, Tecnologia Java
ArticleID=572532
ArticleTitle=Ativar Gerenciamento em Nuvem Centralizado em Aplicativo
publish-date=11052010