Raid 5 oder 10 sinnvoller?

1.Kurz: Raid 10 ist Raid5 gespiegelt.
2.Kein Raid ersetzt z.B. bei Virenbefall ein regelmäßiges Backup!
3.Wenn der Adapter stirbt oder der Rechner ausbrennt hilft die kein 
Raid.

Spare das Geld und kaufe noch ein paar Backup-HDs, die Du  an einen 
sicheren Ort legst.

ich glaube du hast eh keine Wahl, denn ein Raid 10 ist ein gespiegeltes 
Raid5. für ein Raid5 braucht man mindestens 3 Festplatten, damit ist das 
minimum für ein Raid 10, 6Festplatten

ich habe mich auch geirrt, Raid 10 ist doch kein Raid 5 mit spiegelung - 
also geht es auch mit 4 Festplatten. Würde ich aber nicht machen.

Wenn du auf 2TB Platten setzt, ersparst du dir erstmal Gefummel was die 
2TB Grenze / Platte mit sich bringt.

Dagobert schrieb:
> raid 10 soll ja etwas schneller sein als 5

vorallem beim schreiben ist es wesentlich schneller.

> Ich würde 5 wählen, weil man dann eben
> den Speicherplatz von 3 Platten ausnutzen kann (anstatt von 2 bei Raid
> 10)

bei 3 2TB platten im raid 5 stehen auch nur 4TB zur verfügung - eine 
platte geht komplett für prüfsummen drauf. bei 4 2TB platten im raid 1+0 
stehen aber auch nur 2TB zur verfügung.

wenn dir datensicherheit wichtig ist, dann nimm raid 5 und steck noch 
eine 4. platte als hot-standby in das nas rein, wenn es ein vernünftiges 
nas ist dann wird es bei einem platten crash automatisch das raid mit 
der 4. platte neu syncronisieren.

RAID6 ist noch einen Tick besser als 5. Die Hotstandby-Platte bei RAID5 
ist zwar ganz nett, es kommt aber durchaus vor, dass beim Resync des 
degradierten Arrays auf die HS-Platte ein Fehler auf einer anderen 
Platte auffällt. Und damit wird dann ganz schnell aus einem RAID5 ein 
Zero-RAID. Allerdings ist RAID6 jetzt nicht bei jedem NAS möglich...

Auch Hotspare-HDs von der gleichen Charge können am gleichen Tag 
sterben. Einfach spiegeln und lieber öfter ein Backup machen sollte 
reichen.

Iwan, ein Rebuild bei der Plattengröße 2TB könnte auch einige Tage 
brauchen je nach Systemauslastung...

Raid-Z?

Morgen...

Dagober, Du solltest ein RAID 5 nehmen.

1. Stripeset (RAID 0) ist gut, wenn Du eine schnelle Verbindung zu 
deinen Festplatten hast. Bei einem NAS ist, wie ICKE schon sagt, die 
Netzwerkverbindung der Flaschenhals. Macht also kein Sinn.

2. RAID 10 ist eine Spiegelung von einem Stripeset. Wie in Punkt 
beschrieben macht das also auch keinen Sinn.

3. Mit RAID 5 hast Du die größte Ausfallsicherheit und ein gutes 
Festplatten/Speicherplatz Verhältnis (n-1). Das heißt, wenn Du 3 
Festplatten (was bei RAID 5 Mindistanforderung ist) angeschlossen hast, 
steht Dir die Kapazität von 2 Festplatten zur Verfügung. Bei 4 
Festplatten ist es die Kapazität von 3 Festplatten. Die meisten Firmen 
setzen RAID 5 ein.

