La pianificazione delle bande impiegata da VMware è un grave svantaggio?

Stavo leggendo alcuni articoli di technet e questo riguardo alle differenze tra il modo in cui VMware e hyper v eseguono la programmazione della CPU.

Mi chiedevo se avrei potuto ottenere alcune informazioni oggettive su questo. Sembrerebbe che la pianificazione delle bande utilizzata da VMware sia uno svantaggio ENORME, ma non voglio solo bere il coolaid. Influisce gravemente sulle prestazioni o le ultime iterazioni degli hyper visor di VMware risolvono questo problema?

Modifica: quando dico svantaggio intendo relativamente alla "programmazione del processore libera" di Hyper V o comunque KVM lo fa. Il materiale che stavo leggendo non diceva che ci fossero problemi con la "programmazione gratuita del processore" che sono stati evitati con la programmazione gang.

Come cantare Bloody Mary in uno specchio del bagno buio, vediamo se riusciamo a far apparire Jake Oshins ...

La pianificazione delle bande viene anche definita pianificazione condivisa. Penso che VMware preferisca il termine co-scheduling alla programmazione di gruppo.

Nelle versioni ESX precedenti alla 3.x, VMware utilizzava una co-pianificazione "rigorosa", che presentava gli svantaggi della sincronizzazione. In ESX 3.xe versioni successive, VMware è passato alla co-pianificazione "rilassata".

La co-programmazione semplificata ha sostituito la rigida co-pianificazione in ESX 3.x ed è stata perfezionata nelle versioni successive per ottenere un migliore utilizzo della CPU e supportare ampie macchine virtuali multiprocessore. La co-programmazione rilassata ha alcune proprietà distintive rispetto al rigoroso algoritmo di co-pianificazione. Soprattutto, mentre nel rigoroso algoritmo di co-scheduling, l'esistenza di una vCPU in ritardo fa arrestare l'intera macchina virtuale. Nell'algoritmo rilassato di co-scheduling, una vCPU leader decide se deve essere arrestata in base allo skew rispetto alla vCPU fratello più lento. Se l'inclinazione è maggiore di una soglia, la vCPU principale si interrompe da sola. Tieni presente che una vCPU in ritardo è quella che fa progressi significativamente inferiori rispetto alla vCPU di fratelli più veloce, mentre una vCPU leader è quella che fa progressi significativamente maggiori rispetto alla vCPU fratello più lento. Tracciando la vCPU fratello più lento, è ora possibile per ogni vCPU prendere la propria decisione di co-pianificazione in modo indipendente. Come co-stop, anche la decisione di co-start viene presa individualmente. Una volta che la vCPU fratello più lento inizia a progredire, le vCPU co-arrestate sono idonee a ricominciare e possono essere programmate in base alla disponibilità della pCPU. Ciò risolve il problema di frammentazione della CPU nel rigoroso algoritmo di co-schedulazione non richiedendo che un gruppo di vCPU venga pianificato insieme. Nell'esempio precedente della macchina virtuale a 4 vCPU, la macchina virtuale può fare progressi anche se è disponibile solo una pCPU inattiva. Ciò migliora significativamente l'utilizzo della CPU. Tracciando la vCPU fratello più lento, è ora possibile per ogni vCPU prendere la propria decisione di co-pianificazione in modo indipendente. Come co-stop, anche la decisione di co-start viene presa individualmente. Una volta che la vCPU fratello più lento inizia a progredire, le vCPU co-arrestate sono idonee a ricominciare e possono essere programmate in base alla disponibilità della pCPU. Ciò risolve il problema di frammentazione della CPU nel rigoroso algoritmo di co-schedulazione non richiedendo che un gruppo di vCPU venga pianificato insieme. Nell'esempio precedente della macchina virtuale a 4 vCPU, la macchina virtuale può fare progressi anche se è disponibile solo una pCPU inattiva. Ciò migliora significativamente l'utilizzo della CPU. Tracciando la vCPU fratello più lento, è ora possibile per ogni vCPU prendere la propria decisione di co-pianificazione in modo indipendente. Come co-stop, anche la decisione di co-start viene presa individualmente. Una volta che la vCPU fratello più lento inizia a progredire, le vCPU co-arrestate sono idonee a ricominciare e possono essere programmate in base alla disponibilità della pCPU. Ciò risolve il problema di frammentazione della CPU nel rigoroso algoritmo di co-schedulazione non richiedendo che un gruppo di vCPU venga pianificato insieme. Nell'esempio precedente della macchina virtuale a 4 vCPU, la macchina virtuale può fare progressi anche se è disponibile solo una pCPU inattiva. Ciò migliora significativamente l'utilizzo della CPU. Una volta che la vCPU fratello più lento inizia a progredire, le vCPU co-arrestate sono idonee a ricominciare e possono essere programmate in base alla disponibilità della pCPU. Ciò risolve il problema di frammentazione della CPU nel rigoroso algoritmo di co-schedulazione non richiedendo che un gruppo di vCPU venga pianificato insieme. Nell'esempio precedente della macchina virtuale a 4 vCPU, la macchina virtuale può fare progressi anche se è disponibile solo una pCPU inattiva. Ciò migliora significativamente l'utilizzo della CPU. Una volta che la vCPU fratello più lento inizia a progredire, le vCPU co-arrestate sono idonee a ricominciare e possono essere programmate in base alla disponibilità della pCPU. Ciò risolve il problema di frammentazione della CPU nel rigoroso algoritmo di co-schedulazione non richiedendo che un gruppo di vCPU venga pianificato insieme. Nell'esempio precedente della macchina virtuale a 4 vCPU, la macchina virtuale può fare progressi anche se è disponibile solo una pCPU inattiva. Ciò migliora significativamente l'utilizzo della CPU. la macchina virtuale può fare progressi anche se è disponibile solo una pCPU inattiva. Ciò migliora significativamente l'utilizzo della CPU. la macchina virtuale può fare progressi anche se è disponibile solo una pCPU inattiva. Ciò migliora significativamente l'utilizzo della CPU.

