Reparação dos Erros de Clonagem da Máquina Virtual em Nuvem

Resolva problemas com o Runtime Image Activation

Um benefício da virtualização e sistemas virtuais é a possibilidade de cloná-los para serem reutilizados em ambientes diferentes. Os requisitos de fornecimento de dados externos, por exemplo, configurações de rede, como endereços IP, podem causar problemas ao clonar uma máquina virtual para ser usada em um novo ambiente. Se os dados externos não estiverem disponíveis durante o processo, a reconfiguração da máquina virtual provavelmente será incompleta. Os autores oferecem uma maneira de lidar com este problema, mesmo sem muito conhecimento do aplicativo ou sem uma forma de scripts de ativação para ajudar. O Runtime Image Activation (RIA) é uma interface de protótipo de linha de comando que permite orquestrar técnicas de rede para se certificar de que as suas máquinas virtuais clonadas estejam configuradas de maneira apropriada.

Roberto Ragusa, Staff Software Engineer, IBM

Roberto é Staff Software Engineer no IBM Smart Solutions Lab em Roma, Itália, onde trabalha na solução de gerenciamento de ativos digitais NICA (Networked Interactive Content Access). Suas responsabilidades incluem o projeto e as atividades de implementação, com sete anos de experiência específica na pesquisa de documentos, classificação automática, desempenho de backend e a escalabilidade em plataformas Linux e UNIX. Recentemente, ele escreveu um mecanismo de procura rápido e baseado em Lucene e gosta de lidar com redes avançadas.



Claudio Marinelli, IBM Tivoli Configuration Manager Designer, IBM Tivoli Software

Claudio MarinelliClaudio Marinelli tem 20 anos de experiência trabalhando no segmento de mercado de TI com a IBM em diversas funções técnicas dentro da organização de desenvolvimento de software. Atualmente, ele é Senior Technical Staff Member da IBM no IBM Tivoli. Claudio é o principal arquiteto da área de gerenciamento de imagem responsável pelo TPM para Images e ICON, respectivamente, o produto para o gerenciamento de ciclo de vida de imagem virtual de base e o componente que automatiza o desenvolvimento e a composição de imagens virtuais.



Luigi Pichetti, Senior Technical Staff Member, Tivoli, SPDA, IBM

Luigi Pichetti é Senior Technical Staff Member na marca Tivoli do IBM/SWG. Luigi tem 20 anos de experiência no segmento de mercado de TI com foco específico no desenvolvimento e arquitetura de produtos de Gerenciamento de Sistemas e Prestação de Serviços, componentes e soluções. Seu foco mais recente tem sido o Gerenciamento de Virtualização e Soluções em Nuvem, onde ele está liderando a arquitetura das soluções ISDM, IBM Cloudburst e no Image com base na entrega de produtos IBM.



Alex Donatelli, Senior Technical Staff Member, IBM Tivoli Software

Alex Donatelli's photoAlex Donatelli foi nomeado Distinguished Engineer para o Service Process Automation em 2008. Ele comanda a estratégia técnica de produtos-chave como o Tivoli Provisioning Manager, Tivoli Endpoint Manager, Tivoli Workload Scheduler e Tivoli Usage and Accounting Manager. No final de 2009, Alex assumiu a liderança da equipe do Tivoli Performance Leadership e está conduzindo as melhorias de desempenho e escalabilidade no portfólio baseado no Maximo e o espaço de computação em nuvem.



08/Mar/2012

Um dos benefícios da exploração de imagens virtuais de sistema é a capacidade de cloná-las para que elas possam ser reutilizadas em ambientes diferentes. Isso geralmente requer algum esforço para reconfigurar os aplicativos de software que as imagens contêm. A questão de reconfiguração é conhecida ao clonar máquinas virtuais com software pré-instalado, em especial, quando se está trabalhando com aplicativos que implementam serviços do lado do servidor (como o DBserver, AppServer, etc.), que normalmente não podem suportar DHCP e se está recebendo solicitações de entrada TCP em um endereço estático.

Há um processo existente para resolver este dilema de reconfiguração de imagem, que é conhecido como o processo Image Re-Activation. Ele explora técnicas tais como o uso de um mecanismo de ativação (como o IBM Activation Engine, uma estrutura de ativação usada para a customização do tempo de inicialização das imagens virtuais) e scripts de ativação específicos do aplicativo. O problema com o uso do processo Image Re-Activation nessas circunstâncias é que ele assume que, para todos os aplicativos mal configurados, existe um script adequado que pode ser executado para reconfigurar tudo corretamente.