Nachteil (Bei allen RAID's) ist, wenn das NAS defekt ist. Du brauchst 
dann das gleiche NAS bzw. eine Hardware mit dem gleichen 
RAID-Algorithmus, wie ICKE schon geschrieben hat, um die Festplatten 
wieder lesen zu können.

Wenn eine Platte ausfällt, kannst Du immer noch auf die Daten zugreifen. 
Der Zugriff wird langsamer, aber es ist möglich. Wenn Du die defekte 
Platte austauscht, wir der Inhalt der Festplatte aus den vorhandenen 
Platten errechnet und auf die ausgetauschte Festplatte geschrieben. Das 
kann sicherlich länger dauern. In dieser Zeit ist der Zugriff auf Deine 
Daten noch langsamer, aber er ist möglich. Wenn die Platte wieder 
hergestellt ist, ist der Datenzugriff wieder in der gewohnten 
Geschwindigkeit möglich.

RAIDxx schützt Daten von dem Festplattenausfall, nicht von der 
Datenverlust
Solange ein Raid ein Software-Raid ist, kannst du machen was du willst, 
wird nicht schneller.
In deinem NAS-Gehäuse steckt ein Software-Raid, die CPU ist die 
Flaschenhals und nicht Netztwerk. Der hat bestimmt Gigabit schon drin.
An vernüftige Backup kommst du nicht vorbei, wenn deine Daten Wert ist.

Gruß

Tany

Tany schrieb:
> Solange ein Raid ein Software-Raid ist, kannst du machen was du willst,
> wird nicht schneller.
> In deinem NAS-Gehäuse steckt ein Software-Raid, die CPU ist die
> Flaschenhals und nicht Netztwerk.

das gilt leider nicht mehr immer. Die aktuellen CPUs können ohne 
Probleme ein paar 100mbyte/s verodern (XOR). Wenn nicht gerade die 
langsamste CPU verbaut ist, kann ein Softwareraid schneller sein als ein 
Hardwareraid. Das das Hardwareraid dabei effektiver ist (geringer 
stromverbrauch) ist klar.

> In deinem NAS-Gehäuse steckt ein Software-Raid, die CPU ist die
> Flaschenhals und nicht Netztwerk.

>>das gilt leider nicht mehr immer
Du könntet recht haben.

>Wenn nicht gerade die langsamste CPU verbaut ist...
Eben, das gerade NAS-Gerät dieser Klasse sitzt drauf zwar nicht der 
langsamste CPU, aber auch nicht der schnelle CPU (siehe Daten von DS411+ 
auf Synology Seite).

Allerdingst ist RAID1 der sicherste Methode gegen Festplatten- und 
Gerätenausfall...

Gruß
Tany

Tany schrieb:
> Allerdingst ist RAID1 der sicherste Methode gegen Festplatten- und
> Gerätenausfall...

RAID1/Spiegeln hilft nur: solange die Kiste nicht geklaut wird, ein 
Virus oder Dau wütet.

Darum meine ich doch: an vernünftige Backup kommt man nicht vorbei!
Große Firmen haben extra ein Raum dafür. Die haben andere Ansprüche:
- Datenverfügbarkeit: Raid und /oder Redundanz
- Datensicherheit: Backup.

Klare Sache, kann nur Raid 1+0 sein, wie ich grad gelernt habe.

Raid 5 vs 10 oder auch 1+0 genannt, es gibt nur genau einen einzigen 
Grund warum 5 vor 10 vorzuziehen wäre, und das ist:

Man hat nur 4 Bays zum Platten stecken und braucht das absolut maximale 
an Kapazität bei gleichzeitiger nicht ganz minimaler Ausfallsicherheit 
und die Schreibgeschwindigkeit spielt keine Rolle, speziell im recovery 
Fall beträgt dieser nämlich nur noch 20% der Nennleistung.

Angesichts aktueller Kosten für Festplattenspeicherplatz hat RAID 5 
eigentlich keine Daseinsberechtigung mehr. Gleiches gilt auch für die 
RAID versionen 3 und 4 in etwas abgeschwächter Form.

die Details inkl. Begründungen dazu findet ihr bei der BAARF, also hier:

http://www.miracleas.com/BAARF/

Danke das hier so viel Schwachsinn gepostet wurde, das hat mich 
veranlasst mal richtig zu recherchiren, und somit meine eigenen beiden 
RAID 5 Configs zu beerdigen. Zugunsten eines 4bay RAID 10 und eines 6bay 
RAID 10, jeweils in einem QNAP system.

Ich bin mal wirklich gespannt, wie das die Schreibgeschwindigkeiten im 
rsnapshot-Backup beeinflusst.

Aktuell ligt das via SSH bei grad mal 2MB/s und ohne Verschlüsselung 
(also rsync gepulled von der kleinen NAS welche als Backup läuft) bei 
rund 12MB/s. (für 2GB Lan ist das ein Witz) Wobei meine große Maschine 
Lese- und Schreiberaten an den Proxmox-Server von gut 80MB/s liefert. 
(Ich hab die 3TB Survilance Platten von Segate im Einsatz)

Ich bin jetzt mal richtig gespannt wie sich der Software-Raid in der 
TS410 bei RAID 10 verhält und was da für Schreibraten für die Backups 
kommen, den Backups von VM Containern die jede Nacht über 350 GB 
ausmachen, braucht man mit 10MB/s nicht anfangen zu sichern, die sind 
noch nicht Fertig wenn die ersten User morgends die Rechner einschalten.

Gruß Manne

schau mal hier

http://www.adaptec.com/en-us/_common/compatibility/_education/raid_level_compar_wp.htm

die Jungs verstehen ihr Handwerk ...

https://www.synology.com/de-de/knowledgebase/tutorials/492

Synology verwendet Hybrid RAID, die kochen ihre eigene Suppe - auf die 
du dich jetzt einlassen darfst. Vergiss alles geschriebene ...

Ist schon ein wenig abgefahren was die hier machen. Ein "echter" 
Hardwarecontroller (3ware, Adaptec, Intel) ist mir persönlich lieber.

Wenn ich die Wahl zwischen Raid5 und Raid10 habe, nehme ich immer 
Raid10.

Bei den heutigen Plattengrößen und den damit verbundenen Rebuild-Zeiten 
würde ich RAID5 keinem mehr empfehlen: Wenn während des Rebuilds eine 2. 
Platte stirbt, sind alle Daten futsch. Das Rebuild dauert aber gerne mal 
1-2 Tage, je nach Array- und Plattengröße...

Wenn ich unbedingt Platten sparen muss, nehme ich RAID6 - das hat 
identische Performance und identische Probleme zu RAID5, da aber 2 
Platten sterben können (Prüfsumme wird einfach 2x gespeichert) sinkt 
diese Wahrscheinlichkeit des Totalausfalls während des Rebuilds enorm.
Klar, man braucht für RAID6 dann auch mindestens 4 Platten wie bei 
RAID10, aber immerhin kann man dann in 1-Platten-Schritten vergrößern. 
Bei RAID10 muss man halt immer 2 neue Platten reinhängen.

Gründe für meine starke RAID10 Vorliebe:
1.) Langsam, und nicht nur ein bisschen.
Raid5 mit 3 Platten bedeutet, dass über 2 Platten in Blöcken (Chunks) 
XOR gemacht wird und das Ergebnis auf der 3. landet.
Das bedeutet auch, dass wenn ich weniger als Chunk-Größe Daten schreiben 
will, ich
- den kompletten Chunk von Platte 1
- den kompletten Chunk von Platte 2
lesen muss, einen der beiden Chunks mit meinen Daten ändern (z.B. Platte 
1) und dann die XOR-Geschichte tun muss. Danach schreibe ich das 
geänderte Chunk und das XOR-Ergebnis.

Sprich, für einen Zugriff, der z.B. 4kiB schreiben will muss ich (bei 
einer typischen Chunk-Größe von 64kiB):
- 2x64kiB lesen
- 64+4kiB schreiben

Das ist der absolute Killer für jedwede Form von Schreibzugriffen, 
insbesondere Random-Access.
Da Dateisysteme aber permanent irgendwo protokollieren, wann welche 
Datei zugegriffen wurde sind quasi immer alle 3 Platten beschäftigt und 
man erreicht auch beim lesen nicht die erwartete Leistung 2er Platten.

Das Ganze wird eher übrigens schlimmer, je mehr Platten in dem Array 
sind, und sollte das Array von mehreren Nutzern gleichzeitig zugegriffen 
werden (Server, NAS) ist das wirklich nicht mehr schön.

