Quando spostare un server virtualizzato fisico?

La virtualizzazione ha alcuni grandi vantaggi, ma ci sono momentjs in cui un server virtualizzato necessita di più performance e deve essere spostato fisicamente.

La mia domanda è, come si fa a sapere quando questi tempi sono? Sto cercando dati e metriche misurabili che mostrano che spostamento di un server alla propria casella fisica comporterebbe una differenza significativa rispetto alle performance. Personalmente sono interessato a Windows ma presumibilmente gli elementi essenziali sono gli stessi in tutte le piattaforms.

  • È DAS OK per le macchine virtuali sottoutilizzate?
  • Come eseguire un apparecchio OVA + OVF all'interno di AWS EC2?
  • L'utilizzo di SSL provoca un notevole successo?
  • Come funziona la SAN di LeftHand in un ambiente di produzione?
  • Running router come macchina virtuale, può essere realible?
  • Può una macchina virtuale essere convertita in un server virtuale, ad esempio VMWare?
  • Migliori pratiche per re-IP / migrazione di server e applicazioni
  • Qualsiasi gestore di file a due pannelli cross-platform?
  • Percorso AuthUserFile relativo alla radice host virtuale?
  • 9 Solutions collect form web for “Quando spostare un server virtualizzato fisico?”

    Il caso in cui wherevo eseguire un V2P era per una casella di MS SQL che era in esecuzione su doppio CPU da 3,2 GHz dual core (CPU totale 14,4 GHz) che abbiamo migrato in un cluster ESX 2,5 where l'hardware sottostante è stato più recente con più più lenti (2.4Ghz IIRC). Aggiungendo il ~ 10% overhead anche con 4 vCPU questo VM potrebbe avere sempre un efficace CPU 8-8.5Ghz aggregata. La CPU di picco del 60% prima della migrazione è diventata 90-100% dopo la migrazione, la cliencanvas ha voluto la testata così siamo tornati a fisico. Per rispondere specificamente alla tua domanda, abbiamo visto che la casella era in esecuzione al 100% di CPU attraverso la scheda in Perfmon e nel client VI. Una soluzione migliore (a mio avviso) sarebbe stata l'aggiornamento a CPU più veloci ma ci sono casi di bordo come questo where questo non è economico soprattutto con la tendenza a CPU più lenta con più core che abbiamo visto con l'introduzione di Opterons \ Core CPU.

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

    Per quanto riguarda la ricerca di limiti di performance che potrebbero indicare che è necessario abbandonare la VM poi con un guest Windows in ambiente VMWare, allora la combinazione di Perfmon e il client VI dovrebbe essere più che al task di trovare qualsiasi VM che sia la prestazione limitata . Aggiungete a get alcune analisi SAN se puoi, ma se la SAN mostra un problema, quasi certamente sarà altrettanto bene rielaborare la memory per isolare e / o migliorare i volumi che vengono memorizzati sui dischi virtuali di VM. Lo stesso vale per qualsiasi altra combinazione di OS \ Hypervisor – get qualsiasi statistica interna ma potete correlarle alla visione di Hypervisor di ciò che accade perché la CPU del 100% che viene riportta all'interno di un VM (ad esempio) non significa necessariamente che l'Hypervisor non possa mai fornire più performance, solo che non è stato a quel punto.

    Non sono d'accordo che un server virtuale avrebbe bisogno di essere spostato fisicamente a causa della prestazione. I hypervisor sono ora così vicini al metallo che esiste praticamente (pun intended) nessun colpo di performance. Soprattutto ora che molti board maker sono inclusi hypervisors sul chipset. Se hai preso due server con hardware identico, uno che gestisce un singolo ospite e uno che esegue una copia esatta di quell'ospite sull'hardware fisico, saresti costretto a notare una differenza di performance che penso.

    Ci sono altri motivi, però, potrebbe essere necessario un server fisico piuttosto che virtuale. Uno di loro è la compatibilità hardware. Se la tua applicazione richiede hardware non standard con un proprio bus univoco, potrebbe non essere ansible eseguirlo in una macchina virtuale.

    Sono ansioso di ascoltare quello che gli altri hanno da dire. Grande domanda.

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

    Non sono un esperto in 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 è molto difficile trovarli, è sufficiente eseguire il monitoraggio delle performance e cercare i tempi di attesa di i / o elevati.

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

    1. Vogliono cache tutto quello che possono, l'utilizzo della RAM è enorme
    2. Essi funzionano meglio con il threading attraverso diversi core (8-way è normale) e generalmente non si desidera assegnare più di 1 CPU virtuale a qualsiasi server a causa del block
    3. Sono molto affamati di I / O quando carichi i dati in cache, la chiave di I / O è bassa.

    Questo dipende molto dal servizio che sta eseguendo.

    Io in genere esamina le risorse che vengono utilizzate e determinano se sono veramente bottelnecks per questo ospite ei servizi che fornisce.

    Questo in questo modo:

    Se hai un Dual Core (2vSMP), un guest di RAM da 4 GB che gestisce un server Web (IIS) e non stai usando le richieste CPU e RAM, forse l'ospite non richiede più hardware.

    Abbiamo eseguito i casi in cui l'esecuzione di un database Oracle su una piattaforma di virtualizzazione si avvicina alla stessa quantità di performance di un server hardware di simile dimensione.

    Ovviamente, se voleste avere un server a 16-core come un VM, potresti avere qualche problema a vederlo eseguire oltre a hardware dedicato.

    Quando il VM è affamato per risorse (o forse affamando altre VM per risorse) ad esempio:

    1. Quando l'IO di VM non può essere soddisfatto attraverso l'host
    2. Quando la VM necessita di più width di banda di networking di quanto sia ansible condividere il tronco
    3. Quando i processi di VM richiedono più CPU di quanto non possa get, ad esempio se esiste un singolo process che sta usando una CPU virtuale
    4. Se il suo linux ha bisogno di un tempo molto preciso (se la sua esecuzione su un host di linux di VMware ospita sotto il tempo di deriva di VMware, questo può essere alleviato usando ntp, tuttavia per applicazioni che richiedono tempi molto precisi, ad esempio kerberos,
    5. Quando il suo linux ha bisogno di un disco molto affidabile (se è in esecuzione su un host VMware – VMware ha avuto e credo di avere ancora problemi SCSI sotto VMWare in determinate condizioni. Una correzione è stata messa fuori ma è ancora presente, anche se molto less spesso)

    Direi che quando il server è al punto in cui sta consumando abbastanza risorse del server che non può condividere l'hardware.

    ESX, ESXi e Window Hyper V dovrebbero dare tutte le tue performance. Finché una delle macchine non utilizza il 90% delle risorse da solo, non dovreste necessariamente spostarvi in ​​hardware reale.

    Eccezioni che non volete che le cose come i tuoi 2 controller di dominio nella stessa casella dovrebbero fallire l'hardware.

    Dubito che ci sia una risposta generica per questo, ma se sei preoccupato per la performance, allora è quello che devi guardare. L'ovvio sarebbe controllare se stai maxing out CPU, I / O, …

    Ma anche i test di performance e i parametri di riferimento aiuterebbero anche a decidere se vi sia alcuna penalità per essere virtuale e se avere un solo VM sull'host sia sensato o less.

    Dapprima devi identificare quale risorsa è il collo di bottiglia.

    Il monitor di performance di Windows ( perfmon ) fornisce numerosi contatori per vari aspetti come la coda di disco, le statistiche di memory virtuale ecc.

    Se sei legato al disco, dando alla macchina virtuale l'accesso diretto a un disco invece di qualcosa di simile a un file vmx con VMWare, potrebbe aiutare molto.

    Penso che tutto dipenda da due fattori:

  • Condivisione di risorse: l'ospite consuma tante risorse che influenzano le performance dell'altro
  • Sicurezza: se si tratta di un servizio molto critico, probabilmente non dovresti utilizzare la virtualizzazione in quanto si aggiunge livelli tra il software e l'hardware less si potrebbe essere sicuri.
  • solo i miei 2ct.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.