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

Mikor hasznos:

• adott sok-sok PC a salgó polcon: mindegyik valamelyik osztályé, tanszéké, haveré, ügyfélé stb.; vagy
• adott egy (vagy néhány) 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 gagyik:
  • gyakran lefagynak - ilyenkor fizikai jelenlét szükséges (oda kell menni belerúgni);
  • 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 (mondjuk oltóberendezés amúgy sem árt, persze).

• ha újak, megbízhatóak, esetleg márkásak:
  • bonyolultabb és/vagy sokkal drágább lesz az alkatrészcsere, ha elromlanak;
  • fáj, hogy Ott Az A Szép Nagy Gép És Nem Is Csinál Semmit;
    • (egy mai középkategóriás PC sok szerverfeladatra túlméretezett)
  • sok áramot fogyasztanak;
  • sok hőt adnak le - drága lesz a légkondi.

• 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 macerás mindig odamenni a konzolhoz, amikor valamelyiknek valami baja van;
  • LOM (Lights Out Management) megoldás lehet erre, de elég drága.

Bajok az egy Nagy Géppel, Amely 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 "nem dokumentá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, vagy akár egy konfigurációs változtatás, interferálhat egy másikkal.

Ugyanez menedzserül (Szalai Ferenc szavaival):

Miközben a hardver ára állandó vagy csökken, a növekvő komplexitású informatikai infrastruktúrát egyre nehezebb és költségesebb üzemeltetni.

A virtualizáció legfontosabb motivációi:

• költségtakarékosság
• üzemeltetés egyszerűsítése
• flexibilis infrastruktúra
• leállási idő csökkentése
• hely- és energiatakarékosság
• skálázhatóság növelése
• megbízhatóság növelése

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.

2 Fogalmak

• Virtuális gép, hostgép, host OS, guest OS
• Hypervisor, hipervizor: ring0-ban futó alkalmazás, amely erre felkészített operációs rendszerek kerneleit futtatja és ütemezi egyetlen fizikai gépen,
  • így egy fizikai gépen több virtuális gép is működhet.
  • Az oprendszerek speciális rendszerhívásokon, ún. hypercallokon keresztül kommunikálnak vele.
• JIT, Just in Time compilation: futás közbeni fordítás (pl. Java esetében bytecode-ról natív kódra)
  • Emuláció esetén a JIT ad-hoc kód-mikrooptimalizálást is jelenthet (az utasításszintű emulációnál hatékonyabb, de az eredeti kóddal azonos funkciójú natív kód generálását)

3 Virtualizációs technikák csoportosítása

3.1 Virtual hosting

• ugyanazon a fizikai szerveren egy webszerver 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

3.2 Emuláció

• teljes hardverarchitektúra emulációja
• az emulált processzor lehet eltérő a host cpu-tól
  • teljes utasításkészlet-transzformáció történik
• guest OS-t nem kell módositani
• x86: Bochs, Qemu
• powerpc: PearPC
• előnyök:
  • akármilyen architektúra emulálható
  • pl. egyprocesszoros gépen többprocesszoros gép
  • a teljes hardver minden része virtuális, így könnyen cserélhető és minden részlete ellenőrizhető, debugolható, módosítható (pl. a BIOS is)
• hátrányok:
  • lassú (akár 80% teljesítményveszteség)
  • kell egy hostrendszer, ami futtatja
• fő felhasználás:
  • szoftverfejlesztés olyan architektúrára, ami fizikailag nem áll rendelkezésre
  • hardverfejlesztés
  • zárt kódú operációs rendszerek virtualizációja

3.3 Full/Native virtualizáció

• hardverarchitektúra emulációja, de kihasználva, hogy a host-géppel azonosat emulál
  • => csak ugyanolyan processzort tud emulálni, amilyen a hostban van
• guest OS-t nem kell módositani
• Pl. x86: VMWare, VirtualBox
• előny:
  • jóval gyorsabb lehet, mint a teljes emuláció (~10-25% teljesítményveszteség nem irreális)
• hátrány:
  • kisebb rugalmasság, mint a teljes emuláció esetén

3.4 Oprendszerszintű virtualizáció, izoláció

• a guest és host OS kernel ugyanaz, guestek szeparálva vannak a hosttól és egymástól
• unix: chroot
• Linux: vserver, OpenVZ, FreeVPS
• FreeBSD: jail
• Solaris: container
• Wikipédia - OS-level virtualization
• előnyök:
  • jó teljesítmény (akár csak 0-5% teljesítményveszteség)
  • általában nagyon rugalmasan oszthatók ki az erőforrások az egyes guesteknek
• hátrányok:
  • egyetlen kernel (pedig az Oracle-nek ilyen kell, a Lotus Dominónak meg amolyan)
  • gyakran kernelmódosítást igényel

3.5 API-virtualizáció

• Az egyik oprendszeren nyújtsuk egy másiknak az APIját
• Pl: wine, cygwin, ndiswrapper, mplayer (win32 dll, mint codec)
• előny:
  • jó teljesítmény (akár csak 0-5% teljesítményveszteség)
• hátrányok:
  • nincs virtuális gép: az "emulátorban" futó processz nincs elszigetelve a többitől
  • úgy tűnik, több a hibalehetőség
• tipikus felhasználás:
  • játék Linuxon
  • általánosabban: azonos hardverplatformra, de más oprendszerre írt zárt forrású alkalmazás futtatása

3.6 Paravirtualizáció

