RAID+LVM teljesítményanalízis

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

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

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/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

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.

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.

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 

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.

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/