Gyakran találkozom olyan „tervekkel”, amelyekben egy új VMware virtualizációs környezet kialakítása kapcsán kell általában véleményezni kell őket, amennyiben valamit nem ajánlok/javaslok, azok ellen tehetek pár megjegyzést és vagy végül megfogadják vagy nem – ilyen is van.
Szóval gyakorta előkerül a VMware HA egyik legfontosabb beállítása, méghozzá az „Admission control”. Sok ügyfélnél ez például be sincs állítva, gyakorta azért, mert egészen egyszerűen nincs szabad kapacitása, amit „nélkülözni” tudna.
De miért is kellene nélkülözni, meg mi az az Admission Control?
A VMware HA, alapvetően egy klaszteren belül védi a virtuális gépeket az ESXi hosztokat érintő hibák esetén – tekintsünk el a VM monitoring résztől most. 6.5-ben van reaktív – ez volt korábban az egyetlen mód – illetve proaktív HA is.
Proactive HA
Utóbbi képes arra, hogy ha egy hosztban olyan hiba fordul elő, amely nem jár azonnal az érintett hoszt hibájával, akkor a futó virtuális gépeket képes evakuálni arról a szerverről, még mielőtt ténylegesen leállna.
Ilyen esemény lehet például egy tápegység, egy ventillátor meghibásodása vagy ha például a RAID-vezérlőn tönkremegy az akkumulátor/kondenzátor.
Ezt a funkciót még soha sem láttam ügyfeleknél bekapcsolva, pedig véleményem szerint érdemes használni. Semmiféle járulékos költséggel nem jár a bekapcsolása, mivel például ha HPE szerverei vannak, akkor jó eséllyel HPE OneView is van – nem az ingyenes verzió kell – vagy ha Dell van a rackben, akkor OpenManage is lehet nála már.
Reaktív HA
Ez az a high availability amit mindenki a HA alatt ért. Amennyiben megáll, izolálódik, elveszti a tárolóval a kapcsolatot egy vagy több ESXi kiszolgáló, akkor a beállított akciók alapján cselekszik. A legegyszerűbb példában egy hoszt PSOD-dal – ilyen is van igen – áll meg. A rajta futó VM-eket a HA majd újraindítgatja a többi hoszton, viszont ez ugye időszakos elérhetetlenséggel jár az érintett virtuális gépek számára.
Fontos hogy ezt csak akkor teszi, ha van elegendő szabad kapacitás! És pontosan itt jön képbe az Admission Control. Ő felel azért, hogy ha baj van, akkor legyen CPU és RAM erőforrás, így elindíthatóak legyenek az érintett VM-ek. Tehát ezt ki kell erőszakolnia az Admission Control-nak. Itt van az a kapacitás, amit az ügyfél nem használhat normál üzemben, azaz ez amit nélkülöznie kell.
Három módon tudja ezt megtenni:
- Dedicated failover hosts: Magáért beszél, explicit megadható mely hosztot/hosztokat akarjuk fenntartani egy HA esemény kezelésére. Na ez az a beállítás, amire nem tudok jó okot és use case-t mondani. Az így beállított hosztok telejsen üresen ott fognak készenlétben állni, lényegében malmozni.
- Slot policy (powered-on VMs): Ilyenkor a működés egy úgynevezett „slot size” értéken alapul. Ez az érték határozza meg, hogy a HA esemény bekövetkeztekor a fennmaradó fürtben elérhető erőforrások összességére nézve, hány virtuális gép kapcsolható be a HA által. Alapesetben a slot size 32Mhz CPU és 0MB RAM. Ha a fürtben van olyan virtuális gép melynek van CPU és/vagy RAM reservation konfigurálva, akkor a HA a legmagasabb ilyen értéket veszi alapul és állítja be slot size-nak. Ez az egyik ok, ami miatt minden a reservation ellen szól – erősen ellenjavallott. Ha megvan a slot size, akkor minden hosztra kiszámolja a futtatható slot-ok számát – a host root resource pool-ját veszi alapul.
Egy konkrét számoláson megmutatva:
ESXi hardver ( 2 x 28 mag 2,4Ghz, 1024GB RAM).
Nincs VM reservation.
Egy hoszton így a slot-ok száma (2 x 28 x 2,4 x 1024) / 32 = 4300
Ez jól hangzik, de ha van rezerváció, akkor nagy a baj. Tegyük fel hogy van, azaz 32 GB RAM-ot és 14 GHz-et fenntartunk egy VM-nek.
Ekkor a slot-ok száma:
CPU: (2 x 28 x 2,4 x 1024) / 14336 = 9,6
RAM: 1024 / 32 = 32
A szorosabb érték nyer, így egy hoszton 9 darab VM kapcsolható majd be. Szóval ezt ha lehet, sosem javaslom használatra, ami egyébként 6.5 előtt alapértelmezett volt.
- Cluster resource percentage: Egyértelműen a javasolt és 6.5 óta az alapértelmezett is.
Hogyan számol – ha egyébként nem definiáljuk explicit az értékeket? Összeszámolja az összes aktuálisan futó VM által használt erősforrást, aztán az összes erőforrást amelyet a hosztok nyújtani képesek.
Tehát, használunk 5 + 3 + 2 + 1 + 5 + 3 (Ghz) CPU-t = 19 Ghz és 16 + 32 + 8 + 4 + 16 + 16 (GB) RAM-ot = 92 GB.
Összesen a hosztokban 24 Ghz és 128 GB RAM szolgáltatható – a példában kicsik a hosztok, mert nem szeretnék VM-ek százaival számolni.
Szóval a jelenglegi failover capacity:
((24-19) / 24) * 100 = 20,8% CPU és ((128-92) / 128) * 100 = 28,125% memória.
Ha a „Host failure to tolerate” fentebb 1 értékben definiált, azaz a négy node tekintetében, egy elveszhet és mivel homogén hosztokkal dolgozunk, így 25% erőforrás kell mind CPU-ból és RAM-ból, hogy egy hoszt elvesztését sikeresen kezelni tudja. Ez a példában nem teljesül, mert csak 20% szabad kapacitás érhető el már. Szerencsére 6.7 óta ez a százalékos beállítás automatikusan számolódik, így ha a hosztok száma nő, akkor nem kell ezeket a százalékokat átírni, korábban erre szükség volt. Egyértelműen ezt a beállítást javaslom az esetek 99%-ban, nem véletlenül ez az alapértelmezett.
Konklúzió
Érdemes utánajárni az ilyen alapvető fontosságú beállítások előnyeinek és hátrányainak megértése érdekében, illetve szakértőt megkérdezni. Rossz beállítás esetén sérül a redundancia és a végén nem azt kapja az ügyfél amit vár.
