A vSphere HA majd segít, néha.

Látható volt nálam egy találós kérdés azzal kapcsolatban, hogy mi történik ha az alábbi környezetben előfordul a telephelyek közötti szakadás az ethernet oldalon, úgy hogy telephelyen belül az továbbra is működőképes marad és a tárolókat összekötő hálózat nem érintett.

Válasz: Semmi! Minden fut tovább a Firmley adatközpontban.

A válaszok alapján a legtöbben jól tudták, viszont jött pár rossz is.

Szerintem sokakat meglepett és ezt az is bizonyítja, hogy a vExpert-es Slack csoportba is betettem a kvízt és hát keletkezett némi zavar az éterben.

Magyarázat a “miért?” kérdésre

A VMware HA az vSphere ESXi 5.0 óta nem AAM alapon, hanem FDM alapon működik, ami annyit jelent, hogy a régi primary/secondary modellt, a master/slave váltotta és lényegében feloldották azt a modellt amiben az első öt hoszt volt primary a többi pedig mind secondary. Az volt vele a baj, hogy mindenki nyolc hosztos környezeteket építgetett, mert blade formátumban előfordulhatott, hogy egy nagyobb klaszterben pl 10 node estén minden primary az egyik keretben volt és legalább egy primary nélkül a HA halott volt. Na ezt változtatták meg és bekerül a hálózati keepalive mellett a datastore heartbeat a logikába.

Na de vissza az eredeti elképzeléshez és egy élő példán debuggolva a folyamatot. Négy ESXi van alább, esxi1 és esxi2 az első, esxi3 és esxi4 a második telephelyen. A Master szerepét esxi1 birtokolja, a többiek mind slave-ek. A vCenter Server is az első telephelyen fut.

Na vágjuk el a két telephely közötti kábelt, de úgy hogy az IP hálózat legyen csak érintett. Az esxi3 és az esxi4 egyből not responding státuszba kerül, de ez nyilván a vCenter Server szemszögét mutatja, mivel az nem éri el őket többet.

Mielőtt belenézünk a logokba, határozzuk meg a host ID->valós név párokat, könnyebb lesz a logok megértése. Ezt bármelyik hoszton ki lehet deríteni, futtatni kell – az egyébként gyönyörű nevű – /opt/vmware/fdm/fdm/prettyPrint.sh szkriptet.

Inkább táblázatos formába teszem:

esxi1host-2466
esxi2host-2460
esxi3host-2463
esxi4host-2457

A HA logjait a hoszt oldalon érdemes értelmezni, ezért is vegyük sorra őket.

ESXi1 – a master

Látható hogy várja a heartbeat-et egy ideig, majd dead-nek hiszi a másik oldalt, azaz host-2457 és host-2463-at.

ESXi3 a leszakadt hoszt

Látható, hogy bár elveszi a master-rel a kapcsolatot, a host-2466-tal, az esxi1-el, de nem izolálódik, szavazás indul és esxi4-el új master-t választanak, ebben ő veszít és slave lesz.

ESXi4

A szavazásban ő is részt vesz és esxi3 ellenében végül ő lesz a master, ebben a partícióban.

Ha figyelmesen nézzük a sorokat, láthatjuk hogy “isolated=false” látható csak, egyik hoszt sem hiszi soha azt, hogy izolálódott.

Partíció?

Az. Három dolog történhet egy hoszttal:

  • PSOD/megáll/kikapcsol….bármi ami hirtelen a teljes vesztét jelenti.
  • izolálódik: azaz egyedül van, nem hall másokat.
  • partícionálódik: hall másokat, de nem éri el a master-t.

Az első esetben a HA nekiáll a VM-eket újraindítani egy túlélő hoszton.

Izoláció esetén a hoszt ezen a folyamaton megy végig:

  • választási folymat:
    • mivel nem hall másokat, így magát master-ré teszi
  • pingeli a beállított izolációs címet – alapesetben a default gateway
  • ha nem éri el, akkor izoláltnak gondolja magát
  • végrehajtja az izoláció esetére beállított akciót (Leave powered on, Shutdown VM, Power off VM).
  • a HB datastore-on/okon keresztük jelzi a többieknek, hogy izolált lett
  • a HA többi tagja elindítja a korábban rajta futó VM-eket.

Szóval a HA teszi a dolgát.

Partícionálódás esetén pedig legalább két hoszt szakad le együtt olyan módon, hogy egymással igen, de a többiekkel nem tudnak kommunikálni. Ha ez a leszakadt csoport nem tartalmazza a master-t, akkor ez a folymat érvényesül:

  • választási folyamat
  • kiválasztják a master-t, a másik(többi) a partícióban slave lesz(nek)
  • a datastore-on keresztül megpróbálja kideríteni a master, hogy mi történt a saját partíciójában nem szereplő hosztokkal.
    • ha azt tapasztalja, hogy valamely VM leállt, de egyébként a datastore-on található információk szerint futnia kellene, akkor elindítja.
  • ha minden VM fut, ahogy eddig, akkor nem történik semmi további akció.

Azaz a HA nem csinál semmit! És ez a kulcsa az egész feladatnak, ha úgy szakad meg az IP hálózat két telephely között, hogy a telephelyeken belül egyébként továbbra is működik, akkor a HA nem lép akcíóba, a két telephelyen korábban is futó VM-ek, továbbra is futnak, nem kerülnek át egyik vagy másik telephelyre.

A tanulság az annyi, hogy a stretched cluster nem a szent grál. Látható hogy működésében nincs és nem is lehet witness site, ezáltal bizonyos események nagyon rosszul érinthetik a benne futó virtuális gépeket, ezek által az alkalmazásokat. Mivel nincs harmadik telephely ezért előfordulhat a fentihez hasonló split-brain is, ami bár nem jelenti azt, hogy egy VM mindkét telephelyen futni fog, hanem hogy az VM-ek csoportjai olyan telephelyen fognak majd továbbra is futni, ahol lehet, hogy a hálózat teljesen működésképtelen az adatközpontból kifelé, de azon belül mégis minden rendben.

Ezáltal minden esetben automatikus helyreállást nem szabad elvárni, a fenti esetben is lényegében manuálisan kell – például az érintett virtuális gépek leállításával és/vagy tárolók közötti replikációs vonal elérhetetlenné tételével – átállást megvalósítani. A stretch cluster nem DR terv és végképpen nem várázsütésre megvalósuló átállásra alkalmazható megoldás, hanem egy bizonyos fokú hibatűrést biztosító opció.

Ajánlott irodalom:

Duncan Epping tollából: http://www.yellow-bricks.com/2017/10/10/difference-isolation-partition-vsphere/

Andrea Mauro tollából: https://vinfrastructure.it/2017/12/dark-side-stretched-clusters/