Introdução

Conceitos principais

Neste artigo, definimos a configuração de várias redes com o Tivoli Service Automation Manager 7.2.1.1 em um ambiente CloudBurst 2.1 no System x e isolaremos cada uma delas para impedir que os pacotes de uma rede cheguem até outras redes. Antes de começar, vamos abordar alguns conceitos usados neste artigo.

• Com o Tivoli Service Automation Manager 7.2.1, é possível implementar instrumentos virtuais usando uma configuração de rede personalizável, que estamos determinando como um conjunto de definições de sub-rede especificadas como um IP de partida e máscara de rede.
• Cada configuração precisa conter no mínimo uma rede que será usada como uma "rede de gerenciamento". Essa rede é usada pelo Tivoli Service Automation Manager para trabalhar com os instrumentos virtuais fornecidos.
• Uma configuração de rede tem uma associação um-para-um com um conjunto virtual (VRPool). Um conjunto virtual representa todos os recursos ou parte dos recursos gerenciados por um hypervisor. Portanto, um hypervisor pode ser modelado como um ou mais conjuntos virtuais, mas esse é associado a apenas um hypervisor.

A Figura 1 descreve as relações entre os conjuntos virtuais, as configurações de rede, os VLANs e os recursos de hypervisor usando o Tivoli Service Automation Manager.

Configurações de várias redes

Com base na configuração definida pelo usuário, é possível criar projetos incluindo servidores de qualquer VRPool definido. Portanto, se forem definidos um conjunto para desenvolvimento, um conjunto para testes e um conjunto para produção, você terá um projeto que inclui servidores virtuais pertencentes a ambientes diferentes para desenvolver e testar um recurso e, por fim, colocá-lo em produção.

Dessa forma, é possível usar configurações de rede diferentes para cada conjunto. Para ter vários ambientes usando redes diferentes, é preciso no mínimo uma rede de gerenciamento para cada um deles e o servidor no qual o Tivoli Service Automation Manager está instalado precisa ser capaz de acessar todas as redes de gerenciamento definidas.

Este artigo explica como definir várias configurações de rede com o Tivoli Service Automation Manager 7.2.1.1 em um ambiente do CloudBurst 2.1 no System x e demonstra como isolar cada uma delas para impedir que os pacotes de uma rede cheguem até as outras redes.

Nossa solução está voltada para o IBM CloudBurst 2.1 no System x e depende do VMware 4.1 como hypervisor com a pilha de software Tivoli instalada no SuSE SLES 10 Service Pack 3. No entanto, essa solução pode ser facilmente adaptada a um ambiente que depende do IBM Service Delivery Manager 7.2.1. Com um conhecimento prático da arquitetura Power VM, é possível aplicar os conceitos mostrados aqui ao CloudBurst 2.1 no Power VM.

Suporte VLAN fornecido pelo sistema operacional convidado

Antes de falarmos sobre os detalhes técnicos, há varias abordagens que podem ser utilizadas para aproveitar uma configuração com várias redes:

• Criação de um VLAN para rede de gerenciamento. No entanto, isso pode acabar se tornando uma solução não escalável, pois o hypervisor poder possuir limitações referentes ao número de vNICs diferentes que podem ser definidos para cada sistema virtual. Por exemplo, o VMware 4.1 limita para 10 o número de vNICs diferentes em um sistema virtual.
• Uso de um único vNIC sem um ID de VLAN. Embora corrija a limitação anterior, isso inclui uma quebra de segurança, caso deseje criar redes isoladas. É necessário ter IDs de VLAN diferentes para obter o isolamento de rede.
• Uso do suporte de VLAN fornecido pelo sistema operacional convidado.

A abordagem usada no CloudBurst 2.1 para System x tem como objetivo aproveitar o suporte de VLAN fornecido pelo sistema operacional convidado (ou seja, o SuSe SLES 10 Service Pack 3). A seguir, é possível visualizar o processo para implementação dessa abordagem.

Voltar para parte superior

Configurar a pilha de software do CloudBurst 2.1 para suportar várias redes

