Quanta contesa è troppo in VMware?

Per un po 'di tempo ho cercato di capire perché alcuni dei nostri sistemi business-critical stanno ricevendo segnalazioni di "lentezza" che vanno da lievi a estreme. Di recente ho focalizzato la mia attenzione sull'ambiente VMware in cui sono ospitati tutti i server in questione.

Di recente ho scaricato e installato la versione di prova per il management pack di Veeam VMware per SCOM 2012, ma sto facendo fatica a credere (e così anche al mio capo) i numeri che mi sta segnalando. Per provare a convincere il mio capo che i numeri che mi sta dicendo sono veri, ho iniziato a cercare il client VMware stesso per verificare i risultati.

Ho visto questo articolo di VMware KB ; specificamente per la definizione di Co-Stop che è definita come:

Tempo durante il quale una macchina virtuale MP era pronta per essere eseguita, ma ha subito un ritardo a causa della contesa di pianificazione di co-vCPU

A cui sto traducendo

Il sistema operativo guest richiede tempo dall'host, ma deve attendere che le risorse diventino disponibili e pertanto possono essere considerate "non rispondenti"

Questa traduzione sembra corretta?

Se è così, qui è dove faccio fatica a credere a ciò che vedo: l'host che contiene la maggior parte delle VM "lente" sta attualmente mostrando una media di Co-stop della CPU di 127.835,94 millisecondi!

Questo significa che in media le VM su questo host devono attendere 2+ minuti per il tempo della CPU ???

Questo host ha due CPU a 4 core e ha guest CPU 1x8 e guest CPU 14x4.

Posso descrivere alcune delle esperienze che ho avuto in questo settore ...

Non credo che VMware svolga un lavoro adeguato nell'educare i clienti ( o gli amministratori ) sulle best practice, né aggiornano le best practice precedenti man mano che i loro prodotti si evolvono. Questa domanda è un esempio di come un concetto chiave come l'allocazione di vCPU non sia completamente compreso. L'approccio migliore è iniziare in piccolo, con una singola vCPU, fino a quando non si determina che la VM richiede di più.

Per l'OP, il server host ESXi ha due CPU quad-core, che producono 8 core fisici.

Il layout della macchina virtuale descritto è di 15 ospiti totali; 1 x 8 vCPU e 14 x 4 sistemi vCPU. È troppo complicato, soprattutto con l'esistenza di un singolo guest con 8 vCPU . Non ha senso. Se hai bisogno di una VM così grande, probabilmente hai bisogno di un server più grande.

Prova a ridimensionare le tue macchine virtuali. Sono abbastanza sicuro che molti di loro possano vivere con 2 vCPU. L'aggiunta di CPU virtuali non rende le cose più veloci, quindi se questo è un rimedio a un problema di prestazioni, è l'approccio sbagliato da adottare.

Nella maggior parte degli ambienti, la RAM è la risorsa più limitata. Ma la CPU può essere un problema se c'è troppa contesa. Ne hai la prova. La RAM può anche essere un problema se viene allocato troppo alle singole VM .

È possibile monitorare questo. La metrica che stai cercando è "% CPU pronto". È possibile accedervi dal client vSphere selezionando una macchina virtuale e andando su Performance>> OverviewGrafico CPU.

• Meno del 5% CPU Ready - Stai bene.
• 5-10% CPU Ready : osserva da vicino l'attività.
• Oltre il 10% di CPU Ready - Non buono.

Nota la linea gialla nel grafico qui sotto.

Ti dispiacerebbe controllare questo sui tuoi problemi di macchine virtuali e riportare indietro?

Si afferma nei commenti che si dispone di un host ESXi quad-core doppio e si esegue una VM 8vCPU e quattordici VM 4vCPU.

Se questo fosse il mio ambiente, lo considererei grossolanamente eccessivo. Metterei al massimo da quattro a sei guest 4vCPU su quell'hardware. (Ciò presuppone che le macchine virtuali in questione abbiano un carico che richiede che abbiano un conteggio di vCPU così elevato.)

Suppongo che tu non conosca la regola d'oro ... con VMware non dovresti mai assegnare a una VM più core del necessario. Ragionare? VMware utilizza una co-pianificazione piuttosto rigida che rende difficile per le VM ottenere tempo CPU a meno che non ci siano tanti core disponibili quanti sono assegnati alla VM. Ciò significa che una VM 4vCPU non può eseguire 1 unità di lavoro a meno che non ci siano 4 core fisici aperti nello stesso momento. In altre parole, è architettonicamente migliore avere una VM 1vCPU con carico CPU del 90%, quindi avere una VM 2vCPU con carico 45% per core.

Quindi ... SEMPRE creare macchine virtuali con un minimo di vCPU e aggiungerle solo quando è ritenuto necessario.

Per la tua situazione, utilizza Veeam per monitorare l'utilizzo della CPU sui tuoi ospiti. Riduci il numero di vCPU sul maggior numero possibile. Sarei disposto a scommettere che potresti scendere a 2vCPU su quasi tutti i tuoi ospiti 4vCPU esistenti.

Certo, se tutte queste macchine virtuali hanno effettivamente il carico della CPU per richiedere il conteggio vCPU che hanno, allora devi semplicemente acquistare hardware aggiuntivo.

127.835,94 millisecondi è una somma e devi dividere per il tempo di campionamento per ottenere i valori% RDY corretti. Tuttavia, sembra che tu stia già ricevendo le letture% RDY corrette. Puoi andare abbastanza in alto con il rapporto vCPU in cpu fisico ma non nel modo in cui lo stai facendo.

Hai troppe VM quad vCPU e persino una VM 8 vCPU. Esistono già alcune risposte di qualità che discutono del dimensionamento corretto e alcune ramificazioni di cicli non consolidanti a meno vCPU. L'unica cosa che volevo chiarire è che mentre non è più il caso che una VM debba attendere che il numero di CPU fisiche pari al suo numero di vCPU sia disponibile prima che qualsiasi istruzione possa essere elaborata, è molto dannosa avere un provisioning eccessivo di questa entità con il rapporto tra VM multi-vCPU e core fisici. 64 vCPU su 8 core sono ben oltre il rapporto massimo di 4 a 1. Presumo che tu abbia HT su questi processori, quindi hai 16 core logici? Ciò potrebbe essere OK con 1 e 2 VM vCPU che hanno un carico leggero, ma se si dispone di un carico pesante sulle VM sarebbe difficile da realizzare.

Cordiali saluti I processori HT non sono utilizzati nei calcoli della% di CPU utilizzati - il che significa che se si dispone di 32 core logici in esecuzione a 2,4 Ghz su un server, si è al 100% quando si arriva a 38,4 GHz. Quindi, quando vedi le medie di carico che mostrano più di 1.0, ecco perché.

Ecco un host ESXi che esegue un rapporto da 3,5 a 1 da vCPU a CPU fisica (compresi i core HT) con un% RDY medio del 3%.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

Da allora abbiamo installato Veeam ONE che ha fatto luce su dove sono i nostri problemi di prestazioni. Osservando la schermata dei colli di bottiglia della CPU in Veeam ONE, quindi utilizzando Risoluzione dei problemi di una macchina virtuale che ha smesso di rispondere: confronto sull'utilizzo della CPU VMM e Guest come riferimento, abbiamo capito dove si trova la nostra contesa "inaccettabile".

Un piccolo suggerimento che volevo condividere specificamente è che in un caso non avrei potuto eliminare la contesa della CPU fino a quando non avessi rimosso l'istantanea che era sulla VM. Spero che questo aiuti qualcuno.