RAID+LVM teljesítményanalízis

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (→‎Striping)
a (szöveg-átdolgozás)
1. sor: 1. sor:
−
== A Feladat ==
 +
Írta: Nagy Balázs, 2009. december.
   
−
=== RAID 0, RAID 1 vs. LVM stripe ill. LVM mirror ===
 +
A feladat:
   
−
Szoftveres RAID 0, és RAID 1 teljesítményének összehasonlítása LVM-ben megoldott stripinggal, illetve mirroringgal.
 +
# szoftveres RAID 0 és RAID 1 teljesítményének összehasonlítása LVM-ben megoldott stripinggal, illetve mirroringgal. Nagy eltéréseket nem várunk: ugyanazon a vason, hasonló elven megvalósított köteteket nézünk.
−
Itt nagy eltéréseket nem várunk: ugyanazon a vason, mindkét esetben hasonló logikai absztrakcióval megvalósított köteteket nézünk.
 +
# Annak kimérése, mekkora sebességveszteséget okoz egy vagy több LVM-snapshot létezése az eredeti köteten.
   
−
=== LVM snapshotok hatása a sebességre: ===
 +
== Elméleti megfontolások a snapshotokkal kapcsolatban ==
   
  +
A snapshot működésének a lényege az, hogy ha egy a snapshot készítésének pillanata óta érintetlen területet felülírunk az eredeti köteten, akkor az ott található adatok először átmásolódnak a snapshotra; emellett a snapshot metaadataiban jelezni kell, hogy ez az adatterület a snapshotból és nem az eredeti kötetről olvasandó. Ezeknek az írásoknak be kell fejeződni azelőtt, hogy az eredeti köteten módosíthatnánk az adatokat. A merevlemezek és vezérlők a pufferelt írásokat megpróbálhatják optimalizálni (a gyorsabb működés érdekében a keletkezésüktől eltérő sorrendben végrehajtani őket); emiatt nem lenne biztos, hogy a valóságban is előbb történik meg a snapshot írása, és csak utána az eredeti köteté. Ha a sorrend rossz, és pont a két írás között megy el a tápfeszültség, inkonzisztenssé válik a snapshot. (Ugyanez a probléma egyébként a naplózó fájlrendszereket is érinti.)
   
  +
Erre a problémára két megoldás van: drágább hardver támogathat ún. ''write barrier''-eket, amelyeknek a segítségével az operációs rendszer jelezheti, ha szigorúan meg kell tartani bizonyos írási műveletek sorrendjét. A tipikus PC-s hardver általában nem rendelkezik ezzel a képességgel, így az egyetlen lehetőség az, hogy a snapshotokat szinkron módon írjuk, írási cache nélkül. Arra számítunk, hogy ez jelentős, akár nagyságrendi sebességcsökkenést is okozhat.
   
−
'''Snapshotkészítés után az írás gyorsasága:'''
 +
Ha egy egyszer már felülírt területre írunk, azt feltételezzük, hogy nem lesz jelentős eltérés az eredeti (snapshot nélküli) írási sebességtől, hiszen a változtatások már elmentődtek, a snapshot-kötet őrzi a felülírt adat múltbéli konzisztens állapotát, sok köze most nincs hozzánk.
   
−
A snapshot működéséből adódóan kernelszinten csak akkor íródnak ki a változtatások az eredeti kötetről a snapshot volume-ra, amikor azokat először felülírjuk. Ilyenkor csak azt vesszük észre, hogy egyszerűen lassabban megy a felülírás az eredeti kötetünkön.
 +
=== Mennyivel lassíthat jobban két snapshot, mint egy? ===
   
  +
Kétszer akkora lassulást nem várunk, de valamennyit mindenképpen. Ha két, ugyanazon konzisztens állapotot tároló snapshot kötetünk van, akkor az eredeti köteten történő változtatáskor egyszer kell beolvasni az adatunkat, és azt két helyre kiírni. Ezt nyilván lassabban megy, mint egyetlen snapshot esetén, de talán nem kétszer annyira. Nehéz előre megjósolni az eredményeket, hiszen a szinkron írások és a többlet-fejmozgások száma megduplázódik; ezekhez képest az olvasás időigényét elenyészőnek várjuk. Ugyanakkor nem szükségszerű, hogy a snapshotok ugyanazokon a fizikai diszkeken legyenek; ha a két snapshot különböző diszkeken van, az írásuk történhet egyszerre.
   
