Kétségtelen tény, hogy a vSphere ESXi és vCenter termékében olyan sok képesség és funkció érhető el, hogy sokról kis túlzással nagyon kevesen hallottak, könnyen előfordul, hogy ha hallott is róla, nem tudja miképp lehetne használni. Ez nem negatív, főleg azért nem, mert a képességek listája verzióról verzióra bővül, bár van olyan is amit kivezetnek, mert mérhetően senki az ég világon nem használta.
Van pár olyan képesség azonban ami talán méltatlanul van elnyomva és bár ki van fizetve – hiszen a licenszekben benne foglaltatik – mégsem használja egy ügyfél, illetve ha mégis, akkor lehet rosszul.
Predictive DRS
A vSphere 6.5 óta benne van a termékben és nyilván az Enterprise plus licenszen lévő ügyfeleknek a bekapcsolt DRS mellé „ingyen van”. Mégsincs sokszor bekapcsolva, amit én egyetlen okra vezetek vissza, ami igazából a VMware furcsasága, méghozzá hogy vRealize Operations kell hozzá.
Az ötlet amúgy nagyon jó, mivel a DRS alapvetően egy reaktív szolgáltatás, tehát korábban az ESXi hosztok terhelését volt hivatott kiegyenlíteni – ami indirekt módon a virtuális gépek teljesítményét is segítette – majd a DRS 2.0-val inkább a VM-eket akarja boldoggá tenni.
De ez egy dolog nem változott, azaz valaminek be kell következnie, hogy lépjen valamit, mozgasson virtuális gépeket. A predictive DRS pont ezt oldaná fel, azaz ha visszatérő terhelés éri a környezetet, ami végső soron vMotion eseményeket eredményez, akkor előre kialakítaná a megfelelő szabad kapacitást, hogy a bekövetkezéskor legyen elég erőforrás, ne akkor kelljen össze-vissza mozgatni. 14 napnyi historikus adat kell legalább a működéséhez és 60 percet „lát” előre és annak a változásnak megfelelően cselekszik.
Maga a bekapcsolása is igen egyszerű, vSphere-ben a klaszteren kell egyetlen pipát beklikkelni.
vRealize Operations-ben pedig a vCenter Adapter-en kell egyetlen mezőt átállítani, tehát ezen az oldalon ez egy vCenter-re nézve globális beálítás, de a vCenter Server-ben klaszterenként engedélyezhető vagy sem.
Viszont itt a gubanc, nem mindenki használ vRealize Operations-t, mert sok helyen van SCOM, Veeam One, Tivoli vagy bármi más. Még ha annak gyártója írna is ehhez egy megoldást, akkor is a VMware-nek kellene tenni valalamit, hogy ez ne Operations exkluziv dolog legyen.
Proactive HA
Szintén az alapvetően tűzoltás alapú eseménykezelés kiegészítésére. A high availability akkor – vagy még akkor sem mindig – dolgozik, ha egy/több hoszt, valamilyen ok miatt elérhetetlenné válik, izolálódik vagy partícionálódik. tehát a probléma bekövetkezése után tesz valamit, hogy újra működjön minden.
Azonban a HA-nál mindig félreértés van abból, hogy lesz-e kiesés. Igen lesz, mindig minden esetben a virtuális gépek minimum újraindulnak – kivéve ha izoláció esetén leave powered on vagy kikapcsolás a beállítás – tehát az alkalmazások maguk kell megoldják, ha az újraindulás alatt nem akarnak kiesést, legyen az elosztott működés vagy guest cluster.
Szintén külső segítséggel a vCenter rábírható arra, hogy a hosztot érintő nem végzetes hiba esetén felkészüljön a várható kiesésre.
Nem végzetes hibák lehetnek:
- Power Supply – tápegység
- Memory – memória
- Fan – ventillátor
- Storage – tároló
- Network – hálózat
Tehát normál esetben egy tápegység meghibásodása nyilvánvalóan nem érinti a redundáns tápegységekkel rendelkező és megfelelően bekábelezett szerver működését a virtuális gépek szemszögéből. Viszont mi történik, ha a két tápegységből az egyik már meghibásodott, a másik pedig szintén elszáll, tökremegy az is vagy elveszik a betáplálás rajta. Annak a végereménye HA esemény lesz, indulnak is újra a virtuális gépek egy másik hoszton/hosztokon.
Erre adhat megoldást a Proactive HA. Ha egy ilyen nem végzetes esemény bekövetkezik, akkor a hoszt vagy karanténba tehető vagy teljesen evakuálható – illetve van egy mixed mód is. Előbbi esetben a DRS nem fog több virtuális gépet erre mozgatni, utóbbi esetén pedig teljes mértékben kiűríti, minden addig itt kiszolgált virtuális gépet máshová helyez.
A mixed mód „enyhe” hibánál nem mozgat, de súlyosabbnál már lép és kiüríti a hosztot. Valahol a másik kettő között van.
De mégis honnan veszi azt, hogy mi enyhe és mi súlyos vagy éppon azt hogy egy SSD-nek problémája van, mikor az egy RAID kötetként látszik számára. A gyártó ad hozzá integrációt, a kiszolgáló gyártója, illetve annak valamilyen a szervereket menedzselő/monitorozó terméke. A HPE-nél ez a OneView, a Dell EMC-nél az OME, Cisco-nál pedig az UCS Manager-be van integrálva.
Hazánkban ezzel a három gyártóval a mainstream kiszolgálókat vásárló ügyfelek 90%-át simán le lehet fedni és ha így van, akkor miért is nem lehet bekapcsolni?
Admission control – Performance Degradation VMs tolerate
Az admission control beállításáról is írtam már korábban. Teljesen mégértem azokat, akik nem kívánnak kihasználatlan kapacitást tartani a klaszterekben, emiatt HA esetén inkább kikapcsolják a feláldozható virtuális gépeket. Láttam már olyat is, hogy két telephelyre elosztott stretched cluster-ben az admission control beállítása egy hoszt erőforrását tartotta fent – ez volt a beállítás – ami enyhe paradoxon, hiszen miért van stretched klaszter, ha egy telephely kiesését elviselni nem képes a rendszer.
Amiről most írnék, az a méltatlanul és nemes egyszerűséggel gyakorta átugrott beállítás, a „Performance Degradation VMs tolerate”. Ennek alapértelmezett értéke 100%, ami nem mást jelent, minthogy az Admission Control egyáltalán nem törődik azzal, ha a virtuális gépek elérhető teljesítménye bármilyen formában csökkenne HA esemény eredményeként. Ha ezt más értékre állítjuk – százalékonként lehet – akkor az aktuális CPU és RAM használtság alapján dolgozik majd az admission control, amikor figyelmeztet hogy elfogyott az erőforrás oly módon, hogy a „Host failures cluster tolerates” definíciójánál megadott hosztok elvesztése esetén ne legyen a meghatározottnál magasabb túlfoglalás.
Nézzünk egy 4 hosztból álló homogén klasztert. Mindegyik hosztban van 10 x 2,4Ghz CPU és 256GB RAM, ezáltal az összes klaszter erőforrás 4 x 24 = 96 Ghz, illetve 1024 GB RAM. Ha a beállítás így néz ki mint az alábbi képen, azaz egy hoszt kiesését akarjuk tolerálni a VM-ek 50%-os teljesítményvesztésével.
Tegyük fel hogy 820 GB RAM az aktuális felhasználás – reservation nincs(!!) – szóval egy hoszt elvesztésével az elérhető összes memória lecsökken 768GB-ra, viszont azon 820GB-nyi – plusz mindenféle overhead – kell kiszolgálni. Ez 50%-os tolerancia mellett még vállalható, de ezt azt is jelenti, hogy majd lesz egy kis RAM constraint.
Ha „Performance Degradation VMs tolerate” értékét 0%-ra állítjuk, akkor azonnal jelzi az Admission control, hogy nincs elegendő erőforrás a hiba kezelésére, csak a virtuális gépek teljesítményének csökkenésével. Egy ideális környezetben ezért ezt az értéket illendő 0%-ra állítani.
vFlash Read Cache – deprecated
Ez az a funkció ami sokáig benne volt – benne van a vSphere 7.0-ban is – de már régen bejelentették, hogy valamelyik következő verzióban majd eltűnik. Soha senki nem használta – én soha nem láttam még ilyet élesben – ami az all flash tárolók világában még inkább érhető. Ahol volt a hosztban erre SSD/SSD-k, azokat fel lehetett használni az adott hoszton kiszolgált virtuális gépek olvasási műveleteinek gyorsítására, akár ha a VMDK-k egyébként SAN/NAS-on voltak elhelyezve. Nem minden esetben volt haszna.
VMware vSphere Flash Read Cache is being deprecated. While this feature continues to be supported in the vSphere 6.7 generation, it will be discontinued in a future vSphere release.
https://blogs.vmware.com/vsphere/2019/04/vflash-read-cache-deprecation-announced.html
Space reclamation
Több vSphere verzióban az unmap alapból ki volt kapcsolva, manuálisan kellett futtatgatni, ha a tárolón magán akartunk helyet felszabadítani – nyilvánvalóan thick on thick esetén nincs értelme ilyenről beszélni. Ez a 6.7-ben szintén megváltozott, már bekapcsolható az reclaim, viszont sebességét érdemes a saját tárolónk terheléséhez és képességeihez igazítani. 100MB/s-tól egészen 2000MB/s-ig lehet választani. Az alábbi példában a Nimble-re én a legdurvább beállítást alkalmazom, kibírja 🙂
Restart priority HA
Minden renszerben – főleg a politikában 😀 – vannak az egyenlőbbnél is egyenlőbb elemek és ez a virtualizációban sincs másképp. Egyéb beállítás hiányában a HA igazából egyenlőként kezel mindent, de ha mégis szertnénk kiemelten kezelni egy vagy több VM-et, akkor érdemes azt override-ra tenni. Egy jól méretezett rendszerben ilyen „override”-ot nem kell használni, szóval nem állítom, hogy minden rendszerben használni kell, lehet létjogosultsága.
Lentebb látszik, hogy egy VM-et a legmagasabb prioritással indítja és a következőket csak akkor ha számára az erőforrás lefoglalódott – ez még mindig nem reservation(!)
Létezik olyan beállítás is, hogy megvárja a VM Tools általi életjelet is és csak azután indítja a következőt/következőket. Hasznos egymásra épülő alkalmazások esetén, például egy Windows fájlszervert nincs sok értelme az első tartományvezérlő előtt indítani.
Összefoglaló
A lista nem teljes, sok ilyen van elfeledett vagy sosem használt funkció van, néhol még a content library is újdonság, máshol pedig kiterjedten használják. Időről időre érdemes körbenézni a menüben vagy megkérdezni egy naponta ezzel foglalkozót, hogy mi merre, hány méter.
