Vinum (FreeBSD)

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
 
(egy szerkesztő 5 közbeeső változata nincs mutatva)
4. sor: 4. sor:
 
A különböző BSD terjesztések alatt meg kell különböztetnünk slice-okat és partíciókat. Az előbbi hasonlítható a Microsoft rendszerekből ismert elsődleges, és másodlagos partíciókkal, ugyanúgy 4 darab lehet belőle egy merevlemezen. Ennek oka az, hogy a Master Boot Recordban (MBR) csak négy bejegyzés fér el. Ezek a fizikailag is létező partíciók, ezeken túl hozhatunk létre logikai partíciókat. Ezt a korlátot oldja fel a BSD szemlélet azzal, hogy egy ilyen általuk szeletnek, és nem partíciónak nevezett részbe lehet további egységeket létrehozni, amiket ők ténylegesen a partícióknak tekintenek, tehát lehet a gyökér fájlrendszer rajta, a home könyvtár, esetleg tmp, és hasonló egységek, valamint a swap. Ez kompatibilitási szempontból jó, mivel így azon rendszerek alatt is látjuk az fdisk program segítségével. A rendszerünk indítása csak fizikailag létező partícióról lehetséges. Ezeknek a kezdete általában az első 1024 cilinderben kell, hogy elhelyezkedjen. (Ma már talán az a korlát nem létezik.) Erre találták Linux alatt a boot partíciót, ami egy rövid, csak a kernelt tartalmazó rész, és lehetőleg a diszk elején foglal le területet, és az összes további állományrendszer lehet logikai. A BSD rendszerek alatt az elsődleges partíciók számozása 1-4ig történik, ezekre az állományrendszerben úgy találunk hivatkozást, hogy az eszköz neve, pl.: /dev/ad0 (primary master), majd után a slice száma, tehát /dev/ad0s1, ezen belül még elérhetjük a partíciókat, amik az ABC betűivel vannak jelölve, vagyis /dev/ad0s1a lesz az első.
 
A különböző BSD terjesztések alatt meg kell különböztetnünk slice-okat és partíciókat. Az előbbi hasonlítható a Microsoft rendszerekből ismert elsődleges, és másodlagos partíciókkal, ugyanúgy 4 darab lehet belőle egy merevlemezen. Ennek oka az, hogy a Master Boot Recordban (MBR) csak négy bejegyzés fér el. Ezek a fizikailag is létező partíciók, ezeken túl hozhatunk létre logikai partíciókat. Ezt a korlátot oldja fel a BSD szemlélet azzal, hogy egy ilyen általuk szeletnek, és nem partíciónak nevezett részbe lehet további egységeket létrehozni, amiket ők ténylegesen a partícióknak tekintenek, tehát lehet a gyökér fájlrendszer rajta, a home könyvtár, esetleg tmp, és hasonló egységek, valamint a swap. Ez kompatibilitási szempontból jó, mivel így azon rendszerek alatt is látjuk az fdisk program segítségével. A rendszerünk indítása csak fizikailag létező partícióról lehetséges. Ezeknek a kezdete általában az első 1024 cilinderben kell, hogy elhelyezkedjen. (Ma már talán az a korlát nem létezik.) Erre találták Linux alatt a boot partíciót, ami egy rövid, csak a kernelt tartalmazó rész, és lehetőleg a diszk elején foglal le területet, és az összes további állományrendszer lehet logikai. A BSD rendszerek alatt az elsődleges partíciók számozása 1-4ig történik, ezekre az állományrendszerben úgy találunk hivatkozást, hogy az eszköz neve, pl.: /dev/ad0 (primary master), majd után a slice száma, tehát /dev/ad0s1, ezen belül még elérhetjük a partíciókat, amik az ABC betűivel vannak jelölve, vagyis /dev/ad0s1a lesz az első.
   
