Automatize a descoberta e a autoconectividade de máquinas virtuais

Use plug-and-play para descobrir e conectar máquinas virtuais

Em um datacenter virtual, a implementação e a desativação de dispositivos complexos requer que várias etapas de configuração sejam executadas. Requisitos de reconfiguração incluem estabelecer e remover comunicação entre diferentes componentes do mesmo produto em execução em diferentes máquinas virtuais (VMs), bem como em diferentes produtos em execução em diferentes VMs. Tradicionalmente, este processo era inoportunamente manual ou um tanto inflexível, devido ao chamado de scripts predefinidos com valores estáticos. Neste artigo, os autores sugerem StereoCable, suporte a plug-and-play automatizado para dispositivos virtuais complexos em um datacenter virtual, para resolver este problema. Desta maneira, VMs podem descobrir e conectar automaticamente umas às outras, baseado em políticas de conexão predefinidas.

Giuseppe Ciano, Chief Designer of Tivoli Cloud Solutions, IBM

Giuseppe Ciano passou a fazer parte da IBM em 1997 como engenheiro de software no SWG Tivoli Lab de Roma. Ele trabalha há 11 anos como desenvolvedor e designer de diferentes produtos no portfólio Tivoli. É atualmente designer chefe de Soluções em Nuvem Tivoli, como o produto IBM Service Delivery Manager. Também é o designer do StereoCable.



Maurizio Simeoni, Staff Engineer, Tivoli, IBM

Maurizio Simeoni formou-se em engenharia de telecomunicações na Universidade de Roma "La Sapienza". É engenheiro da equipe IBM Tivoli em Roma. Atualmente, ele trabalha no IBM Service Delivery Manager. Tem mais de 10 anos de experiência no desenvolvimento e suporte a aplicativos de software. Contribuiu para o design e desenvolvimento do StereoCable.



Alessio D'Amico, IT Architect for IBM Tivoli Services, IBM

Alessio D'Amico passou a fazer parte da IBM em 1999 como engenheiro de software do SWG Lab em Roma. Durante sua carreira, ele ganhou experiência em todo o ciclo de vida do projeto, de gerenciamento de projeto, análise de negócios, design e construção até implementação. Atualmente, é responsável por projetar e implementar as soluções de gerenciamento de serviço e computação em nuvem baseadas no portfólio de produtos Tivoli. Suas principais áreas de conhecimento incluem gerenciamento de sistemas, fornecimento, gerenciamento de serviço, virtualização e computação em nuvem.



Dr. Antonio Perrone, Senior Software Engineer, IBM

Photo of  Antonio PerroneAntonio Perrone formou-se com mérito em ciências da informação na Universidade de Bari, na Itália, em 1989. Ele passou a fazer parte da IBM em 1990, e ocupou várias posições em desenvolvimento e suporte. Ele está na divisão IBM Tivoli desde 1996, na qual é atualmente arquiteto da área de gerenciamento de desempenho de rede. Seus interesses incluem gerenciamento de sistemas, desempenho e disponibilidade, representação do conhecimento, integração de dados, transação e modelagem de processo e desenvolvimento de software.



06/Dez/2010

Dispositivos virtuais são soluções de software pré-construídas compostas de uma ou mais máquinas virtuais que são empacotadas, atualizadas, mantidas e gerenciadas como uma unidade. Ao contrário de um dispositivo de hardware tradicional, estes dispositivos de software permitem que os clientes adquiram, implementem e gerenciem facilmente pilhas de soluções pré-integradas. Isso acelera o tempo de retorno sobre o investimento e simplifica o desenvolvimento, distribuição e gerenciamento de software.

Dispositivos virtuais estão mudando o paradigma de distribuição de software, pois permitem que construtores de aplicativos otimizem a pilha de software para aplicativos e entreguem ao usuário final um serviço de software pronto para ser usado.