Neste artigo, descreveremos uma forma alternativa para tentar resolver o problema que pode culminar em casos em que não há nem conhecimento do aplicativo em termos de artefatos de configuração que foram impactados pela configuração original de rede, nem a disponibilidade de alguns scripts de ativação pré-desenvolvidos para alterar tais artefatos de configuração específicos do aplicativo. Informações incompletas sobre o ambiente podem existir quando não se sabe quais aplicativos estão presentes na máquina virtual ou se não há script de reativação disponível para eles (o aplicativo pode não ser um aplicativo preenchido, ou pode ser um aplicativo muito recente ou que não esteja documentado, ou um aplicativo ao qual não se possa aplicar engenharia reversa, etc.).

Em casos como este, quando o foco é abordar a má configuração de rede da pilha de software contida que resultou da clonagem da máquina virtual, o método que propomos poderia ter um resultado melhor reativando a máquina virtual. Nossa abordagem proposta é o agnóstico de aplicativo, que chamamos de Runtime Image Activation (RIA). Desenvolvemos um protótipo de uma interface de linha de comando RIA de amostra que permitirá que você orquestre ou implemente as técnicas de rede descritas neste artigo, aquelas que permitem resolver o problema de má configuração da clonagem.

A clonagem perfeita nem sempre é uma boa ideia

O fornecimento de máquina é uma função central nos ambientes orientados por nuvem. Novas máquinas físicas são colocadas on-line ou novas máquinas virtuais são criadas com muita regularidade. Com frequência, as imagens em tempo de execução (isto é, todo o conteúdo dos discos) são clonadas a partir de uma máquina existente ou a partir de um repositório de modelos úteis.

Um problema recorrente ao clonar as imagens de tempo de execução é que elas contêm algumas informações que dependem dos ambientes externos, como endereços IP de configuração de rede. O sistema operacional e os aplicativos incluídos provavelmente não conseguirão funcionar adequadamente sem as reconfigurações necessárias. Os erros típicos incluem:

  • Falhas ao tentar conectar a um soquete de rede.
  • Falha ao tentar contatar um serviço de rede necessário.
  • Expor endereço IP duplicado na rede, certamente, causará sérios problemas, como falhas aleatórias de conexão, desconexões e instabilidade geral da rede.

As informações sobre quais endereços IP que uma máquina está configurada para usar podem ser encontradas nos arquivos de configuração do sistema operacional. A primeira etapa a ser feita após a clonagem de uma máquina virtual é substituir o antigo endereço IP pelo novo. É possível automatizar esta tarefa com scripts e ferramentas que trabalham diretamente sobre o conteúdo da imagem de tempo de execução de uma maneira que depende do sistema operacional específico que está sendo usado, por exemplo, é possível substituir cadeias de caractere em arquivos /etc para sistemas Linux®/UNIX® ou alterar as entradas de registro em sistemas Windows® .

É frequente que os aplicativos instalados contenham alguma configuração interna derivada da configuração da rede e obtida no momento da instalação, por exemplo, um servidor da web poderia ter salvado algo de seus próprios dados de configuração, como o IP e/ou o nome de host que ele anunciará ao servir solicitações HTTP/HTTPS. Uma forma de corrigir isso seria reinstalar o aplicativo, o que significa, basicamente, partir da uma abordagem de "clonagem de uma máquina pré-configurada" para uma "instalação total da máquina". Isso é chato e ineficiente, — pois anula todas as vantagens de clonagem, como ser capaz de criar máquinas virtuais de uma maneira rápida, confiável e consistente.

Então, qual é a abordagem tradicional para que você possa reativar o software em máquinas virtuais após eles terem sido clonadas?


Uma abordagem tradicionalista: Corrija todas as configurações

A maneira que abordamos normalmente essa tarefa é modificar de modo cirúrgico a configuração incorreta onde quer que ela esteja armazenada. De uma maneira caso a caso, individualizada. É possível entender o trabalho envolvido seguindo este método. Isto implica uma compreensão muito precisa de quais aplicativos devem estar presentes e quais operações devem ser executadas em cada um deles. As operações referidas podem ser executadas como scripts na imagem (que não está em execução) montada ou como uma primeira inicialização ou nível de agente na máquina que está em funcionamento.

Supondo que você tenha perfeito conhecimento do que deve ser feito, o resultado final se torna ideal: o aplicativo não parece ser diferente daquele que você acabou de instalar "corretamente".

