A introdução da família de produtos IBM® PureSystems™ eleva a computação em nuvem a novos níveis. O IBM PureSystems — no formato do IBM PureApplication™ System e do IBM PureFlex™ System— é um sistema da nuvem integrado e especialista que compreende aplicativos, serviços, hardware e até mesmo o conhecimento — entregue na forma de padrões de melhores práticas — a fim de integrar, implementar e manter um ambiente da nuvem de nível corporativo.

A arquitetura do IBM PureApplication System suporta três modelos de cargas de trabalho, três tipos diferentes de cargas de trabalho usados para entregar soluções da nuvem:

• O uso de padrões de aplicativo virtual por meio de serviços da plataforma de carga de trabalho. Um aplicativo virtual representa uma coleta de componentes de aplicativo, políticas comportamentais e seus relacionamentos. Usando essa definição centralizada em aplicativo da carga de trabalho, o IBM PureApplication System construirá automaticamente os recursos de infraestrutura e middleware necessários para fornecer e gerenciar continuamente este aplicativo virtual.
  
  
• O uso de padrões de sistema virtual por meio de serviços de middleware virtualizados. Padrões de sistema virtual são uma representação lógica de uma topologia recorrente para um determinado conjunto de requisitos de implementação. Por exemplo, um padrão WebSphere® Application Server Cluster que contém o IBM Deployment Manager, um ou mais nós customizados, o IBM Http Server e scripts de configuração para instalar aplicativos na topologia. Usando essa abordagem, a configuração detalhada do middleware é definida explicitamente e o IBM PureApplication System fornecerá o sistema exato definido neste padrão de sistema virtual.
  
  
• O uso de dispositivos virtuais por meio de serviços de infraestrutura virtualizados. Um dispositivo virtual representa uma única instância de carga de trabalho do servidor, que consiste em um ambiente do sistema operacional pré-configurado, incluindo elementos de middleware e aplicativos pré-instalados necessários em uma imagem de Formato Aberto de Virtualização.

A comunidade do developerWorks fornecerá os recursos para explicar esses elementos; neste artigo, discutiremos um desses principais componentes e como ele afeta o padrão de sistema virtual — dos padrões de TI.

O panorama completo

Basicamente, o IBM PureApplication System possui hardware e software integrados que combinam cargas de trabalho virtualizadas e infraestrutura escalável. Incluído como suporte a middleware para dados e tempo de execução com os recursos de implementação e gerenciamento que simplificam e aceleram essas atividades, tornando-as mais eficientes.

Os padrões de sistema virtual são focados nas camadas de middleware do sistema definindo topologias repetidas e implementáveis que podem ser compartilhadas. Os blocos de construção fundamentais dos padrões de sistema virtual são partes entregues com imagens virtuais. Essas partes, juntas com parâmetros de configuração, scripts e complementos, são usadas para criar padrões complexos que são implementados como uma única unidade.

Reduzir o tempo de implementação, aumentar a consistência e promover a agilidade são benefícios que seriam esperados ao explorar abordagens com base em nuvem para seus ambientes de aplicativos de middleware. A solução do IBM PureApplication System, criada com base no IBM Workload Deployer e em outras tecnologias, enfrenta esses problemas tornando a implementação de ambientes de middleware da nuvem rápida, repetida e eficiente.

A abordagem com base em padrão é a base do IBM PureApplication System e é consistente para os padrões de aplicativo virtual e padrões de sistema virtual. Usando o dispositivo da nuvem, padrões são criados e implementados, representando seus ambientes de aplicativos completamente configurados. Quando estiver pronto para usar um ambiente de aplicativo particular, basta escolher um padrão e implementá-lo. O IBM PureApplication System automatiza a implementação, configuração e integração de várias máquinas virtuais que compõem seu ambiente e entrega o produto completo em questão de minutos.

Voltar para parte superior

Os elementos e funções de um padrão de sistema virtual

Conforme comentado anteriormente, padrões de sistema virtual (também conhecidos como padrões de topologia) representam definições de topologia repetidas com base em várias imagens virtuais de middleware e em configurações de tempo de execução. Os padrões de sistema virtual fornecem flexibilidade e controle sobre a topologia de middleware a ser implementada.

