RAID+LVM teljesítményanalízis
Balu (vitalap | szerkesztései) (→Az Iozone használata az md kötetek mérésére) |
Balu (vitalap | szerkesztései) (→Az Iozone használata az md kötetek mérésére) |
||
| 70. sor: | 70. sor: | ||
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 |
+ | 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 |
=== A paraméterek az LVM kötet mérésekor === |
=== A paraméterek az LVM kötet mérésekor === |
||
A lap 2009. december 19., 19:10-kori változata
Tartalomjegyzék |
1 A Feladat
1.1 RAID 0, RAID 1 vs. LVM stripe ill. LVM mirror
Szoftveres RAID 0, és RAID 1 teljesítményének összehasonlítása LVM-ben megoldott stripinggal, illetve mirroringgal. 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.
1.2 LVM snapshotok hatása a sebességre:
Snapshotkészítés után az írás gyorsasága:
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.
Snapshotkészítés után egy terület újraírási sebessége:
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.
Két snapshot kétszer olyan lassú, 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 lassabb lesz, mint egy snapshot volume esetén, de nem kétszer annyira.
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.
2 Mire is jó ez?
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.
3 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.
4 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.
4.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
4.2 A paraméterek az LVM kötet mérésekor
Itt egy volume groupban lakott mindenki, az LVM beépített kapcsolóit használtam a logical volume-ok létrehozásához:
lvcreate -L 32gb -n mirrorlv -m 1 --corelog vgteszt /dev/cciss/c0d2p1 /dev/cciss/c0d3p1 lvcreate --stripes 2 --stripesize 64 --name stripelv --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.
Az Iozone-nal való mérés:
iozone -a -+u -q 128k -g 1g -i 0 -i 1 -f /mnt/stripe/testfile -R -b ./"`date +%Y%m%d`"-LVMstripe-ext3.xls
és
iozone -a -+u -q 128k -g 1g -i 0 -i 1 -f /mnt/mirror/testfile -R -b ./"`date +%Y%m%d`"-LVMmirror-ext3.xls
4.3 A kapcsolók jelentése:
-a : automatic mode -+u : CPU értékek rögzítése -n : minimális tesztfileméret -g : maximális tesztfileméret -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)
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 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.
4.4 Egy darab snapshot - write, rewrite
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 lmeg 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.
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 indítottam is a tesztet.
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, é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á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ó.
4.5 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
5 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.
5.1 Mirroring
Azaz RAID 1 vs. LVM mirroring
5.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.
5.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 megint fej-fej mellett teljesít az LVM és a RAID.
5.2 Striping
Azaz RAID 0 vs LVM striping
5.2.1 Írás
Itt látható az LVM sebességelőnye a jelölt rekord, és fájlméreteknél egyaránt. A túl kicsi fájlokat, illetve rekordméreteket nem tüntettem fel, még az előzőeknél is aránytalanabbak voltak a sebességkülönbségek. (valószínűleg a cachelési megvalósítások miatt)
5.2.2 Olvasás
Olvasásban az md-s megvalósítás viszi az érmet. Érdekes megfigyelni, ahogy a rekordméret emelkedésével az LVM-hez kerül a stafétabot. A kicsi fájlokat, illetve rekordméreteket itt sem tüntettem fel.
5.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.
6 Források
http://www.iozone.org/ http://www.linuxvilag.hu/content/files/cikk/76/cikk_76_62_66.pdf