−
'''Snapshotkészítés után egy terület újraírási sebessége:'''
 +
== A mérőrendszer ismertetése ==
   
−
Ha egy egyszer már felülírt területre írunk, azt feltételezzük, hogy nem lesz jelentős eltérés az eredeti (snapshot nélküli) írási sebességtől, hiszen a változtatások már elmentődtek, a snapshot volume őrzi a felülírt adat múltbéli konzisztens állapotát, sok köze most nincs hozzánk.
  
   
  +
HP DL380 G3:
  +
* 2,5GHz-es P4 processzor
  +
* 2x256MiB DDR2-266 RAM
  +
* 2x36GiB 15k rpm SCSI HDD
  +
* 4x36GiB 10k rpm SCSI HDD
  +
* Debian Lenny 2.6.26
  +
* IOzone 3.287
  +
* LVM2
   
−
'''Két snapshot kétszer olyan lassú, mint egy?'''
 +
A RAM-ot azért választottam minél kisebbre (ennél is kisebb modulok nem voltak kéznél), hogy a cache-nek a mért sebességekre gyakorolt hatását csökkentsem. A RAM méreténél kisebb, és már becachelt fájloknál így is jól látszik, hogy több 100MB/s-os írási-olvasási sebességeket mérünk, amire a HDD-nk nyilván nem képes.
   
−
Kétszer akkora lassulást nem várunk, de valamennyit mindenképpen. Ha két, ugyanazon konzisztens állapotot tároló snapshot kötetünk van, akkor az eredeti köteten történő változtatáskor egyszer kell beolvasni az adatunkat, és azt két helyre kiírni. Ezt nyilván lassabb lesz, mint egy snapshot volume esetén, de nem kétszer annyira.
 +
A 2 db 15k-s diszken volt RAID1-ben az operációs rendszer, míg a szoftveres RAID megvalósításnál a maradék 2-2 10k-s diszk volt RAID 0-ban, ill. 1-ben; az LVM-es megoldásnál ez utóbbi négy diszk 1 db volume groupot alkotott.
   
−
Az LVM-ből kifolyólag nem feltétlenül egy diszken találhatóak a snapshotok, így ha több helyre kell ugyanazt írni, akkor ez esetben sem kétszeres lesz a lassulás.
 +
LVM-nél a snapshotkészítés utáni sebességcsökkenés mértékét úgy vizsgáltam, hogy egy 1.2 GiB-os tesztfájlba írtam 1 GiB adatot (így a cache hatása kevésbé volt jelentős).
   
  +
Minden méréshez ext3-as fájlrendszert használtam.
   
  +
A tényleges méréseket az IOzone-nal végeztem. A program igen összetett; sok funkciója van, amelyek közül számomra különösen hasznosnak bizonyult, hogy tud xls formátumú kimenetet generálni, amiből utána egyszerűen lehet szép színes grafikonokat rajzoltatni.
   
−
== Mire is jó ez? ==
 +
Az IOzone hátránya, hogy a paraméterezése nem túl intuitív; aki használni szeretné, készüljön fel arra, hogy sokat kell majd olvasnia.
   
−
Megnézzük, hogy a gyakorlatban mennyi előny - hátrány származik LVM, illetve md alatt megvalósított RAID 0-1 megvalósításokból, illetve a snapshotok mennyiségének milyen a hatása az I/O sebességekre.
 +
== Mérések ==
   
  +
Az alábbiakban bemutatom az általam elvégzett konkrét méréseket.
   
−
+
=== Az IOzone használata az md-kötetek mérésére ===
−
== Mérőrendszer ismertetése ==
  
−  
−  
−
HP DL380 G3 2,5GHz P4 proc, 2*256MiB DDR2-266 RAM, 2*36GiB 15k rpm SCSI HDD + 4*36GiB 10k rpm SCSI HDD
  
−
Debian Lenny 2.6.26
  
−  
−
Iozone 3.287
  
−  
−
LVM2
  
