Hogy kapcsoljuk be a vCenter High Availability-t?

A vCenter Server High Availability – továbbiakban VCHA – a vCenter Appliance 6.5-ben jelent meg először és azóta fejlödött is picit. Azelőtt, ha magas rendelkezésre állást vártunk el a vCenter szolgáltatástól, akkor csak a Windows Server alapú vCenter volt használható. Legalább két nagyságrenddel volt bonyolultabb ezeket megépíteni és üzemeltetni, mivel a vCenter Server szolgáltatást egy Microsoft Failover Cluster erőforrásaként kellett fusson, illetve rendes – nem SQL Express – kellett, ami szintén például egy klasztert alkotott. (Én még soha sehol nem láttam ilyen megoldást.)

Ezzel szemben a VCHA tényleg pofon egyszerű (sic), ugyanakkor én 13 (!!) alkalommal próbáltam bekapcsolni – majd látjátok, hogy advanced a kialakítás amivel próbálkoztam – szóval elég sok időmet elvette.

Szerintem ez az a pont, ahol szükséges tisztázni, hogy ez nem egy DR megoldás. Azaz alapvetően egy telephelyen belüli magas rendelkezésre állás a célja és nem az, hogy egyébként több telephelyen működjön és a telephelyek között bárhol futhasson a vCenter. Ez értelmezés kérdése, de azért szerintem az még vállalható, ha egyébként stretched klaszter(ek) van(nak), akkor a vCenter HA egy jó kiegészítése lehet. Viszont ha a klaszterek lokálisak, a vCenter pedig futhat hiba esetén egy másik telephelyen, akkor az nem elegáns, illetve sehogy sem segíti a DR helyzet megoldását, mivel a másik telephelyen ragadt ESXi-ket nem lehet központilag menedzselni, mivel például a telephelyek között nincs kapcsolat.

Hogy működik?

Minden esetben három vCenter appliance van a megoldásban, melyből kettő tekinthető annak, amelyek képesek teljes funkcionalitással kiszolgálni. A harmadik vCenter appliance a witness szerepét tölti be. Nagyon fontos szintén, hogy ha nem látják a witness-t és szakadás van, akkor nem lesz automatikus failover. Ezért kiemelten fontos a stabil kapcsolat közöttük.

A megvalósításban két vCenter szervernek két NIC-je van, a witness-nek csak egy – igazából kettő de az egyiket nem szabad konfigurálni. Az eth0 az a hálózat amelyen a szolgáltatást használjuk, ennek van DNS bejegyzése is. A HA hálózatot az eth1 interfészek használják. Itt valósul meg a replikáció is, azaz nem az eth0 interfészek végzik annak a forgalomnak a lebonyolítását, főleg mivel a passzív node-nak az eth0 interfésze down-ban van és aban is marad amíg nincs failover.

A szükséges előfeltételek:

  • külön VLAN – és értelemszerűen port group – a Management – eth0 – és a HA – eth1 – számára
  • 10 ms RTT-nél alacsonyabb késleltetés a node-ok között
  • legalább “Small” appliance méret – alatta is működik, de nem támogatott.
  • vCenter Standard licensz – nem szükséges a passzív node-ot licenszelni, sem a witness-t, viszont vCenter Server Foundation-ben nincs VCHA.
  • bekapcsolt SSH a VCSA-n.
  • (javasolt)Javasolt dolgok: a vCenter-ek legyenek egy olyan klaszterben ahol legalább három hoszt van – nyilvánvaló, mivel jó lenne ha nem futnának egy hoszton.

Opció 1 – azonos layer 2 minden lokáción

Eddig nem beszéltem arról. hogy egy-egy szegmensbe kell-e lennie minden node-nak az eth0 és eth1 interfészek hármasára vonatkozóan. Alapvetően ez a javasolt design és ettől ne térjen el senki ha megteheti azt hogy ezt a két layer 2 szegmenst kiterjessze három helyre.

Opció 2 – nem azonos layer 2 a lokációkon

Az aktív VCSA eth0 interfésze és a passzív VCSA azonos interfésze más szegmensben van, de ekkor egy failover esetén, DNS-ben át kell írni az új IP-re az adott rekordot. Ez utóbbi nem túl szép megoldás, nem is javaslom.

Opció 3 – hibrid

Az elfogadható szerintem, ha a Management szegmens két lokáción azonos, azaz az aktív node váltözása esetén az IP a másik lokáción is azonos lehet, így nem kell DNS-t állítgatni, viszont a HA hálózat vagy lokációnként különböző vagy a két fő lokáción azonos, de a witness lokáció esetében egy másik.

Hogy kell bekapcsolni?

A fenti opciók mindegyike más folyamatot igényel. Addig teljesen azonos a folyamat, hogy megnyomjuk a “Set up vCenter HA” gombot.

Illetve meg kell adni, hogy hová fogjuk tenni a szükséges két appliance-t. Ez lehet vCenter is, amennyiben például egy management klaszterben éppen egy workload vCenter-t kívánunk VCHA-ra állítani. Ugyanakkor lehet hoszt is és ez a gyakoribb. A példákban én az elsőt mutatom be.

Opció 1 beállítása

Ez a legegyszerűbb, mivel a varázsló mindent megcsinál helyettünk.

