Solaris virtualizációs megoldások

A Unix/Linux szerverek üzemeltetése wikiből

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
Személyes eszközök