riporto qui le slide

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
Router Gateway
Switch A
Switch B
Gigabit Switch
Accesso alla rete fisicamente
ridondato
ESXi 1
ESXi 3
ESXi 2
Fabric 1
Fabric 2
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
Storage Area Network
Due Fabric per ridondanza
accesso all’array
Storage Array con doppio
controller (dual port)
Storage Array
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
o
o
o
o
o
All’attivazione di HA
In caso di fault di un Master Node
In caso di fault di rete (isolated, partitioned)
In caso di disconnessione dalla vCenter del Master
In caso il Master venga messo in maintenance mode o stand by
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
ESXi1
ESXi2
slave
ESXi3
master
slave
Isolation
Management Network
slave
ESXi4
slave
ESXi5
slave
ESXi6
15
Isolated vs Partitioned
• Nonostante alcuni hosts siano isolati questi possono
comunicare tra loro
• Viene eletto un ulteriore Master Node
ESXi1
ESXi2
master
ESXi3
master
slave
Partitioned
Management Network
slave
ESXi4
slave
ESXi5
slave
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
o
o
o
T0: il nodo Master va in fault
T10sec: inizia il processo di elezione del nuovo Master Node
T25sec: il nuovo Master Node accede al file protectedlist
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
o
o
o
o
Agent virtual machine
Fault Tollerance Secondari virtual machine
Virtual machine con priorità di restart «high»
Virtual machine con priorità di restart «medium»
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
o
o
o
o
T0: primo tentativo, circa 30 secondo dopo il fail
T2min: secondo tentativo, 2 minuti dopo il fail
T6min: terzo tentativo, 6 minuti dopo il fail
T14min: quarto tentativo, 14 minuti dopo il fail
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

Download Report