Raid stripe size es az LVM extent size kozotti kapcsolat.

Merevlemezek, vezérlők

Sziasztok,

Eloszor is elnezest az ekezetek miatt..
Segitseget szeretnek kerni egy Backup szerver installalasakor beallitando Raid stripe size illetve LVM extent Size-rol.
Van egy Megaraid SAS 9271 -8i Raid Controller Kartyam hozza 36 db 2TB-os SATA merevlemezzel.
Meg nem dontottem el hogy Raid6-ot vagy Raid60 hasznaljak-e. Az adatfileok meretet tekintve vannak kisebb meretuek de vannak nagyobb meretuek is. Vegyes az eloszlas. LVM-et szeretnek hasznalni a tarterulet reszere ext4 filerendszerrel. A kerdesem az lenne hogy ki mit javasolna a Raid stripe Size illetve LVM extent size kivalasztasaban? Ez utobbit ha jol tudom akkor tudja az ember dinamikusan valtoztatni futo operacios rendszer kozben.
Koszonom a tanacsokat elore is.

  • 5375 megtekintés

( Elbandi v | 2013. 02. 27., sze – 11:01 )

ezt en is feltettem itt a hupon, es azt a valaszt kaptam, hogy nemszukseges szoros kapcsolat a ketto kozott: az extent size csak az lvm-nek kell, hogy tudja melyik resz hova tartozik. (fixme, de elvileg meg limit is van, extentek szama limitalt, ezert a size-ot ugy kell megvalasztani). szvsz persze nemart, ha pl ES oszthato a stripesize-al.

