Amióta partnernél dolgozom, azóta hallom újra és újra a gyártóktól az olyan mondásokat – amelyek inkább a wishful thinking kategóriába sorolandóak – hogy az idei valaminek az éve, például a VDI éve. Ezt már többször hallottam és valahogy soha nem jön el. Van olyan termék ami technológiailag hibátlan és mindenkinek legalább annyira jó lenne mint egy lottónyeremény, de valamiért sosem kerül oda a dolog, hogy ténylegesen implementációra is kerül.
A 2018-as és 2019-es ITBN-en valamilyen formában a „Zero trust” köré építettem az előadásaimat. Azóta ez a kifejezés már a csapból is folyik, akkor is amikor el van zárva. A távoli elérés a munkavállalók számára elengedhetetlen és amennyiben a vállalat csak felhős infrastrukúrával rendelkezik, abban az esetben lényegében majdnem kihívásoktól mentes ennek megvalósítása. Viszont ha csak egyetlen alkalmazás van, amelyet használni kell és nincs publikálva a publikus neten, akkor máris szükség van valamire, amivel a felhasználók azt el képesek érni.
Ilyenkor szóba jöhet:
- valamilyen VPN (per app, direct access stb)
- VDI/RDSH
A második amivel most foglalkozom. Alapvetően a teljesen automatizálható és a lehető legalacsonyabb számú komponensében kőbe vésett rendszereket szeretem. Lehetne szó Citrix-ről, de itt most Horizon-t fogok használni, méghozzá a 7.11-es verzióját. Ezzel fogok külső elérést biztosítani, például contractor kollégák számára, akkor ha a cégnél hagyja valaki a laptopját, nincs hordozható készüléke stb, mindezt úgy hogy elronthatatlan, eldobható virtuális gépekkel operálok.
Alább egy végleteg leegyszerűsített diagram, arról mire van legalább szükség egy ilyen megoldáshoz.
UAG
Kell egy Unified Access Gateway vagy egy Horizon Security Server. Én az előbbit javaslom, mivel utóbbi egy Windows-ra való telepítendő alkalmazás, illetve csak Horizon megoldással lehet használni. Ezzel szemben az UAG egy igazi svájci bicska, lehet belőle akár reverse proxy is, de VMware Airwatch számára is képes szolgáltatásokat nyújtani (per app és tunnel), illetve nem mellesleg egy appliance.
Horizon Connection Server
A belső hálózatban szükség van egy VMware Horizon View Connection Server-re, na és persze Horizon Agent-ekre is, amelyek akár virtuális gépekre akár a felhasználók irodai – asztali/hordozható – készülékeire is feltelepíthető. Nyilvánvalóan mind az UAG-ot, mind a Horizon Connection Server-t érdemes duplikálni az egyszeres hiba elleni védelem miatt.
Ez nagyszerű, de minden végfelhasználói munkaállomás igazi kihívása, azok menedzsmentje. Hogyan kerülnek telepítésre, hogyan vannak karbantartva, hogyan kerülnek rá a szükséges szoftverek, mi védi őket stb. Ezek nem kis kihívást jelentenek egy workplace services féle csapatnak, ezért az, hogy egy kialakítandó View környezetben ezeket a szüségleteket minimalizáljuk, elengedhetetlen.
Mielőtt elmerülünk, tisztázzuk mi a cél. Eldobható munkaállomásokat szeretnénk a felhasználóknak, minimális munka befektetése és erőforrás/tárkapacitás-használat mellett.
Egy Horizon környezetben alapvetően két fajta kiosztás választható:
- Manual pool: Itt nekünk kell a gépeket – legyenek azok VM vagy fizikai kiépítésűek – létrehozni.
- Automated pool: Ez pont az ellentéte. Nem zárja ki egyébként az olyan eseteket, ahol fizikai gépeket osztunk ki, mivel ha van egy csinos HPE Moonshot chassis ami tele van cartridge-el, akkor fizikai munkaállomásokról is lehet szó és mégis lehet Automated pool. Az ilyen pool jellemzője még, hogy a vCenter/Composer (adott esetben), hozza létre a szükséges virtuális gépeket.
Az összerendelés szerint is két mód van:
- Floating: Ebben a felhasználó-munkaállomás összerendelés nem végleges. Az akár belépésenként is változhat. Itt is lehet a kezdetek kezdetén felhasználót rendelni egy munkaállomáshoz, manuálisan, de alapvetően ez inkább „Automatic assignment” szokott lenni, így a Horizon dönti el melyik felhasználó, melyik gépre kap belépést.
- Dedicated: Pont az ellentéte a floating-nak. Explicit meg kell adni, ki melyik gépre kap hozzáférést. Ha egy felhasználó nincs géphez rendelve – de a pool-on van jogosultsága – akkor sem bír belépni egyetlen munkaállomásra sem.
Full/linked-/instant-clone?
Ha virtuális gép formátumról beszélünk, akkor ez a három íz van és körülbelül pont ez a sorrend akkor, ha a menedzsment időszükségletéről van szól, balról, a legtöbb időt igénylő full clone-tól a legkevesebbet igénylő instant clone irányába.
Full clone
Alapvetően létrehozáskor egy kopiából jön létre egy ilyen példány, de amint létrejön, teljesen függetlenné válik attól a VM-től, amiből származik. Ezáltal amint létrejött, menedzsmentre szorul és körülbelül úgy kezelendő – kis túlzással – mint egy asztali számítógép. Ebből származik a legnagyobb hátránya is, hogy azon kívül, hogy a felhasználó asztaláról „elhoztuk” a munkaállomást, mást nem értünk el, menedzsmenten sokat nem nyertünk – nyilvánvalóan legalább a mentést így megoldhatjuk, illetve magában az adatközpontban tudjuk a VM-et. A tárkapacitás szempontjából ez elég pazarló, mert ha 25 GB a base image és létrehozok 100 VM-et, akkor 2,5 TB-ot fog majd a datastore-on foglalni. A deduplikációs tárolók azért ezen kicsit enyhítenek, mivel bár a datastore rétegben 2,5 TB-ot foglal, de a tárolón ez jó eséllyel 25 GB-ot – persze előbb utóbb majd eltolódik a dedup arány negatív irányba. Minden amire szükség van, az egy template entitás a vCenter inventory-ban.
Sejthető, hogy mikor először lép be egy felhasználó és rákattint egy desktop-ra és történetesen az a pool automated pool, akkor lemásolódik a 25 GB, majd a gép beboot-ol, majd guest customization fut rá, bekerül a tartományba – ha szükség van rá – egyebek és utána be tud majd lépni rá a felhasználó. Ez legalább 5 perc, nem túl barátságos, de első belépésnél még tolerálható.
Linked-clone
Itt kell egy újabb VMware komponens, mert kell valami inteligencia ami kezeli az így létrehozott pool-okat és bennük a klónokat. Ez a komponens a Composer. Ez egy template snapshot-jából származtatja a klónokat, de oly módon, hogy az olvasásokat elsősorban az eredeti template-ból végzi és csak a változásokra leírására kap minden klón egy lemezre. Nyilvánvalóan minen példányosított virtuális gép osztozik az alaplemez(ek)en, ezért nem árt, ha valami gyors tárterületre kerül. A full clone-okkal szemben itt érezhető, hogy tárterületben sokkal-sokkal jobban bánik, illetve az is, hogy bármiféle olyan változás – Windows patch, alkalmazás, beállítás – központilag teríthető, ami annyit jelent, hogy a master template-ben megcsinája az admin a változást, majd egy snapshot létrehozása után, teríti a változást (recompose), ami a pool összes gépének ismételt és automatikus létrehozásával történik. Itt a linked-clone létrejöttekor szintén guest customization fut le, ami belépteti domain-be stb, de mivel nem kell megvárni hogy 25GB másolódjon le, sokkal gyorsabb mint a full clone.
Instant-clone
Az instant-clone az pedig maga a legjobb dolog a kerék óta. Nagyon hasonlít a linked-clone-ra, de nincs kell hozzá Composer. Szintén egy parent VM – nem template – amin kell egy snapshot. Mikor létrehozzuk a pool-t, akkor létrejön ebből egy replica VM és abból attól függően mennyi ESXi hosztot választunk ki a pool céljaként, létrejön azonnal a hosztok számával megegyező parent VM, amik RAM rezervációval rendelkeznek majd.
Ezekből a beboot-olt parentből „hasad” majd a példányosított VM, mikor a felhasználó belép. Itt nincs boot, a VM alapból már futó operációs rendszerrel jelenik meg és itt a View agent gyorsan domain-be lépteti és mehet is rá a felhasználó. Ez körülbelül 5-10 másodperc!
Felhasználói adat és profil
Természetesen nem szeretnénk, ha a felhasználóink minden alkalommal egy új kezdettel szembesülnének – van ilyen felhasználási eset is mondjuk – de alapvetően szeretnénk legalább a profiljuk egy részét állandóvá tenni. Dedicated full clone-ok esetén tárolható a VM-ben – mivel mindig azonos felhasználó lép majd be – floating/dedicated linked-clone-ok esetén pedig akár egy persistent disk-en, amely pedig a felhasználóhoz kötődik. Instant clone-ban pedig tényleg kell valami ami megoldja ezt, mert ott nincs ilyen persistent disk.
Itt a profilról beszélek, nem a felhasználó által használt és előállított tartalmakról. Ez utóbbi például az Asztal, Dokumentumok, Kedvencek, Képek stb tartalma. Ezeket gyakorta el kell érni a View rendszeren kívülről is, például ha a felhasználó rendelkezik egy laptop/asztali géppel és eseti jelleggel használja a View rendszert. Akkor nem baj, ha oda-vissza eléri a fájljait. Ezeket ezért javasolt átirányítani – Folder redirection – valamilyen share-re. A profiljával is megtehető ugyanez, de aki már kezdett roaming profile-al, az többé nem akarja használni.
Erre a VMware is rájött és van rá termék, ami többek között a profilok kezelését is függetleníti mindentől, a korábban UEM-ként, most DEM – Dynamic Environment Manager – névre hallgató megoldás.
Van még egy megoldás, de erről később…..
Alkalmazások
Alkalmazásokat a master image-be telepíteni nem egy előremutató megoldás, mivel minden változás az alkalmazásban, nagy feladatot ad a base image menedzsmentjére, mivel abban kell minden apró-nagyobb változtatást megtenni.
Erre a VMware-nek két megoldása van, a ThinApp és az App Volumes. Az utóbbival foglalkozom, mert sokkal szabadabb és használhatóbb mint a ThinApp. A ThinApp alapvetően az alkalmazások csomagszerű kialakítása mellett az izolációra való. Az App Volumes pedig ennél sokkal többre.
App Volumes
Nem csinál mást, mint teljes mértékben lehetővé teszi az alkalmazás függetlenítését az operációs rendszertől. Például elegendő egyetlen Windows 10 image, amiből a felhasználók kaphatnak View desktop-okat, viszont a felhasználók által látható/elérhető alkalmazások lehetnek igazán különbözőek, sőt mi több például egy master image-el képesek vagyunk kiszolgálni például az Office 2016-ot és Office 2019-et használó dolgozókat.
A varázslat nem igényel sok komponenst, csak kettőt:
- App Volumes appliance
- App Volumes agent a master image-ben, View gépben
A jobb oldalon látható AppStacks igazából egy VMDK, amelyben egy vagy több alkalmazás egybe van csomagolva. Vegyünk alapul egy Office telepítést, létrehozunk egy ilyen AppStack-et, majd kiadjuk a capture VM-nek – amiben természetesen ott van az App Volumes Agent. Mikor belépünk arra a gépre és feltelepítjük rá az alkalmazást, akkor az App Volumes minden módosítást a registry-ben, minden írást a Program Files alatt stb. eltárol abban a becsatolt VMDK-ban. Ha végeztünk, akkor lezárhatjuk ezt a capture-et és kiadhatjuk a a felhasználóknak (user vagy csoport) vagy számítógépnek.
Tehát mikor a felhasználó belép, akkor az az AppStack amihez jogosultsága van, becsatolódik abba a VM-be, amibe belép és mindent úgy fog látni/használni, mintha az alkalmazás ténylegesen telepítve lenne. Nem jelenik meg másik meghajtó, ott lesz minden a Start menüben is, fájl-hozzárendelések is léteznek majd, sőt ha például megnézi a Word parancsikont hová mutat, azt látja majd hogy a „C:\Program Files\…..” alá.
Writable volume
A fentebbi képen látható még egy érdekes rész, az pedig a Writable Volume. Ha valaki nem szeretne sem roaming profile-t, sem DEM-et használni, de mégis perzisztens profilt szerete adni a felhasználóknak, akkor a felhasználók számára az App Volumes képes egy úgynevezett Writable Volume-ot adni. Egy felhasználó számára több is adható, mert akár több operációs rendszert is használhatnak a View rendszerben a felhasználók és emiatt akár a profiljuk, akár az alkalmazások is változhatnak. Igen jól olvastad, három lehetőséget kínál, attól függően mit akarunk:
Az elsőben a felhasználói profilt kapja el csak a rendszer, ha a felhasználónak van joga és telepít valamit egy olyan View gépre ami nem perzisztens – pl floating linked-clone vagy instant-clone – akkor azt nem őrzi meg.
A második esetben viszont csak a telepítéseket őrzi meg, szóval ha újra belép a felhasználó és egy másik gépre kerül, akkor ott becsatolódik és minden telepítve lesz, amit ő maga telepített és nem mi adtuk neki az AppStack-ből.
A harmadik pedig a kettő előző metszete.
Nem győzöm eléggé hangsúlyozni azt, hogy a profilt lehet tárolni egy ilyen VMDK-ban, de az Asztal/Dokumentumok stb. tartalma a View rendszeren kívül elérhetetlen lesz, ezért ezeket még mindig javallott inkább átirányítani. Minden más mehet a Writatble Volume-ba, melynek mérete fentebb alapból 10GB, de módosítható. Ha kicsi lenne, akkor bővíthető, ha menteni kell akkor menthető és ha szükséges akkor visszaállítható.
Összefoglaló
A következő sorozatban egy ilyen Horizon View + App Volumes kombináció megépítését fogom bemutatni. Adott esetben NSX-T alá is bevonható a View és akkor tényleg egészen komoly hardening valósítható meg, no meg ha valamilyen agentless AV-t is teszünk mellé, akkor egy bolondbiztos és bothálózat mentes környezet alakul ki.