FreeBSD alatt használt fájlrendszer tipikusan az UFS (Unix File System), amit minden BSD támogat. Ez egy még 4.2 BSD-ben bevezetett fájlrendszer, amit azóta is megtartottak. Időközben elkészül az UFS második verziója, az UFS2, ami a 64 bites kiterjesztést tette meg. Sajnálatos módon a naplózást a maga az implementáció továbbra sem támogatja, így a BSD ilyen téren hiányt szenvednek. A 7.x-es FreeBSD rendszerek már képes a GEOM alrendszeren keresztül naplózást megvalósítani, ami a fájlrendszertől független. Ez az egyik út. A másik pedig a Matthew Dilon által fejlesztett DragonflyBSD-ben jelent meg, ami igyekszik minden hagyománnyal szakítani, és valami teljesen újat létrehozni a semmiből. Ez pedig a HAMMMER névre hallgató fájlrendszer. A tervezés tavaly év elején kezdődött meg, és Matt munka tempójából adódóan 2008. júniusában kiadásra is került az első verzió az akkor megjelenő DragonflyBSD 2.0-ban.
+
FreeBSD alatt használt fájlrendszer tipikusan az UFS (Unix File System), amit minden BSD támogat. Ez egy még 4.2 BSD-ben bevezetett fájlrendszer, amit azóta is megtartottak. Időközben elkészül az UFS második verziója, az UFS2, ami a 64 bites kiterjesztést tette meg. Sajnálatos módon a naplózást a maga az implementáció továbbra sem támogatja, így a BSD ilyen téren hiányt szenvednek. A 7.x-es FreeBSD rendszerek már képes a GEOM alrendszeren keresztül naplózást megvalósítani, ami a fájlrendszertől független. Ez az egyik út. A másik pedig a Matthew Dilon által fejlesztett DragonflyBSD-ben jelent meg, ami igyekszik minden hagyománnyal szakítani, és valami teljesen újat létrehozni a semmiből. Ez pedig a HAMMMER névre hallgató fájlrendszer. A tervezés tavaly év elején kezdődött meg, és Matt munkatempójából adódóan 2008. júniusában kiadásra is került az első verzió az akkor megjelenő DragonflyBSD 2.0-ban.
   
 
== Logikai lemezkezelő alrendszer ==
 
== Logikai lemezkezelő alrendszer ==
22. sor: 22. sor:
 
Itt a bemenetnek a /dev/zero fájlt választjuk, ezt az if-nél adjuk meg, mivel azt szeretnénk, hogy a létrehozott állomány csak 0-ak tartalmazzon. Fontos, hogy nem a /dev/null-t jelöljük ki, mivel az nem tartalmaz semmit, tehát nem lehet belőle olvasni. Kimenetnek az általunk meghatározott elérési útvonalat, és fájlnevet adjuk meg, ezt az of paraméterrel tehetjük meg. Ezek után a bs opció segítségével megadjuk, hogy mekkora blokkméretet szeretnénk, tehát egy olvasásnál mekkora adatot markoljunk fel. Ezek után már csak azt kell megmondanunk, hogy hányszor szeretnénk venni a rendelkezésre álló halmazból, erre szolgál a count. Tehát az eredmény egy 512 mb méretű csupa 0-kból álló fájl lesz, amit az aktuális könyvtárban fogunk megtalálni.
 
Itt a bemenetnek a /dev/zero fájlt választjuk, ezt az if-nél adjuk meg, mivel azt szeretnénk, hogy a létrehozott állomány csak 0-ak tartalmazzon. Fontos, hogy nem a /dev/null-t jelöljük ki, mivel az nem tartalmaz semmit, tehát nem lehet belőle olvasni. Kimenetnek az általunk meghatározott elérési útvonalat, és fájlnevet adjuk meg, ezt az of paraméterrel tehetjük meg. Ezek után a bs opció segítségével megadjuk, hogy mekkora blokkméretet szeretnénk, tehát egy olvasásnál mekkora adatot markoljunk fel. Ezek után már csak azt kell megmondanunk, hogy hányszor szeretnénk venni a rendelkezésre álló halmazból, erre szolgál a count. Tehát az eredmény egy 512 mb méretű csupa 0-kból álló fájl lesz, amit az aktuális könyvtárban fogunk megtalálni.
   
