Comparing ESXi 4.1 and ESXi 5.0 Scaling Performance

In previous articles on VROOM! we used VMmark 2 to investigate the effects of altering a single hardware component, such as a storage array or server model, in a vSphere cluster. In contrast to these earlier studies, we now examine the effects of upgrading the hosts’ software from ESXi 4.1 to ESXi 5.0 on the performance of a VMmark 2 cluster.

vSphere 5 includes many new features and virtual machine enhancements, the details of which can be found here. To the IT professional weighing the costs and benefits of upgrading their existing infrastructure to vSphere 5, an often important question is whether ESXi 5.0 can outperform ESXi 4.1 in the same environment. VMmark 2 is an ideal tool for answering this question with measurable results. We used VMmark 2.1.1 to see how ESXi 5.0 stacked up to ESXi 4.1 on an identically configured cluster.

VMmark 2 is a multi-host virtualization benchmark that models application performance as well as the effects of common infrastructure operations such as vMotion, Storage vMotion, and virtual machine deployments. Each VMmark tile contains a set of VMs running diverse application workloads as a unit of load. VMmark 2 scores are computed as a weighted average of application workload throughput and infrastructure operation throughput. For more details, see the overview, release notes for VMmark 2.1, and for 2.1.1.

Testing Methodology

All VMmark 2 tests were conducted on a cluster of four identically configured entry-level Dell Power Edge R310 servers. To determine the impact of the vSphere 5 environment on performance, a series of tests was conducted with these hosts running ESXi 4.1, then with ESXi 5.0. In addition, for the vSphere 5 environment, the virtual machine hardware and VMware Tools were upgraded on all workload VMs, and LUNs were reformatted as VMFS5. All other components in the environment remained unchanged during testing.

Configuration
Systems Under Test: Four Dell PowerEdge R310 Servers
CPUs: One Quad-Core Intel® Xeon® X3460 @ 2.8 GHz, hyper-threading enabled per server
Memory: 32GB DDR3 ECC @ 800 MHz per server
Storage Array: EMC VNX5500
Hypervisors under test:
VMware ESXi 4.1
VMware ESXi 5.0
Virtualization Management: VMware vCenter Server 5.0
VMmark version: 2.1.1

Results

To characterize cluster performance at multiple load levels, we increased the number of tiles until the cluster reached saturation, defined as when the run failed to meet Quality of Service (QoS) requirements. Scaling out the number of tiles until saturation allows us to determine the maximum VMmark 2 load the cluster could support and to compare the ESXi 4.1 and ESXi 5.0 configurations at each level of load.

The graph below shows the results of the VMmark 2 testing as described above with identically configured clusters running ESXi 4.1 and ESXi 5.0. All data points are the mean of three tests in each configuration.

1

The ESXi 4.1 cluster reached saturation at 3 tiles, but ESXi 5.0 was able to support 4 tiles while still meeting workload Quality of Service requirements. The ESXi 5.0 cluster also outperformed ESXi 4.1 by 3% and 4% on the two and three-tile runs, respectively. Differences in CPU utilization were negligible. The results show that, in an equivalent environment, vSphere 5 handled greater load than ESXi 4.1 before reaching saturation, and showed increased performance at lower levels of load as well. At saturation, vSphere 5 showed a 22% increase in overall VMmark 2 scores over ESXi 4.1. In this cluster, vSphere 5 supported 33% more VMs and twice the number of infrastructure operations while meeting Quality of Service requirements.

VMmark 2 scores are based on application and infrastructure workload throughput, while application latency reflects Quality of Service. For the Mail Server, Olio, and DVD Store 2 workloads, latency is defined as the application’s response time. The completion time for vMotion, Storage vMotion, and VM Deploy is used as the latency measurement for the infrastructure operations. Latency can be very informative about the functioning of the environment and how the cluster as a whole performs under increasing loads. Examining latency at a 3-tile load, as seen in the figure below, reveals significant differences between the hypervisor versions. Latencies were normalized to the ESXi 4.1 results.

2

We saw decreases in latency for all VMmark 2 workloads with vSphere 5. The latency decreases were most striking in Olio, Storage vMotion, and DVD Store 2, with decreases of 20%, 19%, and 15%, respectively. These improvements to vMotion and Storage vMotion are consistent with publicized improvements in vMotion and Storage vMotion latency for vSphere 5 (details here).

A VMmark 2 run passes when all of its application QoS metrics, or latencies, remain below a specified threshold. These decreases in latency with ESXi 5.0 are directly related to why ESXi 5.0 was able to support an additional tile relative to ESXi 4.1.

Our comparison has shown that upgrading an ESXi 4.1 cluster to vSphere 5 had two high-level effects on performance. The vSphere 5 cluster supported 33% more VMs at saturation than the ESXi 4.1 cluster, and it also exhibited improved latency and throughput at lower levels of load, showing that ESXi 5.0 does outperform ESXi 4.1.

Fonte: VMware

Virtualização de servidores pode beneficiar storage virtual

Sistema de armazenamento virtual permite utilizar hardware de qualquer fornecedor e tudo sob um único guarda-chuva.

Um dos benefícios do sistema de armazenamento virtual é que ele permite que seja utilizado qualquer fornecedor de hardware e um único serviço de storage. A ideia básica é que você não fique preso a um único provedor. Isso soa como nirvana, embora, até agora, não tenha correspondido às  expectativas, mas tudo pode mudar por conta da virtualização de servidores.

Atualmente, a maioria dos sistemas de armazenamento não tem forte integração entre hardware e software. Fornecedores, com raras exceções, são primeiramente desenvolvedores de software e frequentemente usam hardware padrão. Você realmente está comprando o software, ou o que chamo de serviços de armazenamento, e com esses serviços vem o hardware.

O objetivo do fornecedor na virtualização é quebrar este modelo. Isso tradicionalmente significa comprar um conjunto relativamente poderoso de servidores, colocá-los à disposição para rodar software de armazenamento. A partir daí, você pode anexar qualquer fornecedor de sistema de disco, alavancando o sistema quando chegar a hora de comprar. Mais uma vez soa como nirvana, alguns compram a ideia, outros, nem tanto.

A razão para a falta de adoção deve-se um pouco à falta do “kit” natural de aproximação e abordagem. Você deve montar os produtos, conectá-los aos servidores e colocar tudo para funcionar. Quando implantado, os sistemas são impressionantes. Eles podem migrar entre fornecedores de storage, replicar para outros e, às vezes, mudar de volume de acordo com os diferentes sistemas de manufatura.

Se alguma coisa der errado, você deve ir ao seu fornecedor de hardware e pedir ajuda. Mas isso se torna difícil, uma vez que você não está usando o software dele. Basicamente, se as luzes estão acesas, eles consideram o trabalho feito. Assim que as companhias de software tentaram ajudar, não havia muito que pudessem fazer e com frequência os consumidores eram deixados para descobrir isso sozinho.

Isso fez com que um único sistema dominasse o mercado de virtualização de storage, e essa fabricante é a única a ofertar o software de complemento da virtualização, abstraindo a criação do volume no gerenciamento de disco, replicação e assim por diante. O pensamento do hardware veio do mesmo fabricante para eliminar o “kit” natural descrito acima. A comunidade de usuário tem apostado que este é um compromisso aceitável, e que fornecedor de armazenamento virtual é hoje relativamente um nicho de mercado.

Tenho dito muitas vezes que temos apenas o panorama superficial de como a virtualização de servidor vai mudar a forma que a TI opera. Uma dessas mudanças talvez seja no armazenamento. O hypervisor talvez acabe com virtualização do armazenamento da mesma forma que a virtualização de CPUs e a conectividade de rede.

O hipervisor talvez faça o “kit” natural do fornecedor de armazenamento virtual parecer mais fácil de gerenciar. Assim como os usuários estão se tornando menos preocupados sobre qual marca de servidor deve usar, também podem se tornar menos preocupados com a marca de armazenamento. Você começará a se concentrar em confiabilidade e desempenho do sistema de storage, em vez de saber quem tem a melhor capacidade instantânea.

Com toda a franqueza, os hypervisors de hoje não têm a capacidade completa de executar todas as funções de armazenamento, como serviço de replicação e clones, mas o software já está disponível para preencher essas lacunas. Deixando o hypervisor lidar com grandes serviços de armazenamento. como locação de dados. e usando software para prover serviços menores. como escalas instantâneas, pode ser uma alternativa viável. Para muitos, isso pode ser um caminho ideal para fazer o storage a custos mais baixos e efetivamente parte do serviço ou projeto de desktop virtual.

Fonte: Information Week Brasil

vSphere 5 – Perguntas Frequentes

P: O novo modelo de licenciamento do VMware vSphere 5.0 se aplica às licenças existentes do VMware vSphere 4.x ou anterior?
R: Não. O novo modelo de licenciamento do vSphere se aplica apenas a novas licenças do vSphere ou a licenças existentes do vSphere 4.x ou anterior que passaram pelo upgrade para o vSphere 5.0.

P: Após fazer upgrade das licenças existentes do vSphere 4.x ou anterior para o vSphere 5.0 poderei manter o modelo de licenciamento do vSphere 4.x?
R: Não. Para concluir o upgrade, o novo EULA do vSphere 5.0 EULA deve ser aceito.

P: O que é vRAM?
R: vRAM ou RAM virtual é a memória total configurada para uma máquina virtual.

P: Qual é a capacidade de vRAM em pools disponível no meu ambiente?
R:
A vRAM em pools disponível é igual à soma de atribuições de direitos de vRAM de todas as licenças de uma única edição do vSphere, gerenciada por uma ou várias instâncias do VMware vCenter Server em Linked Mode.

P: Como é determinado o consumo da capacidade de vRAM?
R:
A vRAM consumida é igual à soma da vRAM configurada para todas as máquinas virtuais ligadas, gerenciadas por uma ou várias instâncias do VMware vCenter Server em Linked Mode.

P: Qual é o tamanho máximo do pool de vRAM que eu posso criar?
R:
A capacidade de vRAM em pools pode ser ampliada indefinidamente com o acréscimo de mais licenças do vSphere ao VMware vCenter Server.

P: A capacidade de vRAM em pools pode ser ampliada com qualquer edição do vSphere?
R:
Não. As atribuições de direitos de vRAM são agrupadas em pools pela mesma edição do vSphere. Portanto, um pool de vRAM pode ser ampliado com o acréscimo de licenças da mesma edição do vSphere.

P: Como me mantenho em conformidade com esse modelo de licenciamento? Existe um limite forçado de vRAM?
R:
Para se manter em conformidade, a vRAM consumida deve ser menor ou igual à capacidade de vRAM em pools disponível. O VMware vCenter Server não irá impor um limite forçado (com exceção do VMware vCenter Server
for Essentials) de vRAM consumida, mas emitirá alertas de que a vRAM consumida está se aproximando da capacidade disponível nos pools ou a ultrapassou. As políticas da VMware determinam que os clientes comprem licenças já antecipando o uso.

P: Recebi um alerta do VMware vCenter informando que ultrapassei a vRAM em pools disponível, mas o produto não me impediu de implantar uma nova máquina virtual. Por que isso aconteceu?
R:
Somente o vSphere Essentials e o Essentials Plus impõem a capacidade de vRAM. O VMware vCenter Server Standard não impedirá que você ultrapasse a capacidade de vRAM disponível. Ele somente sinalizará que o licenciamento do ambiente está fora de conformidade. As políticas de licenciamento da VMwaredeterminam que os clientes comprem licenças já antecipando o uso. Portanto, recomendamos o monitoramento do consumo de vRAM e a extensão da capacidade de vRAM em pools disponível antes de ultrapassá-la. Neste exemplo, para se manter em conformidade, você deverá adicionar imediatamente licenças do vSphere suficientes para cobrir a “high
watermark” da vRAM consumida.

P: Após usar uma licença do vSphere para adicionar vRAM a um pool, poderei posteriormente adicionar a mesma licença a uma CPU?
R:
Sim, utilizando o portal de licenciamento da VMware, (http://www.vmware.com/licensing/license.portal), você pode combinar ou dividir as licenças de processador do vSphere. Esse processo criará novas chaves de licença que poderão ser reatribuídas a CPUs novas e existentes por
meio do módulo de licenciamento do vCenter Server.

P: Qual é o processo por meio do qual é possível adicionar licenças do vSphere ao pool de vRAM?
R:
Há duas maneiras de adicionar licenças do vSphere ao pool:
• Inserir um novo host no pool e atribuir licenças de processador às CPUs dele.
• Adicionar novas licenças de processador, combinando-as com as licenças existentes no portal de licenciamento da VMware.

P: Posso adicionar vRAM a um kit Essentials ou Essentials Plus?
R:
Não, a capacidade total de vRAM dos kits Essentials e Essentials Plus não pode ser estendida.

P: O cálculo do meu SnS será diferente?
R:
O SnS continua vinculado às licenças de processador do vSphere.

P: Os termos de licenciamento variam dependendo do servidor no qual implantei o vSphere 5.0?
R:
Não. Nenhuma atribuição de direitos de licença do vSphere está vinculada às características físicas do servidor no qual o vSphere é implantado.

P: Como adquiro mais vRAM?
R:
Basta comprar e atribuir mais licenças de CPU do vSphere.

P: Este modelo de licenciamento acarretará mais custos?
R:
Embora seja impossível prever os efeitos do novo modelo de licenciamento em todos os tipos de ambiente, ele foi projetado para reduzir o risco dos impactos potenciais nos ambientes existentes e ainda oferecer espaço para desenvolvimento. As atribuições de direitos de vRAM foram definidas para fornecer capacidade suficiente para um dimensionamento muito superior às taxas de consolidação médias atuais de 5:1. Além disso, graças à criação de pools, os clientes poderão compartilhar atribuições de direitos entre vários hosts, utilizando, assim, a capacidade disponível de modo mais eficiente.