Virtualizációs technikák, technológiák

A lap 2007. január 19., 14:24-kori változata

Alternatívák:

• adott sok-sok PC a salgó polcon: mindegyik valamelyik osztályé, tanszéké, haveré, ügyfélé stb.; vagy
• adott egy nagy szerver, ami "Sokmindent Csinál".

A sok PC esetében fellépő problémák:

• A Salgó Polcon Álló PC Nem Professzionális;

• ha a PC-k ósdiak, megbízhatatlanok, „gagyik”:
  • gyakran lefagynak - ilyenkor fizikai jelenlét szükséges az újraindításhoz;
  • meghibásodás esetén kereshetünk beléjük való „gagyi” hardvert;
  • papírfecnivel ki kell ékelni a processzorhűtőt;
  • poroltót kell tartani a közelben.

• ha újak, megbízhatóak, esetleg márkásak:
  • bonyolultabb és/vagy sokkal drágább lesz az alkatrészcsere, ha elromlanak;
  • „Ott Az A Szép Nagy Gép És Nem Is Csinál Semmit” szindróma, azaz gyakran kihasználatlanok az erőforrások;
  • sok áramot fogyasztanak;
  • sok hőt adnak le - megnövekedett hűtési (légkondícionáló) igények.

• ha a gépeket mások menedzselik:
  • a rendszergazdák folyton elfelejtik a rootjelszót, és mehetünk oda a konzolhoz betörni;
  • a rendszergazda lusta, dilettáns, rosszhiszemű és rosszindulatú;
  • emiatt viszonylag nehezen tudunk rendet tartani a hálózatban.

• ha mi menedzseljük őket:
  • akkor is problémás mindig odamenni a konzolhoz, amikor valamelyik gépnél probléma lép fel;
  • LOM (Lights Out Management) megoldás lehet erre, de elég drága.

Baj az egy nagy szerverrel, ami Sokmindent Csinál:

• az Ezen A Héten Divatos Projekt fejlesztőjének azonnal kell a még csak bétában elérhető PHP 8.0, de
• ennek lefordításához és futtatásához kell az új, szintén béta libc6, viszont
• a Múlt Héten Divatos És Még Mindig Fontos Projekt fejlesztői által írt alkalmazás az előző libc6 egy olyan "nemdokumentált funkcióját" használja ki, ami az új libc6-ban nincs benne; valamint
• kernelt is kell cserélni, mert a jelenlegiben túl régi az a NagyonTáposAPI, amit a szintén szükséges új Java is használ, de
• a Menedzsment Által Preferált Kereskedelmi Csoportmunka-Alkalmazás kizárólag a Sun Java 1.3.02 litván nyelvű változatának 1633-as buildjével működik helyesen.
• Rövidebben: a különböző funkciókhoz tartozó szoftverek között túl sok lehet az összefüggés, így az egyiknek az upgrade-je interferálhat egy másikkal.

1 Az elképzelt megoldás

• Legyen egy (vagy több, de kevés) nagyteljesítményű, rendkívül megbízható szerverünk, és
• ezeken külön virtuális szerverekben futtassuk az egyes kis PC-ket vagy a Sokmindent Csináló Gép egyes funkcióit.

Sok virtualizációs megoldás létezik, amelyek sokmindenben hasonlítanak, és meg több mindenben különböznek. Ezeket most nem részletezzük.

2 Virtualizációs technikák

Ez most az aktuális „buzzword”. A gyári 2.6.19-ben bizonyos előkészületek már lesznek a virtualizáció támogatására.

Addig is a legfontosabb megoldások:

2.1 Apache Virtualhost

• igazából max. viszonyítási alapnak illik ide

2.2 chroot

• csak fájlrendszer-szintű szétválasztás:
• a System V IPC közös, a két különböző chrootban azonos UID-del futó processzek küldhetnek egymásnak signalt stb.;
• egy chrootnak nem lehet saját IP-je, saját tűzfalszabályai;
• két chrootban ugyanolyan UID alatt futó processzek küldhetnek egymásnak signalt stb.
• nem igazán lehet egy-egy chroot erőforrásfoglalását korlátozni.
  • nincs diszk-kvóta;
  • nem méltányos az osztozkodás a CPU-n, a hálózaton, a diszken;
  • live migrációról pedig ne is álmodjunk.