Ezek után a létrehozott fájlokat be kell állítanunk, mint eszközmeghajtókat a rendszerben. Ehhez használjuk az mdconfig parancsot, amivel memória lemezeket tudunk konfigurálni és engedélyezni. Itt a -a opcióval jelöljük ki, hogy hozzáadni fogunk egy új lemezt, majd a -t kapcsolóval megmondhatjuk annak a típusát (malloc, vnode, swap), jelen esetben vnode, tehát egy fájlban lesz a tényleges tároló, ezek után a -f kapcsolóval adhatjuk meg az elérési útvonalat.
+
Ezek után a létrehozott fájlokat be kell állítanunk, mint eszközmeghajtókat a rendszerben. Ehhez használjuk az mdconfig parancsot, amivel memória lemezeket tudunk konfigurálni és engedélyezni. Itt a -a opcióval jelöljük ki, hogy hozzáadni fogunk egy új lemezt, majd a -t kapcsolóval megmondhatjuk annak a típusát,
  +
ami az alábbiak közül lehet egy:
  +
  +
* '''malloc''' - amikor a memória egy adott területét akarjuk eszközként használni,
  +
* '''vnode''' - egy fájlt akarunk eszközként elérni,
  +
* '''swap''' - amikor a swap egy területét akarjuk eszközként elérni.
  +
  +
Jelen esetben vnode-ot kell választanunk, tehát egy fájlban lesz a tényleges tároló, ezek után a -f kapcsolóval adhatjuk meg ennek az elérési útvonalát.
   
 
Gyakorlatban tehát:
 
Gyakorlatban tehát:
29. sor: 29. sor:
 
# mdconfig -a -t vnode -f loop4.img
 
# mdconfig -a -t vnode -f loop4.img
   
Ezek után elkészítjük a Vinum konfigurációs fájlját, ami nekünk ezt a két eszközt összefűzve elérhetővé teszi. Itt a következőkben 1m-os csíkozást állítunk be.
+
Ezek után elkészítjük a Vinum konfigurációs fájlját, ami nekünk ezt a két eszközt összefűzve elérhetővé teszi. Itt a következőkben 1mb-os csíkozást állítunk be.
   
 
drive loop3 device /dev/md2
 
drive loop3 device /dev/md2
133. sor: 133. sor:
 
mount /dev/gvinum/mirror /mnt
 
mount /dev/gvinum/mirror /mnt
   
Hozzunk létre most egy ehhez hasonló kötet, csak három lemezből, és a gmirror parancs segítségével. A paraméterezése hasonló a gstripe-hoz, szintén meg kell adnunk a kívánt kötetcímkét, valamint hogy mely eszközökből álljon. Viszont kapunk egy új lehetőséget, méghozzá meghatározhatjuk a RAID1 algoritmusát, ami lehet a balance algoritmus paraméterezését jelenti (-b kapcsoló). Ez lehet a legalacsonyabb load-dal járó betöltés (load), a legmagasabb prioritással járó betöltés (prefer), a körbeforgó (round-robin), valamint az osztott olvasás (split -s [blokk méret byte-ban]), ahol a blokk méretet adhatjuk meg. A paraméterezés során azt is megadhatjuk, hogy a szinkronizáció automatikusan történjen-e meg, vagy csak akkor ha mi kívánjuk, ezt a -n kapcsolóval érhetjük el.
+
Hozzunk létre most egy ehhez hasonló kötet, csak három lemezből, és a gmirror parancs segítségével. A paraméterezése hasonló a gstripe-hoz, szintén meg kell adnunk a kívánt kötetcímkét, valamint hogy mely eszközökből álljon. Viszont kapunk egy új lehetőséget, méghozzá meghatározhatjuk a RAID1 algoritmusát, ami lehet a balance algoritmus paraméterezését jelenti (-b kapcsoló). Itt a következő lehetőségek érhetők el:
  +
  +
* '''load''': a rendszert minél legkevésbé terhelt eszközről olvasunk
  +
* '''prefer''': a rendszerben található legnagyobb prioritású komponensről olvasunk
  +
* '''round-robin''': a olvasás körbe-körbe adódik az eszközök között
  +
* '''split''': az aktív komponensekről egyszer adott méretű darabokat olvasunk be, és a -s kapcsoló segítségével adhatjuk meg a méretet
  +
  +
A paraméterezés során azt is megadhatjuk, hogy a szinkronizáció automatikusan történjen-e meg, vagy csak akkor ha mi kívánjuk, ezt a -n kapcsolóval érhetjük el.
   
 
Ezek után hozzunk létre egy 3 lemezből álló RAID1 tömböt, 2kb-os osztott olvasással:
 
Ezek után hozzunk létre egy 3 lemezből álló RAID1 tömböt, 2kb-os osztott olvasással:
   
 
[root@ ~]# gmirror label -v -b split -s 2048 raid1 /dev/md0 /dev/md1 /dev/md2
 
[root@ ~]# gmirror label -v -b split -s 2048 raid1 /dev/md0 /dev/md1 /dev/md2
  +
  +
Most már a kötet elérhető a /dev/mirror/raid1 útvonalon.
   
 
Ezek után szúrjunk be egy új eszközt a tömbbe:
 
Ezek után szúrjunk be egy új eszközt a tömbbe:
186. sor: 188. sor:
 
==== RAID 3 ====
 
==== RAID 3 ====
   
Létrehozhatunk még RAID3 köteteket a graid3 parancs segítségével, aminek a paraméterezése nagyon hasonló a korábban ismertetett parancsokhoz. Ez a gyakorlatban nem annyira használt, ezért nem is térnék itt ki.
+
Létrehozhatunk még RAID3 köteteket a graid3 parancs segítségével, aminek a paraméterezése nagyon hasonló a korábban ismertetett parancsokhoz. Gyakorlatban használt rendszereknél nem túl sűrűn alkalmazott megoldást, ezért itt részletesebben nem is térnék ki rá.
   
 
==== RAID 5 és RAID 10====
 
==== RAID 5 és RAID 10====
192. sor: 194. sor:
 
Lehetőségünk van RAID5-öt is létrehozni. Erre nincs külön alkalmazás, hanem a gvinum segítségével kell egy megfelelő konfigurációs állományt betöltenünk. Ehhez kiváló példát találunk a színvonalas FreeBSD Handbook-ban.
 
Lehetőségünk van RAID5-öt is létrehozni. Erre nincs külön alkalmazás, hanem a gvinum segítségével kell egy megfelelő konfigurációs állományt betöltenünk. Ehhez kiváló példát találunk a színvonalas FreeBSD Handbook-ban.
   
== Rendszer indítás a logikai kötetekről ==
+
== Rendszerindítás a logikai kötetekről ==
   
A FreeBSD rendszer jelenleg csak olyan kötetről tud boot-olni, ami nem RAID5, vagy nem összefűzött lemezekből álló egység.
+
A FreeBSD rendszer jelenleg csak olyan kötetről tud boot-olni, ami nem RAID5, sem összefűzött lemezekből álló egység.
   
 
== Hivatkozások ==
 
== Hivatkozások ==

A lap jelenlegi, 2008. október 17., 15:12-kori változata

Tartalomjegyzék

[szerkesztés] 1 Logikai kötetkezelés a FreeBSD operációs rendszer alatt

[szerkesztés] 1.1 Partíciók és azzal kapcsolatos fogalmak

A különböző BSD terjesztések alatt meg kell különböztetnünk slice-okat és partíciókat. Az előbbi hasonlítható a Microsoft rendszerekből ismert elsődleges, és másodlagos partíciókkal, ugyanúgy 4 darab lehet belőle egy merevlemezen. Ennek oka az, hogy a Master Boot Recordban (MBR) csak négy bejegyzés fér el. Ezek a fizikailag is létező partíciók, ezeken túl hozhatunk létre logikai partíciókat. Ezt a korlátot oldja fel a BSD szemlélet azzal, hogy egy ilyen általuk szeletnek, és nem partíciónak nevezett részbe lehet további egységeket létrehozni, amiket ők ténylegesen a partícióknak tekintenek, tehát lehet a gyökér fájlrendszer rajta, a home könyvtár, esetleg tmp, és hasonló egységek, valamint a swap. Ez kompatibilitási szempontból jó, mivel így azon rendszerek alatt is látjuk az fdisk program segítségével. A rendszerünk indítása csak fizikailag létező partícióról lehetséges. Ezeknek a kezdete általában az első 1024 cilinderben kell, hogy elhelyezkedjen. (Ma már talán az a korlát nem létezik.) Erre találták Linux alatt a boot partíciót, ami egy rövid, csak a kernelt tartalmazó rész, és lehetőleg a diszk elején foglal le területet, és az összes további állományrendszer lehet logikai. A BSD rendszerek alatt az elsődleges partíciók számozása 1-4ig történik, ezekre az állományrendszerben úgy találunk hivatkozást, hogy az eszköz neve, pl.: /dev/ad0 (primary master), majd után a slice száma, tehát /dev/ad0s1, ezen belül még elérhetjük a partíciókat, amik az ABC betűivel vannak jelölve, vagyis /dev/ad0s1a lesz az első.

