Re: Hardware- oder Software-RAID?

[Raphael Eiselstein <rabe@xxxxxxxxx>]

On Sun, Sep 01, 2013 at 11:56:07PM +0200, Frank Thommen wrote:
> Tja, *das* waere natuerlich wunderschoen, scheitert aber definitiv
> an der Finanzierung und der Groesse der aktuell verfuegbaren SSDs:
> Es stehen sechs 2.5"-Slots zur Verfuegung und im Maximalausbau
> moechten wir 4 TB Nettodaten.  Das geht mit RAID-6 oder
> RAID-5+Hotspare gerade noch.  Mit SSDs bezahlbar leider nicht ;-)

Ich moechte an dieser Stelle ausdruecklich vor RAID 5/6 warnen, insbesondere
wenn man eine defekte Platte einmal rebuilden moechte. Die Schreibperformance 
ist auch mit Batteriegepuffertem Cache unterirdisch im Vergleich zum
RAID 1+0 Setup bei ansonsten identischer Hardware.

Ich habe mit Software RAID und HW-RAID bisher gute Erfahrungen gemacht
sofern der RAID-Level keine Paritaeten erfordert, also RAID 1 oder RAID
1+0 oder fuer Mutige auch RAID 0

Unter FreeBSD und inzwischen auch unter Linux (seit debian wheezy)
verwende ich ZFS im Mirror-Betrieb. Das wuerde ich fuer reine Daten-Pools
jederzeit bevorzugen, unter FreeBSD geht auch / auf ZFS, erfordert
allerdings etwas mehr Erfahrung bzw. eine hoehere Frustrtationstoleranz
;-)

Sowohl unter Linux (md) als auch unter FreeBSD (geom mirror) habe ich schon 
Disk-Mirrors betrieben, in der Regel mit wenig Problemen.

4TB netto aus 6x2.5" Slots ist natuerlich sehr sportlich, aber mit
verfuegbarer Hardware durchaus schon machbar.

Beispiel:

* 2x1TB Platten fuer System, Software und Bewegungsdaten als klassisches Software RAID1 
  --> (HDD0|HDD1) (Mirror)

* 4x2TB Platten (zB WD20NPVX) als ZFSv28 Pool fuer Massendaten
  zusammengesetzt aus 2x mirror, entspricht einem RAID 1+0
  --> (HDD2|HDD3)-(HDD3|HDD5) (2x Mirror als Pool)

IMHO sinnvoll bei ZFS ist, dass man dedizierte Platten verwendet, also
keine Partitionen. Bei Daten-Platten. Nutzt man die Platten auch zum
Booten, will man definitiv GPT verwenden.

Vorteile von ZFS: 
* Datensicherheit durch Checksummen
* zuverlaessige Erkennung und "on-the-fly-Reparatur" von Fehlern, sofern die Redundanz 
  ausreichend gross ist. 
* Dieser Fehlerbereinigungsprozess kann auch im Hintergrund ausgefuehrt werden ("zpool scrub")
* Prinzipbedingt immer konsistent, auch nach Datenverlust.

Nachteile von ZFS
* benoetigt viel Erfahrung
* u.U. komplizierte Installationsroutinen, falls ZFS als ROOT-Filesystem
  verwendet werden soll.
* "Mehr RAM.". "Aber ich hab hab' doch schon â?¦" "â?¦MEHR RAM!" 
* Datenverlust bei Stromausfall moeglich im Rahmen des Sync-Intervalls,
  zB 5sec.
* MEHR RAM!

Schreibperformance mit ZFS bekommt man durch zusaetzliche Nutzung von
SSDs als nichtfluechtiger Cache (ZIL, ARC). Wenn kein SATA-Slot mehr frei 
ist, kann man auch eine SSD in Form einer PCI Karte kaufen. Die hat dann 
idR auch wesentlich mehr I/O als eine SATA600 basierte SSD. 

AFAIK ist die Groesse dieser ZIL-SSD "egal", d.h. auch schon mit zB 64MB SSD 
kann man sein zpool auf HDDs deutlich beschleunigen. Ist letztlich nur eine 
Geldfrage.

Finger weg von Deduplikation, nur wenn das im Einzelfall *echt*
angebracht ist! Kompression ist mit modernen CPUs gut.

Nicht vergessen: MEHR RAM!

Ich denke die optimale Loesung kann beliebig gut werden, wenn Geld keine
Rolex spielt. Eine optimale Loesung bezogen auf das verfuegbare Budget ist
natuerlich immer ein Zugestaendnis.

Zurueck zu HW-RAID vs SW-RAID: 

HW-RAID ist normalerweise eine "ohne Aufwand gluecklich werden fuer viel
Geld"-Loesung, dafuer oft recht unflexibel. Ausser man hat sehr hochwertige
RAID-Controller mit viel Eigenintelligenz etwa fuer VirtualDisks oder
Logical Drives. HW-RAID *nur* mit Batterie oder SSD-Cache verwenden.

SW-RAID ist fuer wenig Geld sehr viel flexibler aber bei fehlenedem
nicht-fluechtigem Schreibcache (Batteriegepuffert oder SSD) auch ein echtes 
Risiko fuer Datenverlust. 

Gruss
Raphael

PS: Mehr RAM!

-- 
Raphael Eiselstein <rabe@xxxxxxxxx>               http://rabe.uugrn.org/
xmpp:freibyter@xxxxxx  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/