Anatomia de um padrão de sistema virtual

A Figura 1 mostra uma visão geral de como é possível criar um padrão de sistema virtual a partir de componentes no catálogo:

Os sistemas virtuais que consistem em uma ou mais partes de imagem virtual são um modelo de implementação de base do IBM PureApplication System. Um sistema virtual é definido no IBM PureApplication System por meio de um padrão de sistema virtual, uma unidade que pode ser fornecida por uma ou mais imagens virtuais a serem instaladas, configuradas e integradas a fim de implementar uma topologia.

Os padrões de sistema virtual podem ser tão simples quanto uma única instância do produto de servidor ou tão complexos quanto uma implementação multinós de diversos produtos.

Os padrões de sistema virtual de melhor prática fornecidos pela IBM vêm pré-carregados no dispositivo; o auge de anos de experiência no trabalho com nossos clientes para entender a configurações ideais. Quando um padrão de sistema virtual for fornecido pelo IBM PureApplication System, é mencionado como uma instância de sistema virtual.

Os padrões de sistema virtual podem ser customizados ou novos padrões podem ser criados usando o Editor de Padrão na interface do usuário do sistema IBM PureApplication System. A customização no Editor de Padrão é alcançada usando uma interface simples de arrastar e soltar de uma paleta de partes (entregue a partir de imagens virtuais), pacotes de scripts e complementos.

Um padrão de sistema virtual geralmente consiste em um ou mais elementos de middleware que trabalham juntos para fornecer a plataforma necessária para um aplicativo completo. Um exemplo de um padrão de sistema virtual para uma configuração do WebSphere® pode conter diversas partes, cada uma representando uma máquina virtual que inclui um sistema operacional Linux® com o WebSphere Application Server ou outro software de middleware pré-instalado e possibilitado para ativação. O padrão pode incluir um gerenciador de implementação, vários nós customizados, um banco de dados do DB2® e um servidor HTTP da IBM.

O uso de um padrão de sistema virtual oferece mais controle sobre a topologia de controle, mas também requer a configuração do middleware para suas necessidades de aplicativos específicas. Os pacotes de scripts podem ser incluídos no padrão para automatizar a customização adicional da topologia de sistemas virtuais; por exemplo, um pacote de scripts para criar recursos do WebSphere e instalar um aplicativo.

Quando um padrão de sistema virtual for implementado, o dispositivo cria a topologia, constrói os relacionamentos entre os componentes (por exemplo, federando os nós customizados no gerenciador de implementação) e configura o middleware com base nos pacotes de script fornecidos. Os administradores do sistema podem efetuar login no sistema para executar customização adicional, se necessário, — mas a melhor prática é fornecer a configuração completa do sistema no padrão usando customizações de imagem, parâmetros, complementos e scripts de automação para criar um padrão que pode ser implementado de forma consistente na nuvem.

A capacidade de integrar aspectos padrão de alta disponibilidade e tolerância a falhas está contida na topologia.

Com um padrão de sistema virtual, é definido o tipo exato de configuração de middleware de que precisa para seu ambiente de aplicativos e o IBM PureApplication System fornece exatamente essa configuração quando o padrão é implementado em sua nuvem privada.

Já comentamos sobre os blocos de construção de um padrão de sistema virtual, mas examinaremos um esses itens com um pouco mais de detalhes.

Partes contidas nas imagens de edição do hypervisor

Os blocos de construção mais fundamentais para padrões de sistema virtual são partes entregues com imagens de edição do hypervisor. Portanto, as questões lógicas são

• O que é uma imagem de edição do hypervisor?
• O que é uma parte?

O que é uma imagem de edição do hypervisor?
Em suma, uma imagem de edição do hypervisor é uma entrega de alguns produtos de middleware compactados de acordo com o Open Virtualization Format (OVF) em um arquivo Open Virtualization Archive (OVA). Essas imagens são importadas em um catálogo de imagem virtual no IBM PureApplication System Application Services.

