O Hyper-V permite compartilhar o uso do processador entre as maquinas virtuais e distribuir sua utilização através de mecanismos próprios que evitam a sobrecarga, focando na eficiência de uso. Para entender melhor como funciona sua utilização é importante entender conceitos de arquitetura do produto.
De acordo com a versão do Hyper-V é possível alocar vários processadores lógicos para as maquinas virtuais. A maquina virtual utiliza processadores virtuais (ou Virtual Processor – VP) que é a representação de um processador para a mesma. Os termos são os seguintes:
- Processador físico (ou Physical Processor): Também às vezes é referenciado como Socket ou Pastilha física, significa o processador físico da máquina.
- Processador lógico (LP ou Logical Processor): Refere-se aos núcleos ou Cores de um processador físico. Um processador físico quad-core significa que possui 4 núcleos, ou 4 LPs.
- Hyper-Threading (HT): refere-se ao mecanismo de alguns processadores de simular uma duplicação na quantidade de núcleos ou Core utilizando partes não aproveitadas do processador na previsão de desvio do pipeline.
- Processador virtual (VP ou Virtual Processor): Representa os processadores que uma maquina virtual possui. O Virtual Processor é executado sob as LP, e um LP pode ter vários VP sustentados.
No Windows Server 2008 R2 são suportados até 64 LP, o que significa ter, por exemplo, um servidor com até 8 processadores físicos om até 8 núcleos cada. No Windows Server 2012 são suportados até 320 LP ou, por exemplo, um servidor físico com até 32 processadores físicos com 10 núcleos cada.
O Hyper-Threading não é usado no calculo de Logical Processor de virtualização. Portanto se você possui um servidor com 64 LP e HT habilitado significa que na pratica você possui 32 LP apenas. O Hyper-V não utiliza o HT, porém há opiniões diversas se o mesmo deve estar desabilitado ou não em um servidor de virtualização. Manter habilitado o HT traz outros benefícios, pois o servidor de virtualização terá mais processamento para executar outros serviços do sistema operacional (apenas não utilizará o HT para virtualização). Entretanto alguns fabricantes de hardware recomendam que o HT seja desabilitado. Nestes casos se há implicações de suporte do fabricante então siga a recomendação do mesmo. Caso não exista impactos então você pode manter o HT habilitado.
Para cálculos de dimensionamento de servidores de virtualização é utilizado a formula VP:LP , ou mais precisamente a quantidade de Virtual Processor para cada Logical Processor. Esta medida pode variar muito dependendo da necessidade de utilização de processadores das maquinas virtuais. A medida básica funciona da seguinte forma:
- Até 8 VPs p/ cada 1 LP (8:1) suportado para Virtualização de Sistemas Operacionais de servidor
- Até 12 VPs p/ cada 1 LP (12:1) suportado para VDI (Virtual Desktop Infrastructure / Infraestrutura de Desktops Virtuais com Windows 7)
Estas taxas de recomendação dependem do workload (Biztalk, Exchange, SQL, LYNC, VDI…). Portanto se você vai virtualizar servidores que demandam uso intensivo de CPU procure reduzir esta taxa para 4:1, dependendo da analise que você fizer. Por questões de previsão de crescimento do servidor de virtualização é interessante trabalhar sempre com uma carga de CPU subutilizada no servidor, de forma que você não tenha impactos futuros de desempenho.
Para quem trabalha com plataforma de virtualização VMware® já deve estar familiarizado com o que chamamos de Afinidade de Processador. Isto significa alocar um núcleo de um processador exclusivamente para uma maquina virtual. Esta funcionalidade não existe para o Hyper-V , pois é utilizado o mecanismo de Scheduler para distribuir as cargas de processamento das maquinas virtuais. Para entender melhor o Scheduler vamos analisar uma situação de 2 maquinas virtuais com uso de CPU em excesso:
Neste cenário temos um servidor com 1 processador físico e 4 núcleos / Cores, representados como LP. A contagem de núcleos / Cores começa sempre pelo que chamamos de Proc 0, e sua contagem vai progredindo. No diagrama acima temos 4 núcleos / Cores, representados pelo LP 0, LP 1, LP 2 e LP 3. Vamos supor que neste servidor foi criado uma maquina virtual com 1 VP. O Scheduler começa a alocação a partir do LP 0 obrigatoriamente.
Na situação a seguir foi criada outra maquina virtual, porém com 2 VPs. O serviço do Scheduler começa da mesma forma a alocar o uso de LP para a mesma, e também inicia sempre a alocação a partir do LP 0. Ainda aqui as 2 maquinas virtuais estão com utilização baixa de CPU (a VM 1 esta com 50% de alocação de CPU e a VM2 está com praticamente 0).
Caso a maquina virtual VM2 comece a utilizar um pouco mais intensivamente a CPU haveria impacto de desempenho para a VM1, pois o LP 0 seria sobrecarregado. Nesta hora o Scheduler analisa a utilização de CPU e automaticamente move a alocação do LP 0 e LP 1 da VM2 para LP 1 e LP 2 respectivamente, conforme diagrama abaixo:
O ponto interessante desta alocação dinâmica é que o processo é totalmente transparente para a maquina virtual, portanto não há impacto nas aplicações e demais serviços que estejam em execução neste momento na VM. Caso a VM2 comece a diminuir sua demanda de processamento na LP 1 e LP 2 o Scheduler começa a mover automaticamente a alocação para a LP 0 e LP 1 respectivamente.
Não existe afinidade de VP para LP. Porém o Scheduler vai tentar manter a afinidade de VP à LP o quanto for possível baseado nas políticas de:
- Carga na atual LP e no restantes dos LP
- Reserva de CPU dos VP em cada VM
- Peso da CPU dos VP em cada VM
- Localização do nó NUMA (Non Uniform Memory Architecture) dos VP em cada VM
Talvez você esteja se perguntando o motivo do Scheduler fazer este processo de alocação dinâmica de LP para as maquinas virtuais. Antes de tudo é importante entender que este processo não causa penalidades para o processamento em geral da maquina, até mesmo porque antes de ler este artigo você não sabia da existência deste mecanismo e talvez nunca tenha se deparado com esta análise de desempenho.
O Scheduler possui vários benefícios, sendo o principal a alocação inteligente e dinâmica de uso de CPU apenas para as demandas necessárias. Outro benefício do Scheduler está intimamente ligado à redução no consumo de energia da CPU. Em qualquer análise de TI verde e consume de energia em um computador nós temos a CPU como um dos itens de maior consumo de energia. Portanto qualquer técnica que você empregue para reduzir o uso de CPU traz benefícios diretos na economia de energia da maquina.
A grande maioria dos processadores suporta um comando chamado C State, que significa colocar núcleos em modo “estacionado” (parked) ou suspensos. Isto significa que um sistema operacional que suporte o C State pode enviar comandos para o processador físico “suspender” de forma dinâmica os núcleos que não estão sendo utilizados no momento. Da mesma forma se houver alguma demanda de CPU o sistema operacional pode enviar comandos C State para processador físico “ativar” somente os núcleos necessários para atender a demanda (desta forma não precisa ativar todos os núcleos, apenas o que precisar naquele momento). Isto é bem diferente de suspender o processador físico inteiro (o que talvez pudesse eventualmente causar algum problema futuro), pois apenas os núcleos são afetados.
No cenário a seguir temos um servidor com 4 processadores físicos, com 4 núcleos cada. Também temos representado varias maquinas virtuais utilizando os núcleos. No cotidiano sabemos que muitos servidores nem sempre utilizam toda a CPU, apenas uma pequena parte.
Nesta situação o Scheduler pode mover dinamicamente as VP para outros núcleos / Cores , de forma que esta agregação não cause impacto de CPU excessivo.
Uma vez que foi feito a movimentação de VP das maquinas virtuais para outros núcleos / Cores então o sistema operacional pode enviar comandos C State para “estacionar” os núcleos que não estão sendo utilizados.
Esta tecnologia que permite “estacionar” ou “suspender” núcleos existe no Windows 7, Windows Server 2008 / R2 em diante e é chamada de Core Parking. Você pode ver sua utilização e saber quais núcleos / Cores estão atualmente suspensos ou não através do Resource Monitor, na aba CPU
No detalhe vocês podem reparar que a CPU 1 aparece em cinza (diferente das demais) e Parked. Isto significa que neste momento o núcleo 1 está em Parked, porém se você ficar observado em seu computador ou servidor vai reparar que as CPUs ficam constantemente trocando seu status de normal para Parked, e vice-versa. Por padrão o Core Parking vem habilitado e é possível desabilitar, porém não é aconselhável, pois você perde este importante recurso de economia de energia.
Outro fator que pode causar impacto na taxa de VP:LP é a quantidade de núcleos / Cores e a velocidade dos mesmos.
- Workloads de CPU intensivo nas VMs tem mais benefício em arquiteturas de CPU com mais ciclos (sem a necessidade de muitos Cores)
- Exchange, Biztalk, SQL e outros: recomendado taxa de 1:1
- Workloads de CPU não intensivos nas VMs terão maior benefício em arquiteturas de CPU com poucos ciclos, porém com mais cores ou threads
- Cenários de VDI com baixo requisito de CPU por VPs de VM
Para entender estes pontos vamos supor que você precise virtualizar um servidor cuja aplicação tem por recomendação do fabricante o uso de 2 CPUs com mínimo de 200 ciclos de CPU. Não são todos os fabricantes que conseguem passar uma especificação na aplicação, mas ter esta informação ajuda a dimensionar melhor o hardware.
Baseado nesta necessidade você resolveu criar uma maquina virtual com 2 CPUs, porém você tem 2 servidores de virtualização que você está homologando:
- Servidor A: Hyper-V Server com 4 núcleos / Cores e 50 ciclos de CPU por núcleo / Core
- Servidor B: Hyper-V Server com 2 núcleos / Cores e 100 ciclos de CPU por núcleo / Core
No teste com o servidor A você verifica que o total de ciclos suportados em uma VM com2 vCPUs chega a atingir máximo de 100 ciclos de CPU. No servidor B você descobre que a mesma maquina virtual consegue funcionar bem com as 2 vCPUs, totalizando 200 ciclos de CPU disponíveis.
Caso queira manter a aplicação no servidor A será necessário alocar mais vCPUs para a maquina virtual de forma que ela possa totalizar os 200 ciclos de CPU necessários para a aplicação. Este exemplo é bem interessante, pois significa que quantidade de núcleos nem sempre oferece maior desempenho. Em geral quando virtualizamos desktops Windows 7 para cenários de VDI temos uma demanda baixa de CPU, o que significa que adquirir um servidor com muitos núcleos para este cenário ajuda a ter uma boa densidade de VMs por servidor. Obviamente cada cenário tem que ser analisado, mas o que importa realmente é que se deve analisar com cuidado cada servidor, de acordo com a demanda de CPU necessária.