Degraded Raid5 - Erst Rebuild oder erst sichern?

[Gelöschtes Mitglied 184103]

Hallo,

Ich hatte vor kurzem auf der Arbeit den Fall, dass von einem Server alle Daten auf eine Ersatz-VM kopiert werden mussten.
Die Daten liegen auf einem 6 Disks umfassenden Raid5. Datensicherungen auf Band waren vorhanden.
Es waren ca. 2,5TB an Daten in winzigen Dateien. Das Kopieren sollte isg 10 Tage dauern. Direkt die Daten auf den Zielserver per Bandrücksicherung einzuspielen war nicht möglich.

Während des Kopierens ist eine Platte ausgefallen. Würdet ihr nun den Kopiervorgang fortsetzen oder ihn abbrechen und erst den Rebuild starten?

Edit: Ersatzplatte war sofort verfügbar. Server lief produktiv weiter während der Kopieraktion, ohne dass jedoch neue Daten hinzugekommen wären, da nur lesend zugegriffen wird.
Ziel war es die Daten asap auf den neuen Server zu kriegen. Der Kopierjob lief schon ca. 4 Tage.

 

[Morpheus2200]

Kann denn der Controller kein Rebuild im Betrieb?
Bei 10 Tagen für 2.5TB ist ja hoffentlich nicht die lesende Seite das Nadelöhr, da stört dann doch ein parallel laufendes Rebuild nicht so sehr.

Du hast ja noch ein Backup auf Bändern, wenn du die Daten zügig brauchst würde ich weiter kopieren. Aber ich würde mir auch mal ansehen, warum das so lange dauert.

Wie wäre denn der Plan bei Ausfall einer Platte bei normalem Betrieb des Servers gewesen?

 

[ludwinator]

Unabhängig davon, ob die Frage jetzt geklärt ist, hoffe ich doch schwer, das nach diesem Vorfall auch die entsprechenden Maßnahmen eingeleitet werden.
Ein Backup, das sich nur auf dem Originalserver wiederherstellen lässt, ist nicht wirklich eins.
Eine Kopieraktion, die im Notfall mehrere Tage dauert, ist ja wohl ebenfalls nicht akzeptabel.

cu

 

[Gelöschtes Mitglied 184103]

Der Server ist ca. 8 Jahre alt und eine physikalische Maschine mit eigenem Bandlaufwerk.
Dass es so lange mit dem Kopieren dauerte, wunderte mich ob des Alters erstmal nicht (2,5 MB/s).
Der Raid Controller kann den Rebuild im laufenden Betrieb.
Ich wollte den Platten nicht die dreifache Last zumuten Kopieren, Rebuild und produktiver Betrieb. Daher habe ich den Rebuild abgewartet und danach das Kopieren fortgesetzt. Ging zum Glück gut, so dass wir nicht noch das Raid neu machen, vom Band restoren und dann erneut Kopieren mussten.
Test des Backups oder Notfallplan existieren nicht. Hier greift das Prinzip Hoffnung.

Die komplette IT wird aufgrund des großen Erfolges am Standort aufgelöst.
Der Server wird virtualisiert in ein neues Rechenzentrum wandern und dort täglich mit Backup-To-Disk gesichert.

 

[Morpheus2200]

Naja 2.5MB/s lesend ist auch bei 8 Jahre alter Hardware extrem langsam. Die liegen ja immerhin auf Platten im Raid und nicht auf einem USB Stick.
Wird an den vielen kleinen Files liegen nehme ich mal an. Welches Dateisystem wurde denn genutzt? Und wie habt ihr kopiert.
Wie habt ihr denn damit in halbwegs tolerabler Zeit ein Tape Backup von 2.5TB hinbekommen? Und auf was für Bändern oder ist das Laufwerk jünger als 8 Jahre?

Naja wer 8 Jahre alte Systeme produktiv ohne getestetes Backup nutzt hat da wohl seine Gründe für (meist kein Geld).
Wer es aus Bequemlichkeit oder sonstigen Gründen einfch ignoriert dem gönne ich auch die 10 Tage hoffen das nichts passiert. Oft sind solche Erfahrungen ja dann doch lehrreich und man schätzt den Wert einer guten Bakup Lösung.

 

[Gelöschtes Mitglied 184103]

Kombiniere Öffentliche Einrichtung mit Ignoranz.
Ob das Backup überhaupt lief weiß auch kein Mensch. Es kam ein Band jeden Morgen raus und das wurde gewechselt.