A következő lépés az, ahol kiválaszthatjuk hogy ez most automatikus legyen vagy manuális. Mi fog történni?

  • eth 1 – azaz NIC2 – kerül be az appliance-ba
  • két klónozás – passzív és witness
  • azok hálózatainak beállítása
  • felkonfigurálása IP-vel

Hogy ehhez legyen elegendő információ, az alábbi ablakban ki kell választani a HA hálózatot, majd egyenként beállítani a passzív és a witness node helyét, és port group-jait. Ezekre csak akkor van szükség, ha az “Automatically create clones for Active node” be van pipálva. Ha nincs, akkor mindent manuálisan kell végrehajtani majd. Ennél az opciónál ennek nincs értelme.

A következő ablakban az IP beállításokat kéri be a varázsló. Figyelem! Bármennyire is csábító default gateway-t beírni, főleg a witness esetében, ahol ez az egyetlen hálókártya, nehogy beírjunk oda bármit, mert nem fog működni a HA. Igazából nem is értem minek van az egyáltalán ott.

A finish kiválasztása után, máris elindul a klónozás és a beállítás. Érdemes 10 perc múlva megnézni hol áll, de addig ez a kép fogad.

Ha minden sikeres volt, akkor a Status oszlopban minden zöld lesz.

Opció 3 beállítása

Az opció 2-t nem mutatom meg, mert nagyon hasolnló az opció 3-hoz, ugyanakkor az opció 2 létjogosultsága szerintem abszolút nem valós. Ezzel szemben ez a verzió sokkal gyakrabban fordulhat elő.

Következő lépésben az IP beállításokat kell megadni.

Meg kell nyomni a “Finish” gombot itt kell leklónozni a gépet – futás közben – két példányban.

Előtte adjunk hozzá egy második NIC-et (vmxnet3) a VCSA-hoz és kapcsoljuk a HA hálózathoz.

Lépjünk be a VAMI felületre és adjunk neki IP-t.

Ezek után készítsünk el két “Customization specification”-t. Egyikkel a passzív node-ot, másikkal a witness-t fogjuk klónozás alatt megváltoztatni.

A következő ablakban így töltsük ki a mezőket.

Időzóna legyen azonos mindegyik VCSA esetében. A hálózatot a NIC1 esetén konfiguráljuk DHCP-re, a NIC2-t pedig állítsuk a szükséges HA IP-re.

Mindenképpen írunk be legalább egy DNS kiszolgálót és a search path-ot a következő lépésben.

Ismételjük meg ennek a customization template létrehozását a witness esetén is, annyi eltéréssel, hogy a NIC2-nek a megfelelő IP-t adjuk a HA hálózatról.

A klónozás végig ugyanúgy történik, mint az már megszokott, viszont az alábbi módon válasszuk ki a lehetőségeket.

A customization template a passzívnál értelemszerűen a vcha-passive.

Ezek után módosításra nincs szükség, mivel az aktív – amiről a klón készül – azonos hálózatokon van a passzív másolattal. Ha az opció 2-t nézzük, abban az esetben itt is módosítani kellene a hálózatokat.

Ne menjünk tovább, ismételjük meg a witness esetén is a klónozást.

A NIC1-et tegyük disconnected-be és valami dummy port group-ba, a NIC2-t pedig a witness port groupba, nálam ez a VLAN_150.

És most jön a rázós rész, statikus route-ot kell beállítani mindhárom appliance-ban. Lépjünk be az aktív-ra konzolon, majd szerkesszük meg a eth1 beállításait.

Három sor kell bele, ami a az aktív és passzív node esetén ezt tartalmazza, esetemben:

[Route]

Gateway=10.1.170.254

Destination=10.1.150.0/24

A witness esetén hasonlóan kell eljárni, de ott nyilvánvalóan az statikus route az aktív és passzív lábak felé mutat.

[Route]

Gateway=10.1.150.254

Destination=10.1.170.0/24

Mindegyik után írjuk be miután elmentettük a fájt, a következő parancsot:

systemctl restart systemd-networkd

Failover teszt

Nem azonnali az átállás, de pár perc alatt megtörténik. Ha még nem indult el a vCenter minden szolgáltatása, de a web server már igen, akkor ezt mutatja:

Ha minden elérhető, akkor belépve látható, hogy az aktív szerepkör a másik és eddig passzív appliance-ra került.

Összefoglaló

Hasznos-e ez a funkció? Igen, viszont csak akkor javasolt használni, ha hajlandóak vagyunk picivel több munkát elvégezni a frissítések alkalmával, mivel ott minden esetben azt parancssorból kell megtenni és nem a VAMI felületéről automatikusan. Az upgrade-ek, pl 6.5 -> 6.7 és majd újabb verziók esetén lényegében el kell távolítani a HA-t, upgrade-et elvégezni – mivel ez ova deploy és a konfig átmásolása történik – majd újra beállítani a VCHA-t. Amennyiben ezt varázslóval meg tudjuk tenni, mert az első opciós design használja valaki, akkor ez nem probléma, viszont amennyiben manuálisan kell klónozgatni és a route-okat állítani, akkor véleményem szerint nem éri meg ez a sok befektetést.