Conteúdo


Modelagem de sistemas virtuais com as ferramentas de arquitetura de implementação do IBM Rational Software Architect

Comments

É possível usar as ferramentas de arquitetura de implementação no IBM Rational Software Architect Version 7.5 para descrever uma ampla variedade de sistemas de computador em um tipo de modelo chamado topologia. As topologias podem incluir computadores individuais, servidores, aplicativos de software, hardware, componentes de redes de computador e muitos outros elementos de sistemas de computador, tudo isso em vários níveis de abstração. O autor deste artigo supõe que os leitores têm uma familiaridade básica com topologias. Para uma introdução a topologias e a ferramentas de arquitetura de implementação, consulte os links na seção Temas relacionados.

As tecnologias e estratégias específicas de virtualização também estão fora do escopo deste artigo, mas, em resumo, um sistema virtual é um sistema de computador isolado do seu host por um intermediário. Esse intermediário interpreta solicitações do sistema virtual para o host, adicionando assim uma camada de virtualização entre o sistema virtual e o host.

No contexto deste artigo, um sistema operacional que é executado diretamente no hardware é um sistema físico (ou não virtualizado). Para criar um sistema virtual, insira uma camada de virtualização para separar o sistema operacional do hardware e para gerenciar a comunicação entre esses componentes. Uma variedade de tecnologias e estratégias está disponível para esse fim, mas, em geral, criar um sistema virtual envolve um hypervisor, que é um software que apresenta a aparência do hardware a um ou mais sistemas virtuais e intercepta as tentativas de um sistema virtual de se comunicar com o hardware.

Em vez de permitir que o sistema virtual acesse o armazenamento de dados, a memória e a energia de processamento do sistema físico diretamente, o hypervisor gerencia esses recursos e fornece acesso mediado a eles. Por exemplo, o hypervisor pode limitar o acesso de um sistema virtual à memória. O hardware físico pode ter uma grande quantidade de memória, mas o hypervisor pode designar apenas 1GB dela para o uso de determinado sistema virtual. Portanto, esse sistema virtual parece estar sendo executado em um equipamento de hardware (ou seja, um servidor virtual) com apenas 1GB de memória. De modo similar, o hypervisor pode mediar acesso para um armazenamento de dados, capacidade de processamento e conexões de rede.

Desse modo, o hypervisor torna os sistemas virtuais mais flexíveis que os físicos. Por exemplo, suponhamos que haja dois sistemas físicos similares, cada um executando um aplicativo diferente, como mostra a Figura 1.

Figura 1. Dois sistemas físicos (não virtualizados) simples
Dois sistemas físicos (não virtualizados) simples
Dois sistemas físicos (não virtualizados) simples

Visto que cada sistema tem seu próprio hardware separado, a quantidade de energia de processamento que está disponível para cada aplicativo é fixa. Se o aplicativo A é muito utilizado, ele pode ser executado lentamente, enquanto o aplicativo B talvez esteja inativo. Assim, a capacidade de processamento do hardware B pode ficar subutilizada. Ao executar ambos os aplicativos no mesmo hardware por meio de um hypervisor, é possível direcionar os recursos para o sistema que precisa deles. Com os sistemas A e B virtualizados no mesmo hardware, o hypervisor pode fornecer mais capacidade de processamento e memória para o aplicativo que está sendo usado com mais intensidade, conforme a Figura 2.

Figura 2. Dois sistemas virtuais
Dois sistemas virtuais
Dois sistemas virtuais

O exemplo da Figura 2 mostra como vários sistemas virtuais podem ser hospedados em um único sistema físico. A virtualização também funciona na direção oposta; vários sistemas físicos podem ser combinados para hospedar um único sistema virtual. O exemplo mais comum desse tipo de virtualização é o armazenamento em cluster, no qual um grupo de servidores de aplicativos trabalham juntos para hospedar um aplicativo. Em vez de executar uma instância separada do aplicativo em cada sistema físico, a camada de virtualização apresenta um único ambiente de hosting para o aplicativo, com os recursos combinados dos sistemas físicos. O seguinte exemplo mostra um cluster de dois servidores de aplicativos que hospedam uma única instância de um aplicativo.

Figura 3. Cluster simples de servidores
Cluster simples de servidores
Cluster simples de servidores