−  
−
A RAM-ot azért választottam minél kisebbre (kisebb modulok nem voltak kéznél), hogy a másolás közbeni cachelt írás-olvasás ne adjon zavaró eredményeket. A RAM méreténél kisebb, és már becachelt fájloknál így is élénken látszódik a több 100MB/s-os írási-olvasási sebesség, amire nyilván nem képes a HDD-nk.
  
−  
−
A 2 db 15k-s diszken volt RAID1-ben az operációs rendszerünk, míg a szoftveres RAID megvalósításnál a maradék 2-2 10k-s diszk volt RAID 0-ban, ill. 1-ben, az LVM-es megoldásnál ez utóbbi négy diszk 1 db volume groupban figyelt.
  
−  
−
LVM-nél a snapshotkészítés utáni első írás - újraírásvizsgálatnál egy 1.2 GiB-os tesztfájlba lett írva 1 GiB.
  
−
(a cache effekt elkerülése miatt)
  
−  
−
Ext3 filerendszert használtam mind az md köteteken, mind az LVM-en, majd ezek lettek aktuálisan a /mnt könyvtárba felmountolva.
  
−  
−
A diszkek sebességének mérésére az Iozone-t használtam. Ez meglehetősen szélesen skálázható, rakás funkciója van, valamint képes .xls kimenetet generálni, amiből utána relatíve egyszerűen tudunk szép színes grafikonokat rajzoltatni.
  
−
Az Iozone képes egy megadott helyre rakni a tesztfájlját, ezen méri gyakorlatilag az eredményeket.
  
−
Hátránya, hogy nem használható intuitívan, a számunkra ideális funkciók megtalálása időigényes manual-turkászást eredményez.
  
−  
−
== Tesztelés ==
  
−  
−
A tesztelés során az alább említett módon hoztam létre a főbb dolgokat. A táblázatkezelést, illetve telepítést, RAID, LVM konfigurálásának lépéseit már leírták máshol, ezt nem részletezném.
  
−  
−  
−
=== Az Iozone használata az md kötetek mérésére ===
  
 
 
 
Az első, md-vel megvalósított RAID 0 felállás esetén:
 
Az első, md-vel megvalósított RAID 0 felállás esetén:
   
−
iozone -a -U /mnt/striperaid/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/striperaid/testfile -R -b ./"`date +%Y%m%d`"-stripe-raid-ext3.xls
+
<pre>
  +
iozone -a -U /mnt/striperaid/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/striperaid/testfile -R -b ./"`date +%Y%m%d`"-stripe-raid-ext3.xls
  +
</pre>
   
 
RAID 1-nél:
  
RAID 1-nél:
   
−
iozone -a -U /mnt/raidmirror/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/raidmirror/testfile -R -b ./"`date +%Y%m%d`"-mirror-raid-ext3.xls
 +
<pre>
  +
iozone -a -U /mnt/raidmirror/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/raidmirror/testfile -R -b ./"`date +%Y%m%d`"-mirror-raid-ext3.xls
  +
</pre>
   
−
=== A paraméterek az LVM kötet mérésekor ===
 +
=== Az LVM-kötetek sebességének mérése ===
   
−
Itt egy volume groupban lakott mindenki, az LVM beépített kapcsolóit használtam a logical volume-ok létrehozásához:
 +
Mind a négy 10k rpm-es diszket egyetlen kötetcsoportba szerveztem, majd az alábbi módon hoztam létre tükrözött ill. csíkozott logikai kötetet:
   
−
lvcreate -L 32gb -n lvmmirror -m 1 --corelog vgteszt /dev/cciss/c0d2p1 /dev/cciss/c0d3p1
 +
<pre>
−
lvcreate --stripes 2 --stripesize 64 --name stripelvm --size 70gb vgstripe
 +
lvcreate -L 32gb -n lvmmirror -m 1 --corelog vgteszt /dev/cciss/c0d2p1 /dev/cciss/c0d3p1
  +
lvcreate --stripes 2 --stripesize 64 --name stripelvm --size 70gb vgstripe
  +
</pre>
   
−
Itt azért adtam a stripenak 64kiB-os csíkméretet, mert az md is annyit csinált defaultban, így pontosabb az összehasonlítás.
 +
