soft/hw raid sebesség különbség

Merevlemezek, vezérlők

Sziasztok,

Itt a fórumon sokszor olvasom, hogy nem nagyon érdemes HW raid vezérlőbe beruházni, mert a linux kernelnek is nagyon jó a soft raid-je.

Éppen most méricskélek egy új HP DL360g8-al (2x300G 10k, 512M cache). Ha jól látom, akkor az írási sebesség fele az olvasásinak (W: 130mbyte/s, R: 290mbyte/s) annak ellenére, hogy 75/25%-ra van állítva a cache. A fenti adatok IMHO kielégítőek, uas írni mindkettőre kell, olvasni is tud osztottan mindkettőről.
(mintha írásra Raid1, olvasásra Raid0 lenne)

Namost linux-md esetén én azt tapasztalom, hogy olvasni csak 1 lemezről tud egyszerre, nem pedig kettőről.
Ezen lehet valahogy változtatni?

Világosítsatok már fel kérlek, hogy is van ez :-)

  • 16318 megtekintés

( Fisher v | 2013. 07. 11., cs – 15:54 )

Hogy tesztelted? "Note that the read balancing done by the driver does not make the RAID1 performance profile be the same as for RAID0; a single stream of sequential input will not be accelerated (e.g. a single dd), but multiple sequential streams or a random workload will use more than one spindle. In theory, having an N-disk RAID1 will allow N sequential threads to read from all disks. "

hm. mondjuk bonnie++ -al:

HP Smartarray:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
Xen-01 29G 293 99 123916 34 82216 27 518 74 297610 39 1051 24
Latency 54591us 255ms 1292ms 1237ms 123ms 150ms
Version 1.96 ------Sequential Create------ --------Random Create--------
Xen-01 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 12678us 781us 1127us 6267us 20us 637us
1.96,1.96,Xen-01,1,1373542487,29G,,293,99,123916,34,82216,27,518,74,297610,39,1051,24,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,54591us,255ms,1292ms,1237ms,123ms,150ms,12678us,781us,1127us,6267us,20us,637us

Linux-MD

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
pbx 2G 214 99 114997 49 56776 27 1336 96 138687 28 418.5 18
Latency 39162us 392ms 219ms 13846us 19339us 155ms
Version 1.96 ------Sequential Create------ --------Random Create--------
pbx -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 21054 69 +++++ +++ 30036 75 26151 81 +++++ +++ 29499 74
Latency 6582us 1008us 1647us 436us 100us 1008us
1.96,1.96,pbx,1,1373543801,2G,,214,99,114997,49,56776,27,1336,96,138687,28,418.5,18,16,,,,,21054,69,+++++,+++,30036,75,26151,81,+++++,+++,29499,74,39162us,392ms,219ms,13846us,19339us,155ms,6582us,1008us,1647us,436us,100us,1008us

A manban én se :D 

ap:~# bonnie++
You must use the "-u" switch when running as root.
usage:
bonnie++ [-d scratch-dir] [-c concurrency] [-s size(MiB)[:chunk-size(b)]]
      [-n number-to-stat[:max-size[:min-size][:num-directories[:chunk-size]]]]
      [-m machine-name] [-r ram-size-in-MiB]
      [-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use]
      [-q] [-f] [-b] [-p processes | -y] [-z seed | -Z random-file]
      [-D]

Version: 1.97

