1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Virtualizáció – Központi menedzsment Micskei Zoltán, Tóth.

Az előadások a következő témára: "1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Virtualizáció – Központi menedzsment Micskei Zoltán, Tóth."— Előadás másolata:

1 1 Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Virtualizáció – Központi menedzsment Micskei Zoltán, Tóth Dániel Intelligens rendszerfelügyelet

2 2 Tartalom  Központi menedzsment – alap infrastruktúra o Menedzsment szerver o Hozzáférés-kezelés o Közös hálózat, tárhely  Erőforrás-gazdálkodás o Allokációs problémák o Terheléselosztás fizikai gépek között  Hibatűrés o Különféle hibamódok o Védekezési lehetőségek a meghibásodások ellen  Virtuális gépek életciklusa o Sablonok o Automatikus életciklus kezelés

3 3 Központi menedzsment motivációs példa  Ipari esettanulmány banki környezetből o 80db ESX gép o 400 - 1000db közötti virtuális gép o Két fő telephely o Egy üzemeltetési rémálom… o … lenne megfelelő központi menedzsment nélkül - Agilitás - Konszolidáció - Közelítőleg megvan a 10:1 arány - Agilitás - Konszolidáció - Közelítőleg megvan a 10:1 arány

4 4 (Központi) menedzsment szerver  Virtualizációt nyújtó gépek összefogása o Akár több gyártó megoldását is  Közös leltár és térkép o Fizikai/virtuális gépek, hálózat, felhasználók… o Historikus adatok gyűjtése is  Plusz funkciók  Pl.: VMware vCenter, MS SCVMM, XenServer…

5 5 DEMO  A VMware vCenter lesz a futó példa, mostantól kezdve ezen mutatunk be mindent vCenter ESX Server ESXi Server Windows Server vCenter Server Update Manager Egyéb plug-in RDBMS

6 6 Távoli elérés – Protokoll  Vezérlés: o saját WebService alapú távoli API (van hozzá WSDL is a VI SDK-ban, ~1500 osztályból áll) o HTTPS felett biztosít: hitelesítés, bizalmas és sértetlen csatornát o Az ESXi és a vCenter is ugyanazt a protokollt használja o Ezen kívül újabban van WS-Mananagement (DMTF SMASH ajánlás alapján)  Konzol hozzáférés: o MKS protokoll o Ez valójában egy saját wrapperbe becsomagolt VNC o A wrapper biztosít hitelesítést, bizalmas és sértetlen csatornát

7 7 Felhasználó- és jogosultságkezelés  Felhasználókezelés o Active Directory o Ez azt jelenti, hogy csoportok is vannak, amiknek lehetnek csoportok tagjai (RBAC megvalósítható)  Jogosultsági modell o Hierarchikus fa szerkezetbe szervezett erőforrások (VM, Resource Pool…) o Örökölhető engedélyek o Hozzáférési maszk 142-féle műveletet definiál (v3.5) Hoszt konfiguráció, VM konfiguráció, adattárak, stb.

8 8 Virtuális hálózat  Virtuális switch-ek, elnevezett hálózatok  Csak bridge-elt és host-only módot támogat o Ha NAT kell, akkor azt saját VM-ben kell megoldanunk  Virtuális switch-hez rendelhetőek a VM-ek és a Service Console, VMkernel hálózati interfészei is  Virtuális switch-hez fizikai hálózati kapcsolat rendelhető o Akár redundánsan is

9 9 Közös tárhely  Az adatokat lokális diszk helyett SAN-on tároljuk  Többszörös hozzáférési lehetőség  Dinamikus allokáció  Alacsonyabb fajlagos költségek  Egy bizonyos méret fölött virtualizáció nélkül is megjelenik ez a megoldás (aka. „Tárhely virtualizáció”)  Tipikus protokollok: FC, iSCSI, NFS…