Os endereços disponíveis para as redes de gerenciamento estão no intervalo 10.100.*.* a 10.129.*.* A rede 10.100 .*.* é definida por padrão, portanto, mostraremos como adicionar 10.101.*.*

Do ponto de vista da rede do cliente, é possível adicionar de forma análoga 30 redes (para simplificar, as nomeamos como 10.130.*.* a 10.159.*.*). Mas, é possível usar o conjunto de endereços IP que seja adequado ao seu ambiente.

O fato de diferentes configurações de rede serem associadas a diferentes conjuntos virtuais e cada modelo de conjunto virtual fazer parte dos recursos de um hypervisor significa que em um ambiente CloudBurst é necessário criar um cluster para cada conjunto virtual no centro virtual do VMware virtual.

Etapa 1. Criar um cluster

No CloudBurst, por padrão, todos os blades dedicados ao fornecimento são agrupados em um cluster chamado CloudBurst-cluster. Nesta etapa, crie um segundo cluster chamado Second-cluster. Para simplificar, deixe metade dos blades no CloudBurst-cluster e associe a outra metade ao Second-cluster.

1. Faça o login no centro virtual do VMware e acesse a visualização Home > Inventory Hosts and Clusters . Clique com o botão direito do mouse em CloudDC datacenter e selecione New Cluster. Na janela Cluster Features, digite Second-cluster e selecione VMware HA e VMware DRS. Nas janelas VMware DRS e Power Management, aceite os valores padrão.
2. Na janela VMware HA, marque Enable Host Monitoring e selecione Enable: Do not power on VMs that violate availability constraints. Na janela Virtual Machine Options selecione Leave powered on as Host Isolation Response. Em VM Monitoring, deixe os valores padrão. Na janela VMware EVC selecione Enable EVC for Intel Host. Na janela Virtual Machine Swapfile location, aceite os valores padrão.
3. Na janela Ready to Complete, clique em Finish. O Second-cluster deve ser exibido em CloudDC. Agora, é possível arrastar metade dos blades do CloudBurst-cluster para o Second-cluster.

Etapa 2: Criar um VLAN adicional usando identificação de VLAN

Para superar a limitação do VMware de no máximo 10 NICs por imagem virtual, utilize o suporte de VLAN fornecido pelo SuSe SLES 10 Service Pack 3.

A tecnologia utilizada é a identificação de VLAN. Para aproveitar a identificação de VLAN, o sistema operacional adiciona uma tag VLAN ID a cada pacote TCP/IP. Para que isso funcione, a imagem virtual precisa ser capaz de se conectar a qualquer grupo de portas nos servidores VMWare ESXi com um VLAN ID diferente de zero. O VMWare define um grupo de portas especial com ID 4095. Ao usar esse número (e se possuir a configuração de comutador apropriada), um pacote TCP/IP somente será permitido nesse grupo de portas se tiver uma tag VLAN ID, independentemente de seu valor. Caso esteja trabalhando com o CloudBurst 2.1 no System x, essa configuração estará pronta.

Usando essa técnica, apenas um grupo de portas será suficiente para todas as imagens virtuais de gerenciamento (icb-tivsam, icb-itm, icb-nfs, icb-tuam). Por outro lado, um grupo de portas específico é usado para as imagens virtuais fornecidas.

Após a conclusão, você pode criar dois conjuntos de imagens virtuais separados. O primeiro conjunto, (já configurado por padrão) usa 10.100.*.* como rede de gerenciamento e 10.130.*.* como rede de cliente. O segundo conjunto usa 10.101.*.* como rede de gerenciamento e 10.131.*.* como rede de cliente.

Primeiramente, é necessário definir um vNIC na 10.101.*.* para icb-tivsam, icb-nfs e icb-itm.

É fácil entender a necessidade de vNIC no icb-tivsam: 10.101.*.*, ele é a rede de gerenciamento usada pelo Tivoli Service Automation Manager. Já a necessidade de um vNIC adicional no icb-nfs e icb-itm não é tão óbvia.

