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

A lap eredeti címe: „http://unixlinux.tmit.bme.hu/index.php?title=Virtualiz%C3%A1ci%C3%B3s_technik%C3%A1k,_technol%C3%B3gi%C3%A1k&oldid=2417”
Személyes eszközök