Uma imagem de edição do hypervisor consiste em alguns produtos de middleware, como o WebSphere Application Server, que são pré-instalados e pré-configurados junto com um sistema operacional (normalmente o Linux) e especificamente designados para ambientes virtuais. Por exemplo, para o WebSphere Application Server, normalmente mostramos a composição da imagem virtual como um sistema operacional, binários WebSphere Application Server e Servidor HTTP da IBM e perfis do WebSphere Application Server junto com o "tempero especial".

Ok, o que é esse tempero especial? É uma combinação de código e ajuste construída na imagem para otimizar o WebSphere Application Server para um ambiente virtual.

Os principais elementos da imagem da edição do hypervisor incluem:

• Imagem pré-instalada e pré-configurada
• Ajuste específico à imagem
• Recursos de ativação de tempo de implementação rápido

Pré-instaladas significa que todos os elementos, sistema operacional, middleware, dependências de middleware e feature packs e manutenção necessária para todos os elementos pré-instalados na imagem. Não é necessário instalar o middleware ou sistema operacional; ou desenvolver um script para fazer isso; — é tudo manipulado automaticamente usando a imagem de edição do hypervisor.

Como a IBM está pré-instalando o middleware e o sistema operacional subjacente, a imagem é especificamente ajustada para melhores práticas e desempenho ideal em um ambiente virtual. Além de ser rápida como um raio ao implementar imagens, porque a instalação a otimização foram feitas antecipadamente. Tudo que é necessário fazer durante a implementação é refinar a configuração e executar alguma lógica de ativação. A manutenção também é simplificada, porque está disponível como imagens completamente instaladas para a solução completa.

O que é uma parte?
Os elementos do middleware são entregues na imagem do hypervisor como partes. Por exemplo, a imagem de edição do hypervisor do WebSphere Application Server inclui partes para o gerenciador de implementação, nó customizado, nó independente, gerenciador de tarefa e assim por diante. Ter esses perfis comuns pré-configurados na imagem novamente economiza tempo significativo de implementação em comparação com processos tradicionais de implementação no qual a criação de perfil é feita posteriormente por scripts.

A configuração de middleware detalhada e o fornecimento para fins específicos são tratados por um agente de ativação. Embora a pré-instalação, a configuração e o ajuste sejam bons, é possível considerar a ativação do "ingrediente secreto" real na imagem de edição do hypervisor.

Para o WebSphere, os recursos de ativação suportam que esta única imagem transforme-se em diferentes configurações do WebSphere Application Server quando inicializada inicialmente. Isso permite que uma imagem de modelo seja copiada e rapidamente reconfigurada para um fornecimento muito rápido de diferentes ambientes do WebSphere Application Server. Isso é feito por meio de um código de ativação incluído na imagem que lê parâmetros de entrada, mapeia esses parâmetros para diferentes perfis pré-configurados e executa a reconfiguração.

Especificamente, durante a ativação, os scripts de reconfiguração dentro da imagem inserem as novas configurações de rede (endereço IP, nome do host, senhas e assim por diante); reconfigure os parâmetros do WebSphere Application Server para nome de célula, nome de nó e assim por diante; e inicie o perfil do WebSphere Application Server correspondente ao tipo de servidor. A substituição ou inserção dos metadados de configuração para ambos os perfis de OS e do WebSphere Application Server fornece uma economia de tempo significativa. A ativação permite que uma imagem assuma e se ajuste rapidamente para novas configurações de rede, senhas e personalidades do WebSphere Application Server, dos gerenciadores de implementação a nós customizados e gerenciadores de tarefas.

As partes são os blocos de construção primários de qualquer padrão de sistema virtual. Entretanto, há outros elementos fundamentais de um padrão de sistema virtual que são necessários para suportar a customização detalhada, isto é, pacotes de scripts e complementos.

Pacotes de scripts
Em padrões de sistema virtual do IBM PureApplication System, um pacote de scripts é seu veículo para fornecer uma configuração de middleware customizada.Isso pode significar a instalação de aplicativos, a configuração de dependências de aplicativos ou, de outra forma, o ajuste da camada de middleware.