Enquanto dispositivos virtuais atuais contém apenas uma máquina virtual (VM), aplicativos corporativos modernos modelam arquiteturas orientadas a serviço (SOA) com várias camadas, nas quais cada camada contém uma ou mais máquinas. O modelo de VM única não é suficiente para este tipo de aplicativo. Distribuir serviços multicamada na forma de dispositivo de software requer dispositivo virtual composto de mais VMs que possam cooperar.

Por exemplo, imagine um aplicativo da Web típico composto de três camadas. Uma camada da Web que implementa a lógica de apresentação, uma camada do servidor de aplicativo que implementa a lógica de negócios, e uma camada de banco de dados de backend. Uma implementação simples dividiria isso em três máquinas virtuais, uma para cada camada. Dessa maneira, o aplicativo pode escalar de uma fração de um host físico para três hosts físicos.

Em um datacenter virtual, a implementação e a desativação de dispositivos complexos requer que várias etapas de configuração sejam executadas para que o dispositivo esteja pronto para uso.

  1. Reconfiguração necessária para designar parâmetros específicos do OS, como informações de rede: IP, nome de host, senhas etc.
  2. Reconfiguração para estabelecer/remover a comunicação entre:
    • Componentes diferentes do mesmo produto sendo executados em máquinas virtuais diferentes.
    • Produtos diferentes sendo executados em máquinas virtuais diferentes.

O que é um mecanismo de ativação?

Um mecanismo de ativação é software integrado no dispositivo virtual que é ativado durante o primeiro boot do dispositivo, após a implementação.

Para exemplos que usam esse conceito de mecanismo de ativação de máquina virtual em várias tecnologias, consulte:

O primeiro problema descrito na lista é tratado com a tecnologia de mecanismo de ativação, software integrado no dispositivo virtual que é ativado durante o primeiro boot do dispositivo, após a implementação.O mecanismo de ativação e plug-ins de customização podem ser escritos e fornecidos para configurar o dispositivo virtual no sistema de destino.

O problema descrito no segundo item da lista não foi tratado. Hoje, reconfigurações são realizadas manualmente ou chamando scripts predefinidos com valores estáticos na entrada. Nós propomos suporte a plug-and-play de dispositivos virtuais complexos em um datacenter virtual para resolver essa questão. Dessa maneira, as máquinas virtuais poderão descobrir e conectar automaticamente umas às outras com base em conexões predefinidas, porém mais flexíveis; StereoCable é complementar com o Mecanismo de Ativação e pode coexistir com ele facilmente. Aliás, o AE pode ser explorado para configurar automaticamente o StereoCable no momento do boot.

Princípios de design do StereoCable

Antes de descrever a arquitetura e fluxo do sistema, vamos apresentar um conceito essencial neste o artigo, o de StereoCable.

Definindo StereoCable

StereoCable é um artefato que descreve como estabelecer cooperação baseada em funções entre duas entidades sendo executadas em máquinas virtuais diferentes, por exemplo:

(PRODA_UI,PRODA_SERVER) ... (PRODA_SERVER,PRODB_SERVER) ... (PRODA_UI,PRODB_SERVER)

Um artefato StereoCable é composto por duas partes (as quais chamaremos de funções):

  • A função de soquete. O soquete descreve as informações que precisam ser fornecidas por uma entidade para estabelecer conexão com outra entidade. Com é designada uma função de soquete a uma VM em um ambiente particular, ela publica as informações exigidas pela definição de soquete.
  • A função de plugue. O plugue descreve as ações que precisam ser executadas por uma entidade em uma VM para estabelecer cooperação com outra entidade sendo executada em uma máquina virtual diferente. Quando é designada uma função de plugue a uma VM em um ambiente particular, ela:
    1. Localiza uma VM com a função de soquete correspondente no mesmo ambiente
    2. Recupera as informações de soquete publicadas
    3. Executa a ação descrita na definição do plugue.

Para representar um artefato StereoCable, foi definido um esquema XML. A Listagem 1 é um exemplo de informações de StereoCable:

