Solaris virtualizációs megoldások
Lanc (vitalap | szerkesztései) a (→Hálózati konfiguráció) |
Lanc (vitalap | szerkesztései) (→Filesystem konfiguráció) |
||
88. sor: | 88. sor: | ||
====Filesystem konfiguráció==== |
====Filesystem konfiguráció==== |
||
+ | Definálhatunk különböző filesystem templateket, két defaulttemplate áll alapesetben rendelkezésünkre, a '''sparse''' és a '''whole root''' zóna. Sparse zóna esetében a <code>/usr, /platform, /lib, /sbin</code> filerendszereket loopback mounttal csatoljuk be (read-only) módon a zónába a global zoneból, ezzel három dolgot érünk el: |
||
+ | * helyet takarítunk meg, egy full-blown OS installnál pár tucat zóna felett ez már jelentős mennyiségű gigabyteot 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 levo programokat erinti megegyszer 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 a /usr alá pl., lévén readonly filerendszer. |
A lap 2010. április 20., 23:38-kori változata
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 zonenak nevezzük, míg a rajta futó zónákat non-global zonenak. Egy zona leginkabb egy vserver-rel hasonlithato össze, az egy hoston (global zónán) futó zónák egymástól elkülönülnek userspace szinten, (a global zóna userspacében egymástól függetlenől futva), míg a kernelspace közös mint a GZ, mind a NGZák között.
NGZ-t többféleképpen konfigurálhatunk, a főbb featurök:
3.3.1 Hálózati konfiguráció
Egy zóna használhat fizikai network interfaceket vagy logikai interfaceket. Fizikai interfacek esetében exclusiv-ip zónáról beszélünk. Ekkor a global zona fizikai interface teljes egészében a zónának lesz dedikálva, 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 interfaceket használ (azaz a fizikai interface a GZ tulajdonában van, es a rajta definiált logikai interfacek tartoznak csak a zonahoz, akkor shared-ip zónáról beszélünk. Egy GZ-ban konfigurálhatunk shared- és exclusiv-ip zónákat egymás mellé, de egy zónahoz vagy fizikai vagy logikai interfaceket konfigurálhatunk a GZból. (Nem keverhetjük a GZ IP stackjet (a shared interfaceken át) a zóna saját IP stackjéevel (a dedikált interfaceken át)).
NB:
- fizikain interfacek használata esetén azokra a zónán belül húzhatunk már fel logikai interfaceket
- Ha LDOM-okon belül futtatunk exclusiv-ip zónákat, akkor alapesetben nem konkrét fizikai hálóozati kártyát dedikálunk egy-egy zónába, habem a controlled domain által emulált virtuális interfacet, ami viszont fizikai interfacekent múkédik
- OpenSolarisban mar implementálták a Crossbow fedőnevű featuret, ami teljes hálózati virtualizációt tesz lehetővé a global zónában, ezzel elegendő virtuóalis interfacet generálva már nem okoz fejtörést a shared-ip zónák routingja illetve Quality of Service
3.3.2 Filesystem konfiguráció
Definálhatunk különböző filesystem templateket, két defaulttemplate áll alapesetben rendelkezésünkre, a sparse és a whole root zóna. Sparse zóna esetében a /usr, /platform, /lib, /sbin
filerendszereket loopback mounttal csatoljuk be (read-only) módon a zónába a global zoneból, ezzel három dolgot érünk el:
- helyet takarítunk meg, egy full-blown OS installnál pár tucat zóna felett ez már jelentős mennyiségű gigabyteot 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 levo programokat erinti megegyszer 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 a /usr alá pl., lévén readonly filerendszer.