Inteligência com virtualização

Parte 1. Melhores práticas com o software IBM Rational

Se atualmente você estiver usando métodos de virtualização com o software IBM Rational, está tudo funcionando tão bem quanto esperava? Três especialistas da IBM explicam a perspectiva do Rational sobre a virtualização e os principais requisitos para ambientes virtualizados a fim de obter o desempenho ideal de aplicativos do Rational. Eles também compartilham dados de dois casos de referência e dicas para resolução de problemas.

Mike Donati, ClearCase Performance Team Lead, IBM

author photoMike Donati mora nas proximidades de Boston, onde trabalha em implementações de clientes e desempenho do IBM Rational ClearCase, incluindo estratégias de virtualização. Quando não está trabalhando, ele divide seu tempo entre viagens com a família, culinária, fotografia e participação em eventos esportivos de suas filhas.



Ryan Smith, Software Performance Analyst, IBM

author photoRyan Smith trabalha em engenharia de desempenho há oito anos. Ele mora em uma cidadezinha na área agrícola do Tennessee ocidental, de onde colabora remotamente com colegas em todo o mundo sobre desempenho e confiabilidade da solução Rational para Collaborative Application Lifecycle Management (CLM). Profissionalmente, seus interesses são o desenvolvimento agile e lean de software, testes de desempenho, tecnologias Java e da web, análise de dados e visualização de dados. Em seu tempo livre, ele caça, pesca, gosta de ler sobre sustentabilidade, liderança e organização, e passa tempo com sua esposa e em atividades da igreja.



Grant Covell, Senior Development Manager, Rational Performance Engineering, IBM Corporation

Grant Covell photoGrant Chu Covell trabalha com o software IBM Rational em assuntos relacionados ao desempenho por quase 10 anos. Agora ele é Senior Performance Obsessor da equipe Jazz Jumpstart. Antes disso, ele gerenciou a equipe de Rational Performance Engineering. Anos atrás, ele fez um trabalho de desenvolvimento de software em fontes, software de notação musical e tradução automática de idiomas. Ele mora nas proximidades de Boston. Acompanhe o blog da equipe Jumpstart, chamado Ratl Perf Land.



08/Jul/2013

Hoje só se fala em virtualização. Se acreditarmos em todo esse alarde, a virtualização revolucionará a TI como conhecemos, otimizará recursos escassos e economizará o dinheiro de todos. A virtualização de servidores promete ser um dos desenvolvimentos mais importantes da década. No entanto, a virtualização já existe por algum tempo, e a IBM é líder nesse assunto por meio das plataformas IBM® System z® e Power Systems™ . Nos últimos anos, a tecnologia de virtualização em System x® e na arquitetura x86 baseada na Intel amadureceu e se tornou mais difundida. Usada de forma adequada, a virtualização é parte essencial da caixa de ferramentas de TI. Não restam dúvidas de que a virtualização chegou para ficar.

Mas toda tecnologia tem seus riscos. Virtualização mal gerenciada pode fazer os aplicativos serem executados mais lentamente, o que pode deixar os clientes que são usuários finais incomodados e insatisfeitos. A IBM fornece suporte total aos seus produtos implementados em ambientes virtualizados. Talvez por causa de sua onipresença e promessas atraentes, alguns clientes se tornaram vítimas de ambientes virtualizados mal gerenciados e, assim, deixaram de perceber seus benefícios prometidos.

Este artigo em duas partes discute os prós e contras da virtualização por meio de exemplos concretos. Na Parte 1, explicamos a virtualização em alto nível, especialmente no que se refere ao software IBM Rational. Tratamos dos principais requisitos de um ambiente virtualizado bem gerenciado e mostramos exemplos de como o IBM ® Rational® ClearCase® e o IBM® Rational Team Concert™ se comportam em ambientes virtualizados com configuração ruim. Oferecemos sugestões e dicas para gerenciar corretamente sua infraestrutura virtualizada, baseando-se em nossa experiência ao testar o software Rational e ao aconselhar os clientes.