O vNIC adicional é necessário no icb-nfs, pois ao instalar o agente do IBM Tivoli Monitoring na imagem virtual fornecida, essa imagem monta remotamente o sistema de arquivos /repositório para acessar os binários de instalação do agente do IBM Tivoli Monitoring.

No icb-itm, o vNIC adicional é usado pelas imagens virtuais fornecidas para enviar dados de monitoramento ao servidor do IBM Tivoli Monitoring, se a imagem virtual tiver sido equipada com um agente do IBM Tivoli Monitoring.

Não há a necessidade de NICs adicionais no icb-tuam, pois o icb-tuam interage somente com o icb-tivsam para trocar dados de uso e de contabilidade. O Icb-tuam não interage diretamente com as VMs fornecidas.

Para criar um VLAN com esse tipo de identificação, os comandos pré-definidos estão presentes no icb-tivsam, icb-nfs e icb-itm. Isso evita que o usuário tenha que lidar diretamente com os comandos do sistema operacional.

Por exemplo, se você fizer login no icb-tivsam, poderá encontrar o comando:

/opt/IBM/CB/bin/addVLAN.sh 

A sintaxe é:

/opt/IBM/CB/bin/addVLAN.sh <VLAN ID> <IP address> <netmask>

Execute o seguinte comando:

/opt/IBM/CB/bin/addVLAN.sh 101 10.101.0.1 255.255.0.0

Após a conclusão do comando, é possível verificar se a placa de rede foi configurada de maneira adequada usando o comando ifconfig eth0.101 .

Repita o mesmo processo para icb-itm e icb-nfs usando 10.101.0.7 e 10.101.0.5, respectivamente, como endereços IP.

Se estiver utilizando a alta disponibilidade do nó duplo, repita o processo usando o endereço IP 10.101.0.6 para icb-nfs-ha e o endereço IP 10.101.0.3 para icb-tivsam-ha.

Observação: Depois de adicionar o vNIC ao icb-itm, é necessário reiniciar o IBM Tivoli Monitoring Server (TEMS), caso contrário ele não poderá obedecer o endereço IP recém-criado e as imagens virtuais fornecidas não poderão enviar dados para ele. Para fazer isso, faça login no icb-itm como virtuser e inicie /opt/IBM/ITM/bin/itmcmd server stop TEMS. Após a conclusão dessa operação, emita /opt/IBM/ITM/bin/itmcmd server start TEMS.

Etapa 3: Adicionar os endereços IP do serviço

É importante definir os endereços IP do serviço para o VLAN criado na etapa anterior, especialmente se estiver utilizando a alta disponibilidade do nó duplo. O principal motivo é que você deseja que o Tivoli System Automation para multiplataformas não permita que você saiba qual imagem virtual (icb-tivsam ou icb-tivsam-ha, icb-nfs ou icb-nfs-ha) está fornecendo o serviço. Essa tarefa precisa ser realizada no icb-tivsam e no cb-nfs.

Para fazer isso, interrompa os serviços gerenciados pelo Tivoli System Automation no icb-nfs e no cb-tivsam.

1. Faça login como root no icb-nfs ou no icb-tivsam e inicie rgreq -o stop top-rg ou rgreq -o stop tsam-rg no icb-tivsam.
2. Verifique se os serviços estão off-line observando o resultado do comando lssam -V. Pode demorar alguns minutos para que todos os serviços estejam off-line.
3. Use o comando /opt/IBM/CB/bin para criar o endereço IP do serviço. A sintaxe é:

   /opt/IBM/CB/bin/tsa_add_service_ip.sh <name of the NIC> <IP address> <netmask>

   
   
4. Nesse exemplo, para icb-nfs use:

   /opt/IBM/CB/bin/tsa_add_service_ip.sh eth0.101 10.101.0.4 255.255.0.0

   
   Para icb-tivsam use:

   /opt/IBM/CB/bin/tsa_add_service_ip.sh eth0.101 10.101.0.2 255.255.0.0

   
   