Pacotes de scripts são basicamente arquivos ZIP que incluem alguns executáveis (shell script, script wsadmin, programa Java™ , etc.) e, opcionalmente, artefatos que suportam a execução do script. Como pode ver, não há um formato singular obrigatório para um script. Você verá que pode reutilizar muitos dos scripts que tem usado em suas implementações tradicionais.

Como era a intenção, é possível alcançar o que deseja com um pacote de scripts. Isso permite que você seja tão flexível e criativo quanto necessário. Os scripts podem ser parametrizados para que a configuração de tempo de implementação possa ser fornecida. Isso permite que um script comum seja aplicado para muitos fins em muitas partes. Os scripts são importados no catálogo de scripts do IBM PureApplication System e podem ser associados a partes contidas em padrões de sistema virtual.

Complementos
Os complementos são scripts especializados para customizar a configuração da máquina virtual. Complementos permitem modificar a configuração da máquina virtual durante a implementação sem a necessidade de modificar e salvar uma nova configuração da imagem. É possível usar complementos para aumentar a configuração de hardware e de sistema operacional de uma máquina virtual.

Os complementos simplificam em grande parte a tarefa de realizar mudanças na configuração do OS em nível mais baixo. Por exemplo, com o complemento de disco Incluir, só é necessário arrastar e soltar o complemento da paleta do Editor de Padrão para a parte apropriada e configurar os parâmetros.

Você usa complementos, como scripts customizados: você os cria e os clona no catálogo de dispositivos conforme necessário e, em seguida, arrasta-os para partes no Virtual System Pattern Editor. A principal diferença é que os complementos são executados antes de qualquer script personalizado e têm como alvo a configuração da máquina virtual.

Entretanto, embora os complementos sejam como scripts, há diferenças significativas. Primeiro, complementos não são listados com os scripts personalizados. Eles têm sua própria categoria no catálogo. Complementos são executados antes de quaisquer scripts personalizados para uma parte no momento da implementação. Diferentemente de scripts personalizados, não é possível especificar a ordem de execução do complemento em uma parte. Os complementos são executados somente durante a criação do sistema; não é possível iniciá-los sob demanda. Eles são APIs em nível de hypervisor para configurar o novo hardware em máquinas virtuais durante a implementação.

Visualizações e partes de edição do padrão de sistema virtual

Falaremos um pouco sobre os padrões de sistema virtual criados a partir desses elementos. O IBM PureApplication System é enviado com um número de padrões de sistema virtual predefinido que representa as melhores práticas derivadas de anos de experiência no trabalho com os clientes. Esses padrões representam configurações comuns de ambientes do WebSphere simples a avançados, várias configurações do DB2® para Enterprise e Express, WebSphere Portal, WebSphere Message Broker, WebSphere MQ e muitas outras topologias.

Os padrões predefinidos podem se adequar exatamente às suas necessidades e é possível implementá-los sem qualquer mudança. Entretanto, é mais provável que deseje clonar e estender esses padrões ou criar seus próprios padrões do zero. Agora, trataremos da mecânica de editar e criar padrões de sistema virtual.

A janela Padrões
Quando selecionar um padrão de sistema virtual para editar na janela Padrão, é possível ver informações detalhadas sobre o padrão de sistema virtual. Uma visualização da topologia para o padrão é implementada no painel direito da janela Padrão.

A topologia para um padrão de sistema virtual está descrita graficamente para fins de edição; partes de imagem virtual, complementos e pacotes de scripts podem ser soltos na tela de edição para criar ou alterar relacionamentos entre as partes que definem a topologia. Tudo isso é feito no Editor de Padrão.

A janela Editor de Padrão
Ao clicar no ícone de edição no painel direito superior da janela Padrões, a janela Editor de Padrão é aberta para o padrão de sistema virtual selecionado. A janela Editor de Padrão fornece listas para selecionar partes de imagem virtual, complementos e pacotes de scripts.