10 10 Központi menedzsment  Ha csak ennyit tudna, azzal még sokat nem érnénk…  Új szolgáltatások o Gépek fürtbe szervezése (Cluster) o Virtuális gépek áthelyezése gépek között o …akár működés közben (live migration) o Hibatűrés o Terheléselosztás o …

11 11 Tartalom  Központi menedzsment – alap infrastruktúra o Menedzsment szerver o Hozzáférés-kezelés o Közös hálózat, tárhely  Erőforrás-gazdálkodás o Allokációs problémák o Terheléselosztás fizikai gépek között  Hibatűrés o Különféle hibamódok o Védekezési lehetőségek a meghibásodások ellen  Virtuális gépek életciklusa o Sablonok o Automatikus életciklus kezelés

12 12 Erőforrás gazdálkodás  Allokációs probléma (pl. memória foglalás szerint) Host1Host2 Guest1 Guest2Guest3 Guest4 Hogyan osszam szét őket?

13 13 Erőforrás gazdálkodás  Manuálisan nehéz feladat o Főleg sok fizikai és virtuális gép esetén problémás o Menet közben is változhat az erőforrás foglalás (főleg CPU, de memória esetén is) o Többféle optimalizálási cél is lehet Hosztok egyenletes terhelése (VM teljesítményét maximalizálni) Minimális számú hoszt használata (energiatakarékosság)  VMware DRS (Distributed Resource Scheduling) o Fürtökbe fog sok ESX/ESXi gépet o Automatikusan vagy félautomatikusan osztja szét a VM- eket a fizikai gépek között o Menet közben a változó terhelésekre állítható gyorsasággal reagálva is változtathatja a hozzárendelést hogyan lehetséges ez?

14 14 Virtuális gépek áthelyezése futás közben  Ismertebb nevén: live migration  Különböző gyártók elnevezései o VMware – VMotion o XenEnterprise – XenMotion o VirtualBox - Teleportation  Cél a kiesési idő minimalizálása o Kissé terhelt gépen 2-3 sec marad ki DE ha sok az aktív memórialap, akkor hosszabb is lehet! o Alapesetben a háttértár SAN-on van, közösen látható mindkét gépről Mi a követelmény egy olyan fájlrendszerrel szemben, amit blokkos eszköz szinten egyszerre több helyről is módosítanak?

15 15 Virtuális gépek áthelyezése  Hogy is működik? Guest CPU állapota RAM > Guest CPU állapota RAM > Memóriatartalom módosul közben! Memóriatartalom módosul közben! másolás Már átvitt, de azóta módosult memórialapok gyűjtése Éppen használatban lévő, aktív memórialapok átvitele A virtuális gép mostantól kezdve fut a másik hoszton, a hálózati kapcsolatot is átvette A módosult, de éppen inaktív memórialapok utólagos átvitele Erőforrás felszabadítás

16 16 Tartalom  Központi menedzsment – alap infrastruktúra o Menedzsment szerver o Hozzáférés-kezelés o Közös hálózat, tárhely  Erőforrás-gazdálkodás o Allokációs problémák o Terheléselosztás fizikai gépek között  Hibatűrés o Különféle hibamódok o Védekezési lehetőségek a meghibásodások ellen  Virtuális gépek életciklusa o Sablonok o Automatikus életciklus kezelés

17 17 Hibatűrés  Hibatűrés célja: o Szolgáltatás nyújtása meghibásodás esetén o Komplex feladat  Első lépés: o Hibatípusok azonosítása o Mindegyikhez megfelelő védekezés kitalálása

18 18 Példák szolgáltatás-kiesésekre HW OS Alkalmazás -HW alkatrész meghibásodik -Hálózat kiesés -Tápellátás megszűnik -OS crash Környezet / emberek -Alkalmazás leáll -Adatok inkonzisztenssé válnak -Hibás üzemeltetői tevékenység -Támadás -Elemi kár Nem tervezett Tervezett - OS frissítés miatt újraindítás kell -HW-t karban kell tartani - Alkalmazás verzióváltás

