Sizing di un’infrastruttura server con VMware

Ho terminato la scrittura di un piccolo manuale in cui spiego come dimensionare un’infrastruttura di server/storage per passare da un ambiente fisico ad uno virtuale con VMware vSphere 4.1 (da poco è uscita la versione 5!). Dato che in Rete non ho trovato nessun documento per il dimensionamento della parte server (per la parte desktop invece ci sono alcune ottime guide) che sia leggibile e abbastanza immediato, me lo sono scritto da solo, in modo da poterlo usare come punto di riferimento :-). […]

Ho terminato la scrittura di un piccolo manuale in cui spiego come dimensionare un’infrastruttura di server/storage per passare da un ambiente fisico ad uno virtuale con VMware vSphere 4.1 (da poco è uscita la versione 5!).

matriosche

Dato che in Rete non ho trovato nessun documento per il dimensionamento della parte server (per la parte desktop invece  ci sono alcune ottime guide) che sia leggibile e abbastanza immediato, me lo sono scritto da solo, in modo da poterlo usare come punto di riferimento :-).  Anzi, in Rete ci sono tantissimi documenti che trattano l’argomento, e sono anche di gran lunga migliori del mio, ma spesso il loro problema è che sono troppo lunghi ed elaborati, risultando difficili da decifrare, con decine e decine di grafici, istogrammi, studi di performance, e 10000 tabelle. Di seguito riporto un estratto del manuale:

Vediamo una serie di best practices per progettare e dimensionare un’infrastruttura di server virtuali con VMware. I punti da tenere in considerazione durante la progettazione sono i seguenti (ordinati in base all’importanza):

  1. tipo di server (entry level, enterprise, …), al quale sono strettamente legati tutti i punti successivi, e l’espandibilità futura (scale-out e scale-up);
  2. RAM, l’elemento più critico che può limitare fortemente le VM e le loro performance all’interno dell’infrastruttura;
  3. CPU, in termini di numero di core, socket, e frequenza;
  4. storage, quantità dello spazio necessario e tecnologia usata;
  5. networking.

Il manuale è liberamente scaricabile dal link sottostante oppure dalla sezione Download, ed è la prima versione (spero presto di aggiornarlo con la nuova versione di vSphere 5, e di renderlo ancora più immediato da utilizzare ma anche completo di spiegazioni ed esempi).

DOWNLOAD del manuale (v1.1)

roghan

p.s.: se ti è piaciuto il mio manuale e reputi interessante il mio lavoro puoi offrirmi da bere… Grazie mille!!!
pulsante paypal

Cosa contiene il database di vCenter Server

In questo articolo verrà esaminato il database utilizzato da vCenter Server, per informare coloro che si chiedono quali dati memorizza o che non hanno mai controllato il suo contenuto ;-). Il database crea principalmente alcune tabelle per memorizzare dati relativi ad eventi, allarmi, informazioni su HA, DRS, sui nodi ESX/ESXi (statistiche, capacità dello storage, spazio libero, …), informazioni sulle VM e sui processi schedulati. […]

In questo articolo verrà esaminato il database utilizzato da vCenter Server, per informare coloro che si chiedono quali dati memorizza o che non hanno mai controllato il suo contenuto ;-). Il database crea principalmente alcune tabelle per memorizzare dati relativi ad eventi, allarmi, informazioni su HA, DRS, sui nodi ESX/ESXi (statistiche, capacità dello storage, spazio libero, …), informazioni sulle VM e sui processi schedulati.

what-is-database

Da notare che le configurazioni dei nodi e delle VM sono invece memorizzate sui singoli nodi, e sono solamente mostrate da vSphere Client al momento della connessione al vCenter Server. Infatti è possibile collegarsi direttamente ad uno dei nodi ESX/ESXi senza vCenter Center, e modificare le configurazioni. Al momento che un nodo viene aggiunto ad un datacenter, vengono lette tutte le informazioni dal nodo e aggiunte al database del vCenter Server. E’ importante ricordare che il database non è essenziale per il funzionamento dei nodi o delle VM, infatti continueranno a funzionare tranquillamente anche se vCenter Server o il suo database non dovessero essere più disponibili: non sarebbero più funzionanti DRS e vMotion, mentre HA continuerebbe a funzionare senza alcun problema. Qualora il database avesse un crash si potrebbe creare una sua nuova istanza, aggiungendo nuovamente gli ESX/ESXi al vCenter Server in modo da ripopolare le informazioni del database. In quest’ultimo caso gli unici dati persi sarebbero le varie statistiche, eventi, allarmi, resource pool, i processi schedulati, e poche altre informazioni non essenziali.

Per ulteriori informazioni consultare i seguenti link (è stato preso spunto dal primo link per questo articolo):

roghan

Cluster VMware vs cluster Microsoft

