Quando si distribuisce un singolo server su un nuovo hardware, lo virtualizzi o no?

Ci sono alcune domande che ho trovato su ServerFault che suggeriscono questo argomento e, sebbene possa essere in qualche modo basato sull'opinione, penso che possa rientrare in quella categoria "buona soggettiva" basata su quanto segue:

Domande soggettive costruttive:

* tend to have long, not short, answers
* have a constructive, fair, and impartial tone
* invite sharing experiences over opinions
* insist that opinion be backed up with facts and references
* are more than just mindless social fun

In modo che fuori dai piedi.

Sto aiutando un altro amministratore di sistema che sta sostituendo un vecchio server fisico con Windows 2003 e sta cercando non solo di sostituire l'hardware ma di "aggiornarlo" a 2012 R2 nel processo.

Nelle nostre discussioni sul suo hardware sostitutivo, abbiamo discusso della possibilità che lui installi ESXi e quindi trasformi il "server" 2012 in una VM e migri le vecchie app / file / ruoli dal server 2003 alla VM invece che a un'installazione non VM sul nuovo hardware.

Nei prossimi anni non avverte la necessità di spostare nient'altro in una VM o creare VM aggiuntive, quindi alla fine si tratterà di nuovo hardware che esegue una normale installazione o nuovo hardware che esegue una singola VM su ESXi.

La mia esperienza si spingerebbe ancora verso una VM, non esiste un motivo davvero convincente per farlo oltre alle possibilità che possono sorgere per creare VM aggiuntive. Ma ora c'è l'ulteriore aspetto di gestione e overhead dell'hypervisor, anche se ho sperimentato migliori capacità di gestione e capacità di reporting con una VM.

Quindi, con la premessa di sperare che questo possa rimanere nella categoria "buon soggettivo" per aiutare gli altri in futuro, quali esperienze / fatti / riferimenti / risposte costruttive devi aiutare a supportare entrambi i risultati (virtualizzando o non un singolo "server") ?

Nel caso generale, il vantaggio di mettere un server autonomo su un hypervisor è a prova di futuro. Rende le espansioni o gli aggiornamenti futuri molto più facili, molto più veloci e, di conseguenza, più economici. Lo svantaggio principale è la complessità e i costi aggiuntivi (non necessariamente finanziari, ma dal punto di vista delle ore-uomo e del tempo).

Quindi, per prendere una decisione, mi pongo tre domande (e di solito preferisco mettere il server su un hypervisor, per quello che vale).

1. Quanto costa il costo aggiuntivo dell'hypervisor?
   • Dal punto di vista finanziario, di solito è minimo o inesistente.
     • Sia VMware che Microsoft dispongono di opzioni di licenza che consentono di eseguire gratuitamente un host e un singolo guest, e questo è sufficiente per la maggior parte dei server autonomi, eccezioni essendo generalmente server ad alta intensità di risorse.
   • Dal punto di vista della gestione e delle risorse, determinare i costi può essere un po 'più complicato.
     • In pratica, raddoppi il costo di manutenzione del sistema, perché ora hai due sistemi per monitorare, gestire e tenerti aggiornato con patch e aggiornamenti (il SO guest e il SO host).
       • Per la maggior parte degli usi, questo non è un grosso problema, poiché non è terribilmente tassativo mantenere un server, anche se per alcune organizzazioni particolarmente piccole o particolarmente tecnicamente sfidate, questo può essere un vero problema.
     • Si aggiunge anche alle competenze tecniche richieste. Ora, invece di avere semplicemente bisogno di qualcuno che possa scaricare gli aggiornamenti da Windows Update, hai bisogno di qualcuno che ne sappia abbastanza per gestire e mantenere l'ambiente di virtualizzazione.
       • Ancora una volta, di solito non è un problema, ma a volte è più di quanto un'organizzazione possa gestire.
         
         
2. Quanto è grande il vantaggio derivante dalla facilità di aggiornamento o espansione?
   • Questo si riduce alla probabile espansione futura, perché ovviamente, se non espandono o aggiornano le risorse del server, questo vantaggio è zero.
     • Se questo è il tipo di organizzazione che sta per riempire il server in un angolo e dimenticarsene per 10 anni fino a quando non deve essere sostituito comunque, non ha senso.
     • Se è probabile che crescano a livello organizzativo o anche solo tecnicamente (ad esempio aggiungendo nuovi server con ruoli diversi, invece di avere un server all-in-one), questo offre un vantaggio abbastanza sostanziale.
       
       
