Solaris virtualizációs megoldások
In progress...
Ez a lap a Sun Solaris 10 operációs rendszer virtualizációs megoldásainak bemutatására készült.
Tartalomjegyzék |
1 A Solarisról általában
A Solaris a Sun Microsystems SVR4 kompabibilis, Unix-ok családjába tartozó operációs rendszere. Jelenlegi legfrissebb kiadása a Solaris 10 10/09, közismertebb nevén a Solaris 10 Update 8. A jelenleg futó kernel verziója:
kvegh@at1p1uivsh005:~$ uname -srv SunOS 5.10 Generic_142900-02 kvegh@at1p1uivsh005:~$
A Solaris 10 2005. január 31.-én jelent meg, olyan újdonságokkal mint a DTrace, az SMF (Service Management Facility, amely az init.d scriptek leváltására jött létre), az NFSv4 vagy a Solaris Containers. Ezen kiadástól kezdve szabadon letölthető - regisztráció után - és szabadon felhasználható az új licencelési struktúrának köszönhetően, ám ehhez csak a negyedéves frissítések és biztonsági javítások járnak.
A ZFS támogatás a Solaris 10 Update 2-ben került be.
1.1 Felhasználása
A Solaris kitűnő SMP képességekkel rendelkezik, kitűnőek skálázódik a többprocesszoroz rendszereken is, lehetővé téve a rendszer teljes és egyenletes kihasználását. Képes kihasználni a nagyobb Sun (és az Opteron) gépek NUMA jellegét is, ahol az SMP-től eltérően egyes memóriaterületek adott processzor(ok)hoz "közelebb" lehetnek. Az ehhez szükséges támogatást Memory Placement Optimizationnek (MPO) hívják.
A skálázhatósága, teljesítménye és robosztussága képesség teszi alkalmazáskritikus feladatok ellátására, ezért előszeretettel használják vállalati környezetben is, legyen szó akár webkiszolgálásról, akár alkalmazásszerverekről.
2 Támogatott architektúrák
A Solaris 10 a következő platformokon fut:
- Sun SPARC
- x86
- x86_64
3 Solaris virtualizációs technológiák
Különböző processzorarchitektúrákon különböző virtualizációs technológiák állnak rendelkezésünkre Solarison.
CPU arch | current CPUtypes | cores on chip | threads per core | virtualization options | virtualization features |
Sparc64 | Sparc64-VII | 4 | 2 | Dynamic domains (+ zones) | elektronical- , kernel-level- , userspace-, filesystem-, network-stack-separation |
CMT (Coolthread series) | T2, T2Plus | 8 | 8 | LDOMs (+ zones) | kernel-level-, userspace-, filesystem-, network-stack-separation |
x86 | Nehalem-series | 4 | 2 | Zones | userspace-, (optional) filesystem-, (optional) network-stack-separation |
x86-on meg tervben volt egy Xen alapú virtualizació (Solarissal a dom0-ban), de ezt a termékvonalat leállították.
3.1 Dynamic domains
Ez a technológia csak Sparc64-es architektúrán érhető el, az Mx000 szerversorozaton. Igazából hardwareparticionálásról van szó, egy chassisban CMU-kat (CPU/Memory Unitokat) és IOU-kat (I/O unitokat (diszkek, NIC-ek, PCI slotok, etc.)) lehet domainekbe összefogni, illetve ezeket a boardokat a domainekben futó OS-ekhez futás közben hozzáadni. A domain maga az OS rendelkezésére bocsátott hardwarekörnyezet. Ennek a már-már mainframe megoldásnak az előnye, hogy lehetőséget nyújt a domainek egymástól elektronikusan elhatárolt definíciójára, egy (akár elektronikai) hiba semilyen mértékben nem befolyásolja a többi dinamikus domain működését. Az OS nem emulált/virtualizált erőforrásokat kap, hanem maga a hardware változtatható dinamikusan a rendszer alatt. A domainekben futó OS-en tetszőleges számú zónát futtathatunk.
3.2 Logical domainek, LDOMok
(aktuális terméknév: Oracle VM Server for SPARC)
Ez a technológia csak a CMT (Coolthread, azaz T1, T2, T2Plus) architektúrán érhető el a Txxx0 szerversorozaton. A hardwaren futó thin hypervisor kezeli az erőforrásokat a definiált logical domainek között. Ellentétben a dinamikus domainek elektronikus elvalasztasaval, itt csak logikailag elhatárolódásról van szó, tehát egy hardwarehiba több ldomot is erinthet. Egy Coolthread CPU 6-8 magos, mindegyik CPUmagon 4-8 thread futhat párhuzamosan, ezáltal 24-256 threadet futtathat összesen egy T rendszer. A futtatható threadek száma határozza meg a konfigurálható logikai domainek számát. Legalább egy ldom control domainként működik, azaz onnan kezelhető/konfigurálható a többi logikai domain. Egy logikai domain tartalmaz HW-threadeket (virtualis CPUkat), memóriaterületet, virtuális networkinterfaceket, storageelemeket (blockdeviceokat, filesystemeket), de akar dedikalt PCI deviceokat is. Egy-egy LDOM képezi az OS számára a futtatási környezetet. Minden LDOMban tetszőleges számú zónát futtathatunk.
3.3 Solaris Containers - zónák
A Solaris legegyszerűbb, és ezzel együtt legrugalmasabb oprendszerszintű virtualizációs megoldása a Solaris zónák. A zóna és a container kifejezést gyakran felcserélhetően használják; egy elterjedt definíció szerint a container kifejezés a zónákat és azok erőforrásmenedzsmentjét együttesen jelenti.
A zónákról a System Administrators Guide dokumentációgyűjtemény Resource Management and Solaris Zones részlegében olvashatunk részletesen.
A bare metal OS installt, vagyis a host OS-t global zone-nak (GZ) nevezzük, míg a rajta futó zónákat non-global zone-nak (NGZ). Egy zóna leginkább egy vserverre hasonlít. Az egy hoszton (global zónán) futó zónák userspace-ei egymástól elszigetelve futnak, míg a GZ és az NGZ-ék kernelspace kódja közös (a fizikai hoszton csak egyetlen kernel fut).
NGZ-t többféleképpen konfigurálhatunk; a főbb featúrák a következők:
3.3.1 Hálózati konfiguráció
Egy zóna használhat fizikai hálózati interfészeket vagy logikai interfészeket. Fizikai interfészek esetében exclusive-ip zónáról beszélünk. Ekkor a global zóna fizikai interfésze teljes egészében az adott zónáé lesz, sem a többi NGZ, sem a GZ nem használhatja; a zónának saját routing-táblája és saját IP-stackje lesz. Ha logikai interfészeket használ (azaz a fizikai interfész a GZ tulajdonában van, es csak a rajta definiált logikai interfészek egy része tartozik a zónához), akkor shared-ip zónáról beszélünk. Egy GZ-ban konfigurálhatunk shared- és exclusive-ip zónákat egymás mellé, de minden konkrét zónahoz vagy csak fizikai, vagy csak logikai interfészeket rendelhetünk (nem keverhetjük a GZ IP-stackjét -- a shared interfaceken át -- a zóna saját IP-stackjével).
További tudnivalók:
- Fizikai interfészek használata esetén azokra a zónán belül húzhatunk fel logikai interfészeket.
- Ha LDOM-okon belül futtatunk exclusive-ip zónákat, akkor alapesetben nem konkrét fizikai hálózati kártyát dedikálunk egy-egy zónának, hanem a controlled domain által emulált virtuális interfészt, ami viszont fizikai interfészként múködik.
- OpenSolarisban mar implementálták a Crossbow fedőnevű featúrát, ami teljes hálózati virtualizációt tesz lehetővé a global zónában, ezzel elegendő virtuális interfészt generálva már nem okoz fejtörést a shared-ip zónák routingja illetve Quality of Service-e.
3.3.2 Fájlrendeszer-konfiguráció
Definálhatunk különböző filesystem template-eket. Eleve rendelkezésünkre áll két template: a sparse és a whole root zóna. Sparse zóna esetében a /usr, /platform, /lib, /sbin
filerendszereket loopback mounttal (ez olyasmi, mint Linuxon a bind mount) csatoljuk be (read-only) módon a zónába a global zónából, amivel az alábbi három dolgot érjük el:
- Helyet takarítunk meg. Egy teljes OS-install esetében pár tucat zóna felett ez már jelentős mennyiségű gigabájtot jelenthet
- A loopback mountoknak köszönhetően sokkal gyorsabban patchelhetünk (a GZ-t patchelve nem kell minden egyes patchet, ami a loopback mountolt filerendszereken levő programokat érinti, még egyszer installálni zónánként).
- A loopback mountoknak köszönhetően sokkal komolyabb függőségi viszony áll fenn a GZ-val: nem installálhatunk (egyszerűen) szoftvert az NGZ-ben pl. a /usr alá, mival az readonly filerendszer.
Egy zónához a saját filerendszerein kívül még sokféleképpen rendelhetünk filerendszereket, device-okat, zpool-okat, loopback mountokat stb.
3.3.3 Erőforráskezelés
Sok zónát egymás mellett futtatva könnyen előfordulhat, hogy egy-egy zóna, illetve a bennük futó alkalmazások (f)elhasználják az erőforrások nagy részét, ezzel hátrányos helyzetbe hozva a többi zónát. Mely erőforrásokat tudunk limitálni/dedikálni kőlönböző zónáknak?
3.3.3.1 Hálózat
Opensolaris esetében használhatjuk a fent említett Crossbow technológiát, Sun Solaris esetén maximum különböző fizikai NICekre konfigurálhatjuk a zónák forgalmát.
3.3.3.2 Processzor
- CPUsetek
- CPUpoolok
- FSS
3.3.3.3 Memória
- RCAP, swap, RAM