RAID+LVM teljesítményanalízis

A lap 2009. december 18., 18:53-kori változata

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 Használt programok, parancsok

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

Az Iozone használata az md kötetek mérésére:

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

valamint

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

miket irtam be

4 Mérőrendszer ismertetése

HP DL380 G3 2,5GHz P4 proc, 2*256MiB DDR2-266 RAM, 2*36GiB 15k SCSI HDD + 4*36GiB 10k SCSI HDD Debian Lenny 2.6.26

Iozone 3.287

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 a /mnt könyvtárba felmountolva.

5 Tesztelés

grafikonok a kulonbozo felallasok eseten

miert ugy merem azt, ahogy

6 Értékelés

miert lassabb, miert gyorsabb, mitol gyorsabb, mitol lassabbl

stripe: 64 k vs 8 k stripe size

7 Források

http://www.iozone.org/
http://www.linuxvilag.hu/content/files/cikk/76/cikk_76_62_66.pdf