O agendamento de gangues empregado pela VMware é uma séria desvantagem?

Question

Eu estava lendo alguns artigos de technet, bem como sobre as diferenças entre o modo como o VMware e o hyper v estão fazendo o escalonamento da CPU.

Eu queria saber se eu poderia obter alguma informação objetiva sobre isso. Parece que o agendamento de gangues usado pela VMware é uma desvantagem ENORME, mas eu não quero apenas beber o coolóide. Isso afeta seriamente o desempenho ou as iterações mais recentes dos hyper visors da VMware resolvem isso?

Edit: Quando digo desvantagem, quero dizer em relação ao "free processor scheduling" do Hyper V ou no entanto o KVM faz isso. O material que eu estava lendo não dizia que havia algum problema com o "agendamento livre do processador" que é evitado com o agendamento de gangues.

    

Answer 1

Como cantar Bloody Mary em um espelho de banheiro escuro, vamos ver se conseguimos mostrar Jake Oshins ...

O agendamento de gangues também é chamado de co-agendamento. Eu acho que a VMware prefere o termo co-agendamento para agendamento de gangues.

Nas versões do ESX anteriores à versão 3.x, a VMware usava o co-agendamento "estrito", que tinha as desvantagens da sincronização. No ESX 3.xe acima, o VMware mudou para o co-agendamento "relaxado".

Relaxed co-scheduling replaced the strict co-scheduling in ESX 3.x and has been refined in subsequent releases to achieve better CPU utilization and to support wide multiprocessor virtual machines. Relaxed co-scheduling has a few distinctive properties compared to the strict co-scheduling algorithm. Most important of all, while in the strict co-scheduling algorithm, the existence of a lagging vCPU causes the entire virtual machine to be co-stopped. In the relaxed co-scheduling algorithm, a leading vCPU decides whether it should co-stop itself based on the skew against the slowest sibling vCPU. If the skew is greater than a threshold, the leading vCPU co-stops itself. Note that a lagging vCPU is one that makes significantly less progress than the fastest sibling vCPU, while a leading vCPU is one that makes significantly more progress than the slowest sibling vCPU. By tracking the slowest sibling vCPU, it is now possible for each vCPU to make its own co-scheduling decision independently. Like co-stop, the co-start decision is also made individually. Once the slowest sibling vCPU starts progressing, the co-stopped vCPUs are eligible to co-start and can be scheduled depending on pCPU availability. This solves the CPU fragmentation problem in the strict co-scheduling algorithm by not requiring a group of vCPUs to be scheduled together. In the previous example of the 4- vCPU virtual machine, the virtual machine can make forward progress even if there is only one idle pCPU available. This significantly improves CPU utilization.

O snippet acima é da própria documentação da VMware.

Portanto, o VMware não está mais usando o agendamento estrito de gangues. Eu trataria a documentação diretamente do fornecedor como sendo mais autoritária.

A única coisa que lhe dará números concretos é um benchmark, e será totalmente dependente dos tipos de código que as CPUs estão rodando. Mas posso dizer que se a VMware estivesse em desvantagem, eles ainda não teriam a maior parte do mercado de virtualização.

    

Answer 2

Ok, Ryan, você fez meu dia. Eu não leio esse fórum tanto quanto costumava, mas aconteceu de eu fazer o check-in.

Red888, você deve saber de antemão que sou um arquiteto de software que trabalha com o Hyper-V na Microsoft. Eu suponho que a maioria das pessoas lendo isso é perfeitamente capaz de clicar no meu link abaixo e descobrir isso, ou até mesmo me pesquisando, mas para essa resposta é útil ter certeza absoluta de que as pessoas que estão lendo não têm dúvidas sobre minha perspectiva. p>

Em geral, o agendamento de gangues é útil se o hipervisor não tiver nenhuma maneira de influenciar o comportamento do sistema operacional em execução na VM. É claro, é por isso que a VMware começou dessa maneira. Eles não possuem nenhum sistema operacional e, portanto, seu objetivo era fazer com que os sistemas operacionais existentes funcionassem bem. Se eu fosse eles, isso é onde eu teria começado.

Agendamento de gangues, e o VMware provavelmente diria que estou certo sobre isso, deixa muitas limitações sobre como você pode usar os processadores físicos dentro da máquina. O hipervisor geralmente não consegue encontrar o recurso certo para o momento. Então, eles modificaram o algoritmo deles ao longo dos anos, procurando maneiras de agendar melhor o trabalho.

A Microsoft (e provavelmente várias outras empresas) começou com uma visão diferente. Nós possuímos o Windows. Nós faremos com que o Windows se comporte bem quando virtualizado. E assim, o agendamento de gangues não será necessário. Nós nem sequer nos preocuparemos em construir um agendador de gangues.

Curiosamente, nós da Microsoft nos preocupamos mais com o Windows rodando bem em comparação com outros sistemas operacionais do que com o Hyper-V parecendo melhor que o VMware, ou KVM, ou Xen, Oracle, Unisys, etc. interfaces que o Windows usa para cooperar com um hypervisor. Aqui está um link se você estiver curioso, embora eu não recomende a leitura para dormir:

link

Assim, qualquer fornecedor de hipervisores pode expor o material que acionará o comportamento cooperativo do Windows. Vários deles têm. Eu sinceramente não sei se a VMware tem, ou exponha isso. Você teria que perguntar a eles, ou a alguém que presta muita atenção a eles. E se o fizerem, ficaria muito surpreso se eles não tivessem modificado o agendador para relaxar ainda mais. Essa última declaração, é claro, é pura especulação.

Então, minha resposta final é que duvido que você deva tomar uma decisão de compra em 2014, com base em como o hipervisor agendado funciona. Eu suspeito que eles são todos muito bons agora. Há alguns anos, isso pode não ter sido verdade.

Você deve testar suas cargas de trabalho nos vários sistemas e ver como eles funcionam. Aposto que seu desempenho final se resume em saber se o armazenamento e a rede atendem às suas necessidades.