Recursos de modelagem de implementação do IBM PowerVM para virtualização

Como customizar o editor de topologia do Rational Software Architect

Este tutorial mostra como usar as habilidades de customização do IBM® Rational® Software Architect para modelar as topologias do IBM ® PowerVM™ . Ele apresenta as etapas para adicionar novas unidades, com novas capacidades e requisitos, e mostra como aproveitar blocos de construção existentes para adicionar uma nova camada de virtualização. Ele também descreve o suporte existente para modelagem de virtualização de x86 e IBM® System z® por meio de uma abordagem passo a passo que explica os conceitos subjacentes utilizados e como aplicá-los no desenvolvimento do novo modelo PowerVM.

Antes de iniciar

IBM® Rational® Software Architect é uma ferramenta poderosa para desenvolvimento de software, mas os recursos não se limitam e essa área específica. Com seu suporte completo a UML e habilidades gerais de modelagem, ele pode ser usado de modos muito flexíveis:

  • Diagramação de forma livre: A multiplicidade de opções de diagrama fornece uma base completa para diagramas de forma livre, visto que eles costumam ser usados em cenários de desenvolvimento não de software. Uma visão geral da arquitetura de TI pode ser obtida facilmente usando um modelo de Implementação ou de Componentes ou até mesmo misturando conceitos de diferentes modelos.
  • Artefatos de método: Ao seguir uma metodologia específica (Rational Unified Process ou OpenUP, por exemplo) muitas vezes há a necessidade de criar modelos e diagramas. O Rational Software Architect pode ser usado com bons resultados para produzi-los, sozinho ou usando plug-ins específicos que agilizam o processo e fornecem modelos úteis.
  • Topologias de implementação de modelagem: Essa é uma habilidade específica que versões recentes disponibilizam e que é diferente do modelo de implementação de UML.

Este tutorial concentra-se no último ponto: topologias de implementação. Este recurso pode ser usado de muitas maneiras diferentes. Como exemplo, pode-se colocar de lado todas as minúcias sobre restrições, requisitos e recursos e simplesmente usá-lo como outra forma de diagramação. Isso se aplica à maioria das partes do Rational Software Architect, na medida em que há um uso superficial que pode ser imediatamente produtivo e um maior complexo que leva mais tempo para aprender, mas que tem potencial ainda maior para produtividade.

As topologias de implementação não são UML (embora usem links UML se estiverem presentes e sejam integradas com diagramas UML existentes) e podem representar uma grande variedade de sistemas de computador em diferentes níveis de abstração. É bastante intuitivo, pois não exige o nível de compreensão conceitual que o UML exige. Ele usa termos bem conhecidos para relacionamentos bem conhecidos entre software, hardware e outros componentes de TI. Por padrão, o Rational Software Architect vem com modelos que abrangem muitos pacotes de software diferentes, modelos de hardware, sistemas operacionais e muitas outras unidades em domínios diferentes. Mas é igualmente importante destacar que o Rational Software Architect possibilita customizar as unidades existentes de acordo com as suas necessidades.

Este tutorial o guiará pelo processo de desenvolvimento de uma estrutura de virtualização feita sob medida para uso na modelagem da plataforma IBM ® Power Systems™ com tecnologias PowerVM. O Rational Software Architect tem um ótimo editor de topologia de implementação que contém suporte explícito a várias tecnologias de virtualização e, igualmente importante, facilita a customização de elementos existentes. Usando a modelagem PowerVM como exemplo, aprenderemos a modificar rapidamente unidades genéricas para adaptá-las a novos cenários.

Sobre este tutorial

Este tutorial é basicamente dividido em três etapas básicas:

  1. Uma introdução breve à modelagem de implementação física, usando servidores discretos
  2. Uma visão geral prática de algumas das tecnologias de virtualização existentes explicitamente suportadas pelo Rational Software Architect
  3. O desenvolvimento gradual do suporte à virtualização PowerVM usando as ferramentas de customização do Rational Software Architect

Embora o processo de customização seja simples, este tutorial não supõe que o usuário tenha experiência prévia com o Rational Software Architect. Portanto, é dada ênfase à demonstração de como as topologias de implementação são criadas e preenchidas. Quando começa o processo de customização, os principais conceitos de topologias já foram demonstrados e formam uma progressão natural.

Objetivos

Neste tutorial, aprenderemos sobre as topologias de implementação do Rational Software Architect, a modelar uma infraestrutura física e a modelar de diferentes tecnologias de virtualização. No final deste tutorial, teremos implementado com sucesso o suporte à modelagem PowerVM e aprendido os conceitos básicos de customização que podem ser usados em muitos outros cenários.

Pré-requisitos

Este tutorial não se baseia em nenhum sistema operacional específico. Contudo, os exemplos usam Linux, de modo que qualquer operação de sistema de arquivo deve ser convertida para o equivalente se for usado outro sistema operacional.

Este tutorial não exige conhecimento prévio das topologias de implementação de modelagem. É útil ter certa familiaridade com o Rational Software Architect, mas não é um requisito.

Requisitos do sistema

O único requisito deste tutorial é o Rational Software Architect Versão 8.0 (ou posterior) com os recursos de Modelagem de Implementação ativados.


Criação de topologia

  1. Abra o Rational Software Architect.
  2. Crie um projeto selecionando File > New > Project.
  3. Na categoria Geral , selecione Project e, a seguir, clique em Next.
  4. No campo de texto Project Name, digite powervm_test.
  5. Clique em Finish para criar o projeto.
Figura 1. Criando um projeto
Criando um projeto

Após criar o projeto, acrescentaremos uma topologia a ele.

  1. Dê um clique com o botão direito do mouse no nome do projeto no Project Explorer e selecione New>Topology.
Figura 2. Acrescentando uma nova topologia ao projeto
Acrescentando uma nova topologia ao projeto

Visualização maior da Figura 2.

  1. Quando aparecer a janela de criação de topologia (veja a Figura 3), selecione Blank Topology na categoria Basic Topologies.
  2. Chame-a de test_topology e clique em Finish
Figura 3. Assistente New Topology
Assistente New Topology

