Solaris virtualizációs megoldások

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(→‎Támogatott architektúrák)
 
(3 szerkesztő 46 közbeeső változata nincs mutatva)
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 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:
   
−
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:
 +
root@solaris10:{/root}# uname -srv
−
<pre>
 +
SunOS 5.10 Generic_141445-09
−
-bash-3.00$ uname -sr
 +
root@solaris10:{/root}#
−
SunOS 5.10
  
−
-bash-3.00$
  
−
</pre>
  
   
−
A Solaris 10 2005. január 31.-én jelent meg, olyan újdonságokkal mint a DTrace, az SMF (Service Management Facility, amely az init.d scriptek leváltására jött létre), az NFSv4 vagy a Solaris Containers. Ezen kiadástól kezdve szabadon letölthető - regisztráció után - és szabadon felhasználható az új licencelési struktúrának köszönhetően, ám ehhez csak a negyedéves frissítések és biztonsági javítások járnak.
+
A 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.
   
−
A ZFS támogatás a Solaris 10 Update 2-ben került be.
 +
==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.
   
−
===Felhasználása===
 +
==Támogatott architektúrák==
  +
  +
A Solaris 10 a következő platformokon fut:
  +
*Sun SPARC
  +
*x86
  +
*x86_64
   
−
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.
 +
x86-on meg tervben volt egy Xen alapú virtualizació (Solarissal a dom0-ban), de ezt a termékvonalat leállítottá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.
 +
==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.
   
−
==Támogatott architektúrák==
 +
===Logical domainek, LDOMok===
−
A Solaris 10 a következő platformokon fut:
 +
−
* Sun SPARC
+
(aktuális terméknév: Oracle VM Server for SPARC)
−
* x86
 +
−
* x86_64
 +
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.
  +
  +
=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<br>
  +
*memória,swap, locked memory<br>
  +
*hálózati interface<br>
  +
*device (valamilyen hardware eszköz)<br>
  +
  +
Logikai jellegűek:
  +
*ütemezési osztály (scheduling-class)<br>
  +
*lwps<br>
  +
*brand<br>
  +
  +
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<br>
  +
*nem lehet a netmask-ot módosítani<br>
  +
*nem lehet routing táblában bejegyzést módosítani, felvenni vagy törölni<br>
  +
*nem lehet az interface lekonfigurálni<br>
  +
*nem lehet más beállításait módosítani (pl. az MTU értéket)<br>
  +
  +
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:<br>
  +
*/usr<br>
  +
*/platform<br>
  +
*/lib<br>
  +
*/sbin<br>
  +
  +
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.
  +
  +
==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<br>
  +
*natív (vagy „native”), ez a solaris-ban az alapértelmezett, ha nem adunk meg mást, ez kerül telepítésre<br>
  +
*labeled Solaris Trusted Extensions könyezetben<br>
  +
*cluster, ha a zónát cluster-elni szeretnénk<br>
  +
*létezik még az „ipkg” is, amely az OpenSolaris alapértelmezett brand-je volt<br>
  +
  +
Rendszerhívásokat aznál a brand-eknél kell emulálni, ahol a kernel elétér a GZ-ben futtatottól:<br>
  +
*„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)<br>
  +
*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)<br>
  +
*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<br>
  +
  +
==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"?>
  +
  +
<!-- Copyright 2005 Sun Microsystems, Inc. All rights reserved.
  +
Use is subject to license terms.
  +
  +
ident "@(#)SUNWdefault.xml 1.2 07/01/14 SMI"
  +
  +
DO NOT EDIT THIS FILE. Use zonecfg(1M) instead. -->
  +
  +
<!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)
   
−
==A Solaris Containers technológiáról==
 +
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

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

Solaris virtualizációs megoldások


Tartalomjegyzék

[szerkesztés] 1 A Solarisról általában

A Solaris a Sun Microsystems SVR4 kompabibilis, Unix-ok családjába tartozó operációs rendszere. Jelenlegi legfrissebb kiadása a Solaris 10 10/09, közismertebb nevén a Solaris 10 Update 8. A jelenleg futó kernel verziója: 

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.

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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)

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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

[szerkesztés] 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
A lap eredeti címe: „http://unixlinux.tmit.bme.hu/index.php?title=Solaris_virtualiz%C3%A1ci%C3%B3s_megold%C3%A1sok&oldid=4886”
Személyes eszközök