Virtualizációs technikák, technológiák
A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(→Xen: Potemkin VMM, mint alkalmazási példa) |
(aktualizáció 2007) |
||
2. sor: | 2. sor: | ||
* adott sok-sok PC a salgó polcon: mindegyik valamelyik osztályé, tanszéké, haveré, ügyfélé stb.; vagy |
* 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". |
+ | * adott egy (vagy néhány) nagy szerver, ami Sokmindent Csinál. |
A sok PC esetében fellépő problémák: |
A sok PC esetében fellépő problémák: |
||
12. sor: | 12. sor: | ||
** meghibásodás esetén kereshetünk beléjük való gagyi hardvert; |
** meghibásodás esetén kereshetünk beléjük való gagyi hardvert; |
||
** papírfecnivel ki kell ékelni a processzorhűtőt; |
** papírfecnivel ki kell ékelni a processzorhűtőt; |
||
− | ** poroltót kell tartani a közelben. |
+ | ** 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: |
* ha újak, megbízhatóak, esetleg márkásak: |
||
** bonyolultabb és/vagy sokkal drágább lesz az alkatrészcsere, ha elromlanak; |
** 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; |
** 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 áramot fogyasztanak; |
||
** sok hőt adnak le - drága lesz a légkondi. |
** sok hőt adnak le - drága lesz a légkondi. |
||
36. sor: | 37. sor: | ||
* 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 |
* 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. |
* 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. |
+ | * 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 |
||
== Az elképzelt megoldás == |
== Az elképzelt megoldás == |
||
43. sor: | 44. sor: | ||
* ezeken külön virtuális szerverekben futtassuk az egyes kis PC-ket vagy a Sokmindent Csináló Gép egyes funkcióit. |
* 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. |
+ | Sok virtualizációs megoldás létezik, amelyek sokmindenben hasonlítanak, és meg több mindenben különböznek. |
+ | |||
+ | == 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) |
||
+ | |||
+ | |||
+ | == Virtualizációs technikák csoportositasa == |
||
+ | |||
+ | === 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 |
||
+ | |||
+ | === 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-transzofrmáció történik |
||
+ | * guest OS-t nem kell módositani |
||
+ | * x86: [http://bochs.sourceforge.net/ Bochs], [http://fabrice.bellard.free.fr/qemu/ Qemu] |
||
+ | * powerpc: [http://pearpc.sourceforge.net/ 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. 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 |
||
+ | |||
+ | === 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: [http://www.vmware.com/ VMWare], [http://www.virtualbox.org/ 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 |
||
+ | |||
+ | === 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 |
||
+ | * [http://en.wikipedia.org/wiki/Operating_system-level_virtualization 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 |
||
+ | |||
+ | === 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 |
||
+ | |||
+ | === Paravirtualizáció === |
||
+ | |||
+ | * a guest speciális API-n keresztül éri el a hardvert |
||
+ | * Pl.: |
||
+ | ** [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Xen] |
||
+ | ** [http://user-mode-linux.sourceforge.net/ UML] (csak Linux; emulációs elemeket is tartalmaz) |
||
+ | ** [http://www.colinux.org/ 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 |
||
+ | |||
+ | === 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 |
||
+ | |||
+ | === Hálózat-virtualizáció === |
||
− | == Virtualizációs technikák == |
+ | Többféleképpen is adhatunk hálózati kapcsolatot a virtuális gépeknek: |
− | 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. |
+ | * 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]]. |
||
− | Addig is a legfontosabb megoldások: |
+ | == Szervervirtualizációs technikák == |
=== Apache Virtualhost === |
=== Apache Virtualhost === |
||
58. sor: | 59. sor: | ||
* csak fájlrendszer-szintű szétválasztás: |
* 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.; |
+ | * a System V IPC közös; |
* egy chrootnak nem lehet saját IP-je, saját tűzfalszabályai; |
* 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. |
* két chrootban ugyanolyan UID alatt futó processzek küldhetnek egymásnak signalt stb. |
||
70. sor: | 71. sor: | ||
=== [[vserver]] === |
=== [[vserver]] === |
||
− | * Olyan mint a chroot, csak jobb. |
+ | * Olyan, mint a chroot, csak jobb. |
* Minden virtuális gép ugyanazon a kernelen fut. |
* Minden virtuális gép ugyanazon a kernelen fut. |
||
** Minimális overhead, úgyhogy gyors. |
** Minimális overhead, úgyhogy gyors. |
||
79. sor: | 80. sor: | ||
** processzkezelés, |
** processzkezelés, |
||
** saját IP. |
** saját IP. |
||
− | * Viszont: nem lehet fájlrendszereket mountolni a guestben, és |
+ | * Viszont: (általában) nem lehet fájlrendszereket mountolni a guestben, és |
− | * a host automatikusan hozzáfér a guest összes adatához. |
+ | * 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ó. |
* 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 |
+ | * 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. |
* 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). |
* Ehhez persze a vservereknek egy fájlrendszeren kell lenniük (de elvileg van vserver-szintű diszk-kvóta, úgyhogy annyira nem baj). |
||
88. sor: | 89. sor: | ||
* Egy vserver migrálása nagyon egyszerű: <tt>tar</tt>. |
* Egy vserver migrálása nagyon egyszerű: <tt>tar</tt>. |
||
* 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. |
* 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. |
+ | * 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. |
− | * Sajnos patchelni kell a kernelt. |
+ | * De: |
− | * Nincs IPv6-támogatás. |
+ | ** 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. :) |
Ilyesmi lehet a FreeVPS és az OpenVZ is. Házi feladat. :) |
||
100. sor: | 101. sor: | ||
* Olyasmi, mint a vserver (egy kernelen fut az összes virtuális gép). |
* 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. |
* 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?''). |
* 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. |
* 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). |
* 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 |
* 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. |
||
=== User Mode Linux === |
=== User Mode Linux === |
||
126. sor: | 125. sor: | ||
* Nem (feltétlenül) szükséges hozzá kernelt patchelni (legalábbis ezen a héten). |
* 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). |
* 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). |
+ | * 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. |
* 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). |
* 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). |
||
134. sor: | 133. sor: | ||
=== Xen === |
=== Xen === |
||
− | * „Paravirtualizáció” (de most már tud hardvereset is: Vanderpool (Intel), Pacifica (AMD)) |
+ | * „Paravirtualizáció” (most már hardveresen is: Vanderpool (Intel), Pacifica (AMD)) |
* Hypervisor, Dom0, DomU |
* Hypervisor, Dom0, DomU |
||
* A Xen virtuális gépei idővel futni fognak a Longhorn hypervisora alatt is. |
* 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). |
* 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. |
+ | * 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á. |
* 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 |
+ | * x86, amd64, ia64, ppc; Sparc készülőben (2006-os állapot) |
− | * dom0-ban lehet: Linux, NetBSD (hamarosan FreeBSD is). |
+ | * dom0-ban lehet: Linux, NetBSD (hamarosan FreeBSD is - 2006-os állapot). |
* paravirtualizált domU-ban lehet: Linux, NetBSD, FreeBSD, Minix, Plan9, OpenSolaris, NetWare |
* paravirtualizált domU-ban lehet: Linux, NetBSD, FreeBSD, Minix, Plan9, OpenSolaris, NetWare |
||
* Alkalmazási példa: [http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin-presentation.pdf Potemkin VMM] |
* Alkalmazási példa: [http://www.cs.ucsd.edu/~mvrable/papers/2005-sosp-potemkin-presentation.pdf Potemkin VMM] |
||
161. sor: | 160. sor: | ||
* [http://ian.blenke.com/xen/3.0/limitations/xen_limitations.html A xen 3.0.x korlátai] |
* [http://ian.blenke.com/xen/3.0/limitations/xen_limitations.html A xen 3.0.x korlátai] |
||
− | == Virtualizációs technikák csoportositasa == |
||
− | |||
− | (Írta: NSzabolcs) |
||
− | |||
− | === 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: [http://bochs.sourceforge.net/ Boch], [http://fabrice.bellard.free.fr/qemu/ Qemu] (gyorsítás nélküli) |
||
− | |||
− | === 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: [http://kvm.sourceforge.net/ KVM], [http://www.vmware.com/ VMWare] (Iron, Workstation, Server) |
||
− | |||
− | === 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: [http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ Xen] |
||
− | * x86, IA-64, PPC: [http://user-mode-linux.sourceforge.net/ UML] (csak Linux) |
||
− | |||
− | === 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 |
||
− | * [http://en.wikipedia.org/wiki/Operating_system-level_virtualization Wikipedia - OS-level virtualization] |
||
− | |||
− | === 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 |
||
== Ajánlott irodalom == |
== Ajánlott irodalom == |
A lap 2007. december 4., 02:25-kori változata
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
Tartalomjegyzék |
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 csoportositasa
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-transzofrmá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. 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.
- 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.