edit: Filesystem ist NTFS auf 2003 Server, Kopieren auf 2008 R2 mittels Robocopy.
Schuld werden sicherlich die vielen kleinen Dateien sein und ich meine mich erinnern zu können, dass das 2008 R2 robocopy auch nicht gerade fix ist.

 

[passat3233]

Oje, Robocopy...........
Das habe ich einmal ausprobiert und es war so extrem lahm........
Das Kopieren über den Windows-Explorer war bei dem Test mit den gleichen Dateien um Faktor 10-20 schneller, ebenso xcopy.

Robocopy ist seitdem bei mir gestorben.

 

[Gelöschtes Mitglied 184103]

Interessanterweise ist die 2003er Version bei mir in Tests deutlich fixer gewesen. Hatte damals mal das Binary vom 2003 Server auf den 2008er kopiert und damit getestet. Gleiche Optionen etc. ging sehr viel schneller.

Edit: es gibt auch einen Hotfix für das Robocopy unter 2008, der bei mir aber genau nix gebracht hat.

 

[RonnyE]

Das Problem sind die winzigen Dateien.... da sind 2,5 MB/s schon ganz "ok". Man darf nicht vergessen, dass man hier im Bereich des wahlfreien Zugriffs ist (weil die Datei vermutlich nur 1-2 Blöcke auf der Platte belegt). Pro Datei muss die Stelle auf der Platte im NTFS-Index lokalisiert werden, dann auf die Blöcke, die die Datei enthalten zugegriffen werden. Für extrem kleine Dateien ist dieser Overhead sehr hoch - und damit entsprechend langsam. Das ist ein klassisches Problem bei dateibasierter Sicherung.

Wenn du das ändern willst musst du die Festplatte als Blockspeicher sichern, entweder mittels z.B. dd oder indem du die Files in eine virtuelle Platte packst - dann hast du als Resultat eine große Datei, die du mit voller Streaminggeschwindigkeit sichern kannst. Als Nachteil hast du dann, dass du für das Recovery einer einzelnen Datei meist die ganze Platte wiederherstellen musst...

Willst du die Daten nur kopieren mach es mittels "dd"... von einer Platte (oder RAID) auf ein anderes...

 

[Morpheus2200]

Viele kleine Dateien sind immer nervig. Aber 10 Tage sind schon extrem.
Unser inkrementelles Backup liest täglich ca. 20 mio. files verteilt auf 6TB in ca. 12h. Da werden dann natürlich nur die geänderten auch übertragen.
Ich würde die Ursache für die lange Dauer eher bei der Software suchen.

 

[fdsonne]

Viele kleine Dateien sind immer nervig. Aber 10 Tage sind schon extrem.
Unser inkrementelles Backup liest täglich ca. 20 mio. files verteilt auf 6TB in ca. 12h. Da werden dann natürlich nur die geänderten auch übertragen.
Ich würde die Ursache für die lange Dauer eher bei der Software suchen.

Das ist aber dann viel eher eine Frage nach der Prüfung bzw. den Settings...
Wenn du nen Binärvergleich machst, wird das um Welten länger dauern, als wenn du simpel nur Zeitstempel vergleichst

Geht man nach deinen Werten, wären das im Schnitt 322KB pro File (20 Mio, 6TB)
Das ganze bei 12h bedeutet, dass du ca. 145MB/sec schaffst. Da ja nicht alle Daten übertragen werden beim Inkr. Backup, sondern nur die geänderten Files, heist aber 145MB/sec auch, das du pro Sekunde ca. 461 Files prüfst. (~322 KB pro File in 145MB/sec) Gehe ich davon aus, das das Prüfen einer Datei genau einen Zyklus Kopfbewegung dauert und setze dafür die Latenz einer HDD an, dann heist das, du müsstest im Schnitt alle ~2ms ein File checken um auf 461 Files die Sekunde zu kommen. 2ms erreichst du nicht mit ner 7,2k Platte Nichtmal mit ner 15k SAS Platte aktuellster Generation.
Der Vergleich hinkt also etwas Das zu erreichen bedarf definitiv mehr wie nur nem simplen Raid 5 aus sechs HDDs, wie es der TE hier zu haben scheint... Entweder mit SSDs gepaart, mit SSDs als Cache oder riesigen Memory Caches. Ggf. auch ein System, was die Daten nicht Random von den Platten holt, sondern Mechanismen in der Controller Logik, die entweder die einzelnen Platten bei Random Last verschiedene Teile lesen lassen oder das immer sequenzielle Bereiche gelesen werden und dann die Daten analysiert werden. -> letzteres glaube ich allerdings nicht, da die Kopiersoftware ja sagt, was gelesen werden muss. Unabhängig der Lage der Daten auf den HDDs.

