www.mikrocontroller.net

Forum: PC Hard- und Software Raid 5 oder 10 sinnvoller?


Autor: Dagobert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Ich hab mir ein NAS von Synology angeschafft (DS411+). Momentan bin ich 
noch am grübeln ob ich das Teil mit 2TB oder 3TB Platten bestücken soll, 
wahrscheinlich wohl 2TB, da ich bereits 2 Stück davon hab.
Wo ich allerdings unschlüssig bin, ist ob ich Raid 5 oder 10 
konfigurieren soll. Raid 10 soll ja etwas schneller sein als 5, was aber 
zu vernachlässigen ist denke ich. Ich würde 5 wählen, weil man dann eben 
den Speicherplatz von 3 Platten ausnutzen kann (anstatt von 2 bei Raid 
10)
Wie siehts allerdings mit der Sicherheit aus (meine größte Sorge). Was 
passiert wenn wirklich mal eine Platte ausfällt?

Autor: oszi40 (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
oszi40 schrieb:

> 1.Kurz: Raid 10 ist Raid5 gespiegelt.

Nein. RAID 10 ist RAID 1+0, d.h. gespiegelt und gestriped.

Autor: Peter (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dagobert schrieb:

> noch am grübeln ob ich das Teil mit 2TB oder 3TB Platten bestücken soll,
> wahrscheinlich wohl 2TB, da ich bereits 2 Stück davon hab.

Wieviele Platten sollen es denn werden?

> Wie siehts allerdings mit der Sicherheit aus (meine größte Sorge). Was
> passiert wenn wirklich mal eine Platte ausfällt?

RAID 1: praktisch kein Unterschied spürbar.
RAID 5: deutliche Verlangsamung.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Beitrag #2093867 wurde vom Autor gelöscht.
Autor: D. I. (Gast)
Datum:

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

Autor: __tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die höhere Geschwindigkeit von RAID10 gegenüber RAID5 wird bei einem NAS 
nicht zum Tragen kommen, da dort eher die Netzwerkanbindung den 
Flaschenhals darstellt. Aus Sicht der Fehlertoleranz nehmen sich die 
beiden auch nicht viel, sodaß man - in diesem speziellen Fall- zugunsten 
der höheren Kapazität RAID5 den Vorzug geben kann.
Sofern die Daten aber nicht noch einmal regelmäßig woanders gesichert 
werden, würde ich weder das eine noch das andere nehmen. Warum? Fällt 
die NAS-Hardware aus, kommst du nicht an die Daten ran, außer du steckst 
die Platten in ein baugleiches Gerät bzw. eines, das mit mit exakt dem 
gleichen RAID-Algorithmus arbeitet. Sehr dumm, wenn man die Daten 
dringend benötigt, aber kein Ersatz zeitnah zur Verfügung steht.
Ich würde jeweils 2 Platten als RAID1 konfigurieren, weil hier die Daten 
nur gespiegelt sind (quasi 1:1-Kopie). Du könntest im E-Fall eine 
Einzelplatte aus dem Verbund an einen beliebigen Rechner anstecken, der 
das Filesystem lesen kann (meist ext3 oder ext4) und kommst somit 
problemlos an die Daten. Die einzigen Nachteile sind die halbe 
Nutzkapazität und bei mehr als zwei Platten die Aufteilung in mehrere 
Volumes (kein zusammenhängender Speicherplatz).

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: oszi40 (Gast)
Datum:

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

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dagobert schrieb:
> Ich hab mir ein NAS von Synology angeschafft (DS411+). Momentan bin ich
> noch am grübeln ob ich das Teil mit 2TB oder 3TB Platten bestücken soll,
> wahrscheinlich wohl 2TB, da ich bereits 2 Stück davon hab.

Gesamtbestückung 4x 2TB klingt doch nett. :-)

> Wo ich allerdings unschlüssig bin, ist ob ich Raid 5 oder 10
> konfigurieren soll.

Kommt drauf an. Schreib-Performance von Raid-5 ist bei Soft-RAIDs schon 
eher mau, insbesondere wenn man wirklich 'mal rebuilden muß. 
Andererseits kann ich bei Fileservern RAID-5 nur empfehlen, ist schon 
ziemlich sicher.

> Raid 10 soll ja etwas schneller sein als 5...

Kein Wunder RAID 10 ist ja auch nur ein Stripeset aus Spiegeln, und zum 
Spiegeln braucht's keine Parity.

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

Die alte Entscheidung Speed vs. Stability.

> Wie siehts allerdings mit der Sicherheit aus (meine größte Sorge). Was
> passiert wenn wirklich mal eine Platte ausfällt?

Platte raus (die Richtige), (Shutdown)*, neue rein, (Restart)*, rebuild 
(langsam)*, Normalzustand. *=systemabhängig.

Iwan

Autor: oszi40 (Gast)
Datum:

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

Autor: Troll (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Raid-Z?

Autor: Иван S. (ivan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Iwan, ein Rebuild bei der Plattengröße 2TB könnte auch einige Tage
> brauchen je nach Systemauslastung...

Und? Habe ich denn überhaupt irgendwo Gegenteiliges behauptet?

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andi schrieb:

> 2. RAID 10 ist eine Spiegelung von einem Stripeset.

Andersrum. Das wäre RAID01.

> 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 die NAS-Box ein simples Software-RAID in Linux verwendet, wie es 
bei manchen günstigen NAS Systemen der Fall ist, dann kann man die 
Platten zur Datenrettung möglicherweise auch an ein normales PC-Linux 
dranhängen.

Autor: Tany (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mannebk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schau mal hier

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

die Jungs verstehen ihr Handwerk ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... schrieb:
> die Jungs verstehen ihr Handwerk ...

In den 4 Jahren des Threads kann manche Information veralten, weil die 
Disks weiterhin an Kapazität zugelegt haben und der Nutzen von RAID 
Levels nicht mehr unabhängig von Kapazität und Typ der Disks betrachtet 
werden kann.

Was dort leider nicht erwähnt wird: Der offizielle Wert für die 
Lesequalität bei normalen SATA Disks liegt seit langem unverändert bei 
einem Fehler auf 10^14 Bits, also 12TB. Diesem Wert zufolge ist die 
Wahrscheinlichkeit, dass bei Wiederherstellung einer Disk eines RAID 5 
Verbundes - bei der alle Bytes aller übrigen Disks gelesen werden - ein 
weiterer Fehler auftritt, mindestens formal nicht mehr zu 
vernachlässigen.

Bei SAS Disks sieht das noch anders aus, dank 10^16 statt 10^14.

Autor: Andy D. (rackandboneman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei RAID5 mit grossen Platten ist das Risiko bekanntermassen auch nicht 
zu vernachlässigen dass es im Rebuild-Fall zu weiteren Fehlern kommt die 
dem ganzen dann den Rest geben.

Heutzutage nutzt man:

-Raid5 für Sachen die bereits ein Backup von irgendetwas sind und wo man 
möglichst billig viel Platz will

-Raid10 wenn man ein 4-Slot-Chassis und Betriebsdaten hat, oder 
möglichst viel Performance braucht

-Raid6 für grössere Plattensätze.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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, und 
das ist keine Hinterhofklitsche.

Die in Filesystemen wie ZFS und BTRFS integrierte Redundanz ist mit RAID 
Controllern nicht zu leisten. Der Zug fährt also in die umgekehrte 
Richtung.

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein wichtiger Punkt der sich bei mir in der Praxis öfters gezeigt hat 
ist die "Hochrüst-Strategie".

Irgendwann mal wird jedes RAID zu klein, gleichzeitig möchte man die 
Platten auch mal prophylaktisch auswechseln. Die Frage ist dann, wie man 
das RAID vergrößern kann, ohne lange Ausfälle oder das Risiko eines 
Ausfalles eines RAIDs zu riskieren.

Mit etwas Risiko kann man das mit RAID-5 machen. Da wechselt man eine 
Platte aus, macht einen Rebuild, dann die nächste, usw. Sprich bei 4 
Platten hat man 4 Rebuilds, was etwas risikobehaftet ist. Schließlich 
kann ja genau dann eine Platte ausfallen.

Da mein Server eh nur 4 Laufwerksschächte hat tendiere ich im Moment zu 
RAID-10. Da ist beim Rebuild immer noch eine Ersatzplatte mit den Daten 
da.

Vor langer Zeit gab es mal in der IX einen Artikel in dem die Software- 
und Hardwareraids verglichen haben. Das war noch mit SCSI-Platten. Im 
Gegensatz zu dem Zeug auf heutigen Mainboards war das auch noch ein 
echtes Hardware RAID. Das Ergebnis waren ziemlich gleich mit 
Unterschieden im Prozentbereich.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

> 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.

> 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.

> Weniger CPU und weniger gleichzeitig laufende Platten bei RAID10 sind
> immer gut.

Bei einem NAS System ist das weniger problematisch.

> 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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd schrieb:
>> NetApp verwendet in deren NAS Systemen keine Hardware-Controller,
>
> dann schraub eins auf und begutachte den RAID-Controller.

Zufällig weiss ich recht gut, wie diese Systeme intern aussehen. 
Einerseits weil prinzipieller Aufbau und Arbeitsweise dokumentiert sind, 
andererseits weil ich natürlich schon reingesehen habe.

> 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.

Volatiler und nichtvolatiler Cache ist da natürlich schon drin. Als 
volatiler Cache dient der Hauptspeicher eines x86 Serverprozessors. Der 
nichtvolatile Cache ist eine separate Systemkomponente und ziemlich 
NetApp-spezifisch. Heute Teil des Basissystems war das früher eine 
separate normale Steckkarte, in HA-Systemen hatte die einen eigenen 
Anschluss zur dezidierten Kopplung der Caches mit der Partnernode.

Die Interface-Controller zu den Disks sind tatsächlich nur einfache SAS- 
oder Fibre-Channel Controller ohne RAID Funktion und ohne integriertem 
Puffer. Jeder nichtvolatile Cache an dieser Stelle würde die HA-Funktion 
vernichten (IBM hatte diesen Fehler in deren erstem SAN Store gemacht).

So hat ein hochverfügbarer Verbund aus 2 solchen Nodes (im 7-mode) eine 
direkte Kopplung zwischen den beiden Nodes und die Daten jeder Node 
werden live zusätzlich in den Pufferspeicher der Partnernode 
geschrieben. Weshalb auch eine Granate in einer Node keine Daten 
riskiert. Diese Kopplung findet auf der Ebene des Systems statt, nicht 
auf der Ebene des Disk-Controllers.

> Du verwechselt hier etwas ...

Ich arbeite mit den Dingern schon seit vielen Jahren.

Nö, eine NetApp Node verwendet keinen RAID Controller, sondern ist in 
gewisser Hinsicht selbst ein RAID Controller mit NAS-Funktion.

Ein RAID Controller ist eine Blackbox mit CPU, Disk-Interfaces, 
Pufferspeicher und Software. Implementiert i.W. als SOC. Aus Sicht des 
Anwenders (des Betriebssystems des Rechners in dem er steckt) wird damit 
Blockspeicher implementiert.

Eine NetApp Node ist eine Blackbox mit CPU, Disk-Interfaces, 
Pufferspeicher und Software. Implementiert grösstenteils aus 
Server-Hardware, mit modularen Disk- und LAN/SAN-Interfaces. Aus Sicht 
des Anwenders - des Netzwerkes - wird damit Filespeicher implementiert. 
Blockspeicher/SAN-Funktion sitzt bei NetApp verkehrt herum oben auf dem 
Filespeicher drauf.

: Bearbeitet durch User
Autor: Icke ®. (49636b65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:
> Mit etwas Risiko kann man das mit RAID-5 machen. Da wechselt man eine
> Platte aus, macht einen Rebuild, dann die nächste, usw. Sprich bei 4
> Platten hat man 4 Rebuilds, was etwas risikobehaftet ist. Schließlich
> kann ja genau dann eine Platte ausfallen.

Mit einer vorhandenen Sicherung ist das kein Risiko. Die Daten nur einem 
RAID anzuvertrauen, ist ebenso leichtsinnig, wie sie nur auf einer 
einzelnen Platte liegen zu haben. Auch wenn es ein alter Hut ist, man 
kann es nicht oft genug betonen, RAID ersetzt NICHT das Backup!

: Bearbeitet durch User
Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> 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 kann dir bei RAID10 aber genauso gehen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard S. schrieb:
> Das kann dir bei RAID10 aber genauso gehen.

Man muss freilich nur eine Platte vollständig fehlerfrei lesen, nicht 
wie bei RAID 5 gleich alle. Weshalb dieses Risiko bei RAID 5 mit der 
Gesamtanzahl der Platten ansteigt, bei 10 nicht. Aber es stimmt schon, 
dieses Risiko ist nur marginal reduziert.

Bei Verfahren mit doppelter Parität hingegen entfällt dieses Risiko 
effektiv, weil dafür 2 einander zugeordnete Sektoren verschiedener 
Disks gleichzeitig unlesbar sein müssten. Das ist extrem 
unwahrscheinlich, wenn der Verbund routinemässig kontrolliert wird 
(scrubbing).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:
> Ein wichtiger Punkt der sich bei mir in der Praxis öfters gezeigt hat
> ist die "Hochrüst-Strategie".

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.

Mann kann also beispielsweise die Kapazität eines RAID 1 Filesystem 
bestehend aus 2 2TB Disks verdoppeln, indem man eine 4TB Disk 
hinzugesellt. Nach einem rebalancing des Filesystems im Hintergrund 
führt das effektiv dazu, dass beide alten Disks auf die neue spiegeln.

Nebenbei stellen diese Filesysteme zudem eine innere Konsistenz auch 
ohne gepuffertem Writecache sicher, Metadaten wie auch Filedaten. Es 
sind bei Crash/Powerdown maximal die Daten der letzten Sekunden weg, 
ohne dass dabei die Konsistenz des Filesystems gefährdet wäre.

@Bernd: Weil NetApps WAFL ebenfalls COW (copy on write) verwendet, 
werden in deren nichtvolatilen Cache die logischen NAS-Operationen 
gepuffert. Nicht die Disk-Operationen. In einem RAID Controller sitzt 
der Cache logisch gesehen zwischen dessen CPU und den Disks, bei NetApp 
jedoch zwischen Netzwerk und CPU.

: Bearbeitet durch User
Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Beitrag #3960015 wurde von einem Moderator gelöscht.
Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> Insofern ist auch bei sequentiellen
> Zugriffen immer was schreibendes dabei, wenn auch extrem wenig.

Natürlich. Das read-modify-write Verfahren betrifft dann aber auch nur 
diese Daten, nicht den Strom.

> 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.

> 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.

> Jain, siehe oben. Ist es nicht reichlich sinnlos, für 1 Schreibzugriff
> immer noch 1 Lesezugriff machen zu müssen?

Das ist auch heute immer noch eine Frage der Kapazität. Freilich nicht 
unbedingt im Privathaushalt mit 3 Disks.

> 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.

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.

> 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.

> kann man das vergessen, es sei denn man nimmt 50-100 Platten. Dann
> wechselst man aber auch täglich eine Defekte aus.

Ich habe insgesamt mit erheblich mehr als 50-100 Disks zu tun und wenn 
die Disks nicht schon im Greisenalter sind, dann sind das einige wenige 
pro Jahr. Insgesamt. Um das mal auf ein 100-Disk NAS System zu peilen: 
Mehr als eine einstellige Anzahl Disks wird in einer Einsatzdauer von 5 
Jahren nicht ausfallen, wenn keine Gurkenserie dabei war.

> 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 
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.

> Deine Aussage würde ich umkehren wollen: Die verwenden eben kein RAID5,
> sondern gerade RAID6, siehe Vorpost / Ausfallwahrscheinlichkeit.

Sicher. Nur bezog sich deine Argumentation auf die Performance, und da 
ist RAID 6 nun wirklich nicht besser als RAID 5. Zur 
Ausfallwahrscheinlichkeit hatte ich mich selbst schon in gleicher Weise 
geäussert.

> 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.

> 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.

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).

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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> Frage: Hast du/irgendjemand btrfs schon mal irgendwo produktiv
> eingesetzt, als RAID6/RAID10?

Bisher ist in BTRFS derzeit nur RAID 1 möglich und das habe ich grad 
recht frisch privat auf meinem Serverlein drauf. Höhere Levels sind erst 
in Vorbereitung und Langzeiterfahrung gibts erst nach Langzeit.

Basis ist wheezy mit Backports als Quelle vom btrfs (Kernel/Utils).

> 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.

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

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

> 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
/sbin/btrfs filesystem show
/sbin/btrfs device stats /dev/disk/by-id/ata-HGST_xxxxxxxxxxxxx
/sbin/btrfs device stats /dev/disk/by-id/ata-HGST_yyyyyyyyyyyyy  
liefert mir
Label: 'btrfs1'  uuid: zzzzzzzzzzz
  Total devices 2 FS bytes used 761.50GiB
  devid    1 size 3.64TiB used 768.28GiB path /dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy
  devid    2 size 3.64TiB used 768.26GiB path /dev/sdb

Btrfs v3.14.1
[/dev/sdb].write_io_errs   0
[/dev/sdb].read_io_errs    0
[/dev/sdb].flush_io_errs   0
[/dev/sdb].corruption_errs 0
[/dev/sdb].generation_errs 0
[/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].write_io_errs   0
[/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].read_io_errs    0
[/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].flush_io_errs   0
[/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].corruption_errs 0
[/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].generation_errs 0
und monatlich wird geschrubbt:
#!/bin/sh
# scrub, foreground, readonly
/sbin/btrfs scrub start -Br /work

: Bearbeitet durch User
Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Icke ®. schrieb:

> Mit einer vorhandenen Sicherung ist das kein Risiko. Die Daten nur einem
> RAID anzuvertrauen, ist ebenso leichtsinnig, wie sie nur auf einer
> einzelnen Platte liegen zu haben. Auch wenn es ein alter Hut ist, man
> kann es nicht oft genug betonen, RAID ersetzt NICHT das Backup!

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.

Autor: Andy D. (rackandboneman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Diese RAIDs sind also nach Powerdown/Crash nicht im Eimer, sondern 
bloss langsamer als welche mit nichtvolatilem Cache."

Solang niemand den Fehler macht die Festplatten zu zwingen ihren eigenen 
Cache zusätzlich ins Spiel zu bringen. Einmal gibt es da manche Modelle 
die ihren eigenen Cache in umsortierter Reihenfolge schreiben und bei 
plötzlicher Abschaltung einen unberechenbaren Zustand behalten (und 
genau dies kann Journalling-Systeme böse aushebeln weil ggf Daten- aber 
nicht Journaleintrag so verloren gehen können oder andersherum - das ist 
schon ohne RAID gefährlich genug) und zweitens kann der RAID-Controller 
sich dann nicht mehr darauf verlassen dass von einem Satz 
zusammengehöriger Writes den er an mehrere Platten geschickt hat 
entweder alle oder keine dann auch ausgeführt wurden.


Die bezahlbare Backuplösung ist dann eben ein aus günstigeren 
Komponenten und räumlich abgetrennt aufgebaute RAID5-Anlage, im 
Zusammenhang mit Datenkompression und einem Übertragungsmechanismus der 
Löschungen nicht unmittelbar weitergibt.

: Bearbeitet durch User
Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> 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

Und ob es kleine gibt. Nämlich die üblichen SAS Disks in 2,5". ;-)
Die haben 600/900GB statt 4/6TB. Da kommt schnell was zusammen.

> Ich glaube sowieso, dass wir hier Äpfel mit Birnen vergleichen.

Bisschen schon, ja. Es fing damit an, dass mal wieder das hohe Lied auf 
die Hardware-RAIDs angestimmt wurde. Nur findet man die zwar mit gutem 
Grund in Servern, aber nicht unbedingt in der dedizierten NAS-Box, auch 
nicht der besseren, wenn die nicht grad aus einem Standard-Server 
zusammengeschraubt wurde. NetApp war da nur ein Beispiel. Bernd wollte 
das nicht glauben (hatte aber wohl noch keines selber gesehen) und da 
ging dann eben der Zirkus los.

> dann schon unter "lieber goldene oder platin Handtuchhalter".

Es geht da nicht um Luxus, sondern sondern um Verfügbarkeit. Funktionen 
wie transparenter Failover ohne manuellem Eingriff können ziemlich 
wichtig sein. Auch wenn man stets hofft, dass man es nie braucht.

> 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.

Es geht bei den Konsistenzgarantien eher um Sekunden als Stunden.

> Da hat das NetApp-NAS alleine vermutlich schon genug RAM, um das
> Working-Set zu cachen,

Die sind da ziemlich geizig. Oder vielleicht wir, weils für die goldenen 
Handtuchhalter nicht reichte und nur Messing drin war, es also ein 
"kleines" System sein musste. Die stecken nämlich nicht rein was rein 
geht, sondern deutlich weniger, um die Systeme besser zu differenzieren. 
Mit mehr Speicher und schnellerem Prozessor kostet das Gesamtpaket aus 
Hard- und Software plötzlich sehr viel mehr.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> ... also nix out-of-the-box, sondern selbstgemacht?

Zwangsläufig. Das btrfs im wheezy selbst ist schon recht alt, weshalb 
ich auf Backports auswich. Da kann man DAU-mässige Integration nicht 
erwarten. Wie das bei anderen Distros aussieht weiss ich nicht.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> Genau das sollte ja mit btrfs-snapshots nicht passieren.

Allein schon weil du fsck bei btrfs nicht benutzen willst. Das kam erst 
sehr spät und steht im Ruf, mehr zu schaden als zu nützen. Das FS ist 
eigentlich so designed, dass man es nicht braucht.

Und ja, diese COW Filesysteme sind naturbedingt recht fix beim 
snapshotten. Das liegt eben in der Natur des COW Verfahrens. Dafür 
meckern dann wieder welche über Fragmentierung, aber das ist auch wieder 
die Sache mit dem Wasser und dem Pelz.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> 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.

Kommt drauf an, was man als Informationsbasis nimmt. Nach Timestamp zu 
suchen ist nicht so langsam. Unoptimierter Einzelvergleich der Fileinfo 
über Netz hingegen schon.

: Bearbeitet durch User
Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> Wobei, wenn man Dateisysteme mit Millionen kleiner Dateien
> hat, wird das inkrementelle Backup ganz schnell extrem langsam.

Manche Backupverfahren klinken sich auch ins System ein um live eine DB 
geänderter Files zu protokollieren. Kostet live etwas Last, dafür geht 
der Backup sehr fix.

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> 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.

FreeNAS ist keine BSD Distro, sondern eine Blackbox. Du kriegst von dem 
BSD darunter nichts zu zu sehen. Sondern kriegst eine Weboberfläche für 
die Verwaltung vom NAS. Ähnlich Qnap/Synology.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
>> 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?

Da wäre beispielsweise Robocopy (Windows). Da wird hübsch einzeln für 
jedes Quellfile verglichen, ob es im Ziel schon vorhanden ist, und wie 
alt/gross/... Über Netz ist das Höchststrafe, weil bei viel 
unverändertem Kleinkram latenzbetont.

Besser wäre das, was ich grad schrieb, mit der Änderungs-DB.

Besser wäre auch der DOS Klassiker, der auch heute noch in Windows zu 
finden ist, nämlich das Backup-Flag. Gibt keinen 1:1 Stand, weil 
Löschungen nicht erkannt werden, ist aber schnell. Wenn man wöchentlich 
ein vollständigeres Verfahren nachzieht kann das ok sein.

Besser ist auch eine Abhängigkeit von der Timestamp. Wie beim 
Backup-Flag auch muss dazu nur das lokale Filesystem gescannt werden, 
und das geht sehr viel schneller als irgendwelche Netzaktivität.

Es gibt noch mehr in der Richtung. Beispielsweise liesse sich die lokale 
Fileinfo in grösseren Bündeln sammeln um diese en bloc der Gegenstelle 
zukommen zu lassen, die es dann mit ihrem Datenbestand vergleicht. Ich 
meine mich zu erinnern, dass rsync ungefähr so arbeitet.

: Bearbeitet durch User
Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL schrieb:
> Ok, danke. Das mit der Änderungs-DB im Dateisystem ist interessant, hab
> ich so noch nirgendwo gesehen.

IBM Tivoli Storage Manager, als Option. Da landen wir aber wieder in der 
Abteilung für Grossspielzeug. ;-)

> 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.

Das ist auch das TSM Standardverfahren, nur ist die DB zentral. Das 
Performance-Problem ist hier die zentrale DB, wenns um unmässig viele 
Files geht.

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

Tja, wie NetApp das intern macht weiss ich auch nicht. Schnell genug ist 
es. Letztlich synced sich das Primärsystem inkrementell auf ein 
Sekundärsystem (SATA Basis), das nicht bloss Platz für ein paar Tage an 
Snapshots sondern für Monate hat. Von da an gehts ab und zu komplett auf 
Band, zwecks Medienbruch und Auslagerung.

Privat verwende ich teils rsnapshot (rsync Basis) auf eine zusätzliche 
Disk. Das ist aufgrund der für jedes File angelegten Hardlinks nicht 
pfeilschnell, aber mir schnell genug. Durch die Hardlinks entsteht eine 
Versionierung analog zu Snapshots, aber auf der Backup-Disk. Stammt aus 
der Zeit vor btrfs.

: Bearbeitet durch User
Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D. I. schrieb:
> Wenn du auf 2TB Platten setzt, ersparst du dir erstmal Gefummel was die
> 2TB Grenze / Platte mit sich bringt.

Wenn Du steinalte Hardware hast, die noch eine 2TB Grenze kennt, dann 
aber schnell weg damit.
4TB ist standard und 6TB verfügbar.

Autor: LOL (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dagobert:

Neugierfrage: Was ist denn das für eine Anwendung, die ein redundantes 
Plattensystem erfordert?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> Neugierfrage: Was ist denn das für eine Anwendung, die ein redundantes
> Plattensystem erfordert?

Autor:  Dagobert (Gast)
Datum: 08.03.2011 10:42

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Snapshots kann man zwar machen, aber das Zurückspielen größerer
> Datenmengen kann Taaaaage dauern.

Es gibt unterschiedliche Formen von Fileverlusten, die völlig 
unterschiedliche Restore-Szenarien zur Folge haben.

Meist hat ein Anwender einzelne Files versemmelt oder im Putzrausch 
übertrieben. Da sind Snapshots ungemein nützlich, weil man direkt drin 
rumbrowsen, den Kram suchen und rauskopieren kann. Wer will, der kann 
das auch den Anwender direkt machen lassen.

Solche Snashots kann man mehrmals täglich machen und die fressen 
praktisch keine Leistung. Ein paar Mail von letzter Woche gesucht? 
Exchange-Datastore vom Snapshot mounten und da rausfischen. Das dauert 
nur Minuten.

Es ist diese Sorte Snapshots, die nicht nur NetApp bietet, sondern eben 
auch ZFS und BTRFS, und die damit allmählich auch im Bereich kleiner 
Systeme schon einsetzbar sind. Windows kann das zwar auch, aber da sind 
die Nebenwirkungen deutlicher, mit COW funktioniert das besser.

Snapshots sind ein ziemlich effektiver Weg, mit den Restores des 
Tagesgeschäfts umzugehen. Backups virtueller Maschinen eingeschlossen, 
der Restore eines virtuellen Servers auf den Stand von vorgestern geht 
genauso.

Komplettrestores eines vernichteten Speichersystems sind eine völlig 
andere Baustelle, da auf dem System selbst liegende Snapshots zusammen 
mit dem System vernichtet sind. Snapshots spielen hier insofern eine 
Rolle, weil gute Snapshots atomar sind und damit der Restore eines 
gesicherten Snapshots einen zeitlich konsistenten Stand herstellt.

> 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.

Ein Komplettrestore eines zerstörten System ist ein Komplettrestore. 
Weiter gehts erst, wenn der durch ist. Ansprüche an Reihenfolge 
innerhalb des Restores kann man da nicht ernsthaft erheben. Manche 
Systeme stellen zuerst alle Directories wieder her. Das macht sich schön 
als Baum auf dem Bildschirm, der ist aber zunächst durchweg leer.

Es muss folglich darum gehen, solch ein Szenario soweit wie möglich zu 
vermeiden. Abhängig von der Art des Unternehmens kann das dann eben bis 
hin zur Spiegelung zwischen räumlich getrennten Systemen gehen, mit 
automatischer Funktionsübernahme im Problemfall. Für Unternehmen, bei 
denen der Produktionsausfall weniger Stunden schon ein grosses und sehr 
sichtbares Problem darstellt (z.B. TV-Medien), sind solche Systeme dann 
keine goldenen Wasserhähne, sondern schlicht notwendig.

Aufgrund der Kosten solcher Lösungen ist dann auch wichtig, produktive 
Daten von Archivdaten zu trennen, um den Umfang der tagesproduktiven 
Daten gering zu halten, damit auch den Aufwand der Wiederherstellung.

: Bearbeitet durch User
Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Uhu Uhuhu schrieb:
>> Neugierfrage: Was ist denn das für eine Anwendung, die ein redundantes
>> Plattensystem erfordert?
>
> Autor:  Dagobert (Gast)
> Datum: 08.03.2011 10:42

Da steht zu meiner Frage rein gar nix.

M.A. haben RAID-Systeme eigentlich nur in Umgebungen einen Sinn, die 
100% Verfügbarkeit erfordern, also Server aller Art, an denen entweder 
sehr viele Nutzer hängen, oder auf denen lebensnotwendige Anwendungen 
laufen.

Für den Heimbetrieb sind sie Spielerei, oder schlicht überflüssig und 
wenn daran mal was aus dem Ruder läuft, dann fängt der Stress erst 
richtig an, weil man natürlich den Fehlerfall, der aufgetreten ist, 
nicht im Kalkül hatte.

Geschwindigkeit ist bei der heutigen Verfügbarkeit von SSDs jedenfalls 
kein Argument mehr für ein RAID-System.

Meine Strategie ist, die Platten im Entwicklungsrechner so gut zu 
kühlen, dass sie niemals in thermischen Stress geraten und ansonsten 
regelmäßige Backups mit rdiff-backup. Bisher bin ich damit sehr gut 
gefahren.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.