festival ICT 2013: Understanding VMware HA

438 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
438
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

festival ICT 2013: Understanding VMware HA

  1. 1. Understanding VMware HA Le meccaniche di ridondanza dei cluster VMware vSphere (v5.x) 1
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. Grazie. 27

×