Linux, RAID-1: Software vs Hardware

[c-nan]

Heeft een HW RAID controller aanzienlijk beter performance/voordelen t.o.v. SW RAID wanneer er gebruik gemaakt wordt van 2 SATA schijven in RAID-1?

Vroeger zou je zeggen dat een HW-RAID beter zou 'performen' ivm CPU gebruik, echter recente machines hebben QuadCore, waardoor je dat niet eens meer zult merken, denk ik?

Hoe denken jullie erover?

Omgeving:
- Linux
- 2x SATA300 7200RPM
- Gebruikte data ~100GB
- MySQL Server

[redfoxert]

Polat06 schreef op zondag 22 januari 2012 @ 20:38:
Heeft een HW RAID controller aanzienlijk beter performance/voordelen t.o.v. SW RAID wanneer er gebruik gemaakt wordt van 2 SATA schijven in RAID-1?

Nee. RAID-1 is mirror en nauwelijks CPU belastend. Zelfs RAID-5, 6 of 50/60 is nauwelijks nog van invloed op de rest van de performance van het systeem.

[ Voor 14% gewijzigd door redfoxert op 22-01-2012 20:41 ]

[c-nan]

redfoxert schreef op zondag 22 januari 2012 @ 20:41:
[...]


Nee. RAID-1 is mirror en nauwelijks CPU belastend. Zelfs RAID-5, 6 of 50/60 is nauwelijks nog van invloed op de rest van de performance van het systeem.

Dat dacht ik dus ook. Waarom zou ik dus een HW RAID controller gebruiken?

Enige punt wat ik mij kan bedenken is de cache wat een controller heeft, echter is dat echt merkbaar? Vooral bij een MySQL server zal dat niet merkbaar zijn denk ik (omdat: veel read, weinig/minder write, en sowieso gaat het om kleine data).

[redfoxert]

Met een 100GB dataset is een SSD vele male sneller dan wat je nu bedacht hebt. Als het om bedrijfsdata gaat kan je met een fatsoenlijke backup ook snel een defecte SSD herstellen. Of je zorgt gewoon voor 2 SSD's die je mirror'd binnen Linux.

Als performance echt een issue is : SSD is the way to go.

Grote databases bij grote bedrijven worden vaak middels hardware van disk naar SSD gecached. Met name de zogenaamde "hotspots" in een database, dus veel gelezen records worden dan vanaf de SSD gelezen. De rest van de database staat op de normale disks. Bij EMC noemen ze het Fast Cache in de Clariions bijvoorbeeld.

[ Voor 34% gewijzigd door redfoxert op 22-01-2012 20:52 ]

[alex3305]

Het rebuilden werkt geloof ik vaak beter bij hardware controllers dan bij software controllers. Maar daar ben ik ook niet 100% zeker van.

Daarnaast is een SSD zeker een optie, maar dan moet de TS wel gaan kijken naar een SLC SSD in plaats van een consumenten SSD en deze zijn wel een stuk duurder dan MLC SSD's. Daarnaast hebben business SSD's stabielere firmware dan die consumenten rommel .

[c-nan]

alex3305 schreef op zondag 22 januari 2012 @ 20:52:
Het rebuilden werkt geloof ik vaak beter bij hardware controllers dan bij software controllers. Maar daar ben ik ook niet 100% zeker van.

Rebuilden maak je als het goed is, eens per 2-3 jaar mee. Dat het dan misschien iets langer duurt, maakt niet uit.

Daarnaast is een SSD zeker een optie, maar dan moet de TS wel gaan kijken naar een SLC SSD in plaats van een consumenten SSD en deze zijn wel een stuk duurder dan MLC SSD's. Daarnaast hebben business SSD's stabielere firmware dan die consumenten rommel .

SSD is sneller, begrijp ik maar daar is de prijs ook naar.

Oh en over firmware twijfel ik een beetje
Er is pas een firmware uitgebracht:

Correct a condition where an incorrect response to a SMART counter will cause the m4 drive to become unresponsive after 5184 hours of Power-on time. The drive will recover after a power cycle, however, this failure will repeat once per hour after reaching this point. The condition will allow the end user to successfully update firmware, and poses no risk to user or system data stored on the drive.

[redfoxert]