Raid 10 liest im Idealfall gemäß der Plattenanzahl N mal schneller und 
schreibt so schnell wie N/2.
Auch gibt es da zwar ne Chunk-Größe, aber wenn ich nur 4kiB schreiben 
will, schreibe ich nur 4kiB.
Die Chunk-Size bestimmt hier nur, wie viele kiB "am Stück" auf eine 
Platte geschrieben werden - bei mehr Schreibvolumen wird eine weitere 
Platte mit belastet. Insofern hat die Chunk-Größe lediglich Einfluss auf 
parallele Zugriffe und die sequentielle vs. random Performance.

2.) Ausfallsicherheit
Beide RAID-Systeme garantieren dass eine Platte sterben darf, bevor 
Datenverlust auftritt. Bei RAID5 ist diese Garantie unabhängig von der 
Plattenanzahl. Bei RAID10 ist die 1 zwar garantiert, es können aber auch 
mehr Platten "problemlos" sterben: Maximal N/2 Platten, mit N=Anzahl der 
Platten im Array. Das liegt daran, dass nun mal auf der Hälfte der 
Platten im Array identische Kopien eines Partners sind - so lange nur je 
einer der Partner stirbt, hat man kein Problem.
Das ist dann aber Glückssache ;)

3.) Recovery
Daten aus einem kaputten RAID5 rauszukratzen ist ne Katastrophe, weil 
man da immer die richtigen 2 Blöcke braucht, und dann ggf. noch XOR 
spielen muss. Bei RAID10 ist das einfacher: Alles was < Chunk-Größe war 
liegt komplett auf einer Platte, was größer war dann halt "fortgesetzt" 
auf dem selben Block der anderen Platte(n).
Insofern hat man da bessere Chancen, Dateien wieder zusammenpuzzlen zu 
können.

4.) Ressourcen
Weniger CPU und weniger gleichzeitig laufende Platten bei RAID10 sind 
immer gut.

Mein Fazit
==========
Wenn Prüfsummen-Raid, dann RAID6 - sonst RAID10.
Wenn Raid5 unbedingt sein muss, dann mit Hot-Spare (leere Platte) im 
System und mit genau 3 Datenplatten, nicht mehr.
Raid5+6 nur zu Archivzwecken, für Daten mit denen mehrere Nutzer 
Arbeiten immer RAID10.

A. K. schrieb:
> Bernd schrieb:
>> Ist schon ein wenig abgefahren was die hier machen. Ein "echter"
>> Hardwarecontroller (3ware, Adaptec, Intel) ist mir persönlich lieber.
>
> NetApp verwendet in deren NAS Systemen keine Hardware-Controller,

dann schraub eins auf und begutachte den RAID-Controller. Du wirst 
sicherlich ein Controller-Chip LSI z.B. SAS2108 mit DDR2 800 Cache 
vorfinden. Dazu ein AkkuPack usw. wie es sich für ein HARDWARE-RAID 
gehört.

Du verwechselt hier etwas ...

Mit Verlaub:

A. K. schrieb:
> LOL schrieb:
>> Das ist der absolute Killer für jedwede Form von Schreibzugriffen,
>> insbesondere Random-Access.
>
> Nicht "insbesondere" sondern "nur". Bei schnellem sequentiellem Zugriff
> muss nicht vorher gelesen werden. Daten werden dann nicht unter
> vorhandene Daten gemischt, sondern komplett mitsamt Parität erzeugt.

Wenn da ein Dateisystem drauf ist, schreibt man dank Journalling, 
(Netzwerk-)Dateisystem-Locks, Last-Access-Datum etc. auch bei jedem 
Lesezugriff irgendwelche Metadaten. Insofern ist auch bei sequentiellen 
Zugriffen immer was schreibendes dabei, wenn auch extrem wenig. Nur hat 
man außer beim Video-Streamen halt nirgendwo "große sequentielle" 
Zugriffe, und das Videostreamen kommt eh aus dem Cache.

Davon abgesehen ist im Mehrbenutzermodus quasi immer jemand am Schreiben 
und blockiert damit mehrere Platten, was die lesenden Zugriffe der 
anderen verlangsamt.

Witziger Weise machen Netzwerkdateisysteme (lies: CIFS) "sequentielle" 
Dateizugriffe auch ziemlich schlecht, da werden dann bestenfalls eher "n 
Zugriffe a 64kiB Blocks" draus. Ist zumindest an den Stellen wo ich 
gemessen habe so, ich habe in den seltensten Fällen irgendwo nen Zugriff 
>64kiB messen können, so bald Netzwerk im Spiel war. (Die Masse der 
CIFS-Zugriffe ist 4kiB oder 16kiB, zumindest was ich so messen konnte - 
ich hab das letztes Jahr erst recht intensiv betrieben. Die 
durchschnittliche Dateigröße im betroffenen System lag aber bei ~512kiB, 
viele Fotos und riesige Excel/Word-Dateien)

Das Grundproblem ist bleibt halt, dass bei einem 3-Platten-RAID5 
jedweder Schreibzugriff < Chunk-Größe immer 3 Zugriffe kostet: 1 
zusätzlichen Lesezugriff, 1 zusätzlicher Schreibzugriff für die 
Prüfsumme. Das ist extrem teuer, und nicht nur die übliche "1/3 
weniger Schreibperformance" die man so im Allgemeinen nachlesen kann. 
Die Chunks kleiner zu machen ist auch keine Lösung, dann geht wieder die 
CPU-Last nach oben und man hat mehr RAID-Overhead allgemein.

>> Das Ganze wird eher übrigens schlimmer, je mehr Platten in dem Array
>> sind,
> Es müssen nie mehr als 2 Disks gelesen werden. Zur Erzeugung der neuen
> Parität reicht es aus, den alten Inhalt der Zieldisk und die bisherige
> Parität zu lesen. Bei mehr Platten verteilt sich das dann auf mehr
> Platten, weshalb die Belastung der einzelnen Platte sinkt.

Jain, siehe oben. Ist es nicht reichlich sinnlos, für 1 Schreibzugriff 
immer noch 1 Lesezugriff machen zu müssen?
Davon abgesehen: Wenn ich nur 0-63kiB schreiben will muss ich bei einer 
Chunk-Größe von 64kiB:
- Chunk A, den zu ändernden kennen -> Lesezugriff 1
- Chunk A ändern
- die alte Prüfsumme oder Chunk B kennen -> Lesezugriff 2
- die neue Prüfsumme berechnen
- die neue Prüfsumme schreiben -> Schreibzugriff 1
- den geänderten Chunk schrieben -> Schreibzugriff 2
So weit mir bekannt, arbeiten die RAID-Systeme immer in diskreten 
Chunk-Größen und berechnen die Parity nicht "blockweise" innerhalb des 
Chunks nach. Kann mich da durchaus irren, hab aber noch nirgendwo das 
Gegenteil gelesen.

Zudem sind die Prüfsummen sind ja nicht auf einer einzelnen Platte 
sondern immer "auf der jeweils anderen". So sind immer 2-3 Platten (egal 
welche) belastet. Im Mehrbenutzer-Szenario fallen die dann aus der 
Perfomance "raus", weil 1 schreibender User 3 Platten blockiert, die die 
anderen auch nicht mehr lesend verwenden können. Ja, das wird besser, 
wenn die Plattenanzahl steigt, aber nicht in dem Maße wie man erwarten 
würde, weil im Mehrbenutzer-Szenario quasi immer irgendwer/irgendwas 
schreibt und für jeden parallel vorkommenden Schreibzugriff drei Platten 
vorzuhalten ist irgendwie unwirtschaftlich.

>> Daten aus einem kaputten RAID5 rauszukratzen ist ne Katastrophe, weil
>> man da immer die richtigen 2 Blöcke braucht,
>
> Man muss bei einem RAID 5 aus N Disks nicht 2 Blöcke lesen, sondern N-1
> Blöcke. Auch der Rest deines Textes legt nahe, dass du das XOR Verfahren
> nicht völlig verstanden hast.

Klarstellung: Es ging hier um disaster-recovery (nicht rebuild!), da 
braucht man bei 3 Platten 2 Blöcke, um 1 Stripe wiederherzustellen:
2x Datenchunk oder 1x Datenchunk + 1x Prüfsumme. Und die sind, je nach 
RAID-Controller/System an verschiedenen Block-Offsets der Platten 
verteilt, viel Spaß beim Suchen....

Wie XOR funktioniert weiß ich schon, und die dolle Performance von RAID5 
hab ich auch schon mehrfach durch - mit 50-100 Usern als Dateiserver 
kann man das vergessen, es sei denn man nimmt 50-100 Platten. Dann 
wechselst man aber auch täglich eine Defekte aus.

Besonders schlimm ist das beim NAS/Fileserver-Szenario: 
Windows-Netzwerkdateisystem. Word, Excel & Co. schreiben aller paar 
Sekunden irgend einen rotz, da bricht die Leistung dramatisch ein.

Das fällt meist nur nicht auf, weil man eben xxx MiB Schreibcache auf 
dem Controller hat und xxx GiB Lesecache im RAM...
Da braucht man dann nur wenige Chunks "sinnlos" lesen...

Ein 4-Bay NAS macht zu 99% Software-Raid, da ist dann der Cache "weg" 
wenn mal Stromausfall ist, Prost! Ne BBU findet man im Heimbereich auch 
eher selten.

IMHO ist RAID5 mit 2+TiB Platten echt durch nichts mehr zu verteidigen.

>> Raid5+6 nur zu Archivzwecken, für Daten mit denen mehrere Nutzer
>> Arbeiten immer RAID10.
>
> Wobei grosse professionelle RAID Systeme dennoch RAID 6 verwenden, oder
> damit vergleichbare Methoden. Und gerade diese Systeme bedienen hunderte
> von Usern.

Deine Aussage würde ich umkehren wollen: Die verwenden eben kein RAID5, 
sondern gerade RAID6, siehe Vorpost / Ausfallwahrscheinlichkeit. Und 
wenn, dann sind das todsicher keine Windows-Dateiserver, NAS oder 
Datenbank-Server, sondern irgendwelche Webserver oder Caches, die 
vornehmlich (über 70%) Lesezugriffe haben.
Bei Windows-Dateiservern im Office-Bereich und Datenbanken ist eher 
50-70% schreiben angesagt, da vermute ich dass sich das keiner traut.

Ich bin von RAID5 jedenfalls nachhaltig geheilt ;)

PS:
Beim Querlesen viel mir auf, dass ich mittlerweile ziemlich viel in das 
Ausgangszenario reininterpretiere / mich reinsteigere. Mehr als 
"4-Platten NAS" ist ja quasi nicht bekannt, ich unterstelle hier einfach 
"Windows-Zugriffe" und "Dateiserver", was ja nicht sein muss. Und die 
RAID5/6 Nachteile gelten halt auch nur, wenn's auf Performance >1 Platte 
lesend bzw. 1/2 Platte schreiben oder halt Mehrbenutzer ankommt und 
nicht auf Platz.
Ohne das bleibt quasi nur die Recover-Situation übrig, das ist aber 
vermutlich auch das Wichtigste der Argumente.

A. K. schrieb:
> An dieser Stelle erweist sich das Redundanzverfahren in ZFS oder BTRFS
> als recht angenehm. Diese Filesysteme stellen bei RAID 1 zwar ebenfalls
> sicher, dass sich alle Daten auf 2 verschiedenen Disks befinden, ein 1:1
> Mapping der Position auf den Disks ist damit aber nicht verbunden.

Frage: Hast du/irgendjemand btrfs schon mal irgendwo produktiv 
eingesetzt, als RAID6/RAID10? Weil, das ist eigentlich eine Sache, die 
mich auch brennend interessiert. Insbesondere wegen "Plattenmischen", 
atomaren Snapshots etc.

