Explorar o IBM SmartCloud Application Services

Criando um novo tipo de padrão para um padrão virtual

Juntamente com a grande ênfase em padrões virtuais nos sistemas em nuvem especialistas do IBM® PureSystems™, o especialista em Nuvem IBM, Dominique Vernier, imaginou que alguns desenvolvedores pudessem querer aprender como criar um tipo de padrão, a estrutura que fornece todos os componentes, links, regras de escalabilidade etc., para desenvolver um padrão. Nesta agregação, o especialista explica, passo a passo, como criar e aprimorar um tipo de padrão. Embora o autor esteja usando o IBM SmartCloud Application Workload Services do SmartCloud Application Services, os resultados são aplicáveis tanto ao SmartCloud Enterprise quanto à família IBM PureSystems.

Dominique Vernier, IT Architect, IBM

Dominique Vernier photoNos últimos anos, Dominique Vernier se concentrou em tecnologias Java e arquitetura de nuvem. Ele também trabalha em tecnologia da informação há algum tempo, tendo obtido conhecimento amplo em tecnologias e produtos como sistema de mensagens, banco de dados, SOA, EAI, cliente/servidor, C/C++ e estruturas existentes. Dominique também possui extenso conhecimento de áreas do segmento de mercado como telecomunicações, CRM, logística e seguros. Ele é o autor/coautor de quatro patentes relacionadas a motores de estado e gerenciamento de recursos. Atualmente, Dominique é responsável pelas soluções IBM SmartCloud Enterprise na IBM GTS Global Team.



30/Ago/2013

Como sou um IT Architect curioso, após ler o artigo do developerWorks Criar e Customizar Padrões de Aplicativos Virtuais, surgiu uma dúvida: "Qual seria a dificuldade em criar um tipo de padrão?" Assim, tentei desenvolver um tipo de padrão para um servidor independente, um projeto um tanto simples, mas que demonstra facilmente os conceitos que sustentam o tipo de padrão.

Este artigo é uma diretriz para esse processo; as etapas envolvidas são extraídas de uma série mais completa do meu blog. Cada seção é uma sinopse de toda a instrução. Para explorar os detalhes, é necessário escolher os links e ler o PDF que acompanha toda a discussão, ou ler o PDF em meu blog. Os PDFs são cópias das entradas reais do blog e são atualizados periodicamente; os links para as entradas reais do blog são provavelmente a versão mais atual das informações e o local onde é possível encontrar novas partes desta série.

Outra observação: cada segmento é desenvolvido com base no trabalho dos segmentos anteriores, portanto, em grande parte da série, examino as mudanças do modelo físico e do aplicativo, e como testá-las para assegurar sua eficácia.

Definições, conceitos, o cenário e a configuração

A Parte 1 começa descrevendo a diferença entre tipo de padrão e pattern: um tipo de padrão fornece todos os componentes, links, regras de escalabilidade etc. para desenvolver um padrão. Ele requer mais esforço para ser criado do que o necessário para criar um padrão baseado em um tipo de padrão.

Em seguida, destaca o cenário:

  • O tipo de padrão contém somente um servidor.
  • O servidor possui um parâmetro.
  • O processo de implementação registra uma mensagem quando a "implementação" começa a instalação.
  • O processo de implementação registra uma mensagem em outro ponto da implementação.

Três conceitos importantes são apresentados:

  1. Um tipo de padrão geralmente consiste em um plug-in que compreende a definição do tipo de padrão e um ou mais plug-ins compostos pela funcionalidade fornecida por esse tipo de padrão — o número de plug-ins é uma opção da arquitetura.
  2. É possível decompor um plug-in em duas partes principais:
    • Modelo do aplicativo: define os diferentes componentes e links para desenvolver um padrão de aplicativo virtual.
    • Modelo físico: define as diferentes máquinas virtuais e scripts que precisam ser ativados na nuvem de destino.
  3. Dois mecanismos são fornecidos para mapear o modelo do aplicativo ao modelo físico: um mecanismo de código baseado em Java™ e um baseado em modelo (preferencial e recomendado).

Finalmente, as etapas de configuração para participar desse exercício são:

  1. Criar uma área de trabalho.
  2. Importar o tipo de padrão e os plug-ins.
  3. Modificar o nome do tipo de padrão.
  4. Editar a descrição do JSON do tipo de padrão.
  5. Criar um novo projeto Java para o plug-in.
  6. Criar um diretório do plug-in.
  7. Copiar os arquivos META-INF, build.plugin.xml e build.properties para o diretório do plug-in.
  8. Atualizar o arquivo config.json do seu plug-in.

Também abordo e forneço o código para:

  • O modelo do aplicativo: definido em plugin/appmodel/metadata.json. Veremos como desenvolvê-lo e testá-lo.
  • O modelo físico: composto por um arquivo de modelo da máquina virtual definindo o elemento virtual que deve ser implementado e a função relacionada ao modelo do aplicativo.

Um teste final é demonstrado e você está pronto para a Parte 2.

PDF Parte 1 | Blog Parte 1


Criar o tipo de padrão Escravo-Mestre

A próxima tarefa é criar um tipo de padrão Mestre-Escravo; ela difere do exercício da Parte 1, pois consiste em um link entre os dois servidores, do Mestre para o Escravo, e recupera algumas informações do Escravo (como o endereço IP) para configurar o Mestre.

As etapas da Parte 2 incluem:

  1. O exame do modelo do aplicativo e a visualização das mudanças feitas nele a partir do arquivo JSON do modelo do aplicativo na Parte 1. Um elemento do tipo de link que especifica se o destino e a origem foram incluídos.
  2. O exame das mudanças do modelo físico, a aprendizagem sobre a atualização do diretório OSGI e a reestruturação das partes com base no Mestre sendo dependente do Escravo.
  3. A descoberta de como testá-lo e quais podem ser os resultados adequados.

PDF Parte 2 | Blog Parte 2


Incluir escalabilidade estática em um tipo de padrão

A Parte 3 mostra como incluir uma escalabilidade estática no tipo de padrão Mestre-Escravo. Por escalabilidade estática, quero dizer definir o número de instâncias durante o design do padrão.

Primeiro, anexe um componente da política ao componente do Escravo, em seguida, defina os atributos dessa política e, finalmente, adapte os modelos da máquina virtual Escrava para importar as informações reunidas a partir do modelo do aplicativo. (Essa funcionalidade é importante, pois também existe para os sistemas especialistas integrados do IBM Workload Deployer e IBM PureSystems.)

PDF Parte 3 | Blog Parte 3


Incluir um coletor de monitoramento em um tipo de padrão

É claro que, para executar a escalabilidade dinâmica, aquela que reagirá a um recurso de monitoramento, é necessário ter a capacidade de coletar informações do servidor. O objetivo desta instrução é conseguir monitorar o número de arquivos de um determinado diretório de um servidor e fazer com que um gráfico mostre isso.

As etapas incluem:

  1. A definição do formato dos dados a serem coletados em um arquivo de metadados. As definições ocorrem durante a criação do arquivo.
  2. A criação do script do coletor que coleta as informações no servidor. Há formas diferentes de coletar informações de um servidor, como HTTP, WCA, entre outros; eu escolhi o script, pois é a mais fácil de entender. Também é possível implementar sua própria classe Java implementando a interface ICollector. Como todos os coletores precisam acompanhar essa interface, a resposta do coletor terá de seguir um determinado formato.
  3. A criação de scripts que fazem upload do arquivo de metadados e do script do coletor no servidor. Eu adaptei o arquivo install.py para essa função. Adicionalmente, há outras formas de executar essa função.
  4. O registro do coletor. Para registrar o coletor, use o comando maestro.monitorAgent.register(). Isso é feito no arquivo configure.py.
  5. Forneça a configuração para a interface com o usuário a fim de mostrar uma representação gráfica dos dados coletados. É preciso criar um arquivo monitoring_ui.json para mostrar o gráfico. Coloque esse arquivo ao lado do arquivo config.json.

PDF Parte 4 | Blog Parte 4


Escalabilidade vertical e horizontal com base no coletor de monitoramento

Você incluiu um coletor simples que conta o número de arquivos em um diretório; o próximo passo é saber como aproveitar esse coletor para incluir regras de ajuste de escala vertical e horizontal com base nas métricas fornecidas por esse coletor.

Para implementar esse cenário, é necessário modificar alguns arquivos para:

  1. Capturar os argumentos das regras de ajuste de escala ao projetar o padrão:
    • O diretório de arquivos a ser monitorado.
    • O limite mínimo/máximo em termos de número de arquivos.
    • O número mínimo/máximo de máquinas virtuais que gostaria de desmembrar.
    • A reação do período.
  2. Refletir esses valores na topologia.
  3. Alterar os scripts para criar o diretório a ser monitorado e passar esse parâmetro ao coletor.

O arquivo de metadados do modelo do aplicativo deve ser modificado para capturar os diferentes parâmetros da regra de ajuste de escala e definir a política de ajuste de escala. O arquivo da máquina virtual deve ser adaptado para injetar os atributos da política de ajuste de escala na topologia.

Com respeito aos scripts, na seção anterior, eu codifiquei permanentemente o diretório a ser monitorado nos scripts. Isso foi feito nos scripts de instalação, no entanto, agora, como se trata de um parâmetro de função, ele deve ser colocado em um script de função, tanto no arquivo configure.py quanto no start.py. Obviamente, ele é uma configuração da função e deve ser colocado nos scripts de configuração.

PDF Parte 5 | Blog Parte 5


Incluir associações às operações

Quando uma função é definida em um tipo de padrão, é possível associar a ela uma série de operações que você deseja ativar no momento da implementação do padrão. Neste exemplo, incluo uma operação "Send string to log" em uma função.

Para implementar uma operação, é preciso incluir um arquivo extra, denominado operation.json, ao lado do arquivo metadata.json, no diretório appmodel. Esse arquivo especifica qual script precisa ser ativado e se ele precisa ser colocado no diretório da função da parte.

No arquivo operation.json para cada função, é possível definir uma série de operações; cada uma delas com um ID, rótulo, descrição, categoria, script e uma lista de atributos. A categoria é usada para reunir uma série de operações na interface com o usuário. O script é um Python e deve ser colocado no diretório de scripts de função da parte. Os atributos são exibidos na interface com o usuário.

Implemente um script bastante simples. Esse script simplesmente recupera o valor do atributo stringToLog e o posta no arquivo de log. É possível recuperar um valor de atributo usando a sintaxe maestro.operation['parms'][{attributeName}];, em que attributeName é o nome do atributo a ser recuperado. O script deve ser colocado no diretório de scripts de função.

PDF Parte 6 | Blog Parte 6


Escalabilidade vertical e horizontal nas métricas de sistemas operacionais

No segmento anterior sobre ajuste de escala, expliquei como escalar vertical e horizontalmente usando seu próprio coletor de monitoramento (contando arquivos em um diretório). Também é possível reutilizar algumas métricas integradas do S.O. em uma política de ajuste de escala. A reutilização de uma métrica existente requer mudanças em apenas dois arquivos — o modelo do aplicativo (para coletar os argumentos da política de ajuste de escala) e o arquivo de topologia (para definir as regras e implementar essa política).

No arquivo do modelo do aplicativo, é preciso definir a política de ajuste de escala e capturar todos os argumentos para essa política. Isso é bastante semelhante ao que foi feito quando definimos a política para nosso próprio coletor de monitoramento. Em vez de definir uma série de arquivos e um diretório para monitorar os atributos, defina um atributo cpuUsage que seja uma porcentagem. Defina um elemento de tipo de política que esteja aplicado à função do servidor. Há dois grupos nessa política: um para uma política de ajuste de escala estática e outro para uma política baseada em CPU.

Para a política baseada em CPU, defina três atributos: cpuUsage, scaleInstanceRange1 e triggerTime1. É possível escolher os nomes que desejar; o importante é que eles sejam equivalentes ao ID de um atributo na lista de atributos definida depois disso. A ordem da referência de atributo no grupo define a aparência da ordem no editor de padrão.

Em seguida, defina cada atributo; por exemplo, para cpuUsage, especifique que é um intervalo; deve ser exibido como uma porcentagem com um padrão mínimo de 1 e máximo de 100.

Nos arquivos de topologia, é preciso injetar o atributo capturado no modelo do aplicativo para definir a regra de ajuste de escala. Isso é feito no atributo JSON scaling do arquivo da máquina virtual. É possível usar o cenário do Velocimacro para inserir elementos na topologia.

PDF Parte 7 | Blog Parte 7


Estender um tipo de padrão existente

Um cliente me fez a seguinte pergunta:

Tenho o meu próprio sistema de evento de log e gostaria que todas as informações dos arquivos de log do ambiente do WebSphere® Enterprise Application fossem copiadas para o meu sistema de evento de log. Não quero recriar o tipo de padrão WebApp integral apenas para incluir uma nova funcionalidade. Portanto, como posso aproveitar o tipo de padrão WebApp existente e incluir nele apenas a funcionalidade de que eu preciso?

A resposta é simples: estenda o tipo de padrão WebApp e inclua um plug-in que faça o que deseja. Você está com sorte: é fácil estender um tipo de padrão. Tudo do que precisa se lembrar é que um tipo de padrão compreende uma definição de tipo de padrão e uma série de plug-ins anexados. A definição do tipo de padrão especifica sua versão, nome e descrição. Cada plug-in anexado a ela especifica seu relacionamento com a definição do tipo de padrão em algumas linhas no arquivo config.json individual.

Tudo o que precisa ser feito é criar um novo plug-in que seja vinculado ao tipo de padrão de destino (nesse caso, WebApp). Inclua novos componentes no arquivo metadata.json.

PDF Parte 8 | Blog Parte 8


Incluir o recurso para ajustar uma instância de aplicativo virtual

As operações são importantes: elas fornecem a capacidade de tomar ações (por exemplo, configurar parâmetros e manipular situações com base em tais) em um padrão ou aplicativo virtual implementado. Isso pode ser feito ativando um script especificado em um arquivo operation.json criado no modelo do aplicativo. Consulte como incluir uma operação em um tipo padrão.

O modelo de operações permite a ativação de scripts com parâmetros em um padrão em execução, mas outra forma de fazer isso é ajustar. A diferença é que um parâmetro ajustado persiste no armazém e, portanto, pode ser reutilizado a qualquer momento durante o ciclo de vida do padrão em execução.

O ajuste fornece a mesma funcionalidade, mas com parâmetros persistidos no padrão implementado. É possível usar o parâmetro de ajuste para regenerar um servidor paralisado e configurá-lo exatamente como na versão anterior. Um exemplo é o arquivo WAR/EAR no padrão WebApp; quando ele é configurado, o caminho para o arquivo é persistido no padrão implementado.

Os parâmetros ajustados podem ser vinculados aos atributos do componente.

No modelo do aplicativo, é preciso criar o tweak.json e arquivos de operações. Defina seus parâmetros ajustados no arquivo tweak.json.

Portanto, você pode perguntar: "Por que preciso de um arquivo de operações, se estou ajustando?". Um arquivo de operações é necessário (com o "id": "configuration",) para que a interface com o usuário mostre o "ajuste".

A persistência é feita no armazém, em parameters.json, localizado no padrão implementado.

Não é necessário fazer nada de especial nos arquivos de topologia (máquina virtual), a menos que você tenha de recuperar um valor usando a função maestro.parms.

PDF Parte 9 | Blog Parte 9


Anexar o armazenamento a uma máquina virtual no SmartCloud Application Services

Estava me perguntando como incluir armazenamento em uma máquina virtual gerada a partir de um tipo de padrão desenvolvido no SmartCloud Application Workload Service: na verdade, é simples. Tudo o que deve ser feito é atualizar seu modelo de topologia para solicitar o armazenamento e, em seguida, mencionar esse armazenamento no elemento de array vm-templates.

Inclua uma solicitação de armazenamento em um arquivo simples da máquina virtual adicionando uma matriz storage-templates ao arquivo JSON, inclua uma referência à solicitação de armazenamento adicionando um elemento de array de armazenamento ao elemento vm-templates, em seguida, desenvolva seu plug-in e o implemente.

Assim que o padrão estiver implementado, conecte-se e verifique se o armazenamento está montado com o tamanho correto.

Uma observação rápida: o SmartCloud Application Workload Service especifica os tamanhos de seu armazenamento em gigabytes (GB); o SmartCloud Enterprise permite a solicitação tanto em GB quanto em terabytes (TB).

PDF Parte 10 | Blog Parte 10


Conclusão

Espero que este resumo sobre a criação e adaptação de um tipo de padrão do SmartCloud Application Services tenha proporcionado uma base sólida para desenvolver um tipo de padrão reutilizável, o bloco de desenvolvimento para a criação de padrões virtuais. Lembre-se de que os detalhes para cada segmento estão a apenas um clique físico de distância.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

  • Participe da comunidade do developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.

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
ArticleID=842734
ArticleTitle=Explorar o IBM SmartCloud Application Services
publish-date=08302013