Por outro lado, este método é frágil; pequenas variações de detalhe (como "o usuário poderia mover a configuração para outro caminho?", "esta versão do software ainda está usando o mesmo armazenamento de configuração que a antiga?" e assim por diante) tornam esta abordagem um pesadelo iminente para a manutenção dos registros.

As tentativas de proceder com a correção das configurações sem conhecimentos específicos do aplicativo estão fadadas a falhar. A digitalização de toda a imagem e a substituição de todas as ocorrências do IP antigo (em forma textual ou binária) pelo novo nunca deve ser considerada de maneira séria por quem compreende a Lei de Murphy.

Há uma estratégia melhor... chamamos isso de "usar os truques de rede".


Uma nova estratégia: Truques de rede

Agora, vamos descrever uma abordagem alternativa e inovadora para a correção de erros de configuração clonados sem o conhecimento específico do software envolvido. Primeiro, vamos configurar o cenário:

Vamos considerar o caso frequente de máquinas que estão exportando serviços por meio de daemons alcançáveis externamente; no momento da instalação, infelizmente, os daemons salvam em sua configuração os endereços IP nos quais eles farão o recebimento. Provavelmente estes daemons falharão ao serem iniciados na máquina clonada, pois não conseguirão se ligar a uma interface de rede.

Em vez de tentar corrigir a configuração do aplicativo, podemos tentar remodelar o ambiente de rede para enganar o aplicativo para que ele funcione com a configuração incorreta. O sistema operacional da própria máquina nos ajudará neste objetivo.

A ideia geral

A Figura 1 descreve todo o processo.

Figura 1. Descrição geral da solução
Descrição geral da solução

À esquerda está a máquina original (chamada máquina de origem) que é clonada para criar a máquina à direita (chamada máquina-alvo; veja o ponto laranja 1). Havia três aplicativos instalados no interior da máquina de Origem no momento em que ela foi clonada. Suponha que app1 seja capaz de detectar automaticamente o IP atribuído à máquina, mas que app2 e app3 estejam usando endereços IP salvos em seus próprios arquivos de configuração (textual ou banco de dados).

O problema para a máquina-alvo é que depois de alterar o endereço IP antigo (IPS) para o novo (IPT; ver o ponto laranja 2), os clientes externos só serão capazes de alcançar o app1; o app2 e app3 não estarão disponíveis, pois não puderam ser inicializados já que a ligação em uma interface com IPS endereço falhou.

O que você deve fazer?

Uma interface de rede adicional fictícia, talvez...

Para começar, crie uma interface de rede adicional. É possível criar quantos aliases de interface quiser em Linux. Por exemplo, é possível criar uma interface de loopback adicional (além da lo comum, configurada como 127.0.0.1/8) e atribuir o IP antigo a ela (veja o ponto laranja 3; Figura 1). A interface adicional pode ser gerada como um alias de lo e será identificada como lo:0. Como uma alternativa, também é possível gerar eth0:0, um do dispositivo eth0.

Depois de fazer isso, o aplicativo configurado incorretamente poderá ser inicializado e se ligar a esta interface falsa. Ainda é impossível aceitar conexões de máquinas externas. Espera-se que hosts externos tentem usar o novo IP, de modo que os pacotes cheguem à nossa máquina clonada e sejam descartados imediatamente já que nenhum processo está ligado à interface com o novo IP.

A Figura 2 mostra um novo endereço (IPT) de 192.168.31.9 e um endereço antigo (IPS) de 10.10.9.9.

Figura 2. Um servidor é iniciado e se liga ao endereço falso
Um servidor é iniciado e se liga ao endereço falso

Há um daemon que pôde ser inicializado se ligando ao IP antigo e "errado".

Em seguida, voltemos o nosso olhar para o redirecionamento do Network Address Translation no nível do kernel.

Redirecionamento de NAT em nível de kernel

Como segundo passo, peça que o sistema operacional intercepte todas as conexões de entrada para o novo IP e redirecione-as silenciosa e internamente para o IP antigo (sim, isso não é um erro de digitação...redirecione o NOVO endereço para o endereço ANTIGO).

Esse redirecionamento é feito facilmente no nível do kernel como uma regra de Network Address Translation. O redirecionamento de NAT não possui implicações de desempenho mensuráveis, já que é apenas um truque comum já bem conhecido usado em firewalls e gateways. O corretor de conexão (veja a estrela cor de laranja na Figura 1) desempenha este papel.