• a FreeBSD jailje biztosít hálózati leválasztást, tehát a jailben futó alkalmazásnak lehet saját IP-je

2.3 vserver

• Olyan mint a chroot, csak jobb.
• Minden virtuális gép ugyanazon a kernelen fut.
  • Minimális overhead, úgyhogy gyors.
  • Pl. az összes vserver osztozik a diszk-cache-en.
  • Cserébe ha borul a kernel, az egész rendszer borul.
• A vservereket logikailag teljesen szétválasztja egymástól:
  • IPC,
  • processzkezelés,
  • saját IP.
• Viszont: nem lehet fájlrendszereket mountolni a guestben, és
• a host automatikusan hozzáfér a guest összes adatához.
• Elvileg változtatás nélkül elindul vserverben a legtöbb Linux-disztribúció.
• Egyáltalán nincs szükség emulációra
• Még olyan eszköz is van, ami megkeresi több guestben az azonos tartalmú fájlokat, és összehardlinkeli őket; de ha valamelyik írna bele, megszűnik a hardlink.
• Ehhez persze a vservereknek egy fájlrendszeren kell lenniük (de elvileg van vserver-szintű diszk-kvóta, úgyhogy annyira nem baj).
• Megadhatunk egy-egy vserverre vonatkozó erőforráslimiteket.
• Egy vserver migrálása nagyon egyszerű: tar.
• A vserver hálózati konfigurációját a hoszt állítja be, úgyhogy a migráció tényleg teljesen átlátszó a vserver számára.
• De: még mindig nem tudunk saját tűzfalszabályokat adni a virtuális gépeknek, és nem csinálhatunk komplex virtuális routingot sem.
• Sajnos patchelni kell a kernelt.
• Nincs IPv6-támogatás.

Ilyesmi lehet a FreeVPS és az OpenVZ is. Házi feladat. :)

Kedvcsinálónak:

2.4 OpenVZ

• Olyasmi, mint a vserver (egy kernelen fut az összes virtuális gép).
• De pl. a VE-knek (Virtual Environment) lehet saját routingja és tűzfala.
• A PID-kat virtualizálja, így az init mindig megkapja az 1-est.
• Virtualizálja a /proc és a /sys fájlrendszereket is (a vserver csak részben - konkrétumok?).
• A VE-k megkaphatnak valódi hardvert, pl. sorosportot, hálózati interfészt.
• A VE-k erőforráskorlátai menet közben növelhetők és csökkenthetők(!).
• A CPU-t méltányosan ütemezi az egyes VE-k között.
• Checkpointing segítségével egy élő VE migrálható fizikai gépek között.
• Külön eszközzel támogatja az új VE fájlrendszerének létrehozását.
• Egy közepes PC 1G RAM-mal akár 100 VE-t is gond nélkül futtathat (mindegyikben apache-csal és sshd-vel).
• x86, amd64, ia64, ppc

2.5 User Mode Linux

• Egy linuxos hoszton több guest kernelt futtathatunk, mindegyik kisszámú userspace processznek látszik.
• Viszonylag gyors (CPU-korlátos műveletek esetén közel natív teljesítmény, I/O esetén jelentősen lassúbb).
• Minden guest-rendszerhívást emulálni kell.
• A hardver kezelését a hoszt kernel végzi, a guest kernel csak hardver-absztrakciókkal találkozik.
• Természetesen minden guestnek saját, korlátos memóriája van, de használhat saját swapet.
• A guestek:
  • saját tűzfalszabályokat állíthatnak be
  • szabadon mountolhatnak fájlrendszereket (persze csak azok közül, amikhez hozzáférnek)
  • egyszerűen kaphatnak közvetlen hozzáférést fizikai diszkhez vagy LV-hez, amin aztán olyan fájlrendszert hoznak létre, amilyet csak akarnak.