5. Após a criação do endereço IP do serviço, reinicie os serviços gerenciados pelo Tivoli System Automation usando o comando rgreq -o cancel top-rg no icb-nfs e rgreq -o cancel tsam-rg no icb-tivsam.
6. Verifique o resultado de lssam -V para ter certeza de que todos os recursos estão on-line. Isso pode demorar alguns minutos, portanto continue verificando.

Observação: o procedimento é exatamente o mesmo se você estiver utilizando a alta disponibilidade de nó duplo ou não. Não é necessário executar essa etapa no icb-tivsam-ha e no icb-nfs-ha, o Tivoli System Automation para multiplataformas entende se você estiver em configuração de nó duplo e propaga adequadamente as informações necessárias para as imagens virtuais de backup.

Etapa 4: Criar um novo conjunto de recursos e um novo conjunto de nuvem

Para utilizar a capacidade do Tivoli Service Automation Manager de criar um conjunto de imagens virtuais usando redes e recursos diferentes, crie conjuntos de recurso diferentes.

Para simplificar o Tivoli Service Automation Manager, são fornecidos, na imagem do icb-tivsam, modelos que podem ser facilmente adaptados e importados.

O primeiro arquivo a ser observado é /opt/IBM/CB/TSAMDefinitions/New_Pool_DCM_objects.xml. Ele contém o conjunto mínimo de entidades que precisam ser definidas ao criar um novo conjunto de recursos: a rede de gerenciamento, a rede do cliente, o repositório de arquivos da nuvem (para UNIX® e Windows®) e a pilha de software.

Personalizar

A personalização mínima necessária é:

• Alterar todas as ocorrências da variável $MGMT_VLANID com o VLAN ID da nova rede de gerenciamento (em nosso cenário é 101).
• Alterar todas as ocorrências da variável $CUST_VLANID com o VLAN ID de sua nova rede de cliente (para esse exemplo, usaremos 10.131).

Também é possível personalizar a rede do cliente com seus dados de rede específicos (como endereços IP, máscara de rede e DNS). Lembre-se de modificar a variável SANStgPoolName para armazenar a lista apropriada de discos de VM que devem ser usados.

É útil criar uma cópia de backup do arquivo New_Pool_DCM_objects.xml, caso deseje resolver o problema ou repetir o procedimento adicionando mais conjuntos de recurso.

Para este artigo, nomeamos a versão personalizada do New_Pool_DCM_objects.xml como 101_Pool_DCM_objects.xml.

Importar

Após personalizar o arquivo, importe-o no Tivoli Provisioning Manager:

Como usuário tioadmin, execute o comando:

/opt/IBM/tivoli/tpm/tools/xmlimport.sh
file:///opt/IBM/CB/TSAMDefinitions/101_Pool_DCM_objects.xml

1. Crie um novo conjunto de nuvens. Aqui, é necessário criar um novo conjunto de nuvens que use o conjunto de recursos recém-criado. É possível usar um arquivo como este:

   1.name=VMware System x 101 1.tpmHPType=VMware 1.order=1 1.tpmPool=Esx Cloud Pool 101 1.hypervisorHostName=vsphere 1.fileRepositoryName=VMwareFileRepository101 1.maxVCPU=4 1.maxCPUUnits=40 1.maxMemMB=8192

   
   
2. Altere o arquivo para seu ambiente. Lembre-se de alterar o arquivo acima de acordo com seu ambiente. Dê um nome significativo ao arquivo, por exemplo, 101_vrpool.properties, para que você se lembre de que ele foi criado para o 101 VLAN.
3. Importe o arquivo. Após a criação do arquivo, importe-o usando a interface de usuário administrativo TSAM:
   1. Faça login em https://icb-nfs/maximo como maxadmin.
   2. Acesse > Service Automation > Cloud Pool Administration.
   3. Clique em Import Virtual Resource Pools.
   4. Vá até o diretório em que você colocou o arquivo 101_vrpool.properties e o importe.
