RAID+LVM teljesítményanalízis
Írta: Nagy Balázs, 2009. december.
A feladat:
- 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.
- 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 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/c0d4p1 /dev/cciss/c0d5p1
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 --chunk=64 --level=stripe --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
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
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
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
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
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
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
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/