FreeBSD alatt használt fájlrendszer tipikusan az UFS (Unix File System), amit minden BSD támogat. Ez egy még 4.2 BSD-ben bevezetett fájlrendszer, amit azóta is megtartottak. Időközben elkészül az UFS második verziója, az UFS2, ami a 64 bites kiterjesztést tette meg. Sajnálatos módon a naplózást a maga az implementáció továbbra sem támogatja, így a BSD ilyen téren hiányt szenvednek. A 7.x-es FreeBSD rendszerek már képes a GEOM alrendszeren keresztül naplózást megvalósítani, ami a fájlrendszertől független. Ez az egyik út. A másik pedig a Matthew Dilon által fejlesztett DragonflyBSD-ben jelent meg, ami igyekszik minden hagyománnyal szakítani, és valami teljesen újat létrehozni a semmiből. Ez pedig a HAMMMER névre hallgató fájlrendszer. A tervezés tavaly év elején kezdődött meg, és Matt munkatempójából adódóan 2008. júniusában kiadásra is került az első verzió az akkor megjelenő DragonflyBSD 2.0-ban.

[szerkesztés] 1.2 Logikai lemezkezelő alrendszer

A logikai lemezkezelést BSD rendszerekben Vinum alkalmazás segíti. Ennek elindítása a gvinum parancs kiadásával történik. Illetve másik lehetséges útvonal számunkra az ehhez kapcsolódó segédalkalmazások, mint a gmirror, gconcat, gstripe, amik automatizáltak, konfigurációs állomány megírása nélkül képesek számunkra az egyes funkciókat megvalósítani. Ezek használatát mutatom be példákon keresztül a későbbiek során. Igyekszem olyan funkciókat szemléltetni, amik a hétköznapokban is felmerülnek, tehát két lemez csíkozott összefűzése, tükrözése, esetleg bővíthető összefűzése.

[szerkesztés] 1.3 Szemléltetés

[szerkesztés] 1.3.1 RAID 0 létrehozása

RAID 0, vagyis összefűzés, a teljesítmény növelésének érdekében oly módon, hogy a lemezeket 1 mb-os darabonként váltva írjuk. Ami azt jelenti, hogy ha egy 10 megabyte-os fájl kívánunk ki írni, egy két lemezből álló kötetre, akkor az a páratlan mb-k az első, még a párosak a második lemezen lesznek megtalálhatóak. Így mind az olvasás, és írás sebessége a felére csökken, mivel párhuzamosítható a diszkműveletekkel elvégezhető.

Először is szükségünk lesz lemezekre, amiket összefűzünk. Jelenleg demonstrációs célból ez két loopback eszköz lesz. Ennek létrehozási módja:

# dd if=/dev/zero of=loop3.img bs=1m count=512
# dd if=/dev/zero of=loop4.img bs=1m count=512

Itt a bemenetnek a /dev/zero fájlt választjuk, ezt az if-nél adjuk meg, mivel azt szeretnénk, hogy a létrehozott állomány csak 0-ak tartalmazzon. Fontos, hogy nem a /dev/null-t jelöljük ki, mivel az nem tartalmaz semmit, tehát nem lehet belőle olvasni. Kimenetnek az általunk meghatározott elérési útvonalat, és fájlnevet adjuk meg, ezt az of paraméterrel tehetjük meg. Ezek után a bs opció segítségével megadjuk, hogy mekkora blokkméretet szeretnénk, tehát egy olvasásnál mekkora adatot markoljunk fel. Ezek után már csak azt kell megmondanunk, hogy hányszor szeretnénk venni a rendelkezésre álló halmazból, erre szolgál a count. Tehát az eredmény egy 512 mb méretű csupa 0-kból álló fájl lesz, amit az aktuális könyvtárban fogunk megtalálni.