A virtualização permite ambientes de computação em nuvem, que são ambientes de hosting dinâmicos que fornecem recursos de computação aparentemente infinitos. Vários tipos de ambientes de computação em nuvem estão em uso hoje, mas em geral uma nuvem fornece uma biblioteca de sistemas virtuais e um hypervisor no qual executá-los. Os usuários solicitam as instâncias desses sistemas virtuais, usam-nas e retiram a alocação delas quando não são mais necessárias. Desse modo, os sistemas em nuvem usam a virtualização para fornecer um ambiente flexível que pode ser configurado e expandido muito mais facilmente do que um sistema físico.

Um sistema virtual pode fornecer um sistema completo ou pode se concentrar em um recurso virtualizado, como o armazenamento. Por exemplo, um sistema de armazenamento virtual pode incluir vários discos físicos representados como um único meio de armazenamento. Os aplicativos acessam a interface do sistema de armazenamento com o sistema virtual, em vez de armazenar dados diretamente nos discos. Desse modo, podemos combinar vários discos em um único disco virtual.

Figura 4. Um sistema de armazenamento virtual simples
Um sistema de armazenamento virtual simples

A virtualização tem muitos outros usos e vantagens que não são discutidos em detalhes aqui, como a habilidade de executar vários ambientes independentes para teste ou compatibilidade e a habilidade de mover sistemas virtuais de um host físico para outro de forma relativamente fácil. Há muitos documentos IBM disponíveis sobre a virtualização em circunstâncias específicas. Para obter mais informações, consulte a seção Temas relacionados.

Virtualização básica com o editor de topologia

Parte da ideia de virtualização é que o aplicativo não precisa saber se está sendo executado em um sistema virtual ou físico. O sistema virtual parece exatamente igual ao físico para o aplicativo, e os detalhes do sistema físico que hospeda o virtual ficam ocultos do aplicativo. Da mesma forma, é possível usar diagramas de topologia separados para ocultar os detalhes do sistema físico para o aplicativo.

Por exemplo, suponhamos que haja um sistema físico simples, como o mostrado na Figura 5, que consiste em hardware com um sistema operacional.

Figura 5. Um sistema físico simples
Um sistema físico simples

Esse sistema podia hospedar uma imagem virtual, que é um ambiente encapsulado no qual é possível executar um sistema virtual. Como mostra a Figura 6, essa imagem virtual pode conter hardware e sistema operacional virtuais.

Figura 6. Uma imagem virtual simples
Uma imagem virtual simples
Uma imagem virtual simples

Note que a unidade do servidor virtual é idêntica à do servidor físico. (A unidade do sistema operacional virtual é idêntica à do sistema operacional físico, exceto que a última tem o recurso de Hypervisor, que analisaremos mais adiante.) O sistema virtual pode servir de host para aplicativos exatamente da mesma maneira que o sistema físico.

Em uma topologia, é possível tornar essa virtualização totalmente integrada criando um diagrama dedicado ao sistema virtual. Quando visualizamos as unidades no sistema virtual para um novo diagrama (dando um clique com o botão direito do mouse nas unidades do sistema virtual e depois clicando em Visualize > Add to New Topology Diagram), o novo diagrama mostra apenas as unidades do sistema virtual, embora essas unidades estejam ligadas ao sistema físico.

Agora é possível usar o sistema virtual em outras topologias importando o diagrama. Quando importamos um diagrama de outra topologia, criamos uma nova instância das unidades e outros elementos de topologia naquele diagrama. É possível hospedar aplicativos no sistema virtual no diagrama importado assim como se faz em qualquer outro sistema. Em resultado disso, o sistema virtual na topologia se comporta como um sistema virtual no mundo real: pode hospedar aplicativos sem expor o sistema físico subjacente nem ser ostensivamente virtual.

Figura 7. Hospedando um aplicativo em um sistema virtual
Hospedando um aplicativo em um sistema virtual
Hospedando um aplicativo em um sistema virtual

Desse modo, se um projeto exige hosting para uma pilha, é possível substituir um sistema virtual compatível. Por exemplo, a seguinte topologia contém uma pilha de hosting conceitual, uma especificação para o sistema que deve servir de host para um aplicativo.

Figura 8. Uma pilha simples de hosting conceitual
Uma pilha simples de hosting conceitual