ZFS ist für mich nicht interessant, weil auf für mich relevanten 
Betriebssystemen nicht nativ verfügbar ;)

Ich hab bislang halt nirgendwo was gesehen, wie man das monitoring 
bewältigt, also dass die Kiste laut schreit, wenn man eine Platte 
verliert.
Beim "typischen" Raid (mdadm oder RAID-Controller) schreit der Server ja 
laut auf (Mail, Event-Script...), wenn er eine Platte verliert. Auch 
wird auf defekte Blöcke überwacht und in $intervall auch mal geprüft, ob 
der Inhalt Spiegel/Parity-Blöcke auch passt.
Bei btrfs hab ich da keinerlei Aussagen/Infos zu gefunden, was der 
größte Hemmschuh für mich ist, dass auch mal einzusetzen.

Insofern fahr ich da bisher immer noch RAID + lvm + Dateisystem...

Reinhard S. schrieb:
>> Bei den heutigen Plattengrößen und den damit verbundenen Rebuild-Zeiten
>> würde ich RAID5 keinem mehr empfehlen: Wenn während des Rebuilds eine 2.
>> Platte stirbt, sind alle Daten futsch.
>
> Das kann dir bei RAID10 aber genauso gehen.

Dann muss der Satz oben aber lauten: Wenn während des Rebuilds die 2.
Platte stirbt, sind alle Daten futsch.

Es muss genau die Platte sterben, die deren Spiegel bereits tot ist. 
Wenn eine andere stirbt ist das egal.

A. K. schrieb:
> LOL schrieb:
>> Nur hat
>> man außer beim Video-Streamen halt nirgendwo "große sequentielle"
>> Zugriffe,
>
> Hab ich haufweise. Backup-Daten auf Archiv- und Backupsystemen
> beispielsweise verwenden neben nichtsequentieller Verwaltung massenhaft
> grosse sequentielle Daten.

Das ist dann aber IMHO wieder ein Spezialfall, weil du sicher dein 
Archiv- und Backupsystem nicht auf dem selben Array wie die Nutzdaten 
fährst. Insofern passt das da schon in das gesagte rein: Raid6 für 
Archiv.

>> Davon abgesehen ist im Mehrbenutzermodus quasi immer jemand am Schreiben
>> und blockiert damit mehrere Platten, was die lesenden Zugriffe der
>> anderen verlangsamt.
>
> Das haben Disks so an sich. Daran ändert das Verwaltungsverfahren der
> Disks nichts. Das R-M-W von RAID 5 impliziert aber nur, dass der
> einzelne Request verlangsamt wird. Die Summe der Requests hingegen
> nicht, insofern kommt ein solches System mit nicht zu geringer Anzahl
> Disks mit einer grösseren Anzahl User durchaus klar, weil sich die auf
> verschiedene Disks verteilen oder optimierte Seeks zulassen.

Naja, die nicht zu geringe Anzahl Disks geht dann aber schnell in 
Richtung "Wahnsinnig viele Disks" über. Dann hat man entweder massiv zu 
viel Kapazität, weil's kaum noch entsprechend kleine Disks gibt (was ja 
kein Problem ist) oder halt zu viel Geld.

Ich glaube sowieso, dass wir hier Äpfel mit Birnen vergleichen. Wenn ich 
6-stellige Beträge auf ein NAS von NetAPP werfe, geht es eh nicht mehr 
darum, aus 8-20 Platten Performance für 4-40 User rauszuholen. Das läuft 
dann schon unter "lieber goldene oder platin Handtuchhalter".

Davon abgesehen dass ich, wenn ich xxGiB Cache für mein Working-Set habe 
eh erst sehr spät oder nie die wahre Performance des Arrays merke. Das 
hat dann aber IMHO auch nix mehr mit RAID-Performancebetrachtungen zu 
tun. Aus dem Preis/Leistungsgefüge in dem ich mich bewege ist man dann 
aber schon sehr lange raus, ganz zu schweigen davon dass sich sowas 
ein kleines Unternehmen i.d.R. sowieso nicht leisten kann/wird...

> Spiegelung belastet schreibenderweise auch immer 2 Disks. Der
> Unterschied liegt in der Reihenfolge der Operationen. Spiegelung muss
> nicht warten, was die Latenz reduziert. Genau deshalb ist ein
> nichtvolatiler Cache bei RAID 5 so essentiell.

Den hat man bei Spiegelung aber auch, so dass der Effekt dann wieder 
negiert wird. Da kommt dann bloß noch die Latenz für das Parity zum 
tragen, die sollte aber idealer Weise << rotationslatenz sein.

>> Klarstellung: Es ging hier um disaster-recovery (nicht rebuild!), da
>> braucht man bei 3 Platten 2 Blöcke, um 1 Stripe wiederherzustellen:
>
> Was war jetzt nochmal der Unterschied? Wenn du einen Restore von Backup
> meinst: Der ist ziemlich sequentieller Natur, deshalb siehe oben.

Ich meinte "Uups, mein Raid ist kaputt und ich habe kein Backup".
Mir schon klar, dass das im Unternehmen nicht passiert, aber Otto-Normal 
hat in der Praxis eher selten ein 2. NAS mit einem Backup rumfliegen.

> Mehr als eine einstellige Anzahl Disks wird in einer Einsatzdauer von 5
> Jahren nicht ausfallen, wenn keine Gurkenserie dabei war.

Dein Wort in Gottes Gehörgang. Aber auch wieder weit von RAID5 weg, denn 
mit 20 Disks baut hoffentlich niemand, der in Stochastik aufgepasst hat 
ein einzelnes RAID5-Array.
So hoch kann die MTBF der Einzeldisk gar nicht sein, als dass man da 
noch auf sinnvolle Werte für das Array kommen würde. In der Praxis mag 
das durchaus laufen, ich gehe das Risiko aber sicher nicht ein.