3. Qual è il vantaggio ora ?
   • La virtualizzazione porta vantaggi oltre a quelli a prova di futuro e, in alcuni casi d'uso, può essere sostanziale.
     • La più ovvia è la possibilità di creare snapshot e backup banali da ripristinare prima di fare qualcosa sul sistema, quindi se va male, puoi tornare indietro con un clic.
     • La possibilità di sperimentare con altre macchine virtuali (e giocare al gioco "what if") è un'altra che ho visto entusiasmare il management. Per i miei soldi, tuttavia, il più grande vantaggio è la portabilità aggiuntiva che si ottiene eseguendo un server di produzione su un hypervisor. Se qualcosa va davvero storto e ti trovi in ​​una situazione di disaster recovery o ripristino da backup, è quasi infinitamente più semplice ripristinare un'immagine del disco su una macchina che esegue lo stesso hypervisor piuttosto che provare a eseguire un ripristino bare metal.

Penso che il sistema operativo in fase di virtualizzazione sia un grande fattore, insieme ai requisiti di prestazioni e al potenziale di espansione / crescita. I server di oggi sono spesso eccessivamente potenti per le applicazioni e i sistemi operativi che utilizziamo. Nella mia esperienza, la maggior parte dei sistemi Windows standard non è in grado di utilizzare in modo efficiente le risorse disponibili in un moderno server a doppio socket . Con Linux, ho sfruttato alcuni degli strumenti granulari di gestione delle risorse ( cgroups ) e container ( LXC ) per utilizzare meglio i sistemi fisici. Ma il mercato è decisamente orientato verso l'hardware ottimizzato per la virtualizzazione.

Detto questo, ho virtualizzato i sistemi singoli anziché le installazioni bare metal in alcune situazioni. Le ragioni comuni sono:

• Licenze - Il numero in diminuzione di applicazioni che concedono in licenza sulla base di limiti rigidi di core, socket o memoria (indipendentemente dalle tendenze dell'informatica moderna ). Vedi: Disabilitare i core della CPU nel BIOS?

• Portabilità : la virtualizzazione di un server estrae la VM dall'hardware. Ciò rende le modifiche della piattaforma meno dirompenti e consente alla VM di fare riferimento a dispositivi / componenti virtualizzati standard. Con questo approccio sono stato in grado di mantenere i sistemi Windows 2000 decrepiti ( ma critici ) sul supporto vitale.

• Espansione futura : ora ho un client con un controller di dominio Windows 2003 in esecuzione su hardware dell'era 2001. Sto costruendo un nuovo sistema ESXi a host singolo per loro che ospiterà un nuovo controller di dominio 2012 R2 per il momento. Ma seguiranno più VM. In questa configurazione, posso offrire un'espansione affidabile delle risorse senza costi hardware aggiuntivi.

L'aspetto negativo di farlo con un singolo host / singola macchina virtuale è la gestione. Vengo dal punto di vista di VMware, ma in passato ESXi era un po 'più amichevole con questa soluzione. Oggi, il requisito di vSphere Web Client e l'accesso limitato alle funzioni di base rendono meno attraente l' esecuzione di una soluzione a host singolo ( e VM singola ).

Altre considerazioni sono il monitoraggio hardware paralizzato e una maggiore complessità delle periferiche esterne comuni (dispositivi USB / unità nastro / backup / soluzioni UPS ). Gli hypervisor di oggi vogliono davvero far parte di una suite di gestione più ampia.

Ci sono alcuni vantaggi nella virtualizzazione di un singolo server. Le prime cose che mi vengono in mente sono

• Crea istantanee
• Importa / Esporta VM (ad esempio, esporta la VM come .OVF in modo che gli sviluppatori possano caricarla su Workstation o Player per avere una copia esatta di un server)
• Clona o trasforma facilmente in un modello (per quando decidi che le VM sono piuttosto carine)
• Prontamente disponibile per aggiungere ulteriori VM in futuro

Penso che il più importante di questi sarebbero le capacità di istantanea. Usiamo VMWare ovunque nella nostra azienda, quindi per noi avrebbe senso avere il server "pronto" per quando è necessario un numero maggiore di VM.

Questa non è una risposta lunga, ma comunque:

Il motivo più convincente per utilizzare un hypervisor per un singolo server, in particolare con qualcosa come Windows Server, è che hai l'astrazione totale dell'hardware per il sistema operativo di produzione e puoi spostarlo su hardware completamente nuovo del server senza alcun problema, in caso di necessità. Considero questa una caratteristica davvero preziosa che supera di gran lunga gli svantaggi di avere un hypervisor pratico non necessario in esecuzione in background.

Non fornirò una risposta così dettagliata qui come altri, quindi dirò solo che sto trovando sempre più difficile in questi giorni giustificare l'installazione del sistema operativo del server su bare metal anziché installare un hypervisor (del tuo scelta) e virtualizzare i carichi di lavoro. I vantaggi di farlo, secondo me, sono:

1. Costi-benefici. A lungo termine, se devo distribuire carichi di lavoro aggiuntivi, non devo sborsare altro hardware per quei carichi di lavoro aggiuntivi. In alcuni casi, quando utilizzo Hyper-V, posso anche risparmiare sui miei costi di licenza.

2. Facilità di implementazione e ridistribuzione.

3. Facilità di implementazione di alta disponibilità e failover.

4. Portabilità. Posso probabilmente spostare la VM praticamente ovunque, se devo smantellare o esternalizzare l'host corrente.

5. Prove future. Il tuo collega amministratore di sistema potrebbe attualmente non vedere alcuna necessità futura di un'infrastruttura basata su hypervisor, ma la mia ipotesi è che entro 12-24 mesi lo farà e sarà contento di aver scelto di percorrere la strada della virtualizzazione, se in effetti sceglie quella rotta .

6. Ripristino di emergenza. Posso eseguire il backup di un'intera VM e ripristinarla o replicarla su un altro host in pochi minuti.

E così via e così via ...

Ecco alcuni motivi per cui direi che una VM è migliore:

• "KVM over IP" incorporato (tipo di): puoi accedere al tuo server da remoto sulla console senza bisogno di KVM over IP. A volte non vuoi fare qualcosa su RDP e hai bisogno dell'accesso alla console. Con una VM, accendi lo strumento di gestione preferito (XenCenter, vSphere Client, ecc.) E sei sulla console della tua VM.

• Con le VM (e per i server non VM, con il mio KVM su IP) non devo più rimanere nella mia stanza del server freddo per ore.

• Migrazione a nuovo hardware - A parte l'aggiornamento del sistema operativo, per inserire il tuo nuovo hardware devi migrare il sistema, spostare le cose, ecc. Con una macchina virtuale, di solito non devi fare nulla. Si aggiorna l'hardware, si inseriscono i file VM sul nuovo hardware e si avvia.

• Sebbene non si preveda una macchina virtuale futura, " se la si costruisce, arriveranno ". Ti consigliamo di creare una nuova macchina virtuale per testare qualcosa e provare nuove cose, ecc. Esistono molte più possibilità.

• Le macchine virtuali ti danno la possibilità di ripristinare con un'istantanea, prenderne una copia, creare un clone della macchina virtuale (in fase di esecuzione) e quindi accenderlo, sia per testare qualcosa prima di metterlo in funzione, sia per avere solo un secondo primo. Ci sono molte cose che puoi fare con le istantanee delle VM e simili.

• Ridondanza: se si inserisce un secondo server VM, è possibile disporre di hardware ridondante e sebbene non conosca gli attuali schemi di licenza VMWare, XenServer ora ha apparentemente XenMotion parte del pacchetto gratuito, quindi il sovraccarico di costi potrebbe non essere applicabile.

I motivi per cui non vorrei usare una VM:

• Sovraccarico - difficilmente ma ovviamente c'è un certo sovraccarico.

• Più complesso da gestire - un po 'più complesso ma è facile da imparare. Se non stai cercando un ambiente virtualizzato di grandi dimensioni, la formazione è banale.

Arrivo tardi e sento che le persone hanno già espresso alcuni dei punti che avrei voluto fare, ma ricapitolerò brevemente:

• A prova di futuro: è più facile aggiungere più RAM / CPU / disco / ecc. quando sorge la necessità.
• Portabilità: passaggio più semplice al nuovo hardware, soprattutto in caso di disastro.
• Virtualizzare è meglio che tenere in giro un vecchio hardware orribile per eseguire qualcosa di cui non è possibile liberarsi.
• Il software di gestione è spesso bello come KVM o DRAC. (Inoltre, se ti capita di ereditare qualcosa da cui l'amministratore precedente è partito senza lasciare la password, puoi usarli come "accesso fisico" per entrare. Utile come i tronchesi che ho nella mia auto per lo stesso motivo - precedente admin in un lavoro ha usato i lucchetti sull'hardware. Ho ereditato i server ma non la chiave.)
• Snapshot e fare copie in modo da poter testare le procedure rischiose prima di distribuirle.

Tuttavia, la cosa che nessuno ha ancora menzionato e probabilmente dovrebbe essere menzionata: se sei nel tipo di negozio in cui le persone potrebbero aver bisogno di un server di prova e probabilmente risolverai tale necessità afferrando un desktop di riserva e schiaffeggiando un sistema operativo del server su di esso, essere in grado di offrire loro una macchina virtuale probabilmente si adatta molto meglio alle vostre e alle loro esigenze. La virtualizzazione del nuovo server può essere la "ragione" per consentire future espansioni virtuali. (E, francamente, se non sei in quel tipo di negozio, probabilmente hai già la virtualizzazione.)

Certo, non tutto si virtualizza. Ho assegnato un punteggio all'hardware fisico per il software di gestione che includeva PXE descrivendo loro cosa avrebbero dovuto fare per disattivare Offloading del segmento TCP ( PXE correva come un cane con una gamba sola con TSO acceso , ma avrebbero dovuto spegnerlo per l'intera VLAN virtuale, e non erano inclini a farlo). Quindi, se il nuovo server è qualcosa di abbastanza specializzato da essere inadatto, beh, non importa.