Como se dá com todas as unidades conceituais, as unidades nessa pilha de hosting podem ter um link de realização com outras unidades que podem executar todas as mesmas tarefas das unidades conceituais. Por exemplo, a unidade de servidor de aplicativos Java™ 2 Platform, Enterprise Edition (J2EE), pode ser realizada com qualquer servidor de aplicativos que suporte a mesma versão de Java EE, independentemente da marca do servidor. É possível realizar essa pilha de hosting com o sistema físico:

Figura 9. Realizando uma pilha conceitual para um sistema físico
Realizando uma pilha conceitual para um sistema físico
Realizando uma pilha conceitual para um sistema físico

Contudo, também é possível realizar essa pilha de hosting conceitual para um sistema virtual da mesma maneira:

Figura 10. Realizando uma pilha conceitual para um sistema virtual
Realizando uma pilha conceitual para um sistema virtual
Realizando uma pilha conceitual para um sistema virtual

Não é preciso encapsular sistemas virtuais em diagramas separados, mas fazer isso em geral é boa prática de modelagem porque mantém suas topologias independentes e pequenas.

Trabalhando com sistemas virtuais

Em vez de projetar um sistema virtual de baixo para cima, é possível converter um sistema físico existente em um virtual. Por exemplo, é possível criar um ambiente de teste virtual que reproduza seu ambiente de produção. Como alternativa, é possível receber um projeto de sistema físico e decidir implementá-lo virtualmente. Converter um sistema físico em virtual como esse envolve adicioná-lo a uma imagem virtual e então configurá-la para usar a conexão de rede e o espaço de armazenamento do host da imagem virtual.

Convertendo um sistema físico em virtual

Execute as seguintes etapas para converter um sistema físico em virtual:

  1. Crie a topologia do sistema físico original que deseja converter em virtual. É possível duplicar um sistema existente copiando e colando suas unidades, ou é possível criar novas unidades, ou usar o sistema físico diretamente.
Figura 11. Um sistema físico pode ser transformado em virtual
Um sistema físico pode ser transformado em virtual
  1. Se o hardware do sistema não tem uma unidade de interface de rede, adicione uma unidade de interface L2 ao servidor. Essa unidade representa a conexão de rede, como uma conexão Ethernet com fio ou wireless.
  2. Se o sistema operacional não tiver uma unidade de interface de IP, adicione-a para representar o uso que o sistema operacional faz da conexão de rede. (Não é necessário link entre a interface de IP e as unidades da interface L2.)
Figura 12. Adicionando as informações de conexão de rede ao sistema físico
Adicionando as informações de conexão de rede ao sistema físico
  1. Adicione uma unidade de imagem virtual à topologia. É possível usar uma imagem virtual genérica, como o modelo (Imagem virtual) da gaveta Virtualização da Paleta, ou usar uma unidade de imagem virtual VMWare ou Xen específica se quiser trabalhar com uma tecnologia de virtualização específica.
  2. Arraste a unidade do servidor físico para a unidade de imagem virtual para tornar o servidor um membro da imagem virtual.
Figura 13. Movendo o hardware físico para a imagem virtual
Movendo o hardware físico para a imagem virtual
Movendo o hardware físico para a imagem virtual
  1. Adicione uma unidade de definição de disco virtual e uma unidade de conexão Ethernet virtual à imagem virtual. Se a imagem for uma imagem virtual genérica, use a unidade de definição do disco virtual genérico do modelo (Def de disco virtual) e uma conexão Ethernet virtual genérica do modelo (Def NIC de Ethernet virtual). Caso contrário, use os modelos específicos de Xen ou VMWare equivalentes.

Essas unidades representam as informações de configuração específicas de um sistema virtual. Nesse caso, representam a configuração do disco virtual e a conexão de rede. Quando modelamos um sistema virtual em topologia, podemos adicionar essas informações para planejar como o ambiente de virtualização fornecerá e gerenciará o sistema virtual.

Figura 14. Adicionando os recursos virtuais à imagem virtual
Adicionando os recursos virtuais à imagem virtual
Adicionando os recursos virtuais à imagem virtual
  1. No recurso da conexão Ethernet virtual, defina o tipo de conexão para a conexão de rede do sistema host usar, como com ponte, apenas host ou NAT.