Ezek után a létrehozott fájlokat be kell állítanunk, mint eszközmeghajtókat a rendszerben. Ehhez használjuk az mdconfig parancsot, amivel memória lemezeket tudunk konfigurálni és engedélyezni. Itt a -a opcióval jelöljük ki, hogy hozzáadni fogunk egy új lemezt, majd a -t kapcsolóval megmondhatjuk annak a típusát, ami az alábbiak közül lehet egy:

  • malloc - amikor a memória egy adott területét akarjuk eszközként használni,
  • vnode - egy fájlt akarunk eszközként elérni,
  • swap - amikor a swap egy területét akarjuk eszközként elérni.

Jelen esetben vnode-ot kell választanunk, tehát egy fájlban lesz a tényleges tároló, ezek után a -f kapcsolóval adhatjuk meg ennek az elérési útvonalát.

Gyakorlatban tehát:

# mdconfig -a -t vnode -f loop3.img
# mdconfig -a -t vnode -f loop4.img

Ezek után elkészítjük a Vinum konfigurációs fájlját, ami nekünk ezt a két eszközt összefűzve elérhetővé teszi. Itt a következőkben 1mb-os csíkozást állítunk be.

 drive loop3 device /dev/md2
 drive loop4 device /dev/md3
 volume stripe
 plex org striped 1m
     sd length 500m drive loop3
     sd length 500m drive loop4

A konfigurációs során kijelöljük, hogy mely eszközöket szeretnénk a kötet létrehozása során használni. Jelen esetben a két loopback eszközt, amire majd loop3 és loop3-ként hivatkozunk a továbbiakban. Ezek után megadjuk az általunk létrehozni kívánt kötet nevét, ez lesz a stripe. A negyedik sorban kijelöljük az érnek (plex) szervezési módját. Itt a csíkozást választjuk ki, méghozzá 1 mb-os csíkokkal. Ezek után megadjuk a kötetben részvevő allemezeket. Itt mind a két eszközünkről kijelölünk egy-egy 500mb-os területet. Ezek után tehát a létrejövő kötet 1 GB-os méretet fog ölteni.

Indítsuk el a gvinum rendszert, ami egy promtot fog visszaadni:

# gvinum ->

Majd adjuk ki a következő parancsot:

# gvinum -> create striped.conf

Ezt a konfigurációs fájlt betöltve a következőket kapjuk:

2 drives:
D loop4                 State: up	/dev/md3	A: 11/511 MB (2%)
D loop3                 State: up	/dev/md2	A: 11/511 MB (2%)

1 volumes:
V stripe                State: up	Plexes:       1	Size:       1000 MB

1 plexes:
P stripe.p0           S State: up	Subdisks:     2	Size:       1000 MB

2 subdisks:
S stripe.p0.s1          State: up	D: loop4        Size:        500 MB
S stripe.p0.s0          State: up	D: loop3        Size:        500 MB

Most már elérhető a /dev alatt a stripe nevű lemez a /dev/gvinum/stripe elérési útvonallal. Ezek után már csak fájlrendszert kell létrehoznunk, felcsatolnunk, és használnunk:

# newfs /dev/gvinum/stripe
# mount /dev/gvinum/stripe /mnt

Egy másik módja a csíkozott rendszer elkészítésének a gstipe parancs használata. Ekkor csak meg kell adnunk, hogy mely lemezekből szeretnénk létrehozni, és mekkora csíkmérettel, valamint milyen címkével. Pl.:

[root@ ~]# gstripe label -v -s 1048576 raid0 /dev/md0 /dev/md1
Metadata value stored on /dev/md0.
Metadata value stored on /dev/md1.
Done.
[root@ ~]# ls /dev/stripe/
raid0

Ezzel a /dev/stripe/raid0 címkével létrejön egy három loopback eszközből álló, 1 mb-os csíkozású RAID0 tömb. (A -v kapcsoló, csak a beszédesebb módot kapcsolja be.) Amit a továbbiak során szabadon felhasználhatunk, hozhatunk rajta létre fájlrendszert, és felcsatolhatjuk az állományrendszerbe.

[szerkesztés] 1.3.2 RAID 1 létrehozása

