Virtualizáció – Központi menedzsment

1. Intelligens rendszerfelügyelet Virtualizáció – Központi menedzsment Tóth Dániel

2. Az előző részek tartalmából • Virtualizáció fogalma, alapvető megvalósításai • A platform virtualizáció megvalósítási lehetőségei • Az operációs rendszer szintű virtualizáció • A szerver virtualizáció különleges követelményei • … és ami most jön: • A szerver virtualizáció központi menedzsmentje • A szerver virtualizáció szolgáltatásainak kiterjesztése

3. A szerver virtualizáció követelményei • Jellegzetességek • Távoli elérés központi szerepe • Cél.: Hálózaton nyújtott szolgáltatások ellátása (ez akár távoli asztal is lehet! -> Desktop virtualizáció) • Erőforrás gazdálkodás • Központi menedzsment fontossága

4. VirtualCenter • A VMwareVirtualCenter lesz a futó példa, mostantól kezdve ezen mutatunk be mindent VirtualCenter Server Consolidated backup Update Manager MS SQL Win Server 2003 ESX Server ESX Server ESXi Server

5. Távoli elérés • Protokoll • Vezérlés: • saját WebService alapú távoli API (van hozzá wsdl is a VI SDK-ban, ~1500 classból áll) • HTTPS felett (biztosít: autentikációt, bizalmas és sértetlen csatornát) • Az ESX, ESXi és a VirtualCenter is ugyanazt a protokollt használja • Ezen kívül újabban van WS-Man (DMTF SMASH ajánlás alapján) • Konzol hozzáférés: • MKS protokoll • Ez valójában egy saját wrapperbe becsomagolt VNC • A wrapper biztosít autentikációt, bizalmas és sértetlen csatornát

6. Távoli elérés • Szervereknél fontos a hozzáférés kezelés • A virtuális szerver konzol távoli elérése = „fizikai” hozzáférés a virtuális géphez • Két fontos részfeladat: • felhasználókezelés, autentikáció • engedélyezés, autorizáció • A virtuális gépekhez felhasználók rendelhetőek • Megadható, hogy milyen műveletet végezhetnek… • Milyen műveletek vannak? • Sok gép esetén valamilyen módon kezelhetővé kell tenni…

7. Távoli elérés • Jogosultsági modell • Felhasználókezelés -> ActiveDirectory • Ez azt jelenti, hogy csoportok is vannak, amiknek lehetnek csoportok tagjai (RBAC megvalósítható) • Hierarchikus fa szerkezetbe szervezett erőforrások (VM, ResourcePool…) • Örökölhető engedélyek • Hozzáférési maszk 142-féle műveletet definiál • Hoszt konfiguráció, VM konfiguráció, adattárak, stb…

8. A szerver virtualizáció követelményei • Jellegzetességek • Távoli elérés központi szerepe • Cél.: Hálózaton nyújtott szolgáltatások ellátása (ez akár távoli asztal is lehet! -> Desktop virtualizáció) • Erőforrás gazdálkodás • Központi menedzsment fontossága

9. Virtuális hálózat • Csak bridge-elt és host-only módot támogat • Ha NAT kell, akkor azt saját VM-ben kell megoldanunk • Elnevezett hálózatok • 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ő • Akár redundánsan is

10. A szerver virtualizáció követelményei • Jellegzetességek • Távoli elérés központi szerepe • Cél.: Hálózaton nyújtott szolgáltatások ellátása (ez akár távoli asztal is lehet! -> Desktop virtualizáció) • Erőforrás gazdálkodás • Központi menedzsment fontossága

11. Erőforrás gazdálkodás • Figyeljünk • Hoszt erőforrások monitorozása • Guesterőforráshasználat monitorozása • Riasztások • Korlátozzunk • Minimum garantált és maximum határok • Ezen belül foglalási prioritások • VM-re vagy erőforráscsoportra vonatkozhat • Az erőforráscsoportok hierarchikusan egymásba ágyazhatóak

12. Korlátozások beállítása CPU affinitás: virtuális gépek hozzákötése 1-1 fizikai CPU-hoz

13. Erőforrás gazdálkodás • A CPU kihasználtságot MHz-ben méri • Ez így jó/nem jó? • A memória használatnál külön van granted, allocated, active, shared, swapped stb. • Az aktív memóriánál a guest által ténylegesen használt memórialapokat számolja • Memória ballonozást, swappelést figyelemmel kísérhetjük • Disk I/O, áteresztés, parancsok száma • Van latency is! Mire jó? • Hálózat, áteresztés

14. Fura jelenségek 1. Betelt a memória… kb. 10:30-kor CPU használat visszaesett… Miért?

15. Fura jelenségek 1. Betelt a memória… kb. 10:30-kor DE a diszk áteresztőképesség is visszaesett… Miért?

