Compare o Desempenho de Agentes Virtuais com o de Reais

Execute agentes do Rational Performance Tester em uma MV para comparar os níveis de desempenho do agente

Neste artigo, os autores comparam a execução de agentes do Rational® Performance Tester (RPT) em uma máquina virtual com a execução de agentes RPT em uma máquina "real". Os resultados iniciais mostram que executar em uma máquina virtual tem mais variabilidade nos tempos de resposta informados. A aplicação de ajuste de rede às máquinas virtualizadas reduz a variabilidade e torna aceitável o uso de agentes RPT virtualizados, desde que uma migração de MV não ocorra durante uma execução de desempenho.

Andrew Citron, Senior Programmer, IBM

Andrew CitronAndy Citron trabalha no grupo de desempenho do WebSphere Portal no Research Triangle Park, NC. Sua carreira de mais de 30 anos com a IBM incluiu tarefas criando produtos como o Mwave Multimedia Card e seu subsistema de atendimento telefônico e diferenciação de chamadas, processadores de texto, sistemas operacionais e acesso à Internet wireless. No final da década de 1980, Andy foi arquiteto líder do protocolo de comunicação SNA, conhecido como APPC (ou LU6.2); seu trabalho no grupo de arquitetura SNA lhe rendeu diversas patentes na área de processamento distribuído de two-phase commit.



Gaurav Bhagat, Performance Analyst, IBM

Gaurav Bhagat atualmente trabalha como portal no z/OS System Performance Analyst no IBM Lotus Labs em Dublin, Irlanda. Ele tem mais de nove anos de experiência em tecnologias de mainframe, trabalhando com diversos clientes globais. Ele é IBM Certified Database Administrator: DB2 9 para z/OS, IBM Certified Database Administrator: DB2 UDB V8.1 para z/OS e IBM Certified System Administrator: DB2 9 para z/OS. Ele também é instrutor IBM Certified de DB2 for z/OS Data Sharing e deu aulas nos Estados Unidos, Europa e Ásia.



Marshall Massengill, Holistic Digital Support, IBM

Marshall Massengill trabalha para a organização Centralized IT no IBM Software Group em RTP. Marshall começou a trabalhar na IBM com 17 anos de idade, pouco antes de se formar na North Carolina School of Science and Mathematics (NCSSM). Graduou-se pela NCSSM em 2005 e frequentou a North Carolina State University, onde obteve o título de bacharel em Engenharia da Computação. Sua função principal agora é auxiliar no desenvolvimento e manutenção da infraestrutura de virtualização de TI centralizada. Adora explorar os usos criativos da nova tecnologia que deu origem à capacidade de oferecer suporte e assistência a uma ampla gama de equipamentos e serviços na IBM.



17/Ago/2012

Uma base principal da computação em nuvem é a virtualização. Uma pergunta orientada à nuvem que os designers, desenvolvedores e administradores devem fazer a si mesmos é "como o nível de desempenho de componentes virtualizados se compara a seus equivalentes físicos "reais"?" e "se há uma diferença negativa, como pode ser superada?".

Este artigo descreve os resultados de uma série de experimentos com agentes do IBM® Rational® Performance Tester executando em máquinas virtuais (VM) e oferece alguns insights básicos sobre o argumento virtual versus "real".

Atrás dos experimentos

Explicamos uma série de experimentos em que os agentes do Rational Performance Tester executam em máquinas virtuais e comparamos esses resultados com a execução dos mesmos testes em hardware não-virtualizado. Antes de examinar o ambiente virtualizado que usamos, vamos começar com uma explicação sobre a terminologia utilizada, a metodologia utilizada e um resumo dos resultados.

Terminologia

Muito simples: é possível seguir os experimentos se entender estes termos:

Agente do Rational Performance Tester
Software que simula milhares de usuários fazendo solicitações a um servidor.
Vuser
Usuário virtual. Cada usuário virtual simula muitos usuários durante o curso do teste. Um vuser em execução começa executando o script com uma identidade de usuário exclusivo. Quando o script for concluído, o vuser seleciona outra identidade de usuário exclusivo e executa o script novamente como essa nova identidade de usuário exclusivo. O vuser repete esse processo de seleção de uma nova identidade do usuário e executar o script desde que o vuser esteja executando.
Agente real
Agente RPT executando em hardware não virtualizado.
VM
Máquina virtual. Um agente virtual é um agente RPT executando em uma VM.
vMotion
Quando o gerenciador de MV movimenta a imagem de MV de uma máquina física para outra.
Plataforma
Representa um período de tempo em que o mesmo número de vusers estão ativos durante um teste.
TPS
Transações por segundo. TPS e PPS (páginas por segundo) são utilizados alternadamente, como uma medida de rendimento.
Paravirtualização
Uma técnica virtualização que apresenta uma interface de software para máquinas virtuais que é semelhante, mas não idêntica, à do hardware subjacente.

Metodologia

O mesmo teste de desempenho foi executado diversas vezes utilizando agentes RPT reais e agentes RPT virtualizados.

A referência de desempenho envolveu diversas solicitações de HTTP diferentes executadas por diferentes usuários simulados. A referência e o sistema em teste não são o foco deste artigo. O foco deste artigo são os agentes RPT que geraram a carga simulada.

Cada teste consistiu em três execuções de 5 minutos simulando 2.000 vusers e três execuções de 5 minutos simulando 2.500 vusers. Cada teste foi executado duas vezes com os agentes reais e duas vezes com os agentes virtuais.

Em cada teste, houve cinco máquinas executando agentes RPT. Uma dessas máquinas era uma máquina real e executou apenas 100 vusers. Essa máquina foi utilizada como um ponto de comparação; ela nunca executou o suficiente de uma carga para causar contenção de seus recursos. No entanto, executou vusers suficientes para gerar um tamanho de amostra utilizável. Isto nos permitiu comparar uma máquina real levemente carregada com VMs fortemente carregadas e máquinas reais.

A análise foi executada em execuções de 5 minutos. As três execuções de 5 minutos também foram combinadas com uma plataforma de 15 minutos. Execuções mais longas oferecem mais pontos de dados para cada intervalo. Mais pontos de dados significam maior estabilidade das médias.

Também fizemos um experimento no qual o agente virtual foi transferido de uma máquina física para outra durante um teste de carregamento. Chamamos esse processo de vMotion.

Um resumo dos resultados gerais

No conjunto de testes inicial, os tempos de resposta e o rendimento informados pelos agentes virtuais variaram mais do que os tempos de resposta informados pelos agentes reais. Para referências, onde existem critérios de tempo de resposta, essa variação causa um problema. A subsequente análise e experimentação levaram a uma configuração de ajuste de rede da MV que reduziu a variação do tempo de resposta. Com esse ajuste adequado, as MVs se comportaram aceitavelmente como agentes RPT.

O experimento para o qual o agente virtual foi migrado (vMotion) mostrou um pico no período de resposta informado, enquanto a MV estava em processo de movimentação. A conclusão aqui é que a migração da MV deve ser uma ocorrência incomum; o analista deve saber quando ela ocorreu, porque pode afetar o resultado do teste.

Agora, vamos ver o ambiente virtualizado.


Descrição do ambiente virtualizado

No campo de TI, há sempre mais de um caminho para resolver um determinado problema. Isso é especialmente verdadeiro na área de projeto de uma boa infraestrutura de virtualização, em que as possibilidades são praticamente ilimitadas. É importante entender que o design de infraestrutura descrito aqui não é uma "melhor prática recomendada" ou um "ambiente de modelo", mas, sim, uma tentativa de criar uma solução que funciona para o ambiente de laboratório ao qual ele oferece hospedagem.

