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.

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 architectures

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