O Rational Software Architect tem diferentes perspectivas, e cada uma muda o modo em que as informações e ferramentas são apresentadas a fim de tornar o ambiente de trabalho mais alinhado com a meta do modelo no qual se está trabalhando.

  1. Após a criação de uma topologia, aparecerá a opção de mudar a perspectiva de Implementação. Aceite a oferta clicando em OK.

Foi criada a topologia (veja a Figura 4). Aparecerá um aviso de boas-vindas. É uma boa ideia explorar os tópicos sugeridos. Para os fins deste tutorial, porém, feche o aviso de boas-vindas.

Figura 4. Topologia em branco
Topologia em branco

Visualização maior da Figura 4.

Agora estamos prontos para explorar o editor de topologia.


Topologias de implementação física

Antes de tratar de ambientes virtualizados, começaremos fazendo a modelagem de um cenário mais simples: a representação da implementação de uma aplicativo em um sistema operacional que é, por sua vez, instalado em um servidor específico. Vários conceitos importantes que é preciso entender mais adiante neste tutorial estão incluídos nesta seção.

Usaremos as seguintes unidades para ter êxito em modelar esse cenário, todas elas presentes na paleta que fica, por padrão, à direita da tela, ao lado do editor de diagrama.

Unidades conceituais e concretas

É importante notar que usaremos unidades realizadas e prontas para usar, não unidades conceituais . Não deixe de selecionar servidor do LDAP, não (servidor do LDAP). Embora, para a maioria dos exemplos, o comportamento fosse o mesmo, as unidades conceituais são diferentes das não conceituais de diversas formas, sendo uma delas o cumprimento de certos requisitos.

As unidades conceituais, em geral, fornecem informações onde uma unidade realizada forneceria um aviso, o que é lógico porque uma unidade conceitual terá de ser realizada com o tempo, e só então os requisitos serão executados. Como regra geral, os modelos conceituais têm muito menos valores padrão especificados do que seus equivalentes físicos e podem ser convertidos em uma unidade realizada e concreta utilizando os valores de Propriedades ou, mais comumente, ligados a uma unidade não conceitual por um link de realização .

  • Servidor do LDAP: Encontrado nos modelos de Middleware
  • Servidor do Power: Encontrado nos modelos de Hardware
  • Servidor x86: Também encontrado nos modelos de Hardware
  • AIX 5L: Encontrado nos modelos de Sistema Operacional
  • Linux: Também encontrado nos modelos de Sistema Operacional

Hosting de servidor do LDAP em sistemas IBM AIX

  1. Arraste o servidor do LDAP para o diagrama e note o ícone de aviso no canto inferior esquerdo. (Veja a Figura 5.)

Clicar nele exibirá informações sobre o erro detectado. Quando não são encontrados erros, o ícone se transforma em um ícone azul com um i nele (letra i minúscula). Ao clicar nele, ele exibe informações, incluindo ações opcionais que seriam úteis, mas não são estritamente necessárias. Isso é muito útil, porém, e deve ser usado constantemente, pois fornece informações em tempo real sobre a consistência do modelo, além de economizar muito tempo, porque as ações propostas não são apenas sensíveis ao contexto, mas levam em conta o ambiente circundante.

Figura 5. Acrescentando o servidor do LDAP à topologia
Acrescentando o servidor do LDAP à topologia
  1. Clique no ícone de aviso. Como a Figura 6 indica, o servidor do LDAP precisa estar hospedado em um sistema operacional.
Figura 6. Mensagem de aviso sobre o servidor do LDAP
Mensagem de aviso sobre o servidor do LDAP
  1. IBM® AIX 5L™ for POWER™ é um sistema operacional UNIX, por isso, acrescente-o ao diagrama: arraste o modelo AIX 5L para o diagrama.

Agora, temos uma representação de uma implementação AIX. Se observarmos o ícone de aviso, notaremos que essa unidade também contém avisos. Mas concentre-se no servidor do LDAP por enquanto e deixe os avisos de AIX para mais tarde.

  1. Clique novamente no aviso do servidor do LDAP e, dessa vez, clique na entrada específica que contém: "Unit ('LDAP Server') must be hosted (OperatingSystem)". Uma das ações sugeridas é hospedá-lo na unidade no hostname , que é a instância AIX acrescentada, mas que ainda não tem um nome adequado.
  2. Selecione essa opção selecionando a ação no painel inferior e dando um clique duplo nela. Isso hospedará a unidade do servidor do LDAP na instância AIX .
Figura 7. Usando as ações propostas
Usando as ações propostas

Note que o aviso desapareceu do servidor do LDAP, o que quer dizer que todos os requisitos obrigatórios foram cumpridos. Há um link de hosting entre o servidor do LDAP e a instância AIX, como mostrado na Figura 8.

Figura 8. Servidor do LDAP hospedado em uma instância AIX
Servidor do LDAP hospedado em uma instância AIX

Visualização maior da Figura 8.

Recursos e requisitos

Para ver os requisitos de qualquer unidade, vá até a guia Requirements da unidade Properties, exibida logo abaixo do diagrama. No caso do servidor do LDAP, há exatamente um requisito: Host no sistema operacional. Execute o mesmo processo para ver os Recursos da unidade.

Relacionamentos diferentes têm links diferentes. O hosting é representado por uma seta com duas linhas paralelas. Mais adiante neste tutorial, veremos como as dependências e os relacionamentos de associação têm filas visuais diferentes.

É hora de dar uma olhada na unidade AIX, que, como mencionado antes, continha avisos.

  1. Clique no ícone de aviso dessa unidade. Aparecerá uma lista de erros (veja a Figura 9) que inclui a necessidade de definir o nome do host, a senha de raiz e de usar como host do sistema operacional um servidor físico.
Figura 9. Avisos da instância AIX
Avisos da instância AIX

Primeiro trataremos das questões relativas ao nome de host e à senha de raiz.

  1. Executando o método explicado anteriormente de seleção de cada erro e escolha de uma ação proposta, dê o nome de gemini ao host AIX (usando a ação Set hostname proposta para o erro "hostname" is undefined ), e defina a senha de raiz como 123 para cuidar do erro userPassword is undefined sob o usuário raiz.
  2. Clique novamente no ícone de aviso e aparecerá o erro final relativo à falta de host (Figura 10).
Figura 10. Aviso de requisito de hosting do AIX
Aviso de requisito de hosting do AIX

