Configurazione degli Host

Una volta completata l’installazione del vCenter Server, possiamo accedervi utilizzando il vSphere Client, ed iniziare la configurazione del cluster. Come prima cosa dobbiamo creare un oggetto datacenter. Per fare questo possiamo cliccare l’hyperlink Create New Datacenter nella Getting Started tab. Il nuovo oggetto comparirà nella Inventory List sulla sinistra della schermata.

Per poter utilizzare il vCenter Server per configurare gli host, è necessario prima aggiungerli al vCenter Server. Il processo di aggiunta degli host automaticamente installa un agent sui server ESXi attraverso il quale il vCenter Server comunica e amministra gli host.

Il nostro datacenter utilizza 3 host :

- un PC DELL con 14 GByte di Ram e 2 processori Intel Xeon quad-core da 2.33 GHz

____________________________________________

Configurazione Datacenter

49

- un PC con 12 GByte di Ram e processore Intel Core i7 quad-core

da 2.80 GHz

- un PC con 8 GByte di Ram e processore Intel Core i7 quad-core da 2.80 GHz

Clicchiamo con il tasto destro sull’oggetto Datacenter e selezioniamo la voce Add Host. Nel Wizard che si apre, ci viene richiesto di specificare l’indirizzo IP o il nome dell’host che si vuole inserire, insieme alle credenziali utente (tipicamente quelle dell’utente root) per consentire l’operazione.

Lo screen seguente mostra le informazioni di base dell’host ESXi, insieme alle VM al momento attive su quel server. Andando avanti ci viene data l’opportunità di inserire il codice di licenza del pacchetto vSphere, che abilita tutte le funzionalità del prodotto per un periodo illimitato. Purtroppo non disponiamo di un codice di licenza, per cui selezioniamo la voce Evaluation Mode e ci prepariamo a usufruire del trial per 60 giorni.

Una volta aggiunti tutti e tre gli host possiamo scegliere di amministrarli separatamente, come entità individuali, oppure raggrupparli insieme in un Cluster, che è un altro elemento chiave nell’inventario del vCenter Server e che quello che abbiamo scelto.

Una volta raggruppati in un Cluster, abbiamo la possibilità di abilitare alcune delle più utili feature di vSphere. vSphere High Availability (HA), vSphere Distributed Resource Scheduler (DRS) e vSphere Fault Tolerance (FT) lavorano solo in un cluster.

Di seguito presentiamo le caratteristiche di queste feature, passando inevitabilmente attraverso la presentazione di un’altra importante funzione, la vMotion.

50

3.4.1 VMotion

Più volte nel testo abbiamo fatto riferimento alla vMotion come una feature che mi consente di bilanciare manualmente l’utilizzazione delle risorse in un ambiente vSphere.

Ma cosa fa esattamente? vMotion fornisce l’abilità di eseguire delle migrazioni a caldo delle macchine da un host ESXi ad un altro senza l’interruzione del servizio. Le connessioni di rete non sono perdute e le applicazioni continuano a girare ininterrottamente (o quasi). In effetti, un utilizzatore remoto non è consapevole del fatto che la VM sia stata scambiata da due host ESXi.

Quando si migra una VM verso un nuovo host, si sta migrando la sua allocazione di risorse (CPU e memoria). Questo rende la vMotion un tool estremamente potente per bilanciare la distribuzione del carico di lavoro tra gli host ESXi ed eliminare gli hot spots all’interno del datacenter, ovvero gli host fortemente utilizzati.

Ma la vMotion offre anche altri benefici. Se un Host ESXi ha bisogno di essere spento per la manutenzione hardware o, per altri motivi, diventa inservibile, è possibile usare la vMotion per migrare tutte le VM attive su quell’host che, così, restano sempre disponibili verso gli utenti che ne hanno bisogno.

Nonostante ciò appaia alquanto magico, le fondamenta della vMotion sono relativamente chiare.

La vMotion lavora copiando le pagine di memoria attive di una VM da un host ESXi all’altro e poi trasferisce il controllo del virtual disk (condiviso) della VM all’host di destinazione.

Guardando le cose più in dettaglio, ecco gli step attraverso cui agisce la live migration:

____________________________________________

Configurazione Datacenter

51 1 Un amministratore decide di spostare una VM attiva (VM1) da un host ESXi (pod-1-blade-5) verso un altro (pod-1-blade-7) come mostrato in figura xx.

2. L’host sorgente (pod-1-blade-5) comincia a copiare le pagine attive di memoria verso l’host di destinazione (pod-1-blade-7) attraverso un’interfaccia VMkernel abilitata per la vMotion. Questa è la cosiddetta fase di pre-copy. Durante questo tempo, la VM continua a servire i clienti dall’host sorgente. Alcune pagine di memoria, dopo essere già state trasferite, potrebbero cambiare nuovamente. Per questo motivo l’host mantiene un file di log per gli accessi che sono effettuati alle pagine di memoria già trasferite. Questo file di log si chiama memory bitmap, che non include il contenuto delle porzioni di memoria mutate, ma solo gli indirizzi di memoria delle pagine sporcate (spesso note come dirty pages). Il trasferimento delle pagine di memoria avviene attraverso processo iterativo e, ad ogni passo, vengono rinviate le pagine del passo precedente che vengono sporcate.

3. Dopo che l'intero contenuto della RAM è stato trasferito verso l'host di destinazione (pod-1-blade-7), la VM1 sull’host di partenza (pod-1-blade-5) viene disattivata. Ciò significa che è ancora in memoria, ma non gestisce più le richieste del client.

Il file bitmap di memoria viene quindi trasferito alla destinazione (pod-1- lama-7).

