Logikai kötetkezelés

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
([http://evms.sourceforge.net/ EVMS]: LVM+RAID recept)
a (ZFS: link kozmetikázva)
 
(2 szerkesztő 21 közbeeső változata nincs mutatva)
2. sor: 2. sor:
 
Ez egyebek mellett lehetővé teszi, hogy a fizikai tárolóeszközöket logikai egységekbe szervezzük, és rugalmasan átméretezhető logikai köteteket hozzunk létre.
 
Ez egyebek mellett lehetővé teszi, hogy a fizikai tárolóeszközöket logikai egységekbe szervezzük, és rugalmasan átméretezhető logikai köteteket hozzunk létre.
 
Ha később új diszk kerül a gépbe, azt is hozzáadhatjuk egy kötetcsoporthoz, és teljesen transzparens módon átlóghatnak rá a filerendszereink, anélkül, hogy külön foglalkoznunk kellene azzal, hogy melyik fizikai diszkre is kerüljenek.
 
Ha később új diszk kerül a gépbe, azt is hozzáadhatjuk egy kötetcsoporthoz, és teljesen transzparens módon átlóghatnak rá a filerendszereink, anélkül, hogy külön foglalkoznunk kellene azzal, hogy melyik fizikai diszkre is kerüljenek.
  +
  +
Ez [http://lwn.net/2000/0224/kernel.php3 2000-ben], amikor megjelent a kernelben, nagyon fontos újdonság volt, már-már a szeletelt kenyérhez hasonló, de 2015-ben azért már érezhetően nyögvenyelős mondjuk a [[ZFS]]-hez képest.
   
 
== Linux LVM ==
 
== Linux LVM ==
   
(Itt most csak a 2.6-os kernelben levő LVM2-vel foglalkozunk. A 2.4-es szériában található LVM1 nagyjából ugyanezt tudta, csak volt néhány korlátozása.)
+
(Itt most csak a 2.6-os kernelben levő LVM2-vel foglalkozunk. A 2.4-es szériában található LVM1 nagyjából ugyanezt tudta, csak volt néhány korlátozása. Szintén nagyon hasonló az AIX és a HP-UX logikai kötetkezelője.)
   
 
A Linux LVM (Logical Volume Management) a következő fogalmakkal dolgozik:
 
A Linux LVM (Logical Volume Management) a következő fogalmakkal dolgozik:
   
 
=== Physical extent ===
 
=== Physical extent ===
  +
 
Allokációs egység. Ekkora egységenként oszthatjuk szét a volume groupban levő helyet a logical volume-ok között (l. később).
 
Allokációs egység. Ekkora egységenként oszthatjuk szét a volume groupban levő helyet a logical volume-ok között (l. később).
   
25. sor: 28. sor:
 
</pre>
 
</pre>
   
Fontosab opciók:
+
Fontosabb opciók:
* --uuid: minden physical volume-nak van egy egyedi azonosítója. Ha egy diszket kicserélünk, és az új diszket be akarjuk tenni a régi helyére az LVM-be, akkor a --uuid kapcsolóval be kell állítanunk rajta a régi diszk azonosítóját.
+
* --uuid: minden physical volume-nak van egy egyedi azonosítója. Ha egy diszket kicserélünk, és az új diszket be akarjuk tenni a régi helyére az LVM-be, akkor a --uuid kapcsolóval be kell állítanunk rajta a régi diszk azonosítóját (ennek akkor lehet értelme, ha az eredeti diszk elromlott, és végső elkeseredésünkben már azzal is beérjük, ha azokat az adatokat strukturált formában lementhetjük, amelyek a kötetcsoport többi diszkjén voltak).
   
 
Dokumentáció:
 
Dokumentáció:
63. sor: 66. sor:
 
</pre>
 
</pre>
   
Láthatjuk, hogy az első megtalált physical volume a /dev/md2-n, egy RAID tömbön van, és a raid5 nevű volume group része (l. később).
+
Láthatjuk, hogy az első megtalált physical volume a /dev/md2-n, egy [[RAID]] tömbön van, és a raid5 nevű volume group része (l. később).
 
A második volume a /dev/loop0 loopback device-on (tehát valójában egy ehhez a device-hoz tartozó image file-ban) van, és még nem rendeltük hozzá volume grouphoz, ezért nem is használható a benne levő hely (Allocatable: no).
 
A második volume a /dev/loop0 loopback device-on (tehát valójában egy ehhez a device-hoz tartozó image file-ban) van, és még nem rendeltük hozzá volume grouphoz, ezért nem is használható a benne levő hely (Allocatable: no).
 
A közölt adatok:
 
A közölt adatok:
69. sor: 72. sor:
 
* PV Name - annak a unix device-nak a neve, amin a physical volume található.
 
* PV Name - annak a unix device-nak a neve, amin a physical volume található.
 
* VG Name - annak a volume groupnak a neve, amelyhez a physical volume tartozik.
 
* VG Name - annak a volume groupnak a neve, amelyhez a physical volume tartozik.
* PV Size - a PV mérete (mit jelent és milyen esetben jelenik meg a "not usable X"?)
+
* PV Size - a PV mérete
* Allocatable - Felhasználható-e a PV-n levő hely (van valakinek kedve precízebb megfogalmazást keresni erre?)
+
* Allocatable - Felhasználható-e a PV-n levő hely
 
* PE Size - a physical extentek mérete abban a volume groupban, amelyhez a PV tartozik.
 
* PE Size - a physical extentek mérete abban a volume groupban, amelyhez a PV tartozik.
 
* Total, Free, Allocated PE - összes physical extent száma, ebből hány szabad, hány foglalt.
 
* Total, Free, Allocated PE - összes physical extent száma, ebből hány szabad, hány foglalt.
83. sor: 86. sor:
 
</pre>
 
</pre>
   
A <tt>pvs</tt> esetén testreszabhatóbb a kimenet formája. Részletesebben l. a dokumentációban.
+
A <tt>pvs</tt> esetén testreszabhatóbb és tömörebb a kimenet, emiatt általában érdemesebb ezt használni. Részletesebben l. a dokumentációban.
   
 
A <tt>pvscan</tt> outputja is nagyon hasonló:
 
A <tt>pvscan</tt> outputja is nagyon hasonló:
96. sor: 99. sor:
 
Ennek akkor van értelme, ha pl. ki akarjuk venni az adott fizikai diszket a gépből, vagy a volume groupból.
 
Ennek akkor van értelme, ha pl. ki akarjuk venni az adott fizikai diszket a gépből, vagy a volume groupból.
 
A pvmove online művelet, vagyis menet közben is használhatjuk, írhatjuk és olvashatjuk az érintett volume-ot.
 
A pvmove online művelet, vagyis menet közben is használhatjuk, írhatjuk és olvashatjuk az érintett volume-ot.
  +
* Legalábbis ez az elmélet; a gyakorlatban nagy I/O-terhelés mellett bizonyos kernelverziók holtpontra juthatnak pvmove közen. Ez valószínűleg nem jár adatvesztéssel, de csak újraindítással orvosolható.
   
 
A <tt>pvremove</tt> segítségével eltávolíthatjuk az LVM-címkét egy PV-ről, így az LVM a továbbiakban nem vesz róla tudomást.
 
A <tt>pvremove</tt> segítségével eltávolíthatjuk az LVM-címkét egy PV-ről, így az LVM a továbbiakban nem vesz róla tudomást.
285. sor: 289. sor:
 
* -l - méret PE-ben
 
* -l - méret PE-ben
 
* -n - a létrehozandó LV neve
 
* -n - a létrehozandó LV neve
* -i - csíkszám (hány különböző PV-n szórja szét - kvázi RAID0)
+
* -i - csíkszám (hány különböző PV-n szórja szét - kvázi [[RAID#RAID0|RAID0]])
* --mirrors - tükrök száma (hány különböző PV-n tárolja ugyanazt - kvázi RAID1, de naplózva, úgyhogy nem kell minden crash után resyncelni)
+
* --mirrors - tükrök száma (hány különböző PV-n tárolja ugyanazt - kvázi [[RAID#RAID1|RAID1]], de naplózva, úgyhogy nem kell minden crash után resyncelni; ennek feltétele, hogy egy harmadik eszközön tartsuk a naplót)
 
* --type - típus: striped, zero, error, snapshot, mirror
 
* --type - típus: striped, zero, error, snapshot, mirror
 
** Ebből közvetlenül csak a zerot és az errort lehet értelme megadni (''ellenvélemény?'')
 
** Ebből közvetlenül csak a zerot és az errort lehet értelme megadni (''ellenvélemény?'')
450. sor: 454. sor:
   
 
A dmsetup amúgy a kernelben levő device mapper alrendszerrel kommunikál, és információnyerésen kívül más érdekes dolgokra is használható.
 
A dmsetup amúgy a kernelben levő device mapper alrendszerrel kommunikál, és információnyerésen kívül más érdekes dolgokra is használható.
A felhasználási területek körüljárása egy lehetséges házi feladat. Lehet vele pl. [http://www.saout.de/misc/dm-crypt/ titkosított block device]-t csinálni.
+
A felhasználási területek körüljárása egy lehetséges házi feladat. Lehet vele pl. [http://code.google.com/p/cryptsetup/ titkosított block device]-t csinálni.
   
 
Átméretezés: lvextend, lvreduce, lvresize. A -L/-l kapcsolókkal megadhatjuk az új méretet abszolút értékkel vagy az előzőhöz képest (pl. <tt>lvextend -L +1G /dev/raid5/var</tt> - egy gigabyte-tal megnöveljük a raid5 kötetcsoport var nevű logikai kötetét).
 
Átméretezés: lvextend, lvreduce, lvresize. A -L/-l kapcsolókkal megadhatjuk az új méretet abszolút értékkel vagy az előzőhöz képest (pl. <tt>lvextend -L +1G /dev/raid5/var</tt> - egy gigabyte-tal megnöveljük a raid5 kötetcsoport var nevű logikai kötetét).
473. sor: 477. sor:
 
*** Upgrade vagy egyéb veszélyes beavatkozás előtt az összes volume-ról csinálunk snapshotot.
 
*** Upgrade vagy egyéb veszélyes beavatkozás előtt az összes volume-ról csinálunk snapshotot.
 
*** Ha vissza akarunk térni a korábbi állapothoz, mindent visszamásolunk a snapshotból.
 
*** Ha vissza akarunk térni a korábbi állapothoz, mindent visszamásolunk a snapshotból.
*** Akár bootlhatunk is úgy, hogy a snapshotokat mountoljuk a "valódi" LV-k helyett.
+
**** Újabban: <tt>lvconvert --merge</tt> beolvasztja a snapshotot az eredetibe.
  +
*** Akár bootolhatunk is úgy, hogy a snapshotokat mountoljuk a "valódi" LV-k helyett.
 
**** Ehhez az kell, hogy a rootfs snapshotjában levő fstabban a snapshotok szerepeljenek a valódi LV-k helyett.
 
**** Ehhez az kell, hogy a rootfs snapshotjában levő fstabban a snapshotok szerepeljenek a valódi LV-k helyett.
 
**** Tehát a snapshot létrehozása után át kell írni az fstabot a snapshoton.
 
**** Tehát a snapshot létrehozása után át kell írni az fstabot a snapshoton.
480. sor: 484. sor:
 
**# Bele<tt>chroot</tt>olunk.
 
**# Bele<tt>chroot</tt>olunk.
 
**# Kipróbáljuk, amit ki akartunk próbálni. Csak a snapshot módosul.
 
**# Kipróbáljuk, amit ki akartunk próbálni. Csak a snapshot módosul.
**# Töröljük a snapshotot.
+
**# Ha jól működött, amit kipróbáltunk, <tt>lvconvert --merge</tt>-dzsel beolvasztjuk a snapshotot az eredeti kötetbe; ha nem, töröljük a snapshotot.
**# Ha jól működött, amit kipróbáltunk, megcsináljuk a valódi rendszeren is; ha nem, nem.
+
** VM klónozása:
** VM klónozás:
 
 
*** Ha sok hasonló virtuális gépet akarunk futtatni, csinálunk egy master LV-ot, amiben összerakjuk a filerendszert.
 
*** Ha sok hasonló virtuális gépet akarunk futtatni, csinálunk egy master LV-ot, amiben összerakjuk a filerendszert.
 
*** Ennek a snapshotjait kapják meg a virtuális gépek (pl. UML vagy xenU).
 
*** Ennek a snapshotjait kapják meg a virtuális gépek (pl. UML vagy xenU).
 
*** Így sokkal kevesebb helyet foglalnak, mivel az adatok nagy része közös helyen lesz.
 
*** Így sokkal kevesebb helyet foglalnak, mivel az adatok nagy része közös helyen lesz.
 
*** Ez csak akkor jó, ha kevés a változás; ha sok, akkor idővel (legfeljebb) ugyanannyi helyet fognak foglalni a snapshotok, mintha eleve külön LV-ket hoztunk volna létre.
 
*** Ez csak akkor jó, ha kevés a változás; ha sok, akkor idővel (legfeljebb) ugyanannyi helyet fognak foglalni a snapshotok, mintha eleve külön LV-ket hoztunk volna létre.
  +
**** Jobb választás lehet egy blokkszinten deduplikáló fájlrendszer.
   
 
Létrehozása: <tt>lvcreate -s</tt>.
 
Létrehozása: <tt>lvcreate -s</tt>.
657. sor: 662. sor:
 
=== LVM és RAID ===
 
=== LVM és RAID ===
   
Természetesen van értelme egyszerre RAIDet (akár szoftveres RAIDet) és LVM-et használni; a RAID biztosítja a redundanciát, az LVM pedig a rugalmasságot.
+
Természetesen van értelme egyszerre [[RAID]]et (akár [[Software RAID Linux alatt|szoftveres RAID]]et) és LVM-et használni; a [[RAID]] biztosítja a redundanciát és/vagy a csíkozást, az LVM pedig a rugalmasságot.
   
Ha egy már LVM-et használó rendszerből szeretnénk RAID1-es rendszert csinálni, arra az alább receptet használhatjuk:
+
Ha egy már LVM-et használó rendszerből szeretnénk [[RAID#RAID1|RAID1]]-es rendszert csinálni, arra az alábbi receptet használhatjuk:
   
 
# Új diszk(ek) beépítése
 
# Új diszk(ek) beépítése
# RAID tömb létrehozása az új diszk(ek)ből (<tt>--level=1 --raid-devices=1</tt>, így "féllábú" lesz a RAID, eleve degradált tömb jön létre)
+
# [[RAID]] tömb létrehozása az új diszk(ek)ből (<tt>--create --level=1 --raid-devices=2 /dev/mdX /dev/ujdisk missing</tt>, így "féllábú" lesz a [[RAID]], eleve degradált tömb jön létre)
# <tt>pvcreate</tt> az új RAID-tömbön
+
# <tt>pvcreate</tt> az új [[RAID]]-tömbön
 
# <tt>vgextend</tt>-del hozzáadjuk a meglevő volume grouphoz az új fizikai kötetet (ami a féllábú RAID)
 
# <tt>vgextend</tt>-del hozzáadjuk a meglevő volume grouphoz az új fizikai kötetet (ami a féllábú RAID)
# <tt>lvmove</tt>-val átmozgatunk minden adatot a régi PV-ról az újra
+
# <tt>pvmove</tt>-val átmozgatunk minden adatot a régi PV-ról az újra
 
# <tt>vgreduce</tt>-szal kiszedjük a VG-ból a régi diszk(ek)et
 
# <tt>vgreduce</tt>-szal kiszedjük a VG-ból a régi diszk(ek)et
 
# <tt>mdadm</tt>-mal új raid-eszközként hozzáadjuk a régi diszk(ek)et a féllábú RAID-tömbhöz
 
# <tt>mdadm</tt>-mal új raid-eszközként hozzáadjuk a régi diszk(ek)et a féllábú RAID-tömbhöz
672. sor: 677. sor:
 
A műveletek nagy része online elvégezhető (kivéve esetleg az új diszkek beépítését, de jobb hardver esetén az is megy leállítás nélkül).
 
A műveletek nagy része online elvégezhető (kivéve esetleg az új diszkek beépítését, de jobb hardver esetén az is megy leállítás nélkül).
   
Ügyeljünk arra, hogy az összes softraides partíciónk típusa 0xFD legyen ("Linux RAID Autodetect").
+
Ügyeljünk arra, hogy az összes softraides partíciónk típusa 0xFD legyen ("Linux RAID Autodetect"), ha azt szeretnénk, hogy a kernel segítség nélkül össze tudja rakni boot közben.
  +
  +
=== Gyakorlati tanácsok ===
  +
  +
Mindig hagyjunk szabad helyet a kötetcsoportjainkban!
  +
  +
Tartsuk észben, hogy a filerendszereinket bármikor könnyedén növelhetjük, de zsugorítani nagyon nehéz lesz. Ezért soha ne osszuk ki egy kötetcsoport összes helyét eleve, hanem minden filerendszernek mindig csak annyi helyet allokáljunk, amennyire biztosan szükség van. Így, ha valahol fogytán van a hely, a VG-ben levő szabad területből még tudunk gazdálkodni. Ha előre kiosztottuk az összes helyet és elrontottuk, akkor a változtatás egy teljes mentéssel, törléssel, az érintett LV-k újbóli létrehozásával, majd mentésből való visszaállással jár.
  +
  +
''Az összes hely preallokálása minden bizonnyal a leggyakoribb tervezési hiba, amit kezdő LVM-felhasználók elkövetnek.''
  +
  +
Ha nincs szabad hely, snapshotokat sem tudunk készíteni.
   
 
== Solaris ==
 
== Solaris ==
  +
  +
Írta: Boros Péter<BR>
  +
Utolsó jelentős módosítás: 2006. szeptember.<BR>
  +
''Nem része a hivatalos tananyagnak,'' de l. a [[ZFS]] szócikket is, ami igen.
  +
 
A Solaris 10 update 2 (6/06), illetve az opensolaris előtt a Solarisban nem vált szét élesen a logikai kötetkezelés és a szoftver RAID. Az így létrehozott metadevice-okon ugyanúgy UFS-t lehet használni, mint alapesetben a diskeken. 2006 júniusában azonban megjelent a ZFS a kereskedelmi solarisban, ami elég sok újítést hozott, és valamilyen szinten elavulttá tette az addigi logikai kötetkezelést. A metadevice-ok létrehozásának lehetősége a Solaris 9-től volt része a kereskedelmi Solarisnak (előző verziókhoz is elérhető volt patch formájában).
 
A Solaris 10 update 2 (6/06), illetve az opensolaris előtt a Solarisban nem vált szét élesen a logikai kötetkezelés és a szoftver RAID. Az így létrehozott metadevice-okon ugyanúgy UFS-t lehet használni, mint alapesetben a diskeken. 2006 júniusában azonban megjelent a ZFS a kereskedelmi solarisban, ami elég sok újítést hozott, és valamilyen szinten elavulttá tette az addigi logikai kötetkezelést. A metadevice-ok létrehozásának lehetősége a Solaris 9-től volt része a kereskedelmi Solarisnak (előző verziókhoz is elérhető volt patch formájában).
 
=== Diskek ===
 
=== Diskek ===
859. sor: 869. sor:
   
 
=== Meta devices ===
 
=== Meta devices ===
A meta eszközök működése hasonló, mint a linux alatti szoftver raid-é, Solarisban ezt hívják volume managernek. Általában a meta kezdetű parancsok ezt tekergetik (elég sok van belőle). Körülbelül ugyanazokat a dolgokat lehet vele megvalósítani, mint a linux alatti md-vel. Legfontosabb különbség, hogy a meta eszközökhöz tartozó adatbázis replikák adminisztrációja itt kézzel történik (a metadb-nek érdemes külön slice-ot csinálni). A meglévő replikákat a metadb paranccsal lehet megnézni:
+
A meta eszközök működése hasonló, mint a linux alatti szoftver raid-é, Solarisban ezt hívják volume managernek. Általában a meta kezdetű parancsok ezt tekergetik (elég sok van belőle). Körülbelül ugyanazokat a dolgokat lehet vele megvalósítani, mint a linux alatti md-vel. Legfontosabb különbség, hogy a meta eszközökhöz tartozó adatbázis replikák adminisztrációja itt kézzel történik (a metadb-nek érdemes külön slice-t csinálni). A meglévő replikákat a metadb paranccsal lehet megnézni:
 
<pre>
 
<pre>
 
# metadb
 
# metadb
1 125. sor: 1 135. sor:
   
 
=== ZFS ===
 
=== ZFS ===
A ZFS a Solaris legújabb, 128 bites fájlrendszere. Ennek következtében egy fájlrendszer maximális mérete 256 quadrillió zetabyte, ami elképzelhetetlenül nagyon sok. Másik fontos újítása, hogy egyszerű kezelni, mindent a zpool és a zfs parancsokkal kell megcsinálni (persze ezeknek nagyon sok lehetősége van). Ha a linux felől közelítjük meg a dolgot úgy kell elképzelni, mintha az LVM maga fájlrendszer is lenne, és nem kellene rajta fájlrendszereket létrehozni, és magában támogat minden fájlrendszerekkel kapcsolatos dolgot. Azzal, hogy az egészben egy absztrakciós szinttel kevesebb van, nyilvánvaló teljesítménynövekedés érhető el, ezen kívül rengeteg előnye van. Egy ilyen például, hogy a RAID-Z (ami egy RAID5, csak trükkös) ezzel oldja meg a RAID5 write hole problémát, ami ma minden RAID5 implementációnál fennáll. Ha a RAID5 blokknak csak egy része került kiírásra (a többi része valamiért nem, pl. áramszünet volt), így a paritás nem lesz jó az adott blokkra egészen addig, amíg valami felül nem írja az adott blokkot. A ZFS ennek kiküszöbölésére változó méretű blokkokat használ, így minden kiírt blokk teljes blokk. Ez azért lehetséges, mert a ZFS kezeli a fájlrendszert és az eszközöket is. Erre a probélmára a RAID-Z az első csak szoftveren alapuló megoldás (hardveresen ezt pl. a RAID controlleren egy akku megoldja).
+
A ZFS a Solaris legújabb, 128 bites fájlrendszere. Ennek következtében egy fájlrendszer maximális mérete 256 quadrillió zetabyte, ami elképzelhetetlenül nagyon sok. Másik fontos újítása, hogy egyszerű kezelni, mindent a zpool és a zfs parancsokkal kell megcsinálni (persze ezeknek nagyon sok lehetősége van). Ha a linux felől közelítjük meg a dolgot úgy kell elképzelni, mintha az LVM maga fájlrendszer is lenne, és nem kellene rajta fájlrendszereket létrehozni, és magában támogat minden fájlrendszerekkel kapcsolatos dolgot. Azzal, hogy az egészben egy absztrakciós szinttel kevesebb van, nyilvánvaló teljesítménynövekedés érhető el, ezen kívül rengeteg előnye van. Egy ilyen például, hogy a RAID-Z (ami egy RAID5, csak trükkös) ezzel oldja meg a RAID5 write hole problémát, ami ma még a RAID5 implementációk [[RAID#RAID5|nagyobb részénél]] fennáll. Ha a RAID5 blokknak csak egy része került kiírásra (a többi része valamiért nem, pl. áramszünet volt), így a paritás nem lesz jó az adott blokkra egészen addig, amíg valami felül nem írja az adott blokkot. A ZFS ennek kiküszöbölésére változó méretű blokkokat használ, így minden kiírt blokk teljes blokk. Ez azért lehetséges, mert a ZFS kezeli a fájlrendszert és az eszközöket is. Erre a probélmára a RAID-Z az első csak szoftveren alapuló megoldás (hardveresen ezt pl. a RAID controlleren egy akku megoldja).
 
Az alábbi diskek állnak rendelkezésre:
 
Az alábbi diskek állnak rendelkezésre:
 
<pre>
 
<pre>
1 288. sor: 1 298. sor:
 
== Ajánlott irodalom ==
 
== Ajánlott irodalom ==
 
* Tomka Gergely: [http://gergely.tomka.hu/raidenbd/ RAID és ENBD - gyakorlati útmutató]. Könnyed bevezetés a [[RAID]], az [[Logikai kötetkezelés|LVM]] és az [http://www.it.uc3m.es/~ptb/nbd/ ENBD] (Enhanced Network Block Device) használatába.
 
* Tomka Gergely: [http://gergely.tomka.hu/raidenbd/ RAID és ENBD - gyakorlati útmutató]. Könnyed bevezetés a [[RAID]], az [[Logikai kötetkezelés|LVM]] és az [http://www.it.uc3m.es/~ptb/nbd/ ENBD] (Enhanced Network Block Device) használatába.
  +
* [https://gitlab.com/cryptsetup/cryptsetup LUKS] - így titkosíthatunk egy teljes blokkeszközt (merevlemezt, partíciót, RAID-tömböt). A [https://github.com/t-d-k/LibreCrypt LibreCrypt] segítségével Windowson is használható.
  +
* [http://clemens.endorphin.org/LinuxHDEncSettings Linux hard disk encryption settings] - a merevlemez-titkosítás kriptográfiai elmélete, lehetséges támadások
   
 
== Potenciális zh-kérdések ==
 
== Potenciális zh-kérdések ==
  +
 
* Miért jó logikai kötetkezelést használni? Mondjon alkalmazási példákat is!
 
* Miért jó logikai kötetkezelést használni? Mondjon alkalmazási példákat is!
** rugalmasan oszthatjuk szét a rendelkezésre álló (akár több partíción, fizikai eszközön vagy más logikai eszközön lévő) tárhelyet logikai eszközök között
 
*** Ez jó, de mit ''jelent''? Kéne néhány alkalmazási példa. Oda is írom a kérdésbe. --[[User:KornAndras|Korn András]] 2006. november 13., 17:36:13 (CET)
 
 
* Milyen fogalmakkal dolgozik a Linux LVM? Melyik micsoda (pl. LV, PV, VG)?
 
* Milyen fogalmakkal dolgozik a Linux LVM? Melyik micsoda (pl. LV, PV, VG)?
** LV = logical volume: absztrakt lemezes eszköz, ez a produkált „végeredménye” a LVM-nek
+
* Mire a snapshot LV? Hogyan működik?
*** Szintén jól hangzik, de effektíve, mit jelent ez? Le kell írni, hogy az LV egy olyan virtuális blokk-eszköz (vagy block device), ami egy volume groupba csoportosított tárolóhelynek egy "szelete"; filerendszert lehet benne/rajta létrehozni. --[[User:KornAndras|Korn András]] 2006. november 13., 17:36:13 (CET)
 
** PE = physical extent: egy fizikai lemezdarab (adott számú blokk)
 
** PV = physical volume: egy LVM-hez rendelt fizikai háttéroló, amit az LVM „birtokba vett”, létrehozta rajta az adatstruktúráit
 
** VG = volume group: PV-k egy csoportjából összeálló logikai egység, ami logikai „partíciókra”, azaz LV-kre osztható
 
* Mire jó a snapshot LV?
 
** egy adott logikai kötet állapotát „lefényképezhetjük”, ezzel egy tetszőleges pillanatban
 
** a kötetről nem készül azonnal másolat, a későbbi változtatások íródnak ki folyamatosan (''copy-on-write'' szemantika)
 
*** Hova? Konkrétan az eredeti tartalom másolata íródik a snapshot LV-be, ha a kiindulási LV valamely része módosul. Ennél ezt biztosan meg lehet fogalmazni szabatosabban is. :) --[[User:KornAndras|Korn András]] 2006. november 13., 17:36:13 (CET)
 
 
* Hogyan lehet snapshot LV segítségével online mentést nem támogató adatbázisról mégis kvázi-online mentést csinálni?
 
* Hogyan lehet snapshot LV segítségével online mentést nem támogató adatbázisról mégis kvázi-online mentést csinálni?
** leállítjuk az adatbázist &ndash; ami az adatokat egy logikai köteten tárolja &ndash;, vagy legalábbis befagyasztjuk tranzakciókat
 
** elkészítünk egy pillanatfelvételt az adott logikai kötetről
 
** az adatbázist újraindítjuk / megengedjük újból a tranzakciók kiírását diszkre
 
** ezután az LVM maga gondoskodik a logikai köteten lévő adatok változása során, hogy kiírja a pillanatfelvétel óta változott adatokat („copy-on-write”) illetve a pillanatfelvétel időpontjában aktuális adatok folyamatosan olvashatóak róla
 
** ha tényleg helyreállítási célra kell, le is kell másolni a snapshot kötetet, hogy „az ellen is” védjen (ne csak olvassa a &ndash; közben meghibásodott, változatlan &ndash; adatokat)
 
*** Igen, pompás. :) Azért a zh-ban legyen kifejtve, mi az az "az ellen". :) --[[User:KornAndras|Korn András]] 2006. november 13., 17:36:13 (CET)
 
 
* Milyen elvárásaink legyenek azokkal a filerendszerekkel szemben, amelyeket logikai kötetekben akarunk használni?
 
* Milyen elvárásaink legyenek azokkal a filerendszerekkel szemben, amelyeket logikai kötetekben akarunk használni?
** lehessen megnövelni a méretét
 
*** lehetőleg mindezt on-line, azaz lecsatolás nélkül
 
**** és gyorsan, és az inode-okat is dinamikusan allokálja, mert különben lehet, hogy hiába csinálunk új helyet, inode-ból futunk ki --[[User:KornAndras|Korn András]] 2006. november 13., 17:36:13 (CET)
 
** esetleg lehessen csökkenteni a méretét
 
*** lehetőleg mindezt on-line, azaz lecsatolás nélkül
 
** minden, amit egy „normális” fájlrendszertől elvárunk: támogasson megfelelő méretű partíciókat, naplózzon, legyen megbízható, stb.
 
*** Ez igaz, de mivel a kérdés kihangsúlyozta, hogy a logikai kötetekbe rakandó filerendszerekről van szó, nem muszáj leírni. --[[User:KornAndras|Korn András]] 2006. november 13., 17:36:13 (CET)
 
 
* Hogyan lehet snapshot LV-k segítségével "homokozót" csinálni, és milyen esetben jó ez?
 
* Hogyan lehet snapshot LV-k segítségével "homokozót" csinálni, és milyen esetben jó ez?
** (kritikus) rendszerfrissítés, olyan átalakítás előtt, aminek a kimenetelében nem bízunk:
 
*** készítsünk pillanatfelvételt az éles rendszerről,
 
*** majd '''ezen''' végezzük el a szükséges frissítéseket;
 
*** amik ha sikerültek, akkor végezzük el őket az éles rendszeren is,
 
*** ellenkező esetben töröljük a snapshotot, és próbálkozunk újra.
 
 
* Mekkora helyet kell biztosítanunk egy snapshot LV számára?
 
* Mekkora helyet kell biztosítanunk egy snapshot LV számára?
** legalább akkora méretűt, amin elférnek az eredeti LV-től eltérő adatok és a kiírásukhoz szükséges metaadatok
 
*** Ez kicsit zavaros. --[[User:KornAndras|Korn András]] 2006. november 13., 17:36:13 (CET)
 
* ''ZFS nem lesz.''
 

A lap jelenlegi, 2016. július 10., 21:54-kori változata

A logikai kötetkezelés egy új logikai absztrakciós réteget biztosít a gépben található háttértárolók és a fájlrendszerek között. Ez egyebek mellett lehetővé teszi, hogy a fizikai tárolóeszközöket logikai egységekbe szervezzük, és rugalmasan átméretezhető logikai köteteket hozzunk létre. Ha később új diszk kerül a gépbe, azt is hozzáadhatjuk egy kötetcsoporthoz, és teljesen transzparens módon átlóghatnak rá a filerendszereink, anélkül, hogy külön foglalkoznunk kellene azzal, hogy melyik fizikai diszkre is kerüljenek.

Ez 2000-ben, amikor megjelent a kernelben, nagyon fontos újdonság volt, már-már a szeletelt kenyérhez hasonló, de 2015-ben azért már érezhetően nyögvenyelős mondjuk a ZFS-hez képest.

Tartalomjegyzék

[szerkesztés] 1 Linux LVM

(Itt most csak a 2.6-os kernelben levő LVM2-vel foglalkozunk. A 2.4-es szériában található LVM1 nagyjából ugyanezt tudta, csak volt néhány korlátozása. Szintén nagyon hasonló az AIX és a HP-UX logikai kötetkezelője.)

A Linux LVM (Logical Volume Management) a következő fogalmakkal dolgozik:

[szerkesztés] 1.1 Physical extent

Allokációs egység. Ekkora egységenként oszthatjuk szét a volume groupban levő helyet a logical volume-ok között (l. később).

Ha akarjuk, hívhatjuk magyarul fizikai mértéknek, de ez elég sután hangzik.

[szerkesztés] 1.2 Physical volume

A physical volume olyan fizikai háttértároló, amin létrehoztuk az LVM metaadat-struktúráját a pvcreate paranccsal. Pl:

# pvcreate /dev/hda
  Physical volume "/dev/hda" successfully created
# pvcreate /dev/loop0
  Physical volume "/dev/loop0" successfully created
# pvcreate /dev/sda3
  Physical volume "/dev/sda3" successfully created

Fontosabb opciók:

  • --uuid: minden physical volume-nak van egy egyedi azonosítója. Ha egy diszket kicserélünk, és az új diszket be akarjuk tenni a régi helyére az LVM-be, akkor a --uuid kapcsolóval be kell állítanunk rajta a régi diszk azonosítóját (ennek akkor lehet értelme, ha az eredeti diszk elromlott, és végső elkeseredésünkben már azzal is beérjük, ha azokat az adatokat strukturált formában lementhetjük, amelyek a kötetcsoport többi diszkjén voltak).

Dokumentáció:

Ha akarjuk, a physical volume-ot hívhatjuk magyarul fizikai kötetnek.

[szerkesztés] 1.2.1 Physical volume-ok kezelése

A pvdisplay paranccsal nézhetjük meg, milyen physical volume-jaink vannak:

# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md2
  VG Name               raid5
  PV Size               697.91 GB / not usable 0   
  Allocatable           yes 
  PE Size (KByte)       32768
  Total PE              22333
  Free PE               4094
  Allocated PE          18239
  PV UUID               elN9K7-dvxq-b0fd-daqR-693p-fHqD-SwbDpD

  --- NEW Physical volume ---
  PV Name               /dev/loop0
  VG Name               
  PV Size               31.81 MB
  Allocatable           NO
  PE Size (KByte)       0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               hlzs9k-H253-ERpK-R39N-8ICT-4bU6-D0xtc1

Láthatjuk, hogy az első megtalált physical volume a /dev/md2-n, egy RAID tömbön van, és a raid5 nevű volume group része (l. később). A második volume a /dev/loop0 loopback device-on (tehát valójában egy ehhez a device-hoz tartozó image file-ban) van, és még nem rendeltük hozzá volume grouphoz, ezért nem is használható a benne levő hely (Allocatable: no). A közölt adatok:

  • PV Name - annak a unix device-nak a neve, amin a physical volume található.
  • VG Name - annak a volume groupnak a neve, amelyhez a physical volume tartozik.
  • PV Size - a PV mérete
  • Allocatable - Felhasználható-e a PV-n levő hely
  • PE Size - a physical extentek mérete abban a volume groupban, amelyhez a PV tartozik.
  • Total, Free, Allocated PE - összes physical extent száma, ebből hány szabad, hány foglalt.
  • PV UUID - egyedi azonosító.

Majdnem ugyanezt tudja a pvs parancs is:

# pvs
  PV         VG    Fmt  Attr PSize   PFree  
  /dev/loop0       lvm2 --    31.81M  31.81M
  /dev/md2   raid5 lvm2 a-   697.91G 127.94G

A pvs esetén testreszabhatóbb és tömörebb a kimenet, emiatt általában érdemesebb ezt használni. Részletesebben l. a dokumentációban.

A pvscan outputja is nagyon hasonló:

  PV /dev/md2     VG raid5   lvm2 [697.91 GB / 127.94 GB free]
  PV /dev/loop0              lvm2 [31.81 MB]
  Total: 2 [697.94 GB] / in use: 1 [697.91 GB] / in no VG: 1 [31.81 MB]

A különbség az, hogy a pvscan újra végignézi az összes block device-t, a pvs és a pvdisplay pedig a kernel adatstruktúráiból szedi az információt.

A pvmove segítségével az egyik phyiscal volume-ban levő physical extenteket átmozgathatjuk a volume group egy másik physical volume-jára. Ennek akkor van értelme, ha pl. ki akarjuk venni az adott fizikai diszket a gépből, vagy a volume groupból. A pvmove online művelet, vagyis menet közben is használhatjuk, írhatjuk és olvashatjuk az érintett volume-ot.

  • Legalábbis ez az elmélet; a gyakorlatban nagy I/O-terhelés mellett bizonyos kernelverziók holtpontra juthatnak pvmove közen. Ez valószínűleg nem jár adatvesztéssel, de csak újraindítással orvosolható.

A pvremove segítségével eltávolíthatjuk az LVM-címkét egy PV-ről, így az LVM a továbbiakban nem vesz róla tudomást.

[szerkesztés] 1.3 Volume group

A volume group lényegében egy logical volume-okkal "partícionálható" absztrakt merevlemez; physical volume-ok egy csoportja. Közvetlenül nem lehet rá adatokat írni, de a benne levő helyet tetszés szerint szétoszthatjuk logical volume-ok között.

Létrehozása a vgcreate paranccsal történik.

# vgcreate proba /dev/loop0
  Volume group "proba" successfully created
# pvdisplay
[...]
  --- Physical volume ---
  PV Name               /dev/loop0
  VG Name               proba
  PV Size               28.00 MB / not usable 0   
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              7
  Free PE               7
  Allocated PE          0
  PV UUID               hlzs9k-H253-ERpK-R39N-8ICT-4bU6-D0xtc1

Egynél több PV-t is felsorolhatunk a parancssorban; ezek mind bekerülnek az új volume groupba (hívhatjuk kötetcsoportnak).

Fontosabb opciók:

  • -s, --physicalextentsize PhysicalExtentSize[kKmMgGtT]: a physical extentek méretét adja meg.

Ilyen granularitással oszthatjuk szét a helyet a logical volume-ok között. A filerendszer I/O teljesítményére elvileg nincs hatással, csak az LVM segédprogramjai lesznek lassúbbak, ha túl sok van (mert túl kicsik). A meta-adatok mennyisége is nagyobb lehet, ha több PE van. Manapság kevés olyan felhasználást lehet elképzelni, ahol szükség lehet 16MB-nál kisebb granularitásra.

Dokumentáció:

[szerkesztés] 1.3.1 Volume groupok kezelése

Listázás: vgdisplay

# vgdisplay
  --- Volume group ---
  VG Name               raid5
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  21
  VG Access             read/write
  VG Status             resizable
  MAX LV                32
  Cur LV                5
  Open LV               5
  Max PV                16
  Cur PV                1
  Act PV                1
  VG Size               697.91 GB
  PE Size               32.00 MB
  Total PE              22333
  Alloc PE / Size       18239 / 569.97 GB
  Free  PE / Size       4094 / 127.94 GB
  VG UUID               I4pM7R-wmD9-m3VP-0OI1-ahbb-hdKy-QIQXnL
   
  --- Volume group ---
  VG Name               proba
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               28.00 MB
  PE Size               4.00 MB
  Total PE              7
  Alloc PE / Size       0 / 0   
  Free  PE / Size       7 / 28.00 MB
  VG UUID               U2pJ4S-J3fj-ebb0-ojYt-Vn7c-VAHU-w7WIlS

A vgdisplaynek van egy -v kapcsolója, aminek a hatására a logical volume-okat is listázza.

A pv*-gal analóg módon van vgs és vgscan is.

A vgchange-dzsel lehet "aktiválni" és "deaktiválni" a kötetcsoportokat (ha nem aktiváljuk, nem tudjuk mountolni a benne levő LV-ket).

# vgchange -a y
  5 logical volume(s) in volume group "raid5" now active
  0 logical volume(s) in volume group "proba" now active

A vgcfgbackup/vgcfgrestore segítségével készíthetünk ill. állíthatunk vissza biztonsági mentést az LVM-konfigurációnkról. A felhasználói adatokat természetesen nem menti el, de arra az esetre, ha megsérülnének az LVM saját adatterületei, vagy véletlenül megszüntetnénk egy fontos LV-t, jól jön.

A vgck ellenőrzi a meta-adatok konzisztenciáját.

Ha egy kötetcsoportot át akarunk vinni egy másik számítógépbe, akkor először exportálnunk kell a vgexport segítségével:

# vgexport proba
  Volume group "proba" successfully exported
# vgdisplay proba
  WARNING: volume group "proba" is exported
  --- Volume group ---
  VG Name               proba
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             exported/resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               28.00 MB
  PE Size               4.00 MB
  Total PE              7
  Alloc PE / Size       0 / 0   
  Free  PE / Size       7 / 28.00 MB
  VG UUID               U2pJ4S-J3fj-ebb0-ojYt-Vn7c-VAHU-w7WIlS

Az exportált kötetcsoport nem aktiválható, amíg nem importáljuk:

# vgchange -a y proba
  Volume group "proba" is exported
# vgimport proba
  Volume group "proba" successfully imported
# vgchange -a y proba
  0 logical volume(s) in volume group "proba" now active

Növelés: vgextend. A vgextend segítségével a kötetcsoporthoz új PV-ot adhatunk hozzá.

Összehúzás: vgreduce. A vgreduce segítségével a kötetcsoportból eltávolíthatunk egy üres PV-t (tehát olyat, amin egyetlen PE-t - physical extentet - sem foglal egyetlen LV - logical volume - sem).

Összevonás: vgmerge. A vgmerge segítségével egy inaktív VG-ot beolvaszthatunk egy másik létező VG-ba, ha a PE-méretek megegyeznek. A cél-VG-ban ezután benne lesznek mindkét kiinduló-VG LV-jai.

Szétválasztás: vgsplit. A kiinduló kötetcsoport fizikai kötetei közül néhányból új kötetcsoportot hozunk létre. A logikai kötetek nem lóghatnak át egyik kötetcsoportból a másikba (erről előtte szükség esetén pvmove-val gondoskodni kell).

A vgmknodes boot közben fut le, létrehozza a /dev alatt a volume groupjainkhoz tartozó bejegyzéseket.

Törlés: vgremove. Teljesen megszünteti a kötetcsoportot és újra felszabadítja a PV-jait.

Átnevezés: vgrename.

Növeljük meg a proba kötetcsoportot; adjunk hozzá egy újabb 32MB-os loop device-t.

# dd if=/dev/zero of=loop1 bs=1048576 count=32
32+0 records in
32+0 records out
33554432 bytes (34 MB) copied, 0.146919 seconds, 228 MB/s
# losetup /dev/loop1 loop1
# pvcreate /dev/loop1
  Physical volume "/dev/loop1" successfully created
# vgextend proba /dev/loop1
  Volume group "proba" successfully extended

[szerkesztés] 1.4 Logical volume

A logical volume (legyen logikai kötet) úgy viselkedik, mint egy merevlemezpartíció, azzal a különbséggel, hogy:

  • szabadon, on-line átméretezhető (a rajta/benne található filerendszert ettől persze külön át kell méretezni);
  • on-line átmozgatható másik diszkre;
  • készíthető róla snapshot.

Létrehozása: lvcreate:

# lvcreate -L 8M -n proba_lv_1 proba
  Logical volume "proba_lv_1" created

Fontosabb opciók:

  • -L - méret byte-ban, megabyteban, gigabyteban stb.
  • -l - méret PE-ben
  • -n - a létrehozandó LV neve
  • -i - csíkszám (hány különböző PV-n szórja szét - kvázi RAID0)
  • --mirrors - tükrök száma (hány különböző PV-n tárolja ugyanazt - kvázi RAID1, de naplózva, úgyhogy nem kell minden crash után resyncelni; ennek feltétele, hogy egy harmadik eszközön tartsuk a naplót)
  • --type - típus: striped, zero, error, snapshot, mirror
    • Ebből közvetlenül csak a zerot és az errort lehet értelme megadni (ellenvélemény?)
    • zero: nullákkal teli (írhatatlan) virtuális volume
    • error: hibákkal teli (olvashatatlan és írhatatlan) virtuális volume
    • Ezeket átméretezéskor is megadhatjuk, tehát bővíthetjük ilyen típusú PE-kkel a LV-ot.
      • Házi feladat: mire jó ez?

A csíkozás és a tükrözés jelenleg nem használható egyszerre, de ez nem probléma, mert a hagyományos linuxos softraiddel mindezt meg tudjuk csinálni.

[szerkesztés] 1.4.1 Logical volume-ok kezelése

Hozzunk létre egy tükrözött és egy csíkozott LV-t. Ehhez csináltam egy proba2 kötetcsoportot, ami három PV-ből áll; az egyikben lesz az első tükör, a másikban a második, a harmadikban pedig a napló (az LVM lognak hívja, nem journalnak).

# lvcreate --mirrors 1 -l 2 -n proba_lv_1 proba2                 
  Logical volume "proba_lv_1" created

# vgdisplay proba2
  --- Volume group ---
  VG Name               proba2
  System ID             
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                4
  Open LV               0
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               180.00 MB
  PE Size               4.00 MB
  Total PE              45
  Alloc PE / Size       5 / 20.00 MB
  Free  PE / Size       40 / 160.00 MB
  VG UUID               K03ymb-kgin-AHf4-vPBZ-6I5E-xKTs-LbLjRu

# lvdisplay /dev/proba2/proba_lv_1    
  --- Logical volume ---
  LV Name                /dev/proba2/proba_lv_1
  VG Name                proba2
  LV UUID                rF1Wa4-23kr-9G0o-GH0D-O8QG-M7oF-pPPRcI
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                8.00 MB
  Current LE             2
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:8

# lvcreate -l 6 -i 3 -n proba_lv_2 proba2       
  Using default stripesize 64.00 KB
  Logical volume "proba_lv_2" created

# vgdisplay proba2
  --- Volume group ---
  VG Name               proba2
  System ID             
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               0
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               180.00 MB
  PE Size               4.00 MB
  Total PE              45
  Alloc PE / Size       11 / 44.00 MB
  Free  PE / Size       34 / 136.00 MB
  VG UUID               K03ymb-kgin-AHf4-vPBZ-6I5E-xKTs-LbLjRu

# lvdisplay /dev/proba2/proba_lv_2 
  --- Logical volume ---
  LV Name                /dev/proba2/proba_lv_2
  VG Name                proba2
  LV UUID                q8OujL-uysn-75KG-2A6l-p15a-ewQ4-mgP8d8
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                24.00 MB
  Current LE             6
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:9

# lvs
  LV         VG     Attr   LSize   Origin Snap%  Move Log             Copy% 
  proba_lv_1 proba2 mwi-a-   8.00M                    proba_lv_1_mlog 100.00
  proba_lv_2 proba2 -wi-a-  24.00M                                          

# lvscan 
  ACTIVE            '/dev/proba2/proba_lv_1' [8.00 MB] inherit
  ACTIVE            '/dev/proba2/proba_lv_2' [24.00 MB] inherit

dmsetuppal látjuk a mirrorokat és a logot is:

# dmsetup info
Name:              proba2-proba_lv_1_mimage_1
State:             ACTIVE
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 7
Number of targets: 1
UUID: LVM-K03ymbkginAHf4vPBZ6I5ExKTsLbLjRuaM82P6ppVyBjJsv32VdW4a8auXRZNnaj

Name:              proba2-proba_lv_1_mimage_0
State:             ACTIVE
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 6
Number of targets: 1
UUID: LVM-K03ymbkginAHf4vPBZ6I5ExKTsLbLjRuS4NGUUe90L1UOyuPDqVGMVBgTnLCPRQl

Name:              proba2-proba_lv_1_mlog
State:             ACTIVE
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 5
Number of targets: 1
UUID: LVM-K03ymbkginAHf4vPBZ6I5ExKTsLbLjRuc8xYiqrk26zrQMaJb14k6Fxlcw9QmETz

Name:              proba2-proba_lv_1
State:             ACTIVE
Tables present:    LIVE
Open count:        0
Event number:      1
Major, minor:      253, 8
Number of targets: 1
UUID: LVM-K03ymbkginAHf4vPBZ6I5ExKTsLbLjRurF1Wa423kr9G0oGH0DO8QGM7oFpPPRcI

Name:              proba2-proba_lv_2
State:             ACTIVE
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 9
Number of targets: 1
UUID: LVM-K03ymbkginAHf4vPBZ6I5ExKTsLbLjRuq8OujLuysn75KG2A6lp15aewQ4mgP8d8

# dmsetup status     
proba2-proba_lv_1_mimage_1: 0 16384 linear 
proba2-proba_lv_1_mimage_0: 0 16384 linear 
proba2-proba_lv_1_mlog: 0 8192 linear 
proba2-proba_lv_2: 0 49152 striped 
proba2-proba_lv_1: 0 16384 mirror 2 253:6 253:7 16/16

A dmsetup amúgy a kernelben levő device mapper alrendszerrel kommunikál, és információnyerésen kívül más érdekes dolgokra is használható. A felhasználási területek körüljárása egy lehetséges házi feladat. Lehet vele pl. titkosított block device-t csinálni.

Átméretezés: lvextend, lvreduce, lvresize. A -L/-l kapcsolókkal megadhatjuk az új méretet abszolút értékkel vagy az előzőhöz képest (pl. lvextend -L +1G /dev/raid5/var - egy gigabyte-tal megnöveljük a raid5 kötetcsoport var nevű logikai kötetét).

Törlés: lvremove.

Átnevezés: lvrename.

[szerkesztés] 1.4.2 Snapshot Logical Volume

  • Pillanatfelvétel egy LV aktuális állapotáról.
  • Copy-on-write szemantika: ha az eredetit módosítjuk, akkor a snapshotban létrejön a korábbi tartalom másolata.
  • Ha kevés az írás, viszonylag kis snapshot volume is elég lehet viszonylag nagy adatterülethez.
  • A snapshot írható is (az LVM1-ben csak olvasható volt).
  • Felhasználás pl.:
    • Majdnem-online adatbázis-backup:
      1. "Egy pillanatra" leállítjuk az adatbázist.
      2. Csinálunk az LV-ről egy snapshotot (ez gyors művelet).
      3. Újra elindítjuk az adatbázist. A snapshoton az eredeti, konzisztens tartalom látszik.
      4. A kedvenc offline backup-eszközünkkel elmentjük a snapshot volume-on található adatbázispéldányt.
      5. Töröljük a snapshot volume-ot.
    • Rendszer-rollback:
      • Upgrade vagy egyéb veszélyes beavatkozás előtt az összes volume-ról csinálunk snapshotot.
      • Ha vissza akarunk térni a korábbi állapothoz, mindent visszamásolunk a snapshotból.
        • Újabban: lvconvert --merge beolvasztja a snapshotot az eredetibe.
      • Akár bootolhatunk is úgy, hogy a snapshotokat mountoljuk a "valódi" LV-k helyett.
        • Ehhez az kell, hogy a rootfs snapshotjában levő fstabban a snapshotok szerepeljenek a valódi LV-k helyett.
        • Tehát a snapshot létrehozása után át kell írni az fstabot a snapshoton.
    • Sandbox:
      1. Snapshotot csinálunk a rendszerről.
      2. Belechrootolunk.
      3. Kipróbáljuk, amit ki akartunk próbálni. Csak a snapshot módosul.
      4. Ha jól működött, amit kipróbáltunk, lvconvert --merge-dzsel beolvasztjuk a snapshotot az eredeti kötetbe; ha nem, töröljük a snapshotot.
    • VM klónozása:
      • Ha sok hasonló virtuális gépet akarunk futtatni, csinálunk egy master LV-ot, amiben összerakjuk a filerendszert.
      • Ennek a snapshotjait kapják meg a virtuális gépek (pl. UML vagy xenU).
      • Így sokkal kevesebb helyet foglalnak, mivel az adatok nagy része közös helyen lesz.
      • Ez csak akkor jó, ha kevés a változás; ha sok, akkor idővel (legfeljebb) ugyanannyi helyet fognak foglalni a snapshotok, mintha eleve külön LV-ket hoztunk volna létre.
        • Jobb választás lehet egy blokkszinten deduplikáló fájlrendszer.

Létrehozása: lvcreate -s.

Próbáljuk ki:

# mke2fs /dev/proba2/proba_lv_2 
[...]
# mount /dev/proba2/proba_lv_2 /mnt/proba_lv_2 
# cat <<EOF >/mnt/proba_lv_2/tesztfile
heredoc> Boci boci tarka
heredoc> Se fule se farka
heredoc> Oda megyunk lakni
heredoc> Ahol tejet kapni
heredoc> EOF

# cd /mnt/proba_lv_2 
# ls -la
total 15
drwxr-xr-x  3 root root  1024 Sep 26 02:02 .
drwxr-xr-x 18 root root  1024 Sep 26 02:01 ..
drwx------  2 root root 12288 Sep 26 02:00 lost+found
-rw-r--r--  1 root root    67 Sep 26 02:02 tesztfile

# cat tesztfile 
Boci boci tarka
Se fule se farka
Oda megyunk lakni
Ahol tejet kapni

# lvcreate -l 1 -s -n proba_lv_2_snap /dev/proba2/proba_lv_2 
  Logical volume "proba_lv_2_snap" created

# lvs
  LV              VG     Attr   LSize   Origin     Snap%  Move Log             Copy% 
  proba_lv_1      proba2 mwi-a-   8.00M                        proba_lv_1_mlog 100.00
  proba_lv_2      proba2 owi-ao  24.00M                                              
  proba_lv_2_snap proba2 swi-a-   4.00M proba_lv_2   0.39                            

# dmsetup status
proba2-proba_lv_2-real: 0 49152 striped 
proba2-proba_lv_2_snap-cow: 0 8192 linear 
proba2-proba_lv_2_snap: 0 49152 snapshot 32/8192
proba2-proba_lv_1_mimage_1: 0 16384 linear 
proba2-proba_lv_1_mimage_0: 0 16384 linear 
proba2-proba_lv_1_mlog: 0 8192 linear 
proba2-proba_lv_2: 0 49152 snapshot-origin 
proba2-proba_lv_1: 0 16384 mirror 2 253:6 253:7 16/16

# lvdisplay /dev/proba2/*
  --- Logical volume ---
  LV Name                /dev/proba2/proba_lv_1
  VG Name                proba2
  LV UUID                rF1Wa4-23kr-9G0o-GH0D-O8QG-M7oF-pPPRcI
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                8.00 MB
  Current LE             2
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:8
   
  --- Logical volume ---
  LV Name                /dev/proba2/proba_lv_2
  VG Name                proba2
  LV UUID                q8OujL-uysn-75KG-2A6l-p15a-ewQ4-mgP8d8
  LV Write Access        read/write
  LV snapshot status     source of
                         /dev/proba2/proba_lv_2_snap [active]
  LV Status              available
  # open                 1
  LV Size                24.00 MB
  Current LE             6
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:9
   
  --- Logical volume ---
  LV Name                /dev/proba2/proba_lv_2_snap
  VG Name                proba2
  LV UUID                Am9wZ6-YHy2-DkeM-UDY1-K8X6-nZ1d-HAeoYl
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/proba2/proba_lv_2
  LV Status              available
  # open                 0
  LV Size                24.00 MB
  Current LE             6
  COW-table size         4.00 MB
  COW-table LE           1
  Allocated to snapshot  0.59% 
  Snapshot chunk size    8.00 KB
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:12
  
# mount /dev/proba2/proba_lv_2_snap /mnt/proba_lv_2_snap 

/mnt# ls -la proba_lv_2*
proba_lv_2:
total 15
drwxr-xr-x  3 root root  1024 Sep 26 02:02 .
drwxr-xr-x 19 root root  1024 Sep 26 02:07 ..
drwx------  2 root root 12288 Sep 26 02:00 lost+found
-rw-r--r--  1 root root    67 Sep 26 02:02 tesztfile

proba_lv_2_snap:
total 15
drwxr-xr-x  3 root root  1024 Sep 26 02:02 .
drwxr-xr-x 19 root root  1024 Sep 26 02:07 ..
drwx------  2 root root 12288 Sep 26 02:00 lost+found
-rw-r--r--  1 root root    67 Sep 26 02:02 tesztfile

# df -h
Filesystem            Size  Used Avail Use% Mounted on
[...]
/dev/mapper/proba2-proba_lv_2
                       24M   14K   23M   1% /mnt/proba_lv_2
/dev/mapper/proba2-proba_lv_2_snap
                       24M   14K   23M   1% /mnt/proba_lv_2_snap

# echo 'Ooooh, edes bociiii! Adj nekunk tejeeeeeeet!' >proba_lv_2/tesztfile 

# cat */tesztfile
Ooooh, edes bociiii! Adj nekunk tejeeeeeeet!
Boci boci tarka
Se fule se farka
Oda megyunk lakni
Ahol tejet kapni

# lvs
  LV              VG     Attr   LSize   Origin     Snap%  Move Log             Copy% 
  proba_lv_1      proba2 mwi-a-   8.00M                        proba_lv_1_mlog 100.00
  proba_lv_2      proba2 owi-ao  24.00M                                              
  proba_lv_2_snap proba2 swi-ao   4.00M proba_lv_2   0.59

# echo 'Ezt is lehet' >proba_lv_2_snap/tesztfile 

/mnt# cat */tesztfile
Ooooh, edes bociiii! Adj nekunk tejeeeeeeet!
Ezt is lehet

# lvs
  LV              VG     Attr   LSize   Origin     Snap%  Move Log             Copy% 
  proba_lv_1      proba2 mwi-a-   8.00M                        proba_lv_1_mlog 100.00
  proba_lv_2      proba2 owi-ao  24.00M                                              
  proba_lv_2_snap proba2 swi-ao   4.00M proba_lv_2   0.98

# umount /mnt/proba_lv_2_snap 

# lvremove /dev/proba2/proba_lv_2_snap 
Do you really want to remove active logical volume "proba_lv_2_snap"? [y/n]: y
  Logical volume "proba_lv_2_snap" successfully removed

# lvs
  LV         VG     Attr   LSize   Origin Snap%  Move Log             Copy% 
  proba_lv_1 proba2 mwi-a-   8.00M                    proba_lv_1_mlog 100.00
  proba_lv_2 proba2 -wi-a-  24.00M                                          

xfs filerendszer esetén a snapshotot csak a nouuid opcióval tudjuk bemountolni; enélkül az xfs azt hiszi, hogy ugyanazt a fizikai filerendszert próbáljuk mountolni másodszor is.

[szerkesztés] 1.5 EVMS

EVMS: Enterprise Volume Management System. Nem a népszerű scifisorozat hangerejének kezelésére szolgál.

LVM-ebb az LVM-nél. Részletek házi feladatként itt: EVMS

[szerkesztés] 1.6 LVM és RAID

Természetesen van értelme egyszerre RAIDet (akár szoftveres RAIDet) és LVM-et használni; a RAID biztosítja a redundanciát és/vagy a csíkozást, az LVM pedig a rugalmasságot.

Ha egy már LVM-et használó rendszerből szeretnénk RAID1-es rendszert csinálni, arra az alábbi receptet használhatjuk:

  1. Új diszk(ek) beépítése
  2. RAID tömb létrehozása az új diszk(ek)ből (--create --level=1 --raid-devices=2 /dev/mdX /dev/ujdisk missing, így "féllábú" lesz a RAID, eleve degradált tömb jön létre)
  3. pvcreate az új RAID-tömbön
  4. vgextend-del hozzáadjuk a meglevő volume grouphoz az új fizikai kötetet (ami a féllábú RAID)
  5. pvmove-val átmozgatunk minden adatot a régi PV-ról az újra
  6. vgreduce-szal kiszedjük a VG-ból a régi diszk(ek)et
  7. mdadm-mal új raid-eszközként hozzáadjuk a régi diszk(ek)et a féllábú RAID-tömbhöz
  8. Kész.

A műveletek nagy része online elvégezhető (kivéve esetleg az új diszkek beépítését, de jobb hardver esetén az is megy leállítás nélkül).

Ügyeljünk arra, hogy az összes softraides partíciónk típusa 0xFD legyen ("Linux RAID Autodetect"), ha azt szeretnénk, hogy a kernel segítség nélkül össze tudja rakni boot közben.

[szerkesztés] 1.7 Gyakorlati tanácsok

Mindig hagyjunk szabad helyet a kötetcsoportjainkban!

Tartsuk észben, hogy a filerendszereinket bármikor könnyedén növelhetjük, de zsugorítani nagyon nehéz lesz. Ezért soha ne osszuk ki egy kötetcsoport összes helyét eleve, hanem minden filerendszernek mindig csak annyi helyet allokáljunk, amennyire biztosan szükség van. Így, ha valahol fogytán van a hely, a VG-ben levő szabad területből még tudunk gazdálkodni. Ha előre kiosztottuk az összes helyet és elrontottuk, akkor a változtatás egy teljes mentéssel, törléssel, az érintett LV-k újbóli létrehozásával, majd mentésből való visszaállással jár.

Az összes hely preallokálása minden bizonnyal a leggyakoribb tervezési hiba, amit kezdő LVM-felhasználók elkövetnek.

Ha nincs szabad hely, snapshotokat sem tudunk készíteni.

[szerkesztés] 2 Solaris

Írta: Boros Péter
Utolsó jelentős módosítás: 2006. szeptember.
Nem része a hivatalos tananyagnak, de l. a ZFS szócikket is, ami igen.

A Solaris 10 update 2 (6/06), illetve az opensolaris előtt a Solarisban nem vált szét élesen a logikai kötetkezelés és a szoftver RAID. Az így létrehozott metadevice-okon ugyanúgy UFS-t lehet használni, mint alapesetben a diskeken. 2006 júniusában azonban megjelent a ZFS a kereskedelmi solarisban, ami elég sok újítést hozott, és valamilyen szinten elavulttá tette az addigi logikai kötetkezelést. A metadevice-ok létrehozásának lehetősége a Solaris 9-től volt része a kereskedelmi Solarisnak (előző verziókhoz is elérhető volt patch formájában).

[szerkesztés] 2.1 Diskek

SPARC architektúra esetén minden disk tartalmaz 8 slice-ot, ebbol 7-re lehet fájlrendszereket létrehozni, a 2-es számú pedig az egész disket jelöli (mint pl. linux alatt a /dev/hda). A diskek a format parancs segitsegevel tekinthetok meg. x86 eseténben primary partíciókon belül emulálja a solaris a sparcos disket, így a solaris nem tud nem primary partíciót használni (ez nem baj, így x86on 1 disken 4*7=28 partíciót lehet létrehozni, a ZFS óra már ez a korlát sincs).
A format parancs kimenete:

# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c0t0d0 <ST39140A cyl 17660 alt 2 hd 16 sec 63>
          /pci@1f,0/pci@1,1/ide@3/dad@0,0
       1. c1t2d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
          /pci@1f,0/pci@1/scsi@1,1/sd@2,0
       2. c1t3d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
          /pci@1f,0/pci@1/scsi@1,1/sd@3,0
       3. c1t5d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
          /pci@1f,0/pci@1/scsi@1,1/sd@5,0
       4. c1t8d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
          /pci@1f,0/pci@1/scsi@1,1/sd@8,0
       5. c1t9d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
          /pci@1f,0/pci@1/scsi@1,1/sd@9,0
       6. c1t10d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
          /pci@1f,0/pci@1/scsi@1,1/sd@a,0

1 disk:

  0       root    wm       0 - 4847        8.30GB    (4848/0/0) 17409168
  1 unassigned    wu       0               0         (0/0/0)           0
  2     backup    wu       0 - 4923        8.43GB    (4924/0/0) 17682084
  3 unassigned    wm       0               0         (0/0/0)           0
  4 unassigned    wm       0               0         (0/0/0)           0
  5 unassigned    wm       0               0         (0/0/0)           0
  6 unassigned    wm       0               0         (0/0/0)           0
  7 unassigned    wm    4848 - 4923      133.26MB    (76/0/0)     272916

x86on ugyanez:

bash-3.00# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c0d0 <DEFAULT cyl 4092 alt 2 hd 128 sec 32>
          /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0
       1. c0d1 <VMware V-0000000000000000-0001-8.00GB>
          /pci@0,0/pci-ide@7,1/ide@0/cmdk@1,0
       2. c1d0 <DEFAULT cyl 4093 alt 2 hd 128 sec 32>
          /pci@0,0/pci-ide@7,1/ide@1/cmdk@0,0
       3. c1d1 <VMware V-0000000000000000-0001-8.00GB>
          /pci@0,0/pci-ide@7,1/ide@1/cmdk@1,0

1 disk:

Part      Tag    Flag     Cylinders        Size            Blocks
  0       root    wm       3 - 3820        7.46GB    (3818/0/0) 15638528
  1       swap    wu    3821 - 4076      512.00MB    (256/0/0)   1048576
  2     backup    wm       0 - 4091        7.99GB    (4092/0/0) 16760832
  3 unassigned    wm       0               0         (0/0/0)           0
  4 unassigned    wm       0               0         (0/0/0)           0
  5 unassigned    wm       0               0         (0/0/0)           0
  6 unassigned    wm       0               0         (0/0/0)           0
  7 unassigned    wm    4077 - 4091       30.00MB    (15/0/0)      61440
  8       boot    wu       0 -    0        2.00MB    (1/0/0)        4096
  9 alternates    wu       1 -    2        4.00MB    (2/0/0)        8192

Muveltek vegzese 1 disken formattal (sparc):

Specify disk (enter its number): 2
selecting c1t3d0
[disk formatted]



FORMAT MENU:
        disk       - select a disk
        type       - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format     - format and analyze the disk
        repair     - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect     - defect list management
        backup     - search for backup labels
        verify     - read and display labels
        save       - save new disk/partition definitions
        inquiry    - show vendor, product and revision
        volname    - set 8-character volume name
        !<cmd>     - execute <cmd>, then return
        quit
format>

format> verify

Primary label contents:

Volume name = <        >
ascii name  = <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
pcyl        = 4926
ncyl        = 4924
acyl        =    2
nhead       =   27
nsect       =  133
Part      Tag    Flag     Cylinders        Size            Blocks
  0 unassigned    wm       0               0         (0/0/0)           0
  1 unassigned    wu       0               0         (0/0/0)           0
  2     backup    wu       0 - 4923        8.43GB    (4924/0/0) 17682084
  3 unassigned    wm       0               0         (0/0/0)           0
  4 unassigned    wm       0               0         (0/0/0)           0
  5 unassigned    wm       0               0         (0/0/0)           0
  6 unassigned    wm       0               0         (0/0/0)           0
  7 unassigned    wm       0               0         (0/0/0)           0

format> partition


PARTITION MENU:
        0      - change `0' partition
        1      - change `1' partition
        2      - change `2' partition
        3      - change `3' partition
        4      - change `4' partition
        5      - change `5' partition
        6      - change `6' partition
        7      - change `7' partition
        select - select a predefined table
        modify - modify a predefined partition table
        name   - name the current table
        print  - display the current table
        label  - write partition map and label to the disk
        !<cmd> - execute <cmd>, then return
        quit

partition> 0
Part      Tag    Flag     Cylinders        Size            Blocks
  0 unassigned    wm       0               0         (0/0/0)           0

Enter partition id tag[unassigned]: root
Enter partition permission flags[wm]:
Enter new starting cyl[0]:
Enter partition size[0b, 0c, 0e, 0.00mb, 0.00gb]: 8.3gb
partition> print
Current partition table (unnamed):
Total disk cylinders available: 4924 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders        Size            Blocks
  0       root    wm       0 - 4847        8.30GB    (4848/0/0) 17409168
  1 unassigned    wu       0               0         (0/0/0)           0
  2     backup    wu       0 - 4923        8.43GB    (4924/0/0) 17682084
  3 unassigned    wm       0               0         (0/0/0)           0
  4 unassigned    wm       0               0         (0/0/0)           0
  5 unassigned    wm       0               0         (0/0/0)           0
  6 unassigned    wm       0               0         (0/0/0)           0
  7 unassigned    wm       0               0         (0/0/0)           0

partition> 7
Part      Tag    Flag     Cylinders        Size            Blocks
  7 unassigned    wm       0               0         (0/0/0)           0

Enter partition id tag[unassigned]:
Enter partition permission flags[wm]:
Enter new starting cyl[0]: 4848
Enter partition size[0b, 0c, 4848e, 0.00mb, 0.00gb]: 4923e
partition> print
Current partition table (unnamed):
Total disk cylinders available: 4924 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders        Size            Blocks
  0       root    wm       0 - 4847        8.30GB    (4848/0/0) 17409168
  1 unassigned    wu       0               0         (0/0/0)           0
  2     backup    wu       0 - 4923        8.43GB    (4924/0/0) 17682084
  3 unassigned    wm       0               0         (0/0/0)           0
  4 unassigned    wm       0               0         (0/0/0)           0
  5 unassigned    wm       0               0         (0/0/0)           0
  6 unassigned    wm       0               0         (0/0/0)           0
  7 unassigned    wm    4848 - 4923      133.26MB    (76/0/0)     272916

partition> label
Ready to label disk, continue? y

Az előbbiekben 1 üres disken létrehoztam 2 partíciót, így készíthető elő a fizikai eszköz arra, hogy majd metadevice része legyen.

[szerkesztés] 2.2 Meta devices

A meta eszközök működése hasonló, mint a linux alatti szoftver raid-é, Solarisban ezt hívják volume managernek. Általában a meta kezdetű parancsok ezt tekergetik (elég sok van belőle). Körülbelül ugyanazokat a dolgokat lehet vele megvalósítani, mint a linux alatti md-vel. Legfontosabb különbség, hogy a meta eszközökhöz tartozó adatbázis replikák adminisztrációja itt kézzel történik (a metadb-nek érdemes külön slice-t csinálni). A meglévő replikákat a metadb paranccsal lehet megnézni:

# metadb
metadb: mp3: there are no existing databases

Hozzunk létre 3 disken metadb replikákat:

# metadb -a -f c0t0d0s7 c1t2d0s7 c1t3d0s7
# metadb
        flags           first blk       block count
     a        u         16              8192            /dev/dsk/c0t0d0s7
     a        u         16              8192            /dev/dsk/c1t2d0s7
     a        u         16              8192            /dev/dsk/c1t3d0s7

Meg mégegyet, mert ilyet is lehet:

# metadb -a c1t5d0s7
# metadb
        flags           first blk       block count
     a        u         16              8192            /dev/dsk/c0t0d0s7
     a        u         16              8192            /dev/dsk/c1t2d0s7
     a        u         16              8192            /dev/dsk/c1t3d0s7
     a        u         16              8192            /dev/dsk/c1t5d0s7

Ha a metadb replikák legalább fele ugyanazt mondja a diskekről, akkor rendben van minden, automatikusan az ő tartalmuk fog érvényesülni. Ha nem, a meta eszközök nem fognak működni, ilyenkor kézzel kell megadni, hogy melyik replika lesz érvényes.

A linuxhoz hasonlóan, itt is egyszerűen megvalósíthatók a különböző szoftver RAID-ek. RAID0:

# metainit d1 1 2 c1t2d0s0 c1t3d0s0
d1: Concat/Stripe is setup

# metastat
d1: Concat/Stripe
    Size: 34807563 blocks (16 GB)
    Stripe 0: (interlace: 32 blocks)
        Device     Start Block  Dbase   Reloc
        c1t2d0s0          0     No      Yes
        c1t3d0s0       3591     No      Yes

Device Relocation Information:
Device   Reloc  Device ID
c1t2d0   Yes    id1,sd@SSEAGATE_ST39173W_SUN9.0GLMD830490000793052T2
c1t3d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP95339000019470FHT

Utána létre lehet rajta hozni UFS fájlrendszert:

# newfs /dev/md/rdsk/d1
newfs: construct a new file system /dev/md/rdsk/d1: (y/n)? y
Warning: 4342 sector(s) in last cylinder unallocated
/dev/md/rdsk/d1:        34807562 sectors in 5666 cylinders of 48 tracks, 128 sectors
        16995.9MB in 355 cyl groups (16 c/g, 48.00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
 32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
......
super-block backups for last 10 cylinder groups at:
 33918112, 34016544, 34114976, 34213408, 34311840, 34410272, 34508704,
 34607136, 34705568, 34804000

Fel is lehet mountolni, sőt, umountolni is:

# mount /dev/md/dsk/d1 /mnt
# df -h|grep d1
/dev/md/dsk/d1          16G    17M    16G     1%    /mnt

# umount /dev/md/dsk/d1

Törölni is egyszerű:

# metaclear d1
d1: Concat/Stripe is cleared

A RAID1 esetében mindez már kicsit komplikáltabb. RAID1 tömböt úgy lehet létrehozni, hogy létrehozunk 2 db RAID0-t (sima mirror esetén ezek 1 diskesek), majd megadjuk, hogy azok egymás tükrei legyenek. Első látásra ez valamilyen szinten komplikáltnak tűnik, a RAID10 tömb egyszerű létrehozhatósága miatt van így megoldva. Másik előnye, hogy a módszerrel egy éles rendszer root fájlrendszere is tükrözhető, anélkül, hogy az élesen kívül más operációs rendszert használnánk ehhez (nem kell single user módba bootolni, és livecd szerűségre sincs szükség). A root fájlrendszer tükrözéséhez a metaroot segédprogram használandó, ez még a vfstab-ot is módosítja megfelelően. Ezek után egy RAID1 tömb létrehozási procedúrája:

-bash-3.00# metainit d11 1 1 c1t2d0s0
d11: Concat/Stripe is setup

-bash-3.00# metainit d12 1 1 c1t3d0s0
d12: Concat/Stripe is setup

-bash-3.00# metainit d10 -m d11
d10: Mirror is setup

-bash-3.00# metattach d10 d12
d10: submirror d12 is attached

-bash-3.00# metastat
d10: Mirror
    Submirror 0: d11
      State: Okay
    Submirror 1: d12
      State: Resyncing
    Resync in progress: 0 % done
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 17409168 blocks (8.3 GB)

d11: Submirror of d10
    State: Okay
    Size: 17409168 blocks (8.3 GB)
    Stripe 0:
        Device     Start Block  Dbase        State Reloc Hot Spare
        c1t2d0s0          0     No            Okay   Yes


d12: Submirror of d10
    State: Resyncing
    Size: 17409168 blocks (8.3 GB)
    Stripe 0:
        Device     Start Block  Dbase        State Reloc Hot Spare
        c1t3d0s0          0     No            Okay   Yes


Device Relocation Information:
Device   Reloc  Device ID
c1t3d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP95339000019470FHT
c1t2d0   Yes    id1,sd@SSEAGATE_ST39173W_SUN9.0GLMD830490000793052T2

Ha már a redundanciáról esik szó, van lehetőség hot spare-ek használatára:

-bash-3.00# metahs -a hsp001 c1t5d0s0
hsp001: Hotspare is added
-bash-3.00# metahs -i
hsp001: 1 hot spare
        Device     Status      Length           Reloc
        c1t5d0s0   Available    17409168 blocks Yes

Device Relocation Information:
Device   Reloc  Device ID
c1t5d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJR34002000019460G0S

-bash-3.00# metastat
d10: Mirror
    Submirror 0: d11
      State: Okay
    Submirror 1: d12
      State: Resyncing
    Resync in progress: 67 % done
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 17409168 blocks (8.3 GB)

d11: Submirror of d10
    State: Okay
    Size: 17409168 blocks (8.3 GB)
    Stripe 0:
        Device     Start Block  Dbase        State Reloc Hot Spare
        c1t2d0s0          0     No            Okay   Yes


d12: Submirror of d10
    State: Resyncing
    Size: 17409168 blocks (8.3 GB)
    Stripe 0:
        Device     Start Block  Dbase        State Reloc Hot Spare
        c1t3d0s0          0     No            Okay   Yes


hsp001: 1 hot spare
        Device     Status      Length           Reloc
        c1t5d0s0   Available    17409168 blocks Yes

Device Relocation Information:
Device   Reloc  Device ID
c1t3d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP95339000019470FHT
c1t2d0   Yes    id1,sd@SSEAGATE_ST39173W_SUN9.0GLMD830490000793052T2
c1t5d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJR34002000019460G0S

Az így létrehozott hot spare-ek az összes tömbnek melegtartaléka lesz (amire értelmezhető, RAID0-nak nem). Törölni is lehet:

-bash-3.00# metahs -d hsp001 c1t5d0s0
hsp001: Hotspare is deleted
-bash-3.00# metahs -i
hsp001: is empty

Device Relocation Information:
Device   Reloc  Device ID

-bash-3.00# metahs -d hsp001
hsp001: Hotspare pool is cleared

-bash-3.00# metahs -i
metahs: mp3: no hotspare pools found

-bash-3.00# metastat
d10: Mirror
    Submirror 0: d11
      State: Okay
    Submirror 1: d12
      State: Okay
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 17409168 blocks (8.3 GB)

d11: Submirror of d10
    State: Okay
    Size: 17409168 blocks (8.3 GB)
    Stripe 0:
        Device     Start Block  Dbase        State Reloc Hot Spare
        c1t2d0s0          0     No            Okay   Yes


d12: Submirror of d10
    State: Okay
    Size: 17409168 blocks (8.3 GB)
    Stripe 0:
        Device     Start Block  Dbase        State Reloc Hot Spare
        c1t3d0s0          0     No            Okay   Yes


Device Relocation Information:
Device   Reloc  Device ID
c1t3d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP95339000019470FHT
c1t2d0   Yes    id1,sd@SSEAGATE_ST39173W_SUN9.0GLMD830490000793052T2

A mirror lebontása a felépítéshez hasonlóan bonyolult:

-bash-3.00# metadetach d10 d12
d10: submirror d12 is detached

-bash-3.00# metaclear d10
d10: Mirror is cleared

-bash-3.00# metaclear d12

d12: Concat/Stripe is cleared

-bash-3.00# metaclear d11
d11: Concat/Stripe is cleared

Mirror esetében ha a metadevice megszűnik, akkor az annak megfelelő slice-okat mount-olva lehet rajtuk látni az UFS-t és használni őket. Elegánsabb megoldás, ha egyből cseréljük a disket, majd a metareplace paranccsal helyreállítjuk a mirrort (RAID5 esetén csak ez működik). Igen, RAID5-őt is lehet csinálni:

-bash-3.00# metainit d1 -r c1t2d0s0 c1t3d0s0 c1t5d0s0
d1: RAID is setup
-bash-3.00# metastat
d1: RAID
    State: Initializing
    Initialization in progress:  0.7% done
    Interlace: 32 blocks
    Size: 34807563 blocks (16 GB)
Original device:
    Size: 34810432 blocks (16 GB)
        Device     Start Block  Dbase        State Reloc  Hot Spare
        c1t2d0s0       3921        No Initializing   Yes
        c1t3d0s0       3921        No Initializing   Yes
        c1t5d0s0       3921        No Initializing   Yes

Device Relocation Information:
Device   Reloc  Device ID
c1t2d0   Yes    id1,sd@SSEAGATE_ST39173W_SUN9.0GLMD830490000793052T2
c1t3d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJP95339000019470FHT
c1t5d0   Yes    id1,sd@SSEAGATE_ST39102LCSUN9.0GLJR34002000019460G0S

Valamiért ezt hívják RAID-nak a Solaris volume managerben. Ennél persze jóval többet tud, ajánlom a meta kezdetű parancsok manualjait, valamint a docs.sun.com-on lévő Solaris Admin Guide-okat a továbblépéshez.

[szerkesztés] 2.3 ZFS

A ZFS a Solaris legújabb, 128 bites fájlrendszere. Ennek következtében egy fájlrendszer maximális mérete 256 quadrillió zetabyte, ami elképzelhetetlenül nagyon sok. Másik fontos újítása, hogy egyszerű kezelni, mindent a zpool és a zfs parancsokkal kell megcsinálni (persze ezeknek nagyon sok lehetősége van). Ha a linux felől közelítjük meg a dolgot úgy kell elképzelni, mintha az LVM maga fájlrendszer is lenne, és nem kellene rajta fájlrendszereket létrehozni, és magában támogat minden fájlrendszerekkel kapcsolatos dolgot. Azzal, hogy az egészben egy absztrakciós szinttel kevesebb van, nyilvánvaló teljesítménynövekedés érhető el, ezen kívül rengeteg előnye van. Egy ilyen például, hogy a RAID-Z (ami egy RAID5, csak trükkös) ezzel oldja meg a RAID5 write hole problémát, ami ma még a RAID5 implementációk nagyobb részénél fennáll. Ha a RAID5 blokknak csak egy része került kiírásra (a többi része valamiért nem, pl. áramszünet volt), így a paritás nem lesz jó az adott blokkra egészen addig, amíg valami felül nem írja az adott blokkot. A ZFS ennek kiküszöbölésére változó méretű blokkokat használ, így minden kiírt blokk teljes blokk. Ez azért lehetséges, mert a ZFS kezeli a fájlrendszert és az eszközöket is. Erre a probélmára a RAID-Z az első csak szoftveren alapuló megoldás (hardveresen ezt pl. a RAID controlleren egy akku megoldja). Az alábbi diskek állnak rendelkezésre:

bash-3.00# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c0d0 <DEFAULT cyl 4092 alt 2 hd 128 sec 32>
          /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0
       1. c0d1 <VMware V-0000000000000000-0001-8.00GB>
          /pci@0,0/pci-ide@7,1/ide@0/cmdk@1,0
       2. c1d0 <DEFAULT cyl 4093 alt 2 hd 128 sec 32>
          /pci@0,0/pci-ide@7,1/ide@1/cmdk@0,0
       3. c1d1 <VMware V-0000000000000000-0001-8.00GB>
          /pci@0,0/pci-ide@7,1/ide@1/cmdk@1,0
Specify disk (enter its number): ^C

A ZFS 2 absztrakciós szintet használ, a poolt és a fájlrendszert. Poolokban kezelhetők a fizikai eszközök, majd ezeken a poolokon egy vagy több fájlrendszert lehet csinálni. Pl. egy RAID-Z pool létrehozása és törlése:

bash-3.00# zpool create ztank raidz c0d1 c1d0 c1d1

bash-3.00# zpool status ztank
  pool: ztank
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        ztank       ONLINE       0     0     0
          raidz     ONLINE       0     0     0
            c0d1    ONLINE       0     0     0
            c1d0    ONLINE       0     0     0
            c1d1    ONLINE       0     0     0

errors: No known data errors


bash-3.00# zpool destroy ztank

bash-3.00# zpool status
no pools available

Paraméterek nélkül a poolt RAID0-ként fogja használni:

bash-3.00# zpool create tank c0d1 c1d0 c1d1

bash-3.00# zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          c0d1      ONLINE       0     0     0
          c1d0      ONLINE       0     0     0
          c1d1      ONLINE       0     0     0

errors: No known data errors

RAID1-et a mirror kulcsszóval lehet csinálni:

 bash-3.00# zpool create mtank mirror c0d1 c1d0
bash-3.00# zpool status
  pool: mtank
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        mtank       ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c0d1    ONLINE       0     0     0
            c1d0    ONLINE       0     0     0

errors: No known data errors

A ZFS viszont ennél jóval többet tud. Pl. a már létrehozott poolok egyből mountolva lesznek:

bash-3.00# df -h|grep tank
mtank                  7.8G    24K   7.8G     1%    /mtank

Majd lehet rajta fájlrendszert is létrehozni:

bash-3.00# zfs create mtank/fs

bash-3.00# zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
mtank                  106K  7.81G  25.5K  /mtank
mtank/fs              24.5K  7.81G  24.5K  /mtank/fs

Az új fájlrendszer a hagyományos eszközökkel is kezelhető marad:

bash-3.00# df -h|grep tank
mtank                  7.8G    25K   7.8G     1%    /mtank
mtank/fs               7.8G    24K   7.8G     1%    /mtank/fs

A fájlrendszerekkel kapcsolatos összes adminisztratív teendőt a ZFS old meg, pár példa következik ezekre. Mountolás:

bash-3.00# zfs set mountpoint=/export/fs mtank/fs

bash-3.00# df -h|grep mtank
mtank                  7.8G    25K   7.8G     1%    /mtank
mtank/fs               7.8G    24K   7.8G     1%    /export/fs

Fájlrendszer szintű kvóta:

bash-3.00# zfs set quota=1G /export/fs

bash-3.00# zfs create mtank/masikfs

bash-3.00# zfs set quota=2G mtank/masikfs

bash-3.00# zfs set mountpoint=/export/masikfs mtank/masikfs

bash-3.00# df -h|grep tank
mtank                  7.8G    26K   7.8G     1%    /mtank
mtank/fs               1.0G    24K   1.0G     1%    /export/fs
mtank/masikfs          2.0G    24K   2.0G     1%    /export/masikfs

NFS megosztás:

bash-3.00# zfs set sharenfs=on mtank/fs

bash-3.00# share
-               /export/fs   rw   ""

A ZFS fájlrendszereket lehet exportálni/importálni, ezzel elősegítve a féjlrendszerek egyszerű migrációját:

bash-3.00# zpool export mtank

bash-3.00# zpool list
no pools available

bash-3.00# zpool import
  pool: mtank
    id: 1849483368148061147
 state: ONLINE
action: The pool can be imported using its name or numeric identifier.
config:

        mtank       ONLINE
          mirror    ONLINE
            c0d1    ONLINE
            c1d0    ONLINE

bash-3.00# zpool list
NAME                    SIZE    USED   AVAIL    CAP  HEALTH     ALTROOT
mtank                  7.94G    254K   7.94G     0%  ONLINE     -

bash-3.00# df -h|grep mtank
mtank                  7.8G    24K   7.8G     1%    /mtank
mtank/masikfs          2.0G    24K   2.0G     1%    /export/masikfs
mtank/fs               1.0G    24K   1.0G     1%    /export/fs

bash-3.00# share
-               /export/fs   rw   ""

Importálás után minden eredeti tulajdonság megmarad, mivel mindent a ZFS kezel (így pl. az NFS megosztás is). Az exportálás/importálás működik például snapshotokra is (igen, azt is lehet vele, de azt már az UFS is tudta). Ez egy nagyon rövid bevezető a ZFS-ről, ennél sokkal többet tud, aki tovább szeretne vele foglalkozni, annal ajánlom a zpool és a zfs man oldalait, valamint a docs.sun.com-on a ZFS dokumentációkat.

[szerkesztés] 3 Ajánlott irodalom

[szerkesztés] 4 Potenciális zh-kérdések

  • Miért jó logikai kötetkezelést használni? Mondjon alkalmazási példákat is!
  • Milyen fogalmakkal dolgozik a Linux LVM? Melyik micsoda (pl. LV, PV, VG)?
  • Mire jó a snapshot LV? Hogyan működik?
  • Hogyan lehet snapshot LV segítségével online mentést nem támogató adatbázisról mégis kvázi-online mentést csinálni?
  • Milyen elvárásaink legyenek azokkal a filerendszerekkel szemben, amelyeket logikai kötetekben akarunk használni?
  • Hogyan lehet snapshot LV-k segítségével "homokozót" csinálni, és milyen esetben jó ez?
  • Mekkora helyet kell biztosítanunk egy snapshot LV számára?
Személyes eszközök