Ativar gerenciamento em nuvem centralizado em aplicativo

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.
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.

02.   Configurar o Autopilot.

03.   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<br />cd /opt/<br /> tar -xzvf jdk1.6.tar.gz<br />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><br />                    #foreach ($node in $AppNodes)<br />                    BalancerMember http://$node.publicIP:8080<br />                   #end<br />        </Proxy><br />           ProxyPass /app balancer://mycluster<br />        <Location /balancer-manager><br />                     SetHandler balancer-manager<br />                     Order Deny,Allow<br />                     Allow from all<br />         </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"><br />           <ibmServer><br />            <name>AppNode</name><br />            <ibmAccount>xxxx</ibmAccount><br />            <keypair>yyyy</keypair><br />            <imageIdentifier>20001150</imageIdentifier><br />            <instanceType>BRZ32.1/2048/175</instanceType><br />            <location>41</location><br />            ..........//Event and other information<br />            <startupCount>2</startupCount><br />          </ibmServer><br />         </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.

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.

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.

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><br />  <name>AppNode</name><br />  <ibmAccount>xxxx</ibmAccount><br />  <keypair>yyyy</keypair><br />  <imageIdentifier>20001150</imageIdentifier><br />  <instanceType>BRZ32.1/2048/175</instanceType><br />  <location>41</location><br /><br />  ..........//Event and other information<br />  <startupCount>2</startupCount><br /></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"><br />          <ibmServer><br />            <name>AppNode</name><br />            <ibmAccount>xxxx</ibmAccount><br />            <keypair>yyyy</keypair><br />            <imageIdentifier>20001150</imageIdentifier><br />            <instanceType>BRZ32.1/2048/175</instanceType><br />            <location>41</location><br />            ..........//Event and other information<br />            <startupCount>2</startupCount><br />          </ibmServer><br /></serverType>

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"><br />      <name>db_tier</name><br />      .....//Event and other information<br />      <serverTypes><br /><br />	   <serverType role="manager" min="1" max="1"><br />          <ibmServer><br />            ....<br />          </ibmServer><br />        </serverType><br /><br />        <serverType role="ndbd" min="2" max="2"><br />          <ibmServer><br />            ...<br />          </ibmServer><br />        </serverType><br /><br />      </serverTypes><br /></tier>

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.

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><br />    .../Event and other information<br />    <tier displayindex="1"><br />     ...<br />    </tier><br /><br />    <tier displayindex="2"><br />     ...<br />    </tier><br /><br />    <tier displayindex="3"><br />     ...<br />    </tier><br /><br /></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"<br /> target="[tier=web_tier][serverrole=default]"><br />       <scriptName>apache.sh</scriptName><br />       <scriptPath>/root</scriptPath><br />       <scriptTemplate type="inline"><br />       <![CDATA[<br />               /etc/init.d/httpd start<br />               ]]><br />       </scriptTemplate><br /><br /></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

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

Onde publicIP1, 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

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<br />  Begin<br />       Execute start-server-default-logic<br />       Execute post-startup hook<br />  END<br /><br />Proc Stop-server-handler<br />  Begin<br />       Execute pre-shutdown hook<br />       Execute stop-server-default-logic<br />  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"><br />      <handler timeout="6000"><br />        <pre-process><br />          	<startServers><br />            	       <serverType role="[tier=app_tier][serverrole=default]" count="1"<br />                          addToEvent="true"/><br />          	</startServers><br />        </pre-process><br />        <process><br />         	 <command type="action" name="start-app"<br />              target="[tier=app_tier][serverrole=default][scaleupserver]"/><br />          <command type="action" name="configure-apache-balancer"/><br />          <command type="action" name="reset-apache"/><br />        </process><br />     </handler><br /> </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"><br />      <handler timeout="6000"><br />        <pre-process><br />          <recoverServers><br />            		<server server-to-recover="[context=event][param=instanceid]"/><br />          </recoverServers><br />        </pre-process><br />        <process><br />         	 <command type="action" name="start-app"<br />              target="[tier=app_tier][serverrole=default][recoveringserver]"/><br />          	<command type="action" name="configure-apache-balancer"/><br />          	<command type="action" name="reset-apache"/><br />        </process><br />      </handler><br /> </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 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.