4. L’host di destinazione (pod-1-blade-7) legge gli indirizzi di memoria nel bitmap file e ne richiede il contenuto all’host sorgente (pod-1-blade-5). 5. Dopo che il contenuto della memoria agli indirizzi specificati nel bitmap file viene trasferito, la VM riparte sul nuovo host (non si tratta di un reboot). Lo stato della VM è specificato nella RAM, per cui l’host semplicemente lo

52

abilita. A questo punto un messaggio di Reverse Address Resolution Protocol (RARP) viene mandato dall’host per notificare la presenza della VM (con il suo MAC address) sulla porta dello switch fisico a cui l’host ESXi è connesso. In questo modo l’infrastruttura di rete è in grado di indirizzare correttamente i pacchetti inviati alla VM senza che nessuna connessione venga persa.

6. Nel frattempo la VM sull’host sorgente, con la sua allocazione di risorse, viene cancellata.

____________________________________________

Configurazione Datacenter

53

Figura 3.7 Trasferimento delle pagine attive

54

Figura 3.9 Trasferimento dirty pages

____________________________________________

Configurazione Datacenter

55 3.4.2 vSphere Distributed Resource Scheduler

vMotion, come detto, è un’operazione manuale, il che significa che è l’amministratore a dover avviare il processo di migrazione. Ma vSphere ha un altro potente tool per avviare automaticamente la migrazione di VM, il Distributed Resource Scheduler (DRS).

Il processo DRS semplicemente utilizza la vMotion per distribuire automaticamente l’utilizzazione delle risorse tra i server ESXi che sono configurati in un cluster.

Un cluster ESXi è un’implicita aggregazione di CPU e memoria da parte di tutti gli host coinvolti.

Il DRS ha un duplice obiettivo:

- all’avvio, il DRS cerca di piazzare ogni VM sull’host che è meglio fornito per poter far girare la VM in quel momento

- mentre la VM sta girando, il DRS cerca sempre di fornire alla VM le risorse specificate nella sua configurazione hardware minimizzando il numero di contese per quelle risorse

La prima funzionalità del DRS è anche nota come piazzamento intelligente. Ma il DRS non si limita ad amministrare le VM al loro avvio, ma continua a monitorarle durante il loro funzionamento. Ad esempio, consideriamo il caso di utilizzare un cluster di tre host (come il nostro datacenter). Quando uno di questi comincia a sperimentare un’alta contesa di cicli di CPU o memoria, il DRS capisce che l’allocazione di risorse nel cluster è sbilanciata e usa un algoritmo interno per determinare quale o quali VM deve essere spostata in modo da creare il cluster meno sbilanciato. Per ogni VM, il DRS simula una migrazione su ogni host e confronta i risultati. La migrazione che crea il miglior bilanciamento è quella che viene effettuata.

56

3.4.3 vSphere High Availability

In molti casi, la grande affidabilità, o la mancanza di grande affidabilità, è un argomento chiave contro la virtualizzazione. L’attacco più comune mosso contro la virtualizzazione suona più o meno così: “Prima della virtualizzazione se un server fisico si piantava, ne risentiva solo un’applicazione o un lavoro. Dopo la virtualizzazione, il blocco di un server fisico si ripercuote su tutte le applicazioni o i lavori che girano, nello stesso tempo, su quella piattaforma”.

VMware affronta e supera questo problema attraverso la vSphere High Availability. Attraverso questa feature viene automatizzato il processo di restart delle VM che girava sull’host ESXi al momento del blocco. La figura mostra la migrazione delle VM quando un server sperimenta un blocco fatale.

La HA, diversamente da DRS, non utilizza la vMotion, poiché quest’ultima è applicabile solo per migrazioni pianificate, e presuppone che entrambi gli host siano correttamente funzionanti. Il meccanismo di HA entra in gioco quando non c’è preavviso al blocco di un server e consente di limitare il downtime per le VM che operavano su quell’host.

Di default, la vSphere HA non rappresenta un meccanismo di failover per il blocco del sistema operativo guest di una VM, sebbene sia possibile monitorare la VM e riavviarla automaticamente se non risponde a dei messaggi interni di heartbeat. Questa funzione è detta VM Failure Monitoring.

Quando si parla di HA, è importante capire che ci sarà un’interruzione del servizio. Se un host fisico si blocca, vSphere HA riavvia le VM e durante il periodo di riavvio il servizio offerto dalle VMK non è fruibile. Per utenti

____________________________________________

Configurazione Datacenter

57 che necessitano di un più alto livello di affidabilità si utilizza la vSphere Fault Tolerance.

Figura 3.11 vSphere HA

3.4.4 vSphere Fault Tolerance

Come descritto nella sezione precedente, la vSphere HA offre un meccanismo di riavvio automatico delle VM, quando un server sperimenta un guasto improvviso. Questo ovviamente implica un certo downtime del servizio (generalmente meno di tre minuti).

La feature di vSphere Fault Tolerance (FT) mi consente di superare questo inconveniente, anche nel caso di guasto improvviso del server. Usando la tecnologia vLockstep basata su un processo di ‘record and replay’, FT mantiene una VM secondaria su un host fisico diverso che va di pari passo con la VM primaria.

Ogni cosa che capita sulla VM primaria (protetta), avviene simultaneamente sulla secondaria (mirrored), per cui se l’host su cui gira la VM primaria

58

dovesse bloccarsi, la secondaria ne prende immediatamente il posto senza perdita di connettività. vSphere FT, a questo punto, avvia automaticamente la creazione di una nuova VM secondaria per offrire nuovamente ridondanza.

Figura 3.12 vSphere FT