Re: Hardware- oder Software-RAID?

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Thu, 5 Sep 2013 23:10:44 +0200
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 möchte an dieser Stelle ausdrücklich vor RAID 5/6 warnen, insbesondere
wenn man eine defekte Platte einmal rebuilden möchte. 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 Paritäten erfordert, also RAID 1 oder RAID
1+0 oder für Mutige auch RAID 0

Unter FreeBSD und inzwischen auch unter Linux (seit debian wheezy)
verwende ich ZFS im Mirror-Betrieb. Das würde ich für reine Daten-Pools
jederzeit bevorzugen, unter FreeBSD geht auch / auf ZFS, erfordert
allerdings etwas mehr Erfahrung bzw. eine höhere 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 natürlich sehr sportlich, aber mit
verfügbarer Hardware durchaus schon machbar.

Beispiel:

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

* 4x2TB Platten (zB WD20NPVX) als ZFSv28 Pool für 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
* zuverlässige Erkennung und "on-the-fly-Reparatur" von Fehlern, sofern die Redundanz 
  ausreichend groß ist. 
* Dieser Fehlerbereinigungsprozess kann auch im Hintergrund ausgeführt werden ("zpool scrub")
* Prinzipbedingt immer konsistent, auch nach Datenverlust.

Nachteile von ZFS
* benötigt 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 möglich im Rahmen des Sync-Intervalls,
  zB 5sec.
* MEHR RAM!

Schreibperformance mit ZFS bekommt man durch zusätzliche Nutzung von
SSDs als nichtflüchtiger 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 Größe 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 Lösung kann beliebig gut werden, wenn Geld keine
Rolex spielt. Eine optimale Lösung bezogen auf das verfügbare Budget ist
natürlich immer ein Zugeständnis.

Zurück zu HW-RAID vs SW-RAID: 

HW-RAID ist normalerweise eine "ohne Aufwand glücklich werden für viel
Geld"-Lösung, dafür oft recht unflexibel. Außer man hat sehr hochwertige
RAID-Controller mit viel Eigenintelligenz etwa für VirtualDisks oder
Logical Drives. HW-RAID *nur* mit Batterie oder SSD-Cache verwenden.

SW-RAID ist für wenig Geld sehr viel flexibler aber bei fehlenedem
nicht-flüchtigem Schreibcache (Batteriegepuffert oder SSD) auch ein echtes 
Risiko für Datenverlust. 

Gruß
Raphael

PS: Mehr RAM!

-- 
Raphael Eiselstein <rabe@uugrn.org>               http://rabe.uugrn.org/
xmpp:freibyter@gmx.de  | 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/

Empfangen am 05.09.2013

Dieses Archiv wurde generiert von hypermail 2.2.0 : 05.09.2013 CEST