Figura 15. Configurando o tipo de conexão
Configurando o tipo de conexão
Configurando o tipo de conexão
  1. Hospede a imagem virtual em um hypervisor apropriado:
    • Para uma imagem genérica, adicione o recurso virtualization.Hypervisor a uma unidade do sistema operacional.
    • Para uma imagem VMWare, use uma unidade VMWare ESX.
    • Para uma imagem Xen, adicione o recurso virtualization.XenHypervisor a uma unidade de sistema operacional.
  2. Hospede o hypervisor em uma unidade de hardware adequada, como uma unidade de servidor x86 a partir do modelo (x86 Server) na gaveta Hardware da Paleta.
Figura 16. Hosting da imagem virtual
Hosting da imagem virtual
  1. Crie um link de dependência da unidade de conexão Ethernet virtual na imagem virtual para conexão L2 no servidor físico. Esse link representa o acesso à rede que o servidor fornece ao sistema virtual. Como se dá com o acréscimo do disco virtual e das unidades de conexão de rede, esse link de dependência aumenta o modelo com informações extras para descrever a configuração da imagem virtual.
Figure 17. Especificando a conexão de rede com um link de dependência
Figure 17. Especificando a conexão de rede com um link de dependência
Figure 17. Especificando a conexão de rede com um link de dependência

O sistema virtualizado completo se comporta exatamente igual a um sistema físico. Como já explicado, é possível importar o sistema virtualizado para outra topologia e usá-lo como usaríamos um sistema físico. Para facilitar a reutilização, visualize o sistema virtualizado em um diagrama separado de modo a poder importar esse sistema para outras topologias sem expor detalhes do host físico.

Figura 18. Hosting de um aplicativo no servidor recém-virtualizado
Hosting de um aplicativo no servidor recém-virtualizado
Hosting de um aplicativo no servidor recém-virtualizado

Planejando a implementação em uma imagem virtual existente

Se já dispusermos de uma imagem virtual, poderemos planejar a implementação dessa imagem em uma topologia. O editor de topologia reconhece arquivos Xen XMDOMAIN, VMWare VMX e VMSD. Esses arquivos fornecem informações sobre um host virtual, e o editor de topologia pode criar unidades que representam o host com base nessas informações. Contudo, esses arquivos não contêm informações suficientes para modelar o sistema operacional e outros softwares hospedados na imagem virtual. É possível usar o editor de topologia para adicionar informações sobre o sistema à imagem virtual e para planejar como a imagem virtual será implementada. (Contudo, o editor de topologia não pode fazer mudanças nos arquivos de imagem virtual.)

Execute as seguintes etapas para implementar uma imagem virtual existente em uma topologia:

  1. Arraste e solte uma imagem virtual, como um arquivo VMWare VMX, para uma topologia (Figura 19). O editor de topologia cria uma unidade de imagem virtual ligada e correspondente (Figura 20) que contém unidades de definição de disco e unidades de conexão de rede, de acordo com os dados no arquivo de imagem virtual.
Figura 19. Arrastando uma imagem virtual para o editor de topologia
Arrastando uma imagem virtual para o editor de topologia
Arrastando uma imagem virtual para o editor de topologia
Figura 20. Unidades que representam a imagem virtual
Unidades que representam a imagem virtual
Unidades que representam a imagem virtual
  1. Hospede a imagem virtual em uma unidade de hypervisor apropriada:
    • Para imagens VMWare, use uma unidade VMWare ESX ou uma unidade de sistema operacional com o recurso virtualization.VMwareHypervisor, que representa o software VMWare instalado em um sistema operacional.
    • Para Xen, use uma unidade de sistema operacional e adicione o recurso virtualization.XenHypervisor para representar o software de hosting Xen.
Figura 21. Hosting da imagem virtual
Hosting da imagem virtual
  1. Dentro da unidade da imagem virtual, adicione unidades conforme apropriado para o uso da imagem virtual. Por exemplo, é possível adicionar uma unidade de hardware de servidor em uma unidade de sistema operacional para representar os recursos de hosting do sistema virtual.
Figura 22. Representando o software que está no sistema virtual
Representando o software que está no sistema virtual
  1. Hospede a unidade do hypervisor em uma pilha de hosting adequada.

Exemplos de topologias virtuais

A seção a seguir mostra alguns exemplos de sistemas virtuais modelados no editor de topologia. Há muitos outros exemplos de topologias disponíveis na ajuda do produto: clique em Help > Help Contents e expanda Samples > Technology Samples > Topologies. Muitas das topologias mostradas neste artigo estão disponíveis na seção Temas relacionados.

VMWare ESX

Um sistema VMWare ESX (Figura 23) é um tipo de hypervisor executado diretamente no hardware, no lugar de um sistema operacional. Uma única instância de VMWare ESX pode servir de host para uma ou mais imagens virtuais, cada qual contendo um sistema virtual. A imagem virtual também contém definição de disco virtual e unidades de conexão de rede virtual que representam os recursos virtuais que o hypervisor fornece ao sistema virtual.

Figura 23. Exemplo de um sistema VMWare ESX
Exemplo de um sistema VMWare ESX
Exemplo de um sistema VMWare ESX

Xen

Xen é uma tecnologia de virtualização de software livre. Topologias que usam Xen para virtualização se parecem muito às que usam VMWare, exceto que o hypervisor Xen é representado pelo recurso virtualization.XenHypervisor na unidade do sistema operacional físico, em vez de por uma unidade separada.

Figura 24. Exemplo de um sistema Xen
Exemplo de um sistema Xen
Exemplo de um sistema Xen

Armazenamento em cluster

Um exemplo simples de armazenamento em cluster foi fornecido na introdução. Um exemplo semelhante está disponível na amostra Topologies for specialized domains (consulte a seção Temas relacionados). O armazenamento em cluster envolve combinar um grupo de sistemas físicos em um único ambiente de hosting para um ou mais aplicativos ou sistemas virtuais. A Figura 25 mostra um cluster dos IBM® WebSphere® Application Servers que serve de host para um aplicativo.

Figura 25. Exemplo de cluster de servidores
Exemplo de cluster de servidores
Exemplo de cluster de servidores

System z

A partir do IBM Rational Software Architect 7.5.4, as ferramentas de arquitetura de implementação incluem unidades e outros elementos de topologia que representam componentes do IBM® System z®. O System z permite virtualização em duas áreas principais: ao nível de hardware com partições lógicas (LPARs) e ao nível de sistema operacional com IBM® z/VM®. Um item do hardware do System z pode ter vários processadores e é possível alocá-los para LPARs no sistema. É possível usar LPARs para dividir um único item de hardware do System z em itens virtuais separados de hardware. Cada um desses LPARs pode executar um sistema operacional, como z/VM, IBM® z/VSE™ ou IBM® z/Linux.

Figura 26. Exemplo de LPARs em um sistema do System z
Exemplo de LPARs em um sistema do System z
Exemplo de LPARs em um sistema do System z

Para fornecer camadas adicionais de virtualização, uma instância do z/VM pode servir de host para um ou mais sistemas operacionais, chamados convidados do z/VM. Esses convidados fornecem outra camada de virtualização. A topologia na Figura 27 mostra um sistema de System z simples que serve de host para vários sistemas virtuais diferentes.

Figura 27. Exemplo de um sistema System z completo, com convidados do z/VM
Exemplo de um sistema System z completo, com convidados do z/VM
Exemplo de um sistema System z completo, com convidados do z/VM

Nesse exemplo, o sistema tem quatro processadores físicos: dois processadores centrais (CPs) e dois z Application Assist Processors (zAAPs). Esses processadores são compartilhados entre os três LPARs, cada qual executando um sistema operacional virtual separado. Um desses sistemas operacionais virtuais é dividido adicionalmente em dois sistemas virtuais convidados, um que hospeda z/Linux e outro, z/VSE. Desse modo, a virtualização do System z permite dividir um grande computador em vários sistemas virtuais e distribuir os recursos do sistema conforme necessário.

Resumo

Os exemplos deste artigo mostram alguns modos de modelar sistemas virtuais simples com as ferramentas de arquitetura de implementação. Mostram também como separar sistemas virtuais em diagramas, o que ilustra a independência dos sistemas virtuais em relação aos seus hosts físicos. Dessa forma, as ferramentas de arquitetura de implementação podem ajudá-lo a planejar a implementação de aplicativos ou ambientes complexos. Vários desses exemplos de topologias estão disponíveis em um projeto na seção de Download.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=499108
ArticleTitle=Modelagem de sistemas virtuais com as ferramentas de arquitetura de implementação do IBM Rational Software Architect
publish-date=07022010