Partes da imagem virtual
A seleção da lista Partes no Editor de Padrão fornece uma listagem das partes que podem ser soltas na tela de padrão do sistema virtual. A tela do padrão de sistema virtual está no painel direito da janela Padrão. Algumas partes da imagem virtual comum incluem:

• Agentes administrativos
• Nós customizados
• Gerenciadores de implementação
• Servidores HTTP
• Gerenciadores de tarefa
• Servidores independentes
• Roteadores sob demanda
• Servidores DB2
• entre outros...

As partes são determinadas pelas imagens virtuais que estão sendo usadas. Algumas partes de imagem virtual representam diversas instâncias; há um badge na tela de edição que indica o número de instâncias de cada parte.

É possível configurar as propriedades da parte ao implementar o padrão de sistema virtual ou diretamente da parte na implementação do editor de padrão. Para configurar a parte antes de implementá-la, clique no ícone Editar Propriedades para a parte na tela de edição. A seleção para bloquear uma propriedade evitará mudanças nela durante a implementação.

Pacotes de scripts
A lista Scripts no Editor de Padrão fornece uma listagem dos pacotes de scripts que podem ser soltos nas partes da imagem virtual. Essa lista pode conter pacotes de scripts associados à imagem virtual e qualquer uma que tiver sido definido para uso com o IBM PureApplication System.

Complementos
Complementos comuns podem ser incluídos em partes na tela de edição, como:

• Disco de inclusão padrão: inclui um disco virtual na máquina virtual e, opcionalmente, formata e monta o disco.
• NIC de inclusão padrão: inclui um controlador de interface de rede virtual (NIC) na máquina virtual, configura informações de endereço IP para ele e o ativa.
• Usuário de inclusão padrão: define um usuário adicional à máquina virtual.
• Disco rígido de inclusão padrão: inclui um disco virtual à máquina virtual, mas não formata nem monta o disco.

Versões customizadas de tipos de complemento também podem ser criadas e disponibilizadas para atender às suas necessidades e incluídas no catálogo. Um complemento pode ser criado do zero ou clonado e modificado do conjunto padrão.

Interação entre partes da imagem virtual
As partes da imagem virtual podem ser definidas para interagir com outras partes também da imagem virtual. Quando as partes interativas da imagem virtual são incluídas no mesmo padrão de sistema virtual, o resultado é a configuração cruzada. Por exemplo, quando um nó customizado e um gerenciador de implementação estão posicionados no mesmo padrão de sistema virtual, eles são automaticamente configurados de forma cruzada. Isso resulta no nó customizado que está sendo federado ao gerenciador de implementação. Da mesma forma, os agentes administrativos (ou gerenciadores de implementação) são registrados com um gerenciador de tarefa.

Partes da imagem virtual podem ser configuradas de forma cruzada se o editor de padrão do sistema virtual puder determinar um relacionamento exclusivo. Caso não seja possível, não ocorrerá nenhuma configuração cruzada. Por exemplo, se um nó customizado for incluído em um padrão de sistema virtual com dois gerenciadores de implementação, não ocorrerá nenhuma federação. Entretanto, se um dos gerenciadores de implementação for removido posteriormente, a configuração cruzada ocorrerá, pois agora existe um relacionamento exclusivo.

É possível usar o indicador de versão nas partes para assegurar que estejam fazendo referência à mesma versão de imagem virtual no catálogo. Se a versão de uma parte estiver incorreta, será possível alterá-la quando a parte estiver na tela de edição. Passar o mouse sobre o nome da parte abre uma janela com informações adicionais sobre a imagem virtual.

Voltar para parte superior

Desenvolvendo um padrão de sistema virtual

É possível desenvolver um padrão de sistema virtual criando um do zero ou clonando um existente.

Clonando um padrão de sistema virtual customizável

Primeiro, selecione o padrão preexistente que mais de adéqua às suas necessidades. (Aqui estão alguns padrões do IBM Workload Deployer.)

