Software-RAID - Erfahrungen und Tips gesucht...

Zitat

Original von ralf1970
Wow. Gratuliere. Bei 56 Platten hätte ich allerdings gefühlsmäßig auch spontan zu Server/RAID Platten gegriffen.

Bleibt die Frage, wie man die tatsächlich sauber in den üblichen Angeboten auseinanderhalten kann. Entsprechend beworben werden die ja doch eher selten.

Zitat

Original von knebb
Bleibt die Frage, wie man die tatsächlich sauber in den üblichen Angeboten auseinanderhalten kann. Entsprechend beworben werden die ja doch eher selten.

Ein kurzer Blick auf geizhals.at bestätigt dies leider. Nur bei einigen WD SATA Platten wird
"RAID Edition" angegeben, was auf der Webseite dann "WD Caviar RE drives provide
exceptional reliability and performance in 24/7 environments" heißt.

Zitat

Original von kilroyNur bei einigen WD SATA Platten wird
"RAID Edition" angegeben, was auf der Webseite dann "WD Caviar RE drives provide
exceptional reliability and performance in 24/7 environments" heißt.

Bei den neueren Hitachis habe ich das auch gefunden. Fragt mich jetzt aber nicht genau nach dem Typ.

Naja, dann wird man wohl die nehmen, die ausdrücklich so beworben sind. Und bei den anderen vermuten, daß sie nicht für 24/7 spezifiziert sind.

Zitat

Original von Matzetronic
Heute habe ich erste Performance-Tests gefahren. Naja, Schreiben ist mit ca. 25 MB/s ziemlich mager im Vergleich zu knapp 40 MB/s vorher...

In der aktuellen iX ist ein Bericht drinnen über Linux- Tuning bei Festplattensystemen. Da sollte man ggf. die chunksize anpassen. Der Artikel lohnt sich!

Mir war am Wochenende mein SW-RAID5 abgeschmiert. Der SCSI-Controller meinte, zwei Platten abmelden zu müssen.
Nach einem Reboot waren die Platten dann aber wieder da. Nur das RAID wegen zwei fehlenden nicht

Aber man hat ja Erfahrung mit SW-RAID Kurzerhand das Teil "neu gebaut":

mkraid --really-force --dangerous-noresync /dev/md2

und das Teil war wieder da. Daten runterkopiert auf das HW-Raid und endgültig beschlossen, auf FibreChannel Arrays umzusteigen
[/EDIt] Ach ja, nicht wegen der Unzuverlässigkeit von SW-RAID, sondern wegen der Unzuverlässigkeit von SCSI im Verbund mit langen Kabeln

Moin moin,

ich hatte gelegentlich Langeweile und hab' mir 'n Skript gebastelt, mit dem SW-RAIDs überwacht werden können. Fällt 'ne Platte aus wird automatisch die Spare-Disk eingebunden, die defekte Platte deaktiviert, 'ne Mail an root gesendet und wenn man die defekte Platte austauscht wird sie automatisch wieder eingebunden. Für Interessierte hab' ich das Paket angehängt.
Installation:

Installation eines Software-RAIDs mit SuSE 9.3 und md_watcher