Também é necessário definir as regras de roteamento dos computadores cliente e qualquer nó intermediário, permitindo que o tráfego direcionado para o IP antigo alcance realmente a máquina.

Última coisa: É necessário redirecionar apenas as portas específicas.

Daemon 'cão de guarda' de fornecimento NAT

Você deve saber quais portas redirecionar, pois uma regra newIP-to-oldIP geral quebraria todos os aplicativos que estão sendo recebidos corretamente no novo IP (por exemplo, aqueles que foram espertos o suficiente para detectar endereços IP em tempo de execução em vez de ler as suas próprias configurações ultrapassadas).

Você ainda deseja evitar qualquer conhecimento específico do aplicativo (na verdade, não estamos tentando saber quais aplicativos estamos tentando corrigir), então, é necessário descobrir as portas usadas de forma automática. Para conseguir isso, solicite ao sistema operacional a lista das portas em que alguém está recebendo por meio da interface com o IP antigo.

Esta lista é obtida no Linux com a opção netstat -l ; organize o redirecionamento de NAT para aquelas portas.

Para obter maior solidez, repita essa verificação e redirecione a fase a cada poucos segundos, assim é possível lidar com aplicativos com inicialização lenta ou aplicativos que vinculam e desvinculam portas de maneira dinâmica.

O daemon "cão de guarda" (ponto laranja 4 e 5, Figura 1) tem a função de realizar a verificação e conduzir o broker.

As Figuras 3 e 4 mostram o "cão de guarda" em ação.

Figura 3. O "cão de guarda" em ação, ele cria uma regra de redirecionamento
O

É possível ver que o "cão de guarda" detectou alguém escutando o 10.10.9.9:80 e criou uma regra de redirecionamento para sequestrar, de forma transparente, o tráfego direcionado para 192.168.31.9:80 em direção ao 10.10.9.9:80.

Figura 4. O cliente estabelece uma conexão com sucesso
O cliente estabelece uma conexão com sucesso

Um cliente externo é agora capaz de se conectar ao servidor apontando para o 192.168.31.9:

  • Do ponto de vista do cliente, a máquina possui um novo endereço (192.*).
  • Do ponto de vista do servidor, a máquina ainda possui o endereço antigo (10. *), mas pode continuar atendendo às solicitações de rede de entrada como era antes da máquina virtual ser clonada.

Conclusão, esta abordagem consiste em

  • Definir uma interface fictícia com o IP antigo para que os daemons configurados de modo incorreto possam ser iniciados sem problemas de rede.
  • Ao mesmo tempo, criar um daemon "cão de guarda" que controle a mesa de recebimento com relação à interface fictícia com o IP antigo. À medida que são descobertos ouvintes lá, o daemon "cão de guarda" organiza o redirecionamento de porta do novo para o antigo IP.

O IP antigo não é visível para os clientes externos, que esperam que o servidor seja configurado corretamente com o novo IP. Os daemons funcionarão por meio da ligação ao novo IP e por meio da ligação ao IP antigo, graças ao truque NAT que foi feito, realizado pelo sistema operacional.

Porém, existem alguns outros truques relacionados à reconfiguração que podem ser usados para tornar a solução mais completa.


Complementando a estratégia: Truques de configuração

Enquanto o mecanismo de aliasing de IP descrito aborda a maioria dos nossos objetivos, existem truques de configuração adicionais que também podem ser orquestrados para fornecer uma solução mais completa:

  • Filtragem de ARP (ARP é o Address Resolution Protocol)
  • Resolução do nome e proxy DNS
  • getHostName() hook

Filtragem de ARP

A configuração das interfaces falsas em hosts Linux pode ter uma consequência desagradável. Mesmo que a interface falsa seja local (lo:0 em vez de eth0:0), as solicitações ARP são, por padrão, respondidas em qualquer interface para todos os IPs configurados em qualquer interface da máquina.

Isto significa que o IP falso está visível de alguma maneira (e acessível, na verdade) a partir dos clientes. É desejável uma operação com dissimulação perfeita, especialmente se você desejar fazer vários clones ou cópias da máquina de origem no mesmo segmento de rede.

É possível fazer isso no Linux mudando o parâmetro de rede sysctlarp_ignore para 1 a fim de evitar o comportamento padrão da média (0 para responder a todas as solicitações de ARP).

Resolução do nome e proxy DNS