Lo snippet sopra è tratto dalla documentazione di VMware .

Quindi VMware non utilizza più una rigida pianificazione di gruppo. Tratterei la documentazione direttamente dal venditore come più autorevole.

L'unica cosa che ti darà numeri concreti è un benchmark, e dipenderà interamente dal tipo di codice che le CPU stanno eseguendo. Ma posso dirti che se VMware fosse in tale svantaggio, non avrebbe ancora la quota del leone nel mercato della virtualizzazione.

Ok, Ryan, mi hai reso felice. Non leggo questo forum tanto come una volta, ma mi è capitato di fare il check-in.

Red888, dovresti sapere in anticipo che sono un architetto software che lavora su Hyper-V presso Microsoft. Suppongo che la maggior parte delle persone che leggono questo sia perfettamente in grado di fare clic sul collegamento del mio nome qui sotto e scoprirlo, o persino cercarmi su Google, ma per questa risposta è utile essere del tutto certi che le persone che leggono questo non hanno dubbi sulla mia prospettiva.

In generale, la pianificazione delle bande è utile se l'hypervisor non ha alcun modo di influenzare il comportamento del sistema operativo in esecuzione nella VM. Questo è, ovviamente, il motivo per cui VMware ha iniziato in questo modo. Non possiedono alcun sistema operativo e quindi il loro obiettivo era far funzionare bene i sistemi operativi esistenti. Se fossi in loro, questo è dove avrei iniziato.

La pianificazione di gruppo, e VMware probabilmente direbbe che ho ragione, lascia molte limitazioni su come utilizzare i processori fisici all'interno della macchina. L'hypervisor spesso non trova la giusta risorsa adatta per il momento. Quindi hanno modificato il loro algoritmo nel corso degli anni, cercando modi per fare meglio la pianificazione.

Microsoft (e probabilmente molte altre società) ha iniziato con una visione diversa. Possediamo Windows. Faremo in modo che Windows si comporti bene quando virtualizzato. E quindi la programmazione delle bande non sarà necessaria. Non ci preoccuperemo nemmeno di costruire un programmatore di gang.

È interessante notare che noi di Microsoft ci preoccupiamo di più del funzionamento di Windows rispetto ad altri sistemi operativi di quanto non ci interessi a Hyper-V che sembra migliore di VMware, KVM, Xen, Oracle o Unisys, ecc. Quindi abbiamo pubblicato le interfacce che Windows usa per cooperare con un hypervisor. Ecco un link se sei curioso, anche se non lo consiglio come lettura prima di coricarsi:

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

Quindi qualsiasi fornitore di hypervisor può esporre le cose che attiveranno il comportamento cooperativo da Windows. Molti di loro hanno. Onestamente non so se VMware ha, o lo fa, o lo esporrà. Dovresti chiedere loro, o qualcuno che presta molta attenzione a loro. E se lo fanno, sarei molto sorpreso se non avessero modificato il loro programmatore per rilassarsi ancora di più. Quest'ultima affermazione, ovviamente, è pura speculazione.

Quindi la mia risposta è che dubito che dovresti prendere una decisione di acquisto nel 2014 in base a come funziona lo scheduler hypervisor. Ho il sospetto che ormai siano tutti abbastanza bravi. Qualche anno fa, potrebbe non essere vero.

Dovresti provare i tuoi carichi di lavoro sui vari sistemi e vedere come funzionano. Scommetto che la tua prestazione finale dipende dal fatto che lo spazio di archiviazione e la rete soddisfino le tue esigenze.