Elvileg 1.95-től támogatott.

    HP SA

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 6 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
Xen-01 29G 287 99 122417 35 82896 27 518 69 302654 40 1059 23
Latency 59974us 1146ms 1956ms 1382ms 108ms 147ms
Version 1.96 ------Sequential Create------ --------Random Create--------
Xen-01 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 6726us 697us 703us 3793us 154us 684us
1.96,1.96,Xen-01,6,1373611329,29G,,287,99,122417,35,82896,27,518,69,302654,40,1059,23,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,59974us,1146ms,1956ms,1382ms,108ms,147ms,6726us,697us,703us,3793us,154us,684us

    Linux-MD:

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 6 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
pbx 2G 211 98 98814 39 57749 27 1354 98 111658 22 397.5 18
Latency 43191us 862ms 612ms 16826us 40934us 270ms
Version 1.96 ------Sequential Create------ --------Random Create--------
pbx -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 18621 62 +++++ +++ 29130 73 25799 79 +++++ +++ 29518 74
Latency 430us 1773us 1757us 436us 77us 921us
1.96,1.96,pbx,6,1373604036,2G,,211,98,98814,39,57749,27,1354,98,111658,22,397.5,18,16,,,,,18621,62,+++++,+++,29130,73,25799,79,+++++,+++,29518,74,43191us,862ms,612ms,16826us,40934us,270ms,430us,1773us,1757us,436us,77us,921us

Nalátod :)

Hát, lehet hogy ennyit tud a linux-md? Ha van dstatod akkor egy dstat -d -D md,mdláb1,mdláb2 hátha mutat valami használhatót.

Legkorábban szerdán, de tudok csinálni egy olyan tesztet, hogy ugyanazon a gépen, ugyanazzal a kernellel megcsinálom mindkét módon a mirrort és rátolom. Most már kezdek kíváncsi lenni.

HP SA 4x300G 15K, Raid10

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 6 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
onvoip-02 100G 281 99 306961 95 156967 69 679 94 496898 91 818.7 32
Latency 51841us 468ms 1095ms 269ms 102ms 136ms
Version 1.96 ------Sequential Create------ --------Random Create--------
onvoip-02 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 4011us 735us 715us 8368us 289us 897us
1.96,1.96,onvoip-02,6,1376825055,100G,,281,99,306961,95,156967,69,679,94,496898,91,818.7,32,16,,,,,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,51841us,468ms,1095ms,269ms,102ms,136ms,4011us,735us,715us,8368us,289us,897us

A DL360g8 szerverbe egy eSATA kártyára külső vinyóházat (inXtron Hydra Super-S LCM) kötöttem, 2db 2T vinyóval, RAID1-ben.

Az arhívum kedvéért bemásolom az eredményt:

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 6 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
Xen-01 32G 767 98 125680 30 75932 13 3443 95 221083 13 178.4 3
Latency 20758us 1247ms 1607ms 16777us 170ms 42088ms
Version 1.96 ------Sequential Create------ --------Random Create--------
Xen-01 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12880 24 +++++ +++ 28631 34 +++++ +++ +++++ +++ +++++ +++
Latency 9167us 972us 1486us 9199us 10us 583us
1.96,1.96,Xen-01,6,1375956694,32G,,767,98,125680,30,75932,13,3443,95,221083,13,178.4,3,16,,,,,12880,24,+++++,+++,28631,34,+++++,+++,+++++,+++,+++++,+++,20758us,1247ms,1607ms,16777us,170ms,42088ms,9167us,972us,1486us,9199us,10us,583us

dd-vel mérve ~165mbyte/s van mindkét irányba

( gabrielakos v | 2013. 07. 11., cs – 16:20 )

Én inkább azt mondanám, hogy a linux md driver elég korrekt sebességet tud, viszont százszor rugalmasabb mint a legtöbb hardware-es raid kontroller. És persze sokkal olcsóbb.

--
Gábriel Ákos
http://i-logic.hu

Egy "PERC H200 Adapter" csere után az egyel újabb vezérlő megtalálta és használatba vette a raid tömböt. Sajnos a CentOS kernele nem támogatta az újabb vezérlőt így nem tudott elindulni. Nem állhatott sokáig a rendszer ezért vissza kellett tenni a régi vezérlőt de sajnos az már nem találta a raid tömböt. A raid tömb elkészítése esetén teljes adatvesztés lett volna, ezért egy merevlemezről futott a rendszer amig nem sikerült egy pont ugyanolyan vezérlőt szerezni mint a régebbi. Akkor újra el kellett készíteni a raid tömböt majd a mentésből vissza kellett tölteni az adatokat.