Acrescentando os servidores físicos

A instância AIX deve ser hospedada em um servidor. Para entender esse requisito, dê uma olhada, como mencionado acima, na guia Requirements na unidade Properties, que, por padrão, se encontra na parte inferior da tela.

Figura 11. Visualizando os requisitos de unidade do AIX
Visualizando os requisitos de unidade do AIX

Visualização maior da Figura 11.

O requisito especifica que o AIX pode ser hospedado em qualquer unidade com o recurso server.Server , o que inclui servidores x86. Isso talvez pareça estranho, mas após uma inspeção melhor nota-se que há uma restrição para esse requisito. Clique na guia Constraints na visualização Properties .

Figura 12. Restrições do hosting de AIX
Restrições do hosting de AIX

Visualização maior da Figura 12.

A restrição especifica que o servidor que serve de host deve implementar a arquitetura PowerPC. Para testar isso, solte duas unidades de servidor no diagrama: um Power Server e um x86 Server.

Figura 13. Incluindo servidores
Incluindo servidores

Visualização maior da Figura 13.

No Rational Software Architect existem várias maneiras de executar a ação, de modo que usaremos um método diferente para determinar o host desta unidade. Coloque o ponteiro sobre a unidade AIX. Aparecerá uma seta amarela. Clique nela e arraste-a para um espaço em branco. Aparecerá uma janela pop-up que perguntará o tipo de relacionamento que se deseja indicar. Escolha Hosting link.

Figura 14. Usando a descoberta de link
Usando a descoberta de link

Visualização maior da Figura 14.

O Rational Software Architect apresentará uma lista de opções compatíveis com os requisitos. Visto que, como já vimos, há um requisito obrigatório em relação à arquitetura de CPU que pode servir de host para uma instância AIX e apenas a unidade Power Server aparece na lista. Selecione-a e clique em OK.

Fazer a correspondência de links de hosting

A instância AIX agora está hospedada e todos os avisos desapareceram dela, como mostrado na Figura 16. O Power Server não tem requisitos, de modo que nunca exibe avisos.

Figura 16. Instância de AIX hospedada no servidor Power
Instância de AIX hospedada no servidor Power

Visualização maior da Figura 16.

Hosting de Linux no servidor x86

Siga o mesmo procedimento para acrescentar uma unidade Linux e outra unidade do servidor do LDAP , hospedar a unidade Linux no servidor x86 e o novo servidor do LDAP na unidade Linux.

Figura 17. Pilhas finais de AIX e Linux
Pilhas finais de AIX e Linux

Visualização maior da Figura 17.

Organização automática das unidades

Os exemplos neste documento usam as opções Select all e Arrange all na barra de ferramentas, que reorganizam automaticamente todas as unidades e links de acordo com um padrão definido na topologia Properties.

Em termos de estilo visual estamos vendo as unidades hospedadas fora do seu host, com um link de hosting que indica o relacionamento. Dependendo do objetivo, isso pode ser útil para ter uma visualização mais compacta. Isso é obtido facilmente por meio das opções da barra de ferramentas Show Unit on Host ou simplesmente arrastando a unidade para o host. Isso também funciona para criar um novo relacionamento de hosting se já não existir um. Arrastar as unidades para fora tem o efeito inverso.

Pode-se misturar e fazer a correspondência de diferentes organizações visuais dentro do mesmo diagrama. Isso pode ser útil para dar um foco diferente a determinados componentes. A Figura 18 mostra duas pilhas diferentes organizadas de maneiras diferentes.

Figura 18. Diferentes maneiras de visualizar relacionamentos de hosting
Diferentes maneiras de visualizar relacionamentos de hosting

Visualização maior da Figura 18.

Agora que experimentamos com sucesso as implementações físicas, é hora de ver o que muda ao apresentar opções de virtualização. As próximas seções dão uma visão geral de algumas das possibilidades.


Modelando topologias virtualizadas: x86 com VMware

A versão atual do Rational Software Architect não trata especificamente do PowerVM. Mas dispõe de uma categoria de paleta de Virtualização com unidades dedicadas para VMware e Xen, mais z/VM. Visto que, mais tarde, utilizaremos suas facilidades simples, mas poderosas, de customização de unidade para modelar implementações do PowerVM, faz sentido primeiro explorar como a virtualização é modelada em outras plataformas de hardware que têm suporte explícito no Rational Software Architect.

  1. Crie uma topologia executando as mesmas etapas de antes e dê-lhe o nome de virt_topology.
  2. Inclua um servidor do LDAP e uma unidade do sistema operacional Linux e crie um link de hosting entre eles.

Observação sobre essas instruções:
Para o restante deste tutorial, alguns detalhes que já foram abrangidos antes serão omitidos.

Figura 19. Refazendo a implementação do LDAP
Refazendo a implementação do LDAP

Visualização maior da Figura 19.

Acrescentando a camada de virtualização

  1. Em vez de criar um servidor, como feito antes, arraste uma unidade VMwareESX da paleta Virtualization para o diagrama.

Visto que o VMware ESX não é implementado em firmware, precisa ser implementado em um servidor x86, como indicado na lista de avisos da unidade. Pode-se visualizar a unidade VMwareESX como representação do software que precisa ser instalado de forma a fornecer um servidor x86 com um hypervisor que permite a virtualização dos recursos.

  1. Inclua uma unidade do servidor x86 no diagrama e hospede a unidade VMwareESX nela
Figura 20. VMware ESX hospedado em servidor x86
VMware ESX hospedado em servidor x86

Visualização maior da Figura 20.

À primeira vista, pode-se supor que essa unidade VMware ESX seria o host direto de vários sistemas operacionais, mas essa unidade não tem essa capacidade. Mas podemos tentar. Se tentarmos criar um link de hosting entre Linux e VMware ESX, será exibida uma janela pop-up para permitir a criação de um novo recurso no destino. Não é isso o que queremos, mas é um recurso útil a lembrar, especialmente para a customização da unidade. O hypervisor não serve de host direto para um sistema operacional, e sim de uma imagem virtual que representa os recursos virtualizados que podem ser usados por um servidor virtual.

  1. Inclua uma Imagem Virtual de VMware no diagrama e use a unidade VMware ESX como host dela. Para este tutorial, a unidade VMware ESX recebeu o nome de host lupus . O resultado deve ser similar à Figura 21.