alex3305 schreef op zondag 22 januari 2012 @ 20:52:
Het rebuilden werkt geloof ik vaak beter bij hardware controllers dan bij software controllers. Maar daar ben ik ook niet 100% zeker van.

Daarnaast is een SSD zeker een optie, maar dan moet de TS wel gaan kijken naar een SLC SSD in plaats van een consumenten SSD en deze zijn wel een stuk duurder dan MLC SSD's. Daarnaast hebben business SSD's stabielere firmware dan die consumenten rommel .

Waarom zou een MLC SSD minder betrouwbaar zijn dan een SLC SSD? Het is niet alsof de SSD in zijn volledigheid elke dag meerdere malen beschreven wordt. Bij veel reads zou het zelfs niet eens uitmaken. Firmware en stabiliteit ... dan zou je ook gewoon een Intel kunnen nemen. En backups zijn er om dataverlies te voorkomen. Een SLC SSD die crashed is net zo goed een SPOF en het zal niet de eerste keer zijn dat zulke SSD's het loodje leggen

[redfoxert]

Polat06 schreef op zondag 22 januari 2012 @ 20:55:
Oh en over firmware twijfel ik een beetje
Er is pas een firmware uitgebracht:

Toevallig een Crucial M4 issue, dat hebben ze niet allemaal

[styx1]

redfoxert schreef op zondag 22 januari 2012 @ 20:51:
Met een 100GB dataset is een SSD vele male sneller dan wat je nu bedacht hebt. Als het om bedrijfsdata gaat kan je met een fatsoenlijke backup ook snel een defecte SSD herstellen. Of je zorgt gewoon voor 2 SSD's die je mirror'd binnen Linux.

Als performance echt een issue is : SSD is the way to go.

Grote databases bij grote bedrijven worden vaak middels hardware van disk naar SSD gecached. Met name de zogenaamde "hotspots" in een database, dus veel gelezen records worden dan vanaf de SSD gelezen. De rest van de database staat op de normale disks. Bij EMC noemen ze het Fast Cache in de Clariions bijvoorbeeld.

De vraag gaat over SATA schijven en niet over SSD schijven. En natuurlijk is een enkele sata/sas/ssd sneller dan sata/sas/ssd in RAID-1, maar dat spreekt voor zich.

Ik ben zelf ook wel benieuwd wat het verschil in voor en nadelen zijn van SW en HW RAID-1.

[analog_]

voordelen is flexibiliteit, elk storage block device kan je gebruiken om je disk te vervangen. In principe zelfs een CDRW/floppy of USB stick als hij maar groot genoeg is. Hetzelfde geldt voor je controllers dan. Cache kan je oplossen met ZFS (heeft ingebouwde ram caching en mogelijkheid om synchrone writes op te vangen met een SSD) of met linux dmv. het filesystem agnostisch bcache project (wat zover ik weet niet af is).

[redfoxert]

HW > Gebonden aan de hardware controller als er iets mis gaat, vaak zelfs merk en type gebonden.
SW > Mogelijk miniem lagere performance. Die hardware controller is echt geen rekenwonder waar je met een dikke quadcore cpu van verliest.


En RAID is sowieso geen backup, had ik dat al gezegd?

[c-nan]

redfoxert schreef op zondag 22 januari 2012 @ 21:07:
En RAID is sowieso geen backup, had ik dat al gezegd?

Volgens mij niet, maar het zorgt er wel voor dat je door kan draaien en de tijd hebt om de schijf te vervangen
Zonder RAID-1 ben je direct offline.

[styx1]

redfoxert schreef op zondag 22 januari 2012 @ 21:07:
HW > Gebonden aan de hardware controller als er iets mis gaat, vaak zelfs merk en type gebonden.
SW > Mogelijk miniem lagere performance. Die hardware controller is echt geen rekenwonder waar je met een dikke quadcore cpu van verliest.


En RAID is sowieso geen backup, had ik dat al gezegd?

Voordeel van een HW is dat je caching hebt met batterij - bij stroomuitval heb je als het goed is geen corrupte data.

Backup is het niet - het is zorgen voor continuteit - zeg ik dat goed?

[c-nan]

analog_ schreef op zondag 22 januari 2012 @ 21:05:
voordelen is flexibiliteit, elk storage block device kan je gebruiken om je disk te vervangen. In principe zelfs een CDRW/floppy of USB stick als hij maar groot genoeg is. Hetzelfde geldt voor je controllers dan. Cache kan je oplossen met ZFS (heeft ingebouwde ram caching en mogelijkheid om synchrone writes op te vangen met een SSD) of met linux dmv. het filesystem agnostisch bcache project (wat zover ik weet niet af is).

Nog te weinig ervaring met ZFS (werkt het, zo ja, hoe goed op Linux?), misschien even over inlezen. Het zal ook nadelen hebben, niet alleen voordelen neem ik aan.

Thanks voor je duidelijk post.

[Verwijderd]

ZFS kent vele voordelen, de nadelen zijn vooral dat het niet algemeen voorhanden is en voor beginners moeilijk kan zijn om in die wereld te duiken. Maar toch niet veel moeilijker dan software RAID onder Linux bijvoorbeeld.

Voor specifieke vragen help ik je graag in Het grote ZFS topic

[redfoxert]

styx1 schreef op zondag 22 januari 2012 @ 21:10:
[...]


Voordeel van een HW is dat je caching hebt met batterij - bij stroomuitval heb je als het goed is geen corrupte data.

Backup is het niet - het is zorgen voor continuteit - zeg ik dat goed?

HW hoeft lang niet altijd met caching en een batterij te zijn. Dat hangt helemaal van de controller af.

RAID is inderdaad zorgen voor continuiteit maar het beschermd alleen tegen hardware uitval. Niet tegen onterecht of onrechtmatig verwijderen. Ook niet tegen data corruptie.

Overigens zijn HW cached met BBU controllers ook niet goedkoop.

[ Voor 5% gewijzigd door redfoxert op 22-01-2012 21:20 ]

[gertvdijk]

styx1 schreef op zondag 22 januari 2012 @ 21:10:
Voordeel van een HW is dat je caching hebt met batterij - bij stroomuitval heb je als het goed is geen corrupte data.

Dat is een fabeltje. Het hangt namelijk ook heel erg van de software af of je data nog altijd consistent is. Een RAID controller werkt op blokniveau, niet op file system niveau.

Een writeback cache voorziet in een prestatieverhoging van writes omdat het de writes kan cachen. Het gevaar is dat die cache nog niet is weggeschreven naar disk op het moment dat er een stroomonderbreking plaatsvindt. Dat wordt dan opgelost met een battery die de write cache voor een beperkte periode bewaart om ze alsnog later weg te schrijven.

Tot zover de theorie, nu de praktijk:

Mensen vergeten vaak om de filesystem cache van de kernel uit te zetten waardoor je alsnog veel in de write queue kwijt bent. Verschil is echter dat het filesystem cache veel slimmer is en dingen afweet op filesystem niveau. Metadata als laatste enzovoorts. Dat maakt een groot verschil in de consistentheid van je data, de mate waarin je kan recoveren naar een consistente staat bedoel ik dan. Je allerlaatste last-minute write vlak voor de power down krijg je er niet mee terug - met een BBU-writecache waarschijnlijk wel, mits goed geconfigureerd.

BBU's gaan ook kapot, ook terwijl je systeem runt. Heb het nu al eens meegemaakt dat er data juist corrupt is gegaan door een falende battery. Bij elke reboot van het systeem waren er weer nieuwe filesystem errors...

Dan nog applicatieniveau:
Voor specifiek MySQL performance en reliability maakt het nogal uit welke engine je gebruikt. Bij InnoDB werk je met transactielogs (fixed size, sequentieel) en je ibdata files (groeiend, random access). Als je dat goed tweakt, de juiste filesystems/hdd's/ssd's kiest en MySQL's caching ook goed zet dan heeft dat grote invloed op je performance.

[ Voor 9% gewijzigd door gertvdijk op 22-01-2012 21:33 ]

[Verwijderd]

Een filesystem genereert FLUSH commando's die je schijven moeten eerbiedigen door de write buffer weg te schrijven alvorens het flush commando voltooid wordt. Normale writes worden dan door de hardeschijf als write-back weggeschreven; direct wordt gereageerd dat de write voltooid is terwijl deze nog in DRAM van de HDD bevindt.

