RAID+LVM teljesítményanalízis

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (→‎Mirroring)
(→‎Eredmények)
 
(2 szerkesztő 20 közbeeső változata nincs mutatva)
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.
  +
Az IOzone paramétereinél a rekordméretet 128 kiB-ban maximalizáltam, próbáltam nem szélsőségesen nagyra választani. Ez esetben túlságosan sokáig tartott volna egy-egy mérés.
   
−
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.
 +
Ha abszolúte a pontosságra törekszünk, érdemes mindenképpen teleírnunk a RAID, vagy LVM kötetünket, mert csak így biztosítható, hogy ugyanazokat a területeket írjuk teli / olvassuk végig. Ha itt sem szeretnénk sokáig várni, míg megvannak az eredmények, célszerű nem több GiB-osra állítani a kötetméretet. (ez persze a RAM-unk mennyiségétől is erősen függ, szóval alaposan át kell gondolni)
   
  +
== Mérések ==
   
  +
Az alábbiakban bemutatom az általam elvégzett konkrét méréseket.
   
−
== Mérőrendszer ismertetése ==
 +
=== Az md kötetek, és az IOzone használata ===
  +
  +
A RAID0 kötet létrehozása:
  +
<pre>
  +
mdadm --create /dev/md2 --chunk=64 --level=stripe --raid-devices=2 /dev/cciss/c0d2p1 /dev/cciss/c0d3p1
  +
</pre>
   
  +
Az IOzone paraméterei:
  +
<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>
   
−
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
 +
Valamint RAID 1-nél ugyanezek:
   
−
LVM2
 +
<pre>
  +
mdadm --create /dev/md2 --level=mirror --chunk=64 --raid-devices=2 /dev/cciss/c0d4p1 /dev/cciss/c0d5p1
  +
</pre>
   
−
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.
 +
illetve:
   
−
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.
 +
<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>
   
−
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.
 +
=== Az LVM-kötetek sebességének mérése ===
−
(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.
 +
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:
   
−
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.
 +
<pre>
−
Az Iozone képes egy megadott helyre rakni a tesztfájlját, ezen méri gyakorlatilag az eredményeket.
 +
lvcreate -L 32gb -n lvmmirror -m 1 --corelog vgteszt /dev/cciss/c0d2p1 /dev/cciss/c0d3p1
−
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.
 +
lvcreate --stripes 2 --stripesize 64 --name stripelvm --size 70gb vgstripe
  +
</pre>
   
−
== Tesztelé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).
   
−
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-t a következőképpen paramétereztem:
   
  +
<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>
   
−
=== Az Iozone használata az md kötetek mérésére ===
 +
ill.
−
 
−
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/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>
   
−
RAID 1-nél:
 +
Az IOzone kapcsolóinak jelentése:
   
−
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
 +
* -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
  +
* -w : a tesztfájl nem törlődik tesztenként
   
−
=== A paraméterek az LVM kötet mérésekor ===
 +
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)
   
−
Itt egy volume groupban lakott mindenki, az LVM beépített kapcsolóit használtam a logical volume-ok létrehozásához:
 +
A rekordméretet 128kiB-ban maximalizáltam; próbáltam nem szélsőségesen nagyra állítani.
   
−
lvcreate -L 32gb -n lvmmirror -m 1 --corelog vgteszt /dev/cciss/c0d2p1 /dev/cciss/c0d3p1
 +
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.
−
lvcreate --stripes 2 --stripesize 64 --name stripelvm --size 70gb vgstripe
  
   
−
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.
 +
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.
   
−
Az Iozone-nal való mérés:
 +
=== Egy darab snapshot hatásának mérése ===
   
−
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
+
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.
   
−
és
+
Hogy legyen viszonyítási alapunk, elvégeztem egy snapshot nélküli referenciamérést a következő paranccsal:
   
−
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 -w -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>
   
−
=== A kapcsolók jelentése ===
 +
Majd létrehoztam egy snapshotot, és úgy is megmértem az írás sebességét:
   
−
-U : újramountolás minden teszt elején
 +
<pre>
−
-a : automatic mode
 +
lvcreate -L 5g -n lv1 vgteszt
−
-+u : CPU értékek rögzítése
 +
lvcreate -L 5g -s -n snap1 /dev/vgteszt/lv1
−
-n : minimális tesztfileméret
 +
iozone -a -+u -w -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_rewriteNO1-snap-ext3.xls
−
-g : maximális tesztfileméret
 +
</pre>
−
-q : maximum 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)
 +
(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.)
   
−
A rekordméretet 128kiB-ban maximalizáltam, próbáltam nem szélsőségesen nagyra állítani.
 +
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ó.
   
−
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 -w kapcsoló azért lényeges, mert ekkor a tesztfájlunk megmarad az első teszt végére, így ezzel garantálható hogy szektorszinten ugyanott fog elhelyezkedni a merevlemezen.
   
−
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.
 +
=== Két snapshot hatásának mérése ===
   
−
=== Egy 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:
   
−
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.
  
   
−
Lett egy sima snapshot nélküli diszk írásteszt is, viszonyítási alapnak.
 +
<pre>
  +
lvcreate -L 5g -s -n snap1 /dev/vgteszt/lv1
  +
lvcreate -L 5g -s -n snap2 /dev/vgteszt/lv1
  +
iozone -a -+u -w -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>
   
−
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
 +
== Eredmények ==
   
−
Majd létrehoztam egy snapshotot, és indítottam is a tesztet.
 +
Relatív grafikonokat választottam, szerintem ez szemléletesebben mutatja be, hogy melyik javára dőlnek el a sebességek.
   
−
lvcreate -L 5g -n lv1 vgteszt
 +
Minden esetben az md-s RAID-ben mért értékeket használtam viszonyítási alapnak.
−
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)
 +
Ez magyarul azt jelenti, hogy ez előbbit vettem 100%-nak, és az LVM ehhez való %-os viszonya van ábrázolva.
−  
−
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 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.
  
−  
−
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
  
−  
−
== 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.
  
   
 
=== Mirroring ===
  
=== Mirroring ===
127. sor: 143. sor:
 
==== Írás esetén ====
  
==== Írás esetén ====
   
−
<p style="text-align:center">[[Fájl:iras_mirr_4k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_iras_mirr_4k.jpg|800px]]</p>
   
   
−
<p style="text-align:center">[[Fájl:iras_mirr_16k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_iras_mirr_16k.jpg|800px]]</p>
   
   
−
<p style="text-align:center">[[Fájl:iras_mirr_64k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_iras_mirr_64k.jpg|800px]]</p>
   
   
142. sor: 158. sor:
 
==== Olvasásnál ====
  
==== Olvasásnál ====
   
−
<p style="text-align:center">[[Fájl:olvasas_mirr_4k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_olvasas_mirr_4k.jpg|800px]]</p>
   
   
−
<p style="text-align:center">[[Fájl:olvasas_mirr_16k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_olvasas_mirr_16k.jpg|800px]]</p>
   
   
−
<p style="text-align:center">[[Fájl:olvasas_mirr_64k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_olvasas_mirr_64k.jpg|800px]]</p>
   
   
160. sor: 176. sor:
 
==== Írás ====
  
==== Írás ====
   
−
<p style="text-align:center">[[Fájl:iras_str_4k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_iras_str_4k.jpg|800px]]</p>
   
−
<p style="text-align:center">[[Fájl:iras_str_16k.jpg]]</p>
  
   
−
<p style="text-align:center">[[Fájl:iras_str_64k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_iras_str_16k.jpg|800px]]</p>
  +
  +
  +
<p style="text-align:center">[[Fájl:%_iras_str_64k.jpg|800px]]</p>
   
   
171. sor: 186. sor:
 
==== Olvasás ====
  
==== Olvasás ====
   
−
<p style="text-align:center">[[Fájl:olvasas_str_4k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_olvasas_str_4k.jpg|800px]]</p>
  +
  +
  +
<p style="text-align:center">[[Fájl:%_olvasas_str_16k.jpg|800px]]</p>
  +
   
−
<p style="text-align:center">[[Fájl:olvasas_str_16k.jpg]]</p>
 +
<p style="text-align:center">[[Fájl:%_olvasas_str_64k.jpg|800px]]</p>
   
−
<p style="text-align:center">[[Fájl:olvasas_str_64k.jpg]]</p>
  
   
 
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.
  
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.

A lap jelenlegi, 2010. január 15., 21:55-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

[szerkesztés] 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.

[szerkesztés] 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.

[szerkesztés] 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. Az IOzone paramétereinél a rekordméretet 128 kiB-ban maximalizáltam, próbáltam nem szélsőségesen nagyra választani. Ez esetben túlságosan sokáig tartott volna egy-egy mérés.

Ha abszolúte a pontosságra törekszünk, érdemes mindenképpen teleírnunk a RAID, vagy LVM kötetünket, mert csak így biztosítható, hogy ugyanazokat a területeket írjuk teli / olvassuk végig. Ha itt sem szeretnénk sokáig várni, míg megvannak az eredmények, célszerű nem több GiB-osra állítani a kötetméretet. (ez persze a RAM-unk mennyiségétől is erősen függ, szóval alaposan át kell gondolni)

[szerkesztés] 3 Mérések

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

[szerkesztés] 3.1 Az md kötetek, és az IOzone használata

A RAID0 kötet létrehozása: 

mdadm --create /dev/md2 --chunk=64 --level=stripe --raid-devices=2 /dev/cciss/c0d2p1 /dev/cciss/c0d3p1

Az IOzone paraméterei: 

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


Valamint RAID 1-nél ugyanezek: 

mdadm --create /dev/md2 --level=mirror --chunk=64 --raid-devices=2 /dev/cciss/c0d4p1 /dev/cciss/c0d5p1

illetve: 

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

[szerkesztés] 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
  • -w  : a tesztfájl nem törlődik tesztenként

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.

[szerkesztés] 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.

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

iozone -a -+u -w -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 -w -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ó.

A -w kapcsoló azért lényeges, mert ekkor a tesztfájlunk megmarad az első teszt végére, így ezzel garantálható hogy szektorszinten ugyanott fog elhelyezkedni a merevlemezen.

[szerkesztés] 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 -w -r 4k -n 1g -g 1g -i 0 -f /mnt/lv1/testfile -R -b ./"`date +%Y%m%d`"-LVM_write-rewrite-2snap-ext3.xls

[szerkesztés] 4 Eredmények

Relatív 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ékeket használtam viszonyítási alapnak.

Ez magyarul azt jelenti, hogy ez előbbit vettem 100%-nak, és az LVM ehhez való %-os viszonya van ábrázolva.


[szerkesztés] 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.

[szerkesztés] 4.1.1 Írás esetén

% iras mirr 4k.jpg


% iras mirr 16k.jpg


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

[szerkesztés] 4.1.2 Olvasásnál

% olvasas mirr 4k.jpg


% olvasas mirr 16k.jpg


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

[szerkesztés] 4.2 Striping

Azaz RAID 0 vs LVM striping


[szerkesztés] 4.2.1 Írás

% iras str 4k.jpg


% iras str 16k.jpg


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

[szerkesztés] 4.2.2 Olvasás

% olvasas str 4k.jpg


% olvasas str 16k.jpg


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

[szerkesztés] 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.

[szerkesztés] 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=4014”
Személyes eszközök