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.