A Parte 2 continua nossa discussão de sugestões, recomendações e dicas e inclui resolução de problemas e exemplos específicos de fornecedores.

Breve história da virtualização

Apesar de ter chamado mais a atenção nos últimos anos como uma tecnologia imprescindível e necessária, a virtualização de servidores na verdade já existe há algum tempo. Nos anos 70, a IBM apresentou a tecnologia de hypervisor nas linhas de produtos System z e System i® . As partições lógicas (LPARs) foram disponibilizadas no System p® em 2000. O surgimento de máquinas virtuais no System x e em hardware x86 baseado na Intel se tornou possível já em 1999. Apenas nos últimos anos é que a virtualização se tornou essencial e inevitável em ambientes Microsoft Windows e Linux.

Previsão com nuvens

A virtualização muitas vezes é ligada à tecnologia na nuvem. É importante entender o relacionamento entre elas. Em termos mais amplos, a tecnologia na nuvem refere-se a entregar capacidade de servidor como um serviço. A virtualização é uma técnica fundamental para gerenciar os recursos de servidor que fornecem essa capacidade.

Precisamos também distinguir entre nuvens públicas e particulares. Em termos simples, as nuvens particulares são isoladas e podem ser gerenciadas e hospedadas dentro de uma empresa ou, em alguns casos, externamente. As nuvens particulares são protegidas com firewalls, autenticação, VPNs e assim por diante. As nuvens públicas costumam ter muito menos segurança e, para todos os efeitos, podem ser visualizadas, compartilhadas e acessadas por qualquer pessoa. Muitos serviços públicos populares são entregues "na nuvem", como email e armazenamento de arquivos e fotos. O modelo de nuvem pública atrai algumas organizações porque, em teoria, organizações ou indivíduos pagam apenas pelo que precisam, os serviços estão sempre disponíveis em qualquer lugar e o provedor em nuvem cuida da maioria das tarefas de gerenciamento de TI.

Descobrimos que alguns clientes do IBM Rational fogem da possível instabilidade e das preocupações com segurança dos ambientes de nuvem pública. Eles preferem a abordagem de nuvem particular hospedada internamente e gerenciada mais de perto, no qual podem controlar todos os aspectos de alocação de recursos do servidor, definir metas de qualidade de serviço específicas e empregar soluções comprovadas de alta disponibilidade e de recuperação de desastres.

No entanto, alguns preferem as soluções baseadas na nuvem IBM porque são projetadas e gerenciadas usando as melhores práticas para o desenvolvimento de software e as estratégias de hosting (IBM SmartCloud Enterprise). A IBM também oferece o software Rational em implementações na nuvem particular, por meio do IBM CloudBurst, por exemplo. (Consulte a seção Resources para obter mais informações sobre essas opções.).


Conceitos básicos

Para simplificar, a virtualização permite colocar um servidor maior (o host ou hypervisor) em servidores menores (os guests, clientes ou máquinas virtuais) e compartilhar o conjunto combinado de recursos. É bem sabido que a maioria dos servidores não opera em plena capacidade o tempo inteiro. Portanto, por que não compartilhá-los e combiná-los? Dois servidores com capacidade média de 25% podem se tornar máquinas virtuais (VMs) e ser hospedados em um único hypervisor que teria, então, capacidade média de cerca de 50%. Naturalmente, o sistema operacional do host e o software do hypervisor contribuem para sobrecarga mensurável, e há também outros detalhes envolvidos.

O host gerencia os recursos dos clientes por meio de software ou emulação. Em geral, nada na máquina virtual indica que ela é, de fato, virtual. Na maioria dos casos, os administradores que estão instalando software em máquinas virtuais não conseguem dizer que estão usando servidores virtuais. Inovações mais recentes, como a tecnologia de virtualização integrada no chipset do hypervisor, permitem manipular os recursos de hardware, como drivers de periféricos, de forma mais precisa e otimizada.