Itt azért használtam 64kiB-os csíkméretet, mert az md alapértelmezése ez volt; így pontosabb az összehasonlítás (bár az egyes megvalósítások saját alapértelmezéseivel végzett összehasonlítás eredményei is relevánsak lennének).
   
−
Az Iozone-nal való mérés:
 +
Az IOzone-t a következőképpen paramétereztem:
   
−
iozone -a -U /mnt/stripelvm/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/stripelvm/testfile -R -b ./"`date +%Y%m%d`"-stripe-lvm-ext3.xls
+
<pre>
  +
iozone -a -U /mnt/lvmmirror/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/lvmmirror/testfile -R -b ./"`date +%Y%m%d`"-mirror-lvm-ext3.xls
  +
</pre>
   
−
és
+
ill.
   
−
iozone -a -U /mnt/lvmmirror/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/lvmmirror/testfile -R -b ./"`date +%Y%m%d`"-mirror-lvm-ext3.xls
 +
<pre>
  +
iozone -a -U /mnt/stripelvm/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/stripelvm/testfile -R -b ./"`date +%Y%m%d`"-stripe-lvm-ext3.xls
  +
</pre>
   
−
=== A kapcsolók jelentése ===
 +
Az IOzone kapcsolóinak jelentése:
   
−
-U : újramountolás minden teszt elején
 +
* -U : újramountolás minden teszt elején
−
-a : automatic mode
 +
* -a : automatic mode
−
-+u : CPU értékek rögzítése
 +
* -+u : CPU értékek rögzítése
−
-n : minimális tesztfileméret
 +
* -n : minimális tesztfileméret
−
-g : maximális tesztfileméret
 +
* -g : maximális tesztfileméret
−
-q : maximum rekordméret
 +
* -q : maximális rekordméret
−
-i : a tesztelési módok kiválasztása
 +
* -i : a tesztelési módok kiválasztása
−
-f : a tesztfájl neve, helye
 +
* -f : a tesztfájl neve, helye
−
-R : MS Excel alapú kimenet készítése
 +
* -R : MS Excel alapú kimenet készítése
−
-b : kimeneti fájl helye
 +
* -b : kimeneti fájl helye
   
 
Alapvetően csak az egyszerű írás - olvasás (ill. újraírás, újraolvasás) műveletek sebességét mértem, a többi módot is kihasználva észveszejtően sok mindent lehet mérni. (-i 0 -i 1 kapcsolók)
  
Alapvetően csak az egyszerű írás - olvasás (ill. újraírás, újraolvasás) műveletek sebességét mértem, a többi módot is kihasználva észveszejtően sok mindent lehet mérni. (-i 0 -i 1 kapcsolók)
   
−
A rekordméretet 128kiB-ban maximalizáltam, próbáltam nem szélsőségesen nagyra állítani.
 +
A rekordméretet 128kiB-ban maximalizáltam; próbáltam nem szélsőségesen nagyra állítani.
  +
  +
A tesztfájl mérete 4KiB-tól 1GiB-ig változott. Az 1 GiB már elegendő ahhoz, hogy a cache hatása elenyésző legyen; ennél nagyobb teszfájl használata csak feleslegesen megnövelte volna a mérés időtartamát anélkül, hogy a pontosság jelentősen nőtt volna.
   
−
A tesztfájl mérete 4KiB-tól 1GiB-ig változott. Az 1 Gib már elégséges (igazából 512MiB is elég lett volna) a RAM cache kiiktatására, nagyobbra állítása esetén csak feleslegesen nőttek volna meg a tesztidők, a végeredmény nem változna.
 +
A -U kapcsolóval is pufferelés hatásait próbáltam kiszűrni: ez minden egyes mérés elvégzése előtt umount - mount műveletet hajt végre, ami pufferürítést eredményez.
   
−
A -U kapcsolóval is a RAM bufferét próbáltam meg kiegyensúlyozni, ez minden egyes teszt elvégzésekor umount - mount műveletet hajt végre, ami által ürül az írási / olvasási buffer.
 +
=== Egy darab snapshot hatásának mérése ===
   
−
=== Egy darab snapshot - write, rewrite ===
 +