raidnel meg figyelni kell hany disket raksz bele, mert elszabott egy stripesize-ok johetnek ki, ami mindennel oszthato csak 2 hatvanyaval nem... :(

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ugy tudom a limit inkabb csak az LVM1-nel lenyeges. A kovetkezoket talaltam:

with LVM2, there's no limit on the maximum numbers of extents per PV/LV. The default extent size is 4MB, and there's no need to change this for most configurations, because there is no I/O performance penalty for smaller/bigger extent size.
So, for the moment I would assume that the same limits apply. According to the TLDP's LVM2 Howto the limits for LVs (logical volumes) in LVM2 are
- 2TB for 2.4 kernels,
- 16TB for 32-bit CPUs on 2.6 kernels,
- 8EB for 64-bit CPUs on 2.6 kernels

---
"Jede Loesung eines Problems ist ein neues Problem"

( kelement | 2013. 02. 27., sze – 13:18 )

Teljesitmenyt kellene merni hozza, de en siman szetbontanam akar 3db raid6 tombre is es azokat stripelnem.

( egeresz | 2013. 02. 27., sze – 14:09 )

nálam pont van egy 36 diszkes (2T egy diszk) gép, amiben 3 darab 12 diszkes raid6 -ot készítettem, amit aztán LVM stripe-vel fűztem össze. Az eredmény végül is raid60.

Mindenhogy szar a performanciája. Csomó kombinációt és kialakítást (chunksize, LVM extent size, offsetek mindféle) kipróbáltam. Nem számít: a raid6 ilyen méretekben már annyira vacak random írást tesz lehetővé, ami nagyban megfogja az egészet, semmi más nem számít. (2 szálon indított backup már random write-nek számít. A 12 diszkes raid6 nettó mérete 20TB, az általad említett kártyában lévő 1GiB cache annyira esélytelenül pici hozzá). Ellenben raid50 (7 darab 5 diszkes raid5, 1 spare) már elfogadhatóan muzsikál. Az 5 diszkes raid5 tömb még nem istenkáromlás, pláne enterspájz diszkeknél nem.

Csak az a baj, hogy - függetlenül attól hogy enterprise vagy sima bolti hdd-ről beszélünk - egy 2TB/7k hdd rebuildingje sok-sok órába telik, akár egy napig is mehet (terheléstől függően). Addig az a raid5 védtelen, és könnyen kihullhat egy újabb drive abból a tömbből. Szóval én mindenképp a raid6-ot javasolnám. Ha pedig mindenképp fontos a random write sebesség, akkor arra ott a raid10...

( secretx v | 2013. 02. 27., sze – 14:27 )

Érdemes egyébként futni pár kört linux IO oldalon is, ha tuningolni akarsz szerintem, nekem pl a tuned elég durva pluszt hozott mindenféle tesztben, és éles felhasználásban is, egy sima raid 1-nél ext4-el.
Régóta akarok csinálni egy hosszabb lélegzetvételű írást, mert jó pár órám elment IO tuning-al nemrég, de még nem jutottam oda :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

nekem pl a tuned

jegyezzük meg, hogy

[...]
Tuned: Daemon for monitoring and adaptive tuning of system devices.
In Fedora, Red Hat Enterprise Linux, and their derivates install tuned package
(optionally tuned-utils, tuned-utils-systemtap, and tuned-profiles-compat):
[...]

power-management@lists.fedoraproject.org
You can also join #fedora-power IRC channel on Freenode.
http://git.fedorahosted.org/cgit/tuned.git
Copyright (C) 2008-2012 Red Hat, Inc.

én pl nem tudtam ilyen cuccról, debian powwa.

( asm v | 2013. 02. 27., sze – 14:52 )

Én úgy gondolom, hogy érdemes arra törekedni, hogy az LVM extent mérete egyenlő vagy többszöröse legyen a raid "hasznos diszkszám"*stripe mérettel.
Például ha van egy 10 diszkes raid6-od, ahol 128kB a stripe méret, akkor leszámítva a két paritást azaz 8*128kB = 1MB a full stride read/write. Ilyen esetben az LVM default 4MB extent size az jó.
Ebből az következik, hogy törekedni kell arra, hogy a raid6-nak a hasznos diszkszáma 2 hatványa legyen, azaz raid6 lehetőleg 4+2=6, 8+2=10 vagy 16+2=18 diszkből épüljön fel. De fixme, ha vki másképp tudná.

az lvm nem extentben ír, hanem csak extentben allokál. (mivel lvm layer csak admin szempontból van, io szempontjából dm layer van, ami blockszinten dolgozik). Általában nem okoz problémát az LVM extent igazítása. Igaz ez szimpla LV-re is (ahol lehetőleg fragmentáció nélkül jönnek az extentek)
Az LVM stripe ( lvcreate --stripesize ) az extent tört része lehet (kettőhatvány csak, beleértve az egész extentet) itt a --stripesize lényegében a raid chunksize fogalmának felel meg. Ennek sincs szekvenciális írás teljesíménybefolyásoló szerepe. Random íráson kicsit dobhat, ha ez a raid stripe (chunk*N) -el egybeesik, de inkább lényeges, hogy ez essen egybe egy raid chunkkal. (vagy osztója, vagy többszöröse). De ez sem a small random write esetén növeli a taljesíményt, hanem a raid chunk méretet elérő write műveleteknél segít.
Méréseim szerint inkább mindegy, mindenhogy rossz a random write teljesítmény, akár small block, akár 4k, akár raid-chunk, akár lvm extent. A 2T diszkekből épített 10-30 diszkes nagy, buta raid6 tömbök mindenhogy vacakok.

Az összes diszket magábafoglaló raid60 esetében már olyan nagy lesz a full stride méret (36*strip size), hogy ahhoz már nem érdemes bármit is igazítani, mert úgyis töredéke lesz az átlagos IO műveletek mérete.
Az egész elmélet mögött az áll, hogy lehetőleg egy írás művelet végrehajtásakor a raidben szereplő összes diszk csak egyszer seekeljen és egyben írja le az adatot. Ha mindez még szekvenciálisan is történik, akkor elérhetjük a legmagasabb data rate-et (MB/s).

Stripe helyett szerintem chunkot akartál írni.

Szerintem is fontos, hogy a PE méret egész számú többszöröse legyen a stripe méretnek, de más miatt. A fájlrendszert is lehet eszerint optimalizálni és ehhez nem árt ha az LV-je stripe határon kezdődik. A pvcreate dataalignment és dataalignmentoffset opciói segíthetnek. Ha az LV stripe határra van illesztve, akkor mkfs.ext4-nek mehet stride és a stripe_width-tel a chunk és a stripe méret _blokk_-ban. Mountkor is használható a stripe opció szintén blokkban.