Nem voltam aktív az utóbbi pár hónapban, ennek egyszerű oka van….sok jó projektben volt szerencsém dolgozni. Az egyik közülük egy VMware Horizon rendszer tervezéséről szólt, amelynek célja több ezer felhasználó munkamenetének biztosítása. Tennie kell ezt hibatűrően, de nem ám csak azon a szinten, hogy kieshet egy ESXi kiszolgáló vagy egy-egy diszk, hanem a felhasználó szemszögéből már a virtuális munkaállomása is redundáns kell legyen.
A feladat tehát világos: egyszerre 5000 felhasználó kiszolgálása a lehető legegyszerűbb módon, minden sallang nélkül. Belépés csak belső hálózatról várható, szóval jelentősen egyszerűsödik az architektúra, mivel nem kell UAG/IDM stb.
A gyártó ki is adott erre egy kicsit már korosodó referencia architektúrát leíró dokumentumot, „VMWARE HORIZON 7 ENTERPRISE EDITION MULTI-SITE REFERENCE ARCHITECTURE VMware Horizon 7 Version 7.2 and Later” névvel.
Attól hogy ez a dokumentum nem épp friss, most tekintsünk el. Nem ír hülyeségeket, de kicsit csapong és nehéz megérteni mit-mire ír pontosan. A szövegezés a felhasználó székéből nézve íródik, tehát az aktív/passzív az nem azt jelenti, hogy az egyik adatközpontban csak kriptót bányásznak a szerverek a VDI kiszolgálása helyett, hanem azt hogy egy felhasználó mindig azonos adatközpontba kerül.
Három esetet tárgyal benne, amiből a harmadik az egyáltalán nem Cloud Pod kiépítés, de az első kettő igen.
VMware szerint aktív/aktív
Az aktív/aktív a fenti táblában igazából a felhasználó szempontjából aktív/aktív.
A felhasználó bármelyik telephelyen kaphat munkamenetet, tulajdonképpen teljesen mindegy hogy hová dobja a rendszer. Nyilvánvalóan a rendszer része egy load balancer – igazából egy globális és egy lokális is – viszont mikor authentikál a felhasználó, akkor kis túlzással véletlenszerűen dől el, hogy honnan kap munkamenetet. Lényeg a lényeg a képen, hogy a profilja, az átirányított dokumentumai és például a vonatkozó DEM beállításai mindenképpen egy telephelyről csatolódnak. Ebből az következik, hogy maga a munkamenet bár nincs adatközponthoz kötve, de a felhasználói adatok többsége mégis. Ennek lehetnek hátrányai is, mivel ha az ilyen adatok már belépéskor távolról csatolódnak és munka közben íródnak – ha például az átirányított könyvtárába dolgozik a felhasználó, akkor annak lesz adatforgalma és késleltetése is nyilván. Ráadásul a fenti ábra például nem oldja meg azt a problémát, hogy ha writable volume-ot használnánk, akkor az mégis hogy csatolódna. Simán nem tárgyalja, mert lehetetlen megoldani.
VMware szerint aktív/passzív
A felhasználó az egyik telephelyen honos, mindig onnan kap munkamenetet. Csak akkor kaphat a másikról, ha azt mi engedélyezzük. Pont ez az a megoldás ami aktív/aktív tud lenni az én olvasatomban. Mondjuk a felhasználókat két csoportba rendezem Active Directory-ban és őket egy-egy – különböző – honos telephelyre rendelem.
A felhasználó szemszögéből ez aktív/passzív de a felhasználói csoport mint összesség, viszont aktív/aktív működés is kialakítható belőle. Lentebb ezt fogom ismertetni.
A megérséshez szükséges alapok
Először nézzük meg a munkamenetek típusait:
- full clone VDI: Nem mások, mint a klónozás után, örökké példányosított virtuális gépek. Egy master gépből a Horizon által létrehozott olyan virtuális gépek összessége, melyek üzemeltetése, mentése, konfigurációja semmiben nem különbözik mondjuk egy asztali számítógéptől, amik a felhasználók asztalain van – nyilván firmware-elni nem kell. A javítások telepítése, alkalmazások terítése is megoldandó feladat, mert jelen példában tulajdonképpen 1000 állandó munkaállomásunk lesz.
- instant clone VDI: Itt nincsenek állandó példányok. Szintén a Horizon hozza létre őket egy kópiából, előre vagy a felhasználó belépésekor, utóbbi esetben másodpercek alatt. Miután a felhasználó kilép, a használt gépe eltörlődik. Szóval ezek volatilis gépek.
- virtuális RDSH szerver: A Horizon Agent telepíthető RDSH szerverre is, szóval Horizon tud multisession opciót is.
- fizikai szerver RDSH: pont mint az előző.
- instant clone RDSH (nyilván virtuális): mint az instant clone VDI, de itt teljes RDSH kiszolgálókat is egy image-ből lehet kigörgetni.
- fizikai munkaállomás: A Horizon Agent telepíthető munkaállomásra is, ha például desktop gépei vannak a felhasználóinknak és home office-ba akarjuk őket engedni.
- alkalmazás prezentáció: nem a teljes asztal és munkamenet prezentált, csak egy-egy alkalmazás.
Korábban volt linked clone opció is – amihez kellett az úgynevezett Composer komponens is – de ez kikerült a lehetőségek közül, helyette az instant clone javasolt.
A VMware Horizon legfontosabb eleme a Horizon Connection Server. Mindenképpen kell legalább egy ilyen, mivel a Horizon szerver oldali komponense fut rajta. Ha több van az redundanciát és természetesen magasabb performanciát is jelent. Viszont egy ilyen csoport, legyen akármennyi is belőle, geográfiailag egy helyen kell legyen. Tehát nem támogatott az, hogy külön-külön adatközpontokban vannak ilyen Connection Server csoportok.
A problémát igazából a redundancia kiépítésével a felhasználói profilok és az általuk előállított adatok kezelése.
Hiszen mi kell egy boldog felhasználó számára?
- operációs rendszer
- alkalmazások
- profil
- dokumentumok
Az operációs rendszer rész az eléggé általános. Semmi felhasználóra specifikus nincs benne, mindenki számára azonos és nem változik percenként.
Az alkalmazások egy része nyilván kerülhet a master példányba, de természetesen használható olyan megoldás, ami alkalmazást vagy több alkalmazást a felhasználó jogosultságaitól vagy cél VDI példány valamilyen paraméterétől függően futáskor csatolódik be. App Volumes pont egy ilyen megoldás.
A profil a baj. Méghozzá azért, mert nem okoz felhasználói elégedettséged az, ha minden belépéskor újra be kell állítani az Outlook fiókot, ha silver-re kell állítani az Office témát, ha a tálca megint alul van és nem oldalt. Egy fizikai munkaállomásnál de még egy full clone-nál is a felhasználói élmény minden esetben állandó. Az instant clone-nál ezt meg kell oldani, mivel amint a felhasználó kilép, kis túlzással azonnal eltörlődik a gép amin dolgozott. Erre több megoldás van, kezdve a legrosszabbal, a méltán gyűlölt roaming profillal. Gyorsan szép nagyra hízhat és persze a belépés is nyúlhat súlyok percekre. Ha nem használjuk, akkor lehet VMware Dynamic Environment Manager – régen UEM – által kezelni, illetve a mostanság inkább javasolt Microsoft FSlogix is elképzelhető.
Cloud Pod Architecture
Ezt oldja fel a Cloud Pod Architecture, azaz egymástól némileg független Horizon Connection Server csoportok federációját. Egymás között kialakítanak olyan kapcsolatot, ami replikál bizonyos adatokat, pontosan azért, hogy ha valamelyik lokációt érint valamilyen probléma, akkor – és amennyiben be van állítva – akkor képes végfelhasználói VDI/RDSH munkameneteket biztosítani.
Ez az egyszerűbb része, mivel egy CPA-t beállítani körülbelül két perc.
Mindkét adatközpontban el kell végezni egy-egy Connection Server-en a beállítást, nyilván az egyiken inicializálni, a másikkal join-t kell elvégezni. Ezek után igazából a logikai összerendelések történnek, azaz kialakítandó a telephely, Horizon Pod összerendelés.
A telephelyek logikaiak, ahogyan a pod-ok is, szóval ez tényleg elég absztrakt.
És itt kezdődnek a bonyolultabb dolgok. Ha a felhasználó nincs site-hoz rendelve, akkor könnyen lehet, hogy bármelyik pod-ból kaphat munkamenetet. Sőt egyszerre akár két munkamenete is lehet, két különböző telephelyről. A munkamenet magában még nem probélma, de a profilja mindenképpen az. Ez az amit a Microsoft nagyon baráti módon meg is mond, hogy akármit trükköznénk az nem támogatott. A profil egy helyen lehet írható és lehet becsatolva.
Profilok
A profil-menedzsment kiválasztását egy kérdés előzi meg, mégpedig „Van-e FSlogix licenszelve?”. Általában van, mert félmillió subscription-ben benne van. Az FSlogix azért szuper mert alapértelmezetten mindent megőriz, míg a VMware DEM pedig pont az ellenkezőjét teszi, alapértelmezetten semmit sem őriz meg. Ráadásul az FSlogix ezt egy VHD/VHDX konténerben teszi, amit belépéskor becsatol a VM-be. Csak arról kell megbizonyosodni, hogy ez a felhasználónkénti egy – vagy kettő ha van office container is – legyen egy elérhető share-en. Ha van bármilyen telephelyek között szinkron replikált megosztás, akkor az tökéletes hely lehet erre, ha nincs akkor a Microsoft DFS tud lenni egy megoldás. Utóbbi esetben mindenképpen figyelni kell arra, hogy az a share amin a fájlok vannak, csak egy aktív referreal-al rendelkezzen, ezzel is elejét vége a duplikált becsatolásoknak. Nem támogatott és a korrupció esélye is jelentkezik ha mégis.
Alkalmazások
A master image-be égetett alkalmazások nyilván azon a körön kívül esnek, amelyeket kezelni kell a telephelyek relációjában is. Ha VMware App Volumes a termék erre, akkor valahogy replikálni szükséges azon csomagokat – vmdk fájlok – amelyekben az alkalmazások vannak. Erre van beépített megoldása az App Volumes rendszernek, méghozzá a „Storage group” bizonyos alkalmazásában.
Egy storage group több célra is használható:
- az alkalmazásokat tartalmazó VDMK fájlok terítése több datastore-on, amik mögött persze lehet más és más tároló is hogy a performancia skálázódjon.
- replikálni/importálni datastore-ok között a köteteket.
Tehát az egyik telephelyen egy ilyen storage group-ot létrehozva replikáljuk egy úgynevezett transport datastore-ra az App Volume-okat, majd a másik telephelyen egy másik storage group-ban importáljuk azokat az ott produktívan használni kívánt datastore-ra.
A fenti ábrán „clustered SQL” szerepel, ami azt is jelenti, hogy a képen látható négy App Volumes Manager igazából egy rendszerben működik. Minden entitlement globálissá válik, míg ha külön adatbázist használnának, akkor a felhasználói csoportokat a volume-okhoz kellene rendelni mindkét telephelyen – vagy szkriptelve szinkronizálgatni.
Az App Volumes szolgáltatja a writable volume-okat is, de azokat – valami megmagyarázhatatlan ok miatt – valami szkripttel vagy éppen olyan tárolóval kell replikálni.
Hogy lesz ez aktív/aktív?
Nemes egyszerűséggel a VMware dokumentációjában lévő aktív/passzív opciót duplikálom. A teljes felhasználói kört két egyenlő részre osztom és egy-egy csoportba rendezem. A CPA lehetővé teszi azt, hogy definiáljam a home site-ot a csoportokra, szóval máris el tudom küldeni az egyik felét az első telephelyre, a másikat a másik telephelyre, normál üzemben. Az adott csoport számára a profilok és home folder-ek azonos telephelyen aktívak, a másikon nem elérhetőek.
Tulajdonképpen a felhasználó számára továbbra is egy adatközpont működik, viszont az összes felhasználóra vizsgálva kettő. Amennyiben beüt a hiba és mondjuk teljes adatközpont esik ki, abban az esetben a túlélő telephelyen a CPA-ban a „Home site” override-ot be kell állítani a kiesett csoport számára, méghozzá a túlélő telephelyre. Persze ezt megelőzően a profil és home folder elemeiket aktiválni kell a túlélő telephelyen.
A fenti kiépítéssel, mindkettő telephelyen szolgáltatunk és hiba esetén össze lehet húzni egy telephelyre a terhelést, bár nyilván ez azt is jelenti, hogy egyiket sem szabad 50%-nál jobban kihasználni. Tehát hardware szempontjából nem spórol semmit, viszont hiba esetén csak a fele csoport érintett és nem a teljes, mint egy teljesen aktív/passzív kiépítésnél.
Jó projekt volt, főleg hogy a design kapcsán pozitív visszajelzést kaptam a VMware-től.