4. Execute o Virtual Center Discovery novamente. Clique no conjunto de nuvens recém-importado. Teoricamente, não é necessário executar novamente o Virtual Center Discovery, mas isso deve ser executado aqui, porque você criou o Second-cluster no VMware após a execução do Virtual Center Discovery. A velocidade de conclusão do Virtual Center Discovery depende do número de blades.
5. Quando o Virtual Center Discovery tiver sido concluído com êxito, configure o Image Repository Host.
   1. Defina-o como cn2.private.cloud.com.
   2. Especifique como File Repository Name VMwareFileRepository101 (ou seja, aquele usado no /opt/IBM/CB/TSAMDefinitions/101_Pool_DCM_objects.xml.)
   3. Especifique no Cluster Name Segundo-cluster. O cluster especificado não deve estar associado a outro conjunto de recursos.
   4. Especifique como Saved Image Repository clone_backup_disk.
   5. Clique no botão Validate and Enable Cloud Pool para fazer com que o novo cluster fique operacional.
6. Adicione o segundo cluster. O segundo cluster precisa ser adicionado manualmente ao conjunto de recursos recém-criado. Na interface de usuário administrativo do Tivoli Service Automation Manager:
   1. Clique em Acesse > Administration > Provisioning > Resource Pools.
   2. Selecione ESX Cloud Pool 101 (criado durante a importação do 101_Pool_DCM_objects.xml).
   3. Clique em Select Action e selecione Add Computer.
   4. Selecione Second-cluster clicando na caixa de seleção próxima a ele.

Agora, é possível iniciar o fornecimento sem o agente do ITM. Se não estiver interessado nesse recurso, ignore a etapa 5.

Etapa 5: Configurar o Tivoli Service Automation Manager para implementação do agente do IBM Tivoli Monitoring

Para o conjunto de nuvens definido por padrão (VMware System x), é possível instalar o agente do IBM Tivoli Monitoring no momento do fornecimento ao marcar a caixa de seleção Monitoring Agent to be Installed no painel Create Project.

Essa técnica não funcionará para o segundo conjunto de nuvens (VMware System x 101). Isso acontece, porque a definição de software para o agente do IBM Tivoli Monitoring associada a essa caixa de seleção está configurada para usar a rede 10.100.*.* (consulte a configuração do CloudFileRepository e do WindowsCloudFileRepository).

Se, ao criar um projeto, for selecionado VMware System x 101 e a caixa de seleção for marcada para instalar o Monitoring Agent, o fornecimento será iniciado, mas falhará, pois a imagem virtual fornecida tem eth0 configurado em 10.101.*.* e ele tenta montar o repositório usando um endereço IP 10.100.*.*. Como você está tentando isolar a rede entre os dois conjuntos (ou seja, a máscara de rede usada é 255.255.0.0), a operação de montagem não é bem-sucedida, causando a falha de todo o fluxo de trabalho de provisionamento.

Para instalar o agente do IBM Tivoli Monitoring no momento do fornecimento para o segundo conjunto de nuvens, é necessário defini-lo como um software adicional. Não use a caixa de seleção Monitoring Agent to be Installed. Em vez disso, use a lista Available Software no painel Create Project.

Para usar essa funcionalidade, crie um módulo de software que representa essa nova configuração para o agente do IBM Tivoli Monitoring.

Há um modelo disponível no icb-tivsam em /opt/IBM/SC/script. Copie esse modelo em /opt/IBM/CB/TSAMDefinitions/101_itm.xml e o modifique:

1. Altere todas as ocorrências do agente do IBM Tivoli Monitoring por algo que facilite sua identificação e esteja relacionado à sua rede 101, por exemplo, IBM Tivoli Monitoring Agent 101.
2. Nomeie o repositório do arquivo de nuvem CloudFileRepository 101, especifique a versão (6.2.2) e o caminho apropriados no repositório de arquivos (itmAgent622). No host do parâmetro, especifique o endereço IP adicional do TEMS como valor (em nosso exemplo 10.101.0.7).

   O arquivo terá uma aparência semelhante àquele neste exemplo.

3. Importe o arquivo 101_itm.xml. Como usuário tioadmin, inicie:

   /opt/IBM/tivoli/tm/tools/xmlimport.sh file:///opt/IBM/CB/TSAMDefinition/101_itm.xml

   
   O modelo de instalação é adequado para a implementação do agente do IBM Tivoli Monitoring no Linux. Para outras plataformas, consulte o Centro de informações do TSAM .
