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

Eu estava lendo alguns artigos do technet, bem como este, sobre as diferenças entre a maneira como o VMware e o hyper v realizam o agendamento da CPU.

Fiquei me perguntando se eu poderia obter algumas informações objetivas sobre isso. Parece que o agendamento de gangues usado pelo VMware é uma enorme desvantagem, mas eu não quero apenas beber o refrigerante. Isso afeta seriamente o desempenho ou as iterações mais recentes dos hipervisores da VMware resolvem isso?

Edit: Quando digo desvantagem, quero dizer em relação ao "agendamento de processador livre" do Hyper V ou, no entanto, o KVM faz isso. O material que eu estava lendo não dizia que havia problemas com o "agendamento de processador livre" que são evitados com o agendamento de grupos.

Como cantar Bloody Mary em um espelho escuro do banheiro, vamos ver se conseguimos fazer Jake Oshins aparecer ...

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

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

O co-agendamento relaxado substituiu o estrito co-agendamento no ESX 3.xe foi aprimorado nas versões subseqüentes para obter melhor utilização da CPU e oferecer suporte a amplas máquinas virtuais multiprocessadoras. O co-agendamento relaxado possui algumas propriedades distintas em comparação com o rigoroso algoritmo de co-agendamento. O mais importante de tudo, enquanto no rigoroso algoritmo de co-agendamento, a existência de uma vCPU atrasada faz com que toda a máquina virtual seja interrompida. No algoritmo de co-agendamento relaxado, uma vCPU líder decide se deve parar-se com base na inclinação contra a vCPU do irmão mais lento. Se a inclinação for maior que um limite, a vCPU principal pára automaticamente. Observe que uma vCPU com atraso é aquela que progride significativamente menos do que a vCPU entre irmãos mais rápidos, enquanto uma vCPU líder é aquela que progride significativamente mais do que a vCPU mais lenta do irmão. Ao rastrear a vCPU mais lenta, agora é possível para cada vCPU tomar sua própria decisão de co-agendamento de forma independente. Como co-stop, a decisão de co-start também é tomada individualmente. Depois que a vCPU do irmão mais lento começa a progredir, as vCPUs co-interrompidas são elegíveis para co-iniciar e podem ser agendadas dependendo da disponibilidade da pCPU. Isso resolve o problema de fragmentação da CPU no algoritmo estrito de co-agendamento, não exigindo que um grupo de vCPUs seja agendado juntos. No exemplo anterior da máquina virtual de 4 vCPU, a máquina virtual pode progredir adiante mesmo se houver apenas uma pCPU inativa disponível. Isso melhora significativamente a utilização da CPU. Ao rastrear a vCPU de irmão mais lento, agora é possível para cada vCPU tomar sua própria decisão de co-agendamento de forma independente. Como co-stop, a decisão de co-start também é tomada individualmente. Depois que a vCPU do irmão mais lento começa a progredir, as vCPUs co-interrompidas são elegíveis para co-iniciar e podem ser agendadas dependendo da disponibilidade da pCPU. Isso resolve o problema de fragmentação da CPU no algoritmo estrito de co-agendamento, não exigindo que um grupo de vCPUs seja agendado juntos. No exemplo anterior da máquina virtual de 4 vCPU, a máquina virtual pode progredir adiante mesmo se houver apenas uma pCPU inativa disponível. Isso melhora significativamente a utilização da CPU. Ao rastrear a vCPU de irmão mais lento, agora é possível para cada vCPU tomar sua própria decisão de co-agendamento de forma independente. Como co-stop, a decisão de co-start também é tomada individualmente. Depois que a vCPU do irmão mais lento começa a progredir, as vCPUs co-interrompidas são elegíveis para co-iniciar e podem ser agendadas dependendo da disponibilidade da pCPU. Isso resolve o problema de fragmentação da CPU no algoritmo estrito de co-agendamento, não exigindo que um grupo de vCPUs seja agendado juntos. No exemplo anterior da máquina virtual de 4 vCPU, a máquina virtual pode progredir adiante mesmo se houver apenas uma pCPU inativa disponível. Isso melhora significativamente a utilização da CPU. Depois que a vCPU do irmão mais lento começa a progredir, as vCPUs co-interrompidas são elegíveis para co-iniciar e podem ser agendadas dependendo da disponibilidade da pCPU. Isso resolve o problema de fragmentação da CPU no algoritmo estrito de co-agendamento, não exigindo que um grupo de vCPUs seja agendado juntos. No exemplo anterior da máquina virtual de 4 vCPU, a máquina virtual pode progredir adiante mesmo se houver apenas uma pCPU inativa disponível. Isso melhora significativamente a utilização da CPU. Depois que a vCPU do irmão mais lento começa a progredir, as vCPUs co-interrompidas são elegíveis para co-iniciar e podem ser agendadas dependendo da disponibilidade da pCPU. Isso resolve o problema de fragmentação da CPU no algoritmo estrito de co-agendamento, não exigindo que um grupo de vCPUs seja agendado juntos. No exemplo anterior da máquina virtual de 4 vCPU, a máquina virtual pode progredir adiante mesmo se houver apenas uma pCPU inativa disponível. Isso melhora significativamente a utilização da CPU. a máquina virtual pode progredir adiante mesmo que haja apenas uma pCPU ociosa disponível. Isso melhora significativamente a utilização da CPU. a máquina virtual pode progredir adiante mesmo que haja apenas uma pCPU ociosa disponível. Isso melhora significativamente a utilização da CPU.

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

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

A única coisa que fornecerá números concretos é uma referência e será totalmente dependente dos tipos de código que as CPUs estão executando. Mas posso garantir que, se a VMware estivesse em desvantagem, eles ainda não teriam a maior parte do mercado de virtualização.

Ok, Ryan, você fez o meu dia. Não leio este fórum tanto quanto costumava ler, mas fiz o check-in.

Red888, você deve saber de antemão que sou um arquiteto de software que trabalha no Hyper-V na Microsoft. Suponho que a maioria das pessoas que lê isso é perfeitamente capaz de clicar no link do meu nome abaixo e descobrir isso ou até mesmo pesquisar no Google, mas para esta resposta é útil ter certeza absoluta de que as pessoas que lêem isso não têm dúvidas sobre minha perspectiva.

Em geral, o agendamento de grupos é útil se o hipervisor não tiver como influenciar o comportamento do SO em execução na VM. É 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, é aqui que eu teria começado.

O agendamento de grupos, e a VMware provavelmente diria que estou certo sobre isso, deixa muitas limitações sobre como você pode usar os processadores físicos na máquina. O hipervisor geralmente não consegue encontrar o recurso certo adequado para o momento. Então, eles modificaram seu algoritmo ao longo dos anos, procurando maneiras de programar que funcionem melhor.

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

Curiosamente, na Microsoft, nos preocupamos mais com o Windows executando bem em comparação com outros sistemas operacionais do que com o Hyper-V com melhor aparência do que VMware, KVM, Xen, Oracle ou Unisys etc. Por isso, publicamos as interfaces que o Windows usa para cooperar com um hipervisor. Aqui está um link se você estiver curioso, embora eu não o recomende como leitura na hora de dormir:

http://www.bing.com/search?q=Hypervisor+Top-Level+Functional+Specification+3.0a%3A+Windows+Server+2012&src=IE-SearchBox&FORM=IESR02

Portanto, qualquer fornecedor de hipervisor pode expor as coisas que acionarão o comportamento cooperativo do Windows. Vários deles têm. Sinceramente, não sei se o VMware tem, ou faz, ou irá expor isso. Você teria que perguntar a eles, ou alguém que presta muita atenção a eles. E se o fizerem, eu ficaria muito surpreso se eles não tivessem modificado o agendador para relaxar ainda mais. Essa última afirmação, é claro, é pura especulação.

Portanto, minha resposta final é que duvido que você deva tomar uma decisão de compra em 2014 com base em como o planejador de hipervisor funciona. Suspeito que todos estejam muito bons agora. Alguns anos atrás, isso pode não ter sido verdade.

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