19 19 HW hiba kezelése – klasszikus eset  Hiba elfedése o Redundancia (2. táp, RAID, több hálózati út…)  Ha nem sikerül gép szinten elfedni o Pl.: feladatátvételi fürtök Szolgáltatás átvétele Tervezett leállásra is jó Rövid kiesés van ……

20 20 HW hibák kezelése – virtualizáció  Problémák virtualizáció esetén: o A fizikai gépen futó összes VM memória és CPU állapotát elveszítjük -> VM leállási hiba o Egy HW hiba esetén SOK virtuális gép hibásodik meg o Live migration „azellen nemvéd”, csak a tervezett leállások előtt lehet leköltöztetni a VM-eket egy fizikai gépről

21 21 HW hibák kezelése – virtualizáció  Ha a VM háttértára hozzáférhető marad, akkor újraindíthatjuk másik hoszton (pl. VMware HA)  Tulajdonképpen egy speciális feladatátvételi fürt  „Host clustering” (vö. guest clustering)

22 22 HW hibák kezelése – klasszikus eset 2.  Futási állapot elvesztés kivédése o Checkpointing rendszeresen állapotmentést készítünk, leállás után a legutóbbi ép állapotmentést visszatöltjük Alkalmazás szintű megoldás! Pl. SA Forum Checkpoint APISA Forum Checkpoint API o Lockstep (pl. Stratus ftServer)

23 23 HW hibák kezelése – virtualizáció 2.  Többszörözött futtatás több hoszton (lockstep) o Azonos VM több példánya több hoszton. Több példány = azonos memóriatartalom és CPU állapot! o Egy példány „elsődleges”, ez kommunikál a hálózaton o A többi példány „tartalék”, ezek kívülről nem megfigyelhető módon (kis késletetéssel) követik az első állapotát o Előny: külső megfigyelők nem veszik észre a váltást o Hátrány: teljesítményvesztés, költséges (több példány) o Nem véd: VM szoftverhibája ellen – minden példány egyformán bele fog futni ugyanabba a hibába

24 24 Többszörözött futtatás megvalósítása  Megvalósítás (VMware FT, Xen Remus)  Van egy elsődleges és egy tartalék VM példány o A tartalék kicsit lemaradva követi az elsődlegest o Az elsődlegesnél rögzít minden eseményt időbélyeggel és teljes CPU állapot mentéssel (lásd: Record/Replay) o Továbbítja a tartalék felé, ahol időhelyesen, CPU állapotot mindig beállítva visszajátssza o Kimenő hálózati forgalmat (vagy bármi kívülről megfigyelhető állapotváltozást) visszatart az elsődlegesen, amíg a tartalék nem jelez vissza, hogy odaért – Miért kell ez? Host Guest FT agent Host Guest FT agent Elsődleges Tartalék További részletek: Szolgáltatásbiztonságra tervezés (VIMIM146), MSc szakirány

25 25 Technikák összefoglalása HW OS Alkalmazás -HW alkatrész meghibásodik -Hálózat kiesés -Tápellátás megszűnik -OS hiba Környezet / emberek -Alkalmazás leáll -Adatok inkonzisztenssé válnak -Hibás üzemeltetői tevékenység -Támadás -Elemi kár Nem tervezett Tervezett - OS frissítés miatt újraindítás kell -HW-t karban kell tartani - Alkalmazás verzióváltás Live migration -Host clustering -FT (lockstepping) -Host clustering -FT (lockstepping) Eddig képesek a virtualizációs rendszer szintű megoldások kezelni a meghibásodásokat! -guest clustering -load balance fürt… -guest clustering -load balance fürt… -checkpointing -replikáció… -checkpointing -replikáció… -mentés -több telephely… -mentés -több telephely…

26 26 Tartalom  Központi menedzsment – alap infrastruktúra o Menedzsment szerver o Hozzáférés-kezelés o Közös hálózat, tárhely  Erőforrás-gazdálkodás o Allokációs problémák o Terheléselosztás fizikai gépek között  Hibatűrés o Különféle hibamódok o Védekezési lehetőségek a meghibásodások ellen  Virtuális gépek életciklusa o Sablonok o Automatikus életciklus kezelés