Listagem 1. Informações de StereoCable em XML
 <StereoCable>
                <StereoCableID>StereoCableID1</StereoCableID>
                <Description>PRODA UI Automatic
                Reconfiguration</Description>
                <PlugSection> <Description>PRODA UI
                Server</Description>
                <PlugID>PRODA_UI</PlugID>
                <ConfigurationActions>
                <ConfigurationAction>
                <Description>Description</Description>
                <ID>ID</ID>
                <Trigger>Deployment</Trigger>
                <Action>
                <ActionType>script</ActionType>
                <ActionDetail>
                <ConfigurationParameters>
                <ConfigurationParamter>
                <ConfigurationName>host</ConfigurationName>
                </ConfigurationParamter>
                <ConfigurationParamter>
                <ConfigurationName>port</ConfigurationName>
                </ConfigurationParamter>
                <ConfigurationParamter>
                <ConfigurationName>name</ConfigurationName>
                </ConfigurationParamter>
                <ConfigurationParamter>
                <ConfigurationName>user</ConfigurationName>
                </ConfigurationParamter>
                </ConfigurationParameters>
                <Operation>/pino/driver4/scripts/PRODAUI.sh</Operation>
                </ActionDetail> </Action>
                </ConfigurationAction>
                </ConfigurationActions>
                </PlugSection> <SocketSection>
                <Description>PRODA
                Master</Description>
                <SocketID>PRODA_SERVER</SocketID>
                <PublishedParameters>
                <ConfigurationParameter>
                <ConfigurationName>host</ConfigurationName>
                <ConfigurationValue>nc125050.romelab.it.ibm.com</ConfigurationValue>
                </ConfigurationParameter>
                <ConfigurationParameter>
                <ConfigurationName>port</ConfigurationName>
                <ConfigurationValue>31117</ConfigurationValue>
                </ConfigurationParameter>
                <ConfigurationParameter>
                <ConfigurationName>name</ConfigurationName>
                <ConfigurationValue>PRODA-istributed</ConfigurationValue>
                </ConfigurationParameter>
                <ConfigurationParameter>
                <ConfigurationName>user</ConfigurationName>
                <ConfigurationValue>PRODA85mdm</ConfigurationValue>
                </ConfigurationParameter>
                </PublishedParameters>
                </SocketSection> </StereoCable>

Componentes do StereoCable

A Figura 1 ilustra os componentes do sistema StereoCable.

Figura 1. Componentes do StereoCable
Componentes do StereoCable

O sistema StereoCable é composto de:

  • Mecanismo StereoCable: Uma entidade de software carregada na VM para processar funções designadas de processo de acordo com as informações de StereoCable expressas em formato XML. Esse mecanismo também é capaz de processar eventos de VM: por exemplo, a implementação e uma nova VM ou a remoção de uma VM existente, para tomar as medidas de configuração apropriadas.
  • Registro de StereoCable: Um repositório que mantém registro dos soquetes disponíveis e os fornece aos plugues sob solicitação (baseado em restrições predefinidas). Esse é o elemento mais obrigatório, pois as VMs das implementações de virtualização de alguns fornecedores podem publicar e compartilhar esse tipo de informações diretamente.
  • Interface com o usuário/Interface de linha de comando do StereoCable: A entidade de software usada para trabalhar com VMs e informações de plugue e soquete, e que exibe suas inter-relações. A UI pode acessar as informações que conectam com o Registro do StereoCable e diretamente com as VMs.

(A implementação do StereoCable que fornecemos neste artigo inclui suporte para VMware; especificamente VMware ESX 3.5 e vSphere 4. Os mecanismos de ativação conectam usando a API VMware VI SDK e o Registro do StereoCable é o VMware VirtualCenter. O sistema operacional guest suportado é SLES10.)

Em seguida, vamos discutir como StereoCable processa ações.


Processamento de StereoCable