Itt először létrehoztam egy 5GiB-os logikai kötetet. Ezt kb. 3/4-ig feltölöttem szeméttel, majd létrehoztam egy 1.2GiB-os tesztfájlt. Ezt az IOzone a mérés végén sajnos mindig letörli, úgyhogy mindig újra létre kell hozni.
   
−
Itt először létrehoztam egy 5GiB-os logical volume-ot. Ezt kb. 3/4-ig feltölöttem szeméttel, majd létrehoztam egy 1.2GiB-os testfilet. Ez utóbbit sajnos mindig meg kellett teremteni, mert az Iozone ezt törli is a teszt végén.
 +
Hogy legyen viszonyítási alapunk, elvégeztem egy snapshot nélküli referenciamérést a következő paranccsal:
   
−
Lett egy sima snapshot nélküli diszk írásteszt is, viszonyítási alapnak.
 +
<pre>
  +
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_write-rewrite-snapless-ext3.xls
  +
</pre>
   
−
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_write-rewrite-snapless-ext3.xls
 +
Majd létrehoztam egy snapshotot, és úgy is megmértem az írás sebességét:
   
−
Majd létrehoztam egy snapshotot, és indítottam is a tesztet.
 +
<pre>
  +
lvcreate -L 5g -n lv1 vgteszt
  +
lvcreate -L 5g -s -n snap1 /dev/vgteszt/lv1
  +
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_rewriteNO1-snap-ext3.xls
  +
</pre>
   
−
lvcreate -L 5g -n lv1 vgteszt
 +
(vgteszt volt a volume group neve; lv1 a létrehozott logical volume, amit a snap1 nevű kötetre snapshotoltunk; 4k a natív blokkméret, ezért nem szórakoztam többfélével.)
−
lvcreate -L 5g -s -n snap1 /dev/vgteszt/lv1
  
−
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_rewriteNO1-snap-ext3.xls
 
   
−
(vgteszt volt a volume group neve, és lv1 a létrehozott logical volume, amit a snap1 nevű kötetre snapshotoltunk, valamint 4k a natív blokkméret, ezért nem szórakoztam többfélével)
 +
Az IOzone írástesztjében (-i 0 kapcsoló) először ír, majd újra felülírja az adott területet, szóval pont a célunknak megfelelően viselkedik ez a kapcsoló.
   
−
Az Iozone írás tesztjében (-i 0 kapcsoló) először ír, majd újra felülírja az adott területet, szóval pont a célunknak megfelelően viselkedik ez a kapcsoló.
 +
=== Két snapshot hatásának mérése ===
   
−
=== Két darab snapshot - write, rewrite ===
 +
Ismét az előbb bemutatott 5GiB-os lv-t használjuk, ugyanazokkal a paraméterekkel, csak éppen két snapshot készül róla:
   
−
Ismét az előbb bemutatott 5GiB-os lv-t használjuk, ugyanazokkal a paraméterekkel. Csak éppen két snapshot készül róla.
  
   
−
lvcreate -L 5g -s -n snap1 /dev/vgteszt/lv1
 +
<pre>
−
lvcreate -L 5g -s -n snap2 /dev/vgteszt/lv1
 +
lvcreate -L 5g -s -n snap1 /dev/vgteszt/lv1
−
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_write-rewrite-2snap-ext3.xls
+
lvcreate -L 5g -s -n snap2 /dev/vgteszt/lv1
  +
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_write-rewrite-2snap-ext3.xls
  +
</pre>
   
 
grafikonok a kulonbozo felallasok eseten
  
grafikonok a kulonbozo felallasok eseten

A lap 2009. december 30., 14:46-kori változata

Írta: Nagy Balázs, 2009. december.

A feladat:

  1. szoftveres RAID 0 és RAID 1 teljesítményének összehasonlítása LVM-ben megoldott stripinggal, illetve mirroringgal. Nagy eltéréseket nem várunk: ugyanazon a vason, hasonló elven megvalósított köteteket nézünk.
  2. Annak kimérése, mekkora sebességveszteséget okoz egy vagy több LVM-snapshot létezése az eredeti köteten.

Tartalomjegyzék

1 Elméleti megfontolások a snapshotokkal kapcsolatban