Wenn ich den TE richtig verstehe, dann heist ca. 8 Jahre alter Server auch, das entsprechend alte HDDs da verbaut sind.
Raid 5 mit ~2,5TB Daten heist bei 6 HDDs ebenso, das wohl minimum 640GB HDDs verbaut sein müssten.
Ende 2006 (also heute abzgl. 8 Jahren) wurde gerade so die erste WD 2TB HDD vorgestellt...
Man müsste nun explizit schauen, was da für HDDs verbaut sind/waren und was zu der Zeit gerade am Markt an 10k/15k "Größen" vertreten war. Aber ich glaube kaum, das es 600GB SAS 10k/15k Platten waren. Klingt für mich eher wie schnöde 7,2k Platten mit "Serverinterface" ala SAS oder U320 SCSI, oder gar "nur" SATA.


Bei derartigen Datenmengen und vor allem auch Files heist das Zauberwort wohl paralelle Verarbeitung der Jobs. Robocopy wie viele andere Tools auch vergleichen nur in einem Stream die Files. Was auch heist, das bei nem Raidsystem wohl zwar die Blöcke von allen HDDs gelesen werden, aber nur ein Bruchteil der Daten überhaupt genutzt wird. Im Endeffekt dürfte die verarbeitete Datenmenge (bis auf die Files, die wirklich kopiert werden) unwesentlich klein sein. Man erhält wohl sozusagen nur den Speed einer Single HDD.

PS: auch ist für den TE ja interessant gewesen, dass er die Daten ja übertragen wollte/will
Sprich es werden auch alle! Files kopiert... Was das Problem nicht minder einfach macht... Bei nem Single Kopiestream heist das dann ebenso, dass im Endeffekt der Randomspeed einer einzelnen HDD für den Kopierspeed verantwortlich ist. Und das ggf. (bei 322KB und 64KB Blocksize) minimum sechs Blöcke, bei ungünstiger Verteilung im Filesystem noch viel mehr Blöcke gelesen werden müssen. Bei günstiger Verteilung auf der Platte selbst wären es zwei Kopfbewegungen. Bei ungünstiger Verteilung auf den Platten deutlich mehr.
10 Tage bei 2,5TB Daten heist ca. 3MB/sec.
Nehme ich ebenso die 322KB durchschnittliche Filegröße, wären das nach obiger Rechnung ca. 105ms. Für Random Load durchaus akzeptabel würde ich sagen... Die 20-25ms einer 7,2k HDD hat es ja auch nur ohne Last. Degraded Zustand sollte man auch nicht vernachlässigen...

PS: auch spricht er von 2003 Server, hat man da nicht aufgepasst, dann ist das Alignment bei der Partitionierung für die Tonne 2003 Server beginnt den ersten Block bei Sektor 63. Unmittelbar nach dem MBR. -> und das heist bei 4KB Clustersize des Filesystems, das minimum zwei Blöcke auf der HDD gelesen werden müssen. Im Raidbetrieb ungünstigerweise also auch zwei Blocke. Man sollte bei 2003 Server definitiv das Partition-Offset so einstellen, dass die Zahl durch 4 teilbar ist. Dann passts...

 

[Morpheus2200]

Ich sage ja auch nur das die lange dauer an der Software liegt. Was hindert das Programm daran ganze Blöcke zu lesen und dann zu prüfen ob sich mehr als eine verwertbare Datei darin befinden oder mehrere Streams parallel zu starten.

Natürlich ist der Fall bei uns nicht vergleichbar. Allein weil die Daten nicht übertragen werden. Und weil die auf 28 7.2k rpm HDDs liegen mit etwas fortschrittlicherem Dateisystem als NTFS.
Aber 2.5MB/s lesened im Durchschnitt ist auch für 8 Jahre alte Hardware wenig. Das würde ich bei vielen kleinen Files auf einer 8 Jahre alten USB HD erwarten aber RAID 5 controller waren damals doch meist mit cache und eigener logik.

 

[fdsonne]

Ich sage ja auch nur das die lange dauer an der Software liegt. Was hindert das Programm daran ganze Blöcke zu lesen und dann zu prüfen ob sich mehr als eine verwertbare Datei darin befinden oder mehrere Streams parallel zu starten.