Perspectiva do Rational na virtualização

IBM oferece suporte à virtualização e, com isso, os produtos IBM Rational são suportados em servidores virtualizados. No entanto, insistimos que a infraestrutura virtualizada seja adequadamente gerenciada e monitorada. É crucial entender como sua infraestrutura virtualizada usa afinidade e supercomprometimento e ter certeza de estar usando-os de forma a assegurar o melhor desempenho do seu software IBM Rational.

O que é essa coisa chamada "afinidade"?

Afinidade (também chamada de titularidade,pinning, dedicação) é a capacidade de dedicar um ou mais recursos em uma máquina virtual (memória ou processador, por exemplo) aos recursos correspondentes no hypervisor. O host distribui os recursos à medida que as máquinas virtuais necessitam deles. A afinidade assegura que os recursos solicitados dedicados a essa máquina virtual estejam sempre disponíveis quando a máquina virtual os exigir.

Lembre-se de que as máquinas virtuais compartilham recursos do sistema com todas as outras máquinas virtuais no mesmo host.

Supercomprometimento é quando a quantidade total de alocação de recursos de imagem virtual ultrapassa os recursos físicos do hardware (não se esqueça de contar os recursos do hypervisor também). Para satisfazer as necessidades de pico de uma máquina virtual, o hypervisor pode tirar recursos de outras máquinas virtuais. Às vezes, as necessidades combinadas de todas as máquinas virtuais podem ultrapassar os recursos reais do hypervisor. Às vezes, o supercomprometimento pode fazer todas as máquinas virtuais de um host sofrer.


Quatro dimensões da virtualização

Como acontece com qualquer tecnologia configurável, ganha-se em alguns pontos e perde-se em outros. Da perspectiva do produto Rational, se alguém usa virtualização, sugere-se que fique de olho em quatro dimensões fundamentais. Essas dimensões são talvez a característica mais significativa de qualquer servidor:

  • CPU, memória
  • Entrada/Saída (E/S) de disco
  • Armazenamento
  • Rede
Tabela 1. Quatro dimensões da virtualização
 Piores características (não gerenciadas) da virtualizaçãoMelhores características (gerenciadas) da virtualização
CPU
  • Chipset sem suporte a VT ou chip V
  • Conjunto de recursos compartilhados
  • Sem titularidade, ou planejamento garantido ou priorizado
  • Capacidade desconhecida de outras VMs
  • vCPUs são frações das CPUs físicas
  • Emulação de hyperthreading ou multiencadeamento (sem classe Nehalem)
  • Chipset com suporte a VT
  • Afinidade da CPU permite que as VMs usem as vCPUs de forma dedicada
  • vCPUs alocadas e igualadas à CPU física
Memória
  • Memória e CPU não colocalizadas
  • O supercomprometimento resulta em troca excessiva (incluindo com outras VMs)
  • Afinidade definida
  • Memória e CPU colocalizadas
E/S de disco e armazenamento
  • Disco SATA ou IDE local único com IOPS baixo
  • RAID local, mas número limitado de compartimentos de unidade
  • Número desconhecido de canais acessam o mesmo armazenamento
  • Conexão Fibre Channel com o armazenamento
  • Armazenamento de arquivo
Rede
  • Porta de rede 1 G (ou inferior) única compartilhada por todas as VMs
  • Porta de rede dedicada
  • Rede de 10 G ou superior
  • Agregação de link

CPU

As CPUs modernas foram projetadas tendo em mente a virtualização. Por exemplo, as tecnologias de chips VT da Intel e V da AMD asseguram que as CPUs x86 possam manipular de forma ideal a carga virtualizada. Outras plataformas podem usar virtualização assistida por hardware, que promete virtualização mais eficiente pelo endereçamento direto de CPUs de host.

No ambiente de virtualização com pior gerenciamento, o hardware real e a CPU não suportam a virtualização ou o fazem apenas por emulação e contando com uma camada de software mais lenta. No ambiente com pior gerenciamento, não é feito esforço para rastrear outras VMs. Na verdade, outras VMs podem roubar livremente os ciclos de CPU de outras VMs. As CPUs fracionadas às vezes são possíveis ou inevitáveis, mas em um ambiente virtualizado com gerenciamento ideal, as VMs têm acesso a CPUs físicas inteiras.

Memória

No ambiente de virtualização com pior gerenciamento, a memória do servidor e as CPUs não estão no mesmo barramento. O hardware moderno usa acesso à memória não uniforme (NUMA), por meio do qual um processador pode acessar a memória local mais rapidamente do que a memória localizada remotamente, em outro barramento. Em hardware moderno, não faz sentido trabalhar contra a arquitetura NUMA, projetada para velocidade e escalabilidade.

Fique atento às opções e configurações que seu software de virtualização possa oferecer, porque muitas vezes é fácil neutralizar a arquitetura NUMA inerentemente eficiente. Pode parecer útil fazer a memória no local A referir-se à CPU no local B, mas isso cria trabalho extra para o servidor e pode resultar em diminuição do desempenho. Na VM com gerenciamento ideal, a memória e a CPU estão no mesmo barramento.

E/S de disco e armazenamento

No ambiente de virtualização com pior gerenciamento, uma única unidade local suporta todas as VMs. Visto que vários servidores estão compartilhando o mesmo disco, a atividade de E/S real ocorre em mais locais no disco. É possível que uma unidade de disco rígido local sofra falha mais cedo simplesmente por causa do aumento da atividade. O ideal é que as VMs sejam alocadas em unidades específicas, cada qual com sua própria E/S e mecanismos. Em alguns ambientes ideais, o armazenamento pode ser em arquivadores, que são adequados às exigências de virtualização, e acessado por meio de Fibre Channel.

Rede

Provavelmente é fácil imaginar uma configuração de rede com virtualização ruim. As placas de rede são medidas por sua capacidade (1 Gb/s, por exemplo). Quando compartilhadas pelas VMs, sua capacidade é subdividida (2 VMs compartilhando 1 Gb receberiam, no máximo, 500 Mb/s). O ambiente de virtualização com pior gerenciamento tem uma única placa de rede ou a porta para todas as VMs que hospeda, e o rendimento total é dividido entre as VMs. Em um ambiente virtualizado com gerenciamento ideal, cada VM tem uma porta de rede dedicada ou então uma conexão da rede de 10 Gb ou superior é compartilhada pelas VMs. Agregação de link é uma técnica de rede em que várias conexões de rede são usadas em conjunto para otimização de redundância e rendimento.


Melhores características (gerenciadas) da virtualização

Para obter o melhor ambiente de virtualização, com gerenciamento ideal, podemos resumir os pontos anteriores de forma concisa:

  • O número de CPUs virtuais nunca ultrapassa o número de CPUs físicas.
  • A alocação da CPU para cada VM corresponde às CPUs físicas reais.
  • A quantidade de RAM virtual nunca ultrapassa a quantidade de RAM real.
  • Há amplo acesso ao armazenamento e rede.

Alguns podem argumentar que esse conselho anula o sentido da virtualização ou que estamos sendo cautelosos demais. Em um mundo ideal, cada VM teria acesso a recursos ilimitados sob demanda. Contudo, no mundo real, as VMs precisam compartilhar recursos. Descobrimos que o software Rational tem o melhor desempenho e se comporta de forma mais eficaz em servidores virtualizados quando os recursos são gerenciados de perto para garantir que sempre haja CPU dedicada, memória e outros recursos.

Se bem gerenciada, a alocação de recursos com supercomprometimento pode ser uma estratégia de virtualização viável, mas apenas se houver monitoramento rigoroso dos recursos reais usados. Quando ocorre supercomprometimento, a organização deve estar disposta a aceitar desempenho lento ou imprevisível ou então custos de administração otimizados.


É como brincar de dança das cadeiras

Em um ambiente de virtualização com gerenciamento ruim, as máquinas virtuais podem compartilhar indiscriminadamente os recursos do host. Qualquer VM pode pedir mais memória ou CPU do que foi alocado, e o hypervisor mal gerenciado as fornecerá, fazendo divisão em fatias de tempo das solicitações de outras VMs.

É como brincar de dança das cadeiras. É possível que um único servidor de 16 processadores e 64 GB de RAM sirva de host para cinco servidores distintos de 4 processadores e 16 GB de RAM. Quando a máquina virtual A exige ciclos de processador, ela solicita isso ao host. O host obterá tempo do processador não utilizado de qualquer uma das outras quatro VMs ou gravará dados das outras VMs em disco para liberar recursos.

Esse modelo pode funcionar perfeitamente bem se os cinco servidores nunca operarem em alta capacidade ao mesmo tempo. Processos de backend que os usuários finais nunca veem podem ser executados mais lentamente e com mais interrupções. No entanto, os aplicativos essenciais para os negócios que os usuários finais tocam provavelmente mostrarão os efeitos do supercomprometimento quando seus aplicativos começarem a travar ou ficarem lentos.


Estudo de caso N.° 1. "Menu Misterioso", o Rational Team Concert em três nuvens com gerenciamento ruim

A equipe do IBM ® Rational® Performance Engineering explorou três imagens de VM fornecidas por um provedor da nuvem. Cada imagem era diferente, como se escolhêssemos partes pequenas, médias e grandes de um menu. Sabíamos muito pouco sobre as especificações reais das VMs (tipo de armazenamento, rede, velocidade do processador e assim por diante), a não ser o número teórico de CPUs virtuais e a memória fornecida com cada VM.

A VM A tinha 4 CPUs virtuais e 8 GB de RAM; a VM B, 8 CPUs virtuais e 16 GB de RAM; a VM C, 16 CPUs virtuais e 16 GB de RAM. Nossa intenção era fornecer a mesma quantidade de carga a cada imagem e ver como os diferentes tamanhos de imagem se comportavam.

Fornecemos uma carga multiusuário simulada para a VM A (4 vCPU, 8 GB) e rapidamente atingimos 100% da capacidade de CPU e de memória. O desempenho foi bastante aceitável, mas queríamos melhorá-lo. Se tivéssemos utilizado máquinas físicas, teríamos imediatamente aumentado o número de núcleos e a quantidade de memória RAM, e foi isso que fizemos.

Fornecemos a mesma carga à VM B (8 vCPU, 16 GB) e os resultados nos surpreenderam: o desempenho se degradou drasticamente, mas foram usadas proporcionalmente menos CPU e memória. A CPU e a memória não eram mais o gargalo. Em vez disso, o gargalo foi o E/S de disco.

Quando fornecemos a mesma carga à VM C (16 vCPU, 18 GB), o desempenho ficou ainda pior, e a proporção de CPU utilizada diminuiu novamente. O gargalo ainda era o E/S de disco. (Para maior clareza, usamos uma média do E/S de disco em cada teste e expressamos a média em incrementos de 25%.)

Figura 1. Três VMs em uma nuvem sem gerenciamento
Três VMs em uma nuvem sem gerenciamento

Nossa explicação é que essas imagens eram hospedadas em uma nuvem não gerenciada e as VMs maiores, B e C, estavam na verdade roubando núcleos e memória de outras VMs. Sem saber como o hypervisor era gerenciado, podemos apenas especular que os recursos com supercomprometimento resultaram em troca de disco. As CPUs eram subutilizadas porque o sistema passava a maior parte do tempo gravando outras imagens no disco para obter os recursos que nossa VM estava pedindo. (Supomos que nossas imagens também estavam sendo gravadas no disco quando as outras VMs estavam pedindo ciclos e RAM.)

A Figura 2 oferece outra maneira de encarar os mesmos dados, mostrando resultados de memória, CPU e disco não utilizados e utilizados. Isso talvez explique com mais clareza o que estava acontecendo.

Figura 2. Outra análise das mesmas três VMs
Outra análise das mesmas três VMs

Na Figura 2, representamos graficamente as três VMs para que as quantidades de CPU e de memória fossem proporcionais uma à outra, e usamos wickets ou barras vazias no gráfico para indicar a CPU não utilizada e a capacidade de memória nas três VMs. A VM A está usando toda a sua CPU e memória alocadas, mas não muito disco. A VM B tem acesso a mais CPU e memória, mas é incapaz de usá-las todas, devido ao gargalo criado pelo aumento da atividade do disco. A VM C oferece mais CPU, que é apenas ligeiramente usada pela VM porque, como na VM B, a VM C tem um gargalo no disco.

Quem se lembra do gerenciamento de ambientes físicos talvez fique surpreso com esses resultados. Na maioria dos casos com hardware físico, o aumento da CPU e da memória também aumentava o desempenho. No entanto, em um ambiente virtualizado mal gerenciado, em que a CPU e a memória são ilimitadas, o aumento da CPU e da memória de uma VM às vezes resulta em desempenho mais lento.

Nossas conclusões

Nossa primeira conclusão é a de reafirmar que, em uma VM adequadamente gerenciada, o software Rational será executado corretamente. O estudo de caso 1 forneceu exemplos de um aplicativo com comportamento ruim em uma nuvem não gerenciada.

Segundo, reafirmamos que VMs devem ser usadas em um ambiente gerenciado . Nesse estudo de caso, não tínhamos conhecimento do hypervisor ou outras VMs no ambiente. Acreditávamos que nosso desempenho era determinado pela configuração e o comportamento de outras VMs no mesmo ambiente, mas não podíamos ter certeza.

Terceiro, alertamos contra suposições de que os mesmos princípios que funcionam em hardware físico também funcionarão dentro do ambiente de VM. Se houvesse excesso de recursos de CPU e memória, o aumento do tamanho das VMs poderia ter produzido uma melhora, mas estávamos realmente causando o supercomprometimento dos recursos.

Por fim, repetimos o ponto de que o supercomprometimento de recursos resulta em VM ruim e, com isso, em desempenho ruim de aplicativos. Nesse exemplo, nosso aplicativo foi o Rational Team Concert, mas já observamos outros softwares Rational funcionar mal em ambientes com gerenciamento ruim, independentemente da tecnologia de virtualização e do sistema operacional.


Estudo de caso N.° 2. "Qual a importância da afinidade?" ClearCase é uma nuvem com supercomprometimento e uma carga não autorizada

Nosso próximo exemplo foi demonstrado ao vivo durante uma conferência. Ilustramos como a configuração de afinidade (às vezes chamada de titularidade ou recursos dedicados) pode estabilizar aplicativos IBM Rational, mas não usar a afinidade pode permitir que outras imagens de VM assumam recursos e retardem o desempenho do aplicativo até ele quase parar.

Usamos um servidor Intel Sandy Bridge com 32 CPUs virtuais e 32 GB de RAM que serviu de host para duas implementações separadas do IBM® Rational® ClearCase® . Cada implementação do ClearCase consiste em VMs Red Hat Enterprise Linux (RHEL) 5.5 idênticas (4 vCPUs, 8 GB de RAM) com um servidor ClearCase VOB e um servidor ClearCase CM servindo de hosts para visualizações na web. Usamos VMware ESX como host das VMs. As VMs que servem de host do ClearCase na Implementação A não usam afinidade; as VMs de ClearCase na Implementação B têm afinidade de CPU e de memória. Fora da nuvem, no hardware físico, usamos dois ambientes de trabalho do IBM® Rational® Performance Tester para acionar uma simulação de carga de 100 usuários em cada implementação.