4. Por fim, anexe o agente do IBM Tivoli Monitoring à pilha de software:
   1. Faça login no toTivoli Service Automation User Interface.
   2. Clique em Acesse > IT infrastructure > Software Catalog > Software Stacks.
   3. Selecione EsxPoolStack101 e selecione Add Stack Entry na lista suspensa Select Action.
   4. No campo de edição Software Definition, digite IBM Tivoli Monitoring Agent 101.
   5. Clique em Submit.
   6. Lembre-se de salvar as alterações.

Etapa 6: Verificação

A melhor maneira de verificar se a configuração está correta é criar um projeto para o novo conjunto de recursos.

Considere que cada conjunto de recursos tem seu próprio conjunto de modelos de imagens registradas. Se um modelo de imagem já tiver sido registrado para um conjunto de recursos, não será possível registrá-lo para outro conjunto de recursos. Se realmente deseja usar esse mesmo modelo, será necessário cloná-lo, executar a descoberta do Virtual Center e, então, será possível registrá-lo para seu novo conjunto de recursos.

Para simplificar, vamos supor que você já possui o modelo de imagem no VMware e ele não está associado a qualquer outro conjunto de recursos (neste exemplo, ele não foi registrado para o VMware System x). O modelo ao hypervisor foi adicionado após a execução do Image Template Discovery e é preciso executá-lo novamente:

1. Na interface de usuário administrativa do Tivoli Service Automation Manager, clique em Acesse > Service Automation > Cloud Pool Administration.
2. Filtre para encontrar o VMware System x 101 e clique nessa entrada.
3. Inicie a descoberta do modelo de imagem clicando no botão Image Discovery.

Após a conclusão bem-sucedida, acesse https://icb-nfs/SimpleSRM e registre o modelo recém-descoberto. Lembre-se de selecionar VMware System x 101 como conjunto de recursos.

Após registrar o modelo, é possível criar um projeto. Lembre-se de selecionar VMware System x 101 como conjunto de recursos e não marque a caixa de seleção Monitoring Agent to be Installed. Em vez disso, selecione ITM Monitoring Agent 101 em Available Software.

Após a conclusão bem-sucedida da solicitação de serviço, é possível fazer o login na VM fornecida e verificar a configuração de rede. Também é possível ver que um sistema adicional é exibido na interface de usuário do IBM Tivoli Monitoring (http://icb-itm:1920).

Observação: se você selecionar o servidor fornecido e procurar por informações de monitoramento enquanto estiver conectado em https://icb-nfs/SimpleSRM, elas não estarão disponíveis. Elas estarão disponíveis apenas para as imagens virtuais fornecidas no VMware System x.

Agora, a última verificação que deve ser feita é se a imagem virtual fornecida não consegue acessar nenhuma outra imagem que pertença ao conjunto VMware System x.

Voltar para parte superior

Conclusão

Após concluir este artigo, você deverá estar familiarizado com os componentes internos do CloudBurst 2.1 e com as técnicas e modelos disponíveis para utilizar a funcionalidade de suporte de várias redes.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• Saiba como desenvolver uma nuvem particular com CloudBurst e TSAM.
  
  
• Mais recursos do developerWorks que complementam este artigo se encontram em Tivoli no developerWorks e WebSphere no developerWorks.
  
  
• Encontre mais informações sobre o Tivoli Service Automation Manager e o dispositivo WebSphere CloudBurst .
  
  
• Próximas etapas: Descubra como acessar o IBM SmartCloud Enterprise.
  
  

Obter produtos e tecnologias

• Consulte as imagens do produto available on the IBM Smart Business Development and Test on the IBM Cloud.
  
  

Discutir

• Participe de um grupo de computação em nuvem no developerWorks.
  
  
• Leia todos os ótimos 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 os autores

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Configurar a pilha de software do CloudBurst 2.1 para suportar várias redes
• Conclusão
• Download
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais