A máquina virtual é mais lenta que a máquina física subjacente?

Essa pergunta é bastante geral, mas mais especificamente, estou interessado em saber se a máquina virtual executando o Ubuntu Enterprise Cloud será mais lenta que a mesma máquina física sem virtualização. Quanto (1%, 5%, 10%)?

Alguém mediu a diferença de desempenho do servidor web ou servidor db (virtual VS físico)?

Se depender da configuração, vamos imaginar dois processadores quad core, 12 GB de memória e um monte de discos SSD, executando o servidor corporativo ubuntu de 64 bits. Além disso, apenas 1 máquina virtual pode usar todos os recursos disponíveis.

A experiência típica para uma carga de trabalho de servidor de propósito geral em um hipervisor \ Tipo 1 bare metal é de cerca de 1-5% da sobrecarga da CPU e 5-10% da memória, com alguma sobrecarga adicional que varia dependendo da carga geral de E / S. Isso é bastante consistente na minha experiência em sistemas operacionais convidados modernos em execução no VMware ESX \ ESXi, Microsoft Hyper-V e Xen, onde o hardware subjacente foi projetado adequadamente. Para sistemas operacionais de servidor de 64 bits em execução em hardware compatível com as extensões de virtualização de hardware da CPU mais atuais, eu esperaria que todos os hipervisores do Tipo 1 estivessem indo para esse número adicional de 1%. A maturidade da KVM não está de acordo com o Xen (ou VMware) neste momento, mas não vejo razão para pensar que seria visivelmente pior do que eles no exemplo que você descreve.

Para casos de uso específicos, embora o "desempenho" agregado geral de um ambiente virtual possa exceder servidores bare metal \ discretos. Aqui está um exemplo de uma discussão sobre como uma implentação em cluster do VMware pode ser mais rápida \ melhor \ mais barata que um Oracle RAC bare metal. As técnicas de gerenciamento de memória da VMware (especialmente o compartilhamento transparente de páginas) podem eliminar quase toda a sobrecarga de memória se você tiver VMs suficientes semelhantes. O importante em todos esses casos é que os benefícios de desempenho / eficiência que a virtualização pode oferecer somente serão alcançados se você estiver consolidando várias VMs em hosts, seu exemplo (1 VM no host) sempre será mais lento do que o bare metal em algum grau .

Embora tudo isso seja útil, os problemas reais em termos de virtualização de servidores tendem a se concentrar em gerenciamento, técnicas de alta disponibilidade e escalabilidade. Uma margem de desempenho de CPU de 2-5% não é tão importante quanto poder escalar com eficiência para 20, 40 ou quantas VMs você precisar em cada host. Você pode lidar com o desempenho atingido selecionando uma CPU um pouco mais rápida como sua linha de base ou adicionando mais nós em seus clusters, mas se o host não puder escalar o número de VMs que pode executar, ou o ambiente é difícil de gerenciar ou não confiável, é inútil do ponto de vista da virtualização de servidores.

"Performance" tem muitos aspectos. O n00bs mede o tempo de inicialização de um sistema operacional e diz, por exemplo, o Windows 2012 é muuuuito bom porque inicializa em 12 segundos em HD real, talvez 1 segundo em SSD.
Mas esse tipo de medida não é muito útil: o desempenho é igual ao tempo de inicialização do sistema operacional, mas o sistema operacional é inicializado uma vez por mês, otimizando tanto que não faz muito sentido.

Como é o meu negócio diário, posso apontar as quatro partes a seguir que compunham o "desempenho"

1. Carga da CPU
   Isso deve ser comparável, ou seja, uma tarefa com 1000 ms em metal puro será executada em 1000 ms em tempo de processo e provavelmente 1050 ms em tempo de relógio em um ambiente VM inativo no mesmo hardware (alguns detalhes posteriormente). Pesquise no Google o MSDN quanto ao tempo de processo e ao contador de consultas e você pode fazer algo que pode mostrar quanto a VM consome seu tempo de CPU.

2. Desempenho SQL
   O desempenho do SQL depende muito de E / S no armazenamento de dados em que os dados do SQL são armazenados. Vi uma diferença de 300% entre o ISCSI de 1ª geração, que você pode encontrar no NAS doméstico de Buffalo, depois o ISCSI com DCE e um ambiente FC real da velha escola, em todos os níveis. O FC ainda ganha hoje em dia, porque a latência do FC é a menor capacidade de arquivamento que leva a uma "cópia" do protocolo FC para aprimoramentos do datacenter TCP / IP. Aqui, as IOps e a latência são vitais, mas também a largura de banda das E / S do processo do servidor para a mídia - depende se o aplicativo tende a No-SQL ou Datawarehousing ou está no meio disso, como os sistemas ERP ... Sage KHK for small enterprise, SAP para os grandes.

3. Acesso ao sistema de arquivos
   Alguns aplicativos, como o streaming de vídeo, contam com uma largura de banda mínima garantida, outros contam com a taxa de transferência máxima de E / S, como abrir arquivos grandes em um editor hexadecimal, carregar um projeto de vídeo no seu programa de criação de filmes favorito. Não é uma situação típica em uma vm .... os IOps também podem ser importantes para os desenvolvedores. Os desenvolvedores costumam usar VMs porque os ambientes de desenvolvimento são muito sensíveis e, portanto, a tentação de fazer isso em uma VM é alta. Compilar um projeto grande geralmente significa ler toneladas de arquivos pequenos, fazer as coisas do compilador e criar um EXE e os componentes que o acompanham.

4. Latência da rede para o cliente
   Aqui, a usabilidade dos programas WYSIWIG, como o Word 2010, o Openoffice Writer, o LaTEX, o GSView e outros, depende muito da velocidade - a rapidez com que a ação do mouse chega do cliente ao servidor. Especialmente em aplicativos de CAD, isso é importante ... mas também não é um problema de LAN, é o acesso remoto pela WAN onde isso é importante.

Mas - e falo da perspectiva de anos de consultoria - existem usuários com a senha de administrador (e geralmente são funcionários de uma empresa GRANDE com um orçamento GRANDE e um bolso GRANDE) reclamando isso e aquilo, mas deve ser esclarecido qual componente de desempenho é importante para eles e qual é importante da perspectiva do aplicativo que eles usam.
Provavelmente não é um bloco de notas, mas um aplicativo altamente sofisticado para projetar isso e aquilo, que também foi muito dispendioso e deve ser movido no VMware, HyperV ou Xenapp e não tem o desempenho esperado.

Mas eles não têm em mente que ele pode rodar em Xeons de 1,5 GHz em blades não fabricados para desempenho puro da CPU, eles são construídos para uma média, digamos "otimizados para $ por ciclo de CPU" ou "ciclos de CPU por Watt" .

E quando falamos de tradeoffs e economizações - isso leva principalmente a compromissos excessivos. O comprometimento excessivo leva à falta de recursos, onde a CPU pode ser tratada muito bem, mas a falta de memória leva a paginação, a falta de E / S nos roteadores principais aumenta o tempo de resposta em tudo e a sobrecarga transacional em qualquer tipo de armazenamento pode parar todos os aplicativos úteis de responder muito rapidamente. Aqui, o monitoramento é necessário, mas muitos fornecedores de software não conseguem fornecer essas informações ... por outro lado, um host com recursos de 3 servidores físicos provavelmente pode lidar com 8 máquinas virtuais do mesmo layout, como as físicas ...

As compensações da CPU em sistemas inativos geralmente levam a sistemas com desempenho 50% mais lento que os sistemas físicos; por outro lado, ninguém é capaz de instalar o sistema operacional "mundo real" e o aplicativo "mundo real" que os funcionários de TI do cliente desejam migrar para a VM caixa. E leva dias (talvez semanas, mas com certeza 42 reuniões) para deixar claro que a tecnologia VM pode oferecer flexibilidade negociando a velocidade pura da CPU. Isso acabou de ser incorporado às CPUs desses sistemas blade, que atualmente hospedam ambientes VM maiores. Além disso, a memória não será comparável, também serão aplicadas algumas trocas. O DDR3 1600 CL10 terá maior largura de banda de memória que o DDR2 800 ECC LLR - e todos sabem que as CPUs Intel lucram com isso de uma maneira diferente da AMD cpus. Mas eles raramente são usados ​​em ambientes produtivos, mais em caixas brancas ou em datacenters hospedados em países do terceiro mundo que oferecem serviço de datacenter por 10% do preço que um datacenter em sua própria terra natal pode cobrar. Graças ao Citrx, um datacenter pode estar em qualquer lugar se tiver menos de 150 ms de latência entre o usuário final e o datacenter.

E a perspectiva dos usuários domésticos ....

Por último, mas não menos importante, algumas pessoas querem jogar fora o Win7 ou XP e trocá-lo por um Linux, e então surge a questão dos jogos porque, na verdade, apenas alguns jogos estão disponíveis para Linux e Windows. O jogo depende muito da aceleração 3D. A estação de trabalho VMWare 6.5 e o player gratuito conectado podem lidar com o DirectX 9, o que significa que um Doom3 em uma VM pode ser executado na placa gráfica do host em tela cheia. Os jogos são na maioria aplicativos de 32 bits, portanto, eles não consomem mais de 3 GB e, principalmente, não mais que 3 CPUs (visto no Crysis). Os players de VM e WS mais novos podem lidar com versões mais altas do DirectX e provavelmente também com OpenGL ... Eu joguei UT e UT2004 no VMware 6.5, o host tinha um ATI Radeon 2600 móvel e uma CPU T5440. Era estável em 1280x800 e jogável mesmo em jogos em rede ....

Sim. Mas essa não é a questão. A diferença é normalmente negligenciável (1% a 5%).

Eu apontaria que a virtualização pode exceder o desempenho físico em determinadas situações. Como a camada de rede não se limita à velocidade de gigabit (mesmo que a emulação de hardware seja de uma placa LAN específica), as VMs no mesmo servidor podem se comunicar entre si a velocidades além da de vários servidores phyiscal com equipamento de rede médio.

Fiz algumas comparações de teste do mesmo software executando o mesmo teste (aplicativo Web baseado em .NET com altos volumes de tráfego na Web e acesso considerável ao SQL Server). Aqui está o que eu vi:

• A máquina física é melhor na instanciação de classes (que se traduz em alocar memória no nível do sistema) - isso faz sentido para mim porque as máquinas físicas fazem isso através do hardware de gerenciamento de memória e as VMs fazem isso através do software (com assistência parcial de hardware) (na VM , o aplicativo passou uma quantidade significativa de tempo em seus construtores (onde a memória é alocada (e nada mais é feito), na máquina física, os construtores nem foram incluídos entre os 1000 principais)
• Quando você está no meio de um método, os dois são equivalentes - provavelmente é assim que a maioria dos benchmarks são construídos que mostram os dois "sendo iguais"
• Quando você acessa um controlador de rede, o físico supera um pouco a VM - novamente, o físico não tem muito tempo entre o processo .NET e o hardware. A VM adiciona adiciona outras "coisas" pelas quais cada transação precisa percorrer.
• Realmente, o mesmo se aplicava ao acesso ao disco (o SQL Server estava em outra máquina) - a diferença é muito pequena, mas quando você os adiciona, é perceptível. Isso pode ter sido causado pelo acesso mais lento à rede ou por um acesso mais lento ao disco.

Eu posso ver facilmente como alguém pode criar benchmarks que provam que são 1% diferentes ou iguais ou onde as VMs são mais rápidas. Não inclua nada em que seu processo aproveite os benefícios do suporte de hardware local, onde a VM precisa simulá-lo em software.

Você está tentando comparar um sistema operacional, software e dados instalados em um determinado hardware físico com o mesmo sistema operacional, software e dados instalados por si só dentro de um hipervisor no mesmo hardware original. Essa comparação simplesmente não é válida, porque quase ninguém faz isso (pelo menos a princípio). Claro que isso provavelmente seria mais lento. Felizmente, ele perde completamente o ponto mais comum do motivo pelo qual você virtualiza servidores.

Um exemplo melhor aqui é olhar para dois (ou mais!) Servidores mais antigos no seu data center. Procure servidores que tenham um desempenho razoavelmente bom, mas que sejam antigos agora e que estejam chegando no ciclo de atualização. Esses servidores já apresentam bom desempenho em hardware mais antigo, e, graças à lei de Moore, qualquer coisa nova que você obtiver será muito exagerada.

Então, o que você faz? É simples. Em vez de comprar dois novos servidores, você compra apenas um e depois migra os dois servidores antigos para o mesmo novo dispositivo físico. Ao se preparar para comprar seu novo servidor, você planeja ter capacidade suficiente não apenas para lidar com a carga dos dois servidores mais antigos, mas também com qualquer carga do hipervisor (e talvez um pouco mais, para que você ainda possa obter um aumento de desempenho e pode permitir o crescimento).

Em resumo: as máquinas virtuais fornecem desempenho "suficientemente bom" para a maioria das situações e ajudam a fazer melhor uso de seus servidores para evitar o poder de computação "desperdiçado".

Agora vamos alongar isso um pouco mais. Como esses servidores são antigos, talvez você estivesse procurando alguns servidores simples de caixa de pizza de US $ 1500 para substituí-los. As chances são de que mesmo uma dessas caixas de pizza ainda possa lidar facilmente com a carga de ambas as máquinas hipotéticas mais antigas ... mas digamos que você decida gastar US $ 7500 ou mais em algum hardware real. Agora você tem um dispositivo que pode lidar facilmente com até uma dúzia de servidores existentes (dependendo de como você lida com armazenamento e rede), com um custo inicial de apenas 5. Você também tem os benefícios de gerenciar apenas um servidor físico, desacoplando seu software a partir do seu hardware (por exemplo: agora é menos provável que a atualização do hardware precise de uma nova licença do Windows ou cause tempo de inatividade), você economiza bastante energia e seu hipervisor pode fornecer melhores informações sobre desempenho do que você ' você teve no passado. Obtenha duas delas e, dependendo do tamanho que você tem, talvez todo o seu centro de dados esteja reduzido a apenas duas máquinas, ou talvez você queira usar o segundo servidor como um modo de espera quente para contar uma história melhor de alta disponibilidade.

O que quero dizer aqui é que não se trata apenas de desempenho. Eu nunca pegaria um servidor de produção perfeitamente bom e o virtualizaria sozinho para um hardware equivalente só porque. É mais sobre economia de custos e outros benefícios que você pode obter com a consolidação, como alta disponibilidade. A realização desses benefícios significa que você está transferindo servidores para um hardware diferente e, por sua vez, é necessário dedicar um tempo para dimensionar esse hardware adequadamente, incluindo a contabilização da penalidade do hipervisor. Sim, você pode precisar de um pouco mais de poder de computação no total do que se cada uma dessas máquinas estivesse em seu próprio dispositivo físico (dica: você provavelmente precisa de muito menos poder de computação total ), mas será muito mais barato, mais eficiente em termos de energia, e mais fácil de manter executar um servidor físico do que executar muitos.

Acabei de atualizar para um SSD (OCZ Vertex 2) e executo meu ambiente de desenvolvimento XP VM nele, sou desenvolvedor de software. Uma coisa que notei é que, quando inicio um programa (um grande o suficiente para levar tempo para carregar), um núcleo da CPU virtual se encaixa. Isso acontece ao carregar o IE também. Desde que a CPU se destaca, presumo que o gargalo é a CPU e não o SSD. Mas parece estranho, tenho a sensação de que, se a mesma coisa fosse feita em uma máquina física, ela carregaria mais rapidamente e minha sensação é de que há algum custo adicional de processamento adicional que o VMWare está fazendo e que consome CPU no acesso ao disco.

Um exemplo: eu uso o Delphi e em uma máquina física com um disco rígido normal, pode demorar 20 segundos para iniciar a partir de uma inicialização a frio. Na VM executando um SSD, ele é carregado em 19 segundos a partir de uma partida a frio. Não há muita diferença, aposto que se o SSD estivesse na máquina física, ele carregaria mais rápido. No entanto, não verifiquei o uso da CPU na máquina física, é possível que a CPU também tenha sido um gargalo.

Mas a sensação da VM é que o acesso ao disco tributa a VM.

Obviamente, uma máquina virtual é mais lenta que a máquina física. Mas quando você está nesse cenário, precisa avaliar o que é ideal para atender às suas necessidades. Se você precisar de apenas um sistema e for rápido, instale-o diretamente no hardware. Por outro lado, se você precisar de flexibilidade, escalabilidade (e todos os outros benefícios de virtualização: P) implantar uma VM. Será mais lento, mas em alguns casos o IMHO é justificado e o desempenho não é significativamente lento.

Parece que a Microsoft fez alguns testes de benchmark usando o BizTalk Server e o SQL Server em diferentes configurações a esse respeito. Veja o link abaixo:

http://msdn.microsoft.com/en-us/library/cc768537(v=BTS.10).aspx

Idealmente, o desempenho do PC virtual está em:

CPU: 96-97% do host

Rede: 70-90% do host

Disco: 40-70% do host

Desculpe discordar do TomTom.

Eu uso o VMware Workstation há algum tempo, principalmente nos sistemas nativos Windows XP, Windows Vista e agora Windows Seven para executar diferentes sabores do Windows e no Ubuntu.

Sim, um ambiente virtualizado é mais lento que um sistema nativo e pode estar na faixa de 5 a 100%.

O principal problema não é tanto a carga da CPU, mas a falta de memória física.

Digamos que você tenha um Windows Seven 64 Ultimate rodando em um sistema de 4 Gb que, quando ocioso, precisa de quase 1,5 Gb e usa ~ 10% da CPU. O lançamento da camada extra do VMware custará ~ 300 Kb e as cargas da CPU subirão até ~ 20%. Em seguida, o lançamento de um sistema virtual no VMware solicitará no mínimo a quantidade de memória que você definiu para a máquina virtual com no mínimo 1 Gb para qualquer sistema decente. Então você verá a carga da CPU ~ 60% se a máquina virtual for Ubuntu e ~ 80% para qualquer versão do sistema operacional Windows recente.

Agora, você iniciará aplicativos diferentes nessa máquina virtual.

Se a quantidade de memória que você configurou para essa máquina virtual não for suficiente, o sistema virtualizado começará a trocar, diminuindo drasticamente seu desempenho e capacidade de resposta gerais.

Se a soma da quantidade de memória configurada para essa máquina virtual mais a quantidade de memória necessária para o sistema nativo estiver acima da quantidade de memória do sistema nativo, será o sistema nativo que será trocado, diminuindo a velocidade o sistema nativo e o virtualizado.

Portanto, primeiro depende do equilíbrio da memória necessária para as máquinas nativas e virtualizadas.

Agora é quase o mesmo com a carga da CPU. Se um aplicativo virtualizado precisar de uma carga enorme de CPU e um aplicativo nativo também precisar de uma carga enorme de CPU, seu sistema nativo precisará gerenciar a prioridade e equilibrar a carga da CPU entre seus aplicativos diferentes, sendo o sistema virtualizado nada mais que um aplicativo, mas que Esse fenômeno é um problema clássico de carga da CPU que você pode enganar com as prioridades do aplicativo.

Portanto, meu primeiro conselho, se você precisar usar a virtualização, é colocar um monte de memória em sua máquina, independentemente do sistema operacional usado nativamente ou dentro de uma máquina virtual.

Apenas meus 2 centavos.

Cumprimentos.

Na minha experiência, as máquinas virtuais são sempre muito mais lentas que as físicas FORA DA CAIXA.

Você só notará isso ao executar aplicativos que atingem o disco e sobrecarregam muito a CPU. Eu executei muitos bancos de dados e servidores da Web em máquinas virtuais, e como usuário final e o feedback de outros usuários (ou seja: acessar o aplicativo a partir de um navegador remoto), há um grande atraso ao usar máquinas virtuais.

É claro que uma máquina virtual configurada corretamente pode chegar a 80% (não sei o número real) ou a velocidade da máquina física, mas você acaba tendo que se aprofundar no que o aplicativo está fazendo e como a máquina virtual trabalho. Então eu acho que é uma equação de custo de quão valioso é o seu tempo para configurar os versos de VMs apenas comprando e hospedando um novo servidor.

Para mim, as máquinas virtuais NÃO SÃO SOBRE DESEMPENHO, mas sobre ser mais fácil de gerenciar e hospedar várias VMs de baixo desempenho, é claro.