A seconda della potenza delle apparecchiature di cui disponiamo e delle risorse necessarie per i nostri sistemi, avremo un rapporto medio di macchine virtuali per server.
Prendiamo ad esempio la manutenzione programmata di un server nel Computer Center. Alcuni anni fa se questo non facesse parte di un cluster, il sistema contenuto nelle apparecchiature sarebbe stato portato offline, di conseguenza anche gli utenti sarebbero stati colpiti e/o il personale coinvolto nella manutenzione avrebbe dovuto lavorare in finestre temporali ridotte (per non dire scomodo).
Nel caso di un ambiente virtualizzato, le macchine virtuali possono essere semplicemente "spostate o migrate" su un altro membro di un cluster e l'apparecchiatura può essere spenta per lavorare su di essa. Problema risolto.
Cominciamo a vedere situazioni in cui la mancanza di servizio non è programmata.
Monitoraggio di macchine virtuali e applicazioni
Ogni volta che creiamo una macchina virtuale si consiglia di installare un compendio di applicazioni e driver che ottimizzino il comportamento dell'hardware virtuale nella sua interezza (disponibile per Windows, Mac OS, Linux e altri OS). Questi strumenti, chiamati VMTools, includono tra l'altro la possibilità per l'host di monitorare la macchina virtuale (tramite heartbeat, come nei cluster). Se non risponde entro un certo periodo, riavvia il sistema operativo.
Un caso simile si verifica con il monitoraggio delle applicazioni, ma prima è necessario ottenere l'SDK appropriato (o utilizzare un'applicazione che supporti VMware Application Monitoring).
Ma… cosa succede se la colpa è hardware?
Il cluster di cui sopra è il primo livello della soluzione.
Memoria condivisaDove tutti i membri del cluster hanno accesso alle macchine virtuali.
Collaborazione in reteDi fronte al guasto di una scheda, le restanti continuano a gestire il traffico.
Percorsi multipli (multipercorso)Per l'archiviazione non solo ottimizzeranno l'accesso, ma forniranno anche ridondanza.
In generale, queste tre tecnologie mitigano il tempo in cui le nostre informazioni sono inaccessibili. Ora, a seconda della licenza che abbiamo, possiamo anche avere due caratteristiche molto interessanti: High Availability (HA) e Fault Tolerance (FT).
In entrambi i casi è richiesto un cluster con storage condiviso. Senza la necessità di installare software aggiuntivo, HA può essere abilitato e configurato in modo tale che se un server o una macchina virtuale si guasta nel cluster, si avvierà automaticamente su un altro membro del cluster. Vale la pena chiarire che l'HA non è destinato alle VM mission-critical (macchine virtuali). Quindi il tempo stimato senza servizio sarà: "Avvio del sistema operativo + Avvio dei servizi".
Numero di errori host supportati dal cluster
Abbiamo X quantità di macchine virtuali distribuite in Y server in un cluster.
Quanti host possono guastarsi senza compromettere la disponibilità e le prestazioni del nostro ambiente virtuale?
HA può essere configurato per supportare un numero specifico di errori del server, assicurando che ci siano risorse sufficienti rimanenti per il ripristino.
L'HA affetta le risorse disponibili di un cluster tenendo conto della CPU e della RAM configurate e consumate dalle nostre macchine virtuali in modo molto conservativo. Prende la prenotazione della CPU configurata più grande di qualsiasi macchina virtuale su ogni host nel cluster e quindi la prenotazione della memoria più grande e il suo eccesso. Se non è stata configurata alcuna prenotazione, saranno necessari un minimo di 32 Mhz per VM per CPU e 0 Mb di RAM + il suo eccesso.
Con questi numeri si presume che ogni macchina virtuale utilizzata consumerà quella CPU e memoria, quindi genera un valore chiamato dimensione dello slot. Con questo valore si determina quanti slot sono disponibili/utilizzati da ciascun host.
Il problema sorge quando, ad esempio, abbiamo una singola macchina con una grande CPU e riserva di memoria. Prendendo le prenotazioni configurate, è molto probabile che il resto delle nostre macchine virtuali non abbia realmente bisogno di quelle risorse, con conseguente minor numero di slot per il nostro cluster.
Percentuale di risorse del cluster come capacità di fallire
A differenza dell'opzione precedente, questa funziona molto bene quando si hanno macchine virtuali con configurazioni di CPU e memoria altamente variabili.
È possibile configurare separatamente i valori percentuali di CPU e memoria, risultando in questo modo ancora più flessibili e risparmiando di conseguenza risorse. Questo è generalmente il metodo preferito per la configurazione dell'HA.
Host per il failover
Questa è la tipica configurazione del cluster di standby. Questa opzione viene fornita principalmente poiché alcune organizzazioni mantengono criteri che indicano che devono essere presenti server in standby in caso di emergenza. Poiché VMware esegue una buona gestione della tolleranza agli errori, forse questa sarebbe l'opzione quando le risorse sono abbondanti… ma sicuramente non la migliore.
vMovimento: Migrazioni in tempo reale
La migrazione in tempo reale consente di spostare macchine virtuali funzionanti da un server fisico a un altro mantenendo la connessione e l'identità di rete. La memoria attiva (processi in esecuzione) viene trasferita sulla rete ad alta velocità. L'intero processo richiede meno di 5 secondi su una rete gigabit.
È possibile spostare la VM, i file che utilizza, o entrambi, e la procedura può essere eseguita a macchina accesa o spenta. In quest'ultimo caso, la chiamiamo "migrazione a freddo" e se la macchina è in esecuzione la chiamiamo vMotion.
Usi e vantaggi di vMotion
- Riorganizzazione della macchina virtuale, ottimizzando così le risorse. Rimuoverli dai server soggetti a guasti o saturati.
- Ottimizzazione automatica delle risorse disponibili (Lavoro in collaborazione con Dynamic Resource Scheduler o DRS).
- Fare manutenzione dell'infrastruttura sottostante nessuna necessità di pianificazione della manutenzione o interruzione dell'attività.
Ogni componente dell'integrità della macchina virtuale viene gestito in modo diverso durante la migrazione. La configurazione generale è la più semplice, non si sposta ma viene ricreata sul computer di destinazione.
Poiché il disco non può essere ricreato in così poco tempo, è necessario disporre di uno spazio di archiviazione condiviso. Lo stato corrente della memoria viene gradualmente copiato sull'host di destinazione, al termine della copia vengono confrontate le differenze esistenti emerse durante la migrazione, viene bloccato lo stato della VM di origine e viene attivato il sistema operativo sulla VM di destinazione .
Perché in alcuni casi l'opzione per riavviare la macchina non è l'ideale, per mission critical abbiamo la Tolleranza ai guasti. Ciò che si desidera in questi casi non smette di funzionare in nessun momento, anche se il suo host fallisce. L'unico modo in cui ciò sia possibile è se la VM fosse in esecuzione in due posti contemporaneamente. È configurato a livello di macchina virtuale e genererà una copia esatta della VM, mantenendola sempre replicata al 100% su un altro server, quindi in caso di guasto hardware, il suo gemello continuerà semplicemente a funzionare senza alcuna perdita di informazioni. Interessante, vero?
Se si trattasse solo di risorse, abiliteremmo FT in tutte le macchine virtuali del nostro data center, ma nelle versioni precedenti di vSphere abbiamo riscontrato alcune limitazioni, la più importante: Non era possibile abilitare FT in macchine che utilizzavano più di una virtual processore. Fortunatamente, nell'ultima versione del prodotto, supporta fino a 4 processori virtuali contemporaneamente per macchina protetta, tuttavia sarà necessario considerare la licenza:
Il numero di vCPU supportate da una VM abilitata per FT è limitato dal livello di licenza acquistata per vSphere.
La tolleranza agli errori è supportata come segue:
- vSphere Standard ed Enterprise. Consente fino a 2 vCPU.
- vSphere Enterprise Plus. Consente fino a 4 vCPU.
Questo non è l'unico requisito del sistema.
ConservazioneLe macchine virtuali devono disporre di spazio di archiviazione condiviso. Non è possibile utilizzare RDM fisico (Raw Devide Mapping).
ReteÈ necessario disporre di almeno due schede virtuali (vmnics), una per vMotion e l'altra (10 gbps) per FT Logging. È un nuovo requisito della versione 6 (in precedenza erano necessarie piastre da 1 gbps)
ProcessoreProcessori e sistemi operativi devono essere compatibili con FT (e tra loro).
Limitazioni
- Non è possibile acquisire istantanee delle VM protette con FT e devono essere eliminate prima di abilitare questa funzione.
- Dischi virtuali (VMDK) maggiori di 2 Tb.
- Nella documentazione di VMware è presente un elenco di dispositivi e funzionalità specifici.
E c'è anche una limitazione al numero di VM per server: un massimo di 4 macchine protette per host o 8 vCPU protette (a seconda del limite che si verifica per primo). Questi valori massimi includono la macchina primaria e secondaria (e vCPU)
Differenze tra legacy FT (precedente) e attuale
IPv6
Legacy FT = Non supportato dalle schede di rete configurate per la registrazione FT FT = Supportato
API VStorage - Backup con protezione dei dati
Legacy FT = Non supportato FT = Supportato
Disco virtuale
Legacy FT = EZT (Eager Zeroed Thick) FT = Tutti i tipi, inclusi thick e thin
Ridondanza Vmdk (disco virtuale)
Legacy FT = Copia singola FT = Le macchine Primaria e Secondaria mantengono copie indipendenti, questo consente loro di essere archiviate in diversi datastore e aumentare la ridondanza
Larghezza di banda della piastra di rete
Legacy FT = NIC dedicata da 1 Gb consigliata FT = NIC dedicata da 10 Gb consigliata
Compatibilità CPU e host
Legacy FT = Richiede lo stesso modello di CPU e la stessa famiglia. Versioni di vSphere quasi identiche FT = Le CPU devono essere compatibili con vSphere vMotion o EVC. La versione di VSphere deve essere compatibile con vSphere vMotion
Attiva / Disattiva FT con la macchina in funzione
Legacy FT = Non sempre supportato FT = Supportato
Ricorda che FT protegge dai guasti dell'hardware del server, non dai guasti dei sistemi operativi o delle applicazioni.
Watchdog del server vCenter è una funzionalità incorporata della versione 6.x. Controlla periodicamente lo stato dei servizi che compongono vCenter, riavvia i processi di amministrazione o la VM se necessario.