A snapshot működésének a lényege az, hogy ha egy a snapshot készítésének pillanata óta érintetlen területet felülírunk az eredeti köteten, akkor az ott található adatok először átmásolódnak a snapshotra; emellett a snapshot metaadataiban jelezni kell, hogy ez az adatterület a snapshotból és nem az eredeti kötetről olvasandó. Ezeknek az írásoknak be kell fejeződni azelőtt, hogy az eredeti köteten módosíthatnánk az adatokat. A merevlemezek és vezérlők a pufferelt írásokat megpróbálhatják optimalizálni (a gyorsabb működés érdekében a keletkezésüktől eltérő sorrendben végrehajtani őket); emiatt nem lenne biztos, hogy a valóságban is előbb történik meg a snapshot írása, és csak utána az eredeti köteté. Ha a sorrend rossz, és pont a két írás között megy el a tápfeszültség, inkonzisztenssé válik a snapshot. (Ugyanez a probléma egyébként a naplózó fájlrendszereket is érinti.)

Erre a problémára két megoldás van: drágább hardver támogathat ún. write barrier-eket, amelyeknek a segítségével az operációs rendszer jelezheti, ha szigorúan meg kell tartani bizonyos írási műveletek sorrendjét. A tipikus PC-s hardver általában nem rendelkezik ezzel a képességgel, így az egyetlen lehetőség az, hogy a snapshotokat szinkron módon írjuk, írási cache nélkül. Arra számítunk, hogy ez jelentős, akár nagyságrendi sebességcsökkenést is okozhat.

Ha egy egyszer már felülírt területre írunk, azt feltételezzük, hogy nem lesz jelentős eltérés az eredeti (snapshot nélküli) írási sebességtől, hiszen a változtatások már elmentődtek, a snapshot-kötet őrzi a felülírt adat múltbéli konzisztens állapotát, sok köze most nincs hozzánk.

1.1 Mennyivel lassíthat jobban két snapshot, mint egy?

Kétszer akkora lassulást nem várunk, de valamennyit mindenképpen. Ha két, ugyanazon konzisztens állapotot tároló snapshot kötetünk van, akkor az eredeti köteten történő változtatáskor egyszer kell beolvasni az adatunkat, és azt két helyre kiírni. Ezt nyilván lassabban megy, mint egyetlen snapshot esetén, de talán nem kétszer annyira. Nehéz előre megjósolni az eredményeket, hiszen a szinkron írások és a többlet-fejmozgások száma megduplázódik; ezekhez képest az olvasás időigényét elenyészőnek várjuk. Ugyanakkor nem szükségszerű, hogy a snapshotok ugyanazokon a fizikai diszkeken legyenek; ha a két snapshot különböző diszkeken van, az írásuk történhet egyszerre.

2 A mérőrendszer ismertetése

HP DL380 G3:

  • 2,5GHz-es P4 processzor
  • 2x256MiB DDR2-266 RAM
  • 2x36GiB 15k rpm SCSI HDD
  • 4x36GiB 10k rpm SCSI HDD
  • Debian Lenny 2.6.26
  • IOzone 3.287
  • LVM2

A RAM-ot azért választottam minél kisebbre (ennél is kisebb modulok nem voltak kéznél), hogy a cache-nek a mért sebességekre gyakorolt hatását csökkentsem. A RAM méreténél kisebb, és már becachelt fájloknál így is jól látszik, hogy több 100MB/s-os írási-olvasási sebességeket mérünk, amire a HDD-nk nyilván nem képes.

A 2 db 15k-s diszken volt RAID1-ben az operációs rendszer, míg a szoftveres RAID megvalósításnál a maradék 2-2 10k-s diszk volt RAID 0-ban, ill. 1-ben; az LVM-es megoldásnál ez utóbbi négy diszk 1 db volume groupot alkotott.

LVM-nél a snapshotkészítés utáni sebességcsökkenés mértékét úgy vizsgáltam, hogy egy 1.2 GiB-os tesztfájlba írtam 1 GiB adatot (így a cache hatása kevésbé volt jelentős).

Minden méréshez ext3-as fájlrendszert használtam.

A tényleges méréseket az IOzone-nal végeztem. A program igen összetett; sok funkciója van, amelyek közül számomra különösen hasznosnak bizonyult, hogy tud xls formátumú kimenetet generálni, amiből utána egyszerűen lehet szép színes grafikonokat rajzoltatni.