• Az UML elvileg titkosíthatja a saját fájlrendszerét úgy, hogy a hosztgép üzemeltetője ne tudja elolvasni (kivéve a rootfs-t).
• A hosztgépen debugolhatjuk a guest kernelt (ha kernelfejlesztők vagyunk).
• Elvileg az UML hibája miatt nem fagyhat szét a hosztgép kernele.
• Nem (feltétlenül) szükséges hozzá kernelt patchelni (legalábbis ezen a héten).
• Nem szükséges annyi fizikai memóriával rendelkezni, amennyit elosztogatunk a guestek között (használhatnak swapet).
• 64 bites hoszton futtathatunk 32 bites guestet (a Xen pl. ezt nem tudja).
• Bonyolult virtuális hálózati topológiákba szervezhetjük az UML-eket anélkül, hogy a valódi hálózatra kilátnának.
• Egy vendéggép konzolját kirakhatjuk egy tcp portra, így elérhetővé válik a hálózatról anélkül, hogy neki magának lenne hálózati kapcsolata (a TCP-kapcsolat a hoszttal épül fel).
• Eleinte a guestben gyakorlatilag nem volt memóriavédelem, mivel a hosztkernel szempontjából egyetlen processz volt az egész (ez ma már szerencsére nem igaz).
• x86, IA64, PowerPC, Sparc?

2.6 Xen

• „Paravirtualizáció” (de most már tud hardvereset is: Vanderpool, Pacifica)
• Hypervisor, Dom0, DomU
• A Xen virtuális gépei idővel futni fognak a Longhorn hypervisora alatt is.
• Hardveres virtualizációval fut benne a Windows XP is.
• Tud live migrációt: apránként átmásolja a domU-t egy másik gépre, majd 1 másodpercnél rövidebb idő alatt átkapcsol rá.
• x86, amd64, ia64, ppc; Sparc készülőben
• dom0-ban lehet: Linux, NetBSD (hamarosan FreeBSD is).
• paravirtualizált domU-ban lehet: Linux, NetBSD, FreeBSD, Minix, Plan9, OpenSolaris, NetWare
• Létezik paravirtualizált Windows XP is, csak a licencfeltételek miatt nem adhatja ki a University of Cambridge.
• Később lesz róla szó részletesebben is.

Szalai Ferenc előadásának fóliái

3 Virtualizációs technikák csoportositasa

(Írta: NSzabolcs)

3.1 Emuláció

• teljes hardver architektúra emuláció
• emulált processzor lehet eltérő a host cpu-tól
• guest OS-t nem kell módositani
• x86: Boch, Qemu (gyorsítás nélküli)

3.2 Full/Native virtualizáció

• hardver architektúra emuláció, de kihasználja, hogy a host géppel azonosat emulál
• csak ugyanolyan processzort tud emulálni, mint amin a host van
• guest OS-t nem kell módositani
• több guest is lehet
• x86: KVM, VMWare (Iron, Workstation, Server)

3.3 Paravirtualizáció

• nem feltétlen emulál, hanem speciális API-n keresztül éri el a guest a hardvert
• guest OS-t módositani kell
• x86: Xen
• x86, IA-64, PPC: UML (csak Linux)

3.4 OS-level virtualizáció

• a guest és host OS kernel ugyanaz, guestek szeparálva vannak a hosttól
• kis overhead
• unix: chroot
• Linux: vserver, OpenVZ
• FreeBSD: jail
• Wikipedia - OS-level virtualization

3.5 Virtual hosting

• ugyanazon a fizikai szerveren egy web szerver több különböző domain név alatt nyújt különböző szolgáltatásokat
• lehet name-based vagy IP-based
• pl: Apache Virtualhost

4 Ajánlott irodalom

• Nem ajánlott: Projects on the move, ismeretterjesztő cikk többek között a virtualizációs technikákról. Óvatosan olvassátok, vannak benne marhaságok (pl. "As each VServer has its own init process, it can launch services with their own IP addresses." - nem igaz, igaz, nincs összefüggés). Azért szerepel itt, mert a google esetleg kidobja, mint találatot.
• Egy thread a debian-administration.org fórumán a virtualizációs technikákról.
• Annotated HOWTO for creating an SELinux enabled UML system - szakácskönyv.
• Comparison of virtual machines
• ZAP - userspace-ben megvalósított processz-migráció Linuxra