Das ist wohl die Unmöglichkeit bei der Sache Je nach verwendetem Filesystem, OS und der Hardware hast du dort mehrere übereinander liegende Layer.
Im Falle des TEs bei nem simplen physisch installiertem 2003 Server hast du faktisch den Filesystemlayer, den Layer des logischen Volumes des Raids und den Hardware Layer der Platten.
Heist also, kommt die Software und sagt, ich brauche File xyz, geht die damit zum OS und holt die Infos, auf welchen Adressen diese Infos auf dem logischen Layer des Volumes liegen. Diese Info geht dann an den Raidcontroller und der geht zu den Platten und holt die Infos von den Platten. Dann wandern die Daten zurück und das Programm erhält die Daten für die angeforderte Datei.
Das Programm kann aber nicht hingehen und sagen, hol mir die Infos von der physischen Adresse xyz + 4096 Sektoren. Denn dadrin kann alles und nix stehen... Es kennt die Zuordnung einfach nicht. Physischer Layer zu logischem Volume Layer kennt der Raidcontroller. Und logischer Volume Layer zu Filesystemlayer kennt das OS. Und oben drauf kennt nur die Software selbst die Zuordnung von File in Source zu File in Destination.
Zumal die Fragmentierung der Files, gerade bei nem Fileserver extrem sein kann! Vor allem dann, wenn das OS keine Routinen bietet, diese Framentierung zyklisch auszubessern... Und 2003 Server kann das meine ich nicht automatisch. Oder besser, macht es nicht von Haus aus.

Was mehrere Streams gleichzeitig angeht, ja das geht potentiell. Die meisten Tools, die ich dabei aber kenne nutzen gleichzeitige Streams bestenfalls für den reinen Copyjob. Der Check, ob die Files kopiert werden müssen hingegen ist idR sequenziell. -> und das kostet unmengen an Zeit, gerade bei Millionen mini Files...

Natürlich ist der Fall bei uns nicht vergleichbar. Allein weil die Daten nicht übertragen werden. Und weil die auf 28 7.2k rpm HDDs liegen mit etwas fortschrittlicherem Dateisystem als NTFS.
Aber 2.5MB/s lesened im Durchschnitt ist auch für 8 Jahre alte Hardware wenig. Das würde ich bei vielen kleinen Files auf einer 8 Jahre alten USB HD erwarten aber RAID 5 controller waren damals doch meist mit cache und eigener logik.

Wie gesagt, 2,5-3MB/sec sind schon realistisch... Da brauch es nichtmal ne alte USB HDD.
Du kannst ja mal selbst den Test machen. Schnapp dir ne alte HDD und viele kleinst Files. Bspw. eine komplette Windows Installation, also den Windows Ordner ansich. Diese syncst du mal einfach, bestenfalls über ein Stück Netzwerk auf eine andere Stelle. Das sind zwar in Summe nur ein paar tausend Files, aber kein Vergleich dazu, als hättest du die selbe Größe mit sagen wir Files im 1-2 MB Größendurchschnitt getätigt. Oder gar mit großen ISOs von mehreren 100MB pro File.

Übrigens, nicht zu vernachlässigen ist auch der Part, das meist Quelle oder Ziel bei so einer Aktion über eine Freigabe im LAN angesprochen wird.
Einfacher Test, mal ein "DIR /S" im lokalen Windows Ordner machen. Und dann im Vergleich dazu das gleiche über eine SMB Freigabe tätigen. -> Zeitunterschied ist exorbitant. Da nutzen selbst für den SMB Test keine SSDs was. Es ist einfach um Welten langsamer.
Auch sehr viel Zeit kann man sich sparen, wenn man die grafische Ausgabe völlig deaktiviert. Gerade bei Kommandozeilentools... Denn das CMD Fensterchen ist grotten lahm... Ein "DIR /S" im lokalen Windows Ordner mit Ausgabe im Fenster dauert je nach Anzahl der Files mehrere Minuten. Ein "DIR /S > xxx.yyy" mit Umleitung der Augabe in eine Datei dauert nur wenige Sekunden.


Heist unterm Strich, nicht ausschließlich das Tool ist schuld, wenn auch sicher der Einfluss recht groß ist. Sondern die Hardware/eingesetzte Technik und vor allem auch das Händling der Tools ist maßgeblich am Speed beteiligt...

 

[Morpheus2200]

Win2K3 Server nutzt noch eine alte CIFS version oder? Die performance für Netzwerkfreigaben unter Windows vor CIFS v2 ist wirklich erschreckend schlecht.
Aber bevor ich da 10 Tage warte schiebe ich die Daten halt zur Not über ein andere Protokoll wie FTP oder auf exterene Medien oder sowas.

Zeitverlust durch "richtiges tool falsch eingesetzt" kenne ich auch ganz gut. Gerade bei vielen kleinen files.
Aber bevor ich 10 Tage warte denke ich lieber mal eine halbe Stunde nach.

Die Abstraktionsschichten beim Zugriff auf das Dateisystem gibt es, aber es gibt auch sowas wie read ahead cache. Das kann ein kleines bisschen helfen bei vielen kleinen Files.

 

[fdsonne]

Win2K3 Server nutzt noch eine alte CIFS version oder? Die performance für Netzwerkfreigaben unter Windows vor CIFS v2 ist wirklich erschreckend schlecht.
Aber bevor ich da 10 Tage warte schiebe ich die Daten halt zur Not über ein andere Protokoll wie FTP oder auf exterene Medien oder sowas.

Jupp, ist noch v1 wenn ich das richtig sehe. Bis 2008 R2 dann v2 und ab 2012 dann v3...
Ich muss aber ehrlich sagen, dass ich auch mit 2003 Server vollen 1GBit Speed via LAN bekomme, wenn das Storage passt (auf beiden Seiten) Mit nem RAM Drive auf beiden Seiten hast du faktisch auch keine Probleme mit dem Random Access

Die Abstraktionsschichten beim Zugriff auf das Dateisystem gibt es, aber es gibt auch sowas wie read ahead cache. Das kann ein kleines bisschen helfen bei vielen kleinen Files.

Das ist natürlich richtig... Aber wie oben erwähnt, bei nem Fileserver, der vor allem, wenn der Datenbestand historisch gewachsen ist, also nicht irgendwann mal da am Stück draufgekippt wurde, hat den eklatanten Nachteil, dass eben die Files wild durcheinander und ggf. stark fragmentiert auf dem physischen Volume liegen.
Read Ahead bewirkt, dass mehr Daten von den Disks gelesen werden und im Cache gehalten werden -> zur eventuell späteren Verwendung. Nur muss das natürlich auch passieren. Wenn man verschiedenste Datenblöcke (Der Controller kennt ja die File zu Datenblockzuweisung nicht, das obliegt dem Filesystem!) wild durcheinander vor den Plattenbereichen holt, dann werden wohl 99% der gelesenen Daten einfach nicht angefordert werden. Ergo kein Vorteil.
Der Speedvorteil entsteht dann, wenn die Daten benötigt werden... Also angenommen, das File liegt irgendwie am Stück auf dem Storage, das Tool ließt erst den Fileheader, stellt fest, jetzt brauch ich die Daten des Files und holte diese dann direkt aus dem Cache... Um so mehr Random Access, desto weniger wird Read Ahead einen Speedvorteil bringen. Vor allem dann nicht, wenn der Cache sehr klein ist und die mal gelesenen Daten nicht schnell genug abgerufen werden, weil andere Blöcke sich anschicken im Cache auf Abruf zu warten


Was ggf. was bringen könnte, man könnte versuchen das Volume Serverseitig zu defragmentieren um die Fragmentierung zu minimieren und somit den Random Access Anteil runter zu schrauben... Je nach Grad der Fragmentierung bringt das enorme Zeitvorteile.
Oder was ggf. noch viel mehr bringt, ist das Copyverfahren zu ändern... Bspw. bei nem nicht Systemvolume des Fileservers wäre es denkbar ein Backup via Imagesoftware zu ziehen. Bestenfalls noch der Imagesoftware zu sagen, hole die Daten 1:1 -> dann gibts sequenziellen Access. Wäre es das Systemvolume, müsste man die Hütte halt booten und via Bootmedium das Image ziehen...
Das Image kann man dann idR bequem auf dem Zielsystem wieder ausrollern... Was dann ebenso sequenziell passieren würde, da Blockweise eben 1:1.
Ob das allerdings sinnvoll wäre, steht auf nem anderen Blatt. Das Partition Offset sollte definitiv angepasst werden! Zumindest für den neuen Filer. Ich würde dieses Vorgehen aber nicht im Image machen... Und auch nicht unbedingt im Nachgang bei der Partition. Heist also, Daten müssen nochmal händisch übertragen werden. Und man benötigt entsprechend auch halbwegs schnellen Speicher mit genügend Platz (Imageziel und die Kopie) für diese Methode.