Ha már Solaris akkor tekintsünk kicsit a jelenbe és talán kicsit már a múltba. Konkrétan a Solaris saját Volume Managerére, az SVM-re. A Solaris 10 update6ig kötelezően az SVM volt az alapértelmezett volume kezelője a SUN operációs rendszerének. Röviden tekintsük át, mi is ez és hogy is működik.
Az természetes bármilyen számítógép esetén, hogy „külső” háttértárolóról töltődik be rendszer, és nagy adatainkat is erre a külső diskre írjuk ki, vagy olvassuk be. Viszont amióta adatokat tárolunk, azóta kérdés az adatbiztonság, és emelett a tárolókapacitásunk minél dinamikusabb és jobb kihasználtsága.
Az adatbiztonságról már írtam egy rövid magyarázó cikket itt, és a raid kalkulátorral ezt számosítani is tudjuk itt. Így ezt a tudást nem kívánom újra átvenni.
Alap esetben disk-ek slice-it (szeleteit) tudjuk kezelni, filesystem-et tenni rá, mountolgatni, tehát adatot tárolni rajta. Amennyiben a slice-k méretét akarjuk valahogy módosítgatni, az utólag elég körülményes, és én nem szívesen ajánlom senkinek se, habár aki tudja mit csinál könnyedén megteheti. Arról viszont ne is beszéljünk, hogy nekünk szükségünk lenne adatbiztonságra, vagy tárterületek összevonására, akkor már SVM-hez kell fordulnunk.
Mi is kell az SVM-hez?
Először is szükségünk lesz egy meta adatbázisra. Ez egy olyan „tárterület”, ahol a különböző diskek státusza, információi tárolódnak le, tehát annak a szintnek az agya, ami többlet tudással ruházza fel az egyszerű diskjeink tárkapacitását. Ennek a metaadatbázisnak a helyéről, és létrehozásáról sajnos nekünk kell gondoskodnunk.
Először is létre kell hoznunk manuálisan egy disken egy slice-t. Amit erre a célra fogunk hasznáni. Én 100Mb-ot ajánlok. Ezek után ha már van egy létező slice, amit metadb tárolására akarunk használni, akkor már csak létre kell hoznunk és oda eltárolnunk azokat.
# metadb -a -c 2 c1t3d0s1 # metadb flags first blk block count a u 16 8192 /dev/dsk/c1t3d0s1 a u 8208 8192 /dev/dsk/c1t3d0s1
Ahogy fentebb is látszik a metadb parancs kiadásával tudjuk listázni a meta adatbázis állapotát. A -a kaplcsolóval jelezzük, hogy létre akarunk hozni, a -c 2 pedig az, hogy több példányban is hozza létre ugyan arra a helyre a metaadatbázist. Lehet eset, amikor szükséges a -f kapcsolóval eröltetni a létrehozást.
Most már van meta adatbázisunk, elkezdhetünk csináni meta device-kat. A meta device-k azok a logikai egységek lesznek amivel nevesítjük a logikai (metadevice-ok által generált) világban a tároló kapacitásunkat. Hogy mit is jelent ez egész pontosan?
Egy metadevice egy jelölés, aminek neve van és azonosít egy disk-en lévő slice-t, vagy egy más metadevicek bizonyos összefüggését. A metadevice-k neve akármi lehet. Kiskacsa, kutyafule, mama123, de bevállt konvenció hogy „d” betűvel jelöljük őket és utána számot írunk.
Teszem azt a mi konvenciónk a következő kép néz ki:
d11 – első slice az egyes diskről
d12 – első slice a kettes diskről
d10 – RaidX tömb az első slice-kből
d101 – első slice az egyes storage LUN-on
d201 – második slice a kettes storage LUN-on
Raid 0 – Stripe volume létrehozása
A metainit paranccsal a következő képp lehet egy Raid 0 stripe-t létrehozni:
metainit d20 1 3 c0t1d0s2 c0t2d0s2 c0t3d0s2
Raid 0 – Concat létrehozása
A legegyszerűbb konkatenáció, amivel egy szimpla slice volumet tudunk létrehozni. Ez ugye egy egy elemű Raid0-t fog jelenteni, aminek bár így nincs sok értelme, de további metadevice szerveződés alapelemeként szolgálhat:
# metainit d25 1 1 c0t1d0s2 d25: Concat/Stripe is setup
Persze ezt az egy elemű Raid 0 metadevice tömböt tetszőlegesen online bővíthetjük a következő paranccsal akármikor:
# metattach d25 c1t2d0s2 c1t2d1s2 c1t2d3s2 d25: components are attached
Vagy van lehetőségünk, arra is, hogy egyből egy több mint egy elemű tömböt hozzunk létre egy paranccsal:
# metainit d40 4 1 c0t1d0s2 1 c0t2d0s2 1 c0t2d0s3 1 c0t2d1s3 d40: Concat/Stripe is setup
Ebből már jól látszik a szisztéma. A stripe esetében az első szám mindig 1 a második szám pedig hogy a stripe hány elemű legyen. Míg a concat esetén az első számmal adjuk meg hány elemet fogunk egymás után fűzni, és utána szépen egyesével felsoroljuk a tagokat.
Raid 1 – mirror létrehozása:
Tükör létrehozásakor nincs más feladatunk mint megcsinálni a két lábát a mirrorunknak. Értelemszerűen ha a két láb több diskből épített raid0 akkor már is elértük a Raid0+1-et. De feltételezzük most csak azt, hogy sima egy tagból álló metadevicek vannak.
# metainit d51 1 1 c0t0d0s2 d51: Concat/Stripe is setup # metainit d52 1 1 c1t0d0s2 d52: Concat/Stripe is setup # metainit d50 -m d51 d50: Mirror is setup # metattach d50 d52 d50: Submirror d52 is attached
A metainit paranccsal és a -m kapcsolóval van lehetőségünk mirror képzésére. Ahol definiálnunk kell az első tagot, tehát azt, hogy melyikről készüljön majd a másodikra másolat. A metattach parancs segítségével pedig a mirrorhoz illeszthetjük a második lábat is. Ekkor nekiindul a vad szinkronizáció, és végül kapunk egy raid 1 tömböt.
# metastat d50 d50: mirror Submirror 0: d51 State: Okay Submirror 1: d52 State: Resyncing Resync in progress: 41 %done Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 2006130 blocks
Raid 5 – Paritás volume létrehozása:
Raid 5 metadevice létrehozására is van lehetőségünk. Ahogy lent is látszik a metainit parancsot csupán egy -r kapcsolóval kell meghívnunk, és felsorolnunk a tagokat.
# metainit d45 -r c2t3d0s2 c3t0d0s2 c4t0d0s2 d45: RAID is setup # metastat d10 d10: RAID State: Okay Interlace: 32 blocks Size: 10080 blocks Original device: Size: 10496 blocks Device Start Block Dbase State Hot Spare c0t0d0s1 330 No Okay c1t2d0s1 330 No Okay c2t3d0s1 330 No Okay
Soft Partíciók
Mivel most már tudunk meta devicek alá szervezni különböző raid szinteket és azokat tetszés szerint méretezni ezért szükségessé válhat ezen nagyobb poolokat dinamikusan felosztani kisebb részekre. Dinamikusság alatt azt értem, hogy egyszerű, és későbbiekben tetszés szerint növelhető alrészekre felosztani a mi kis metadevice-unkat. Erre a célra kitűnőek a Soft partíciók. Lehetőségünk van általa egy meghatározott nagyságú tárterületet elkülöníteni egy új néven.
# metastat d1 d1: soft partition component: d100 state: OKAY size: 42674285 blocks Extent Start Block Block Count 0 10234 40674285 1 89377263 2000000 d100: Mirror Submirror 0: d10 State: OKAY Read option: roundrobin (default) Write option: parallel (default) Size: 426742857 blocks
A fenti példán jól látszik, hogy a d100-as mirrorból létre van hozva egy d1-es soft partition. Félre értés ne essen a d100-as meta device ugyan olyan szereppel bír file tárolás szempontjából, mint a d1. Ugyan úgy rakhatunk rá filesystem-et, mountolhatjuk bármelyiket. Viszont akkor nézzük, hogy is jön létre.
# metainit d1 -p d100 4g
A fenti parancsnál először definiálnunk kell a létrehozandó soft partíciót, majd -p kapcsoló jelzi, hogy ez soft partíció lesz, aztán követi a forrás device neve, amiből származtatódik a disk terület majd maga a méret.
Persze ami fontos, hogy egy soft partíciót amennyiben az őt kiszolgáló meta device rendelkezik még szabad területtel online bővíthetünk.
# mount /dev/md/dsk/d20 /home2 # metattach d20 10g # growfs -M /home2 /dev/md/rdsk/d20
A metattach parancs után meg kell adni a soft partíció nevét, majd a a tárterület méretét amennyivel bővíteni akarjuk. Természetesen nem szabad megfeledkezni arról, hogy az SVM nem file system csak egy volume kezelő, ezért külön a filesystem-ünk méretét is meg kell növelni. Ez lenne a harmadik parancs a fenti esetekben.
Hot Spare disk és Hot Spare pool
A hot spare diskek azon lemezek, amik arra várnak hogy meghibásodás történjen és átvehessék az elromlott disk szerepét. Természetesen feltételeznünk kell, hogy valamilyen hibatűrő RAID tömbről beszélünk, ahol van értelme spare diskekről beszélni. Persze jogos a kérdés miért tartsunk spare diskeket, amennyiben hibatűrő rendszert építettünk. A válasz egyszerű, ezzel méginkább hibatűrővé tehetjük a file tárolásunkat. Hisz az első meghibásodás után a rendszerünk, felhasználva azt a kálóban ott álló disket automatikusan javítja a RAID tömbünk szerkezetét, így egy esetleges második meghibásodás se okozhat problémát, és nem kell számolni az adminisztrátor várhatóan lassú beavatkozási idejével. Ha pedig már cserélni kell valamit egyszerűbb egy olyat ami amúgy sincs használva, így a raid tömb helyreállítási ideje nem a disk kicserélés idejéhez adódik hozzá.
Solaris alatt ez úgy néz ki, hogy úgynevezett host spare poolokat kell csinálnunk.
# metahs -a hsp001 /dev/dsk/c3t0d0s2 hsp001: Hotspare is added
A metash parancs segítségével lehetőségünk van egy nevesített poolhoz diskeket adni. Ez akármennyi lehet, és ugyan az a disk egyszerre tartozhat több hotspare poolhoz is.
Amennyiben nem rendeljük hozzá a hot spare poolunkat egyik metadevie-hoz sem, akkor bármely meghibásodás esetén segíteni fog, viszont lehetőség van arra, hogy egy hotspare poolt egy metadevice-hoz rendeljünk. Sőt akár egy mirror két külön lábához is külön-külön poolokat.
# metaparam -h hsp100 d10 # metaparam -h hsp100 d11 # metastat d0 d0: Mirror Submirror 0: d10 State: Okay Submirror 1: d11 State: Okay ... d10: Submirror of d0 State: Okay Hot spare pool: hsp100 ... d11: Submirror of d0 State: Okay Hot spare pool: hsp100
Ami fontos, hogy egy metadevice-hoz, egy hot spare pool tartozhat csak, egy poolba, viszont akármennyi disk lehet, tehát ez nem igazi korlát.
Meta Disk Set
Amiről eddig beszéltünk az SVM-el kapcsolatban az mind egy bizonyos rendszerhez tartozott csupán. Viszont lehetőségünk van az SVM már tárgyalt funkcióit közösen több Solaris-al együtt használni. Ezt hívják Metaset eknek vagy Disk seteknek.
Nem kell itt annyira vad dologra gondolni, ugyanis az eddig megtárgyaltakon semmit se változik, minden továbbra is igaz lesz metasetek esetében is. Ezen felül pedig nem arról van szó, hogy a saját diskünk-et adjuk oda. Minden esetben ugyanis alapból létezik egy Local Disk set. Ez jelenti azt, ami csak és kizárólag az adott géphez tartozik. Amennyiben olyan tárterületet akarunk managelni SVM-el, amit több gép között osztunk meg, akkor kell egy nevesített Disk Set-et létrehoznunk.
Alapvetően két típusa létezik: Shared Disk set és Multi Owner Disk set. A Shared Disk set esetében hiába több különálló rendszer is látja ugyan azt a metadevice-t egyszerre csupán egy férhet hozzá. A Multi Owner esetében pedig erre egyszerre van lehetőségük. A Multi Owner metaset elég speciális. Gyakorlatilag csak Oracle RAC esetében valósítható meg.
Nézzük akkor, hogy is készül el egy közös, nevesített Shared Disk Set.
Először is hozzuk létre és a névhez kössünk egy hostot. Ez esetben a blue a neve a disk setünknek, és a host1 host a birtokosa.
# metaset -s blue -a -h host1 # metaset Set name = blue, Set number = 1 Host Owner host1
Majd adjunk ehez a közös a blue disk sethez két közös disket is. Ezt természetesen akármikor megtehetjük később is.
# metaset -s blue -a c1t6d0 c2t6d0 # metaset Set name = blue, Set number = 1 Host Owner host1 Yes Drive Dbase c1t6d0 Yes c2t6d0 Yes
Persze a Shared Disk Set-nek pont az a lényege, hogy több host között használhatjuk a metedevice-kat. Így aduk hát hozzá a második hostunkat is.
# metaset -s blue -a -h host2 # metaset Set name = blue, Set number = 1 Host Owner host1 Yes host2 Drive Dbase c1t6d0 Yes c2t6d0 Yes
Jól látszik a fenti példán is, hogy a host1 az owner, tehát neki enged az SVM és a Metaset hozzáférést a metadevicekhoz.
Most lehetőségünk van, minden féle már ismert dolgot csinálnunk. Fontos hogy minden parancs esetében szükséges a -s METASET kapcsolót használni, hogy a rendszer tudja, hogy mi azon a metaset-en kívánjuk azon utasításokat végrehajtani. Amennyiben -s METASET nélkül az a LOCAL metasetekre lesz értelmezve.
Lássuk hát egy mirror beállítása hogy megy ezen a metaseten a két diskünkel.
# metainit -s blue d11 1 1 c1t6d0s0 blue/d11: Concat/Stripe is setup # metainit -s blue d12 1 1 c2t6d0s0 blue/d12: Concat/Stripe is setup # metainit -s blue d10 -m d11 blue/d10: Mirror is setup # metattach -s blue d10 d12 blue/d10: submirror blue/d12 is attached # metastat -s blue blue/d10: Mirror Submirror 0: blue/d11 State: Okay Submirror 1: blue/d12 State: Resyncing Resync in progress: 0 %done Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 17674902 blocks blue/d11: Submirror of blue/d10 State: Okay Size: 17674902 blocks Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t6d0s0 0 No Okay blue/d12: Submirror of blue/d10 State: Resyncing Size: 17674902 blocks Stripe 0: Device Start Block Dbase State Reloc Hot Spare c2t6d0s0 0 No Okay
Amennyiben egy disket ki akarunk venni a metasetünkből azt a következőképp tehetünk meg:
host1# metaset -s blue -d c1t6d0 host1# metaset -s blue Set name = blue, Set number = 1 Host Owner host1 host2 Drive Dbase c2t6d0 Yes
Ahogy említettem már a Shared Disk Set esetében kezelnünk kell azt, hogy mikor melyik hostnak van hozzáférése a metasethez. A metasetet egy hosthoz tudjuk rendelni (take), és el tudjuk engedni (release).
A következő parancsok használhatóak hozzá:
host1# metaset ... Set name = blue, Set number = 1 Host Owner host1 host2 ... host1# metaset -s blue -t host2# metaset ... Set name = blue, Set number = 1 Host Owner host1 Yes host2
A -t kapcsolóval tehát hozzá tudjuk rendelni a hosthoz a metaset-ünket.
host1# metaset -s blue -r host1# metaset -s blue Set name = blue, Set number = 1 Host Owner host1 host2 Drive Dbase c1t6d0 Yes c2t6d0 Yes
A -r kapcsolóval pedig el tudjuk engedni. Mindkét esetben lehetőség van a -f kapcsoló használatára is, így erőltetve valamelyik dolgot. Ez persze veszélyes lehet, mert a végrehajtás megtagadásának többnyire jogos oka szokott lenni.
Amennyiben egyik Solaris hostról akarjuk a másik Solaris hostra átköltöztetni a nevesített metasetünket a metasetimport parancs lehet nagy segítségünkre.
# metaimport -r Drives in regular diskset including disk c1t2d0: c1t2d0 c1t3d0 More info: metaimport -r -v c1t2d0 Import: metaimport -s newsetname c1t2d0 Drives in replicated diskset including disk c1t4d0: c1t4d0 c1t5d0 More info: metaimport -r -v c1t4d0 Import: metaimport -s newsetname c1t4d0 # metaimport -r -v c1t2d0 Import: metaimport -s newsetname c1t2d0 Last update: Mon Dec 29 14:13:35 2003 Device offset length replica flags c1t2d0 16 8192 a u c1t3d0 16 8192 a u
A -r kapcsolóval riportot kaphatunk arról, hogy milyen metaset meta adabázis infókat tud diskekről elérni, és a -v kapcsolóval részletes infókat nyerhetünk ki a fennálló kapcsolatokról. Mikor már tudjuk ki kivel van be tudjuk importálni egy új néven a diskeket.
# metaimport -s red c1t2d0 Drives in diskset including disk c1t2d0: c1t2d0 c1t3d0 c1t8d0 More info: metaimport -r -v c1t2d0 # metaset -s red Set name = red, Set number = 1 Host Owner host1 Yes Drive Dbase c1t2d0 Yes c1t3d0 Yes c1t8d0 Yes
Metastat
A végén pedig még had ejtsek egy rövid gondolatot a metastat parancsról. Ez a legtöbbet használt SVM parancs. Ez képes részletes illetve kevésbé részletes információkat adni metadevice-inkről.
Lehetőségünk van minden listázására részletesen:
# metastat
lehetőségünk van mindenről egy összefoglalót kérni (Csak Solarias 10 alatt):
# metastat -c
Illetve akármelyik konkrét metadevice adatait lekérni:
# metastat d100
Természetesen az itt leírtak bemutató jellegű kalauzolásnak szántam, nem teljes referencia anyagnak. Olyan betekintés félét mindabból amit az SVM nyújthat egy Solarisosnak. A teljes hivatalos referencia dokumentum elérhető itt.
“Solaris Volume Manager – SVM” bejegyzéshez 3 hozzászólás