--
maszili

Én részemről azért szavaznék rá, mert nincs olyan gond vele, hogy a hw raid vezérlő az 500G alatti vinyóval simán adja a raidset-et, viszont ha belógatok egy 2 Tibis vinyót akkor azt mondja, hogy én ezt nem látom.

Fájt a szívem amikor dobni kellett a süti gyári vezérlőt, de örültem, hogy vinyók kerültek a szerverbe, azt nem szerették volna, ha még benyögöm, hogy akkor kéne még egyszer ennyiért egy új vezérlő is.

Ellenpélda, a hw raid-re összerakás után "rá se kellett nézni", az sw raid azért igényelt alkalmankénti karbantartást.

szerk.: nyilván nem mai csibe a hw-raid vez.

én egy rocketraid vezérlőt dobattam ki a kukába (mondjuk olyan is volt), mert a vinyócserénél nem kultiválta a sata3-as vinyókat (a sata2-est se nagyon). ez bónusz 80eFt kiadás, de megérte, rá se kell nézni.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

pl. a legutóbbi. Elinudul a szinkronizálás automatikusan, egy adott fájlnál (mindig ugyanott) a vinyo kerneles IO hozzáférés hibát dob, és természetesen a szinkron megáll.
Emiatt amíg ez a hibát ki nem javítottam, egy vinyóból állt csak a raid-em.

Ezen egy vinyó állapotban az újraindítás nem ment zökkenőmentesen természetesen, minden egyes alkalommal nem ment tovább a boot-olás amíg rá nem bólintottam, hogy a hibás raid-et automatikusan újra összerakhassa.

Ami jogos, hogy ezt egyszer kellett csak gatyába ráznom, azóta rendben van.

( andrej_ v | 2013. 07. 11., cs – 16:29 )

Két diszken nem lesznek csodák, főleg nem RAID1-el. A md-t is ezen teszteled? Mert annak nem túl ideális a hwraid.

A cache-nél 25% olvasás és 75% írásra állítottad?

szó nincs arról, h csodát várnék.
a lent bemásolt eredmény első esetben (mint azt írtam ) HP Smart array (hw raid) a második esetben linux-md

(ok, első esetben 2x300G SAS 10k, a második esetben WD SATA 500G Blue)

mint azt irtam, igen. olvasás / írás 25/75% (szerk: bocs, most látom, h fent fordítva írtam, javítom)

( mauzi v | 2013. 07. 11., cs – 17:40 )

- Softraid esetében sosem lesz BBWC/FBWC-d, ellenben áramszüneted, kernel panic-od, és egyéb szabálytalan leállásod lehet.
- Hardveres RAID esetében nem kell közelharcot vívnod a BIOS-szal, és a boot managerrel, ha éppen a boot tömbből rohad ki komponens.
- ...

- Egy szétesett md-raid boot tömbről én hamarabb fogok bootolni, mint egy szétesett HW RAID tömbről, de javítsatok ki, ha tévedek. Ha rendesen konfiguráltam a rendszert, akkor a grub nekem gond nélkül bootolt úgy, hogy a boot kötet egyik tagja feldobta a talpát.

- Hány csúnya RAID vezérlő firmware hibát láttunk már eddig? És ott nem az van, hogy letöltesz egy frissebb kernelt (vagy akár magadnak megpatcheled), hanem vagy van rá fix a gyártótól, vagy pedig majd egyszer lesz (esetleg), addig spirituális módon lehet javítani = sűrű ima, hogy nálad nem jön elő

- Nyilván md-raidnél is volt már adatvesztéssel járó bug, de ott legalább nincs vendor lock-in.

-A topicban kicsit off, de ma már nem csak a HW és SW RAID között lehet kizárólag válogatni, hanem ott a ZFS és (1-2 éven belül) a Btrfs is.

( freeoli v | 2013. 07. 12., p – 09:40 )

