1. Understanding
VMware HA
Le meccaniche di ridondanza dei cluster
VMware vSphere (v5.x)
1

2. «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

3. 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

4. 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

5. 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

6. Il cluster VMware
Gigabit Switch
Accesso alla rete fisicamente
ridondato
ESXi Hosts
Virtual Switch 0 con 2 UPLINK
- vmnic0 connessa a Switch A
- vmnic1 connessa a Switch B
Doppio 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 Network
Due Fabric per ridondanza
accesso all’array
Storage Array con doppio
controller (dual port)
Router Gateway
6

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. Grazie.
27