Ebben a szekcióban egy kicsit időtállóbb rendszert próbálunk létrehozni, ahol több lemezen tároljuk szinkronban ugyanazon adatokat. Így természetesen az eszközök kihasználtsága csökken, viszont a rendelkezésreállásuk növelhető. Ezt valósítja meg a RAID1.

Először is hozzuk létre a virtuális eszközöket, amiken dolgozni fogunk a példa során:

# dd if=/dev/zero of=loop1.img bs=1m count=512
# dd if=/dev/zero of=loop2.img bs=1m count=512
# mdconfig -a -t vnode -f loop1.img
# mdconfig -a -t vnode -f loop2.img

Ezek után el kell készítenünk egy konfigurációs fájl, mondjuk mirror.conf néven. Ennek tartalma legyen:

drive loop1 device /dev/md0
drive loop2 device /dev/md1
volume mirror
  plex org concat
  sd length 450m drive loop1
  plex org concat
  sd length 450m drive loop2

A fájl felépítése hasonló az előző példához, azzal a különbséggel, hogy itt más a szervezési mód. Mivel egy tükröt szeretnénk létrehozni, ezért a kötetben két ér lesz, amikbe allemezeket fűzünk. Természetesen több eszközt is hasonló módon vehetnénk bele az sd szekciónál. Látható, hogy ezek után, egy 450mb méretű RAID1-be szervezett eszközre mutató hivatkozás jelenik majd meg a /dev alatt.

Ezek után már csak be kell töltenünk. Ehhez indítsuk el a gvinum alkalmazást, és adjuk ki a következő parancsot:

# gvinum -> create mirror.conf
4 drives:
D loop4                 State: up	/dev/md3	A: 11/511 MB (2%)
D loop3                 State: up	/dev/md2	A: 11/511 MB (2%)
D loop2                 State: up	/dev/md1	A: 61/511 MB (12%)
D loop1                 State: up	/dev/md0	A: 61/511 MB (12%)

2 volumes:
V stripe                State: up	Plexes:       1	Size:       1000 MB
V raid1                 State: up	Plexes:       2	Size:        450 MB

3 plexes:
P stripe.p0           S State: up	Subdisks:     2	Size:       1000 MB
P raid1.p1            C State: up	Subdisks:     1	Size:        450 MB
P raid1.p0            C State: up	Subdisks:     1	Size:        450 MB

4 subdisks:
S stripe.p0.s1          State: up	D: loop4        Size:        500 MB
S stripe.p0.s0          State: up	D: loop3        Size:        500 MB
S raid1.p1.s0           State: up	D: loop2        Size:        450 MB
S raid1.p0.s0           State: up	D: loop1        Size:        450 MB


Most már elérhető a /dev alatt a mirror nevű lemez a /dev/gvinum/mirror elérési útvonal alatt. Ezek után már csak fájl rendszert kell létrehoznunk, felcsatolnunk, és használnunk:

newfs /dev/gvinum/mirror
mount /dev/gvinum/mirror /mnt

Hozzunk létre most egy ehhez hasonló kötet, csak három lemezből, és a gmirror parancs segítségével. A paraméterezése hasonló a gstripe-hoz, szintén meg kell adnunk a kívánt kötetcímkét, valamint hogy mely eszközökből álljon. Viszont kapunk egy új lehetőséget, méghozzá meghatározhatjuk a RAID1 algoritmusát, ami lehet a balance algoritmus paraméterezését jelenti (-b kapcsoló). Itt a következő lehetőségek érhetők el:

  • load: a rendszert minél legkevésbé terhelt eszközről olvasunk
  • prefer: a rendszerben található legnagyobb prioritású komponensről olvasunk
  • round-robin: a olvasás körbe-körbe adódik az eszközök között
  • split: az aktív komponensekről egyszer adott méretű darabokat olvasunk be, és a -s kapcsoló segítségével adhatjuk meg a méretet

A paraméterezés során azt is megadhatjuk, hogy a szinkronizáció automatikusan történjen-e meg, vagy csak akkor ha mi kívánjuk, ezt a -n kapcsolóval érhetjük el.

Ezek után hozzunk létre egy 3 lemezből álló RAID1 tömböt, 2kb-os osztott olvasással:

[root@ ~]# gmirror label -v -b split -s 2048 raid1 /dev/md0 /dev/md1 /dev/md2