A HW raid esetén az indikátor led és a hotswap a legfontosabb, a második legfontosabb a sebesség és adatbiztonság áramszünet esetén.
Nem minden OS-en lehet minden vezérlőt és a lemezeket távolról monitorozni.

Az SW raidban még sosem csalódtam, remekül túléli az áramszüneteket, a tömböt, lemezeket, smartot menet közben is lehet ellenőrizni és a sebesség is jó.

Több mint 10 éve használok linux sw raid-et (raid1 raid5 raid10) 20+ product szerveren, de sohasem volt vele gondom. HW raidről sajnos nem mondhatom el ugyanezt. Ha ugyan azokat a diszkeket használom nincs lényeges sebesség különbség közöttük. Ahol HW raid kártyát használok, ott akkor is inkább JBOD-be rakom a diszkeket és a raidet kernelből oldom meg. Sokkal nyugottabb vagyok így. :-)

HW raid JBOD + ZFS?

BlackY
Szerk.: Amúgy (meg)értem, amit mondasz, de mindhárom megoldásnak vannak előnyei és hátrányai (pl.: tiszta HW raid és a vezérlőhalál, szoftver raid-ek és a növekedett CPU, de JBOD+ZFS-nél pl. egy diszk hibánál egy 30%-os telítettségű tömbön nem írja végig az új lemezt [és olvassa végig a többit], csak a használt 30%-ot, ami növeli az esélyt, hogy megúszod, hogy ezidő alatt kimenjen egy másik diszk is)

Egy üres gép, boni, cékettő: 

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             502.50     32656.00        38.50      65312         77
sdb             422.50     28144.00        40.50      56288         81
md0             978.00     60800.00        30.50     121600         61

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
      78148096 blocks [2/2] [UU]
# uname -r
2.6.26-2-amd64

Azt kérdezted hogy lehet több diskről egyszerre. Így.

Csak ezért nem fogom szétborítani ezt a mirrort. Szerdán tudok tesztelni.

Teszteltem screen+2 dd + iostat:

[code]Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 978.50 63614.00 57.00 127228 114
sdb 912.00 64838.00 56.00 129676 112
md0 31980.50 127872.00 48.50 255744 97[code]

A 60k az kb. amit a diskek egyedül (illetve 1db dd-vel) tudnak. 2xdd, 2x sebesség, most már csak az a kérdés hogy a boni miért lassabb, pl. a -c vel tényleg csinál-e új thread-et, gondolom igen, és lehet hogy a külön thread nem elég, külön process kell.

Esetleg lehet két bonit futtatni.

( andrej_ v | 2013. 07. 13., szo – 00:02 )

4x300GB RAID1+0 P410i 256MB BBWC, szintén 25/75-os r/w cache opcióval.

Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
hosztnev 64G 721 99 246794 32 124105 16 2650 80 380715 21 683.9 51
Latency 17143us 394ms 290ms 141ms 423ms 138ms
Version 1.96 ------Sequential Create------ --------Random Create--------
hosztnev -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12237 19 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 277us 763us 817us 316us 10us 674us
1.96,1.96,hosztnev,1,1373673005,64G,,721,99,246794,32,124105,16,2650,80,380715,21,683.9,51,16,,,,,12237,19,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,17143us,394ms,290ms,141ms,423ms,138ms,277us,763us,817us,316us,10us,674us

( dblaci | 2013. 07. 16., k – 20:26 )

" hogy olvasni csak 1 lemezről tud egyszerre, nem pedig kettőről"

valójában egy szál egy lemezről olvas, de kettő már kettőről, tehát tényleges terhelésnél (feltéve hogy nincs írás közben) dupla olvasási sebesség van. Sőt, mivel nem stripe, ezért a két lemez lehet máshol seekelve, így a párhuzamos több random olvasás esetén ez a felállás gyorsabb lehet, mint a raid0. Szerintem nincs gond a linux sw raiddel, de már minden érv elhangzott, amiért így gondolom.