A hypervisor é uma combinação de software, hardware ou firmware que cria, executa e gere máquinas virtuais (VMs). O computador que executa um hipervisor é conhecido como o seu anfitrião, enquanto que cada VM no anfitrião é conhecido como um convidado. Um hipervisor fornece aos convidados uma plataforma operacional virtual que gere os seus sistemas operacionais (SOs), permitindo a múltiplos SOs partilhar recursos virtualizados no mesmo anfitrião.
A capacidade de partilhar recursos é uma das razões mais significativas para que uma empresa implemente hipervisores. No entanto, a variedade de hipervisores actualmente disponíveis pode tornar este processo de decisão um desafio. A selecção de um hipervisor resume-se frequentemente a uma escolha entre VMware e Kernel-based Virtual Machine (KVM). VMware é o nome de uma empresa que desenvolve uma gama de hipervisores, incluindo a ESXi de classe empresarial. KVM é uma infra-estrutura para o kernel Linux que lhe fornece as capacidades de um hipervisor.
p>Os seguintes pontos de comparação podem ajudar as organizações que necessitam de um hipervisor a escolher entre VMware e KVM.
- Performance
- Integração
- Custo
- Complexidade
- Maturidade
- Scalabilidade
- Suporte de funcionalidade
Overvisão
Um hipervisor virtualiza um ambiente informático, o que significa que os convidados nesse ambiente partilham recursos físicos tais como capacidade de processamento, memória e armazenamento englobando uma nuvem privada. Cada hóspede gere o seu próprio sistema operativo, o que o faz parecer como se tivesse os seus próprios recursos, mesmo que não tenha. A partilha eficiente de recursos requer o processador físico para suportar a virtualização, que se chama AMD-V para processadores AMD e VT-x para processadores Intel.
Um hipervisor precisa de isolar eficazmente cada convidado, de modo a que a operação de um convidado não possa afectar os outros convidados a correr no anfitrião. Este requisito significa que um hipervisor tem de emular com precisão o hardware físico para impedir o acesso dos convidados, excepto em circunstâncias cuidadosamente controladas. O método que um hipervisor usa para o fazer é um factor chave no seu desempenho.
Hypervisors usam frequentemente controladores “paravirtualizados” (PV) para emular o hardware físico, que actuam como hardware, tais como discos de armazenamento e cartões de rede. Estes controladores são específicos do SO e muitas vezes específicos de um determinado hipervisor. Os controladores PV podem melhorar o desempenho de um hipervisor por uma ordem de magnitude.
Performance
Hypervisors podem ser classificados em dois tipos, que podem ter impacto no seu desempenho. Os hipervisores de tipo 1, também conhecidos como hipervisores de “metal nu”, funcionam directamente sobre o hardware físico, e o SO de cada convidado corre sobre o hipervisor. Estes hipervisores permitem tipicamente que alguns hóspedes controlem o hipervisor. A maioria das empresas utiliza hipervisores de Tipo 1.
Um hipervisor de Tipo 2, também conhecido como hipervisor hospedado, corre dentro de um sistema operativo que corre no hardware físico. O SO de cada convidado corre então em cima do hipervisor. Os hipervisores de secretária são normalmente hipervisores Tipo 2.
Xen é provavelmente o melhor exemplo de um hipervisor puro Tipo 1, embora ESXi seja claramente um hipervisor Tipo 1 também porque não é uma aplicação que está instalada num SO. ESXi inclui um kernel e outros componentes do SO que integra no SO nativo.
A classificação de KVM é mais desafiante porque partilha características de ambos os tipos de hipervisor. É distribuído como um componente Linux, o que significa que um utilizador Linux pode iniciar o KVM a partir de uma linha de comando ou interface gráfica de utilizador (GUI). Estes métodos de iniciar o KVM fazem-no aparecer como se o hipervisor estivesse a correr no sistema operativo anfitrião, mesmo que o KVM esteja realmente a correr no metal nu.
O sistema operativo anfitrião fornece ao KVM um mecanismo de lançamento e estabelece uma relação de co-processamento com ele, permitindo ao KVM partilhar o controlo sobre o hardware físico com o kernel Linux. O KVM utiliza as instruções de virtualização do processador quando corre em hardware x86, permitindo que o hipervisor e todos os seus convidados corram directamente sobre o metal descoberto. O hardware físico executa a maioria das traduções dos recursos, pelo que o KVM cumpre os critérios tradicionais para um hipervisor Tipo 1.
Um hipervisor Tipo 1 deve ter um desempenho superior ao de um hipervisor Tipo 2, sendo todos os outros factores iguais. Os hipervisores de Tipo 1 evitam a sobrecarga que um hipervisor de Tipo 2 incorre quando solicita acesso a recursos físicos do sistema operativo anfitrião. Contudo, outros factores desempenham também um papel importante no desempenho de um hipervisor. Por exemplo, o ESXi geralmente requer mais tempo para criar e iniciar um servidor do que o KVM. ESXi também tem um desempenho mais lento quando executa servidores, embora esta diferença possa ser insignificante para cargas típicas.
Integração
Hypervisor utiliza métodos diferentes para comunicar com o hardware físico do anfitrião. O KVM utiliza um agente instalado no anfitrião para comunicar com o hardware, enquanto o ESXi utiliza o plano de gestão do VMware para comunicar com o hardware. O processo oferece a vantagem de permitir à ESXi aceder a outros produtos VMware que utilizam este plano de gestão. Contudo, também requer que a ESXi utilize a pilha de controlo da VMware, o que pode aumentar os requisitos de hardware.
A integração com o sistema operativo anfitrião é a principal razão pela qual os programadores Linux tipicamente preferem o KVM, que foi incorporado no kernel Linux pouco depois do seu lançamento em 2007. Em comparação, Xen não se tornou oficialmente parte do kernel Linux até 2011, oito anos após o seu lançamento inicial. Os programadores de Linux são também mais propensos a utilizar o KVM porque a Red Hat e outros distribuidores de Linux o adoptaram em preferência a outros hipervisores. Illumos é um SO de código aberto baseado em OpenSolaris que também escolheu KVM em vez de outros hipervisores quando adicionou suporte para virtualização de hardware.
Cost
KVM ganha claramente sobre VMware com base no custo. O KVM é de código aberto, pelo que não implica qualquer custo adicional para o utilizador. Também é distribuído de várias maneiras, muitas vezes como parte de um OS.
VMware cobra uma taxa de licença para utilizar os seus produtos, incluindo ESXi. É capaz de o fazer porque a VMware foi a primeira empresa a lançar software de virtualização de classe empresarial e continua a ser líder de mercado neste segmento. A sua marca continua, portanto, a ser relevante para os utilizadores finais de uma empresa, independentemente do que os criadores possam pensar sobre ela. Um utilizador ESXi deve também adquirir uma licença para utilizar o vSphere, o conjunto de ferramentas para computação em nuvem da VMware que utiliza ESXi. Poderão ser necessárias licenças de software adicionais, o que aumentará ainda mais o custo de implementação do ESXi.
IBM realizou alguns cálculos relativamente ao custo total de propriedade (TCO) para a KVM e VMware em 2012. Estes cálculos mostraram que o TCO da KVM era tipicamente 39 por cento inferior ao da VMware, embora o TCO real dependa de factores específicos do local, tais como a configuração operacional e a carga de trabalho. Esta diferença no TCO indica que os fornecedores de serviços de nuvem provavelmente irão querer implementar KVM em pelo menos um cluster, independentemente dos outros factores a considerar.
Complexidade
Uma comparação de KVM e VMware também mostra uma diferença clara no tamanho da base de código, o que afecta os custos de manutenção de um hipervisor. O KVM foi inicialmente lançado para tirar partido de extensões de processador que lhes permitiram virtualizar os convidados sem traduzir o código binário. Esta origem significou que a primeira versão estável do KVM foi essencialmente um driver de virtualização leve, com pouco mais de 10.000 linhas de código (LOC).
VMware acredita-se ter mais de 6 milhões de LOC, embora este facto não possa ser verificado uma vez que o seu código fonte não está disponível publicamente. Este total não afecta directamente o desempenho, uma vez que o VMware utiliza extensões de hardware para virtualizar convidados. Contudo, o seu código original nunca foi completamente reescrito, resultando numa base de código mais complexa do que KVM.
Maturidade
KVM e ESXi são ambos altamente maduros e estáveis. KVM faz parte do núcleo do Linux há mais de uma década, e ESXi está disponível ao público desde 2006. No entanto, o KVM está mais amplamente implantado uma vez que é de código aberto e está incluído em muitos pacotes como o Redhat Enterprise Virtualization (RHEV). KVM também suporta mais características que qualquer outro hipervisor.
Scalabilidade
KVM é geralmente mais escalável que VMware, principalmente porque o vSphere tem algumas limitações nos servidores que pode gerir. Além disso, a VMware adicionou um grande número de Redes de Área de Armazenamento (SANs) para suportar vários fornecedores. Esta característica significa que VMware tem mais opções de armazenamento do que KVM, mas também complica o suporte de armazenamento da VMware ao aumentar a escala.
Functionality Support
Hypervisors variam muito no seu suporte de funcionalidade. O suporte de rede e de armazenamento são especialmente importantes e são provavelmente mais importantes do que qualquer outro factor para além da integração do SO. Não deve ser uma surpresa saber que o suporte da ESXi para outros produtos VMware é incomparável por qualquer outro hipervisor. Por outro lado, KVM oferece mais opções de suporte de rede do que VMware.
Sumário
KVM é tipicamente a escolha mais popular para utilizadores que se preocupam com o custo de operação de cada VM e menos interessados em funcionalidades de nível empresarial. Esta regra aplica-se principalmente aos fornecedores de serviços de cloud e host, que são particularmente sensíveis ao custo e densidade dos seus servidores. É muito provável que estes utilizadores escolham hipervisores de código aberto, especialmente KVM.
A integração apertada com o SO anfitrião é uma das razões mais comuns para os programadores escolherem o KVM, especialmente aqueles que utilizam Linux. A inclusão do KVM em muitas distribuições Linux também o torna uma escolha conveniente para os programadores. KVM é também mais popular entre os utilizadores que não estão preocupados com marcas.
também ver VMWare vs Proxmox