Solaris Volume Manager – SVM « Xorp Blog Podcast

Solaris Volume Manager – SVM 122 kattintás

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.

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:

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:

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

Amennyiben egy disket ki akarunk venni a metasetünkből azt a következőképp tehetünk meg:

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á:

A -t kapcsolóval tehát hozzá tudjuk rendelni a hosthoz a metaset-ünket.

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.

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.

Published január 29th, 2010 in Informatika and SUN. 0 Comments

0 Responses to “Solaris Volume Manager – SVM”

Feed for this Entry Trackback Address

No Comments

ZFS – Modern kor a tárolásban « Xorp Blog Podcast
Pingback on feb 2nd, 2010 at 6:33 du.
Veritas Storage Foundation « Xorp Blog Podcast
Pingback on feb 8th, 2010 at 2:33 du.
Sun Cluster 3.2 « Xorp Blog Podcast
Pingback on feb 12th, 2010 at 8:56 du.