Solaris virtualizációs megoldások
Lanc (vitalap | szerkesztései) (→Erőforráskezelés) |
a (→Solaris Containers - zónák: magyar korrektúrázás) |
||
77. sor: | 77. sor: | ||
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.<br> |
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.<br> |
||
A zónákról a [http://docs.sun.com/app/docs/coll/47.16?l=en System Administrators Guide] dokumentációgyűjtemény [http://docs.sun.com/app/docs/doc/817-1592/zone?l=en&a=browse Resource Management and Solaris Zones] részlegében olvashatunk részletesen.<br> |
A zónákról a [http://docs.sun.com/app/docs/coll/47.16?l=en System Administrators Guide] dokumentációgyűjtemény [http://docs.sun.com/app/docs/doc/817-1592/zone?l=en&a=browse Resource Management and Solaris Zones] részlegében olvashatunk részletesen.<br> |
||
− | A bare metal OS installt, vagyis a host OS-t '''global zone'''nak nevezzük, míg a rajta futó zónákat '''non-global zone'''nak. Egy zóna leginkább egy [[vserver]]-rel hasonlítható ö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. <br> |
+ | 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 [[vserver]]re 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 featurök: |
+ | |
+ | NGZ-t többféleképpen konfigurálhatunk; a főbb featúrák a következők: |
||
====Hálózati konfiguráció==== |
====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)).<br> |
+ | 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). |
− | 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 |
||
− | ====Filesystem konfiguráció==== |
+ | További tudnivalók: |
− | 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 |
+ | * Fizikai interfészek használata esetén azokra a zónán belül húzhatunk fel logikai interfészeket. |
− | * 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) |
+ | * 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. |
− | * 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. |
+ | * 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. |
− | Egy zónába a saját filerendszerein kívül még sokféleképpen definiálhatunk filerendszereket, deviceokat, zpool-okat, loopback mountokat, stb. |
+ | |
+ | ====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 <code>/usr, /platform, /lib, /sbin</code> 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. |
||
====Erőforráskezelés==== |
====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 nagyré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? |
+ | 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? |
+ | |||
=====Hálózat===== |
=====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. |
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. |
||
+ | |||
=====Processzor===== |
=====Processzor===== |
||
* CPUsetek |
* CPUsetek |
||
* CPUpoolok |
* CPUpoolok |
||
* FSS |
* FSS |
||
+ | |||
=====Memória===== |
=====Memória===== |
||
− | *RCAP, swap, RAM |
+ | * RCAP, swap, RAM |
A lap 2010. április 21., 01:18-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[elrejtés] |
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