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?
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.
oszi40 schrieb: > 1.Kurz: Raid 10 ist Raid5 gespiegelt. Nein. RAID 10 ist RAID 1+0, d.h. gespiegelt und gestriped.
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
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.
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.
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).
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.
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
Iwan, ein Rebuild bei der Plattengröße 2TB könnte auch einige Tage brauchen je nach Systemauslastung...
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?
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.
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.
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 ...
... 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.
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.
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.
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.
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.
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.
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 ...
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.
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
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
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.
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).
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
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.
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.
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
1 | #!/bin/sh
|
2 | /sbin/btrfs filesystem show |
3 | /sbin/btrfs device stats /dev/disk/by-id/ata-HGST_xxxxxxxxxxxxx |
4 | /sbin/btrfs device stats /dev/disk/by-id/ata-HGST_yyyyyyyyyyyyy |
liefert mir
1 | Label: 'btrfs1' uuid: zzzzzzzzzzz |
2 | Total devices 2 FS bytes used 761.50GiB |
3 | devid 1 size 3.64TiB used 768.28GiB path /dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy |
4 | devid 2 size 3.64TiB used 768.26GiB path /dev/sdb |
5 | |
6 | Btrfs v3.14.1 |
7 | [/dev/sdb].write_io_errs 0 |
8 | [/dev/sdb].read_io_errs 0 |
9 | [/dev/sdb].flush_io_errs 0 |
10 | [/dev/sdb].corruption_errs 0 |
11 | [/dev/sdb].generation_errs 0 |
12 | [/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].write_io_errs 0 |
13 | [/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].read_io_errs 0 |
14 | [/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].flush_io_errs 0 |
15 | [/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].corruption_errs 0 |
16 | [/dev/disk/by-id/ata-HGST_HDN724040ALE640_yyy].generation_errs 0 |
und monatlich wird geschrubbt:
1 | #!/bin/sh
|
2 | # scrub, foreground, readonly
|
3 | /sbin/btrfs scrub start -Br /work
|
:
Bearbeitet durch User
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.
"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
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: > 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
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.
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.
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. ;-)
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.
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.
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
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.
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.
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?
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.
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
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.
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
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.
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.
@Dagobert: Neugierfrage: Was ist denn das für eine Anwendung, die ein redundantes Plattensystem erfordert?
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
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.
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.