Desenvolva um Padrão de Sistema Virtual

Considerações-chave para planejamento e desenvolvimento de seu padrão de sistema virtual

Os padrões de sistema virtual no IBM® PureApplication™ System possibilitam implementações rápidas e repetidas de sistemas desde máquina virtual até o aplicativo. Com um padrão de sistema virtual, as tarefas manuais necessárias para criar toda sua topologia pode ser completamente automatizada, o que permite que um aplicativo seja implementado em minutos em vez de horas ou dias. A implementação do middleware orientada a padrões elimina erros introduzidos por processos de configuração manual propensos a erros e permite que as melhores práticas sejam preparadas em padrões, acelerando e otimizando, assim, a implementação de soluções. Neste artigo, os autores destacam os pontos principais para revisão ao desenvolver um padrão de sistema virtual.

Nauman Fakhar, Senior Solutions Architect, IBM

Nauman Fakhar é Senior Solutions Architect na equipe de laboratórios do IBM Cloud no Vale do Silício. Em sua função atual, Nauman ajuda clientes e parceiros de negócios IBM com a estratégia e soluções da nuvem. Antes de fazer parte da equipe de laboratórios da nuvem, Nauman ocupou cargos em startups e na equipe de vendas e consultoria mundial do WebSphere da IBM.



Giuseppe Accardo, Senior Technology Consultant, IBM

Giuseppe Accardo é Senior Technology Consultant no IBM Innovation Center em Foster City, no Vale do Silício. A principal função de Giuseppe é divulgar as tecnologias de computação em nuvem e ajudar os parceiros de negócios IBM e seus clientes a integrarem suas soluções ao portfólio de software e hardware da IBM. Giuseppe trabalhou para a marca Tivoli no gerenciamento de datacenter inteligente e participa da equipe mundial do IBM PureApplication System.



30/Abr/2012

Os padrões de sistema virtual automatizam completamente a implementação de aplicativos e plataformas complexos enquanto aproveitam as melhores práticas, portanto, a função técnica mais importante na implementação do padrão de sistema virtual é a do implementador de aplicativos.

O implementador de aplicativos é o especialista no assunto em:

  • Identificar pré-requisitos do aplicativo (hardware e software).
  • Entender a arquitetura de solução a partir da perspectiva de alta disponibilidade, escalabilidade, failover e tolerância a falhas.
  • Aplicar as melhores práticas para a implementação do aplicativo e entender os gargalos de instalação e configuração.
  • Instalar todos os componentes do aplicativo.
  • Criar scripts da instalação do aplicativo (usando shell, Jython, scripts DDL).
  • Administrar produtos de middleware e software pré-requisitos.
  • Executar testes funcionais básicos no aplicativo.

O ideal é que o implementador de aplicativo tenha experiência anterior suficiente em instalação, implementação e configuração para identificar os pontos de contato de automação das principais tarefas manuais e também integrar as melhores práticas do segmento de mercado. Por exemplo, se a maioria dos clientes ou usuários forem executados com um tamanho de heap da™ máquina virtual (JVM) Java específica no WebSphere®, essa configuração deve ser integrada ao padrão.

Vamos, então, analisar algumas sugestões sobre o processo de planejamento e desenvolvimento de um padrão de sistema virtual; tentaremos fornecer comentários úteis em cada ponto. Os tópicos abordados incluirão:

  • Principais conceitos no design de VSP, como elasticidade, topologia, orquestração e segurança.
  • Alguns dos aspectos técnicos importantes ao implementar um padrão de sistema virtual:
    • Identificar e mapear tempos de execução para componentes do padrão.
    • Incorporar componentes nativos em seu padrão.
    • Reutilizar ativos existentes, como scripts e conjunto de ferramentas.
    • Dimensionar discos virtuais.
  • Três formas de estender as funcionalidades do catálogo de imagem base disponível no IBM PureApplication System utilizando pacotes de script, conjunto de ferramentas integrado de extensão/captura e Image Construction and Composition Tool (ICON).
  • Melhores práticas na abordagem iterativa ao desenvolvimento de padrão e teste.

Principais conceitos do design do padrão

Revise estes conceitos ao projetar e desenvolver um padrão de sistema virtual:

  • Elasticidade
  • Topologia
  • Orquestração
  • Segurança

Vamos discutir cada um deles com mais detalhes.

Elasticidade

A elasticidade em um ambiente da nuvem envolve a escala horizontal e vertical automática de seu aplicativo por meio da designação dinâmica de recursos. Em um padrão de sistema virtual, os ambientes do WebSphere Application Server podem se tornar elásticos usando o recurso Intelligent Management Pack (IMP) no IBM PureApplication System.

O recurso IMP pode aumentar ou diminuir uma célula do WebSphere Application Server em um padrão de sistema virtual sob demanda, com base em acordos de nível de serviço ou métricas de desempenho descritas por meio de políticas. Um exemplo de como o IMP alcança a escala horizontal é quando ele detecta um pico de carga de trabalho na célula do WebSphere Application Server, que pode acabar com a capacidade atual da CPU, ele automaticamente fornecerá um novo nó WAS para atender à demanda da carga de trabalho. Além disso, o IMP é flexível o suficiente para implementar a escala vertical quando configurada. Para cumprir um ANS de tempo de resposta a fim de evitar a degradação do desempenho, o IMP pode acionar o início de novas JVMs em um cluster do WebSphere.

Se a elasticidade for um requisito para seu aplicativo, considere o uso do ambiente do WebSphere Application Server aprimorado pelo IMP no IBM PureApplication System.

Figura 1. Selecionando imagens do WebSphere ativadas pelo IMP em um VSP
Selecionando imagens do WebSphere ativadas pelo IMP em um VSP

Topologia

Se as melhores práticas de topologia existentes tiverem sido aplicadas em seu ambiente atual, elas também serão relevantes ao padrão de sistema virtual.

Por exemplo, se uma configuração em cluster do WebSphere Application Server for usada com 8 JVMs e uma replicação de sessão de memória interna como sua melhor prática para produção, o mesmo se aplica ao tipo de produção do seu padrão de sistema virtual.

Para um tipo de devtest do padrão de sistema virtual, é possível escolher uma única configuração do servidor e tamanhos de heap menores nas JVMs.

Como parte do desenvolvimento do padrão de sistema virtual, é útil criar um diagrama da topologia na qual cada produto está listado (junto do número de VMs por produto) e o relacionamento entre cada VM é refletido; por exemplo, se o WebSphere Application Server precisar se conectar a um servidor MQ, essa comunicação deverá ser refletida no diagrama de topologia.

Figura 2. Documentando a topologia do VSP em um diagrama
Documentando a topologia do VSP em um diagrama

Orquestração

Quando a topologia tiver sido identificada para o padrão do sistema virtual, a próxima etapa lógica é listar as ações necessárias em cada VM para orquestrar a criação do sistema. Além disso, a ordem de cada ação também deve ser determinada.

Figura 3. Determinando a ordem na qual a topologia é orquestrada
Determinando a ordem na qual a topologia é orquestrada

Por exemplo, se seu processo de instalação do aplicativo exigir que um banco de dados esteja funcionando com um esquema implementado, faria sentido orquestrar a configuração do banco de dados antes de o processo de instalação do aplicativo ser iniciado.

Para ativar esse tipo de orquestração, os padrões de sistema virtual permitem que o desenvolvedor especifique a ordem na qual as máquinas virtuais são criadas e a ordem na qual os scripts de automação são executados em máquinas virtuais.

Figura 4. Especificando a ordem de orquestração na ferramenta de implementação de VSP
Especificando a ordem de orquestração na ferramenta de implementação de VSP

Pode ser útil listar essas tarefas de orquestração, incluindo sua ordem, em uma versão estendida do diagrama de topologia, já que elas se tornam o projeto para o desenvolvedor de padrão do sistema virtual.

Segurança: Servidores do diretório

O suporte a LDAP é um dos tópicos relacionados à segurança a ser considerado no desenvolvimento de um padrão de sistema virtual. Geralmente, os aplicativos não obrigam os servidores LDAP dedicados; a maioria dos aplicativos se conectará a um servidor LDAP existente (como um diretório LDAP corporativo) para autorizar o acesso a recursos protegidos. Nessa situação, um componente do servidor LDAP não seria incluído em um padrão de sistema virtual.

A partir de uma perspectiva do WebSphere Application Server, a conexão com um servidor LDAP existente em um padrão de sistema virtual pode ser capturada por meio de um pacote de scripts que usam informações do servidor LDAP (host, usuário/senha, etc.) como parâmetros de entrada. O pacote de scripts automatizará a configuração de uma conexão do LDAP no WebSphere Application Server por meio de um script Jython, desobrigando um usuário de um padrão de sistema virtual de fazê-lo manualmente.

Figura 5. Configurando uma conexão do LDAP com o WAS com um pacote de scripts
Configurando uma conexão do LDAP com o WAS com um pacote de scripts

Se um aplicativo exigir um servidor LDAP dedicado, uma nova instância do Tivoli® Directory Server primeiro pode ser criada usando o Padrão de Aplicativo Virtual do aplicativo da web no IBM PureApplication System e as instâncias do WebSphere no padrão de sistema virtual podem se conectar ao servidor LDAP do Tivoli Directory Server recém-criado;— os pacotes de scripts no padrão de sistema virtual podem ser usados para configurar o WebSphere Application Server com o novo Tivoli Directory Server.

Figura 6. Conectando uma instância do WAS em um VSP a um servidor TDS criado por um padrão de aplicativo virtual
Conectando uma instância do WAS em um VSP a um servidor TDS criado por um padrão de aplicativo virtual

Reunindo informações de outras funções principais na organização

Em algumas organizações, o conhecimento do especialista pode ser difundido entre várias funções que podem exigir a participação de um conjunto mais amplo de especialistas técnicos, como:

  • Arquitetos de aplicativo: Este pode ser o caso se uma migração de versão do produto estiver sendo feita como parte da criação do padrão de sistema virtual. Por exemplo, se estiver fazendo upgrade de versões do servidor de aplicativos de um nível para outro, migrando para um padrão de sistema virtual, um arquiteto de aplicativo também pode precisar fornecer informações sobre uma possível migração do código.
  • Testadores de aplicativo: Se seu aplicativo exigir um teste complexo funcional e/ou de desempenho desconhecido do implementador de aplicativos, pode ser necessário que os testadores se comprometam em validar o funcionamento adequado do aplicativo quando ele for implementado no padrão de sistema virtual.
  • Engenheiros de vendas e gerentes de produto: Os funcionários com insights sobre os pontos de impacto do cliente na instalação, configuração, gerenciamento de ciclo de vida e ajuste de escala podem fornecer informações valiosas no design do padrão de sistema virtual. Por exemplo, um gerente de produto pode observar que um padrão de sistema virtual pode reduzir um ciclo de instalação/configuração de 10 dias para 20 minutos, melhorando o prazo de lançamento no mercado ou o tempo de maturação. Um engenheiro de vendas pode apontar que, se um padrão de sistema virtual puder criar um ambiente POC para um cliente em minutos (em vez de horas/dias), ele pode reduzir a duração média do ciclo de vendas e demonstrar facilidade de uso de seu produto aos seus clientes.

Uma melhor prática recomendada é envolver esses "recursos" em suas reuniões iniciais para reunir informações sobre o design e descobrir possíveis problemas iniciais. Conforme o projeto avançar, vincule o implementador de aplicativo principal à equipe estendida caso seja necessária ajuda no futuro.

Como com qualquer projeto, as funções não técnicas também estão envolvidas no desenvolvimento do padrão de sistema virtual, como as funções dos patrocinadores e gerentes de projeto. Entretanto, as descrições dessas funções estão fora do escopo deste artigo.


Identificando e mapeando tempos de execução

Definitivamente será preciso identificar vários tempos de execução a fim de mapeá-los de maneira efetiva para os componentes do padrão do sistema virtual. Vamos observar esses processos.

Identificar tempos de execução

A primeira etapa no desenvolvimento de um padrão de sistema virtual é identificar todos os componentes do tempo de execução (incluindo números exatos de versão) necessários para hospedar o aplicativo de destino. Eles geralmente incluem:

  • Sistemas operacionais, incluindo extensões, como RPMs específicos no Linux® .
  • Servidores da web.
  • Servidores do aplicativo.
  • Bancos de dados.
  • Servidores de processo de negócios.
  • Sistema de mensagens e componentes de conectividade, como o MQ.
  • Componentes de middleware customizados, como um servidor de aplicativos C++ customizados.

O primeiro tempo de execução a ser verificado é o sistema operacional; certifique-se de que ele seja compatível com o IBM PureApplication System.

Mapear os tempos de execução do middleware para componentes do padrão

Quando for verificado que o sistema operacional necessário é compatível, o mapeamento começa:

  • Os componentes do middleware IBM devem ser mapeados para edições de hypervisor de produtos de middleware que são enviados com o IBM PureApplication System. Por exemplo, se o WebSphere Application Server V7 no Red Hat Linux for um dos componentes de tempo de execução, ele mapeará para a edição de hypervisor do WebSphere Application Server V7.X para a imagem do Red Hat Linux enviada com o IBM PureApplication System.
  • Caso não haja uma correspondência exata do número da versão de um produto IBM no catálogo de imagens do IBM PureApplication System, será necessária uma avaliação sobre a possibilidade de o aplicativo ser executado em uma versão mais nova do produto. Por exemplo, se o aplicativo for executado no WebSphere Application Server V7.0.0.17 e a imagem do WebSphere Application Server no IBM PureApplication System for V7.0.0.19, será necessária uma avaliação do aplicativo em execução na versão mais nova do WebSphere Application Server.
  • Se o aplicativo não puder ser executado no nível da versão de um produto IBM no IBM PureApplication System ou se não existir nenhuma versão do hypervisor do produto IBM no catálogo de imagens do IBM PureApplication System, o sistema proporcionará a flexibilidade de criar imagens virtuais completamente customizadas.
    Figura 7. Estendendo e capturando uma imagem base no catálogo
    Estendendo e capturando uma imagem base no catálogo
    • Imagens customizadas: É possível criar uma imagem customizada do produto por meio do recurso estender/capturar no IBM PureApplication System ou por meio da ferramenta ICON. Nesse método, uma imagem principal do hypervisor do sistema operacional é vista como uma base e o produto é instalado sobre a imagem principal desse sistema operacional. Essa imagem customizada é capturada de volta no IBM PureApplication System para implementações repetidas.
    • Considerações de suporte para imagens customizadas: Antes de criar imagens customizadas de produtos de middleware IBM, verifique com o suporte IBM para assegurar que essa configuração do produto será suportada.
  • Se um componente do padrão de sistema virtual mapear para um produto não IBM, a abordagem de imagens customizadas que acabou de ser descrita pode ser usada para incluir um produto não IBM no padrão de sistema virtual.
    Figura 8. Mapeando produtos na topologia para componentes no VSP
    Mapeando produtos na topologia para componentes no VSP

Incorpore componentes nativos em um padrão

Os componentes nativos são produtos ou tempos de execução que não são agnósticos do sistema operacional. Por exemplo, um servidor customizado gravado em C++ pode ser considerado um componente nativo, já que pode ter sido compilado para ser executado em um sistema operacional ou arquitetura específica.

O ponto primordial é assegurar que o componente nativo seja compatível com o sistema operacional de edição de hypervisor de destino no IBM PureApplication System.

Os componentes nativos podem ser integrados ao padrão de sistema virtual por meio de um pacote de scripts, estender/capturarou uma abordagem de conjunto de ferramentas ICON.


Reutilizando scripts e conjunto de ferramentas existentes

Os padrões de sistema virtual foram desenvolvidos para maximizar a reutilização de investimentos existentes que os clientes podem ter feito em sua infraestrutura e plataforma. Os scripts que automatizam a instalação e a configuração de seu aplicativo serão um ativo principal a ser reutilizado no desenvolvimento do padrão de sistema virtual.

Figura 9. Um diagrama de reutilização de scripts
Um diagrama de reutilização de scripts

Por exemplo, caso tenha scripts Jython que criam um cluster do WebSphere Application Server, configure origens de dados/definições de fila e instale um arquivo EAR, em seguida, será muito fácil reutilizar esse script no ambiente do padrão de sistema virtual para orquestrar a criação de seu aplicativo. O mesmo se aplica a arquivos® DDL ou SQL do DB2, que criam esquemas e preenchem suas tabelas com dados iniciais; esses scripts também podem ser facilmente aplicados a componentes do DB2 no padrão de sistema virtual.

Além disso, caso tenha produtos em seu padrão de sistema virtual para os quais as imagens do hypervisor do IBM PureApplication System não existem, qualquer conjunto de ferramentas de automação existente para esses produtos será muito útil no padrão de sistema virtual. Por exemplo, o conjunto de ferramentas de instalação silenciosa para produtos de terceiros (em vez de blindagens de instalação orientadas a GUI) pode ser reutilizado em padrões de sistema virtual para automatizar a criação de produtos não IBM.


Considerações de dimensionamento de disco

As configurações padrão das imagens de edição do hypervisor vêm com tamanhos de disco específicos. Por exemplo, os perfis do WebSphere Application Server são posicionados em um disco virtual de 2 GB e o tamanho do disco virtual de dados do DB2 é 10 GB por padrão.

Se seu aplicativo exigir diferentes tamanhos de disco, será necessário estender/capturar as respectivas imagens do produto no catálogo do IBM PureApplication System com discos virtuais maiores.

Uma estratégia também deve ser implementada para a limpeza ou rolamento de arquivos de log e arquivos temporários que podem fazer com que os discos virtuais sejam preenchidos.


Estender e capturar componentes em um padrão

Se houver um produto em seu design de padrão de sistema virtual para o qual uma imagem do hypervisor não existe no IBM PureApplication System (eles poderão ser produtos de terceiros não IBM ou produtos IBM para os quais não existem edições de imagem do hypervisor), há três métodos para capturar esse produto/componente no padrão de sistema virtual:

  • Usando pacotes de scripts.
  • Usando o método estender/capturar.
  • Usando a Image Construction and Composition Tool (ICON).

Usando pacotes de scripts

Os pacotes de script permitem que scripts novos ou existentes sejam executados em VMs fornecidas por um padrão de sistema virtual. O motivo pelo qual são chamados de "pacotes" é que um usuário faz upload de um arquivo ZIP ou TAR no dispositivo que pode conter scripts e arquivos binários associados, bem como arquivos sob os quais o script precisa atuar. Por exemplo, se um pacote de scripts precisar executar um programa Java customizado, o usuário pode fazer upload de um arquivo ZIP que contém um arquivo JAR com o script shell que chamará o código Java dentro desse arquivo JAR.

Além disso, os pacotes de scripts podem acessar variáveis de ambiente integrado que os tornam mais inteligentes quanto à nuvem em que estão sendo executados. Por exemplo, um pacote de scripts em uma VM do WebSphere Application Server pode consultar o nome do host de uma VM do DB2 (que também é parte do mesmo padrão de sistema virtual) na nuvem no tempo de implementação.

Portanto, os pacotes de script também podem ser usados para automatizar a instalação e a configuração de um componente de terceiro em uma imagem de hypervisor do IBM PureApplication System.

Quanto à questão sobre qual tipo de imagem do hypervisor escolher para instalar o produto de terceiro, as opções estão entre a imagem do S.O. Principal e qualquer outra imagem do hypervisor já existente em seu padrão. É necessário fazer algumas considerações para responder adequadamente a essa questão.

Se seu produto de terceiro puder ser colocalizado em uma imagem que já é parte do padrão de sistema virtual, pode ser mais fácil somente instalar o produto nessa imagem existente. Por exemplo, caso já tenha uma imagem do WebSphere Application Server em seu padrão de sistema virtual e o produto de terceiro puder ser colocalizado com o WebSphere Application Server, será mais simples somente incluir o pacote de scripts na VM do WebSphere Application Server.

Entretanto, se o produto precisar de sua própria VM dedicada, é possível usar uma imagem do S.O. Principal em seu padrão de sistema virtual e incluir o pacote de scripts nela. Uma imagem do S.O. Principal é uma imagem de hypervisor em branco com apenas um sistema operacional instalado nela. Essa VM da imagem do S.O. Principal será criada como parte de seu padrão, assim como outras VMs comuns de produto IBM e o pacote de scripts incluído nessa VM será executado para instalar, configurar e inicializar seu produto de terceiro.

Portanto, essa pode ser uma boa abordagem, contanto que seus binários de produto de terceiro não sejam muito grandes (no momento da composição deste artigo, há um limite de 2 GB nos tamanhos de pacote de scripts transferidos por upload da GUI do IBM PureApplication System) e desde que a instalação/configuração de seu produto de terceiro não seja muito complexa e possa ser automatizada com scripts shell.

Observe que os pacotes de scripts maiores que 2 GB podem ser transferidos por upload por meio da interface da linha de comandos da ferramenta de implementação. Se arquivos grandes ou binários de produtos estiverem sendo compactados com o pacote de scripts, é uma melhor prática para o script acessar um Network File System ou um armazenador central em que grandes arquivos são armazenados.

Estender/capturar

Embora os pacotes de scripts permitam a customização de imagens do hypervisor (por meio de scripts) no tempo de implementação do padrão de sistema virtual, o método estender/capturar customiza as VMs antes do padrão de sistema virtual ser implementado e torna da VM customizada parte do catálogo do IBM PureApplication System.

Se desejar configurar uma linha de base padrão para uma VM em todos os seus padrões, o estender/capturar pode ser um bom método para fazê-lo. Por exemplo, se o tamanho do disco padrão do diretório de perfis da imagem do hypervisor do WebSphere Application Server no IBM PureApplication System não atender aos seus requisitos e você desejar tamanhos de disco maiores para os perfis do WebSphere Application Server, é possível estender a imagem do WebSphere Application Server no catálogo e empregar mais espaço em disco ao diretório de perfis do WebSphere Application Server. O mesmo princípio se aplica a qualquer outra normatização que desejar realizar nas VMs, como ter RPMs do Linux específicos presentes em determinadas VMs em todos os padrões.

Além disso, essa abordagem estender/capturar pode ser usada também para instalar produtos de terceiro também em um S.O. Principal ou em uma imagem do hypervisor de produto IBM existente. No método estender/capturar, a imagem a estender é primeiro implementada na nuvem e a customização manual (como a instalação do produto de terceiro) é executada na VM fornecida para a imagem. Quando a customização estiver concluída, o estado da VM implementada é capturado no catálogo com um novo nome lógico. Então, essa imagem customizada pode ser usada em um padrão de sistema virtual.

A abordagem estender/capturar é preferencial para pacotes de scripts (para produtos de terceiro) quando a instalação e/ou a configuração do produto não puder ser alcançada por meio de scripts. Por exemplo, se seu produto for instalável somente por meio de uma GUI que requer intervenção humana, a abordagem estender/capturar é uma boa opção. Além disso, em situações em que você deseja uma rápida integração de um produto em um padrão de sistema virtual e não tem recursos no momento para criar scripts para a instalação automatizada, essa também pode ser uma abordagem preferencial.

Além disso, se seus binários de produto de terceiro forem muito grandes (maiores que 2 GB), o método estender/capturar é preferencial para pacotes de scripts.

Será necessário observar que os pacotes de scripts evitam o que é conhecido como "expansão de imagem"; eles permitem incluir diferentes "tipos" em uma imagem base. Sem pacotes de scripts, até mesmo as configurações levemente diferentes de uma imagem base exigiriam o percurso do processo de estender/capturar que levaria a muitas imagens em seu catálogo.

Há alguns desafios no método estender/capturar.

Primeiro, a customização que um usuário faz na VM capturada é manual, portanto, não é facilmente repetida a menos que seja completamente documentada. Por exemplo, caso o Red Hat e SuSE Linux sejam compatíveis, essa customização terá de ser feita duas vezes para ambos os tipos de Linux. Da mesma forma, se fizer upgrade para uma nova versão de uma imagem do hypervisor na linha, essa customização manual terá de ser repetida.

Em segundo lugar, lembre-se de que certas propriedades da imagem customizada são dinâmicas; elas mudam a cada implementação. Por exemplo, cada instância de uma imagem na nuvem possui um nome do host ou endereço IP designado dinamicamente. Se o produto de terceiro configurado na imagem precisar dessas informações dinâmicas, um pacote de scripts associado (executado no momento da ativação da imagem) terá que ser usado para atualizar essas informações na imagem.

Para lidar com alguns desses desafios, o conjunto de ferramentas ICON pode ser usado.

Usando o Image Construction and Composition Tool

O Image Construction and Composition Tool (ICON) é uma ferramenta enviada com o IBM PureApplication System que permite a customização repetida de uma imagem virtual base. O princípio estender/capturar explicado acima também se aplica ao ICON com uma diferença principal: o ICON permite uma customização modular de uma imagem por meio de um conceito conhecido como bundles— isso significa que a customização da imagem é inerentemente documentada e repetida com o ICON.

Um pacote configurável no ICON representa os scripts do software e de configuração necessários para instalar/configurar esse software e é executado em uma imagem base do hypervisor. Os scripts de configuração são executados como parte da ativação de imagem, portanto, são capazes de entender o contexto da nuvem em que estão sendo executados (como escolher dinamicamente o nome do host da VM). Diversos pacotes configuráveis podem ser incluídos em uma imagem no ICON. Eles podem ser reutilizados em imagens diferentes. Por exemplo, um pacote configurável para "produto X" pode ser usado para customizar uma imagem do Red Hat ou SuSE.

Da mesma forma, se uma versão mais nova da imagem base for obtida e precisar ser customizada, o(s) pacote(s) configurável(is) pode(m) ser executado(s) novamente na nova imagem base de uma forma automatizada e repetida, reduzindo, portanto, a responsabilidade da manutenção da customização de imagens virtuais.

Portanto, embora o ICON exija um maior investimento inicial, é preferencial para a abordagem básica estender/capturar no IBM PureApplication System, quando diversos suportes de sistema operacional estiverem envolvidos, quando a repetitividade da customização da imagem for uma questão e quando as imagens forem atualizadas frequentemente.