Há três partes principais para qualquer infraestrutura de virtualização — servidores, armazenamento e rede. O ambiente usado para estes testes:

  • Servidores. Os servidores consistiram em IBM System x3850 X5s. Esses servidores são carregados com quatro CPUs Intel Xeon X7560 e 512 GB de RAM. Os servidores são agrupados tanto física quanto logicamente em clusters de oito máquinas. Este armazenamento em cluster de máquinas é descrito detalhadamente mais tarde.
  • Infraestrutura de armazenamento. O armazenamento desses servidores consiste em malhas SAN Fibre Channel redundantes. As malhas são feitas redundantes por meio de adaptadores de barramento de host de porta dupla nos servidores e comutadores SAN de topo de rack redundantes. Essas malhas são, então, conectadas a uma malha maior, que consiste em vários uplinks para várias redes conectadas de armazenamento (SAN) do IBM DS5300. Cada conjunto de oito servidores é colocado em um grupo de hosts que só pode atingir determinados números de unidade lógica (LUNs, Logical Unit Numbers) nas SANs. Cada host em um grupo de hosts pode ver apenas o armazenamento disponibilizado para esse grupo de hosts.
  • Infraestrutura de rede. A rede para esses servidores consiste em um link de gerenciamento de 100 MB e quatro links de 1 GB, de um total de cinco conexões Ethernet para cada servidor.
    • O link de gerenciamento de 100 MB é utilizado para comunicação com o módulo de gerenciamento integrado a bordo, que permite acesso do console remoto ao servidor, bem como a capacidade de monitorar o status do hardware.
    • Os quatro links de 1 GB são divididos em dois grupos de duas conexões cada:
      • O primeiro grupo é usado para o tráfego de dados para as máquinas virtuais.
      • O segundo grupo é utilizado para o tráfego de gerenciamento ao servidor host.

O tráfego de gerenciamento é mantido isolado em uma rede interna privada enquanto o tráfego de dados é permitido para uma rede pública maior. Isso foi feito para reduzir a quantidade de tráfego na rede de dados, além de assegurar a segurança do tráfego de gerenciamento. Cada grupo de links é dividido em um link ativo e um link de espera. Essa combinação de links ativos e de espera assegura a redundância.

Para permitir que uma multidão de redes privadas e públicas sejam conectadas, a identificação VLAN é utilizada. Cada pacote saindo de qualquer máquina virtual é identificada com o número VLAN adequado. Isso permite o acesso a um grande número de subredes no ambiente. Também permite que máquinas virtuais sejam transferidas de um cluster de máquinas para outro cluster através de um processo conhecido como migração.

A Figura 1 mostra um diagrama do ambiente virtualizado.

Figura 1. O ambiente virtualizado
O ambiente virtualizado

Os agentes reais eram executados em máquinas Intel® Xeon® que tinham dois processadores de 2,8 GHz e 2 GB de RAM. Essas máquinas tinham uma placa Ethernet de 1 GB.

Os agentes virtuais eram executados no RedHat Linux®. Os agentes reais eram executados no Windows® Server 2003. Teria sido melhor se os agentes virtuais e reais fossem executados no mesmo hardware e software, mas essa não era uma opção. Temos outra prova que indica que os agentes reais executando no Linux mostram menos de 1% de variação para rendimento entre as execuções. Isso é semelhante ao que vimos com os agentes reais do Windows.

A máquina que utilizamos como a máquina real de controle era um Intel Xeon, executando o Windows Server 2003. Ela tinha dois processadores de 3,2 GHz. O HT estava ativado. Houve 3,5 GB de RAM. Tinha uma placa Ethernet de 100 MB e executava apenas 100 vusers. Não precisava ser tão eficiente quanto os outros agentes.


Ilustrando os resultados

Agora vamos mostrar alguns gráficos que ilustram os números por trás das conclusões a que chegamos; vamos mostrar o rendimento e os tempos de resposta antes e depois que o ajuste de rede foi aplicado.

Rendimento e tempos de resposta para a rede não ajustada

O primeiro gráfico (Figura 2) mostra o rendimento e os tempos de resposta informados pelos agentes virtualizados antes que o ajuste de rede fosse aplicado. Ele pode ser comparado com o segundo gráfico (Figura 3), que mostra as mesmas informações para agentes reais. Esses gráficos são provenientes das plataformas da carga de trabalho de 2.500 vusers.

Figura 2. Agentes virtuais, rede não ajustada, 2.500 vusers
Agentes virtuais, rede não ajustada, 2.500 vusers
Figura 3. Agentes reais, rede não ajustada, 2.500 vusers
Agentes reais, rede não ajustada, 2.500 vusers

Os gráficos ilustram que os relatórios dos agentes virtualizados de tempos de resposta e rendimento variaram mais do que os agentes reais:

  • Os tempos de resposta informados pelos agentes virtuais variaram de 188,6 ms a 104,5 ms; ou seja, um intervalo de 48,1 milissegundos.
  • Os tempos de resposta informados pelos agentes reais variaram de 148,4 ms a 120,6 ms; ou seja, um intervalo de 27,8 milissegundos.

A taxa de acerto de página informada pelos agentes de MV variou de 215,9 PPS para 219 PPS. Ou seja, uma diferença de 33,1 PPS para os agentes virtualizados. Os agentes reais informaram um intervalo de 218,5 PPS para 219,3 PPS. Ou seja, uma diferença de 0,8 PPS. Novamente, isso ilustra que os agentes virtuais mostraram uma variação maior que os agentes reais nos dados informados.

Depois de ajustar o adaptador de rede nas MVs

Depois que o primeiro conjunto de testes mostrou alta variabilidade nos tempos de resposta informados pelos agentes virtuais, mudamos o tipo de adaptador de rede virtual que a máquina estava usando.

É possível pensar nisso como comutação do adaptador Ethernet de um sistema físico.

Inicialmente, as máquinas virtuais eram configuradas para utilizar um adaptador "flexível", que é basicamente a forma da VMware de permitir que o adaptador seja escolhido com base nas necessidades do sistema. Esses adaptadores funcionam perfeitamente na teoria, e não tão bem na prática. A VMware descontinuou seu uso, em favor de algo chamado adaptadores vmxnet3 ou vmxnet2. Há também a opção de usar um adaptador de rede virtual E1000, que é basicamente uma Placa de Rede E1000 Intel emulada.

Descontinuamos o uso do adaptador flexível em favor do adaptador VMXNnet3. Isso gerou um aumento de desempenho em todo o tráfego de rede para o sistema. O adaptador VMXNet3 é tecnicamente um adaptador de rede paravirtual. O hardware paravirtual trabalha com a ideia de descarregar tarefas da CPU de host para os recursos físicos do sistema. No caso desses adaptadores Ethernet paravirutais, a carga de trabalho está sendo manipulada pelos adaptadores Ethernet físicos Intel e Broadcom nos hosts, em vez da CPU de hosts. Isso leva a um aumento nos tempos de resposta e rendimento.

Além de fazer essa mudança no hardware, a mudança também foi feita no sistema operacional guest e no driver que ele utiliza para se comunicar com o adaptador. Isso é semelhante a instalar novos drivers em uma máquina física depois de instalar um novo adaptador de rede. O mesmo precisa ser feito em uma máquina virtual.

A Figura 4 mostra que, após aplicar o adaptador VMXNet, os tempos de resposta foram menores que antes. De fato, os resultados com o adaptador VMXNet foram menores que todos os outros testes. O PPS informado também foi ligeiramente maior.

Figura 4. Comparando agentes reais, VMs com/sem o adaptador VMXNet3
Comparando agentes reais, VMs com/sem o adaptador VMXNet3

Este gráfico também não mostra que a variação dos tempos de resposta informados também foi menor com o adaptador VMXNet3. Isso é importante para conseguir reproduzir resultados de execução para execução.

A conclusão é que, com as configurações de rede corretas, um agente virtualizado é tão confiável quanto um agente real para informar tempos de resposta e rendimento.


Clusters e vMotion

vMotion é a tecnologia da VMware que permite que máquinas virtuais sejam migradas ao vivo de servidor para servidor. Isso geralmente é feito para motivos de balanceamento de carga. Em nosso experimento, forçamos uma migração de uma das VMs durante uma das plataformas de 5 minutos. Fizemos isso para determinar o efeito que teria nos dados informados pelos agentes virtualizados.

Cada cluster de servidores compartilha algumas características. Cada agrupamento de oito servidores compartilha o mesmo tipo de hardware. As CPUs, memória, disco e adaptadores são todos iguais em cada máquina em um cluster. Essa semelhança é chave para que o processo de vMotion funcione corretamente.

Clusters de máquinas também compartilham características de configuração, tais como alta disponibilidade e planejamento dinâmico de recursos:

  • A alta disponibilidade é o processo pelo qual as máquinas virtuais são mantidas funcionando para minimizar o tempo de inatividade no caso de falha de hardware. Se um servidor em um cluster enfrentar uma falha, as máquinas virtuais desse servidor são imediatamente colocadas de volta online em um servidor diferente nesse cluster. Isso minimiza qualquer tempo de inatividade como resultado de uma interrupção de serviço.
  • Planejamento dinâmico de recursos é o processo pelo qual as máquinas virtuais são dinamicamente movidas entre os servidores em um cluster com base em suas necessidades de recursos e na disponibilidade de recursos para uso dos mesmos. Se uma máquina virtual precisar de recursos de CPU em um host que tem muito poucos recursos disponíveis, essa máquina virtual será migrada para um host diferente em que há recursos de CPU disponíveis. Como alternativa, as máquinas virtuais que têm menos necessidade de recursos geralmente são migradas para liberar espaço para máquinas virtuais que precisam consumir mais recursos.

O processo de vMotion funciona migrando uma máquina virtual de um estado de execução atual de um host para outro dentro em um cluster. A máquina virtual é mantida executando enquanto esse processo está acontecendo e, como resultado, as máquinas virtuais experimentam praticamente nenhuma interrupção.

Em nossos testes, observamos que os usuários finais experimentam, na pior das hipóteses, um desligamento curto, não diferente da perda de um ou dois pacotes por falhas de transmissão de rede. Trata-se de uma interrupção aceitável para executar integração, usabilidade, funcionalidade e outros tipos de testes, mas não para testes de desempenho em que um único pacote eliminado pode distorcer o resultado. Vmotion frequente também pode ser um problema em um ambiente de produção que tem acordos de nível de serviço estritos.

O planejamento dinâmico de recursos e a alta disponibilidade podem utilizar o processo de vMotion para migrar máquinas virtuais executando em um host para outro, para fornecer proteção contra falha ou atender às necessidades imediatas de recursos de uma máquina virtual. A Figura 5 mostra nosso ambiente virtualizado com a migração vMotion em processo.

Figura 5. Migração vMotion no ambiente virtualizado
Migração vMotion no ambiente virtualizado

Em circunstâncias normais, o vMotion não ocorre frequentemente. Sentimos que um experimento realista era migrar um de quatro VMs que utilizamos durante o teste. Também tínhamos um quinto agente real que estava executando 100 vusers. Usamos esse agente como um controle para ter alguma ideia dos tempos de resposta informados por um agente que não devem ser afetados pelo vMotion.

O efeito da migração da MV era aparente e durou cerca de um minuto. Os gráficos a seguir ilustram isso.

A Figura 6 mostra o relatório de um agente de MV durante a migração. Isso foi utilizado na plataforma de 2.000 vusers.

Figura 6. Tempo de resposta da página; o aumento era inválido
Tempo de resposta da página; o aumento era inválido

O aumento no tempo de resposta em que o VMotion ocorreu é aparente. Esse tipo de aumento, causado pela infraestrutura de virtualização, durante uma execução de teste de desempenho é inaceitável.

Em seguida, veja o vMotion quando analisado como plataformas de 15 minutos (Figura 7).

Figura 7. Uma plataforma mais longa proporciona uma média mais estável
Uma plataforma mais longa proporciona uma média mais estável

Quando mais longa a plataforma, mais estável será a média que oferecerá, além de minimizar o efeito da migração da VM. No entanto, você ainda pode ver que o vMotion causou tempos de resposta maiores a serem informados nos agentes virtualizados. Este gráfico informa o tempo médio de resposta geral em comparação com o tempo de resposta no único agente real executando 100 vusers.

O gráfico da Figura 7 mostra que a única MV migrando teve um efeito sobre os tempos médios de resposta informados. Embora três das quatro MVs não tenham sido migradas, o maior tempo de resposta informado pela migração da MV fez com que o tempo médio de resposta fosse maior do que o informado pelo agente real do grupo de controle.

O que não pode ser visto na Figura 7 é que o impacto da migração da MV não teve impacto sobre os tempos de resposta informados por todos os agentes. Presumivelmente, isso foi causado por um gargalo no servidor em teste que não conseguiu concluir as solicitações que eram iniciadas pela migração da VM, até que a migração dessa MV foi concluída.

Em geral, é melhor se o vMotion puder ser desativado nos agentes virtualizados. Ao executar um teste de desempenho, qualquer origem não controlada de variação é um problema.

Se você não puder desativá-lo, é importante conseguir determinar se o vMotion ocorreu durante um teste. A infraestrutura de virtualização fornece logs que podem ser examinadas para determinar se a migração ocorreu. A captura de tela (Figura 8) é da visualização dentro do software cliente de infraestrutura virtual das tarefas e eventos para uma das VMs em que o processo de migração foi executado. Os logs indicam claramente que a tarefa de migração foi executada juntamente com quem iniciou a tarefa e quando a tarefa foi concluída.

Figura 8. Logs como uma fonte para determinar se o vMotion ocorreu (se não for possível desativá-lo)
Logs como uma fonte para determinar se o vMotion ocorreu (se não for possível desativá-lo)

(Consulte uma versão maior da Figura 8.)

Se o sistema estivesse movendo dinamicamente as máquinas virtuais com base no carregamento, então a tarefa teria sido iniciada pelo sistema, e não por um usuário (neste caso, VISRTP/marshall). Essas informações de log podem também ser reunidas ou verificadas programaticamente com as APIs da VMware e utilitários de script.

É importante observar que o planejamento dinâmico de recursos pode ser desativado para determinadas máquinas virtuais em um determinado ambiente. Isso aumenta o risco de que o tempo de atividade de uma máquina virtual seja afetado com base em uma indisponibilidade do host, mas, para uma equipe de desempenho, manter o desempenho constante é mais importante do que a possibilidade de uma indisponibilidade.


Conclusão

A virtualização dos agentes do Rational Performance Tester é uma configuração viável; no entanto, é importante certificar-se de que o ambiente virtualizado esteja ajustado corretamente. A configuração da placa de rede foi crítica em nosso ambiente.

Para uma avaliação de comparação, é melhor ter os agentes não virtualizados que estão executando hardware e sistema operacional equivalentes como os agentes virtualizados. Porém, para a determinação de problema, é recomendável ter um conjunto de agentes reais, de preferência executando um sistema operacional diferente do que os agentes virtualizados. Descobrimos que os agentes reais são um grupo de controle útil quando ocorreram problemas ou gargalos. Mas, executando um teste com os agentes reais, conseguimos estabelecer que a MV era uma causa de problemas.

Se a migração da MV ocorreu durante um teste, é importante que o analista esteja ciente disso. O monitoramento automatizado das VMs é preferível. A melhor alternativa é desativar o vMotion nos servidores que estão hospedando os agentes RPT.

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, Rational
ArticleID=833276
ArticleTitle=Compare o Desempenho de Agentes Virtuais com o de Reais
publish-date=08172012