>> Ein 4-Bay NAS macht zu 99% Software-Raid, da ist dann der Cache "weg"
>> wenn mal Stromausfall ist, Prost! Ne BBU findet man im Heimbereich auch
>> eher selten.
>
> Klassische Filesysteme arbeiten bei Metadaten-Updates journalled und
> ausreichend synchron. COW Filesysteme haben ihre consistency points.
> Wenn man es nicht anderweitig dazu zwingt, dann schreibt ein NFS Service
> auf Disk durch, bevor er den Vorgang quittiert. Ohne nichtvolatilem

Die schreiben AFAIK nur bis dem Punkt durch, der sagt "erledigt". Das 
ist
entweder der Controller-Cache mit BBU oder halt die Platte. Bei den 
Platten ist das dann so ne Sache: Theoretisch kann man da den 
Schreibcache abschalten, praktisch ist es aber schwierig, das sicher zu 
verifizieren, das wirklich gar nix in irgend einem Puffer rumgeistert. 
Das läuft dann unter "Vertrauen in den Hersteller".
Praktisch wirft man ne USV drauf und gut ist.

> Writecache geht das freilich deutlich auf die Performance. Diese RAIDs
> sind also nach Powerdown/Crash nicht im Eimer, sondern bloss langsamer
> als welche mit nichtvolatilem Cache.

Das Array nicht, aber die zu schreibenden Daten sind halt u.U. weg. 
Klar, dann greifen die Konsistenzgarantien der Dateisysteme, aber wenn 
halt meine letzten 2h Arbeit weg sind hilft mir das auch nicht wirklich.

>> wenn, dann sind das todsicher keine Windows-Dateiserver, NAS oder
>> Datenbank-Server, sondern irgendwelche Webserver oder Caches, die
>> vornehmlich (über 70%) Lesezugriffe haben.
>
> Du musst es ja wissen. ;-)
>
> Wie wärs mit einer dreistelligen Anzahl VMware-VMs, deren Datastores per
> NFS auf solcher NetApp-NAS mit RAID DP und SAS-Disks sitzen? Windows und
> Linux bunt gemischt, in verschiedensten Rollen.

Da hat das NetApp-NAS alleine vermutlich schon genug RAM, um das 
Working-Set zu cachen,
inkl. Schreibcache. Das ist ziemlich weit von jedweden 
RAID-Performance-Betrachtungen
weg, IMHO ist das dann schon eher ein RAM-Benchmark ;)
Mal abgesehen davon, dass da auf der VM-Host Seite sicherlich auch schon
einiges an RAM dazwischenhängt ;)

Wie sieht bei sowas eigentlich die Statistik schreibend/lesend 
Blockgrößen aus? Im direkten "Samba als CIFS-Server mit RAID10 drunter" 
Betrieb bekomme ich wie gesagt keine großen sequentiellen Zugriffe zu 
sehen, und meine VMs auf der anderen Kiste machen auch typisch 4k oder 
16k und eher random.

>> Bei Windows-Dateiservern im Office-Bereich und Datenbanken ist eher
>> 50-70% schreiben angesagt, da vermute ich dass sich das keiner traut.
>
> Auch das Zeug liegt da drauf. Office ist völlig harmlos, dieser Traffic
> fällt kaum ins Gewicht.

Naja, das ist bei mir neben den VMs der Use-Case schlechthin. Von daher 
hab ich da auch recht viel Zeit reingesteckt, nachzuvollziehen was 
Windows so auf CIFS-Netzlaufwerken treibt. Und das ist, im Gegensatz zu 
Linux, eine ziemliche Katastrophe.

> Auch Datenbanken liegen da drauf. Funktioniert recht gut. Bei denen mit
> hohem Anteil nichtsequentieller Schreiboperationen muss öfter
> defragmentiert werden (wegen COS Filesystem, nicht wegen RAID).

Datenbanken haben sequentielle Schreiboperationen? o_O
Da müssen da ja massive Datenmengen mit relativ wenigen 
Querverweisen/Indizes etc.pp. drinstecken. Alles was ich bislang gesehen 
habe war eher random.

> Bei Datenbanken ist das freilich eine Einzelfallentscheidung. Also je
> nach Aktivität und Verfügbarkeitsanforderung. Ein paar lokale SSDs in
> RAID 1 sind bei der Performance schwer zu übertreffen.

Im Zweifelsfall würde ich heute das RAID1 / RAID10 der SSDs einfach an 
das RAID der Platten als Cache anbinden. Das funktioniert recht gut, und 
man muss nicht sortieren was man wo hinlegt. Braucht natürlich 
entsprechende SSDs und man ist recht schnell wieder im Bereich 
"Cache-Benchmark" statt "Raid-Benchmark".

Mit so einer Lösung kommt man dann auch wieder in den Bereich, an dem 
man sagen kann das nicht mehr die Plattenlatenz, sondern die 
Netzwerklatenz entscheidend ist. Beim typischen NAS geht letzteres ja 
eher unter.

A. K. schrieb:
> LOL schrieb:
>> Weil, das ist eigentlich eine Sache, die
>> mich auch brennend interessiert. Insbesondere wegen "Plattenmischen",
>> atomaren Snapshots etc.
>
> Snapshots setze ich schon lange produktiv ein, nur eben auf NetApp. Aber
> das Verfahren unterscheidet dabei sich nicht wesentlich von ZFS/BTRFS,
> als Folge von COW.

Snapshots nutze ich auch, nur das die halt mit lvm & co. halt 
block-atomar sind und nicht fs-atomar. D.h. das typischerweise beim 
Mount des Snapshots erstmal gemeckert wird und kurz fsck läuft umddas 
Journal durchzuspielen, wenn die Platte in Benutzung war, als der 
Snapshot erstellt wurde.

Genau das sollte ja mit btrfs-snapshots nicht passieren.

> Manche verwenden in Heim-NAS eigens deshalb FreeNAS. Da steckt BSD drin,
> mit nativem ZFS, aber dank Blackbox-Prinzip ist das Betriebssystem
> ziemlich unwichtig.

Naja, auf mein Heim-NAS ist halt noch mehr als nur ein Datengrab, 
insofern müsste ich da schon mehr mit *BSD machen.

>> Ich hab bislang halt nirgendwo was gesehen, wie man das monitoring
>> bewältigt, also dass die Kiste laut schreit, wenn man eine Platte
>> verliert.
>
> Regelmässiges /bin/sh

... also nix out-of-the-box, sondern selbstgemacht? Hmmm.... Könnte ich 
auch, will ich aber eher nicht. Ich bin in den letzten Jahren eher zum 
"gibt es ein Paket/Dienst dafür" Menschen geworden.
Naja, irgendwann erklären die btrfs dann endgültig für Produktiv, da 
gibt's dann solche Schmankerl sicher auch.

Christian Berger schrieb:
> Naja, mal abgesehen davon, dass es keine bezahlbaren Backuplösungen für
> mittelgroße Datenmengen (5-20 Tb) gibt ist eine Rücksicherung doch etwas
> das man vermeiden möchte, da die doch bei den Datenmengen schon Tage
> dauert.

Im einfachsten Fall stellt man sich 2 identische Boxen räumlich getrennt 
hin und spiegelt die auf Blockebene, z.B. via drbd. Da hat man dann RAID 
via Netzwerk, und wenn eine Kiste stirbt merkt man es nicht mal. 10Gbe 
ist heute auch nicht mehr der Preisfaktor.

Klassisches Backup geht bei den o.g. Datenmengen quasi auch nur noch 
über Snapshot + ein 2. NAS, da kann das dann auch mal länger dauern.
Wobei Zeit sowieso das größte Problem am Backup ist: Selbst wenn man 
Snapshots macht, will man nicht tagsüber seine Bandbreite für's Backup 
verbraten.

Im Zweifelsfall kann man bei RAID10 auf dem Backup-NAS einfach die 
Hälfte der Platten des NAS rausnehmen und in einen Schrank packen, 
praktisch würde ich das aber auch nicht machen wollen, der 
Ausfallwahrscheinlichkeit wegen. Dann doch lieber 1-2 preiswerte Boxen 
hinstellen und alternierend mit Daten bespielen. So groß/schwer sind die 
auch nicht, die kann man sich schon noch in den Stahlschrank packen.

LOL schrieb:
> Klassisches Backup geht bei den o.g. Datenmengen quasi auch nur noch
> über Snapshot + ein 2. NAS, da kann das dann auch mal länger dauern.

Das sich nicht alle Daten in Kurzer zeit ändern, ist ein Backup auf 
Dateisystem ebene meist sinnvoller. Dabei kann man recht schnell 
feststellen das sich 95% der Daten nicht geändert haben und damit auch 
nicht ein 2.Mal gebackup werden müssen. Dann braucht man nur noch neue 
und geänderte Dateien zu sichern.

Je mehr Wissen man über die Daten hat, desto besser kann man ein Backup 
einrichten.

Peter II schrieb:
> Das sich nicht alle Daten in Kurzer zeit ändern, ist ein Backup auf
> Dateisystem ebene meist sinnvoller. Dabei kann man recht schnell
> feststellen das sich 95% der Daten nicht geändert haben und damit auch
> nicht ein 2.Mal gebackup werden müssen. Dann braucht man nur noch neue
> und geänderte Dateien zu sichern.

Zur Klarstellung: Die Aussage "Snapshot machen" bezog sich darauf, einen 
Snapshot auf Blockebene zu machen, zu mounten dann auf Dateisystem-Ebene 
sichern.
Wie du schreibst ist beim echten Backup ist Blockebene meist nicht 
sinnvoll. Wobei, wenn man Dateisysteme mit Millionen kleiner Dateien 
hat, wird das inkrementelle Backup ganz schnell extrem langsam.

A. K. schrieb:
> LOL schrieb:
>> ... also nix out-of-the-box, sondern selbstgemacht? Hmmm.... Könnte ich
>> auch, will ich aber eher nicht. Ich bin in den letzten Jahren eher zum
>> "gibt es ein Paket/Dienst dafür" Menschen geworden.
>
> Wasch mir den Pelz aber mach mich nicht nass?
>
> Genau das wäre FreeNAS. Aber das ist dir dann wieder zu fertig. ;-)

Ich meinte da jetzt nicht das bauen des btrfs oder des Kernels/moduls. 
Da könnte ich mit leben, so oft kommt das nicht vor.

Aber wenn ich die Überwachung des Arrays selber schreiben muss, habe ich 
eben nichts, was out-of-the Box funktioniert und halbwegs standardisiert 
in andere Dienste integrierbar ist. Für zu Hause ist mir das vermutlich 
zu viel Aufwand für 1 Kiste, für die Arbeit wäre mir das vermutlich zu 
kompliziert in diverse Überwachungssysteme einzubauen.
Zumal ich dann auch noch das Risiko trage, nicht alles oder nicht 
rechtzeitig zu erkennen, was Fehler sind.

Ich hab echt nix dagegen, Dinge selbst zu automatisieren, aber ich 
vertrete halt die Ansicht, das Storage so weit wie möglich "hinstellen, 
fertig" sein sollte. Das macht Linux software-raid z.B. ganz gut denke 
ich, mdadm schreit einfach wenn's was gibt und ansonsten muss ich nicht 
drüber nachdenken.

Gegen freenas hab ich ja nix, ich kann nur aktuell mit *BSD nix 
anfangen. Und ein einzelnes BSD in einer Landschaft von Linux 
aufzustellen ist irgendwie nicht zielführend: Selbst wenn ich es 
bedienen kann, bin ich dann immer noch alleine auf weiter flur. Es ist 
schon schwierig genug, Leute zu finden die wirklich Linux kennen/können.

A. K. schrieb:
> LOL schrieb:
>> Wobei, wenn man Dateisysteme mit Millionen kleiner Dateien
>> hat, wird das inkrementelle Backup ganz schnell extrem langsam.
>
> Kommt drauf an, was man als Informationsbasis nimmt. Nach Timestamp zu
> suchen ist nicht so langsam. Unoptimierter Einzelvergleich der Fileinfo
> über Netz hingegen schon.

Was meinst du mit "unoptimierter Einzelvergleich der Fileinfo"? Kannst 
du das bitte mal genauer ausführen, insbesondere was da besser geht?

Ok, danke. Das mit der Änderungs-DB im Dateisystem ist interessant, hab 
ich so noch nirgendwo gesehen.

Was ich derzeit mache, ist den Krempel via dar zu sichern, so nach dem 
Motto "alles was neuer ist als...". Dar selbst pflegt ne Datenbank-Datei 
mit den Daten, die er zuletzt gesichert hat und macht 
timestamp-Vergleiche.
Dadurch braucht er das alte Archiv nicht zu kennen und weiss bei der 
wiederherstellung, welches Archiv er extrahieren muss.
Da er aber auch Löschungen erkennt, muss er das für jede Datei machen.

Ist also irgendwo zwischen der ganz langsamen Methode und der ganz 
schnellen Methode ohne DB-Unterstützung. Aktuell bin ich eher dadurch 
limitiert, das das Dateisystem verhältnismäßg lange braucht, die 
Timestamps und Verzeichnisinhalte zu laden, aufgrund der 
Dateizahl/Verzeichnis und weil es eben ziemlich viele kleine Dateien 
sind.

Alle Backups von denen ich rede sind im übrigen lokal, also sprich die 
Kiste steuert ihr eigenes Backup an, da ist für vergleiche etc. kein 
Netzwerk-Traffic notwendig.

rsync ist ne feine Sache, aber hat aber ein paar Pferdefüße:

1.) Es synct. Das heißt auch, man kann kein "ab xx.yy.2015 zz:aa Uhr" 
als Parameter mitgeben, er vergleicht immer 2 Verzeichnisbäume.
Wenn man das will, muss man die Datei/Verzeichnisliste selbst erzeugen, 
z.B. mit "find".

2.) Es ist auf Bandbreite optimiert. D.h. er überträgt Dateiänderungen 
als Delta und muss deshalb lokal relativ viel auf Platte rumwürgen. Kann 
man aber abschalten, dann geht aber zusammen mit 1.) der Sinn verloren.

Insgesamt also eher nix, wenn man nicht gerade eine Art "snapshot auf 
Dateisystem-Ebene über Netzwerk" machen will.

LOL schrieb:
> Aktuell bin ich eher dadurch
> limitiert, das das Dateisystem verhältnismäßg lange braucht, die
> Timestamps und Verzeichnisinhalte zu laden, aufgrund der
> Dateizahl/Verzeichnis und weil es eben ziemlich viele kleine Dateien
> sind.

über welche Anzahl von Dateien reden wird? Wir haben ein System mit über 
10.000.000 Dateien und da geht das auch noch recht flott.

Teilweise machen die Programm den Fehler, erst sich alle Dateien liefern 
zu lassen und Fragen dann für jeden Datei die Attribute ab, dabei 
bekommt man die Infos schon bei suchen.

Peter II schrieb:
> LOL schrieb:
>> Aktuell bin ich eher dadurch
>> limitiert, das das Dateisystem verhältnismäßg lange braucht, die
>> Timestamps und Verzeichnisinhalte zu laden, aufgrund der
>> Dateizahl/Verzeichnis und weil es eben ziemlich viele kleine Dateien
>> sind.
>
> über welche Anzahl von Dateien reden wird? Wir haben ein System mit über
> 10.000.000 Dateien und da geht das auch noch recht flott.

Ca. 1,5 Millionen <64k in ca. 150 Verzeichnissen, die 
Verzeichnisstruktur kann man leider nicht ändern :(

Das Problem ist aber vermutlich eher folgendes:
- Steinzeit-Hardware die mittlerweile zu klein ist (8 Sata-Platten an 
SAS mit mdadm/RAID10)
- Nebenbei laufen noch andere Tasks
- Single-Threaded Backup / Listing
- darf nix kosten (4-stellig)

Insofern kann ich mit der gebotenen Leistung eigentlich zu frieden sein, 
zumal an Neuinvestitionen derzeit eh nicht zu denken ist.

Es ist irgendwie echt schwierig, (Linux, FOSS) Multi-Threaded-Software 
zu finden was den Serverbereich angeht. Und so dauern bestimmte 
Operationen auf einer CPU halt ewig, während der Storage sich langweilt.
Prinzipiell gilt halt trotz Multi-Core/Multi-Socket Boards unter Linux 
immer noch die Prämisse, im Zweifelsfall die höher getaktete CPU zu 
kaufen, auch wenn man die im Alltag eigentlich nicht braucht...

Ich lös das teilweise durch Multi-Processing, in dem ich Spezialfälle in 
extra Tasks auslagere, das hat aber dann wieder den Nachteil, dass man 
sich mit locking etc. beschäftigen muss. Man will ja nicht zu viel 
Parallel machen oder gar die Dateien anderer Tasks wegrationalisieren ;)

In der Preisliga TSM oder NetApp spiele ich wie gesagt nicht mit, und 
wie sich die Sache derzeit entwickelt wird's wohl noch ne ganze Weile 
dauern, bis ich wieder mal 5-stellige Investitionen tätigen kann.


Prinzipiell sind wir mit dem Thema aber schon soweit OT, dass wir 
langsam von Threadnapping sprechen können - insofern sollten wir das 
hier vielleicht ein wenig zurückfahren. Zum Thema Raid5,6,10 ist ja 
quasi alles gesagt.

schrieb im Beitrag #3960683:
> Datum: 08.03.2011 10:42

Wie ich oben schon 2011 schrieb: Raid kann kein Backup ersetzen. Egal 
welches Raid, wenn der spezielle Controller im Eimer ist, sieht es 
schlecht aus.

Snapshots kann man zwar machen, aber das Zurückspielen größerer 
Datenmengen kann Taaaaage dauern. Mit sortieren nach Datum kann man zwar 
die letzten geschrieben Daten als erste zurückspielen, aber was ist mit 
igendwelchen Files, die seit Jahren täglich nur gelesen werden? Ganz so 
einfach wirds wohl nicht.