Most már a kötet elérhető a /dev/mirror/raid1 útvonalon.

Ezek után szúrjunk be egy új eszközt a tömbbe:

[root@ ~]# gmirror insert raid1 /dev/md3

Most vegyük ki mondjuk a 3. eszközt, hogy készítsünk róla egy biztonsági mentést, és aktiváljuk újra:

[root@ ~]# gmirror deactivate raid1 /dev/md2
[root@ ~]# dd if=/dev/md2 of=md2backup.img
[root@ ~]# gmirror activate raid1 /dev/md2

Ha nem történne meg a szinkronizáció automatikusan, mivel a kötet létrehozásánál esetlegesen azt kértük, akkor tegyük meg most:

[root@ ~]# gmirror rebuild raid1 /dev/md2

[szerkesztés] 1.3.3 Bővíthető lemezkötetek

Létrehozhatunk kötetekből egy összefűzött csomót, amit a későbbiek során folyamatosan igény szerint növelhetünk. Ilyen rendszer alkalmazása kiváló lehet, ha felhasználók home könyvtárjait külön szeretnénk tárolni, illetve a későbbiek során számukra több helyet biztosíteni. Ennel első lépése, hogy létrehozzuk a fent ismertett módon két loopback eszközt. Ezeket egy csoportba foghatjuk a következő módon:

# gconcat label -v home /dev/mdx /dev/mdy ...

Ezzel egy home cimkevel ellátott eszközfájl fog megjeleni számunkra a /dev/concat könyvtárban. A -v kapcsoló a beszédesebb visszajelzést állítja be. Az utána felsorolt eszközök kerülnek be a kötetbe. Ezek után a szokásos módon hozhatunk létre fájlrendszert rajta:

# newfs /dev/concat/home

Ha nem szeretnénk felhasználni a teljes kötet, akkor a -s kapcsoló segítségével megadhatjuk, hogy milyen méretű fájlrendszert szeretnénk létrehozni a megadott eszközön.

Ezek után, ha a felhasználás során felmerül az igény a home eszköz megnövelésére akkor a következő módon járunk el:

# gconcat label home /dev/mdz

Ezzel a z. loopback eszközt hozzávettük a kötethez. Ekkor még a rajta található partíció mérete nem vette át a kötet méretét, tehát azt meg kell növelnünk. Ehhez használjuk a growfs parancsot:

# growfs /dev/concat/home

Ha nem szeretnénk, hogy a fájlrendszer kitöltse a teljes kötetet, akkor -s kapcsolóval adhatjuk meg az új méretet. Továbbá, ha a méreten kívül más paraméterét is változtatni szeretnénk a létező fájlrendszernek, amiket az newfs során adtunk meg, akkor erre a tunefs nevű programot tudjuk használni, mivel bővebbek a lehetőségei, mint az itt említett growfs-nek.

Természetesen a felcsatolás a szokásos módon elvégezhető a mount paranccsal.

Bővítés előtt a lemezt szükséges lecsatolni. A kötetet leállítani a következő módon tudjuk:

# gconcat stop home
# gconcat unload

[szerkesztés] 1.3.4 További lehetőségek példák nélkül

[szerkesztés] 1.3.4.1 RAID 3

Létrehozhatunk még RAID3 köteteket a graid3 parancs segítségével, aminek a paraméterezése nagyon hasonló a korábban ismertetett parancsokhoz. Gyakorlatban használt rendszereknél nem túl sűrűn alkalmazott megoldást, ezért itt részletesebben nem is térnék ki rá.

[szerkesztés] 1.3.4.2 RAID 5 és RAID 10

Lehetőségünk van RAID5-öt is létrehozni. Erre nincs külön alkalmazás, hanem a gvinum segítségével kell egy megfelelő konfigurációs állományt betöltenünk. Ehhez kiváló példát találunk a színvonalas FreeBSD Handbook-ban.

[szerkesztés] 1.4 Rendszerindítás a logikai kötetekről

A FreeBSD rendszer jelenleg csak olyan kötetről tud boot-olni, ami nem RAID5, sem összefűzött lemezekből álló egység.

[szerkesztés] 1.5 Hivatkozások

Személyes eszközök