Installation starten und Festplatten manuell partitionieren. Partitionen nicht formatieren und Dateisystemkennung 0xfd (Linux RAID) auswählen. Bessere Lösung ist zunächst das Rettungssystem von CD/DVD zu starten und die Festplatten mit fdisk zu Partitionieren. In beiden Fällen ist wichtig, dass die Partitionstabellen aller Festplatten identisch sind, incl. bootflag. Überprüfen kann man das mit sfdisk -d /dev/hdX.
Nun kann man entweder während der Installation mit YaST einzelne Partitionen zu Raids zusammenfassen, oder ebenfalls mit dem Rettungssystem und mdadm das vor der Installation erledigen. Entscheidet man sich für die erste Variante, muss man Partitionen, die auf der als Spare-Disk vorgesehenen Festplatte liegen nachträglich einbinden, weil YaST keine Spare-Disks kennt.
Ist das erledigt und das System installiert muss die Datei /etc/mdadm.conf angelegt werden.
Am einfachsten geht das mit den zwei Befehlen
echo ''DEVICE /dev/hd[aceg]*'' > /etc/mdadm.conf
und
mdadm -Ds >> /etc/mdadm.conf,
wobei statt des regulären Ausdruckes /dev/hd[aceg]* auch alle Partitionen die mit 0xfd markiert sind einzeln durch Leerzeichen getrennt angegeben werden können. Benutzt man den zweiten Befehl zur Vervollständigung der Konfigurationsdatei muss die Synchronisation der Raids abgeschlossen sein, da die Konfigurationsdatei den Sollzustand der Raids darstellen soll. Läuft die Synchronisation noch, werden noch nicht synchronisierte Partitionen als Spare-Disks angezeigt.
Als nächstes das Paket md_watcher.tgz mit
tar -xzf md_watcher -C /
entpacken und den Befehl
handle_mdadm_events -c
ausführen.
Überprüfen ob die Datei /etc/md_watcher/parttbl.dat vorhanden ist. Falls nicht, sind die Partitionstabellen der Festplatten nicht identisch s.o.. Ändern und Befehl wiederholen.
Im YaST Runlevel-Editor die Dienste md_watcherd und check_md aktivieren. Fertig.

ACHTUNG Die Skripte funktionieren nur mit SuSE 9.3 und nur mit RAID1 und RAID5. Ich übernehme natürlich keine Gewähr und die Benutzung erfolgt auf eigene Gefahr. Man sollte auf jeden Fall vorher einen Blick in die Manpages von mdadm geworfen haben.

Gruß

Merten

Zitat

Original von knebb

In der aktuellen iX ist ein Bericht drinnen über Linux- Tuning bei Festplattensystemen. Da sollte man ggf. die chunksize anpassen. Der Artikel lohnt sich!

Die performance unterschiede hängen auch am generell filesystem.
Bei sen Seagate 250GB SATA platte meldet hdparm ca. 50MB/s. Mit ext2/3 und reiser bleiben beim schreiben davon noch etwa 15..20MB/s übrig. Bei XFS sinds dan schon wieder 25..30MB/s (gemessen von mc beim kopieren von 2GB vdr files von einer platte auf die andere).
Ich hab letzte woche erstmalig ein sw-raid5 eingerichtet (5x20GB als 80GB array). Bei xfs fielen sofort massive logging meldungen auf der konsole auf, das er laufend die cache size ändern muss. performance war auch nur lau (<10..15MB/s)
Also mit man in der xfs doku rumgekramt. Siehe an, ssize, su und sw angepasst auf das array und die probleme sind weg. Hdparm meldet jetzt wieder 50..75GB/s auf /dev/md0. Mit mc bleiben etwa 22..25MB/s beim schreiben übrig (P.S. quelle und ziel sind hier auf den selben platten !).
Ich hab auch mal versucht hdparm massiv zu stören. Dazu mit mc auf einer konsole die freedb datenbank kopiert (tausende von kleinen dateien). Hdparm kommt dann immer noch auf 40..45MB/s. Auch hier wiederum quelle und ziel auf den selben platten (ich hab nur 5).

Also meine meinung: sw-raid5 hat seit SATA seine berechtigung. Es sollte zuverlässiger als ein RAID5 hardware controller arbeiten, vorausgesetzt man vergleicht das nicht mit einem sauteuren profi raid adapter.
Wir reden hier von heimanwendern. Die low und middle range RAID adapter dürften alle ihre macken haben. Da ist mir ein ausgetestes sw-raid5 mit stabilem linux kernel leiber.
Also lieber zuverlässigen midrage SATA adapter und sw-raid /PUNKT

gruss Peter

P.S. Ich bin bisher von hd ausfällen verschont worden wenn man mal von der buggy 40GB Fujitsu serie absieht. Selbs mit der hatte ich aber nur moderate probleme.

Zitat

Original von PeterD
Wir reden hier von heimanwendern. Die low und middle range RAID adapter dürften alle ihre macken haben. Da ist mir ein ausgetestes sw-raid5 mit stabilem linux kernel leiber.
Also lieber zuverlässigen midrage SATA adapter und sw-raid /PUNKT

Schön, daß mir da einer zustimmt. Von nix anderem rede ich ja schon seit Ewigkeiten

Trotzdem habe ich hier einen sehr guten 3Ware 9500-S8 Die anderen Platten sind allerdings per SW-RAID "zusammengeschraubt".

Hallo zusammen,

Vor- und Nachteile der einzelnen Lösungen sind hier schon mehrfach angesprochen worden, daher von mir ein Erfahrungsbericht und einige Fragen.

Ich habe schon ziemlich lange 6x120G im Raid5, dazu OS-Platte und DVD-Rom(alles PATA) zu Hause im Fileserver laufen. Die Geräte sind über den Onborad-Controller sowie 2 Promise IDE-Controller(PCI) verteilt. Dazu kommt eine Gigbit-Netzwerkkarte, auch PCI. Probleme gab es mit dem System noch nie - mehrere Stromausfälle waren überhaupt kein Problem.
Nachteile liegen klar auf der Hand:
der PCI Bus pfeifft aus dem letzten Loch - ganz klarer Flaschenhals
teilweise hängen 3 oder mehr Platten aus dem Raid Verbund am selben Controller - auch nicht da Wahre.
Die Zugriffszeiten übers Gigbit-Lan sind für mich aber völlig zufriedenstellend.

Nun zu den Fragen:

Da der Platz langsam ausgeht, möchte ich das ganze etwas runder gestalten und das Array vergrößern - das ganze möglichst günstig.

Option1 (weiterhin Software-Raid5): Neues Board mit ausrechend SATA-Ports Onboard sowie Gigbit-Lan onboard, dazu 3-4 große Platten (400-500 GB) im SW-Raid5 Plus OS-Platte (das PCI-Flaschenhals-Problem sollte sich somit erledigt haben).

Option 2: Was fertiges. Platten und OS getrennt. Als OS-Einheit sowas wie die NSLU2 in vernünftig(Gbit Lan und SW-Raid-Support).
Was Plattengehäuse angeht gibt es von Raidsonic einige interessante Ansätze und hier kommen dann auch die Fragen:

Am Besten gefällt mir ja sowas:
http://www.raidsonic.de/de/pag…raid.php?we_objectID=2643
- proprietäres Raid-System mit diversen Anschlussmöglichkeiten - sowas direkt mit Gbit-Lan und ich wäre glücklich. Leider ist das Teil ziemlich teuer.

Alternativ kann man die Platten auch über ein externes Gehäuse via eSATA, Firewire oder USB anbinden, z.B. http://www.raidsonic.de/de/pag…ases.php?we_objectID=3766
und dann ein Software-Raid draus machen. Wie ist Eure Meinung zu den verschiedenen Lösungen?

Edit: Habt Ihr nen Link für mich was große SATA-Raid-Edition-Platten angeht? So ab 400GB?

Zitat

Original von skies
Am Besten gefällt mir ja sowas:
http://www.raidsonic.de/de/pag…raid.php?we_objectID=2643
- proprietäres Raid-System mit diversen Anschlussmöglichkeiten - sowas direkt mit Gbit-Lan und ich wäre glücklich. Leider ist das Teil ziemlich teuer.

Alternativ kann man die Platten auch über ein externes Gehäuse via eSATA, Firewire oder USB anbinden, z.B. http://www.raidsonic.de/de/pag…ases.php?we_objectID=3766
und dann ein Software-Raid draus machen. Wie ist Eure Meinung zu den verschiedenen Lösungen?

Alles anzeigen

Wozu extern. Du brauchst eh 4 eSATA anschlüsse = 2 controller.
Da würd ich eher einen seperaten PC mit Gbit als NAS bauen.

Zitat

Edit: Habt Ihr nen Link für mich was große SATA-Raid-Edition-Platten angeht? So ab 400GB?

Seagate ST3400832NS (RAID-Edition) 400GB
http://www.alternate.de/html/shop/productDetails.html?showTechData=true&artno=A9BS14&#tecData
Kaum teurer als die normale 400GB SATA.
Aber die 250GB haben eine wesentlich bessere preis/leistung: 0,44€/GB gegenüber 0,72€/GB bei 400GB platten.

Wenn du platz hast: 8x 250GB Seagate ST3250823NS (RAID-Edition) and 2x 4fach SATA adapter als RAID5 oder RAID6.
Beim vergleich:

• 4x400GB = 1,2TB RAID5 = 1156€
• 6x250GB = 1,25TB RAID5 = 654€
• 8x250GB = 1,75TB RAID5 = 872€

Ich denk die rechnung ist eindeutig. Die 400er kosten doppelt soviel wie die 250er. Selbst wenn man die controller noch mit berechnet bleibt noch n' batzen übrig.

Es gibt recht gute 8fach SATA controller für 300..400€, sogar schon mit hardware raid5.
Aber eigentlich sollten zwei 4x PCI-X controller wie der Dawicontrol DC-4300 reichen (~200€). Ich denke 2 controller sind einfacher zu verkabeln.

gruss Peter

PeterD

Du verigsst dabei 3 Faktoren.
1. mehr Strombedarf bei mehreren kleinere Platten
2. mehr Platten = Ausfallwarscheinlichkeit ist hoeher
3. die 400 Gig Platten halten deutlich laenger (Kapazitaet).

Also so einfach wie deine Rechnung ist es leider nicht.

Zitat

Original von devnix
PeterD

Du verigsst dabei 3 Faktoren.
1. mehr Strombedarf bei mehreren kleinere Platten

4 gegen 6 platten. Die 400er haben sicher selbst auch einen (etwas) höheren strombedarf.
Also viel sicher nicht.

Zitat

2. mehr Platten = Ausfallwarscheinlichkeit ist hoeher

Na ja 4 gegen 6 platten macht etwa 50% höheres risiko das etwas passiert.
Ich denk das kann man bei preis faktor 2x ()bei gleicher kapazität akzeptieren.

Zitat

3. die 400 Gig Platten halten deutlich laenger (Kapazitaet).

Weder noch, 4x 400er und 6x 250er ergeben je ~1,2TB kapazität als RAID5 da bei den 400er 25% und bei den 250er nur 17% für die parity benötigt werden.
MTBF ist bei den RAID editions auch gleich.
Also milchmädchenrechnung

Zitat

Also so einfach wie deine Rechnung ist es leider nicht.

Für mich schon

Also in meinen Preislisten liegen die Platten gar nicht soo weit auseinander.
400GB -> 199.-
250GB -> 104.-
Macht 624 zu 796 Euronen. Klarer Unterschied, aber bei Weitem nicht so gravierend wie in Deiner Rechnung(waren allerdings Preise für die Raid-Platten von WD).

Zitat

Original von skies
Also in meinen Preislisten liegen die Platten gar nicht soo weit auseinander.
400GB -> 199.-
250GB -> 104.-
Macht 624 zu 796 Euronen. Klarer Unterschied, aber bei Weitem nicht so gravierend wie in Deiner Rechnung(waren allerdings Preise für die Raid-Platten von WD).

Ich hatte die (fast) gleichen Seagate platten verglichen:

ST3250824AS (non raid) 250GB/SATATII = 94€
ST3250823NS raid edition 250GB/SATA(I) = 109€

ST3400633AS (non raid) 400GB/SATAII = 224€
ST3400632NS raid edition 400GB/SATAI = 299€
(preise laut alternate.de)

Die raid edition sind im prinzip die vorgängerplatten (7200.8, SATA I) aber mit MTBF von 1.000.000h.