Vamos examinar os dois tipos de processos encontrados com StereoCable — o processo de inicialização do mecanismo e o processamento dinâmico do StereoCable (a vantagem de automação que um artefato StereoCable tem em relação ao processo tradicional de descoberta e reconfiguração de conexão de VM). Para esta seção, pensamos que seria mais claro e conciso oferecer uma série de etapas e um fluxograma para ilustrar o processo.

As etapas principais para inicialização e processamento dinâmico do StereoCable

O processo de Inicialização do Mecanismo segue estas etapas:

  1. O Mecanismo do StereoCable conecta-se ao registro para recuperar as funções e os StereoCables. Esta etapa pode incluir autodescoberta do Registro se o protocolo usado pelo Mecanismo permitir, por exemplo, SLP (service discovery protocol que permite que computadores e outros dispositivos localizem serviços em uma LAN sem configuração anterior).
  2. Recuperar as funções da VM e os ambientes aos quais a VM pertence.
  3. Recuperar os StereoCables associados à VM.
  4. Mecanismo do StereoCable processa os StereoCables contidos no arquivo StereoCables.xml.
  5. Desativar a funcionalidade StereoCable geral para aquela VM.
  6. Para todas as funções de soquete em StereoCables.xml, se a função for igual a uma das funções da VM:
    1. Verificar se a dependência está OK. Se não estiver, colocar o soquete em uma fila em operação.
    2. Recuperar os atributos do soquete, como descritos no arquivo XML.
    3. Publicar os atributos do soquete.
    4. Publicar a informação de que o soquete está ativo agora.
    5. Enviar um evento para o soquete publicado.
    6. Colocar o soquete na tabela ativa de StereoCable; também especificar as informações às quais o soquete é conectado.
  7. Ativar a funcionalidade geral do StereoCable para aquela VM.
  8. Para todas as funções de plugue em StereoCables.xml; se a função for igual a uma das funções da VM:
    1. Verificar se a dependência está OK. Se não estiver, colocar o plugue em uma fila em operação.
    2. Recuperar as informações relacionadas ao soquete (função...) descritas no arquivo XML.
    3. Descobrir as VMs que fornecem o soquete apropriado e que pertencem ao mesmo ambiente.
    4. Para todas as VMs descobertas:
      1. Decidir, baseado nas regras definidas no arquivo XML, qual VM será selecionada se mais de uma tiver sido descoberta.
      2. Recuperar os atributos do soquete publicado se o status do soquete estiver ativo.
      3. Chamar as ações de configuração; passar as informações recuperadas como um parâmetro.
      4. Publicar as informações; o plugue agora está ativo, e também descreve as informações sobre o soquete ao qual está conectado.
      5. Enviar um evento para o plugue publicado.
      6. Colocar o plugue na tabela ativa de StereoCable; especificando a informação sobre o soquete ao qual está conectado.
    5. Se não houver VM disponível, ou se a VM estiver disponível, mas o soquete não estiver ativo, colocar o StereoCable na fila em funcionamento para processamento, especificando as funções e ambiente de teste necessários.

As seguintes etapas (elas continuam a partir das anteriores) mostram como o processamento dinâmico do StereoCable funciona.

  1. Coletar periodicamente eventos StereoCable (soquete criado, soquete removido, soquete atualizado) e eventos relacionados a VM (implementação de VM, desativação de VM) para VMs com funções específicas.
  2. Para toas as funções de plugue na fila em funcionamento:
    1. Se uma nova VM tiver sido descoberta e ela publicar um soquete ativo solicitado
      1. Recuperar os atributos do soquete publicado se o status do soquete estiver ativo.
      2. Chamar as ações e configuração, passando-os como um parâmetro, a partir das informações recebidas.
      3. Publicar a informação de que o plugue agora está ativo, descrevendo também a informação sobre o soquete ao qual está conectado.
      4. Remover o plugue da fila em funcionamento do StereoCable.
      5. Colocar o plugue na tabela ativa de StereoCable, especificando também a informação sobre o soquete ao qual está conectado.
      6. Enviar um evento para o plugue publicado.
    2. Se for removida do datacenter uma VM que publica um soquete atualmente em uso por um plugue salvo na tabela ativa de StereoCable:
      1. Chamar as ações de configuração de remoção, passando as informações relacionadas ao soquete como um parâmetro.
      2. Remover o plugue da tabela ativa do StereoCable.
      3. Colocar o plugue na fila em funcionamento do StereoCable.
      4. Publicar a informação de que o plugue agora está inativo e desconectado.
      5. Enviar um evento para o plugue não publicado.

