Solaris virtualizációs megoldások
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
x86-on meg tervben volt egy Xen alapú virtualizació (Solarissal a dom0-ban), de ezt a termékvonalat leállították.
4 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 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 hardware-n futó thin hypervisor kezeli az erőforrásokat a definiált logical domainek között. Ellentétben a dinamikus domainek elektronikus elválasztasaval, itt csak logikailag elhatárolódásról van szó, tehát egy hardwarehiba több ldomot is érinthet. Egy Coolthread CPU 6-8 magos, mindegyik CPU-magon 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, storage-elemeket (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 lehetzó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ési osztálynak 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: 192.168.220.94
physical: bge0
defrouter: 192.168.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:
root@solaris10:{/}# zoneadm -z salve install
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