Figura 21. Acrescentando uma imagem virtual
Acrescentando uma imagem virtual

Visualização maior da Figura 21.

Imagens e servidores virtuais

À primeira vista, esse modo de modelagem de ambientes virtualizados pode parecer muito complexo. Talvez surja a pergunta: por que não usar uma Imagem Virtual como representação do hardware virtual onde um sistema operacional pode ser implementado, em vez de tê-la como camada extra?

Analise a possibilidade de trabalhar em uma transformação de físico para virtual na qual já existe um modelo de topologia para a infraestrutura física. A abordagem da Imagem Virtual torna trivial simplesmente "agrupar" o ambiente físico dentro do contêiner de Imagem Virtual, em vez de ter de modificar o relacionamento de hosting entre o sistema operacional e o servidor físico. Levando em conta que o servidor físico pode ter informações relevantes (número de CPUs ou tamanho da memória RAM, por exemplo), isso significaria ter de duplicar manualmente as informações ou descartá-las completamente.

Para entender melhor o conceito por trás das imagens virtuais, dê uma olhada na lista de Recursos da unidade. Os recursos e requisitos, com as limitações associadas, definem a maior parte do que se precisa saber sobre qualquer unidade. Observe que isso precisa ser hospedado em um servidor, como visto anteriormente, e deve ter um membro que é um servidor. De início, isso pode ser estranho porque não há sinal de aviso na unidade. Se dermos uma olhada mais de perto na guia Constraints , a falta de aviso é esclarecida: o número de servidores que devem ser membros da unidade é um ou zero.

É importante notar que essa unidade de Imagem Virtual de VMware não especifica os sistemas operacionais como possíveis membros, mas servidores, que, por sua vez, servirão de host do sistema operacional.

  1. Inclua um servidor x86 no diagrama e torne-o um membro da unidade ESX, arrastando e soltando esse servidor na unidade Imagem Virtual de VMware . A associação sempre é mostrada por meio da exibição do membro no host. A Figura 22 mostra a topologia até esse ponto.
Figura 22. Usando uma Imagem Virtual como contêiner
Usando uma Imagem Virtual como contêiner

Visualização maior da Figura 22.

Modelagem de recursos virtuais

Antes de hospedar a unidade Linux no servidor virtual, talvez já tenha notado que clicar em uma unidade também exibe uma pequena dica de ferramenta com ícones, um tipo de entrada de "inclusão rápida", que mostra o que costuma ser hospedado ou agrupado nessa unidade. Se isso for feito em um servidor x86 aparecerá uma lista dos sistemas operacionais Microsoft Windows e Linux. Em um IBM Power Server, mostrará apenas AIX e, no AIX, mostrará ícones de usuários, grupos, sistemas de arquivos, e assim por diante. Na unidade Imagem Virtual de VMware exibirá as seguintes definições:

  • VMware Virtual SCSI Disk Definition: Representa a configuração de um disco virtual, como feito pelo ESX, que é disponibilizada para a imagem virtual.
  • VMware Virtual IDE Disk Definition: Como acima, mas para um disco IDE.
  • VMware Virtual Ethernet NIC Definition: representa um NIC disponibilizado para a imagem virtual
  • VMware Virtual Server Snapshot: Uma configuração de captura instantânea

Como observado anteriormente, essas definições representam os recursos virtuais disponibilizados para a imagem virtual e, portanto, em última instância, para o sistema operacional hospedado. Essas unidades não são exigidas pela imagem virtual, e sua utilização depende da implementação específica que está sendo feita e do nível de detalhamento que a topologia refletirá.

Inclua VMware SCSI Disk Definition e VMware Virtual Ethernet NIC Definition no diagrama. Os avisos e os Requirements indicam que devem ser hospedados em VMware Virtual Server Definition, um recurso que a unidade Imagem Virtual de VMware existente implementa.

Figura 23. Acrescentando recursos virtuais a uma imagem
Acrescentando recursos virtuais a uma imagem

Visualização maior da Figura 23.

Como se pode ver na Figura 23, há um ícone de informações na imagem virtual e no NIC virtual (unidades de hosting sempre mostram avisos e as informações herdadas das unidades que hospedam), que informam que existe um requisito opcional não atendido: o NIC Virtual de VMware depende de uma interface de Camada 2. Ou, explicando de outra maneira: o NIC de Ethernet Virtual deve ser apoiado por um físico. Esse nível de detalhamento está fora do escopo deste tutorial. Consulte o artigo do developerWorks intitulado "Modelagem de sistemas virtuais com as ferramentas de arquitetura de implementação do IBM Rational Software Architect", citado na seção de Recursos .

Agora há, em uma extremidade, um servidor de LDAP hospedado em uma instância Linux e, na outra, um servidor x86 que hospeda VMware ESX, o qual, por sua vez, hospeda uma Imagem Virtual. Esse elemento Imagem Virtual hospeda dois recursos virtuais (um disco e uma NIC de Ethernet) e tem como membro um servidor x86 que representa a capacidade virtual de hospedar sistemas operacionais.

Reunindo tudo

Agora pode-se, finalmente, reunir as duas extremidades e hospedar a instância Linux no x86 Server contido na Imagem Virtual de VMware. defina o nome de host da instância Linux, se já não tiver feito isso. Todos os avisos desaparecem do modelo e devem ser muito similares à Figura 24.

Figura 24. Hosting de Linux na infraestrutura virtualizada
Hosting de Linux na infraestrutura virtualizada

Visualização maior da Figura 24.

Isso resume os principais conceitos de modelagem de implementações de virtualização de VMware no Rational Software Architect, que são basicamente idênticos ao usar Xen em vez de VMware

A seção a seguir mostrará uma abordagem diferente na modelagem de virtualização.


Modelando topologias virtualizadas: System z e z/VM

Agora, veremos como a virtualização é modelada no System z. Os recursos de virtualização do System z eram pioneiros quando foram lançados, e o Rational Software Architect tem suporte explícito para eles. Ao falar sobre a virtualização do System z, é importante notar que existem várias maneiras de implementá-la, incluindo estas:

  • LPAR: O System z permite a criação de vários LPARs, que são então gerenciados, em termos de recursos, pelo PR/SM.
  • VM Guest: IBM® z/VM® é um sistema operacional com a capacidade de executar outros sistemas operacionais como convidados (o ambiente z/VM típico usa o CMS como sistema operacional) incluindo outra cópia do z/VM.