Alle niet-prehistorische filesystems (NTFS, FAT32, Ext3, UFS+SU of SUJ) gaan hier goed mee om. De normale writes zelf zijn write-back maar wanneer het filesystem metadata wegschrijft wordt een flush commando gestuurd. Dit voorkomt dat het filesystem inconsistent raakt omdat de metadata niet langer met de data correspondeert. Zonder deze bescherming op filesystem-niveau, die de schijf moet eerbiedigen, heb je regelmatig last van corruptie. Denk aan Win95 en 98/ME die erg vaak tijdens het opstarten hun filesystem moesten scannen.

Dus dat werkt allemaal prima, maar wat nou met Hardware RAID met eigen (DRAM) buffercache? Die kan writes 'write-through' doen dus direct naar de schijven en de controller doet zelf geen (extra) buffering. Of je kunt write-back draaien waarbij writes direct afgehandeld worden door de controller, en vervolgens naar de disks toe gaan. Dit laatste kan (*) sneller zijn, maar heeft het risico dat als de controller een flush commando niet eerbiedigt door deze ook naar de schijven te sturen, dat je filesystem dan wel corrupt kan raken.

Hardware RAID kan dus prima veilig FLUSH commando's in write-back modus afhandelen, maar doen dat bewust niet. Dit omdat er regelmatig metadata geschreven wordt en dat betekent dat de buffer nauwelijks goed gevuld blijft. Veel hogere performance is mogelijk door de FLUSH commando's te negeren en de write buffer lekker te laten volstromen zodat de disks optimaal bezet kunnen worden.

Maar dan neem je dus een bescherming weg die er zonder die controller wel is, namelijk dat de schijven flush commando's krijgen om hun buffer te kunnen legen. Je vertrouwt er dan op dat de controller met een BBU (Battery Backup Unit) de data in de DRAM kan houden en vervolgens naar de disks te schrijven, zelfs na een stroomstoring.

Dit alles is een in-depth verhaal. Ik kan kort zeggen dat traditioneel hardware RAID + traditioneel filesytem gewoon risico's kent die je niet voldoende kunt afdekken. Je moet dus sowieso zwaar vertrouwen op een goede backup van alle data die je lief is. Veel beter is natuurlijk ZFS, die data wél de bescherming geeft die je mag verwachten anno 2012.

Belangrijk voor ZFS is dat je juist weinig hebt aan zo'n Areca controller, wat als belangrijk nadeel gezien mag worden voor een vrij dure investering. Zeker als je nu al Linux wilt draaien zeg ik: blijf bij software RAID. Dat werkt prima onder Linux en behalve de hierboven genoemde nadelen heb je dan een relatief betrouwbaar opslagmedium.

[analog_]

Polat06 schreef op zondag 22 januari 2012 @ 21:12:
[...]


Nog te weinig ervaring met ZFS (werkt het, zo ja, hoe goed op Linux?), misschien even over inlezen. Het zal ook nadelen hebben, niet alleen voordelen neem ik aan.

Thanks voor je duidelijk post.

Zie ZFS topic- post

[__fred__]

Laatst nog een mooi gevalletje op een HP server mirrored Raid 1:

* Door een software bug in de Raid controller firmware liep het systeem vast
* Daardoor raakte de drives out of sync.
* De software bug liet de raid controller bij de herstart denken dat het recoveren van de data uit de BBU RAM cache mislukt was.
* Hierdoor werden de drives automatisch in write through mode caching gezet
* En begon ie leuk met rebuilden.
* En bij een reboot kon je niet meer aangeven dat je toch write back wilt forcen.

Toen duurde het wel even voordat de server weer enigszins vooruit te branden was, om vervolgens nog twee maal geherstart te moeten worden: 1 maal voor de benodigde firmware update en nog 1 maal om de cache weer in write through te kunnen hengsten.

Altijd mooi, hardware raid. (OK, geef toe, had natuurlijk ook ff die firmware update kunnen doen, maar ja in de advisory stond edge cases (wel critical update))

[Q]

Is de wijze les van spelende vrouw hier niet dat je gewoon je hardware/software/firmware up2date moet houden? Dit is niet hardware RAID / Software RAID specifiek.

Ik hou zelf niet zo van hardware RAID voor thuis gebruik omdat het je wat afhankelijker maakt van een specifieke controller, maar eigenlijk maakt het niet zoveel uit.

Maar software RAID is meestal goedkoper.

[ Voor 55% gewijzigd door Q op 26-01-2012 23:01 ]