No servidor ESX, criamos várias VMs cujo único propósito era criar demanda para a CPU, a memória e o disco. Essas VMs continham programas simples que executam cálculos matemáticos e alocam toda a memória livre, resultando em 100% de uso da memória e da CPU. Nós forçamos esses programas para criarem supercomprometimento do servidor ESX em até 300%. (Fizemos essas VMs não autorizadas usar três vezes a quantidade de CPUs e memória físicas do hypervisor.)

As Figuras 3 e 4 foram tiradas do Rational Performance Tester. Elas mostram os tempos médios de resposta (medidos em milissegundos) das transações do ClearCase executadas pela Implementação A e pela Implementação B. Ambas as implementações se comportaram de forma consistente até por volta da marca de 1.200 segundos, quando ativamos os programas na VMs não autorizadas. A Implementação A, em que a VM do ClearCase foi executada sem afinidade, apresentou um súbito aumento nos tempos de resposta. A Implementação B, em que a VM do ClearCase VMs foi executada com afinidade, apresentou lentidão ocasional, mas se manteve relativamente constante, exceto por alguns picos. Por volta da marca de 4.000 segundos, as imagens não autorizadas foram paradas e a Implementação A voltou ao normal. (Note que a escala do eixo y, que mostra os tempos de resposta de transação médios medidos em milissegundos, não é igual nos dois gráficos.)

Figura 3. Implementação A sem afinidade
Implementação A sem afinidade
Figura 4. Implementação B com afinidade de CPU e memória
Implementação B com afinidade de CPU e memória

Comparando os testes, as operações do ClearCase na Implementação A sem afinidade levaram em média 118 segundos para ser concluídas em comparação com a Implementação B com afinidade, em que levaram em média 18 segundos. A Implementação B com afinidade foi, em média, seis a sete vezes mais rápida.

Nossas conclusões

O estudo de caso 2 talvez seja extremo, porque criamos uma carga de VM não autorizada que pode ter sido irrealista. No entanto, fomos capazes de mostrar claramente como o desempenho de um aplicativo pode ser degradado se não soubermos o que mais o hypervisor está fazendo ou se as outras VMs precisarem solicitar recursos.

Configurar a afinidade de processador e memória permitiu que os aplicativos na VM que nos preocupavam mantivessem desempenho e comportamento consistentes, mesmo quando o restante das VMs no ambiente executavam cargas extremas.

Note que, na Implementação A sem afinidade, o desempenho não voltou ao normal após as VMs não autorizadas serem interrompidas. Se houver VMs em seu ambiente que são autorizadas a serem executadas com supercomprometimento ou sem limite, pode ocorrer um comportamento semelhante nelas.

Nesse exemplo, nosso aplicativo Rational foi o ClearCase, mas já observamos outros softwares Rational funcionar mal em ambientes com gerenciamento ruim, independentemente da tecnologia de virtualização e do sistema operacional.


A virtualização veio para ficar, por isso, aprenda a usá-la sabiamente

Não há dúvida de que a virtualização veio para ficar. Cada vez mais, os clientes do IBM Rational a usam e dependem dela. No entanto, como vimos, a virtualização pode ser usada mal, com efeitos prejudiciais para a operação do software.

É importante compreender a virtualização e saber gerenciá-la. Esperamos que nossos estudos de caso tenham demonstrado alguns dos possíveis efeitos colaterais de ambientes virtuais mal gerenciados. É possível reconhecer os sintomas de ambientes virtualizados mal gerenciados depois de considerar nossos estudos de caso. Na Parte 2, exploraremos outros sintomas de uma virtualização ruim. Também ofereceremos dicas de resolução de problemas e apresentaremos exemplos específicos de fornecedores.

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=Rational
ArticleID=936267
ArticleTitle=Inteligência com virtualização
publish-date=07082013