• a guest speciális API-n keresztül éri el a hardvert
• Pl.:
  • Xen
  • UML (csak Linux; emulációs elemeket is tartalmaz)
  • Cooperative Linux (Linux, Windows alatt - noha nem igazán paravirtualizáció, ahhoz hasonlít a legjobban)
  • VMWare ESX
• előnyök:
  • jó teljesítmény (akár csak 2-5% teljesítményveszteség)
  • egyre jellemzőbb a hardvertámogatás
• hátrányok:
  • guest OS-t módositani kell (kivéve hardvertámogatás esetén)
  • sok a hype; nagyobb a füstje, mint a lángja
  • egyelőre kevés használható menedzsment-eszköz van hozzá, és ami van, az is inkább kereskedelmi

3.7 Storage-virtualizáció

• Új absztrakciós réteg a gépek és a SAN-rendszerek közé, ami
  • elrejti az egyes SAN-ok sajátosságait
  • esetleg összevonja a tárolókapacitásukat

3.8 Hálózat-virtualizáció

Többféleképpen is adhatunk hálózati kapcsolatot a virtuális gépeknek:

• virtuális interface a guest és a host között (pl. Xen)
  • Ezeket aztán rakhatjuk bridge-be, route-olhatunk közöttük stb.
• TAP driver (UML, CoLinux)
  • ez egy virtuális ethernet, kb. mint a Xennél
• izoláció
  • a guestnek nincs saját hálózati kártyája;
  • a hoszt interfészeinek és IP-címeinek egy részhalmazát látja, azokat tudja használni.
  • Ezt csinálja a vserver.

4 Szervervirtualizációs technikák

4.1 Apache Virtualhost

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

4.2 chroot

• csak fájlrendszer-szintű szétválasztás:
• a System V IPC közös;
• 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

4.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: (általában) nem lehet fájlrendszereket mountolni a guestben, és
• a host (általában) 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.
• Egy-egy guest könnyen kaphat hozzáférést egy hardverhez: egyszerűen létrehozzuk a megfelelő device node-ot a guest fájlrendszerében.
• 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 (bár elég jól haladnak vele).

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

Kedvcsinálónak:

4.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.
• Virtualizálja a /proc és a /sys fájlrendszereket is (a vserver csak részben - konkrétumok?).
• Checkpointing segítségével egy élő VE migrálható fizikai gépek között.
• 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
• De:
  • Amikor próbáltam, nem működött.
  • A kereskedelmi Virtuozzot akarják eladni vele, nem igazi FLOSS projekt.

4.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 a közelmúltig nem tudta - hogy állunk most?).
• 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?

4.6 Xen

• „Paravirtualizáció” (most már hardveresen is: Vanderpool (Intel), Pacifica (AMD))
• Hypervisor, Dom0, DomU
• A Xen virtuális gépei idővel futni fognak a Longhorn hypervisora alatt is.
• A Vista virtualizálhatóságáért külön fizetni kell (csak a drágább változatok támogatják).
• Hardveres virtualizációval fut benne a Windows XP is; a konzolt VNC-vel látjuk.
• 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 (2006-os állapot)
• dom0-ban lehet: Linux, NetBSD (hamarosan FreeBSD is - 2006-os állapot).
• paravirtualizált domU-ban lehet: Linux, NetBSD, FreeBSD, Minix, Plan9, OpenSolaris, NetWare
• Alkalmazási példa: Potemkin VMM
  • A UCSD-n (University of California, San Diego) van egy üresen álló A osztályú címtartomány, amit "Network Telescope"-nak használnak
  • Ide normális esetben nem jön csomag; ha mégis, akkor az pl. ész nélkül próbálkozó portscan vagy féreg
  • Nosza, rakjunk bele honeypotokat, hogy lássuk, mit csinálnak a megtámadott gépek
  • Csakhogy: kinek van tizenhatmillió-hétszázhetvenhétezer-kétszáztizennégy számítógépe? (Talán a Google-nak... :)
  • Megoldás: pár tucat PC, mindegyiken egy módosított Xen
  • A domU-kban különféle Windowsok, párféle szolgáltatásmixszel
  • Ha érdekesnek tűnő csomag jön be, akkor a cél-IP-hez párszáz milliszekundum alatt klónoznak egy új domU-t egy meglevőből úgy, hogy a memóriája copy on write szemantikával allokálódik, tehát amihez nem nyúl, azon osztozik az eredeti példánnyal
  • Így egy PC-n százával lehet (nagyon hasonló) virtuális gépeket futtatni
  • Ha az új Windows semmi izgalmasat nem csinál a csomaggal, egyszerűen megszüntetik
  • Ha ő is elkezd miatta kommunikálni, akkor megtartják egy darabig és nézik, mit csinál
  • Az Internet felé nem tud új kapcsolatot nyitni, ha megpróbálja, az egy új virtuális géphez jut el (így a fertőzések dinamikája is nyomon követhető)
  • Pár tucat PC segítségével látszólag megtölthető gépekkel egy /8-as hálózat...
• Létezik paravirtualizált Windows XP is, csak a licencfeltételek miatt nem adhatja ki a University of Cambridge.
• A Xenről később lesz szó részletesebben is.
  • Lett: Szalai Ferenc előadásának fóliái
• A xen 3.0.x korlátai

5 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 feltétlenül 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
• Szalai Ferenc xenes előadásának fóliái
• A xen 3.0.x korlátai
• Xenoppix - Knoppixba gyógyított Xen. Könnyű vele kipróbálni a xenes virtualizációt.