Solaris virtualizációs megoldások

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (Solaris Containers - zónák: magyar korrektúrázás)
1. sor: 1. sor:
In progress...
+
=Solaris virtualizációs megoldások=
  +
  +
   
Ez a lap a Sun Solaris 10 operációs rendszer virtualizációs megoldásainak bemutatására készült.
 
 
==A Solarisról általában==
 
==A Solarisról általában==
 
A Solaris a [http://sun.com 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
+
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:
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.
+
root@solaris10:{/root}# uname -srv
  +
SunOS 5.10 Generic_141445-09
  +
root@solaris10:{/root}#
   
A ZFS támogatás a Solaris 10 Update 2-ben került be.
+
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. UPDATE: az Oracle megváltoztatta a licenszelést, így nem járnak hozzá patch-ek, csak érvényes support szerződés esetén.
  +
  +
A ZFS támogatás a Solaris 10 Update 2-ben került be.
   
===Felhasználása===
+
==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 Solaris kitűnő SMP képességekkel rendelkezik, kitűnőek skálázódik a többprocesszoros rendszerekre 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.
+
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.
   
 
==Támogatott architektúrák==
 
==Támogatott architektúrák==
A Solaris 10 a következő platformokon fut:
+
* Sun SPARC
+
A Solaris 10 a következő platformokon fut:
* x86
+
Sun SPARC
* x86_64
+
x86
+
x86_64
==Solaris virtualizációs technológiák==
+
+
=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.
 
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
{| border="1" style="text-align:center"
+
Sparc64 Sparc64-VII 4 2 Dynamic domains (+ zones) elektronical- , kernel-level- , userspace-, filesystem-, network-stack-separation
|+CPU architectures
+
CMT (Coolthread series) T2, T2Plus 8 8 LDOMs (+ zones) kernel-level-, userspace-, filesystem-, network-stack-separation
| CPU arch
+
x86 Nehalem-series 4 2 Zones userspace-, (optional) filesystem-, (optional) network-stack-separation
| 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
 
|}
 
<br>
 
 
x86-on meg tervben volt egy Xen alapú virtualizació (Solarissal a dom0-ban), de ezt a termékvonalat leállították.
 
x86-on meg tervben volt egy Xen alapú virtualizació (Solarissal a dom0-ban), de ezt a termékvonalat leállították.
+
===Dynamic domains===
+
+
==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.
+
  +
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.
   
 
===Logical domainek, LDOMok===
 
===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.
  +
  +
  +
=Solaris Containers - zónák=
  +
  +
A Solaris legegyszerűbb, és ezzel együtt legrugalmasabb operációs rendszerszintű 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. Elérhető mind x86(_64), mind SPARC platformon.
  +
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 (GZ-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). Mi itt kizárólag az x86(_ 64bit) architechtúrán futtatott Solaris zónákkal foglalkozunk.
  +
  +
==Erőforrás-kezelés==
  +
  +
A virtualizáció egyik fő motivációja a hatékonyabb erőforrás-kihasználás. Mivel a Containers technológia operációs rendszer virtualizációs technológia, ezért az egyes zónák a telepítés és a futás során sokmindent örököl(het)nek az őket futtató GZ-től. A GZ-ből lehet delegálni erőforrásokat az egyes zónáknak . Az erőforrások lehetnek:
  +
  +
Fizikai jellegűek:
  +
  +
-CPU-k, CPU-set-ek
  +
-memória,swap, locked memory
  +
-hálózati interface
  +
-device (valamilyen hardware eszköz) .
  +
  +
Logikai jellegűek:
  +
-ütemezési osztály (scheduling-class)
  +
-lwps
  +
-brand
  +
  +
A NGZ konfigurációját a "zonecfg" parancssori eszköz segíti, amelynek segítségével a zónákhoz erőforrásokat és korlátozásokat rendelhetünk. Az egyes limitációk megadásakor definiálásra kerül az is, hogy mi történjen akkor, hogyha az NGZ eléri a korlátot (pl. ha előre definiáljuk, hogy 500 process lehet a zónában, akkor mi történjen, ha elindulna a az 501.). Az egyes erőforrások definiálása során lehetőség van arra is, hogy az erőforrásokat a rendszer a zóna indulásakor előre lefoglalja (pl a locked-memory esetén). Minden zóna csak azokat az erőforrásokat használhatja fel, amelyeket neki használatra engedélyeztünk, ezek módosítására csak a GZ-ből van lehetőség.(Kivéva brand-et, azt a zóna telepítése után már nem tudjuk megváltoztatni, hiszen maga a telepítés is függ magától a brand-től)
  +
  +
===CPU-set-ek===
  +
  +
A CPU-set-ek olyan egységek, amelyeket többprocesszoros rendszerekben definiálhatunk, segítségükkel a processzorokat "particionálhatjuk" úgy, hogy az egyes processzor magokat egy cpu- set-be tesszük. Ezek a set-ek globális szinten érvényesek. Lehetőség van az egyes set-eket zónákhoz rendelni, így az dedikált CPU erőforrást kap (ezután még természetesen definiálhatunk olyan resource-control-t, hogy ezeknek max pl. 50%-át használhatja ki). Lehetőség van egy CPU-set több zónához történtő dedikálására is.
  +
  +
===Memória===
  +
  +
A memória erőforrásokat a zóna bootolásakor a GZ az NGZ rendelkezésére bocsátja, az előre definiált mértékig. Az NGZ ezután természetesen annyit lát, amennyit a konfiguráció során megadtunk neki. Amennyiben nem difiniáltunk locked-memory-t, akkor az induláskor nem a teljes memória-területet foglalja le. Ez abban az esetben lehet fontos, ha a zónáknak több memória van kiosztva, mint amennyi fizikailag a rendelkezésünkre áll. Ekkor, ha van egy olyan zónánk, amelyben kiemelt fontosságú, hogy mindig rendelkezésére álljon adott mennyiségű memória, akkor a locked-memory mechanizmussal ezt a mennyiséget a GZ fenntartja a kiemelt NGZ számára, megelőzve ezzel a versenyhelyzetek kialakulását.
  +
  +
===Scheduler===
  +
  +
A scheduler a kernel ütemező programja, amely a folyamatok számára biztosítja az optimális erőforráshoz jutást. A zónák esetében a konfiguráció során ki kell jelölni a zóna számára az ütemezési osztályt. A Solaris alapértelmezett ütemezője az TS, a TimeShare, amely a folyamatok egyenlő CPU-hoz jutását helyezi előtérbe. Zónák esetében az FSS (Fair-Share Scheduler) használata javasolt.
  +
  +
===Hálózati interface-ek===
  +
  +
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 GZ 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 interface 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, a kettő együtt nem működik.
  +
A zónáknak az esetek túlnyomó többségében logikai interface-t definiálunk. A fizikai interface dedikálása csak abban az esetben javasolt, ha az NGZ-nek saját routing táblára van szüksége (pl. static route-ok esetén), egyedi, a GZ-től független tűzfalrendszert akarunk kialakítani, esetleg valamilyen VPN megoldást (pl. IPSec) veszünk igénybe (vagy nyújtunk) az NGZ-ben. Logikai NIC esetén az interface megjelenik a NGZ-ben, mint fizikai interface, a GZ-ben pedig mint logikai interface, ezért a GZ-ból lehetőség van arra, hogy az adott interface-en műveleteket végezzünk, pl. az interface lekonfigurálása. A NGZ-ben az interface adatainak megváltoztatására nincs lehetőség:
  +
-nem lehet az IP címet átírni
  +
-nem lehet a netmask-ot módosítani
  +
-nem lehet routing táblában bejegyzést módosítani, felvenni vagy törölni
  +
-nem lehet az interface lekonfigurálni
  +
-nem lehet más beállításait módosítani (pl. az MTU értéket)
  +
  +
Minden esetben a parancs "permission denied" hibaüzenettel tér vissza.
  +
  +
===Fájlrendeszer-konfiguráció===
  +
  +
A Solaris esetében a fájlrendszerek adminisztrációját a ZFS nagyban megkönnyíti. A ZFS magában foglalja a logikai kötetkezelést és a fájlrendszerek kezelését is, ezért a "zfs" és "zpool" parancsokkal gyakorlatilag minden fájlrendszerrel kapcsolatos művelet könnyedén elvégezhető. A zónáknak ajánlatos külön zpool-t létrehozni a könnyebb és áttekinthetőbb kezelés érdekében. Amennyiben ez nem áll rendelkezésünkre, akkor érdemes csinálni egy külön ZFS-t erre a célra, amelybe összegyűjthetjük a zónák számára kiadott ZFS volume-okat, hiszen minden ZFS akár funkcionálhat úgy is, mintha az LVM esetén egy VG-ről beszélnénk, holott LV is egyben.
  +
Az egyes ZFS fájlrendszerekre szintén bevezethetünk korlátozásokat, ezek a zóna számára transzparens módon jutnak érvényre.
  +
A zóna telepített mérete függ a zóna jellegétől, ha sparse zónát telepítünk, annak mérete kb. 70 MB, köszönhetően annak, hogy a legtöbb fájlt a GZ-től örökli. Whole root zóna esetén, függően a GZ-be telepített szoftverektől (és azok méretéről), akár GB-os nagyságrendbe is eshet.
  +
A beállítástól függően a NGZ örökölhet fájlrendszereket vagy könyvtárakat a global zónától, pl. SUNWdefault esetén:
  +
• Usr
  +
• Platform
  +
• Lib
  +
• Sbin
   
(aktuális terméknév: Oracle VM Server for SPARC)
+
Ezeket natív zóna esetén nem célszerű megváltoztatni, mivel ezekben a könyvtárakban olyan alapvető binárisok és libary-k vannak, amelyek minden zónában ugyanazok lennének, ha nem örökönék őket a globaltol. Az örökléssel egyrészt helyet takarítunk meg, másrészt központosítva lehet ezeket a könyvtárakat kezelni a global zónából, mivel ezek a zónákban csak olvasható módban mount- olódnak, ez hasonló a linux bind mount-jához. Ennek segítségével a zónák patch-elése is jóval kevesebb időt vesz igénybe, mivel csak egy helyen kell a patch-eket telepíteni. A Solaris 10 újabb verzióiban a patch-elési mechanizmus megújításra került, ezért a zónákat már lehet párhuzamosan patchelni, ezt régebben csak úgy lehetett megtenni, ha minden zónára külön kézzel alkalmaztuk a patch-eket. Ez több sok zóna esetén akár több órát is igénybe vehet(ett).
  +
A zónákban character/block device-ok létrehozására nincs lehetőség a klasszikus unix-os eszközökkel (pl. mknod).
  +
Amennyiben a zónák azonos szolgáltatás-csomagokat futtatnak, célszerű a /opt könyvtárat is örökíteni a global-ból, olyan esetben is hasznos alkalmazni, ha a zóna felügyeletét másra bízzuk, ám a szoftverek/csomagok verziókezelését és frissítéseit központilag kívánjuk megoldani.
   
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.
 
   
===Solaris Containers - zónák ===
+
==Brand-ek==
+
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>
+
Habár minden zóna közös kernelt használ, további lehetőségek állnak rendelkezésre arra, hogy a rendszeren a környezet a lehető legjobban megfeleljen a NGZ-ben futó operációs rendszernek (amely lehet akár Linux is). Ezeket a környezeteket hívjuk együttesen brand-eknek, amelyek lehetnek rendszerhívásokat emuláló-k is.
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 (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 featúrák a következők:
+
Nem emulál rendszerhívásokat a
  +
- natív (vagy „native”), ez a solaris-ban az alapértelmezett, ha nem adunk meg mást, ez kerül telepítésre
  +
- labeled Solaris Trusted Extensions könyezetben
  +
- cluster, ha a zónát cluster-elni szeretnénk
  +
- létezik még az „ipkg” is, amely az OpenSolaris alapértelmezett brand-je volt
   
====Hálózati konfiguráció====
+
Rendszerhívásokat aznál a brand-eknél kell emulálni, ahol a kernel elétér a GZ-ben futtatottól:
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).
+
- „solaris8” és „solaris9” , ezeknél a kernelverzió 5.8 ill. 5.9 , ezeknél a rendszerhívások nem egyeznek meg a 5.10-essel. E két brand-et általában régi Solaris-ra írt szoftverekkel való kompatibilitás és futtathatóság miatt szokták alkalmazni (nem biztos, hogy az alkalmazásunk rendesen fut 5.10 alatt, mert pl. speciális rendszerhívásokat használ)
  +
- lx, amely brand a linux guest-ek számára tartalmaz alapkönyvtárakat (elsősorban természetesen RedHat-hez és 1-2 származékához (pl. Centos5 kitűnően tud futni, de egy natív zónához képest pl. 5-10%-kal nagy overheaddel jár)
  +
- OpenSolaris-ban létezik egy sol10brand, amely Solaris környezetet biztosít (az OpenSolaris és Solaris rendszerhívások közti megfeleltetésekkel együtt), elsősorban migrációhoz
   
További tudnivalók:
+
==Zónák telepítése a gyakorlatban==
+
* Fizikai interfészek használata esetén azokra a zónán belül húzhatunk fel logikai interfészeket.
+
Az NGZ-k konfigurálását a GZ-ből elérhető "zonecfg" parancssori program segítségével végezhetjük:
* 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.
+
<pre>
* 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.
+
-interaktívan módon (minden paramétert kézzel írunk be)
+
-előre megírt parancsokat tartalmazó fájlból a "-f" kapcsolóval (előnyös lehet, ha sok zónát akarunk telepíteni és előtte pl. bash scripttel létrehozzuk ezeket)
====Fájlrendeszer-konfiguráció====
+
-template-ek segítségével .
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:
+
</pre>
+
A konfiguráció hatására a /etc/zones/ könyvtár alatt létrejön egy XML dokumentum, amelyben a konfiguráció megtalálható. Minden zónához létrejön egy külön XML file.
* 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
+
Nézzük meg a SUNWdefault.xml file tartalmát:
* 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.
+
<?xml version="1.0"?>
+
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.
+
<!-- Copyright 2005 Sun Microsystems, Inc. All rights reserved.
+
Use is subject to license terms.
====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?
+
ident "@(#)SUNWdefault.xml 1.2 07/01/14 SMI"
+
=====Hálózat=====
+
DO NOT EDIT THIS FILE. Use zonecfg(1M) instead. -->
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.
+
+
<!DOCTYPE zone PUBLIC "-//Sun Microsystems Inc//DTD Zones//EN" "file:///usr/share/lib/xml/dtd/zonecfg.dtd.1">
=====Processzor=====
+
* CPUsetek
+
<zone name="default" zonepath="" autoboot="false">
* CPUpoolok
+
<inherited-pkg-dir directory="/lib"/>
* FSS
+
<inherited-pkg-dir directory="/platform"/>
+
<inherited-pkg-dir directory="/sbin"/>
=====Memória=====
+
<inherited-pkg-dir directory="/usr"/>
* RCAP, swap, RAM
+
</zone>
  +
  +
Az XML file-ban található egy figyelmeztetés, hogy ne az xml file-ok szerkesztésével változtassuk meg az értékeket, hanem a zonecfg parancsot használjuk. Ez fontos tanács!
  +
  +
A deklarációkban az egyes direktívák az XML szabvány szintaxisa szerint jelennek meg, az itt találhatóak a következő jelentéssel bírnak:
  +
-zone name : a zóna neve, amely alapján hivatkozhatunk erre a zónára, pl a zoneadm vagy a zonecfg parancsban
  +
-zonepath: a zóna file-rendszerének mount point-ja a GZ könyvtárstruktúrájában
  +
-autoboot: az adott NGZ a GZ bootolásakor elinduljon-e (true => igen, false =>nem).
  +
-inherited-pkg-dir direktívával adhatunk meg könyvtárakat, amelyeket a NGZ read-only módban felcsatol a megegyező könyvtárba (pl. a /platform a NGZ /platform könyvtárába mount- olódik read-only módban)
  +
  +
Nézzünk egy teljes zóna telepítést az alapoktól!
  +
  +
A zóna neve legyen "slave".
  +
  +
A zóna telepítéséhez először vizsgáljuk meg, hogy áll-e rendelkezésre ZFS pool illetve milyen a jelenlegi állapota:
  +
  +
root@solaris10:{/etc}# zpool list
  +
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
  +
rpool 464G 59.8G 404G 12% ONLINE -
  +
root@solaris10:{/etc}#
  +
  +
  +
Látható, hogy az "rpool" nevű zpool rendelkezésre áll. Amennyiben részletesebb információt szeretnénk kérni, a "list" helyett a "status" argumentumot kell megadni:
  +
  +
root@solaris10:{/etc}# zpool list
  +
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
  +
rpool 464G 59.8G 404G 12% ONLINE -
  +
root@solaris10:{/etc}# zpool status
  +
pool: rpool
  +
state: ONLINE
  +
scrub: none requested
  +
config:
  +
  +
NAME STATE READ WRITE CKSUM
  +
rpool ONLINE 0 0 0
  +
mirror ONLINE 0 0 0
  +
c0t0d0s0 ONLINE 0 0 0
  +
c0t1d0s0 ONLINE 0 0 0
  +
  +
errors: No known data errors
  +
root@solaris10:{/etc}#
  +
  +
  +
Ebből a kimenetből látható, hogy egy RAID1 felett működő ZPOOL-lal van dolgunk.
  +
Következő lépésben meg kell nézni, hogy az adott zónához létezik e már ZFS, lehetőleg olyan nevet válasszunk a ZFS-nek, amely alapján egyszerűen és egyértelműen tudjuk azonosítani.
  +
  +
root@solaris10:{/etc}# zfs list
  +
NAME USED AVAIL REFER MOUNTPOINT
  +
rpool 75.8G 381G 34K /rpool
  +
rpool/ROOT 6.86G 381G 21K legacy
  +
rpool/ROOT/s10x_u8wos_08a 6.86G 381G 6.86G /
  +
rpool/dump 40.0G 381G 40.0G -
  +
rpool/export 10.6G 381G 23K /export
  +
rpool/export/home 10.6G 381G 10.6G /export/home
  +
rpool/swap 16G 397G 16K -
  +
rpool/zones 2.32G 381G 24K /zones
  +
rpool/zones/zone1 1.16G 14.8G 1.16G /zones/zone1
  +
rpool/zones/zone2 1.16G 18.8G 1.16G /zones/zone2
  +
root@solaris10:{/etc}#
  +
  +
Látható, hogy nincs ilyen ZFS. (Nagy kimenet esetén "|grep"-pel érdemes keresni.)
  +
  +
Hozzunk létre egy ZFS-t az új zónának a "zones" nevű ZFS-en belül(!), állítsuk be a mountpoint-ot /zones/slave-re és állítsunk be 17G méretkorlátot rá:
  +
  +
root@solaris10:{/etc}# zfs create rpool/zones/slave
  +
root@solaris10:{/etc}# zfs set mountpoint=/zones/slave rpool/zones/slave
  +
root@solaris10:{/etc}# zfs set quota=17G rpool/zones/slave
  +
  +
Nézzük meg milyen attribútumokkal rendelkezik a filerendszerünk:
  +
  +
root@solaris10:{/etc}# zfs get all rpool/zones/slave
  +
NAME PROPERTY VALUE SOURCE
  +
rpool/zones/slave type filesystem -
  +
rpool/zones/slave used 21K -
  +
rpool/zones/slave available 17.0G -
  +
rpool/zones/slave referenced 21K -
  +
rpool/zones/slave compressratio 1.00x -
  +
rpool/zones/slave mounted yes -
  +
rpool/zones/slave quota 17G local
  +
rpool/zones/slave reservation none default
  +
rpool/zones/slave recordsize 128K default
  +
rpool/zones/slave mountpoint /zones/slave local
  +
rpool/zones/slave sharenfs off default
  +
rpool/zones/slave checksum on default
  +
rpool/zones/slave compression off default
  +
rpool/zones/slave atime on default
  +
rpool/zones/slave devices on default
  +
rpool/zones/slave exec on default
  +
rpool/zones/slave setuid on default
  +
rpool/zones/slave readonly off default
  +
rpool/zones/slave zoned off default
  +
rpool/zones/slave snapdir hidden default
  +
rpool/zones/slave aclmode groupmask default
  +
rpool/zones/slave aclinherit restricted default
  +
rpool/zones/slave canmount on default
  +
rpool/zones/slave shareiscsi off default
  +
rpool/zones/slave xattr on default
  +
rpool/zones/slave copies 1 default
  +
rpool/zones/slave version 4 -
  +
rpool/zones/slave utf8only off -
  +
rpool/zones/slave normalization none -
  +
rpool/zones/slave casesensitivity sensitive -
  +
rpool/zones/slave vscan off default
  +
rpool/zones/slave nbmand off default
  +
rpool/zones/slave sharesmb off default
  +
rpool/zones/slave refquota none default
  +
rpool/zones/slave refreservation none default
  +
rpool/zones/slave primarycache all default
  +
rpool/zones/slave secondarycache all default
  +
rpool/zones/slave usedbysnapshots 0 -
  +
rpool/zones/slave usedbydataset 21K -
  +
rpool/zones/slave usedbychildren 0 -
  +
rpool/zones/slave usedbyrefreservation 0 -
  +
root@solaris10:{/etc}#
  +
  +
Látható, hogy sok beállítás létezik, ezek módosíthatóak még a zóna telepítése előtt, így teljesen transzparens lesz a zóna számára pl. a quota vagy a tömörítés.
  +
  +
Ennyi előkészítés után kezdjuk meg a zóna konfigurációját a "zonecfg" parancs megfelelő argumentumaival:
  +
  +
root@solaris10:{/etc}# zonecfg -z slave
  +
slave: No such zone configured
  +
Use 'create' to begin configuring a new zone.
  +
zonecfg:slave>
  +
  +
Ezzel még a zóna konfigurációs állománya nem jött létre, csak a rendszer megkezdett egy új konfigurációt, ám ha ezt nem mentjük el a későbbiek folyamán, akkor a rendszer eldobja.
  +
A zonecfg használata során bármikor kiadhatjuk a "?" parancsot, amelynek hatására megjelenik a súgó (angol nyelven természetesen), a TAB hatására (hasonlóan a bash-completion-hoz, a kiadható parancsok listáját, illetve azok kiegészítését jeleníti meg a program).
  +
  +
zonecfg:slave>
  +
add clear commit create delete exit export help info remove revert select set verify
  +
zonecfg:slave> add
  +
add attr add capped-memory add dedicated-cpu add fs add net
  +
add capped-cpu add dataset add device add inherit-pkg-dir add rctl
  +
zonecfg:slave> cle
  +
clear autoboot clear ip-type clear max-msg-ids clear max-shm-memory
  +
clear bootargs clear limitpriv clear max-sem-ids clear pool
  +
clear cpu-shares clear max-lwps clear max-shm-ids clear scheduling-class
  +
zonecfg:slave> select
  +
select attr select capped-memory select dedicated-cpu select fs select net
  +
select capped-cpu select dataset select device select inherit-pkg-dir select rctl
  +
zonecfg:slave> set
  +
set autoboot= set cpu-shares= set max-lwps= set max-shm-ids= set scheduling-class=
  +
set bootargs= set ip-type= set max-msg-ids= set max-shm-memory= set zonename=
  +
set brand= set limitpriv= set max-sem-ids= set pool= set zonepath=
  +
zonecfg:slave>
  +
  +
Korfigurálás során ezeket a parancsoat használhatjuk fel a különböző beállítások és tulajdonságok módosítására.
  +
  +
Add - egy erőforrás vagy eszköz hozzárendelése a zónához
  +
Cancel - egy erőforrás/beállítás-t töröl
  +
Clear - egy beállítás értékeit törli
  +
Commit - a konfiguráció rögzítése/elmentése (nem történik ellenőrzés az konfiguráció szintaxisára nézve)
  +
Create - ez létrehozza tulajdonképpen a konfigurációt (mentés nem történik, csak szerkesztésre hozza létre), "-a"-val egy lecsatolt zónautvonal alapján hozható létre konfiguráció, "-b" hatására egy "üres" jön létre, míg argumentum nélkül a "default" alapkonfiguráció töltődik be. Érdemes megjegyezni a -t kapcsolód, ekkor előre definiált template alapján lehet zónákat létrehozni, ez fontos lehet automatizált vagy nagy mennyiségű zóna létrehozásakor.
  +
Delete - az egész konfigurációt törli
  +
End - egy alszakasz mentése és visszatérés az előző menübe
  +
Exit - kilép a program
  +
Info - az aktuálisan beállított értékekről egy összefoglalást jelenít meg
  +
Remove - egy erőforrást lehet törölni vele
  +
Revert - a konfiguráció visszagörgethető az utolsó mentett (commited) állapotba
  +
Select - kiválasztható egy erőforrás, amelyet módosítani szeretnénk
  +
Set - egy értéket be lehet vele állítani
  +
Verify - ennek hatására a program ellenőrzi, hogy van-e valamilyen hiba a konfigurációban, esetleg egy szükséges értéket nem állítottunk-e be. Szükség esetén figyelmeztet. Csak hibátlan "verify" esetén engedi a "commit" műveletet végrehajtani.
  +
  +
  +
Elsőként állítsuk be a zóna nevét, amellyel hivatkozni tudunk rá:
  +
zonecfg:slave> set zonename=slave
  +
  +
Elinduljon a zóna a GZ indulásakor?
  +
zonecfg:slave> set autoboot=true
  +
  +
Hol legyen a zóna a GZ filrendszerének hierarchiájában?
  +
zonecfg:slave> set zonepath=/zones/slave
  +
  +
Ezzel jeleztük a rendszernek, hogy az előbb elkészített ZFS volume-ra telepítsen.
  +
  +
Az ütemezőnek válasszuk az FSS-t:
  +
  +
zonecfg:slave> set scheduling-class=FSS
  +
  +
Érdemes a NGZ-nek hálózati interface-t adni, ellenkező esetben nem tudunk rajta hálózati szolgáltatásokat nyújtani:
  +
  +
  +
zonecfg:slave> add net
  +
zonecfg:slave:net> set physical=bge0 # A GZ melyik interface-én keresztül fogja tudni az NGZ elérni a hálózatot
  +
zonecfg:slave:net> set address=152.66.220.94 # IP cím beállítása
  +
zonecfg:slave:net> set defrouter=152.66.220.126 # Gateway beállítása
  +
zonecfg:slave:net> end
  +
  +
A zóna első indítása után ezek az értékek megváltoztathatóak egy next-next-finish jellegű konfiguráció során. Itt csak a rend kedvéért szerepelnek.
  +
  +
Adjunk a zónának CPU limitet, max 30% -ot használhat az összes CPU erőforrásból.
  +
  +
zonecfg:slave> add rctl
  +
zonecfg:slave:rctl> set name=zone.cpu-shares
  +
zonecfg:slave:rctl> add value (priv=privileged,limit=30,action=none)
  +
zonecfg:slave:rctl> end
  +
zonecfg:slave>
  +
  +
512MB memória elég lesz, ugyanennyi swap:
  +
  +
zonecfg:slave> add capped-memory
  +
zonecfg:slave:capped-memory> set swap=512M
  +
zonecfg:slave:capped-memory> set physical=512M
  +
zonecfg:slave:capped-memory> end
  +
zonecfg:slave>
  +
  +
Maximalizáljuk a zónában futtatható folyamatok számát 600-ban és a további folyamatok elindulását ne engedélyezzük:
  +
  +
zonecfg:slave> add rctl
  +
zonecfg:slave:rctl> set name=zone.max-lwps
  +
zonecfg:slave:rctl> add value(priv=privileged,limit=600,action=deny)
  +
zonecfg:slave:rctl> end
  +
  +
Ellenőrizzük a beállított értékeket:
  +
  +
zonecfg:slave> info
  +
zonename: slave
  +
zonepath: /zones/slave
  +
brand: native
  +
autoboot: true
  +
bootargs:
  +
pool:
  +
limitpriv:
  +
scheduling-class: FSS
  +
ip-type: shared
  +
[max-lwps: 600]
  +
inherit-pkg-dir:
  +
dir: /lib
  +
inherit-pkg-dir:
  +
dir: /platform
  +
inherit-pkg-dir:
  +
dir: /sbin
  +
inherit-pkg-dir:
  +
dir: /usr
  +
net:
  +
address: 152.66.220.94
  +
physical: bge0
  +
defrouter: 152.66.220.126
  +
capped-memory:
  +
physical: 512M
  +
[swap: 512M]
  +
rctl:
  +
name: zone.cpu-shares
  +
value: (priv=privileged,limit=30,action=none)
  +
rctl:
  +
name: zone.max-swap
  +
value: (priv=privileged,limit=536870912,action=deny)
  +
rctl:
  +
name: zone.max-lwps
  +
value: (priv=privileged,limit=600,action=deny)
  +
  +
Ezután "commit"-oljuk a változásokat és lépjünk ki.
  +
  +
Nézzük meg, hogy az új zóna milyen státuszban van:
  +
  +
root@solaris10:{/etc}# zoneadm list -vic
  +
ID NAME STATUS PATH BRAND IP
  +
0 global running / native shared
  +
2 zone1 running /zones/zone1 native shared
  +
6 zone2 running /zones/zone2 native shared
  +
- slave configured /zones/slave native shared
  +
root@solaris10:{/etc}#
  +
  +
Ezek szerint konfigurált állapotban van, ami azt jelenti, hogy készen áll a telepítésre.
  +
Már csak a /zones/slave könyvtár jogait kell beállítani :
  +
  +
root@solaris10:{/}# chmod -R 700 /zones/slave/
  +
  +
Telepítsük a zónát:
  +
  +
A telepítés kb. 5 percet vesz igénybe. Ezután a zóna "installed" állapotba lép.
  +
  +
Boot-oljuk be a zónát:
  +
  +
root@solaris10:{/}# zoneadm -z slave boot
  +
  +
Belépni a zónába a "zlogin" paranccsal lehet. Első indításkor végig kell menni egy beállító menün (zlogin -C), amelyben az alapvető beállításokat (IP, search domain, DNS/NIS szerver, NFS szerver, Kerberos, root jelszó, stb) lehet megtenni.
  +
  +
Ezután beléphetünk a zónába és megkezdhetük a munkát!
  +
  +
További információk a zónáról:
  +
-a telepítés során a felhasználók nem kerülnek át a GZ-ből, kezdetben csak a root tud beléni
  +
-az SMF beállításokat a GZ-től örökli, csakúgy mint a telepített csomagokat
  +
-NGZ-ből nem látható a GZ (sem eszközök, sem mount-olt device-ok)
  +
-a NGZ rendelkezik saját init-tel, de annak PID-je nem 1, a PID a GZ-ben /sbin/init-ként jelenik meg, amely egy "zsched" process gyermekeként szerepel

A lap 2011. január 21., 13:14-kori változata

Tartalomjegyzék

1 Solaris virtualizációs megoldások

1.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:

root@solaris10:{/root}# uname -srv
SunOS 5.10 Generic_141445-09
root@solaris10:{/root}#

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. UPDATE: az Oracle megváltoztatta a licenszelést, így nem járnak hozzá patch-ek, csak érvényes support szerződés esetén.

A ZFS támogatás a Solaris 10 Update 2-ben került be.

1.2 Felhasználása

A Solaris kitűnő SMP képességekkel rendelkezik, kitűnőek skálázódik a többprocesszoros rendszerekre 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.

1.3 Támogatott architektúrák

A Solaris 10 a következő platformokon fut: Sun SPARC x86 x86_64

2 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.


2.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.

2.1.1 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 Solaris Containers - zónák

A Solaris legegyszerűbb, és ezzel együtt legrugalmasabb operációs rendszerszintű 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. Elérhető mind x86(_64), mind SPARC platformon. 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 (GZ-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). Mi itt kizárólag az x86(_ 64bit) architechtúrán futtatott Solaris zónákkal foglalkozunk.

3.1 Erőforrás-kezelés

A virtualizáció egyik fő motivációja a hatékonyabb erőforrás-kihasználás. Mivel a Containers technológia operációs rendszer virtualizációs technológia, ezért az egyes zónák a telepítés és a futás során sokmindent örököl(het)nek az őket futtató GZ-től. A GZ-ből lehet delegálni erőforrásokat az egyes zónáknak . Az erőforrások lehetnek:

Fizikai jellegűek:

-CPU-k, CPU-set-ek -memória,swap, locked memory -hálózati interface -device (valamilyen hardware eszköz) .

Logikai jellegűek: -ütemezési osztály (scheduling-class) -lwps -brand

A NGZ konfigurációját a "zonecfg" parancssori eszköz segíti, amelynek segítségével a zónákhoz erőforrásokat és korlátozásokat rendelhetünk. Az egyes limitációk megadásakor definiálásra kerül az is, hogy mi történjen akkor, hogyha az NGZ eléri a korlátot (pl. ha előre definiáljuk, hogy 500 process lehet a zónában, akkor mi történjen, ha elindulna a az 501.). Az egyes erőforrások definiálása során lehetőség van arra is, hogy az erőforrásokat a rendszer a zóna indulásakor előre lefoglalja (pl a locked-memory esetén). Minden zóna csak azokat az erőforrásokat használhatja fel, amelyeket neki használatra engedélyeztünk, ezek módosítására csak a GZ-ből van lehetőség.(Kivéva brand-et, azt a zóna telepítése után már nem tudjuk megváltoztatni, hiszen maga a telepítés is függ magától a brand-től)

3.1.1 CPU-set-ek

A CPU-set-ek olyan egységek, amelyeket többprocesszoros rendszerekben definiálhatunk, segítségükkel a processzorokat "particionálhatjuk" úgy, hogy az egyes processzor magokat egy cpu- set-be tesszük. Ezek a set-ek globális szinten érvényesek. Lehetőség van az egyes set-eket zónákhoz rendelni, így az dedikált CPU erőforrást kap (ezután még természetesen definiálhatunk olyan resource-control-t, hogy ezeknek max pl. 50%-át használhatja ki). Lehetőség van egy CPU-set több zónához történtő dedikálására is.

3.1.2 Memória

A memória erőforrásokat a zóna bootolásakor a GZ az NGZ rendelkezésére bocsátja, az előre definiált mértékig. Az NGZ ezután természetesen annyit lát, amennyit a konfiguráció során megadtunk neki. Amennyiben nem difiniáltunk locked-memory-t, akkor az induláskor nem a teljes memória-területet foglalja le. Ez abban az esetben lehet fontos, ha a zónáknak több memória van kiosztva, mint amennyi fizikailag a rendelkezésünkre áll. Ekkor, ha van egy olyan zónánk, amelyben kiemelt fontosságú, hogy mindig rendelkezésére álljon adott mennyiségű memória, akkor a locked-memory mechanizmussal ezt a mennyiséget a GZ fenntartja a kiemelt NGZ számára, megelőzve ezzel a versenyhelyzetek kialakulását.

3.1.3 Scheduler

A scheduler a kernel ütemező programja, amely a folyamatok számára biztosítja az optimális erőforráshoz jutást. A zónák esetében a konfiguráció során ki kell jelölni a zóna számára az ütemezési osztályt. A Solaris alapértelmezett ütemezője az TS, a TimeShare, amely a folyamatok egyenlő CPU-hoz jutását helyezi előtérbe. Zónák esetében az FSS (Fair-Share Scheduler) használata javasolt.

3.1.4 Hálózati interface-ek

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 GZ 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 interface 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, a kettő együtt nem működik. A zónáknak az esetek túlnyomó többségében logikai interface-t definiálunk. A fizikai interface dedikálása csak abban az esetben javasolt, ha az NGZ-nek saját routing táblára van szüksége (pl. static route-ok esetén), egyedi, a GZ-től független tűzfalrendszert akarunk kialakítani, esetleg valamilyen VPN megoldást (pl. IPSec) veszünk igénybe (vagy nyújtunk) az NGZ-ben. Logikai NIC esetén az interface megjelenik a NGZ-ben, mint fizikai interface, a GZ-ben pedig mint logikai interface, ezért a GZ-ból lehetőség van arra, hogy az adott interface-en műveleteket végezzünk, pl. az interface lekonfigurálása. A NGZ-ben az interface adatainak megváltoztatására nincs lehetőség: -nem lehet az IP címet átírni -nem lehet a netmask-ot módosítani -nem lehet routing táblában bejegyzést módosítani, felvenni vagy törölni -nem lehet az interface lekonfigurálni -nem lehet más beállításait módosítani (pl. az MTU értéket)

Minden esetben a parancs "permission denied" hibaüzenettel tér vissza.

3.1.5 Fájlrendeszer-konfiguráció

A Solaris esetében a fájlrendszerek adminisztrációját a ZFS nagyban megkönnyíti. A ZFS magában foglalja a logikai kötetkezelést és a fájlrendszerek kezelését is, ezért a "zfs" és "zpool" parancsokkal gyakorlatilag minden fájlrendszerrel kapcsolatos művelet könnyedén elvégezhető. A zónáknak ajánlatos külön zpool-t létrehozni a könnyebb és áttekinthetőbb kezelés érdekében. Amennyiben ez nem áll rendelkezésünkre, akkor érdemes csinálni egy külön ZFS-t erre a célra, amelybe összegyűjthetjük a zónák számára kiadott ZFS volume-okat, hiszen minden ZFS akár funkcionálhat úgy is, mintha az LVM esetén egy VG-ről beszélnénk, holott LV is egyben. Az egyes ZFS fájlrendszerekre szintén bevezethetünk korlátozásokat, ezek a zóna számára transzparens módon jutnak érvényre. A zóna telepített mérete függ a zóna jellegétől, ha sparse zónát telepítünk, annak mérete kb. 70 MB, köszönhetően annak, hogy a legtöbb fájlt a GZ-től örökli. Whole root zóna esetén, függően a GZ-be telepített szoftverektől (és azok méretéről), akár GB-os nagyságrendbe is eshet. A beállítástól függően a NGZ örökölhet fájlrendszereket vagy könyvtárakat a global zónától, pl. SUNWdefault esetén: • Usr • Platform • Lib • Sbin

Ezeket natív zóna esetén nem célszerű megváltoztatni, mivel ezekben a könyvtárakban olyan alapvető binárisok és libary-k vannak, amelyek minden zónában ugyanazok lennének, ha nem örökönék őket a globaltol. Az örökléssel egyrészt helyet takarítunk meg, másrészt központosítva lehet ezeket a könyvtárakat kezelni a global zónából, mivel ezek a zónákban csak olvasható módban mount- olódnak, ez hasonló a linux bind mount-jához. Ennek segítségével a zónák patch-elése is jóval kevesebb időt vesz igénybe, mivel csak egy helyen kell a patch-eket telepíteni. A Solaris 10 újabb verzióiban a patch-elési mechanizmus megújításra került, ezért a zónákat már lehet párhuzamosan patchelni, ezt régebben csak úgy lehetett megtenni, ha minden zónára külön kézzel alkalmaztuk a patch-eket. Ez több sok zóna esetén akár több órát is igénybe vehet(ett). A zónákban character/block device-ok létrehozására nincs lehetőség a klasszikus unix-os eszközökkel (pl. mknod). Amennyiben a zónák azonos szolgáltatás-csomagokat futtatnak, célszerű a /opt könyvtárat is örökíteni a global-ból, olyan esetben is hasznos alkalmazni, ha a zóna felügyeletét másra bízzuk, ám a szoftverek/csomagok verziókezelését és frissítéseit központilag kívánjuk megoldani.


3.2 Brand-ek

Habár minden zóna közös kernelt használ, további lehetőségek állnak rendelkezésre arra, hogy a rendszeren a környezet a lehető legjobban megfeleljen a NGZ-ben futó operációs rendszernek (amely lehet akár Linux is). Ezeket a környezeteket hívjuk együttesen brand-eknek, amelyek lehetnek rendszerhívásokat emuláló-k is.

Nem emulál rendszerhívásokat a - natív (vagy „native”), ez a solaris-ban az alapértelmezett, ha nem adunk meg mást, ez kerül telepítésre - labeled Solaris Trusted Extensions könyezetben - cluster, ha a zónát cluster-elni szeretnénk - létezik még az „ipkg” is, amely az OpenSolaris alapértelmezett brand-je volt

Rendszerhívásokat aznál a brand-eknél kell emulálni, ahol a kernel elétér a GZ-ben futtatottól: - „solaris8” és „solaris9” , ezeknél a kernelverzió 5.8 ill. 5.9 , ezeknél a rendszerhívások nem egyeznek meg a 5.10-essel. E két brand-et általában régi Solaris-ra írt szoftverekkel való kompatibilitás és futtathatóság miatt szokták alkalmazni (nem biztos, hogy az alkalmazásunk rendesen fut 5.10 alatt, mert pl. speciális rendszerhívásokat használ) - lx, amely brand a linux guest-ek számára tartalmaz alapkönyvtárakat (elsősorban természetesen RedHat-hez és 1-2 származékához (pl. Centos5 kitűnően tud futni, de egy natív zónához képest pl. 5-10%-kal nagy overheaddel jár) - OpenSolaris-ban létezik egy sol10brand, amely Solaris környezetet biztosít (az OpenSolaris és Solaris rendszerhívások közti megfeleltetésekkel együtt), elsősorban migrációhoz

3.3 Zónák telepítése a gyakorlatban

Az NGZ-k konfigurálását a GZ-ből elérhető "zonecfg" parancssori program segítségével végezhetjük:

-interaktívan módon (minden paramétert kézzel írunk be)
-előre megírt parancsokat tartalmazó fájlból a "-f" kapcsolóval (előnyös lehet, ha sok zónát akarunk telepíteni és előtte pl. bash scripttel létrehozzuk ezeket)
-template-ek segítségével .

A konfiguráció hatására a /etc/zones/ könyvtár alatt létrejön egy XML dokumentum, amelyben a konfiguráció megtalálható. Minden zónához létrejön egy külön XML file. Nézzük meg a SUNWdefault.xml file tartalmát:

<?xml version="1.0"?>
 

<!DOCTYPE zone PUBLIC "-//Sun Microsystems Inc//DTD Zones//EN" "file:///usr/share/lib/xml/dtd/zonecfg.dtd.1">
 
<zone name="default" zonepath="" autoboot="false">
 <inherited-pkg-dir directory="/lib"/>
 <inherited-pkg-dir directory="/platform"/>
 <inherited-pkg-dir directory="/sbin"/>
 <inherited-pkg-dir directory="/usr"/>
</zone>

Az XML file-ban található egy figyelmeztetés, hogy ne az xml file-ok szerkesztésével változtassuk meg az értékeket, hanem a zonecfg parancsot használjuk. Ez fontos tanács!

A deklarációkban az egyes direktívák az XML szabvány szintaxisa szerint jelennek meg, az itt találhatóak a következő jelentéssel bírnak: -zone name : a zóna neve, amely alapján hivatkozhatunk erre a zónára, pl a zoneadm vagy a zonecfg parancsban -zonepath: a zóna file-rendszerének mount point-ja a GZ könyvtárstruktúrájában -autoboot: az adott NGZ a GZ bootolásakor elinduljon-e (true => igen, false =>nem). -inherited-pkg-dir direktívával adhatunk meg könyvtárakat, amelyeket a NGZ read-only módban felcsatol a megegyező könyvtárba (pl. a /platform a NGZ /platform könyvtárába mount- olódik read-only módban)

Nézzünk egy teljes zóna telepítést az alapoktól!

A zóna neve legyen "slave".

A zóna telepítéséhez először vizsgáljuk meg, hogy áll-e rendelkezésre ZFS pool illetve milyen a jelenlegi állapota:

root@solaris10:{/etc}# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT rpool 464G 59.8G 404G 12% ONLINE - root@solaris10:{/etc}#


Látható, hogy az "rpool" nevű zpool rendelkezésre áll. Amennyiben részletesebb információt szeretnénk kérni, a "list" helyett a "status" argumentumot kell megadni:

root@solaris10:{/etc}# zpool list
NAME    SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
rpool   464G  59.8G   404G    12%  ONLINE  -
root@solaris10:{/etc}# zpool status
 pool: rpool
 state: ONLINE
 scrub: none requested
 config:

        NAME          STATE     READ WRITE CKSUM
        rpool         ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            c0t0d0s0  ONLINE       0     0     0
            c0t1d0s0  ONLINE       0     0     0

errors: No known data errors
root@solaris10:{/etc}#


Ebből a kimenetből látható, hogy egy RAID1 felett működő ZPOOL-lal van dolgunk. Következő lépésben meg kell nézni, hogy az adott zónához létezik e már ZFS, lehetőleg olyan nevet válasszunk a ZFS-nek, amely alapján egyszerűen és egyértelműen tudjuk azonosítani.

root@solaris10:{/etc}# zfs list NAME USED AVAIL REFER MOUNTPOINT rpool 75.8G 381G 34K /rpool rpool/ROOT 6.86G 381G 21K legacy rpool/ROOT/s10x_u8wos_08a 6.86G 381G 6.86G / rpool/dump 40.0G 381G 40.0G - rpool/export 10.6G 381G 23K /export rpool/export/home 10.6G 381G 10.6G /export/home rpool/swap 16G 397G 16K - rpool/zones 2.32G 381G 24K /zones rpool/zones/zone1 1.16G 14.8G 1.16G /zones/zone1 rpool/zones/zone2 1.16G 18.8G 1.16G /zones/zone2 root@solaris10:{/etc}#

Látható, hogy nincs ilyen ZFS. (Nagy kimenet esetén "|grep"-pel érdemes keresni.)

Hozzunk létre egy ZFS-t az új zónának a "zones" nevű ZFS-en belül(!), állítsuk be a mountpoint-ot /zones/slave-re és állítsunk be 17G méretkorlátot rá:

root@solaris10:{/etc}# zfs create rpool/zones/slave root@solaris10:{/etc}# zfs set mountpoint=/zones/slave rpool/zones/slave root@solaris10:{/etc}# zfs set quota=17G rpool/zones/slave

Nézzük meg milyen attribútumokkal rendelkezik a filerendszerünk:

root@solaris10:{/etc}# zfs get all rpool/zones/slave NAME PROPERTY VALUE SOURCE rpool/zones/slave type filesystem - rpool/zones/slave used 21K - rpool/zones/slave available 17.0G - rpool/zones/slave referenced 21K - rpool/zones/slave compressratio 1.00x - rpool/zones/slave mounted yes - rpool/zones/slave quota 17G local rpool/zones/slave reservation none default rpool/zones/slave recordsize 128K default rpool/zones/slave mountpoint /zones/slave local rpool/zones/slave sharenfs off default rpool/zones/slave checksum on default rpool/zones/slave compression off default rpool/zones/slave atime on default rpool/zones/slave devices on default rpool/zones/slave exec on default rpool/zones/slave setuid on default rpool/zones/slave readonly off default rpool/zones/slave zoned off default rpool/zones/slave snapdir hidden default rpool/zones/slave aclmode groupmask default rpool/zones/slave aclinherit restricted default rpool/zones/slave canmount on default rpool/zones/slave shareiscsi off default rpool/zones/slave xattr on default rpool/zones/slave copies 1 default rpool/zones/slave version 4 - rpool/zones/slave utf8only off - rpool/zones/slave normalization none - rpool/zones/slave casesensitivity sensitive - rpool/zones/slave vscan off default rpool/zones/slave nbmand off default rpool/zones/slave sharesmb off default rpool/zones/slave refquota none default rpool/zones/slave refreservation none default rpool/zones/slave primarycache all default rpool/zones/slave secondarycache all default rpool/zones/slave usedbysnapshots 0 - rpool/zones/slave usedbydataset 21K - rpool/zones/slave usedbychildren 0 - rpool/zones/slave usedbyrefreservation 0 - root@solaris10:{/etc}#

Látható, hogy sok beállítás létezik, ezek módosíthatóak még a zóna telepítése előtt, így teljesen transzparens lesz a zóna számára pl. a quota vagy a tömörítés.

Ennyi előkészítés után kezdjuk meg a zóna konfigurációját a "zonecfg" parancs megfelelő argumentumaival:

root@solaris10:{/etc}# zonecfg -z slave slave: No such zone configured Use 'create' to begin configuring a new zone. zonecfg:slave>

Ezzel még a zóna konfigurációs állománya nem jött létre, csak a rendszer megkezdett egy új konfigurációt, ám ha ezt nem mentjük el a későbbiek folyamán, akkor a rendszer eldobja. A zonecfg használata során bármikor kiadhatjuk a "?" parancsot, amelynek hatására megjelenik a súgó (angol nyelven természetesen), a TAB hatására (hasonlóan a bash-completion-hoz, a kiadható parancsok listáját, illetve azok kiegészítését jeleníti meg a program).

zonecfg:slave> add clear commit create delete exit export help info remove revert select set verify zonecfg:slave> add add attr add capped-memory add dedicated-cpu add fs add net add capped-cpu add dataset add device add inherit-pkg-dir add rctl zonecfg:slave> cle clear autoboot clear ip-type clear max-msg-ids clear max-shm-memory clear bootargs clear limitpriv clear max-sem-ids clear pool clear cpu-shares clear max-lwps clear max-shm-ids clear scheduling-class zonecfg:slave> select select attr select capped-memory select dedicated-cpu select fs select net select capped-cpu select dataset select device select inherit-pkg-dir select rctl zonecfg:slave> set set autoboot= set cpu-shares= set max-lwps= set max-shm-ids= set scheduling-class= set bootargs= set ip-type= set max-msg-ids= set max-shm-memory= set zonename= set brand= set limitpriv= set max-sem-ids= set pool= set zonepath= zonecfg:slave>

Korfigurálás során ezeket a parancsoat használhatjuk fel a különböző beállítások és tulajdonságok módosítására.

Add - egy erőforrás vagy eszköz hozzárendelése a zónához Cancel - egy erőforrás/beállítás-t töröl Clear - egy beállítás értékeit törli Commit - a konfiguráció rögzítése/elmentése (nem történik ellenőrzés az konfiguráció szintaxisára nézve) Create - ez létrehozza tulajdonképpen a konfigurációt (mentés nem történik, csak szerkesztésre hozza létre), "-a"-val egy lecsatolt zónautvonal alapján hozható létre konfiguráció, "-b" hatására egy "üres" jön létre, míg argumentum nélkül a "default" alapkonfiguráció töltődik be. Érdemes megjegyezni a -t kapcsolód, ekkor előre definiált template alapján lehet zónákat létrehozni, ez fontos lehet automatizált vagy nagy mennyiségű zóna létrehozásakor. Delete - az egész konfigurációt törli End - egy alszakasz mentése és visszatérés az előző menübe Exit - kilép a program Info - az aktuálisan beállított értékekről egy összefoglalást jelenít meg Remove - egy erőforrást lehet törölni vele Revert - a konfiguráció visszagörgethető az utolsó mentett (commited) állapotba Select - kiválasztható egy erőforrás, amelyet módosítani szeretnénk Set - egy értéket be lehet vele állítani Verify - ennek hatására a program ellenőrzi, hogy van-e valamilyen hiba a konfigurációban, esetleg egy szükséges értéket nem állítottunk-e be. Szükség esetén figyelmeztet. Csak hibátlan "verify" esetén engedi a "commit" műveletet végrehajtani.


Elsőként állítsuk be a zóna nevét, amellyel hivatkozni tudunk rá: zonecfg:slave> set zonename=slave

Elinduljon a zóna a GZ indulásakor? zonecfg:slave> set autoboot=true

Hol legyen a zóna a GZ filrendszerének hierarchiájában? zonecfg:slave> set zonepath=/zones/slave

Ezzel jeleztük a rendszernek, hogy az előbb elkészített ZFS volume-ra telepítsen.

Az ütemezőnek válasszuk az FSS-t:

zonecfg:slave> set scheduling-class=FSS

Érdemes a NGZ-nek hálózati interface-t adni, ellenkező esetben nem tudunk rajta hálózati szolgáltatásokat nyújtani:


zonecfg:slave> add net zonecfg:slave:net> set physical=bge0 # A GZ melyik interface-én keresztül fogja tudni az NGZ elérni a hálózatot zonecfg:slave:net> set address=152.66.220.94 # IP cím beállítása zonecfg:slave:net> set defrouter=152.66.220.126 # Gateway beállítása zonecfg:slave:net> end

A zóna első indítása után ezek az értékek megváltoztathatóak egy next-next-finish jellegű konfiguráció során. Itt csak a rend kedvéért szerepelnek.

Adjunk a zónának CPU limitet, max 30% -ot használhat az összes CPU erőforrásból.

zonecfg:slave> add rctl zonecfg:slave:rctl> set name=zone.cpu-shares zonecfg:slave:rctl> add value (priv=privileged,limit=30,action=none) zonecfg:slave:rctl> end zonecfg:slave>

512MB memória elég lesz, ugyanennyi swap:

zonecfg:slave> add capped-memory zonecfg:slave:capped-memory> set swap=512M zonecfg:slave:capped-memory> set physical=512M zonecfg:slave:capped-memory> end zonecfg:slave>

Maximalizáljuk a zónában futtatható folyamatok számát 600-ban és a további folyamatok elindulását ne engedélyezzük:

zonecfg:slave> add rctl zonecfg:slave:rctl> set name=zone.max-lwps zonecfg:slave:rctl> add value(priv=privileged,limit=600,action=deny) zonecfg:slave:rctl> end

Ellenőrizzük a beállított értékeket:

zonecfg:slave> info zonename: slave zonepath: /zones/slave brand: native autoboot: true bootargs: pool: limitpriv: scheduling-class: FSS ip-type: shared [max-lwps: 600] inherit-pkg-dir:

       dir: /lib

inherit-pkg-dir:

       dir: /platform

inherit-pkg-dir:

       dir: /sbin

inherit-pkg-dir:

       dir: /usr

net:

       address: 152.66.220.94
       physical: bge0
       defrouter: 152.66.220.126

capped-memory:

       physical: 512M
       [swap: 512M]

rctl:

       name: zone.cpu-shares
       value: (priv=privileged,limit=30,action=none)

rctl:

       name: zone.max-swap
       value: (priv=privileged,limit=536870912,action=deny)

rctl:

       name: zone.max-lwps
       value: (priv=privileged,limit=600,action=deny)

Ezután "commit"-oljuk a változásokat és lépjünk ki.

Nézzük meg, hogy az új zóna milyen státuszban van:

root@solaris10:{/etc}# zoneadm list -vic

 ID NAME             STATUS     PATH                           BRAND    IP
  0 global           running    /                              native   shared
  2 zone1            running    /zones/zone1                   native   shared
  6 zone2            running    /zones/zone2                   native   shared
  - slave            configured /zones/slave                   native   shared

root@solaris10:{/etc}#

Ezek szerint konfigurált állapotban van, ami azt jelenti, hogy készen áll a telepítésre. Már csak a /zones/slave könyvtár jogait kell beállítani :

root@solaris10:{/}# chmod -R 700 /zones/slave/

Telepítsük a zónát:

A telepítés kb. 5 percet vesz igénybe. Ezután a zóna "installed" állapotba lép.

Boot-oljuk be a zónát:

root@solaris10:{/}# zoneadm -z slave boot

Belépni a zónába a "zlogin" paranccsal lehet. Első indításkor végig kell menni egy beállító menün (zlogin -C), amelyben az alapvető beállításokat (IP, search domain, DNS/NIS szerver, NFS szerver, Kerberos, root jelszó, stb) lehet megtenni.

Ezután beléphetünk a zónába és megkezdhetük a munkát!

További információk a zónáról: -a telepítés során a felhasználók nem kerülnek át a GZ-ből, kezdetben csak a root tud beléni -az SMF beállításokat a GZ-től örökli, csakúgy mint a telepített csomagokat -NGZ-ből nem látható a GZ (sem eszközök, sem mount-olt device-ok) -a NGZ rendelkezik saját init-tel, de annak PID-je nem 1, a PID a GZ-ben /sbin/init-ként jelenik meg, amely egy "zsched" process gyermekeként szerepel

Személyes eszközök