Ma escludendo quel tipo di specializzazione, varrebbe la pena per me sbarazzarmi di un gruppo di macchine (potenzialmente non gestite) di classe PC che eseguono sistemi operativi server in giro, ora o in futuro.

Assolutamente, virtualizzo ogni volta che posso. Questo mi permette di prepararmi a fare quanto segue in futuro:

• Backup di sistema completi che sono molto più facili da eseguire e spesso anche più economici.
• Il sistema operativo può essere portatile, posso spostare la VM su un altro host se necessario, con o senza downtime e clustering, non importa a questo punto
• Le licenze di Windows possono diventare più economiche a determinate condizioni
• Quando ho poco hardware, posso usare i sistemi di produzione per testare gli aggiornamenti (non le migliori pratiche, ma il budget, il budget ...), dopo aver scattato un'istantanea. Non è possibile farlo su un host normale, a meno che non si stia avviando da una SAN costosa
• Con l'hardware del server finale più basso possibile, ottengo ancora più risorse di quelle di cui potrei aver bisogno per un ruolo server specifico. Potrebbe anche ottenere hardware migliore e utilizzarlo tutto con le macchine virtuali.
• Le funzionalità di virtualizzazione possono spesso sostituire software non necessari. Ad esempio, ho usato per creare doppietti e non ho mai fallito molto, per impostare repliche DR di server Windows. Con la virtualizzazione, posso farlo a livello di hypervisor, utilizzando tecnologie molto più economiche e eseguendo soluzioni più affidabili e flessibili.

In breve, a meno che il server non stia eseguendo un software specifico che presenta limitazioni, vietandone la virtualizzazione (in genere reqs di latenza IO della rete o del disco rigidi e con l'hardware giusto, anche quelli realizzabili con la virtualizzazione) cerco di mantenere le cose il più virtuale possibile.

Un motivo a cui riesco a pensare a favore della virtualizzazione di un singolo server in una VM su un singolo host è la capacità che ti dà di fare casino con un ambiente di test per quel "server".

Se l'hardware è più che capace, è possibile clonare la VM del server e rimuovere le sue capacità NIC / rete e isolare quel clone come "piattaforma di test" con cui fare confusione prima di provare lo stesso sul server "di produzione". Un esempio potrebbe essere se il server esegue un software ERP e si desidera verificare cosa succederebbe se si eseguisse uno script specifico sul software / database ERP. Potresti farlo prima sulla macchina virtuale clonata come test. Ciò potrebbe quindi essere eseguito in combinazione con un'istantanea della VM attiva prima della distribuzione su di essa, con l'ulteriore vantaggio di sapere che dovrebbe funzionare correttamente.

La creazione dello stesso ambiente "test" clonato potrebbe essere eseguita con un P2V di un server fisico esistente, ma occorrerebbe quindi un host fisico aggiuntivo per posizionare la nuova macchina virtuale di test ... in quanto sopra, tutto può risiedere sullo stesso fisico hardware (che oggigiorno è quasi sempre eccessivo per una singola macchina virtuale)

Se il tuo caso d'uso non richiede il 100% della potenza dall'hardware dedicato, diventerei virtuale ogni volta. Offre flessibilità, funzionalità snapshot e accesso alla console integrato (anche se è necessario utilizzare anche la gestione fuori banda)

Un unico punto che è piuttosto tangenziale alla domanda principale:

Di recente ho avuto una VM il cui disco non era abbastanza grande. Stava eseguendo qualcosa che generava grandi quantità di dati in un database relazionale, che per motivi di prestazioni dovevano essere sullo stesso computer.

Dopo aver espanso l'immagine del disco due volte, sono arrivato sul palco dove non era rimasto spazio sufficiente sull'host per copiare ed espandere l'immagine in modo sicuro. Mi sarei risparmiato un paio di giorni di lavoro per farlo dall'inizio su una macchina dedicata, anche se fosse un PC economico, non un server ad alte prestazioni.

Con una macchina dedicata puoi semplicemente spegnerlo e aggiungere altri dischi. Se si tratta di un server che esegue altre macchine virtuali, a meno che non si disponga di alloggiamenti hot-swap di riserva, è possibile che si verifichi un arresto.