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