Az IOzone hátránya, hogy a paraméterezése nem túl intuitív; aki használni szeretné, készüljön fel arra, hogy sokat kell majd olvasnia.

3 Mérések

Az alábbiakban bemutatom az általam elvégzett konkrét méréseket.

3.1 Az IOzone használata az md-kötetek mérésére

Az első, md-vel megvalósított RAID 0 felállás esetén: 

iozone -a -U /mnt/striperaid/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/striperaid/testfile -R -b ./"`date +%Y%m%d`"-stripe-raid-ext3.xls

RAID 1-nél: 

iozone -a -U /mnt/raidmirror/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/raidmirror/testfile -R -b ./"`date +%Y%m%d`"-mirror-raid-ext3.xls

3.2 Az LVM-kötetek sebességének mérése

Mind a négy 10k rpm-es diszket egyetlen kötetcsoportba szerveztem, majd az alábbi módon hoztam létre tükrözött ill. csíkozott logikai kötetet: 

lvcreate -L 32gb -n lvmmirror -m 1 --corelog vgteszt /dev/cciss/c0d2p1 /dev/cciss/c0d3p1
lvcreate --stripes 2 --stripesize 64 --name stripelvm --size 70gb vgstripe

Itt azért használtam 64kiB-os csíkméretet, mert az md alapértelmezése ez volt; így pontosabb az összehasonlítás (bár az egyes megvalósítások saját alapértelmezéseivel végzett összehasonlítás eredményei is relevánsak lennének).

Az IOzone-t a következőképpen paramétereztem: 

iozone -a -U /mnt/lvmmirror/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/lvmmirror/testfile -R -b ./"`date +%Y%m%d`"-mirror-lvm-ext3.xls

ill. 

iozone -a -U /mnt/stripelvm/ -+u -g 1g -q 128k -i 0 -i 1 -f /mnt/stripelvm/testfile -R -b ./"`date +%Y%m%d`"-stripe-lvm-ext3.xls

Az IOzone kapcsolóinak jelentése:

  • -U  : újramountolás minden teszt elején
  • -a  : automatic mode
  • -+u : CPU értékek rögzítése
  • -n  : minimális tesztfileméret
  • -g  : maximális tesztfileméret
  • -q  : maximális rekordméret
  • -i  : a tesztelési módok kiválasztása
  • -f  : a tesztfájl neve, helye
  • -R  : MS Excel alapú kimenet készítése
  • -b  : kimeneti fájl helye

Alapvetően csak az egyszerű írás - olvasás (ill. újraírás, újraolvasás) műveletek sebességét mértem, a többi módot is kihasználva észveszejtően sok mindent lehet mérni. (-i 0 -i 1 kapcsolók)

A rekordméretet 128kiB-ban maximalizáltam; próbáltam nem szélsőségesen nagyra állítani.

A tesztfájl mérete 4KiB-tól 1GiB-ig változott. Az 1 GiB már elegendő ahhoz, hogy a cache hatása elenyésző legyen; ennél nagyobb teszfájl használata csak feleslegesen megnövelte volna a mérés időtartamát anélkül, hogy a pontosság jelentősen nőtt volna.

A -U kapcsolóval is pufferelés hatásait próbáltam kiszűrni: ez minden egyes mérés elvégzése előtt umount - mount műveletet hajt végre, ami pufferürítést eredményez.

3.3 Egy darab snapshot hatásának mérése

Itt először létrehoztam egy 5GiB-os logikai kötetet. Ezt kb. 3/4-ig feltölöttem szeméttel, majd létrehoztam egy 1.2GiB-os tesztfájlt. Ezt az IOzone a mérés végén sajnos mindig letörli, úgyhogy mindig újra létre kell hozni.

Hogy legyen viszonyítási alapunk, elvégeztem egy snapshot nélküli referenciamérést a következő paranccsal: 

iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_write-rewrite-snapless-ext3.xls

Majd létrehoztam egy snapshotot, és úgy is megmértem az írás sebességét: 

lvcreate  -L 5g -n lv1 vgteszt
lvcreate  -L 5g -s -n snap1 /dev/vgteszt/lv1
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_rewriteNO1-snap-ext3.xls