Essas etapas são descritas neste fluxograma:

Como o StereoCable realiza a inicialização e o processamento dinâmico
Como o StereoCable realiza a inicialização e o processamento dinâmico

(Veja uma imagem maior deste fluxograma.)

A UI e CLI exibem as conexões do StereoCable entre as VMs no datacenter; também fornecem informações detalhadas sobre as conexões estabelecidas e os detalhes dos plugues e soquetes relacionados.

Sobre o processamento dinâmico do StereoCable

Uma vez estabelecidas, as conexões do StereoCable são verdadeiramente dinâmicas devido à capacidade do mecanismo que processa eventos:

  • Esse mecanismo é capaz de processar eventos (como, por exemplo, um soquete publicado ou removido) para ativar, remover ou reativar uma conexão.
  • O mecanismo também gera eventos quando um soquete é publicado, atualizado ou removido, para notificar a mudança aos usuários.

A Figura 2 mostra como o mecanismo processa eventos.

Figura 2. Processando eventos
Processando eventos

Criando uma conexão StereoCable

Nesta seção, iremos descrever as etapas para criar, implementar, estabelecer e verificar uma conexão StereoCable entre dois produtos — o primeiro agindo como um agente e o segundo, como um servidor— instalados em máquinas virtuais diferentes. Este é apenas um exemplo de uma conexão cliente/servidor, mas o StereoCable pode também ser usado para estabelecer conexões de servidor a servidor em cenários de integração complexos.

Definindo uma conexão StereoCable

Uma conexão StereoCable é composta por duas partes, o plugue e o soquete, e é especificada em formato XML. A Listagem 2 mostra a definição da conexão StereoCable:

Listagem 2. Definição da conexão StereoCable em XML
                <tns:StereoCablesxmlns:tns="http://ibm.com/stereocables"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="http://ibm.com/stereocables StereoCables.xsd
                "> <StereoCable>
                <StereoCableID>AGENT-SERVER</StereoCableID>
                <Description>Agent Server
                Connection</Description>
                <PlugSection> <Description>Agent
                Plug</Description>
                <PlugID>AGENT</PlugID>
                <ConfigurationActions>
                <ConfigurationAction>
                <Description>Agent
                configuration</Description>
                <ID>ConfigurationActionID1</ID>
                <Trigger>Deployment</Trigger>
                <Action>
                <ActionType>script</ActionType>
                <ActionDetail>
                <ConfigurationParameters>
                <ConfigurationParameter>
                <ConfigurationName>hostname</ConfigurationName>
                </ConfigurationParameter>
                <ConfigurationParameter>
                <ConfigurationName>port</ConfigurationName>
                </ConfigurationParameter>
                </ConfigurationParameters>
                <Operations>
                <Operation>agent_config.sh</Operation>
                <OS>Linux</OS>
                </Operations> </ActionDetail>
                </Action> </ConfigurationAction>
                </ConfigurationActions>
                </PlugSection> <SocketSection>
                <Description>Server
                Socket</Description>
                <SocketID>SERVER</SocketID>
                <PublishedParameters>
                <ConfigurationParameter>
                <ConfigurationName>hostname</ConfigurationName>
                <ConfigurationType>ActionBased</ConfigurationType>
                <Action>
                <ActionType>script</ActionType>
                <ActionDetail>
                <ConfigurationParameters>
                <ConfigurationParameter>
                <ConfigurationName>hostname</ConfigurationName>
                <ConfigurationValue>hostname</ConfigurationValue>
                <ConfigurationType>UserDefined</ConfigurationType>
                </ConfigurationParameter>
                </ConfigurationParameters>
                <Operations>
                <Operation>getNetworkConf.sh</Operation>
                <OS>Linux</OS>
                </Operations> <Operations>
                <Operation>getNetworkConf.sh</Operation>
                <OS>AIX</OS>
                </Operations> </ActionDetail>
                </Action> </ConfigurationParameter>
                <ConfigurationParameter>
                <ConfigurationName>port</ConfigurationName>
                <ConfigurationValue>2000</ConfigurationValue>
                </ConfigurationParameter>
                </PublishedParameters>
                </SocketSection> </StereoCable>
                </tns:StereoCables>

