O uso de imagens virtuais interconectadas como forma de implementar pilhas de software está se tornando mais prevalente. Uma abordagem típica é pré-configurar a pilha de software para minimizar o esforço de implementação da solução.

Embora essa abordagem funcione bem para a implementação inicial, deve-se ter cuidado para reverificar as configurações após mudanças ambientais significativas, como:

• Restauração de um conjunto de imagens de backup como parte de um cenário de recuperação de desastre.
• Modificação de configuração de hardware (como inclusão de novos blades).
• Modificação de configuração de software (como inclusão de redes, hypervisors externos).

Este artigo descreve uma série de etapas que os clientes devem seguir para garantir que seu ambiente de imagem virtual seja devidamente verificado após mudanças ambientais significativas. A solução de software pré-integrado IBM® CloudBurst 2.1 é usada como exemplo das etapas necessárias para garantir o sucesso. A mesma metodologia pode ser usada para verificar outras pilhas de software pré-configuradas.

Apresentando os testes do CloudBurst 2.1

A pilha de software do CloudBurst 2.1 é composta de imagens virtuais pré-instaladas e pré-configuradas que contêm os produtos IBM para explorar as funcionalidades críticas necessárias para a computação em nuvem:

• Tivoli® Service Automation Manager (TSAM): Oferece a funcionalidade principal para um ambiente de computação em nuvem. Permite que o usuário solicite, crie, exclua, modifique e gerencie as imagens virtuais na nuvem.
• IBM Tivoli Monitoring (ITM): Mantém a disponibilidade e o gerenciamento de desempenho de imagens virtuais e as imagens virtuais provisionadas sob controle.
• Tivoli Usage and Accounting Manager (TUAM): Acompanha o consumo de recursos para funções de faturamento.

A implementação prática de ambientes de imagem virtual como o CloudBurst 2.1 exige uma nova verificação do ambiente de software depois de mudanças significativas no ambiente. Este artigo descreve uma série metódica de etapas para garantir a operação e o funcionamento de todo o ambiente. Isso envolve uma abordagem que passa do específico para o geral:

• Verificar o status de funcionamento de cada imagem virtual do ponto de vista de rede.
• Verificar as pilhas de software dentro de cada imagem virtual para garantir que estão ativas e operando corretamente.
• Em relação ao software, verificar os pontos de integração entre as imagens virtuais.

Concluir essas etapas garantirá o funcionamento e a operação do seu ambiente CloudBurst.

Observe que, para simplificar, os testes descritos não incluem o recurso opcional de alta disponibilidade de nó duplo.

Etapa 1: Verificando a configuração de rede

Primeiro vamos percorrer as questões para verificar a configuração da rede.

Configuração de rede padrão

A configuração de rede padrão das imagens de gerenciamento do CloudBurst 2.1 é mostrada na figura abaixo:

Na figura, são mostradas quatro imagens virtuais. Três das imagens virtuais (icb-tsam, icb-tuam, icb-itm) estão equipadas com duas placas da interface de rede virtuais (vNICs) e uma delas (icb-nfs) tem três vNICs. As vNICs de todas as quatro imagens virtuais são definidas no hypervisor.

Outras interfaces de rede (aquelas sem vNICs) são criadas em uma de duas maneiras: usando tags de rede local virtual ou com o Tivoli System Automation for Multiplatforms (TSA).

Tags de rede local virtual, também conhecidas como IEEE 802.1Q, são um padrão de rede de grupo de trabalho IEEE 802.1 para o compartilhamento de um link de rede Ethernet físico por diversas redes lógicas e independentes. Eles definem o significado de uma rede local virtual (VLAN) com respeito ao modelo conceitual que define a ligação na camada MAC e para o protocolo de árvore de amplitude IEEE 802.1D (que permite que os nós de diferentes VLANs se comuniquem entre si por meio de um comutador de rede com recursos de camada de rede OSI camada 3 ou por meio de um roteador.

Se o cliente estiver explorando os diversos recursos de rede do Tivoli Service Automation Manager, a figura de rede terá mais NICs criados com tags de rede local virtual e TSA.

Verificando se as interfaces de rede estão ativas

A primeira etapa é verificar se todas as interfaces de rede estão ativas e corretamente configuradas:

Observando o hypervisor, nota-se para cada imagem virtual as seguintes configurações:

• O primeiro adaptador de rede é conectado à rede de VM.
• O segundo adaptador de rede é conectado à rede de gerenciamento.
• O terceiro adaptador de rede (apenas para icb-nfs) é conectado à rede do cliente.

Se efetuarmos login em cada imagem virtual de gerenciamento, o comando ifconfig mostrará todos os adaptadores de rede definidos. A tabela a seguir mostra todos os endereços IP definidos por padrão no CloudBurst 2.1:

*Note que as imagens virtuais icb-tivamha e icb-nfs-ha existem apenas no caso de ser explorada a alta disponibilidade de nó duplo.

Como fazer isso: Um ping bem-sucedido, usando todas as interfaces definidas, demonstrará que a configuração de rede está correta.

À primeira vista, este teste pode parecer muito básico e desnecessário, mas saiba que muitos problemas na implementação de imagens virtuais (especialmente com o agente IBM Tivoli Monitoring) e problemas de encaminhamento de URL costumam estar relacionados a uma configuração de rede incorreta.

Etapa 2: Verificando a pilha de software

O poder da solução CloudBurst vem do poder combinado dos produtos individuais incluídos nela. Com esse poder vem a complexidade de sua infraestrutura.

Nesta seção, veremos uma maneira simples de assegurar que o middleware e os aplicativos sejam executados de forma adequada.

Todo o software necessário é configurado para iniciar automaticamente na inicialização. Assim, assegure-se de que todo o software está ativo e funcionando. Será preciso ir a cada imagem virtual mencionada nas subseções a seguir e fazer as verificações identificadas indicadas.

Verificações da imagem virtual icb-itm

• Verifique se o DB2® está ligado. Para o DB2, é suficiente que o usuário db2inst1 ative db2start. Deve aparecer uma mensagem dizendo que o gerenciador do banco de dados já está ativo.
• Confirme se estes seis componente do IBM Tivoli Monitoring instalados estão em execução:
  • Tivoli Enterprise Monitoring Server
  • Linux® – agente de sistema operacional
  • agente de proxy de armazém
  • agente de resumo e limpeza
  • Tivoli Enterprise Portal Server
  • Eclipse Help Server

Como fazer isso: Para os componentes de ITM, a saída de /opt/IBM/ITM/cinfo -r mostra-os no estado de execução (precisam ser iniciados e parados como virtuser).

Verificações da imagem virtual icb-nfs

• Verifique se no icb-nfs, o servidor HTTP, o servidor de correio, o servidor do Network File System e o servidor Samba estão em execução. Mesmo que não esteja usando a alta disponibilidade de nó duplo, todos os serviços serão gerenciados pelo TSA.

Como fazer isso: Para verificar se tudo está em execução adequadamente, observe a saída de lssam -V e verifique se todos os recursos estão on-line, como mostrado na figura abaixo.

Na figura, os recursos incluem:

• O recurso samp-ihs-server representa o servidor HTTP.
• O recurso samp-nfsserver representa o servidor NFS.
• O recurso samp-samba-server representa o servidor Samba.
• O recurso samp-postfix-server representa o servidor de correio.
• O recurso samp-mgmt-virtual-ip representa o endereço IP do serviço em eth1.
• O recurso samp-virtual-ip representa o endereço IP do serviço em eth0.
• O recurso samp-prvs-eth0.100 representa o endereço IP do serviço em eth0.100.

Note que a saída mostrada na Figura 3 não contém o endereço IP do serviço para eth2; não tinha sido incluído quando obtive essa captura de tela.

Verificações da imagem virtual icb-tivsam

• Verifique se no icb-tivsam, as instâncias do DB2 que pertencem a ctginst1 e dasusr1, LDAP, WebSphere, Tivoli Provisioning Manager e Tivoli Service Automation Manager estão ativas e em execução.

No caso de icb-nfs, mesmo que não esteja sendo explorada a alta disponibilidade de núcleo duplo, todos os serviços serão gerenciados pelo TSA.

Como fazer isso: Para verificar se tudo está em execução adequadamente, observe a saída de lssam -V É preciso verificar se todos os recursos estão on-line, como mostrado na figura a seguir.

Na figura acima, os recursos incluem:

• O recurso db2_ctginst1_0-rs representa a instância de DB2 usada pelo Tivoli Service Automation Manager.
• O recurso db2_idsccmdb_0-rs representa a instância de DB2 usada pelo Tivoli Directory Server (LDAP).
• O recurso ids-rs representa o LDAP.
• O recurso tpm_tio-rs representa o Tivoli Provisioning Manager.
• O recurso was_MXServer-rs representa o MXServer.
• O recurso was_dmgr-rs representa o WebSphere Deployment Manager.
• O recurso was_nodeagent-rs representa o agente do nó do WebSphere.
• O recurso was_server1-rs representa o servidor de aplicativos server1.
• O recurso was_webserver-rs representa o WebSphere Application Server.
• O recurso samp-mgmt-virtual-ip representa o endereço IP do serviço em eth1.
• O recurso db2ip-rs representa o endereço IP do serviço em eth0.
• O recurso samp-prvs-eth0.100 representa o endereço IP do serviço em eth0.100.

Verificações da imagem virtual icb-tuam

• Verifique a imagem virtual icb-tuam para se certificar de que o DB2 e o servidor de aplicativos tenham sido iniciados.

Como fazer isso: No DB2, é suficiente que o usuário db2inst1 ative db2start. Se o gerenciador do banco de dados estiver em execução, o db2start retorna uma mensagem dizendo que o gerenciador do banco de dados já está ativo.

Como fazer isso: Como raiz do servidor de aplicativos, ative /opt/IBM/tuam/ewas/bin/serverStatus.sh server1 -username virtuser -password <virtuser’s password>. Se o servidor estiver ativo e em execução, o comando retorna uma mensagem dizendo que o servidor foi iniciado.

Os detalhes sobre como iniciar e parar a pilha de software são encontrados no centro de informações CloudBurst 2.1, em Recursos (logo abaixo).

Verificação final de software iniciado

Por fim, efetue login nas interfaces com o usuário dos produtos:

• ITM: https://192.168.88.7:1920 (usuário padrão sysadmin).
• TSAM: https://192.168.88.2/SimpleSRM (usuário padrão PMRDPCAUSR).
• TPM: https://192.168.88.7/maximo (usuário padrão maxadmin).
• TUAM: http://192.168.88.8:11052 (usuário padrão virtuser).

Efetuar login com sucesso nas respectivas interfaces com o usuário (UIs) demonstra que o software individual foi iniciado corretamente.

Etapa 3: Verificando as funcionalidades do software atômico

Depois que todas as verificações da etapa 2 tiverem sido feitas com êxito, pode-se começar a analisar as funcionalidades do produto específico. Digamos que estejamos passando com êxito de “teste de unidade” para “teste funcional”.

Vamos começar com os mais fáceis e rápidos primeiro.

Teste funcional de Network File System (icb-nfs)

Para essa imagem virtual, o teste funcional visa assegurar que o servidor do Network File System e o servidor Samba estejam funcionando adequadamente. Uma falha aqui compromete a capacidade de executar implementações com o agente ITM.

Como fazer isso: O modo mais fácil de verificar se esses dois serviços estão funcionando é tentar usá-los. A partir do servidor da imagem virtual, tente se conectar ao sistema de arquivos exportado abrindo o Windows Explorer e digitando \\192.168.88.4\repository e efetuando login com Administrator /<Administrator’s password>. O resultado é mostrado na figura abaixo.

Se planejar fornecer imagens virtuais no Windows® , é bom fazer uma verificação análoga de uma das imagens virtuais provisionadas antes de tentar implementar uma imagem virtual, juntamente com o agente ITM.

Naturalmente, é preciso usar o endereço de icb-nfs adequado na rede de gerenciamento especificada na interface com o usuário administrativo do Tivoli Service Automation Manager (como visto na figura a seguir). Na configuração padrão, é bom usar Error! Hyperlink reference not valid.

 

É mais fácil verificar o servidor de Network File System. Visto que não precisamos de imagem virtual provisionada, basta usar uma das imagens virtuais de gerenciamento. Para esse exemplo, vamos usar icb-itm. Crie um diretório temporário ali (/mytestdir) e tente montar o sistema de arquivos exportado: mount 10.100.0.4:/repository /mytestdir.

No caso do servidor Samba, lembre-se de fazer os testes com o endereço IP de icb-nfs que corresponde à rede de gerenciamento definida na interface com o usuário administrativo do Tivoli Service Automation Manager.

Teste funcional do IBM Tivoli Monitoring Server (icb-itm)

No caso do icb-itm, um teste simples é verificar se os agentes ITM em execução nas imagens virtuais de gerenciamento estão aparecendo na interface com o usuário:

Dessa forma, é possível verificar se os produtos de monitoramento foram iniciados e se a conexão com o banco de dados está funcionando.

Teste funcional do Tivoli Usage and Accounting Server (icb-tuam)

No caso do icb-tuam, também é suficiente verificar se é possível efetuar login na interface com o usuário e navegar nela (figura abaixo).

 

Teste funcional do Tivoli Service Automation Manager (icb-tivsam)

No caso do Tivoli Service Automation Manager, os testes funcionais não são tão simples. Suponhamos que já tenhamos criado uma equipe; o teste principal que precisamos fazer é criar um projeto.

Essa é a única maneira de verificar se toda a configuração definida na interface com o usuário administrativo está correta e é consistente.

O Tivoli Service Automation Manager 7.2.1 oferece verificação de erro melhorada, em especial para configuração de rede. Ainda há nada melhor do que tentar um fornecimento.

Sugiro primeiro tentar um fornecimento simples (ou seja, sem agente ITM ou software adicional) e depois passar para cenários mais complexos (a próxima seção tem mais informações a esse respeito). Dessa forma, pode-se limitar as variáveis caso seja necessário executar uma determinação de problema.

Como fazer isso: Antes do fornecimento, verifique a UI administrativa do Tivoli Service Automation Manager para ver todos blades de fornecimento entre os computadores de fornecimento. Além disso, pode ser interessante verificar se a configuração do conjunto de nuvem que será usado para o fornecimento está correta:

1. Navegue até Go To > Service Automation > Cloud Pool Administration.
2. Selecione seu conjunto de nuvem.
3. Clique na guia Cloud Pool Network Settings e verifique se o conjunto está anexado às redes adequadas e se aquela disponível pelo icb-tivsam está com a caixa de opção Use as management Interface marcada.

Em seguida, pode-se verificar se o conjunto de recursos correspondente está configurado para o cluster adequado de fornecimento: Go To > Administration > Provisioning > Resource Pools.

A última coisa a verificar é se as redes anexadas ao conjunto de nuvem têm as variáveis apropriadas definidas para os endereços IP bloqueados e IDs de rede local virtual: Go To > IT Infrastructure > Provisioning Inventory > Subnetworks.

Depois de terminar isso, efetuar login na interface com o usuário de Web 2.0 do TSAM e crie um projeto. Certifique-se de selecionar o conjunto de recursos correto.

Após a conclusão bem-sucedida do fornecimento, deve-se receber uma notificação por e-mail do aplicativo Tivoli Service Automation Manager contendo a senha administrativa para acessar a imagem virtual. Conecte-se à imagem e verifique se a configuração de rede é a esperada.

Etapa 4: Verificando os pontos de integração

Se todas as etapas anteriores tiverem funcionado, estaremos prontos para verificar os pontos de integração:

• Redirecionamento de URL.
• TSAM-ITM: Criar uma imagem virtual equipada com agente ITM.
• TSAM-TUAM: Exibir relatórios de fatura.

Redirecionamento de URL

O redirecionamento de URL é a funcionalidade que permite acessar as interfaces administrativas e da Web 2.0 do TSAM e as interfaces com o usuário do TUAM usando o endereço IP de icb-nfs. Assim, o teste simples aqui é tentar abrir estas UIs com o endereço adequado:

• UI administrativa de TSAM: https://icb-nfs/maximo.
• UI de Web 2.0 de TSAM: https://icb-nfs/SimpleSRM.
• UI de TUAM: https://icb-nfs/ibm/console.

Como fazer isso: De acordo com o endereço IP usado para acessar o icb-nfs, certifique-se de que o sistema a partir do qual está sendo usado o navegador da Web possa acessar a rede correspondente. Por exemplo, se estiver sendo usado o navegador no servidor de imagem virtual, o redirecionamento funcionará usando https://icb-nfs/maximo ou https://192.168.88.4/maximo, mas não funcionará usando https://10.90.0.4/maximo porque o servidor de rede virtual não tem acesso a essa rede.

Integração de TSAM e ITM

O teste principal para verificar a integração TSAM-ITM é criar um projeto marcando a caixa de seleção Monitoring Agent to be Installed. Ali, é preciso verificar se não apenas a solicitação de serviço é encerrada em estado resolvido, mas também se a UI do Tivoli Monitoring mostra o agente e os dados de monitoramento correspondentes:

Se tiverem sido incluídas redes adicionais com tags de rede local virtual, o agente ITM deve ser instalado como software adicional. A caixa de seleção Monitoring Agent to be Installed só funciona para eth0.100.

Integração de TSAM e TUAM

Para verificar a integração entre TSAM e TUAM precisa haver uma quantidade correspondente a um dia de dados coletados. É preciso aguardar um dia após um fornecimento bem-sucedido ou eliminação antes de os dados estarem disponíveis nos relatórios de fatura.

Como fazer isso: Um dia após o fornecimento/eliminação, os seguintes itens devem ser verificados:

• Verificar se, no icb-tivsam, em /var/IBM/TSAM/metering, foi criado um arquivo RDP_*<date>.txt e se o seu tamanho é diferente de zero. Cada dia, um arquivo é criado com os dados correspondentes ao dia anterior.
• Verifique no icb-tuam, em /opt/IBM/tuam/samples/logs/collectors, se o arquivo verificado na instrução anterior está presente (ele é movido para lá por uma tarefa cron).
• Na UI do TUAM, se acessarmos Tivoli Usage and Accounting Manager > Chargeback Maintenance > Load Tracking, é possível ver os dados importados no dia especificado.
• Na UI administrativa do TSAM, é possível exibir os relatórios de fatura: Go To > Administration > Report Administration.

Em conclusão

As etapas descritas neste artigo são as principais que precisam ser executadas para verificar o status de funcionamento da sua pilha de software do CloudBurst.

Esses testes sugeridos abrangem as funcionalidades básicas de cada produto de software incluído na solução e todos os pontos de integração funcional predefinidos.

Esses testes devem ser as verificações principais a serem feitas após a aplicação de mudanças no seu ambiente CloudBurst; por exemplo, depois de restaurar um conjunto de imagens de backup em um cenário de recuperação de desastre ou após a atualização da pilha de software.

Recursos

Aprender

• Para obter mais informações sobre os tópicos deste artigo:
  • Comece pelo centro de informações do CloudBurst 2.1.
  • No caso de falha nos testes descritos neste artigo, aqui há alguns resultados de resolução de problemas para o CloudBurst e para TSAM.
  • Estes tutoriais do CloudBurst o aprofundarão na execução de tarefas básicas, como aquelas mencionadas no artigo.

• 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.
• Mais recursos do developerWorks que complementam este artigo se encontram em Tivoli no developerWorks e WebSphere no developerWorks.
• Próximas etapas: Descubra como acessar o IBM SmartCloud Enterprise.

Obter produtos e tecnologias

• Consulte as imagens do produto disponíveis no IBM SmartCloud Enterprise.

Discutir

• Participe de um grupo de computação em nuvem no developerWorks.
• Leia todos os excelentes blogs sobre nuvem no developerWorks.
• Participe da comunidade do developerWorks, uma rede profissional e conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.

Sobre o autor
Rossella De Gaetano é líder de teste do IBM Service Delivery Manager. Ela é responsável pelo controle de qualidade da pilha de software Tivoli incluída no IBM CloudBurst e no IBM Service Delivery Manager.