2. Problémák
●
Informatika egyre kritikusabb
infrastruktúra és egyre nagyobb
rendelkezésre állást várnak el tőle
●
Növekvő teljesítmény igényeket nem
lehet erősebb gépekkel kielégíteni
gazdaságosan
●
Növekvő bonyolultságú informatikai
infrastruktúra (egyre több szerver a
szerverszobában)
●
Növekvő tárolandó adatmennyiség (kép,
videó, adatbázisok)
3. Miért virtualizáljunk?
●
Vezetői szemlélet: a vas ára állandó, a
adminisztrációs költségek nőnek
●
Motiváció:
– költségtakarékosság: 51.7 %
– üzemeltetés egyszerűsítése: 14.6 %
– flexibilis infrastruktúra: 13.1 %
– leállási idő csökkentése: 12.6 %
– helytakarékosság: 10.9 %
– skálázhatóság: 10.9 %
– megbízhatóság: 10.9 %
(IDC 2005)
4. Mit?
●
storage (adattároló alrendszerek): elrejteni
a különféle gyártók SAN rendszereit,
összevonni az elemi adattároló
kapacitásokat (pl: NONSTOP architektúra)
●
I/O virtualizáció: dinamikus sávszélesség és
QoS fizikai csatornákon (pl.: Infiniband)
●
szerver virtualizáció
5. Hogyan?
●
Szerver virtualizációs technikák fő
kategóriái:
– Emuláció
– para-virtualizáció
– operációs rendszer szintű
– API virtualizáció
– Alkalmazás szintű
●
Egzotikumok:
– Virtual SMP: elosztott közös memóriájú
klaszterek
– PC architektúrán túl: IBM Power 5, 6
– IBM S/360 hypervisor OS – minden virtualizáció
ős anyja
6. Alapfogalmak
●
host gép/operációs rendszer: virtuális
gépeket befogadó fizikai eszköz
●
virtuális gép: absztrakció, szoftver elem,
ami fizikai eszközök virtualizálásával teremt
az operációs rendszerek számára futási
környezetet
●
guest gép/operációs rendszer: virtuáis
gépen futó OS
●
hipervizor: szuper-privilégizált módban futó
kernel, ami a virtuális gépet szolgáltat (para
virtualizáció)
●
JIT – just in time: futás közbeni fordítás
7.
8. Emuláció
●
Előnyök:
– változatos architektúrák (PC, Amiga, stb.)
– teljes hardver kontroll (BIOS, VGA, stb.)
●
Hátrányok:
– sebesség
– host rendszer mindig kell
– nagy teljesítmény igény a host rendszeren is
●
Legismertebb megoldások:
– Vmware Wokrstation, Player, Server
– MS Virtual PC és szerver
– Qemu
– Boch
– Amiga, Mobiltelefon, stb. fejlesztő környezetek
9. Paravirtualizáció
●
Előnyök:
– jó teljesítmény (2-5% veszteség, néha
nyereség)
– hardver támogatás
●
Hátrányok:
– guest OS módosítását igényli
– kiforrott management eszközök hiánya
●
Legismertebb megoldás: XEN
11. HVM – Hardware Virtual Machine
●
Ezzel tudunk Windowst futtatni Linuxon!
●
Közös interfész az Intel (VT-x vagy Vanderpool) és az AMD
(SVM vagy Pacifica) saját hardveres virtualizációs
megoldásához (hvmloader)
●
Új futási mód a hipervizornak, OS futhat ring0-ban.
●
Új utasítások a processzorban (Intel: VMLaunch,
VMResume, VMExit, AMD: VMRUN)
● dom0-ban ioemu (módosított qemu) a legtöbb eszköz (PCI,
VGA, IDE, NE2000, stb.) emulációja ezen keresztül történik
●
nagy teljesítményt igénylő eszközök emulációja (IOAPIC,
LAPIC, VPIT, stb.) magában a XEN-ben van.
●
Pl: Intel Pentium D 9xx, Core Duo, 2 Core Duo, egyes
Xeonok AMD Athlon 64 3xxx+, X2 Dual-Core, Turion,
Opteron [1,2,8]000
●
KVM: Kernel Virtual Machine (Linux)
12.
13. Operációs rendszer szintű
●
Előnyök:
– teljesítmény (2-5 % veszteség)
– pehelysúlyú
– jó virtuális gépenkénti erőforrás használat
szabályozás
●
Hátrányok:
– nem lehet több különféle OS típus
– kernel módosítást igénye, host-on, guest-en
egyaránt
●
Ismertebb megoldások:
– chroot, BSD Jail
– Linux-Vserver
– OpenVZ
– Solaris Container
17. XEN hálózat
● /etc/xen/scripts alatt
– egy 'network' script, ami a
dom0-án állítja a hálózatot a
xend indulásakor
– egy 'vif' script ami a dom0-án
konfigurálja a virtuális
interfészeket
minden domaint vifX.Y
xenbr0
alakú hálózati interfész
reprezentál a domain0ban.
(X=domainID, Y=interfész
szám)
Alap scriptek: bridge, route, xenbr1
nat (problémás lehet),
vegyes megoldások, saját
18. Lemez formátumok
●
Cél:
– kis méret, gyors elérés. hatékony VM tárolás
●
Méret csökkentő megoldások:
– „Lyukak” az állományrendszerben
– COW (copy on write)
– tömörítés
●
Sebesség növelő megoldások:
– többszintű cache és clustering
●
Titkosítás
●
Típusok:
– Raw (Qemu)
– COW (UML, Vmware disk, MS Virtual PC)
– Tömörített: QCOW (qemu)
19. XEN virtuális lemezkezelés
●
image állomány (loopback)
● disk = ['file:/var/images/debian.img,sda1,w']}
●
user space megoldások: blktap
● disk =
['tap:aio:/dev/images/debian.img,sda1,w']}
●
külön partíció
● disk = ['phy:/dev/hda2,sda1,w']}
●
logikai kötet (LVM)
● disk = ['phy:/dev/xenimages/noc.grid,sda1,w']}
●
user space megoldás HVM esetén: qemu-dm
● disk =
['phy:/dev/xenimages/win2003,ioemu:hda1,w']}
● NFS root: konfigurációs állományban nfs_server,
nfs_root
20. VM Extrák
●
Snapshot mód
●
Migráció
●
P2V
●
Klónozás és template vezérelt management
●
Fizikai hibák szimulációja
23. Mikor melyiket?
●
Új hardver platform: Emuláció pl.: Qemu,
VMware
●
Hosting:
– ha sok azonos rendszer: OS szintű virtualizáció -
pl.: OpenVZ
– ha sokféle rendszer: Paravirtualizáció – pl.: Xen,
VMware ESX
●
Linux kernel fejlesztés: UML
●
Windows-on Linux, ha kell teljesítmény is:
CoLinux
●
Oktatói tesz hálózat: XEN, UML
●
Desktop Virtualizációs: VMware
24. Milyen szolgáltatásokat?
●
Levelező rendszer, ha
– nincs nagy forgalom vagy sok IMAP kapcsolat
●
Web szerver
– ha az átlag terhelés < 10 rq/s
●
Adatbázis szerver
– Oracle-vel óvatosan kell bánni
●
Tűzfal, ha nincs más megoldás
●
Alkalmazás szerver:
– az enterpise JAVA kacatokkal bajok lehetnek
●
Állomány szerver:
– irodai környezetben
25. Miért jó klaszter építeni?
●
Nagy rendelkezésre állás: HA klaszeterek
– alkalmazás szintű megoldás: pl.: Heathbeat
●
Teljesítmény elosztás (Load balance
klaszterek)
– Layer 4 és Layer 7 szintű megoldások. Pl.: IPVS
●
Nagy teljesítményű számítás (HPC
klaszterek)
– beowulf
●
NUMA klaszterek
●
SSI (single system image) klaszterek: pl.
OpenMosix, OpenSSI
26. Megfelelő tároló alrendszer
●
Klaszterek alapja a közös állomány és/vagy
tároló alrendszer
●
Hol tároljuk a virtuális gépek virtuális lemezeket?
●
Lehetőségek tárolóra:
– dom0-ba rakjunk sok lemezt: nehezen
skálázható, nagy rendelkezésre állás
kialakítása nehézkes
– NAS (NFS): három egymástól független
állományrendszer konzisztencia problémája
– Fibre Channel/Infiniband SAN: jó de általában
drága
– IP/Ethernet SAN: jó kompromisszum lehet
27. IP/Ethernet SAN
●
forrás (target), cél (initiator) architektúra
●
IP SAN: iSCSI
●
Ethernet SAN: AOE (Ata-over-Ethernet)
●
AOE: egyszerű protokoll ATA üzenetek natív
etherneten történő továbbítására
– initiator 2.6.11 óta Linux kernel része
– célhardver target (Coraid Inc.)
28. Egyszerű HA VM klaszter
●
Közös tároló vagy DRBD
●
A fizikai gép
meghibásodás ellen
védekezünk
●
floating IP
●
Heathbeat
– domainek indítása
– raid, lvm összeállítása
– hálózat
●
Figyelem: Linux sw raid
nem támogatja a
klaszterezést!
29. Egyszerű terhelés kiegyenlítő
VM klaszter
●
CLVM (GFS nem
kell!)
●
XEN migráció
●
Külső
monitorozás és
automatizált
domain
áthelyezés
(SLA)
●
HA IPVS 2
gépen
30. NONSTOP
storage és XEN
●
Adattároló klaszter nem csak
Xen-hez.
●
Moduláris adatkapcsolat, igény
szerint
●
Egyszerű elemek
●
Skálázható a sávszélesség és
a switchek erejéig
●
management eszköz kell
hozzá
●
storage virtualizáció képesség
NONSTOP =
NONSTOP Network Storage Platform
31. Tervezési szempontok
●
Előbb az adattároló alrendszer
●
1-2 hónap monitorozási adatok kellenek
(mit érdemes és mint nem virtualizálni)
●
VM hosting platform kialakítása és
tesztelése
●
P2V migrációval test imagek készítése
(Linux rendszerek esetén egy jól irányzott
dd is megtesz, vagy ha van backup akkor
az)
●
HA és Loadbalance tesztek, intenzíven
●
Migráció egyesével, esetleg
szolgáltatásonként
●
Mérés