É tão simples quanto pressionar um botão para clonar e renomear o padrão. Então, é possível customizar o clone na janela Editor de Padrão incluindo, removendo, editando partes; inclua ou remova pacotes de scripts ou complementos; configure propriedades para partes; configurer parâmetros para pacotes de scripts; configure partes como ordem de inicialização; etc.

`Para saber mais sobre esta etapa, consulte "Cloning an existing virtual system pattern."

Criando um padrão de sistema virtual

Surpresa! Este método é tão fácil quanto o método de clonagem; neste caso, a primeira etapa é incluir um novo padrão. As mesmas etapas são percorridas, como se fosse clonar um padrão de sistema virtual.

Para saber mais sobre esta etapa, consulte "Creating a virtual system pattern."

Sempre que possível, tente reutilizar os padrões de sistema virtual predefinidos ou usá-los como um ponto de início. Isso pode economizar tempo substancial e caso não deseje nenhuma customização, ele evitará que tenha de manter versões customizadas desses padrões.

Voltar para parte superior

Usando um padrão de sistema virtual

Você pode estar se perguntando "quais condições atendem o uso de um padrão de sistema virtual do IBM PureApplication System em relação a um padrão de aplicativo virtual?" Neste caso, definiremos melhor a questão para que faça mais sentido.

Basicamente, os padrões de sistema virtual são semelhantes aos padrões de aplicativo virtual, pois ambos representam modelos de um aplicativo virtualizado para implementação na nuvem. Quando nos referimos a padrões no contexto da nuvem, estamos nos referindo ao encapsulamento de atividades de instalação, configuração e integração e facilita a implementação e o gerenciamento de ambientes em uma nuvem muito mais fáceis. Independentemente de que tipo de padrão acabará usando, você se beneficia em tratar um ambiente de infraestrutura de middleware ou aplicativo middleware possivelmente complexo como uma única unidade atômica por todo seu ciclo de vida de criação, implementação e gerenciamento.

Começaremos considerando o continuum de troca da nuvem a fim de entender as diferenças entre as implementações de padrão do aplicativo e dos sistemas. (Novamente, usamos o IWD já que é a tecnologia anterior imediata e temos muitos dados e experiência em seu uso.)

• O eixo X representa o grau no qual possui controle de customização sobre o ambiente resultante. O grau de controle é reduzido conforme você se move da esquerda para a direita.
• O eixo Y representa o custo total de propriedade (TCO) que diminui conforme você move o eixo para cima.
• O eixo Y direito representa o tempo de maturação que, da mesma forma, diminui conforme você move o eixo para cima.

Naturalmente, as empresas desejam mover o eixo Y para cima, no entanto, às vezes, hesitam em ceder muito controle (mover para a direita no eixo Y) para atingir esse objetivo.

Com o que esta figura mostra como um ponto de referência, comece a pensar um pouco mais sobre as duas abordagens baseadas em padrões.

Cenário: Usando um padrão de sistema virtual

Considere um aplicativo de serviço da web relativamente simples que deseja implementar na nuvem. Se fosse usar um padrão de sistema virtual para alcançar isso, você provavelmente começaria usando partes da imagem do WebSphere Application Server Hypervisor Edition para exibir a topologia. Você pode incluir um gerenciador de implementação, dois nós customizados e um servidor da web.

Após estabelecer a topologia, você incluiria pacotes de scripts customizados para instalar o aplicativo de serviço da web e configuraria quaisquer recursos dos quais o aplicativo depende. Os usuários que desejavam implementar o padrão de sistema virtual acessariam, forneceriam detalhes de configuração como o nome da célula, nomes de nó, alocação de recurso virtual e parâmetros de script customizados do WebSphere Server, e em seguida, implementariam.

Uma vez implementado, os usuários poderiam acessar o ambiente e a infraestrutura de middleware como sempre. Isso significa que eles poderiam executar scripts administrativos, acessar o console administrativo fornecido pelo software de middleware implementado e qualquer outra coisa que normalmente desejariam executar.

Mesmo cenário: Usando um padrão de aplicativo virtual

O uso de um padrão de aplicativo virtual para suportar o mesmo aplicativo de serviços da web resultaria em uma experiência notadamente diferente de um ponto de vista de implementação e gerenciamento.

Ao usar a abordagem padrão de aplicativo virtual, um usuário começaria selecionando um tipo de padrão de aplicativo virtual baseado no tipo de aplicativo. Este pode ser um tipo de padrão enviado pela IBM, como o Pattern for Web Applications, ou pode ser um criado pelo usuário por meio de mecanismos de extensibilidade criados no dispositivo.

Após selecionar o padrão apropriado, um usuário forneceria o aplicativo de serviço da web, definiria requisitos funcionais e não funcionais para o aplicativo por meio de políticas e, em seguida, implementaria.

O padrão de aplicativo virtual e o IBM PureApplication System fornecem o conhecimento necessário para instalar, configurar e integrar a infraestrutura de middleware e o próprio aplicativo. Uma vez implementado, um usuário gerencia o ambiente de aplicativos resultante por meio de uma ótica radicalmente simplificada fornecida pelo IBM PureApplication System. Ele fornece monitoramento e gerenciamento contínuo do ambiente em um contexto apropriado para o aplicativo.

Isso significa que normalmente não há consoles administrativos e os usuários podem somente alterar aspectos bem definidos do ambiente. É uma mudança substancial na ideia de implementar e gerenciar aplicativos middleware.

Então, como eu decido?

O ponto principal é, quando você implementa um software usando um padrão de sistema virtual, para a maior parte, você gerencia o ambiente da mesma forma como sempre gerenciou para esse tipo específico de software; normalmente por meio de consoles administrativos. Com os padrões de sistema virtual, você não foca na alteração do modo como opera ou gerencia o software; em vez disso, você primeiramente foca na melhoria da entrega do dito software.

Com padrões de aplicativo virtual, você basicamente altera tudo sobre esses ambientes. Está trabalhando com uma solução altamente otimizada e automatizada. O fardo de gerenciar a alta disponibilidade e reagir dinamicamente a condições em mudança é criado na solução de tipo de padrão para que precise somente especificar seus requisitos de nível de negócios. O gerenciamento e as operações desse ambiente são completamente integrados na interface do usuário do IBM PureApplication System. Tudo está integrado e altamente especializado para o tipo de aplicativo específico.

É preciso basear sua decisão em seus requisitos e necessidades de gerenciamento para o aplicativo específico que está sendo considerado.

Para cada aplicativo, é necessário decidir se favorece a abordagem centralizada em infraestrutura middleware de padrões de sistema virtual ou se prefere a abordagem centralizada em aplicativo de padrões de aplicativo virtual. É possível ser orientado pela necessidade de suportar configurações muito específicas que não se encaixam facilmente em um tipo de padrão virtual já disponível. Nesse caso, você pode escolher criar seu próprio tipo de padrão de aplicativo virtual ou usar um padrão de sistema virtual para criar a topologia exata que seu aplicativo requer — talvez replicando um ambiente físico que tenha sido implementado anteriormente. Em outros casos, você deve achar que seu aplicativo se adéqua bem a um dos tipos de padrão de aplicativo virtual que já estão fornecidos.

Sempre que possível, você deve buscar utilizar a otimização e conveniência de um padrão de aplicativo virtual já que este sempre fornecerá o custo total de propriedade mais baixo e o tempo de maturação mais curto. Entretanto, certamente haverá cenários em que você exigirá configurações muito detalhadas e, portanto, decidirá a favor do controle detalhado que está disponível com padrões de sistema virtual.

A coisa mais importante é entender todas as opções e tomar uma decisão informada. Observe seu caso de uso, entenda o que está disponível para ajudá-lo a realizar esse caso de uso e, finalmente, decidir sobre como deseja que a experiência de seu usuário seja.

Por fim, também é importante observar que o IBM PureApplication System suporta ambos os modelos simultaneamente. É possível ter uma combinação de aplicativos virtuais, sistema virtual e até mesmo dispositivos virtuais, todos implementados no mesmo conjunto de recursos da nuvem. Os recursos mais sólidos criados no IBM PureApplication System possibilitam essa variedade de implementações, permitindo que escolha o modelo de implementação para cada aplicativo oferecer a melhor adequação com o mais alto retorno sobre o investimento.

Voltar para parte superior

Conclusão

Apresentamos os padrões de sistema virtual e seu local no ecossistema do IBM PureApplication System (bem como de que forma eles são comparados e estão em contraste com padrões de aplicativo virtual); também descrevemos componentes de padrão de sistema virtual e funções e fornecemos uma visão básica de como criar e usar um padrão de sistema virtual.

Para obter mais experiência na implementação da nuvem centralizada em padrão, consulte as comunidades associadas, fóruns, artigos e vídeos na seção Recursos.

Recursos

Aprender

• Saiba mais sobre o IBM PureSystems.
  
  
• Encontre Recursos do IBM PureSystems no developerWorks
  
  
• Para saber mais sobre como realizar tarefas na nuvem IBM, visite estes recursos:
  • Faça upload e download de arquivos a partir de uma instância do Windows.
  • Instale o servidor da web IIS no Windows 2008 R2.
  • Crie uma instância da nuvem IBM com a linha de comando do Linux.
  • Crie uma instância da nuvem IBM com a linha de comando do Windows.
  • Estenda a sua rede corporativa com a nuvem IBM.
  • Aplicativos de alta disponibilidade na nuvem IBM.
  • Parametrize imagens de nuvem para instâncias customizadas dinamicamente.
  • Abordagens focadas no Windows para fornecimento na nuvem IBM.
  • Implemente produtos usando o serviço de implementação rápida.
  • Integre a política de autenticação usando um proxy.
  • Configure o Linux Logical Volume Manager.
  • Implemente uma topologia complexa usando uma ferramenta de utilitário de implementação.
  • Forneça e configure uma instância que envolve uma VLAN pública e privada.
  • Proteja o acesso à nuvem IBM para dispositivos Android.
  • Recupere dados no IBM SmartCloud Enterprise.
  • Proteja instâncias de máquina virtual na nuvem.
  
  
• Na seção recursos de desenvolvedor da nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão desenvolvendo os seus projetos de implementação de nuvem.
  
  
• Descubra como acessar o IBM SmartCloud Enterprise; o desenvolvimento no SmartCloud é uma ótima forma de praticar o desenvolvimento para IBM PureSystems.
  
  

Obter produtos e tecnologias

• Consulte os as imagens do produto disponíveis para o IBM SmartCloud Enterprise.
  
  

Discutir

• Faça parte de um grupo de computação em nuvem no developerWorks.
  
  
• Leia todos os excelentes blogs sobre nuvem no developerWorks.
  
  
• Faça parte da comunidade do developerWorks, uma rede profissional e conjunto unificado de ferramentas comunitárias para conectar, compartilhar e colaborar.
  
  

Sobre os autores

Bobby McChesney é Advisory Software Engineer no IBM Software Group com 23 anos de experiência na IBM. Seu foco atual é em Application and Integration Middleware e IBM Workload Deployer.

Joe Bohn é Engenheiro de Software Sênior atualmente trabalhando como propagador técnico de tecnologias emergentes do WebSphere. Anteriormente, ele trabalhou em projetos de software livre envolvendo Apache Aries, Apache Geronimo e WebSphere Community Edition. Joe começou sua carreira na IBM em 1985 como programador de sistemas CICS e ocupou várias posições de desenvolvedor e arquiteto em uma variedade de áreas, incluindo WebSphere Portal e Tivoli.

James Kochuba atualmente é Support Staff Engineer do WebSphere Application Server e chefe técnico de equipe do pessoal de suporte IBM cujo foco é o WebSphere Extended Deployment e WebSphere Application Server. Essa função requer foco nos problemas do cliente para ajudar a orientar engenheiros de suporte e clientes em direção à identificação da origem do problema e sua resolução final.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• O panorama completo
• Os elementos e funções de um padrão de sistema virtual
• Desenvolvendo um padrão de sistema virtual
• Usando um padrão de sistema virtual
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais