Localizar Gargalos no Desempenho do Fornecimento na Nuvem

Testar e analisar desempenho do fornecimento da sua nuvem

O fornecimento em nuvem é o processo de implementação e gerenciamento de recursos de TI nas infraestruturas em nuvem. O fornecimento rápido é um requisito de desempenho-chave para serviços de nuvem, especialmente quando há um grande número de recursos de solicitação de clientes ao mesmo tempo. No entanto, é difícil determinar qual fator, ou combinação de fatores, é a causa do desempenho de fornecimento precário porque não há nenhuma ferramenta existente e métodos para rastrear cada mudança de status e etapa de execução no provisionamento. O autor detalha um método de teste de desempenho de fornecimento que é possível usar como uma ferramenta para determinar se o seu desempenho de fornecimento pode estar atrasado.

Xiang Wen Chen, Performance Engineer, IBM

Xiang Wen Chen é um engenheiro de desempenho no Laboratório do Desenvolvedor da IBM China com mais de dois anos de experiência com projetos relacionados da nuvem e vários documentos sobre a computação em nuvem para publicações internas da IBM e sites de comunidade.



01/Out/2012

Este artigo descreve um método de teste de desempenho de fornecimento que é possível usar como uma ferramenta para determinar onde o desempenho de fornecimento de computação em nuvem pode estar atrasado. A finalidade desse teste de desempenho de fornecimento é:

  1. Fornecer uma medição do tempo de provisão total de ponta a ponta da perspectiva de um usuário.
  2. Determinar as tendências de tempo de provisão quando há várias provisões ao mesmo tempo.
  3. Interromper o inteiro tempo de provisão em segmentos para compreender que componentes e que etapas custam o máximo em gasto adicional de desempenho.
  4. Obter as informações de enfileiramento no nível de componente quando há muitas solicitações de fornecimento no sistema para ajudar a localizar o gargalo.

Vamos examinar alguns dos fundamentos do fornecimento da nuvem.

Fundamentos do fornecimento de nuvem

O fornecimento em nuvem é o processo de implementação e gerenciamento de recursos de TI nas infraestruturas em nuvem. Ele consiste em três tipos de fornecimento:

  • Fornecimento de máquina virtual: inclui a instanciação de uma ou mais máquinas virtuais que correspondem aos requisitos de hardware e de software de um aplicativo. A maioria dos provedores em nuvem oferece um conjunto de modelos de VM com configurações de software e hardware genéricos. Por exemplo, IBM® O SmartCloud Enterprise suporta centenas de tipos de VM cada com diferentes opções de processadores, memória e desempenhos de E/S.
  • Fornecimento de recurso: o mapeamento e o planejamento de VMs nos servidores físicos dentro da nuvem.
  • Fornecimento de aplicativo : a implementação de aplicativos especializados dentro das VMs e o mapeamento das solicitações de usuário final às instâncias de aplicativo.

Os clientes também fornecem seus próprios ativos, por exemplo, uma instância de servidor virtual, uma imagem ou uma unidade de armazenamento persistente por meio de um portal da web ou API.

Este artigo se concentra no fornecimento de máquina virtual e no fornecimento de recurso, duas das principais funções dentro da nuvem. Vamos examinar os desafios do desempenho do fornecimento.


Os problemas do desempenho de fornecimento podem ser enganosos

O processo de fornecimento é complicado, devido à natureza imprevisível dos recursos de TI virtualizados e elementos de rede. Os clientes muitas vezes encontram um problema com o desempenho de fornecimento, mas acham que é difícil determinar que fator ou combinação de fatores compõe a causa.

Alguns dos desafios que os clientes de nuvem experimentam:

  • Diferentes provedores de nuvem usam diferentes mecanismos de fornecimento. Os usuários devem ter algum conhecimento do mecanismo de fornecimento que eles usam antes de se comunicarem efetivamente com o provedor em nuvem sobre os problemas de desempenho, sem mencionar a determinação da causa-raiz.
  • No tempo de execução, pode haver problemas imprevistos de desempenho de interoperabilidade que evitem o fornecimento suave. Ao passo que alguns componentes de middleware podem ser testados quanto ao desempenho antes de serem integrados no sistema, alguns dos problemas de desempenho podem vir à tona somente depois de interagirem com outros middlewares ou quando eles necessitam de uma configuração específica para satisfazer uma necessidade de negócios.
  • Em um grande ambiente de computação, por exemplo, um datacenter, a disponibilidade, carga e rendimento dos recursos de TI e rede também podem afetar o desempenho.
  • Os fluxos de trabalho de provisão podem se tornar complexos e introduzir problemas de desempenho. Por exemplo, um mecanismo de fornecimento de finalidade geral propicia serviços que permitem fornecer componentes de middleware específicos, por exemplo, bancos de dados ou servidores de aplicativos. A implementação da operação real de fornecimento subjacente é implementada por um script ou componente de mecanismo específico. Um grande número de operações é composto por serviços de fornecimento que podem ser integrados em diferentes fluxos de trabalho de fornecimento.

Vamos examinar os métodos e análise de teste de desempenho de provisão.


O método de teste de fornecimento e processo de análise

A equipe com que trabalhei desenvolveu um método de teste que primeiro descreve um conjunto de estados e operações de modo que o processo de fornecimento inteiro pode ser definido independentemente dos mecanismos de fornecimento específicos usados. A Figura 1 descreve esses estados.

Figura 1. Definindo o processo de fornecimento por meio dos estados e operações em vez dos mecanismos usados
Definindo o processo de fornecimento por meio dos estados e operações em vez dos mecanismos usados

Durante o Período de Envio, o usuário submete uma solicitação e obtém a resposta. Se a chamada do fluxo de trabalho de fornecimento for bem-sucedida, o status do componente muda de "accept" para "submitted". O status da solicitação de fornecimento muda para "New".

Durante o Período de Reserva de Recursos, se a reserva de todos os componentes necessários não for possível, o fornecimento da solução completa não será possível e o fluxo de fornecimento será interrompido. Para reservar um componente, o status de componente muda de "Not Available" para "Reserving". Se a reserva for bem-sucedida, uma mensagem reservada é retornada e o status do componente muda para "Reserved".

Durante o Período de Provisão, assim que o mecanismo de fornecimento tiver executado todas as etapas necessárias para configurar o componente, uma mensagem fornecida será enviada e o componente mudará para o estado "Provisioned". Uma vez que um componente seja fornecido, todas as suas propriedades estão disponíveis por meio do log de customização da execução.

Neste artigo, eu conduzo dois tipos de testes — um teste de linha de base e um teste de carga.

As medições de linha de base são necessárias para um teste válido. Recomendo testar um pequeno número de imagens com diferentes tipos e tamanhos. No teste de linha de base, a interrupção do tempo de fornecimento total para cada um desses três períodos é registrada e o tempo é registrado para cada mudança de status. Por calcular a duração do período no nível de solicitação, você tem uma ideia inicial de que parte dura mais. Os dados do recurso de cálculo e da versão do sistema operacional da máquina virtual também são coletados para detectar os problemas de provisão de determinadas configurações de imagem.

O teste de carga simula várias provisões que podem causar tempos de provisão mais longos. Ao executar o teste de carga, você monitora as atividades do nível de componente para localizar os gargalos do sistema. O registro de data e hora de cada mudança de status de componente é registrado. Usar o mesmo tipo de imagem que o objeto de provisão pode tornar a comparação clara e mostrar uma tendência do tempo. Acompanhar como a duração de provisão se altera à medida que as provisões concorrentes aumentam ajuda a monitorar o comportamento de transação em um nível de componente.

A equipe desenvolveu o script de teste com base no fluxo de trabalho de ponta a ponta dos usuários. O script envia uma solicitação de provisão e rastreia o status da provisão por todo o caminho para determinar se a provisão foi bem-sucedida, estava com falha ou atingiu o tempo limite. Ferramentas de teste de desempenho, como Rational® O Performance Tester pode ser usado para acionar a carga de trabalho de fornecimento e capturar tais dados do lado do usuário como períodos de configuração e provisão de imagem no nível da solicitação. A maioria dos mecanismos e ferramentas de fornecimento e gerenciamento oferece uma abordagem nativa para a manipulação de recursos e componentes.

Como um resultado, ao usar tais ferramentas, o cliente pode registrar que operação em que mecanismo e qual serviço/terminal foi chamado. O período de provisão para cada nível de componente será calculado a partir desses dados. Um Python e VBscript é usado para análise de log e geração de relatório.


Monitorando o comportamento dos componentes do fluxo de trabalho

A próxima seção apresenta alguns casos de uso onde o SmartCloud é usado para testar o desempenho do fornecimento da nuvem. Mas, primeiro, examine a Figura 2 — ela inclui os componentes-chave no fluxo de trabalho de provisão e interface usada para monitorar esses comportamentos de componentes.

Figura 2. Os componentes-chave do fluxo de trabalho de provisionamento
Os componentes-chave do fluxo de trabalho de provisionamento

O Período de Envio de provisionamento ocorre principalmente no WebSphere® Application Server. A equipe usou os logs e as métricas de solicitação para rastrear as transações individuais, registrando o tempo de processamento em cada um dos componentes principais do WebSphere Application Server.

É possível usar o console da web, a API e o banco de dados de consulta para obter o tempo de resposta para fornecimento do fluxo de trabalho de projeto e reserva. O servidor IBM Tivoli® Service Automation Manager/IBM Tivoli Provisioning Manager (TSAM/TPM) permite que os usuários solicitem, criem, excluam, modifiquem e gerenciem recursos virtuais. A reserva de recursos ocorrerá no servidor TSAM/TPM.

O período de fornecimento ocorre no Tivoli Provisioning Manager Deployment Engine. O Tivoli Provisioning Manager coleta informações de "depuração" que incluem o tempo que cada fluxo de trabalho chama outro fluxo de trabalho. A tela de status do fluxo de trabalho no Tivoli Provisioning Manager permite acesso a esse perfil do tempo de execução/dados de depuração que fornece detalhes sobre os fluxos de trabalho por exemplo, como ele se desenrola e onde está gastando o seu tempo. Se houver um gargalo no seu aplicativo, é possível analisar esses dados para compreender em que componentes estão os gargalos específicos. Adicionalmente, é possível configurar um servidor IBM Tivoli Monitoring para controlar e configurar os recursos, a disponibilidade e o desempenho.


Resultados dos casos de uso

Vamos examinar os resultados de como usar esse método em três casos de uso:

  • Fornecimento de VM único
  • Várias soluções de fornecimento submetidas no WebSphere Application Server
  • Várias provisões causando um aumento no tempo de provisão total

Fornecimento de VM único

Problema: Determinados tipos de fornecimento de imagem podem levar um longo período durante o período de provisionamento em nosso teste de linha de base.

Detalhes: O período de provisão principalmente inclui o tempo de processamento no Tivoli Provisioning Manager Deployment Engine e hypervisor. É possível utilizar o log do fluxo de trabalho do Tivoli Provisioning Manager para ver cada etapa do processamento.

Etapas:

  1. Obter o ID da solicitação de fornecimento usando a API.
  2. Obter a solicitação de serviço que foi criada pela sua solicitação no visualizador JINSIGHT do Tivoli Service Automation Manager.
  3. Localizar a etapa no fluxo de trabalho que ocupou a maior porcentagem do tempo (Figura 3).
Figura 3. Visualizar o fluxo de trabalho de implementação usando o JINSIGHT
Visualizar o fluxo de trabalho de implementação usando o JINSIGHT

Na Figura 3, é possível ver que nesse fluxo de trabalho a imagem do clone de cópia custa 24,7 por cento; os discos de configuração custam outros 22,5 por cento. A etapa mais cara no disco de configuração é o status de boot de verificação.

Várias soluções de fornecimento submetidas no WebSphere Application Server

Problema: Ao enviar várias provisões ao mesmo tempo, o tempo de resposta de envio aumenta dramaticamente.

Detalhes: O período de envio principalmente inclui o tempo de processamento no WebSphere Application Server. É possível coletar e analisar o log de rastreio para obter cada etapa de processamento.

Etapas:

  1. Configurar as classes relacionadas para o nível do log de detalhes.
  2. Obter a duração do período de envio para cada provisão.
  3. Registrar a data e hora do primeiro envio e do último envio. Coletar o log de rastreio entre esses dois registros de data e hora.
  4. Analisar os registros do horário de início e de encerramento de cada etapa de processamento em cada processo de manipulação de provisão.
  5. Localizar as etapas mais caras e desenhar os gráficos para refletir a tendência do tempo de resposta. Compare esses gráficos para localizar o que causa o aumento do tempo de envio total (Figura 4).
Figura 4. Tempo de resposta de envio total
Tempo de resposta de envio total

Depois de analisar o log de rastreio para essas 13 solicitações, você descobrirá que a etapa mais cara é fazer a chamada OSS que precisa interagir com o servidor Tivoli Service Automation Manager. Assim, eu desenhei uma linha para essa etapa:

  • A linha vermelha mostra o tempo total de resposta de envio para cada provisão. Ele aumenta dramaticamente depois de 7 envios.
  • A linha azul está fazendo o tempo de resposta da chamada de OSS e é totalmente estável, o que significa que ele não contribuiu ao aumento do tempo de resposta total.

Em seguida, localize a segunda etapa mais cara e desenhe o gráfico de tendência de tempo para comparar as duas.

Várias provisões causam um aumento no tempo de provisão total

Problems: Quando há várias provisões no sistema, o tempo de provisão total aumentará. Você deseja saber que período contribui mais e que componente é o gargalo.

Detalhes: É possível usar o relatório de teste de carga de provisão que exibe a variação de duração de três períodos para descobrir que período custa mais. Use o gráfico intitulado "Provision a virtual machine component level workflow" para localizar o componente suspeito. Use os recursos de monitoramento existente, por exemplo, o console do Tivoli Service Automation Manager, o console do Tivoli Provisioning Manager e o Tivoli Provisioning Manager DB para obter o tempo de espera e o tempo de serviço de cada provisão. Desenvolva um modelo de fila para localizar o gargalo.

Etapas:

  1. Iniciar as várias provisões usando as ferramentas de teste de referência.
  2. Obter o Tivoli Service Automation Manager e os IDs para essas provisões do banco de dados do portal.
  3. Passar o ID de backend para os scripts SQL para a consulta do banco de dados do Tivoli Provisioning Manager para obter informações de tempo a tempo.
  4. Calcular o número de serviço de solicitação em tempo real, o número de fluxo de trabalho, o tempo de serviço médio e o tempo de espera para cada componente com base nos dados do banco de dados do Tivoli Provisioning Manager.
  5. Desenvolva um modelo de fila junto com o processo de descobrir o gargalo.

Na Figura 5, é possível ver que as 20 provisões enviadas ao mesmo tempo têm um grande desvio do tempo de resposta embora ele solicite o mesmo tipo e tamanho de imagem.

Figura 5. Tempo de provisão total
Tempo de provisão total

Na Figura 6, você vê que o tempo de resposta do período de reserva aumentou dramaticamente o que faz com que o tempo de provisão total aumente.

Figura 6. Tempo de resposta de três provisões
Tempo de resposta de três provisões

O período de envio e o período de provisão têm um tempo de resposta estável, nesse caso, você continua a mapear o segundo período até o fluxo de trabalho do nível de componente para localizar o gargalo.

O segundo período inclui principalmente o tempo de processamento no servidor TSAM/TPM. É possível usar o console do Tivoli Service Automation Manager para procurar as solicitações de serviço e o console do Tivoli Provisioning Manager para procurar os fluxos de trabalho de implementação. Para várias provisões, usar os scripts SQL para acessar diretamente o Tivoli Provisioning Manager DB é a solução mais conveniente.

É possível desenhar um fluxograma (Figura 7) com o tamanho da fila em cada componente baseado no número que você calcular depois de analisar os dados brutos do banco de dados.

Figura 7. O fluxograma mostra cada tamanho de fila relativa ao componente
O fluxograma mostra cada tamanho de fila relativa ao componente

No fluxograma, você vê que o componente de reserva pode ter mais solicitações de espera. O Mecanismo de Implementação do Tivoli Provisioning Manager pode fornecer apenas cinco máquinas virtuais simultaneamente para assegurar o desempenho do hypervisor. Mesmo se você gerenciar para melhorar a capacidade no TSAM/TPM, apenas cinco provisões podem fluir para o hypervisor; mais provisões serão bloqueadas no segundo período.


Para Concluir

O método de teste que minha equipe propôs está baseado na estrutura de provisão geral e pode ser combinada com soluções de monitoramento existentes de diferentes provedores de nuvem para ajudar usuários a localizar problemas de desempenho de fornecimento sem depender dos detalhes fornecidos pelos mecanismos de fornecimento.

Dado o relacionamento de mapeamento entre os fluxos de trabalho de provisão e os componentes, o usuário pode informar o provedor que componente pode ter problemas potenciais de desempenho.

Usando ferramentas e interfaces de monitoramento nativas, um provedor de nuvem pode rapidamente localizar que etapas de provisão em que terminal e que serviço de provisão afetam todo o processo de provisão.

Ainda há melhorias adicionais necessárias nesse método de teste de provisão:

  • Mais métricas e dados de desempenho devem ser coletados e organizados por tempo, local e relacionamento automaticamente; isso pode dar ao usuário um quadro mais claro dos problemas.
  • Mais ferramentas e métodos de monitoramento nativo para diferentes mecanismos de provisão em nuvem devem ser integrados. A relação de mapeamento entre os dados do usuário de front-end com dados de componente de backend será criada automaticamente depois de configurar mecanismos de provisão específicos.
  • Mais atividades de provisão devem ser abordadas por este teste, como fornecimento dinâmico, eliminação e fornecimento de aplicativo.

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=Tivoli, Cloud computing, WebSphere
ArticleID=838499
ArticleTitle=Localizar Gargalos no Desempenho do Fornecimento na Nuvem
publish-date=10012012