Quando spostare un server virtualizzato su fisico?

La virtualizzazione offre alcuni grandi vantaggi, ma a volte un server virtualizzato necessita di maggiori prestazioni e deve essere spostato su fisico.

La mia domanda è: come si fa a sapere quando sono questi tempi? Sto cercando dati misurabili e metriche che mostrano che spostare un server nella propria scatola fisica farebbe una differenza significativa nelle prestazioni. Personalmente sono interessato a Windows ma presumibilmente gli elementi essenziali sono gli stessi su tutte le piattaforme.

L'unico caso in cui ho dovuto eseguire un V2P era per un box MS SQL che era in esecuzione su CPU dual core dual 3.2Ghz (CPU totale 14.4Ghz) che abbiamo migrato in un cluster ESX 2.5 dove l'hardware sottostante era più recente con più core più lenti (2.4Ghz IIRC). Aggiungendo un overhead del 10% circa anche con 4 vCPU, questa VM potrebbe ottenere una CPU aggregata efficace solo 8-8,5 Ghz. 60% di picco della CPU prima che la migrazione diventasse 90-100% dopo la migrazione, il cliente desiderava un margine di sicurezza, quindi siamo passati al fisico. Per rispondere specificamente alla tua domanda, abbiamo visto che la scatola funzionava al 100% della CPU su tutta la linea in Perfmon e nel client VI. Una soluzione migliore (a mio avviso) sarebbe stata quella di passare a CPU più veloci, ma ci sono casi limite come questo in cui ciò non è economico soprattutto con la tendenza a rallentare la CPU '

Con ESX 4 potremmo sbattere una scatola come questa fino a 8 vCPU ma che al momento non era un'opzione.

Per quanto riguarda la ricerca di massimali di prestazioni che potrebbero indicare la necessità di abbandonare la VM quindi con un Windows Guest su ambiente VMWare, la combinazione di Perfmon e VI Client dovrebbe essere più che all'altezza di trovare qualsiasi VM che abbia prestazioni limitate . Aggiungete un po 'di analisi SAN a questo, se potete, ma se la SAN mostra un problema, sarete quasi sicuramente rielaborando la memoria per isolare e \ o migliorare i volumi su cui sono archiviati i dischi virtuali della VM. Lo stesso vale per qualsiasi altra combinazione OS / Hypervisor: ottieni qualunque statistica interna possibile ma correlale alla visione di Hypervisor su ciò che sta accadendo perché il 100% di CPU che viene segnalato all'interno di una VM (ad esempio) non significa necessariamente che Hypervisor non possa mai fornire più prestazioni,

Non sono d'accordo sul fatto che un server virtuale debba essere spostato su fisico a causa delle prestazioni. Gli hypervisor sono ora così vicini al metal che non c'è praticamente (gioco di parole intenzionale) nessun impatto sulle prestazioni. Soprattutto ora che molti produttori di schede stanno includendo hypervisor nel chipset. Se prendessi due server con hardware identico, uno che eseguiva un singolo guest e uno che eseguiva una copia esatta di quel guest sull'hardware fisico, penso che potresti notare una differenza nelle prestazioni.

Esistono altri motivi, tuttavia, potrebbe essere necessario un server fisico anziché virtuale. Uno di questi è la compatibilità hardware. Se l'applicazione richiede hardware non standard con un proprio bus univoco, potrebbe non essere possibile eseguirlo in una macchina virtuale.

Sono ansioso di sapere cosa hanno da dire gli altri. Ottima domanda

NOTA: abbiamo server che sono stati virtualizzati e quindi rimessi sullo stesso hardware solo per avere le capacità di istantanea / vmotion che amiamo.

Non sono un esperto di questo argomento, ma in generale: le applicazioni I / O molto affamate (specialmente quelle che scrivono poco e velocemente) sono quelle che ottengono il proprio server fisico.

Non è nemmeno difficile trovarli, basta eseguire il monitor delle prestazioni e cercare tempi di attesa di I / O elevati.

Inoltre, i database di fascia alta di solito ottengono il proprio server dedicato, per diversi motivi:

1. Vogliono memorizzare nella cache tutto ciò che possono, l'utilizzo della RAM è enorme
2. Funzionano meglio con il threading su più core (8 vie è normale) e in genere non si desidera assegnare più di 1 CPU virtuale a qualsiasi server a causa del blocco
3. Sono molto affamati di I / O durante il caricamento dei dati nella cache, la latenza bassa sull'I / O è fondamentale.

Questo dipende molto dal servizio che sta eseguendo.

In genere guardo le risorse che vengono utilizzate e determinando se sono effettivamente colli di bottiglia per questo ospite e i servizi che fornisce.

Questo in questo modo:

Se hai un Dual Core (2vSMP), un guest RAM da 4 GB che esegue un server Web (IIS) e non stai esaurendo le richieste di CPU e RAM, forse l'ospite non ha bisogno di altro hardware.

Abbiamo riscontrato casi in cui l'esecuzione di un database Oracle su una piattaforma di virtualizzazione si avvicina alla stessa quantità di prestazioni di un server hardware di dimensioni simili.

Ovviamente, se si desidera avere un server a 16 core come VM, è possibile che si verifichino dei problemi nel vederlo funzionare oltre che nell'hardware dedicato.

Quando la VM ha fame di risorse (o forse muore di fame altre VM per risorse), ad esempio:

1. Quando l'IO della VM non può essere soddisfatta tramite l'host
2. Quando la VM ha bisogno di più larghezza di banda di rete di quanto sia possibile condividere il trunk
3. Quando i processi della VM richiedono più CPU di quanta ne possa ottenere, ad esempio se esiste un singolo processo che sta massimizzando una CPU virtuale
4. Se è Linux e ha bisogno di un tempo molto preciso (se è in esecuzione su un host VMware, host Linux in tempo di deriva VMware. Questo può essere alleviato usando ntp, tuttavia per le app che richiedono un tempo molto preciso, ad esempio Kerberos, potresti considerare l'hardware reale)
5. Quando è Linux e necessita di un disco molto affidabile (se è in esecuzione su un host VMware - VMware ha avuto e credo che abbia ancora problemi SCSI in VMWare in determinate condizioni. È stata pubblicata una correzione ma si verifica ancora, anche se molto meno spesso)

Direi che è quando il server è nel punto in cui sta consumando abbastanza risorse del server da non poter condividere l'hardware.

ESX, ESXi e Window Hyper V dovrebbero offrirti prestazioni quasi reali. Quindi, purché una delle macchine non stia utilizzando il 90% delle risorse da sola, non è necessario passare all'hardware reale.

A parte il fatto che non vorresti cose come i tuoi 2 controller di dominio nella stessa scatola in caso di guasto dell'hardware.

Dubito che ci sia una risposta generica per questo, ma se sei preoccupato per le prestazioni, allora è quello che devi guardare. L'ovvio sarebbe verificare se si sta massimizzando CPU, I / O, ...

Inoltre, i test delle prestazioni e i benchmark ti aiuterebbero anche a decidere se ci sono penalità per essere virtuali e se avere una singola VM sull'host è ragionevole o meno.

È innanzitutto necessario identificare quale risorsa è il collo di bottiglia.

Il monitor delle prestazioni di Windows ( perfmon ) fornisce molti contatori per vari aspetti come la coda del disco, le statistiche della memoria virtuale ecc.

Se sei legato al disco, dare alla macchina virtuale l'accesso diretto a un disco invece di qualcosa come un file vmx con VMWare potrebbe essere di grande aiuto.

Penso che tutto dipenda da due fattori: