Solaris virtualizációs megoldások

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen Sjrextor (vitalap | szerkesztései) 2011. január 21., 13:26-kor történt szerkesztése után volt.

Solaris virtualizációs megoldások


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:

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.

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.

3 Támogatott architektúrák

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

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


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

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


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

5.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)

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

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

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

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

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

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

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