(vgteszt volt a volume group neve; lv1 a létrehozott logical volume, amit a snap1 nevű kötetre snapshotoltunk; 4k a natív blokkméret, ezért nem szórakoztam többfélével.)

Az IOzone írástesztjében (-i 0 kapcsoló) először ír, majd újra felülírja az adott területet, szóval pont a célunknak megfelelően viselkedik ez a kapcsoló.

3.4 Két snapshot hatásának mérése

Ismét az előbb bemutatott 5GiB-os lv-t használjuk, ugyanazokkal a paraméterekkel, csak éppen két snapshot készül róla: 


lvcreate  -L 5g -s -n snap1 /dev/vgteszt/lv1
lvcreate  -L 5g -s -n snap2 /dev/vgteszt/lv1
iozone -a -+u -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_write-rewrite-2snap-ext3.xls

grafikonok a kulonbozo felallasok eseten

miert ugy merem azt, ahogy

4 Eredmények

Különbségi grafikonokat választottam, szerintem ez szemléletesebben mutatja be, hogy melyik javára dőlnek el a sebességek. Minden esetben az md-s RAID-ben mért értékekből vontam ki az LVM alatt mérteket.

4.1 Mirroring

Azaz RAID 1 vs. LVM mirroring

Muszáj voltam ennyi ábrán bemutatni, mert egy grafikonon nem lett volna eléggé reprezentatív a mért eredmény. Így is csak egy pár (4, 16, 64kiB-os) rekordméretet ragadtam ki.

4.1.1 Írás esetén

Fájl:iras mirr 4k.jpg


Fájl:iras mirr 16k.jpg


Fájl:iras mirr 64k.jpg


Látható, hogy csak a kisebb, cachelt fájlok esetén jönnek elő érdemleges különbségek, 512-1024MiB-os fájloknál nagyjából megegyezik az írási sebesség különböző rekordméretek esetén is.

Az LVM vezet a nagyobb fájlok esetén a sebességben.

4.1.2 Olvasásnál

Fájl:olvasas mirr 4k.jpg


Fájl:olvasas mirr 16k.jpg


Fájl:olvasas mirr 64k.jpg


Itt is ugyanez mondható el, mint írásnál: kisebb fájlok cachelődnek, kicsit szélsőségesek a sebességek, nagyobb fájloknál előkerül a rendszer valódi áteresztőképessége, és az md egyértelműen jobban teljesít.

4.2 Striping

Azaz RAID 0 vs LVM striping


4.2.1 Írás

Fájl:iras str 4k.jpg


Fájl:iras str 16k.jpg


Fájl:iras str 64k.jpg


Itt minden rekordméretnél jól látható a szoft RAID sebességelőnye kisebb fájlméreteknél, míg a nagyobbaknál már szinte nulla az eltérés.

4.2.2 Olvasás

Fájl:olvasas str 4k.jpg


Fájl:olvasas str 16k.jpg


Fájl:olvasas str 64k.jpg


Olvasásban az LVM-es megvalósítás viszi az érmet. Érdekes megfigyelni, ahogy a rekordméret változásával vannak pontok, ahol az md eléggé közel kerül.

4.3 Snapshotok melletti teljesítmény

2vs1vs0snap.JPG


Itt látható amit megjósoltunk, a snapshotok mennyisége nem áll lineáris kapcsolatban az írási sebességek változásával. Újraírás esetén elhanyagolhatóak a különbségek, megközelítőleg egyforma sebességgel ír egy snapshot mentes kötet is, mint egy egy (de akár két) snapshottal rendelkező.

A 2 snapshotnál tapasztalt nagyobb újraírási sebesség mérési hiba eredménye lehet, ennek nem szabadna gyorsabbnak lennie.

5 Források 

http://www.iozone.org/
http://www.linuxvilag.hu/content/files/cikk/76/cikk_76_62_66.pdf
http://hu.openoffice.org/
A lap eredeti címe: „http://unixlinux.tmit.bme.hu/index.php?title=RAID%2BLVM_teljes%C3%ADtm%C3%A9nyanal%C3%ADzis&oldid=3904”
Személyes eszközök