27 27 Virtuális gépek életciklusa  Életciklus - a virtuális gép létének állapotai a létrehozástól az üzemeltetésen keresztül a visszavonásig Létrehozás (creation) Létrehozás (creation) Üzembeállítás (deployment) Üzembeállítás (deployment) Üzemeltetés (operation) Üzemeltetés (operation) Üzemen kívül helyezés Visszavonás (retirement) Visszavonás (retirement) Mi a különbség a létrehozás és üzembeállítás között? Mi a különbség az üzemen kívül helyezés és visszavonás között?

28 28 Virtuális gépek üzembeállítása  Motivációs példa Kéne egy virtuális gép nekem Win2008 Serverrel! Tessék itt a gép, telepítsd bele a Windowst! Persze aztán állítsd ám be JÓL! De miért Én telepítsem? Nem értek hozzá, hogy kell JÓL beállítani. Meg nem is érek rá, nekem most kéne!

29 29 Virtuális gépek üzembeállítása  Megoldás: o Készítsünk alap virtuális gépeket alap OS telepítéssel és azt másoljuk le, amikor kell o Mi ezzel a baj? Testreszabás (IP cím, gépnév, UUID, SID stb.) Licensz kérdések Túl sok manuális lépés o Vezessük be a „sablon” (template) fogalmát Olyan, mint egy sima virtuális gép, csak fel van készítve rá, hogy automatikusan üzembeállítható legyen Az üzembeállításhoz konfigurálni kell a vendég OS-t. Mi kell ehhez? – Operációs rendszer specifikus ágens (pl.: VMware Tools)

30 30 Virtuális gépek automatikus üzembeállítása  Miért álljunk meg az operációs rendszer szintjén? o Lehet kész sablonunk a telepített alkalmazásokkal is o Az automatikus konfigurálása (még) nem teljesen megoldott  Nekünk kell a sablonokat elkészíteni? o Nagyvállalati környezetben belefér o Elérhetőek Virtual Appliance-ek, készre telepített gépek, egy specifikus alkalmazás ellátására o Vannak csoportos „Appliance Team”-ek is Pl.: 3 rétegű webes alkalmazásszerver 3 VM-ből egy csomagban készre telepítve VMware vApp (bővebben: http://blogs.vmware.com/vapp/ )http://blogs.vmware.com/vapp/ VMware Studio alkalmazással készíthetők

31 31 „Újhullámos” infrastruktúramenedzsment  Egy virtuális gép mostantól kezdve egy építőelem o (FRU - Field Replacable Unit) o Szükség esetén példányosítható sablonból o Feladata végeztével eldobható  Virtual appliance-ekből összeépíthető a teljes infrastruktúra o Anélkül, hogy alkalmazás telepítéssel, konfigurálással bajlódni kéne o Konfigurációmenedzsment problémáját is meg lehet oldani ezen a szinten  Ez az egész MOST kezdődik igazán az iparban!

32 32 Példa: VMware LabManager  Automatikus életciklus kezelés - Miért jó ez? o Felhasználó is elvégezheti saját magának o Szabályokkal korlátozható a felhasználók VM használata (pl. lejárati idő, nem használt VM-ek leállítása stb.)  Appliance-ek használata o Pl.: a LabManager a virtuális hálózatok közötti átjárást egy-egy kis Linux alapú NAT appliance-szel oldja meg  UPDATE: „private cloud” megoldás  lásd később

33 33 Összefoglalás  Virtualizáció fogalma, alapvető megvalósításai  A platform virtualizáció desktopon és szerveren  Az operációs rendszer szintű virtualizáció  A szerver virtualizáció különleges követelményei  A szerver virtualizáció központi menedzsmentje  A szerver virtualizáció szolgáltatásainak kiterjesztése, hibatűrés, terheléselosztás  Virtuális gép sablonok és appliance-ek