Neste exemplo, o plugue é o agente; e o servidor é o soquete.

O PlugSection especifica as ações executadas pelo agente/plugue para conectar-se ao servidor/soquete. No exemplo, o script chamado agent_config.sh será executado no momento da implementação, tomando como entradas o nome do host e porta publicados pelo soquete.

O SocketSection descreve as informações publicadas pelo soquete, especificamente o nome do host e a porta exigidos pelo agente/plugue. Observe que o nome do host é recuperado dinamicamente executando o script getNetworkConf.sh enquanto a porta é definida estaticamente no arquivo XML.

O arquivo StereoCables.xml que contém a definição StereoCable será implementado nas máquinas agente e servidor.

Implementando os mecanismos StereoCable

Para implementar os mecanismos, é necessário transferir por download e descompactar os arquivos do Mecanismo StereoCable nos diretórios das máquinas agente e servidor. A Figura 3 mostra isso.

Figura 3. Implementando os mecanismos
Implementando os mecanismos

Em nosso exemplo, o mecanismo está configurado para usar um tempo de execução Java™ no diretório Java (neste caso, Java 2 Technology Edition, Ambiente de Tempo de Execução de 64 bits Versão 5.0 para Linux® em uma arquitetura AMD64). Se você tiver uma arquitetura diferente, especifique o caminho no arquivo conf/environment.properties. Observe que o mecanismo foi testado com Java 2 Technology Edition, Ambiente de Tempo de Execução de 64 bits Versão 5.0 para Linux em arquitetura AMD64.

Implementando os StereoCables

Em seguida, copie o arquivo StereoCables.xml no diretório de dados (Figura 4).

Figura 4. Implementando os StereoCables
Implementando os StereoCables

Definindo as regras

Especifique as regras de cada máquina no arquivo conf/stereocables.properties.

Figura 5. Definindo as regras
Definindo as regras

Na máquina servidor, edite a chave dos soquetes de modo que seja sockets=SERVER. Na máquina agente, edite a chave dos plugues de modo que seja plugs=AGENT.

Definindo o ambiente

Nas máquinas agente e servidor, especifique o mesmo ambiente: environment=TEST.

Agora, inicie os mecanismos

Para iniciar os mecanismos, faça uma série de registro deles antes de executá-los.

Para registrar a máquina servidor:

 $./vEngine.sh -reg CTJES0003I
                Loading configuration. CTJES0004I The configuration has been
                successfully loaded. CTJES0001I Executing the operation:
                Registering the engine. CTJES0002I Operation successfully
                executed: Registering the engine.

Para executar a máquina servidor:

 $./vEngine.sh -run CTJES0003I
                Loading configuration. CTJES0004I The configuration has been
                successfully loaded. CTJES0001I Executing the operation: Run the
                engine. CTJES0001I Executing the operation: Cable processing.
                CTJES0005I Processing socket: SERVER. CTJES0011I Publishing
                information. CTJES0013I Sending event: Socket SERVER published.
                CTJES0019I Processing event's type:
                STEREOCABLES_SOCKET_PUBLISHED.SERVER. CTJES0020I Event
                processed. CTJES0006I Socket SERVER successfully processed.
                Socket processed: SERVER: Success Plug processed: CTJES0002I
                Operation successfully executed: Cable processing.