01. 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).

02. 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).

03. 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<br />Script a ser executado:<br /><br />wget http://3rdparty-tools.s3.amazonaws.com/apache/httpd-2.2.14.tar.gz<br /> tar -xzvf  httpd-2.2.14.tar.gz<br /> cd httpd-2.2.14<br /> export CFLAGS=-O2<br /> ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all<br />  --enable-proxy_balancer=shared --enable-proxy_http=shared --enable-rewrite=shared<br />  --enable-proxy=shared<br /> make<br /> make install<br /> 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<br />Arquivo de configuração a ser copiado:<br /><Proxy balancer://mycluster><br /><br />        BalancerMember http://publicIP1:8080<br />        BalancerMember http://publicIP2:8080<br />        ....<br />        ....<br />        BalancerMember http://publicIPn:8080<br /><br /></Proxy><br />ProxyPass /app balancer://mycluster<br /><Location /balancer-manager><br />        SetHandler balancer-manager<br />        Order Deny,Allow<br />        Allow from all<br /></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><br />       #foreach ($node in $appNodes)<br />       BalancerMember http://$node.publicIP:8080<br />       #end<br /></Proxy><br />  ProxyPass /app balancer://mycluster<br /><Location /balancer-manager><br />       SetHandler balancer-manager<br />       Order Deny,Allow<br />       Allow from all<br /></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<br />Script a ser executado:<br /><br />cp httpd-IMOD.conf /usr/local/apache2/conf/extra/<br />/usr/local/apache2/bin/apachectl start<br />sed -i 's/COMMIT/-A INPUT -p tcp -m tcp --dport 80<br />  -j ACCEPT\n-A INPUT -p tcp -m<br />    tcp --dport 10050 -j ACCEPT\nCOMMIT/g' /etc/sysconfig/iptables<br />/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<br />Script a ser executado:<br /><br />/usr/bin/wget -O /opt/ APP .tar.gz<br />http:// SOURCE .com/ APP .tar.gz<br />cd /opt<br />tar -xzvf  APP .tar.gz<br />ln  -s /opt/ APP  /usr/local/ APP<br />export JAVA_HOME=/usr/local/java;<br />/usr/local/ APP /bin/startup.sh<br />sed -i 's/^.*FW_SERVICES_EXT_TCP=".*".*$/FW_SERVICES_EXT_TCP="8080 10050"/g'<br /> /etc/sysconfig/SuSEfirewall2<br />/etc/init.d/SuSEfirewall2_setup reload

Instalando o Java Development Kit
Ou install-jdk.

Tipo de ação: executável<br />Script a ser executado:<br /><br />/usr/bin/wget -O /opt/jdk1.6.tar.gz http://SOURCE.com/jdk1.6.0_16.tar.gz<br />cd /opt/<br /> tar -xzvf jdk1.6.tar.gz<br />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<br />Script a ser executado:<br /><br />/usr/local/apache2/bin/apachectl stop<br />sleep 5<br />rm -rf /usr/local/apache2/conf/extra/httpd-IMOD.conf<br />cp httpd-IMOD.conf /usr/local/apache2/conf/extra/<br />/usr/local/apache2/bin/apachectl start

04. 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}

05. 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).

06. 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

• A opção
  A wiki N-Tier Guide System Definition fornece detalhes sobre o arquivo System Definition.
• Este vídeo fornece alguns motivos para considerar o uso do IMOD para gerenciamento de aplicativo em nuvem.
• Visite o site da Kaavo para obter mais informações sobre a tecnologia da empresa.
• A opção
  O guia do usuário do Apache Velocity
  irá familiarizá-lo com o Velocity e a sintaxe da sua linguagem de
  script simples, porém poderosa, a Velocity Template Language (VTL).
• Nos recursos para desenvolvedores de nuvem do developerWorks,
  descubra e compartilhe o conhecimento e a experiência dos
  desenvolvedores de aplicativos e serviços que estão desenvolvendo os
  seus projetos de implementação de nuvem.

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.

***

artigo publicado originalmente no developerWorks Brasil, por Joydeep Biswas

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.