A vCLS gépek nyugalma

A VMware szerver oldali virtualizációs termékében, a vSphere-ben a management és a control plane (részben), mindig a vCenter Server volt. A vCenter Server a konfiguráció helye, az a felület, amin a legtöbb klaszter szintű és annál magasabb képesség kezelhető. Azonban a vCenter Server ezáltal egyre több és több feladattal a hátán, egyre kritikusabb és kritikusabb részévé vált az infrastruktúrának. Azok az idők pedig már elmúltak, hogy a vCenter Server és a klaszter összerendelése egy az egyhez legyen. Ebből fakadóan a vCenter elérhetetlensége nyilván járhat nem optimális okozattal.

Született persze vCenter High Availability az évek során, de én azt soha senkinek nem ajánlom. Azért kellett az, mert így lehetett feature parity-be hozni a Windows alapú vCenter telepítéssel és utóbbit támogatását megszűntetni. Persze egész más egy Windows Failover Cluster-ben, SQL klaszterrel a háttérben egy vCenter, mint a VCHA maga, a három linux appliance-on. Három ügyfélnél is láttam, hogy kipróbálták és ha sikerült is kiépíteni, nem hozta amit kell. Menedzsment szempontból nem éppen álom, ha nem a szimpla next-next-finish kiépítéssel indul valaki.

A VMware tehát azt gondolta a vSphere 7.0U1-ben, hogy kiszervez bizonyos képességeket a vCenter-ből és letolja az ESXi hosztok szintjére. Megszülettek tehát a vSphere Cluster Services – továbbiakban vCLS – virtuális gépek, amelyek agent virtual machine entitások. A frissítés során – aki eljutott a vSphere 7.0U1-re már (lol) – azoknál alapból megpróbál létrejönni pár ilyen vCLS gép, minden klaszterben egy vagy több, maximum három darab ha van legalább három ESXi hoszt. Ezek között anti-affinitási szabály létesül, hogy ne legyenek egy ESXi-n, mert akkor semmi értelme az egésznek. Akkor is vannak ilyen vCLS gépek, ha adott klaszterben nincs bekapcsolva HA, sem DRS.

Feladatuk egyszerű, a vCenter elérhetetlensége esetén biztosítják a zavartalan működést. A DRS-hez mindenképpen kellenek. A DRS a terhelés optimális elosztását végzi, amely immáron a virtuális gépek „egészséges kiszolgálását” próbálja elérni – korábban az ESXi-k egyenletes terhelését tartotta céljának – amihez egy folyamatosan változó és több metrikából álló halmazt használ a döntések meghozatalához. Ezt eddig a vCenter Server végezte egymaga, szóval ha nem volt vCenter Server éppen elérhető, akkor a DRS sem működött.

A vCLS gépek nem kérnek sok erőforrást, 1 vCPU, 128MB és 2GB diszk birtokában működnek. Ami viszont lényeges, hogy melyik datastore-on kívánjuk őket elhelyezni. Alapvetésben automatikusan választ – pont mint a HA a datastore HB-hez – datastore-t, főleg azt nézve hogy melyik az a datastore, amihez a legtöbb cluster-ben lévő ESXi hozzáfér. Tehát preferáltan közös datastore-ra próbál lőni, amellett hogyha több ilyen datastore van, akkor azokra egy-egy vCLS gépet tesz. Természetesen lehet ezeket a vCLS gépeket storage vmotion segítségével másik datastore-ra helyezni, de azt jó lenne lekövetni a vCLS Allowed résznél per klaszter.

A „solution blocked” részben lehet kiválasztani olyan datastore-okat, amelyekre ne rakhasson vCLS gépet. Itt olyanokra gondolok, hogy például valaki nem használ content library-t és egy datastore pl csak az ISO/OVA/template gépek és állományok számára van fenntartva, arra persze hogy ne tegyen semmit.

A vCLS gépek egészségi állapota legalább olyan fontos, mint maga a vCenter-é, tehát érdemes kezelni ha bajt jeleznek. Klaszter szintjén egészen jól meg is lehet nézni hogy éppen mi az állapot és mikor/hogyan változott.

Bár nagyon fontos gépekről van szó, nem kell/szabad őket snapshot-olni, nem kell őket menteni sem és visszaállítani sem. Beléjük telepíteni semmit sem szabad és igazából belépni sem kellene rájuk. A jelszavukat egyébként ki lehet nyerni a vCenter Server-ből ha nagyon kell, de én hirtelen nem tudok olyan okot, ami miatt erre szükség lenne.

Retreat mode

Bármi olyan karbantartás esetén, ahol a egészen egyszerűen az összes közös datastore megszűnik elérhetővé lenni – kivételes eset – szóval nincs hová storage vmotion-özni a vCLS gépeket, akkor kellhet a retreat mode. Ebben a módban nem fog működni a DRS, mármint be lesz kapcsolva – ha eddig be volt – de nem fog vMotion-t indítani, ha maintenance módba kerül egy hoszt, akkor arról nem fog lemozgatni semmit, hiába van fully automated-ben. Persze a HA sem tud majd optimális döntést hozni arról, hol indítsa el a VM-eket, ha mondjuk pont a retreat mode alatt áll meg egy vagy több ESXi hoszt. Mármint a HA elindítja a VM-eket, de nincs rá garancia, hogy a teljesítmény a legoptimálisabb lesz.

Pre 8.0U2 esetén a vCenter szinten kellett beadni egy advanced parameter-t a cluster-t jellemző domain-re. 8.0U2-nél már kint van a GUI-n is.

A retreat mode bekapcsolása maximum egy percen belül eltakarítja a vCLS gépeket és a fentebb mutatott monitoring Degraded státuszt mutat majd, mivel a DRS nem lesz működőképes.

Összefoglaló

A vCLS gépeket hagyni kell létezni, de szabad őket storage vmotion-özni ha kell. Nem szabad kikapcsolni/bekapcsolni őket – amúgy is védettek – nem kell őket menteni, nem kell belépkedni rájuk, nem kell telepíteni semmit sem – amúgy sincs hálózati interfészük.