Understanding VMware HA
Le meccaniche di ridondanza dei cluster
VMware vSphere (v5.x)
1
«Chi sono?» Rocco Sicilia, IT Manager e Virtualization Architect.
Attualmente sono responsabile del team di Design di
un System Integrator ed opero come analista
specializzato in infrastrutture di virtualizzazione ed
erogazione servizi IaaS e PaaS.
Ho conseguito diverse certificazioni per lo più in
ambito virtualizzazione e networking, recentemente
nominato vExpert da VMware.
Mi trovate su http://www.roccosicilia.it/
2
Parliamo di… • Cluster, HA e la virtualizzazione di VMware
• Funzionamento di un cluster VMware
• Il disegno di rete e l’impatto su VMware HA
• Comportamento in caso di fault di un host ESXi
• Admission Control: quando e come usarlo
• Aiutare HA: DRS
3
High Availability • Ha lo scopo di rendere il servizio disponibile anche
in caso di fault degli host
• Il servizio in disponibilità è la Virtual Machine o HA non protegge direttamente le applicazioni delle VMs
o HA si applica a tutte le VMs del cluster a prescindere dall’O.S. e dalle
applicazioni/servizi che vi girano
• HA non è Business Continuity
4
Prerequisiti per HA • Almeno 2 ESXi hosts con almeno 3 GB di RAM
• VMware vCenter Server
• Storage condiviso tra gli hosts (Datastore)
• Pingable gateway o altro sistema
• È inoltre raccomandato avere: o Una rete di management ridondata
o Più di un Datastore condiviso
5
Il cluster VMware
Gigabit SwitchAccesso alla rete fisicamente ridondato
ESXi HostsVirtual Switch 0 con 2 UPLINK - vmnic0 connessa a Switch A - vmnic1 connessa a Switch BDoppio HBA - HBA1 per Fabric 1 - HBA2 per Fabric 2
Switch A Switch B
ESXi 1 ESXi 2 ESXi 3
Fabric 1 Fabric 2
Storage Array
Storage Area NetworkDue Fabric per ridondanza accesso all’arrayStorage Array con doppio controller (dual port)
Router Gateway
6
Il cluster VMware Principio di funzionamento
In caso di fault di uno degli hosts le Virtual Machines vengono
riaccese sugli altri hosts del cluster secondo specifici criteri
• Meccaniche alla base di HA: o Master / Slave
o Heartbeating
o Networking: isolated vs. partitioned
7
Master / Slave • vSphere 5.x introduce il concetto di nodo Master e
nodo Slave in luogo del precedente sistema con
Primary e Secondary Node.
• Ogni cluster elegge un nodo Master che si fa
carico di assolvere ai compiti che garantiscono il
funzionamento di HA.
• I restanti nodi (fino a 31) sono Slave e possono
essere eletti a Master in caso questo subisse un
fault.
8
Master Node • Assume l’ownership dei Datastores del cluster (lock
del file protectedlist)
• Tiene traccia dello stato delle VMs di cui è owner
• Verifica lo stato dei nodi Slave (heartbeat)
• Riceve informazioni da tutti i nodi Slave
• Inoltra le informazioni del cluster alla vCenter
9
Master Node • Condizioni di (ri)elezione di un Master Node:
o All’attivazione di HA
o In caso di fault di un Master Node
o In caso di fault di rete (isolated, partitioned)
o In caso di disconnessione dalla vCenter del Master
o In caso il Master venga messo in maintenance mode o stand by
o In caso di riconfigurazione di HA
• Il processo di elezione dura 15 secondi
• Il meccanismo di elezione si basa: o sul numero di Datastores connessi al nodo
o sull’Object ID più alto in gestione (lessicalmente comparati)
10
Slave Node • Tutti i nodi Slave verificano lo stato di salute del
Master tramite heartbeat
• Ogni Slave Node verifica lo stato delle proprie VMs
e lo comunica al Master Node
• Le informazioni sulle VMs vengono salvate su
appositi files nei Datastores del cluster (es: il file
poweron contiene l’elenco delle VMs accese)
11
Network Heartbeating • Si basa sullo scambio di pacchetti tra Il Master
Node e gli Slave Node
• Non vi è comunicazione tra gli Slave Node
• Di default lo scambio avviene ogni secondo
• L’efficacia del meccanismo di heartbeating è
legata al buon funzionamento della rete
12
Datastore Heartbeating • Non ha nulla a che fare con il Datastore Cluster
• È un ulteriore meccanismo di controllo dello stato
degli Hosts non basato sulla rete ethernet
• Viene utilizzato dal Master Node per comprendere
se un host è effettivamente in fault o se si è
verificato un isolamento/partizionamento della rete
• Il controllo si basa sullo stato del file poweron: o Se presente ed aggiornato si deduce che lo Slave Node è attivo ma
isolato o posizionato in altro segmento di rete
o In caso contrario si deduce che lo Slave Node è effettivamente in fault ed
HA interverrà per riaccendere le VMs
13
Isolated vs Partitioned • Un host è in stato isolated quando:
o Non riceve pacchetti heartbeat dal Master Host
o Non riceve il traffico di elezione del nuovo Master
o Non raggiunge, tramite ping, l’isolation address
• Un host è in stato di Network Partitioned quando: o Non riceve pacchetti heartbeat dal Master Host
o Riceve il traffico di elezione del nuovo Master
14
Isolated vs Partitioned • Il riavvio della VMs di un host isolato avviene sulla
base della policy Isolation Response
• Default setting: Leave power on
Management Network
slave master slave
slave slave slave
Isolation
ESXi1 ESXi2 ESXi3
ESXi4 ESXi5 ESXi6
15
Isolated vs Partitioned • Nonostante alcuni hosts siano isolati questi possono
comunicare tra loro
• Viene eletto un ulteriore Master Node
Management Network
master master slave
slave slave slave
Partitioned
ESXi1 ESXi2 ESXi3
ESXi4 ESXi5 ESXi6
16
Isolated vs Partitioned • La mancata comunicazione con un host non lo
identifica necessariamente come failed
• Datastore Heartbeat consente di identificare con
sicurezza un host failed
• HA interviene solo quando realmente necessario
diminuendo il rischio di riavviare VMs operative
17
HA in azione • In virtù delle meccaniche discusse HA reagisce in
tre specifici casi: o Fault di uno o più hosts del cluster
o Isolation di uno o più hosts del cluster
o Fault di un guest O.S.
• A seconda del tipo di problema HA opererà il
restart, o meno, delle VMs secondo specifiche
regole
18
HA in azione: Master Fail • In caso di fault del Master Node il sistema esegue
una serie di azioni che precedono il restart delle
VMs ed introducono una certa latenza: o T0: il nodo Master va in fault
o T10sec: inizia il processo di elezione del nuovo Master Node
o T25sec: il nuovo Master Node accede al file protectedlist
o T53sec: inizia il restart delle VMs protette
19
HA in azione: Slave Fail • Anche in caso di fault del Master Node il sistema
esegue una serie di azioni che precedono il restart
delle VMs: o T0: il nodo Slave va in fault
o T3sec: il nodo Master inizia a controllare il Datastore Heartbeat (15
secondi al timeout)
o T10sec: il nodo viene dichiarato irraggiungibile ed il Master esegue un
ping di 5 secondi verso la sua management network
o T15sec: se Datastore Hearbeat non è configurato il nodo viene dichiarato in fault
o T18sec: se Datastore Hearbeat è configurato il nodo viene dichiarato in
fault
20
HA in azione: priority • In caso di fault confermato di un host il processo di
restart della VMs avviene secondo la seguente
priorità: o Agent virtual machine
o Fault Tollerance Secondari virtual machine
o Virtual machine con priorità di restart «high»
o Virtual machine con priorità di restart «medium»
o Virtual machine con priorità di restart «low»
21
HA in azione: retries • HA esegue un massimo di 5 tentativi di restart di una
VM o T0: primo tentativo, circa 30 secondo dopo il fail
o T2min: secondo tentativo, 2 minuti dopo il fail
o T6min: terzo tentativo, 6 minuti dopo il fail
o T14min: quarto tentativo, 14 minuti dopo il fail
o T30min: quinto tentativo, 30 minuti dopo il fail
• Se il quinto tentativo fallisce la VM resterà in stato
power-off
22
Considerazioni su HA • I meccanismi decisionali di HA richiedono tempo
• Sono ammessi un massimo di 32 restart process
concorrenti per host
• La VMs vengono riaccese secondo priority
prestabilite
• Possono verificarsi casi limite dove i tempi di restart
si allungano notevolmente: o due host ESXi, 33 VMs su Host-A e o VMs su Host-B
o durante i tentativi di restart il Master Node va in fault
23
Admission Control • Uno dei concetti meno compresi e di conseguenza
poco usati
• E’ un set di policy a supporto di HA
• Non è indispensabile per il funzionamento di HA, ma
può renderlo estremamente efficiente anche a
fronte di gravi guasti infrastrutturali
24
Admission Control • Tre policy che in modo diverso perseguono lo stesso
fine: garantire alle VMs un corretto quantitativo di
risorse anche in caso di fault
• Policy: o Host failures the cluster tollerates: 1-31
o Percentage of cluster resources reserved as failover spare capacity: xx%
o Specify failover host: x hosts
25
Aiutare HA: DRS • Distributed Resource Scheduler consente ai cluster
VMware di distribuire il carico delle VMs (in termini di
CPU e RAM) sui nodi del cluster
• Un cluster bilanciato consente ad HA di gestire in
modo efficiente i restart delle VMs a seguito di un
eventuale fault
• Un cluster bilanciato è in grado di generare meno
down-time in caso di fault
26
Grazie.
27