No caso de os daemons app2/app3 representados na Figura 1 na máquina virtual clonada terem mantido uma referência estática ao antigo nome do host (digamos HNS), além ou no lugar do IP antigo (IPS), também será necessário influenciar a cadeia de resolução de nome para retornar o IP correto.

Isto pode ser conseguido atualizando o arquivo de configuração /etc/hosts local de modo que qualquer consulta pelo antigo nome do host (HNS) retorne o novo IP (IPT). No caso de o processo de resolução de nomes explorar um servidor de nome externo, é possível instalar um proxy DNS local configurado para ser o servidor de nome de cadeia direita de resposta, o que responderá de forma coerente com o arquivo /etc/hosts modificado.

Usando um gancho getHostName()

Uma estratégia de configuração adicional que pode vir a calhar é o "gancho" — capturando a chamada de função — da função getHostName() de modo que ela retorne valores modificados (em outras palavras, o nome do host antigo).

Um protótipo foi criado e pode ser aninhado em níveis de usuários diferentes (por exemplo, a raiz ampla ou para afetar os processos em execução com um privilégio de usuário específico e inferior).

Reunindo tudo

Para facilitar o processo geral de configuração, existe uma linha de comando RIA de protótipo para Linux que é capaz de aplicar as técnicas de configuração conforme já foi descrito neste artigo.

Aqui está a sintaxe e o uso de amostra em um sistema virtual RHEL:

./ria start -oh <oldhostname> -oi <old_ipv4> -ni <new_ipv4> [options]
./ria stop | status

./ria start -oh oldhostname.domain.com -oi 10.10.1.1 -ni 1.2.3.4 -ipalias -hnresolv -dnat

Conclusão

A implementação real desta técnica mostrou-se muito bem-sucedida. Testamos no servidor da web (Apache) e nos servidores de ambientes de host (IBM WebSphere® Application Server) dos aplicativos que precisaram ser instalados com uma configuração de IP estático e que, após a clonagem da máquina virtual, não funcionariam mais, pois a pilha de software ainda estaria tentando ligar, ouvir ou aceitar a configuração do IP antigo armazenada em artefatos de configuração específicos de aplicativo.

A abordagem RIA contornou o problema, deixando a pilha do servidor de software trabalhar no novo ambiente, mesmo se continuasse a pensar que ainda estava no ambiente antigo. A abordagem requer a regressão dos principais casos de uso do produto.

Tenha em mente que a abordagem Image Re-Activation é sempre uma alternativa viável a ser explorada. Ela é uma espécie "cirúrgica" e definitiva de abordagem, já que tem o objetivo de "remover" a configuração do aplicativo antigo e substituí-la por uma nova. Isso pode ficar caro e às vezes não é a melhor abordagem.

No entanto, em todos os casos em que não há conhecimento, nenhum plano de investimento ou nenhuma forma documentada para alterar a configuração integrada de aplicativos de software, você deve recorrer à abordagem agnóstica de aplicativo RIA.

Uma possível objeção que os usuários poderiam levantar: O que acontece durante os segundos quando o aplicativo tiver sido iniciado, mas o daemon NAT ainda não tiver providenciado o redirecionamento?

A resposta é que o serviço parece simplesmente indisponível para clientes externos; do ponto de vista externo, o serviço parece ter sido iniciado com êxito apenas alguns segundos mais tarde. Nenhum efeito negativo significativo pode ser observado quando se usa o tempo de pesquisa razoável, como pesquisar uma vez por segundo durante alguns minutos (para pegar imediatamente o que estiver começando) e depois relaxar, pesquisando uma vez a cada 5 a 10 segundos.

O método Runtime Image Activation pode ser facilmente incorporado ao software de fornecimento em nuvem, e tem sido transformado com sucesso em protótipo usando o Tivoli® Pilha de Cloud Management (Tivoli Service Automation Manager, TSAM). O conhecimento de IP antigo (que pode ser especificado quando as imagens são importadas e registradas na ferramenta de implementação em nuvem) e de novos IPs (que a ferramenta de implementação em nuvem gera e explora dinamicamente em fluxos de trabalho de implementação adequados) é o único elemento que é necessário ter conhecimento de quando se aplica o recurso para o processo de implementação da máquina virtual.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

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


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

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

 


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

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

Elija su nombre para mostrar



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

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

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

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

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Linux, Cloud computing
ArticleID=800568
ArticleTitle=Reparação dos Erros de Clonagem da Máquina Virtual em Nuvem
publish-date=03082012