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:
| esxi1 | host-2466 |
| esxi2 | host-2460 |
| esxi3 | host-2463 |
| esxi4 | host-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/