Bei den 400er kommt so erschwerend hinzu das die raid edition 25% teurer ist, bei den 250er sind es nur 10%.

Bei WD hast du recht. Die sind deutlich billiger.
Wobei die Seagate sind wirklich leise, bei WD weiss ich's nicht.

Wie ist den der zuverlässigkeitsstatus bei WD ?

gruss Peter

Zitat

Original von PeterD
Wobei die Seagate sind wirklich leise, bei WD weiss ich's nicht.

Naja, wenn Du RAID einsetzt, sollte Dir die Lautstärke der Platten vollkommen egal sein.
Wenn Du mehrere Platten in ein Gehäuse einbaust, benötigst Du ZWINGEND eine deutlich bessere Kühlung, als bei den "normalen" Desktop-Rechnern:

• Der Luftstrom wird durch zusätzliche Kabel und Platten erschwert.
• Mehr Platten heißt mehr Wärme.
• Gerade im 24/7 Betrieb haben die Platten oftmals Wärmespezifikationen, die gewisse Beschränkungen auferlegen.

Durch die dadurch folgenden Zusatzlüfter hörst Du sowieso die Platten nicht mehr

Zitat

Original von Matzetronic
Ok, ich habe gerade gesehen, dass die Ausgabe zwar von 10MB spricht, aber /dev/md0 30MB groß ist

Das mkfs vorher ist natürlich Quatsch. Ich habe es jetzt nochmal ohne getestet - es funktioniert auch. Die Frage ist jetzt, wie spreche ich die Partitionen an ? cfdisk zeigte mir die Partitionen als md0p1 und md0p2, aber mkfs mag dieses gar nicht
Ein cat /proc/partitions zeigt mir auch nur md0.
Was mache ich falsch ?

Matze

PS.:

Code

zwerg:/# hdparm -t /dev/md0


/dev/md0:
 Timing buffered disk reads:   28 MB in  0.70 seconds =  40.23 MB/sec
zwerg:/#

Alles anzeigen

Hallo alle, Hallo matze,

hast du dieses Problem schon gelöst? Ich versuche schon das ganze Wochenede /dev/md0 zu partitionieren. Es wird einfach kein /dev/md0p1 angelegt. Wenn ich alle md* devices von Hand lösche und mit "mdadm --assemble -ap4 /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2" das array starte wird nur /dev/md0 angelegt, aber keine md0p1, obwohl das laut manpage der Parameter -ap4 bei 2.6er Kerneln veranlassen sollte. Habe auch schon von Hand mit mknod experimentiert "mknod /dev/md0p1 b 9 1" (blicke da aber nicht wirklich durch),hat aber nichts gebracht.
Irgendwelche Ideen? Danke schonmal....

Peter

Zitat

Original von peterlustig
Irgendwelche Ideen? Danke schonmal....

Ja. Warum überhaupt partitionieren?

mkfs -t ext3 /dev/md0

und gut ist. Oder ein LVM drauflegen.

Ich weiss dass es sinnvoller ist md0 komplett dem LVM als PV zuzuordnen. Hintergedanke war eigentlich nur eine kleine "Steganographische Spielerei": md0 komplett aus /dev/urandom befüllen, eine riesige Partition für LVM anlegen, aber ein paar 10 MBytes am Ende unpartitioniert freilassen und per crypt-loop einbinden. Mein Gedanke war, dass so keiner auf ein verschlüsseltes Dateisystem schliessen kann, da es ja nirgends eine verschlüsselt Imagedatei, bzw. Logical Volume gibt. Im Nachhinein scheint mir das dann doch ziemlich unausgegoren, da es doch sehr verdächtig ist, md0 zu partitionieren, nur um eine riesige Partition für LVM zu haben.
Trotz allem wurmt es mich, das ich den Fehler nicht finde. Für mein Ego wäre es besser, wenn ich wenigstens einmal ein funktionierendes /dev/md0p1 habe, bevor ich dann 'pvcreate /dev/md0' eintippe....