16. Fura jelenségek 2. VM1 CPU terhelve Max. 2660MHz Magyarázat: CPU cache kiszorítás (cache contention) Ezért rossz az OS ütemező, mint teljesítménymérő… A két időfüggvény gyanúsan hasonló, bár teljesen más skálán. Ezt semmi nem indokolná… vagy mégis? VM2 CPU Végig terheletlen Max. 220MHz

17. Az előző részek tartalmából • Virtualizáció fogalma, alapvető megvalósításai • A platform virtualizáció megvalósítási lehetőségei • Az operációs rendszer szintű virtualizáció • A szerver virtualizáció különleges követelményei • … és ami most jön: • A szerver virtualizáció központi menedzsmentje • A szerver virtualizáció szolgáltatásainak kiterjesztése

18. Központi menedzsment motivációs példa • Az egyik nagy magyarországi bankban… • 80db ESX hoszt • 400 - 1000db közötti virtuális gép • Két fő telephely • Egy üzemeltetési rémálom… • … lenne megfelelő központi menedzsment nélkül • Agilitás • Konszolidáció • Közelítőleg megvan a 10:1 arány

19. Központi menedzsment • VirtualCenter • Több ESX hosztot kezelhetünk egy felületről • Historikus adatgyűjtés az összes hosztról, guestről • Konfigurációs térkép (host, guest, hálózat, adattár) • Jellegzetesség: központi háttértár kezelés • 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ó”)

20. Központi menedzsment • Ha csak ennyit tudna, azzal még sokat nem érnénk… • Új szolgáltatások • Hosztok fürtbe szervezése (Cluster) • Virtuális gépek áthelyezése hosztok között • …akár működés közben (live migráció) • Hibatűrés • Terheléselosztás

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

22. Virtuális gépek áthelyezése • VMware úgy hívja VMotion (van pl. XenMotion is) • Cél a kiesési idő minimalizálása • Kissé terhelt gépen 2-3 sec marad ki • DE ha sok az aktív memórialap, akkor sokkal hosszabb is lehet! • Alapesetben a háttértár SAN-on van, közösen látható mindkét hosztról • Létezik háttértárat mozgató megoldás is (Storage VMotion), működési elve megegyezik a memóriamozgatáséval Mi a követelmény egy olyan fájlrendszerrel szemben, amit blokkos eszköz szinten egyszerre több helyről is módosítanak?

23. Hibatűrő fürtök • Ha egy hoszt kiesik… • Sok virtuális gépet vihet magával • Memóriatartalom elveszik… • de ha a háttértár megvan, akkor más hoszton újra lehet indítani • VMware HA Cluster ezt csinálja • VirtualCenter csak a konfiguráláshoz kell, egyébként elosztott működés az ágensek között Fontos tanulság: Ez nem „csodaszer”, egyéb alkalmazás szintű hibatűrési mechanizmusok kiegészítő technológiájaként kell rá tekinteni! Heartbeat jelek Guest HA agent HA agent Guest ESX ESX HDD ====

24. Terheléselosztás • Ha van sok hoszt gépünk, kezeljük az erőforrásaikat egy nagy poolként • Minden hosztnak azonos adattárakat és hálózatokat kell látnia • Nem feltétlen kell, hogy hardveresen egyformák legyenek a hosztok, de célszerű (miért is?) • Hagyjuk, hogy a menedzsment szerver automatikusan ossza szét a virtuális gépeket a hosztok között • Lehetséges manuális vagy félautomata megoldás • Lehetnek különböző optimalizálási szempontok • CPU terhelés legyen egyenletes a hosztok között • Memóriafoglalás legyen egyenletes a hosztok között • Vagy éppen ellenkezőleg: minél kevesebb hoszt működjön („greencomputing”) • Ez sem „csodaszer”: • - Egy virtuális gépet nem fog tudni szészórni egynél több hosztra. • Nem helyettesíti az alkalmazás szintű terheléselosztó rendszereket • MagasszintűQoS metrikákra nem tud szabályozni

25. Virtuális gépek automatikus üzembeállítása • Motivációs példa Kéne egy virtuális gép nekem Win2008 Server-rel! 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!

26. Virtuális gépek automatikus üzembeállítása • Megoldás: • Készítsünk alap virtuális gépeket alap OS telepítéssel és azt másoljuk le, amikor kell • Mi ezzel a baj? • Testreszabás (IP cím, hosztnév, UUID, SID stb.) • Licenszkérdések • Túl sok manuális lépés • Vezessünk be „sablon” (template) fogalmat • 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 bele kell konfigurálni a gépbe. Mi kell ehhez? • Ágens  (pl.: VMwareTools)

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

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

29. Összefoglalás • Virtualizáció fogalma, alapvető megvalósításai • A platform virtualizáció megvalósítási lehetőségei • 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