Para registrar o mecanismo agente:

 $./vEngine.sh -reg CTJES0003I
                Loading configuration. CTJES0004I The configuration has been
                successfully loaded. CTJES0001I Executing the operation:
                Registering the engine. CTJES0002I Operation successfully
                executed: Registering the engine.

Para executar o mecanismo agente:

 $$./vEngine.sh -run CTJES0003I
                Loading configuration. CTJES0004I The configuration has been
                successfully loaded. CTJES0001I Executing the operation: Run the
                engine. CTJES0001I Executing the operation: Cable processing.
                CTJES0005I Processing plug: AGENT. CTJES0011I Publishing
                information. CTJES0013I Sending event: plug AGENT published.
                CTJES0019I Processing event's type:
                STEREOCABLES_PLUG_PUBLISHED.AGENT. CTJES0020I Event processed.
                CTJES0006I Plug AGENT successfully processed. Socket processed:
                Plug processed: AGENT: Success CTJES0002I Operation successfully
                executed: Cable processing.

Verificando as conexões

É possível listar as informações publicadas e as conexões StereoCable disponíveis no ambiente executando o comando $script/Cli.sh -list.

 CTJES0003I Loading configuration.
                CTJES0004I The configuration has been successfully loaded.
                CTJES0001I Executing the operation: Discovery machines.
                CTJES0002I Operation successfully executed: Discovery machines.
                -------------------------------------------------------------------
                srv.ivm.com
                -------------------------------------------------------------------
                guestInfo.stereocables.env = TEST guestInfo.stereocables.status
                = Enabled guestInfo.stereocables.sockets = SERVER
                guestInfo.stereocables.socket.SERVER.status=Active
                guestInfo.stereocables.socket.SERVER.hostname=srv.ivm.com
                guestInfo.stereocables.socket.SERVER.port=2000
                guestInfo.stereocables.plugs =
                -------------------------------------------------------------------
                -------------------------------------------------------------------
                agt.ivm.com
                -------------------------------------------------------------------
                guestInfo.stereocables.env = TEST guestInfo.stereocables.status
                = Enabled guestInfo.stereocables.sockets =
                guestInfo.stereocables.plugs = AGENT
                guestInfo.stereocables.plug.AGENT.status=Active
                guestInfo.stereocables.plug.AGENT.connected=srv.ivm.com:SERVER
                -------------------------------------------------------------------

Como você pode ver, no ambiente TEST, a máquina agt.ivm.com está plugada em srv.ivm.com.


Conclusão

A etapa seguinte

Para avançar com descoberta, configuração e conexão de VM, sugerimos que você faça download do arquivo zip do StereoCable e leias os outros dois artigos do developerWorks mencionados neste artigo.

Nós tivemos o prazer de lhe mostrar um novo conceito — uma maneira pela qual máquinas virtuais em um datacenter virtual podem descobrir e conectar automaticamente umas às outras baseado em políticas de conexão predefinidas — e apresentamos um projeto no qual estamos trabalhando que você pode usar para ativar um sistema assim.

Lembre-se, dispositivos virtuais tem o poder de alterar a maneira como o software é distribuído, pois podem dar aos construtores de aplicativos a capacidade de otimizar sua pilha de software para aplicativos e oferecer ao usuário final um serviço de software pronto para uso. Uma etapa essencial para conseguir esse nível de serviço em um aplicativo na nuvem é automatizando, e assim aprimorando, as conexões de máquina virtual.


Download

DescriçãoNomeTamanho
Sample code for this articlestereocable.zip10KB

Recursos

Aprender

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, Tecnologia Java
ArticleID=594746
ArticleTitle=Automatize a descoberta e a autoconectividade de máquinas virtuais
publish-date=12062010