Tabela 1. Qual ferramenta é mais adequada para quais tarefas
A ferramenta...... é mais adequada para...
Pacotes de scriptsInstalação de pequenos produtos de área de cobertura
Os produtos com uma opção de instalação silenciosa que não exigem intervenção humana
Etapas de customização pós-instalação
Orquestração solicitada de topologia
Estender/capturarProcesso de instalação orientado à GUI sem opção de instalação silenciosa
Instalação de produtos com uma ampla área de cobertura
Tempo de implementação mais rápido para grandes topologias
ICONCriação simplificada de imagens virtuais customizadas que podem ser importadas para o IBM PureApplication System
Instalação de produtos não IBM complexos

Desenvolvimento iterativo e teste

Por fim, vamos considerar uma filosofia geral para desenvolvimento e teste de padrões de sistema virtual, uma que também funcione na maioria dos esforços de desenvolvimento.

Pode ser tentador assumir uma abordagem de "adoção de big bang" para desenvolver o padrão de sistema virtual, no qual você tenta automatizar a criação e configuração de cada componente no padrão de sistema virtual na primeira tentativa. No entanto, essa abordagem pode ser arriscada, porque ela pode atrasar a descoberta de desafios imprevistos de criar o aplicativo no novo ambiente.

Esse será o caso principalmente se estiver fazendo o upgrade para uma versão mais nova ou diferente de um produto à custa de uma abordagem de padrão de sistema virtual. Por exemplo, você pode descobrir que seu aplicativo requer algum ajuste para funcionar em uma versão diferente de um produto. Ou que um componente de terceiro não funciona adequadamente em uma versão específica de um sistema operacional na imagem do hypervisor.

Para evitar a descoberta tardia desses problemas, é melhor assumir uma abordagem iterativa para o desenvolvimento de padrão de sistema virtual. Isso é feito com um teste simulado manual de todas as tarefas que deseja automatizar com pacotes de scripts:

  • Implemente todas as VMs na topologia na nuvem sem pacotes de script.
  • Caso já tenha scripts existentes para executar tarefas de configuração nas VMs, execute-as manualmente fazendo upload delas diretamente na VM e chamando-as à mão. Se ainda não tiver scripts, faça todas as tarefas manualmente (por meio de uma GUI ou linha de comandos) e documente qualquer lacuna que encontrar em suas etapas de orquestração do padrão de sistema virtual original.
  • Quando todas as VMs tiverem sido configuradas e o aplicativo tiver sido criado manualmente, execute alguns testes básicos no ambiente para verificar o aplicativo.
  • Quando tiver verificado que o aplicativo funciona no ambiente, é possível começar a criar scripts para automatizar todas as etapas manuais executadas.
  • Caso haja scripts existentes, tudo o que precisa fazer é incluí-los nos pacotes de scripts. Entretanto, caso não haja scripts existentes, primeiro poderá desenvolvê-los iterativamente nas VMs configuradas manualmente.
    • Além disso, também há uma abordagem iterativa para testar pacotes de scripts. Os pacotes de scripts podem ser especificados para serem executados automaticamente (na inicialização ou no encerramento da VM) ou manualmente a partir da GUI de implementação da carga de trabalho.
    • A vantagem de executá-los manualmente a partir da GUI é que as atualizações nos pacotes de scripts são escolhidas mediante cada chamada. Isso permite testar iterativamente seus pacotes de scripts sem ter de reimplementar todo o padrão de sistema virtual em todas as mudanças feitas em um script.

Conclusão

Esperamos que este artigo, combinado aos recursos no developerWorks e no IBM PureApplication System Infocenter, possa lhe oferecer um forte início no desenvolvimento de seus próprios padrões de sistema virtual.

Agradecimentos

Gostaríamos de agradecer o suporte e a orientação de: Kai Young, Catherine C. Diep, Shaun Murakami, Jason Anderson e Animesh Singh.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing, WebSphere, Tivoli
ArticleID=811521
ArticleTitle=Desenvolva um Padrão de Sistema Virtual
publish-date=04302012