Nesta seção, implementaremos em um convidado do z/VM, porque essa é a escolha mais comum ao levar em conta o Linux e o System z.

Importando topologias

É possível e incentivado usar a mesma topologia base que representa a implementação de LDAP no Linux e depois importá-la para cada uma das diferentes topologias de virtualização. Isso permitirá usar a mesma topologia básica, um servidor do LDAP hospedado em Linux, e modelar sua implementação em diferentes cenários. Este tutorial não usa essa abordagem, principalmente para evitar a introdução de um conceito diferente, mas também para permitir mais prática na criação e ligação de unidades.

Para mostrar claramente que estamos usando unidades não compartilhadas, os nomes de host das unidades nos exemplos são diferentes em cada topologia.

Criando a topologia base

  1. Crie uma topologia chamada systemz_topology e recrie a implementação de servidor do LDAP no Linux:
    1. Inclua um servidor do LDAP e um sistema operacional Linux e crie um link de hosting entre eles.
    2. Defina a senha de raiz e o nome de host para a unidade Linux .
  2. Solte um Servidor de System z da categoria de paleta Hardware no diagrama. Clicar no indicador de aviso mostra que o servidor de System z precisa de, pelo menos um LPAR.
  3. Inclua um LPAR, também encontrado na paleta Hardware , no diagrama e hospede-o no servidor de System z criando um link de hosting.
  4. Agora, inclua um IFL (Integrated Facility for Linux), que é uma CPU dedicada para Linux, no LPAR. É fácil executar essa ação clicando na unidade de LPAR.
  5. Quando aparecer uma barra de ferramentas, selecione o ícone que representa uma CPU com um pinguim. O LPAR contém um aviso (Figura 25) porque um LPAR com um IFL deve hospedar diretamente Linux ou z/VM.
Figura 25. Um LPAR com IFL possui requisitos específicos
Um LPAR com IFL possui requisitos específicos

Visualização maior da Figura 25.

  1. Clique no ícone de aviso e selecione o aviso existente.
  2. Clique duas vezes na ação Host "ZVM" em LPAR "LPAR" proposta.

A Figura 25 mostra o resultado final das ações tomadas até este ponto.

Figura 26. Hosting de instância z/VM
Hosting de instância z/VM

Visualização maior da Figura 26.

O IFL anteriormente adicionado ao LPAR apresenta um ícone de informações porque um IFL pode, opcionalmente ser hospedado no servidor de System z.

  1. Clique no ícone de informações do IFL, selecione a entrada Unit (IFL) may be optionally hosted () e dê dois cliques na ação Host "IFL" em "System z Server" proposta. Essa relação representa o fato de que o IFL está fisicamente presente no servidor de System z, mas não foi atribuída ao LPAR.

Note a diferença entre as setas que representam os relacionamentos entre o host e a unidade contida. No Servidor de System z, o IFL é hospedado; no LPAR, o IFL é um membro.

Se tentarmos hospedar a instância Linux na unidade z/VM criada, isso não funcionará. Assim como no cenário de VMware, é preciso uma camada intermediária que indique que o sistema operacional está sendo executado em uma imagem virtual, não diretamente a partir da instância z/VM.

  1. Arraste a unidade convidado z/VM da paleta Virtualization para o diagrama (ou use a barra de ferramentas da unidade z/VM, como já mostrado) e hospede-a na unidade z/VM.

Lidar com erros de hosting

Agora estamos prontos para hospedar a instância Linux. Ligue a unidade Linux ao Convidado z/VM para criar um relacionamento de hosting.

Figura 27. Erro de hosting de Linux no z/VM
Erro de hosting de Linux no z/VM

Nota-se que, como na Figura 29, o link de hosting tem um aviso. Clicar nele revelará que a unidade Linux que estava sendo usada não pode ser implementada no z/VM.

Figura 28. Detalhes de erro de hosting
Detalhes de erro de hosting

Existem várias maneiras de resolver isso, e alguns delas são fornecidos pela caixa de diálogo de aviso. A abordagem mais direta é a utilização de um modelo apropriado. Em vez de Linux, que é específico do x86, use z/Linux, que pode ser encontrado na pilha do System z na gaveta de paleta Operating Systems .

Usando um atalho para incluir unidades

O atalho Ctrl-t chamará uma janela pop-up que exibe todos os modelos disponíveis e permite pesquisa em tempo real, reduzindo os resultados cada vez que a tecla é pressionada. Mantém também as unidades usadas mais recentemente no alto.

Uma alternativa que usaremos neste tutorial, para mostrar como as unidades podem ser customizadas, envolve a remoção de restrições. Visto que o Linux roda em praticamente qualquer coisa (o que é especialmente verdadeiro se levarmos em conta as arquiteturas de CPU disponíveis no Rational Software Architect), basta remover a restrição associada ao requisito de hosting da unidade Linux. Selecione a unidade Linux e vá até a guia Requirements da unidade Properties. Selecione o requisito Server e, na área de conteúdo à direita, selecione a guia Constraints (Figura 29).

Há uma restrição listada, cpuArchitecture = intel. Selecione-a e remova-a clicando na cruz vermelha acima dela.

Figura 29. Removendo uma restrição
Removendo uma restrição

Isso remove imediatamente o aviso e o modelo está livre de erros, como mostrado na Figura 30.

Figura 30. Modelo final sem avisos
Modelo final sem avisos

Essa unidade Linux que você criou é genérica em termos de requisitos de hospedagem de hardware. Outra opção seria apenas mudar a restrição para fazê-la exigir uma arquitetura de System z , nesse caso criaríamos uma unidade muito similar ao padrão z/Linux . Nas próximas seções, veremos como esse tipo de unidade customizada pode ser acrescentado à paleta.

Note que, com o System z, não usamos nenhum Disco Virtual ou definição de NIC. No Rational Software Architect, a virtualização de System z não os usa, mas, em contrapartida, há suporte de baixa granularidade para diferentes CPUs (CP, IFL, ZiP, e assim por diante) e como elas são hospedadas e usadas.

Nas próximas seções começaremos a desenvolver nossa própria abordagem de virtualização.


Acrescentando recursos de hosting do PowerVM

Agora que já vimos como a virtualização é modelada no System z e x86, finalmente começaremos a trabalhar no objetivo principal deste tutorial: ser capaz de modelar cenários de virtualização que incluem PowerVM.

Há um modo que já funciona: visto que o Power Server não impõe nenhuma restrição quanto ao número de sistemas operacionais que hospeda diretamente, basta acrescentar algumas unidades AIX em um único Power Server. Se usarmos a unidade Linux customizada que alteramos para permitir a implementação no System z, também poderemos usá-la da mesma maneira. Essa possibilidade pode ser encarada como suporte inerente para o hypervisor PowerVM integrado nos servidores Power, mas se tentarmos fazer o mesmo com um servidor x86, que não tem hypervisor integrado, existirá a mesma falta de restrição.

Figura 31. Hosting diretamente diversos sistemas operacionais
Hosting diretamente diversos sistemas operacionais

Visualização maior da Figura 31.

Essa maneira de fazer as coisas pode realmente ser útil se seu objetivo é produzir um diagrama rápido (como na Figura 31), mais do que um modelo real que garanta a consistência e verifique os recursos e requisitos. Para isso, teremos de implementar algum tipo de suporte a PowerVM, modelado a partir do que já existe para x86 e System z. Neste tutorial, usaremos conceitos de ambos:

  • Inicialmente, não usaremos NIC Virtual e Definições de disco, de modo que seguiremos o modelo do System z.
  • Usaremos uma Imagem Virtual, que está mais alinhada com o exemplo de VMware.

Criando a topologia inicial

Crie uma topologia chamada powervm_topology e acrescente a pilha base: um servidor do LDAP, uma instância AIX e um servidor Power exatamente como feito na seção sobre modelagem de implementações físicas. Hospedaremos o servidor do LDAP na instância AIX desta vez porque precisaremos fazer algumas mudanças primeiro, antes de implementar a unidade AIX . A Figura 32 mostra a topologia até esse ponto.

Figura 32. Topologia inicial
Topologia inicial

Visualização maior da Figura 32.

Customização de unidades existentes

Dê uma olhada na categoria de paleta Virtualization . Note que há unidades de "contêiner" para VMware, Xen e z/VM, e elas estão totalmente realizadas (elas têm uma unidade conceitual e uma concreta que realiza a conceitual). Também há uma seção de aparência genérica que, na maior parte, é apenas conceitual e não menciona nenhuma tecnologia específica. É o que usaremos. Esses modelos (Figura 33) usam as unidades e recursos base, independentes de tecnologia. Isso faz deles blocos de construção ideais para a meta de criar unidades específicas do PowerVM.

Figura 33. Paleta de modelos de virtualização
Paleta de modelos de virtualização

Visualização maior da Figura 33.

  1. Arraste e solte uma Imagem Virtualconceitual no diagrama. Note que aquilo que seria aviso em uma unidade concreta é apresentado como informação em uma conceitual.
  2. Agora dê uma olhada em Requirements dessa unidade conceitual. Essa unidade pode ter um servidor como membro (e apenas um, como se vê na restrição) e, opcionalmente, pode servir de host para qualquer quantidade de unidades, de qualquer tipo. Mas o que é mais relevante é o requisito de hosting: necessita de um hypervisor (genérico).
Figura 34. Requisitos de Imagem Virtual
Requisitos de Imagem Virtual

Visualização maior da Figura 34.

Em termos de Recursos, pode-se ver que essa unidade implementa uma Imagem Virtual e uma Virtual Server Definition. Os nomes dos recursos às vezes estão ligados a informações que ainda não foram fornecidas, e é por isso que o primeiro recurso aparece como no imageId. Analisar a informação Type: mostra os recursos referenciados, como se vê na Figura 35.

Figura 35. Recursos de Imagem Virtual
Recursos de Imagem Virtual

Visualização maior da Figura 35.

A próxima etapa será criar uma unidade concreta que possa ser usada para modelar LPARs de PowerVM.

  1. Desmarque Conceptual nas Properties de Imagem Virtual na guia General e acrescente um Stereotype chamado PowerVM LPAR. Esse estereótipo lhe permitirá ver rapidamente que essa unidade concreta é um tipo específico de Imagem Virtual.
Figura 36. Acrescentando estereótipos
Acrescentando estereótipos

Visualização maior da Figura 36.

  1. Agora, faça as seguintes mudanças:
    1. Exclua o requisito AnyMember . Não é removê-lo não faria muita diferença, mas vai deixar nossa unidade mais alinhada com outras imagens virtuais especializadas.
    2. Altere o Image id para PowerVM LPAR. O campo Image id também se encontra na guia Capabilities .
    3. Selecione o campo chamado no imageId e mude o campo apropriado na área de conteúdo à direita.
  2. Para tornar essa unidade reutilizável, nós a acrescentaremos à paleta:
    1. Dê um clique com o botão direito do mouse na unidade e selecione Add to Palette.
    2. Dê um nome (PowerVM LPAR) e um ícone

A (Figura 37) mostra que o ícone do LPAR do System z foi selecionado) e haverá uma nova entrada na categoria de paleta Local Extensions .

Figura 37. Acrescentando uma unidade customizada à paleta
Acrescentando uma unidade customizada à paleta

A próxima etapa será hospedar a nova unidade PowerVM LPAR no Power Server, mas se tentar fazer isso, não terá permissão. Isso ocorre porque a unidade LPAR precisa ser hospedada em um servidor com hypervisor e, por padrão, a unidade Power Server do Rational Software Architect não o tem. Em outras palavras, o PowerVM LPAR tem um requisito de hosting do tipo virtualization.Hypervisor e a unidade Power Server não fornece esse recurso.

Para corrigir isso, será necessário criar outra unidade customizada: um Power Server com recursos de hypervisor. Como alternativa, pode-se criar uma unidade PowerVM para ser implementada em uma unidade Power Server , como no cenário do VMware ESX, mas a opção de acrescentar a funcionalidade de hypervisor diretamente ao servidor reflete o fato de que, em Power Systems, o hypervisor não é um produto de software independente.

  1. Selecione a unidade Power Server , vá até a guia Capabilities e clique no ícone Add Capability... . Na janela pop-up que aparece, escolha Virtualization.Hypervisor (Figura 38).
Figura 38. Acrescentando o recurso de hypervisor
Acrescentando o recurso de hypervisor
  1. Deve-se também acrescentar um estereótipo de Servidor PowerVM . A designação não é estritamente correta, mas é curta o suficiente para ser útil para a finalidade deste tutorial. Adicione esse servidor à paleta seguindo as mesmas etapas acima. A Figura 39 mostra a área de trabalho após essas modificações.

Agora, pode-se hospedar o PowerVM LPAR no Servidor PowerVM.

Figura 39. Hosting do LPAR no servidor PowerVM
Hosting do LPAR no servidor PowerVM

Visualização maior da Figura 39.

Concluindo a topologia

Quando usar o servidor habilitado com hypervisor

Diferente do z/VM, os hypervisors do PowerVM não podem ser aninhados. Isso significa que, embora o z/VM possa hospedar uma cópia de z/VM, em Power Systems, um LPAR poderá ser host direto apenas de um sistema operacional. É por isso que se deve usar a unidade Power Server padrão dentro do PowerVM LPAR sob medida.

A próxima etapa é soltar um Power Server no diagrama e fazer dele um membro do PowerVM LPAR. Esse servidor será o que fornecerá hosting à sua instância AIX. Esse conceito é o mesmo que o explicado anteriormente e permite uma maneira muito mais fácil de modelar os cenários de transformação, porque os servidores físicos existentes podem ser agrupados dentro de um LPAR.

  1. Crie um link de hosting entre a unidade AIX e esse Power Server.

A topologia, mostrada na Figura 40, agora está concluída e sem avisos

Figura 40. Topologia final com todos os links de hosting em vigor
Topologia final com todos os links de hosting em vigor

Visualização maior da Figura 40.

Os conceitos usados são similares aos exemplos em x86 e System z, ou seja, no uso de três camadas separadas:

  • Um servidor físico que hospeda as diferentes imagens (o Servidor PowerVM)
  • Uma imagem virtual que representa a capacidade de divisão do host (o PowerVM LPAR)
  • Um servidor virtual que é membro da imagem virtual e fornece recursos de hosting (o Power Server dentro do LPAR)

O trabalho feito nesta seção é suficiente para modelar os principais aspectos da virtualização com PowerVM. A próxima seção acrescentará a capacidade de modelar mais detalhes, ou seja, recursos virtuais, como discos e placas Ethernet.


Recursos virtuais e PowerVM

O trabalho feito até agora já fornece uma forma funcional para modelar implantações de PowerVM. Nesta seção, daremos um passo além e implementaremos parte do comportamento encontrado no cenário VMware, ou seja, discos virtuais e NICs que representam os dispositivos virtuais configurados no HMC para serem usados pelo sistema operacional no LPAR.

Há dois pontos importantes que se deve levar em consideração:

  • Usar unidades genéricas como ponto de partida para novas unidades é extremamente flexível, rápido e fácil de gerenciar, mas o que se pode fazer fica limitado. Em especial, pode-se usar apenas recursos existentes. (O Rational Software Architect oferece maneiras de criar unidades e domínios, mas isto está além do escopo deste tutorial.) Pode-se usar essa abordagem, por exemplo, para acrescentar um recurso de Virtualization.PowerVMHypervisor mais adequados às suas necessidades. Para obter mais informações, veja o artigo do developerWorks Extending the topology editor with custom technology domains mencionado nos Recursos
  • Um dos melhores pontos do Rational Software Architect é o suporte ao desenvolvimento orientado por modelo. Isso significa que, em muitos casos, há suporte integrado para transformar diagramas em configurações reais que podem ser implementadas, mais ou menos da mesma forma em que cria arquivos de cabeçalho Java a partir de diagramas UML. Nossas customizações visam apenas fornecer um modelo coerente e não suportam funcionalidades avançadas, como a criação automática de arquivos de configuração HMC que configuram um servidor de acordo com nosso modelo.

Usaremos a mesma abordagem geral da seção anterior: pegar uma unidade conceitual genérica e customizá-la de acordo com suas necessidades. Será preciso usar estas duas definições:

  • Definição de Disco Virtual conceitual
  • Definição de NIC de Ethernet Virtual conceitual
  1. Usando a mesma topologia da seção anterior, acrescente uma Virtual Disk Definition conceitual ao diagrama e desmarque Conceptual , como antes. O resultado é um disco virtual genérico que pode ser hospedado em uma imagem virtual.
  2. Agora, acrescente um estereótipo chamado PowerVM Virtual Disk Def à unidade.

No ponto em que se encontra, esse disco virtual de PowerVM permitiria facilmente um relacionamento de hosting com, por exemplo, uma imagem virtual de VMware. É bom limitar a unidade a um tipo específico de imagem virtual, para que essa Definição de Disco Virtual de PowerVM recém-criada seja hospedada apenas por seu PowerVM LPAR sob medida.

Como já mencionado, o Rational Software Architect oferece modos de acrescentar novos recursos e domínios. Para os fins deste tutorial, no entanto, uma abordagem mais simples é suficiente, e uma possibilidade é utilizar estereótipos.

  1. Selecione Virtual Disk Definition que acabou de ser customizada e vá até a guia Requirements .
  2. Selecione o requisito HostingReq e vá até a guia Constraints .
  3. Para acrescentar a restrição, clique no sinal de mais verde no editor de restrições e selecione Stereotype na janela pop-up.
  4. Na caixa de diálogo que aparece, digite PowerVM LPAR nos campos Caption e Includes.
  5. Clique em Close ao concluir.

A Figura 41 mostra a restrição acrescentada.

Figura 41. Acrescentando restrições de hosting ao disco virtual
Stereotype (PowerVM LPAR) includes [POWERVM LPAR)]

Visualização maior da Figura 41.

  1. Agora, tente hospedar seu disco virtual no PowerVM LPAR.

Você verá que o link de hosting exibirá um erro (veja a Figura 42). O virtual de PowerVM LPAR não tem o estereótipo adequado.

Figura 42. Erro de hosting de disco virtual
Erro de hosting de disco virtual

A razão pela qual isso aconteceu é que a restrição especificada não foi feita em relação ao estereótipo da unidade de hosting e sim ao estereótipo de um recurso específico presente na unidade de hosting, ou seja, virtualization.VirtualServerDef.

  1. Usando a ação proposta pela caixa de diálogo de resolução de erro, acrescente o estereótipo ao recurso Virtual Server Definition na unidade PowerVM LPAR . (Veja a Figura 43.)
Figura 43. Acrescentando um estereótipo para satisfazer aos requisitos de hosting
Acrescentando um estereótipo para satisfazer aos requisitos de hosting

Visualização maior da Figura 43.

  1. Repita o processo com uma definição conceitual de NIC de Ethernet Virtual.

O resultado, mostrado na Figura 44, será bastante similar à topologia de VMware.

Figura 44. Topologia final com dispositivos virtuais
Topologia final com dispositivos virtuais

Com o acréscimo de dispositivos virtuais, as possibilidades de virtualização de PowerVM desenvolvidas no decorrer deste tutorial estão completas. A próxima seção dá um toque final que pode ser útil.


Exigindo um HMC

Como exercício final, faremos o Servidor PowerVM exigir um Hardware Management Console (HMC). Embora existam situações em que um HMC não é estritamente necessário, como em um servidor independente ou servidor com IVM, na prática e para nossos objetivos neste tutorial, vamos considerar o HMC um requisito.

  1. Usando a mesma topologia de antes, começaremos criando um HMC. O Hardware Management Console é um servidor x86 com uma versão customizada do Linux. Agora, já sabemos modelá-lo usando uma unidade de servidor x86 e uma unidade Linux.
  2. Inclua um estereótipo HMC no Servidor x86.
  3. Para tornar as coisas um pouco mais interessantes, mude a aparência da unidade para fazê-la se sobressair. Pode-se fazer isso usando a guia de propriedades Appearance e selecionando uma aparência diferente na lista.

A Figura 45 mostra o HMC em tons de verde.

Figura 45. Acrescentando um HMC
Acrescentando um HMC

Visualização maior da Figura 45.

Pode-se acrescentar uma pilha composta do servidor e do SO à paleta, se quiser. A paleta pode conter modelos compostos de várias unidades e relacionamentos.

É preciso fazer o Servidor PowerVM depender de, pelo menos, um HMC. Isso quer dizer que é necessário criar um requisito de dependência obrigatória na unidade do Servidor PowerVM.

  1. Na guia Requirements da unidade Servidor PowerVM , clique no ícone Add Requirement posicionado acima do editor de requisitos.
  2. Digite Needs HMC como valor de Caption, defina a Link type como dependency e configure Type para server.X86Server.

A Figura 46 mostra o requisito acrescentado.

Figura 46. Acrescentando o requisito à unidade PowerVM
Acrescentando o requisito à unidade PowerVM

Visualização maior da Figura 46.

  1. Esse requisito é definido em server.X86Server, que não é suficientemente específico. Portanto, acrescente uma restrição ao requisito Needs HMC para o estereótipo HMC .
Figura 47. Acrescentando uma restrição
Acrescentando uma restrição

Visualização maior da Figura 47.

Se tentar criar um link de dependência entre o Servidor Power VM e o HMC, aparecerá uma janela pop-up que mostrará a correspondência entre os requisitos e os recursos. Como se vê na Figura 48, não há 100% de correspondência entre o requisito especificado e os recursos da unidade HMC. O motivo é o mesmo das seções anteriores: a dependência é executada com base nos estereótipos de recurso, e não na própria unidade.

Figura 48. Correspondência entre requisitos e recursos
Correspondência entre requisitos e recursos

É preciso acrescentar o estereótipo HMC ao recurso server.X86Server do HMC.

  1. Vá até a unidade HMC , guia Capabilities , selecione o recurso x86 Server e acrescente um estereótipo HMC .
Figura 49. Acrescentando o estereótipo ao recurso de servidor
Acrescentando o estereótipo ao recurso de servidor

Visualização maior da Figura 49.

  1. Desta vez, use o ícone de aviso do Servidor PowerVM para criar o link de dependência. Clique no ícone de aviso daquela unidade.
  2. Quando aparecer a janela pop-up de aviso, como se vê na Figura 50, dê um clique duplo na ação proposta para criar um link de dependência com a unidade do servidor x86.
Figura 50. Criando um link de dependência
Criando um link de dependência

Agora seu modelo não contém erros.

A Figura 51 mostra a topologia em seu estado final. Nós a levamos por vários estágios, cada qual se baseando no anterior. Agora podemos usá-la para modelar não apenas LPARs, mas também dispositivos virtuais e requisitos de HMC.

Figura 51. A topologia final
A topologia final

Visualização maior da Figura 51.


Possibilidades adicionais

Isso conclui este tutorial. Agora temos unidades customizadas na paleta local que podem ser usadas com bons resultados na modelagem de implementações de PowerVM. Acima de tudo, devemos nos sentir mais confortáveis para customizar as unidades padrão do Rational Software Architect e adaptá-las a uma variedade maior de cenários.

Há muito mais que se pode fazer em termos de implementação do PowerVM, por exemplo:

  • Exigir mais de um HMC para fins de disponibilidade
  • Criar domínios e recursos completamente novos
  • Implementar algo para modelar servidores de E/S virtual
  • Aprender a modelar algo de forma semelhante ao modelo de alocação de CPU do System z

Neste tutorial, mal arranhamos a superfície do que se pode fazer com os recursos de modelagem de implementação. Explorar alguns dos tipos de links, por exemplo, revela inúmeras possibilidades em relação às regras de colocação e planejamento de capacidade.

As topologias de implementação do Rational Software Architect são simples de usar e customizar, mas também tem um uso muito claro e intuitivo. O sistema de Ajuda contém exemplos e tutoriais que ajudam a entender todos os usos potenciais. Explore aqui a seção de Recursos para começar a saber mais.


Download

DescriçãoNomeTamanho
RSA project file for this tutorialrsa_powervm.zip22KB

Recursos

Aprender

Obter produtos e tecnologias

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=Rational
ArticleID=654470
ArticleTitle=Recursos de modelagem de implementação do IBM PowerVM para virtualização
publish-date=07292013