In questo post verranno trattati i vantaggi di implementare un cluster Microsoft e quelli invece di un cluster VMware vSphere. Un cluster Microsoft ha il vantaggio che sono monitorate le applicazioni all’interno del sistema operativo, ad esempio SQL Server: se l’applicazione su uno dei nodi del cluster ha un crash, subentra immediatamente l’istanza sull’altro nodo in modo da garantire continuità di servizio. Nel caso di VMware invece può essere configurato un cluster con la Fault Tolerance (FT), la funzionalità che meglio si avvicina a MSCS. […]

In questo post verranno trattati i vantaggi di implementare un cluster Microsoft e quelli invece di un cluster VMware vSphere.

cluster

Un cluster Microsoft ha il vantaggio che sono monitorate le applicazioni all’interno del sistema operativo, ad esempio SQL Server: se l’applicazione su uno dei nodi del cluster ha un crash, subentra immediatamente l’istanza sull’altro nodo in modo da garantire continuità di servizio. Nel caso di VMware invece può essere configurato un cluster con la Fault Tolerance (FT), la funzionalità che meglio si avvicina a MSCS. Con la FT attiva VMware garantisce la continuità di esecuzione di una VM, ma non delle singole applicazioni all’intero della VM:

  1. se il nodo che ospita la VM ha un malfunzionamento, una VM identica già attiva e avviata entrerà in funzione, garantendo zero disservizio;
  2. se il nodo che ospita la VM funziona correttamente ma ha un crash un’applicazione interna alla VM (un database, un server web, …), la FT non è in grado di effettuare alcun azione e il servizio non verrà più erogato.

Dunque nella scelta tra MSCS e VMware deve essere tenuto in considerazione il livello di protezione garantito, che è maggiore con MSCS ma con lo svantaggio di costi maggiori e di un maggior livello di complessità. Con MSCS infatti devono essere configurati singolarmente i nodi del cluster, così come devono essere configurati disco di quorum e RDM. In VMware invece la configurazione del cluster è molto più semplice ed intuitiva, e viene fatta interamente attraverso vCenter Server, il quale si occuperà sia di monitorare le VM sia di eseguire le azioni opportune in caso di crash. In definitiva, MSCS è da preferire per applicazioni mission-critical, come un database, in cui un disservizio anche minimo può causare notevoli problemi, mentre per altri tipi di servizi, come server DHCP, DNS, o anche server web, un cluster con VMware FT (o eventualmente HA se può essere tollerato un disservizio di alcuni minuti) offre una protezione più che adeguata.

L’alternativa è quella di ricorrere ad un cluster Microsoft direttamente all’interno di un cluster VMware, in modo da unire i benefici della virtualizzazione ad una continuità di servizio 24h/24 per le applicazioni più critiche. Inoltre, si ha un ulteriore vantaggio, che consiste nella possibilità di “spostare” un’applicazione da una VM ad un’altra senza alcun disservizio, ad esempio se si deve effettuare qualche operazione di manutenzione. E’ da notare però che in questo caso sono supportati cluster solo di alcune versioni di Windows. Per maggiori dettagli consultare i collegamenti seguenti:

roghan

E’ migliore ESXi embedded o installabile?

Premettendo che non ci sono differenze funzionali tra le due versioni, vediamo i vantaggi/svantaggi di entrambe:
ESXi embedded:
+ il sistema è già pronto per l’uso e non deve essere installato niente;
+ costi bassi (un flash drive USB costa meno di dischi in RAID);
– no ridondanza, al massimo può essere mantenuta una copia di backup del sistema su un altro drive USB;
– la qualità dei flash drive USB raramente è elevata;
– il sistema operativo risiede interamente su un dispositivo esterno USB (se qualcuno per ignoranza lo rimuove?!). […]

Premettendo che non ci sono differenze funzionali tra le due versioni, vediamo i vantaggi/svantaggi di entrambe:

ESXi embedded:
+  il sistema è già pronto per l’uso e non deve essere installato niente;
+  costi bassi (un flash drive USB costa meno di dischi in RAID);
–  no ridondanza, al massimo può essere mantenuta una copia di backup del sistema su un altro drive USB;
–  la qualità dei flash drive USB raramente è elevata;
–  il sistema operativo risiede interamente su un dispositivo esterno USB (se qualcuno per ignoranza lo rimuove?!).
esxi_embedded
ESXi installabile:
+  flessibilità nell’installazione e possibilità di personalizzazione;
+  alta disponibilità e ridondanza, i dischi su cui viene installato ESXi possono essere messi in RAID;
–  costi elevati.
Le due soluzioni sono invece sullo stesso livello per quanto riguarda le prestazioni così come per il tempo di deploy (ESXi embedded è già pronto all’uso, ma anche ESXi installabile richiede al massimo pochi minuti per essere installato e avviato).Personalmente preferisco la versione installabile :-), ma tuttavia anche la versione embedded funziona egregiamente.

roghan