Raid Rebuild zu langsam ..

[Shadowblues]

Sodelle .. zweite Platte ist durch ... wieso auch immer viel schneller.

D.h. Platte am Freitag bekommen, erstmal als Single Platte mit Datenträgerprüfung getestet und dann am Samstag um 11 ins Raid konfiguriert, Rebuild am Dienstag Morgen 7 Uhr beendet ..

Das waren also keine 72h für den Rebuild. Wieder war das System nicht ressourcentechnisch am Rand, hätte also schneller gehen können. Aber 3 Tage sind grade noch zu verkraften ..

Unklar ist der Unterschied der Rebuild Times.

Der Support hat sich auch gemeldet. Nachdem ich detailliert beschreiben hatte was vorgeht, wie die Auslastung ist usw. und detaillierte Fragen gestellt hatte kam die lapidare Antwort: "Dauert halt manchmal länger". Auf erneute Nachfrage von mir wieder keine Antwort ...

Also das nächste NAS wird wohl nicht Synology lauten .. mal schauen ..

Gruß
Roger

 

[Puppetmaster]

Oder einfach keine Archive HDDs mehr nutzen ...

 

[Shadowblues]

Sorry, das ist Quatsch .. wenn ich das mal so sagen darf ...

Die Archive HDDS sind hier nur im Lesemodus gefragt, das darf also die Performance des Rebuilds nicht verringern.

Wenn ein Raid ausgefallen ist, dann muss es möglich sein das sehr schnell wieder in einen sicheren Betriebszustand zu überführen. Wieso dann hier mit so niedrigen Werten gearbeitet wird und wieso nicht alle verfügbare Performance aus dem System für den Rebuild herausgeholt wird, ist unklar. Ich arbeite hier jeden Tag mit vernünftigen Systemen, da kann man dem Raid-controller durchaus mitgegeben mit welcher Priorität / Performance er sich um den Rebuild kümmern soll. Ok, die Systeme kosten mindestens 10x so viel wie eine 1815, nach oben fast unbegrenzt offen, aber trotzdem ist die Implementierung schwach. Synology achtet in letzter Zeit zu sehr auf Features statt auf ein stabiles performantes System ...

Um das Argument mit den Archiv-HDDs gelten lassen zu können, müsste es nach dem Austausch der letzten Archiv-HDD viel schneller gehen. Wir werden sehen ... 2 weitere 8TB NAS Platten sind im Zulauf ...

Gruß
Roger

 

[Puppetmaster]

Genau, mach doch erstmal zu Ende, und dann fällst du ein Urteil.

Nutzt du bei deinen "vernünftigen Systemen" denn auch Archive Platten mit SMR? Hast du dort auch ein Software-Raid?

Du beruteilst hier halbe Birnen indem du sie mit ganzen Äpfeln vergleichst, sorry ...

 

[dil88]

Die Idee, die Speed des Rebuilds im DSM konfigurieren zu können, finde ich prinzipiell gut, sie müsste aber als Feature-Request an Synology herangetragen werden, um die Chance auf Umsetzung zu bekommen.

Wenn auf einem System während des Rebuilds gearbeitet werden muss - und dafür erhöht man ja die Verfügbarkeit -, dann macht es Sinn, dafür ausreichend Performance zu erhalten.

Da bei einem RAID-Rebuild auf alle Platten geschrieben wird, wirkt sich das SMR der Archive-Serie enorm auf die Laufzeit aus (Edit: Dies ist falsch).

 

[Shadowblues]

Hallo,

nein, ich habe da natürlich keine SMR Platten drin, den fehler gebe ich ja auch zu. Aber dass man den Rebuild mit einer Priorität versehen könnte und die ganze Leistung des Systems nutzen könnte - auch bei einem Software-Raid - das kannst Du kaum abstreiten ...

Anleitungen dazu gibts ja genug im Netz

Gruß
Roger

 

[Puppetmaster]

Ich sag nicht, dass es da nicht womöglich Schräubchen geben kann, an denen man drehen kann. Du stellst es nur so dar, als hättest du da ein ootb unglaublich träges und schlecht konfiguriertes System. Dem ist aber nicht so, denn du hast es mit deinen SMR Platten erst dazu gemacht. Und sowohl Plattenhersteller und auch NAS-Hersteller raten u.a. aus genau diesem Grund vom Einsatz von SMR Platten in einer NAS ab.

Warum sie das tun hast du meiner Meinung nach sehr schön in deinem Thread dargestellt.

Grundlegende Eigenschaften einer SMR-Platte wirst du damit aber auch nicht aushebeln können. Die Platte ist so träge, das liegt dann eben nicht unbedingt an der DS.

 

[Shadowblues]

Jetzt erhellt mich mal bitte:

Wieso hat SMR einen Einfluss auf den Rebuild? Nach meiner Kenntnis wird bei einem Rebuild die getauschte Platte beschrieben, vom Rest nur gelesen. Wieso schreibt ihr, dass alle Platten geschrieben werden? Habt ihr hierzu eine Referenz?

Gruß
Roger

 

[mb01]

Mit "richtigen" Platten (8TB PMR) macht meine DS415+ einen Raid5-Rebuild in einem dreiviertel Tag, IIRC. Per Konsole lässt sich der Rebuild mit ein paar schnellen Standardbefehlen auch noch etwas beschleunigen, sodass fast der volle Plattenspeed erreicht wird und auch die Auslastung sehr hoch ist.

Eine Seagate Archive kann man im NAS-Umfeld (IMHO) einzig als "externes" Laufwerk für Sicherungen verwenden bzw. dort, wo Geschwindigkeit keine Rolle spielt.

 

[frankyst72]

hätte also schneller gehen können

ich kann mir nicht vorstellen, dass Synology irgendwelche Warteschleifen eingebaut hat, wozu?. Wenn die Platte den nächsten Befehl abarbeiten kann, dann wird sie das tun. Wenn sie noch nicht soweit ist, wird sie das signalisieren. Und nicht alles bekommst Du im Ressourcen-Manager angezeigt,

 

[Shadowblues]

Naja, Franky,

klar hat Synology da keine Warteschleifen eingebaut .. da die sich ja hier auf die Linux Funktion verlassen haben die da gar nichts selber gemacht. Synology gibt hierbei Limits an, welche dann genutzt werden. Diese Limits sind sehr niedrig gewählt, so dass das auf derselben Platte als Raid laufende Systemvolume auch noch etwas abbekommt und hier kein Ressourcenengpass dem System Probleme macht. Wenn ich das richtig verstehe, so sind dieses Defaultwerte, welche nicht an das jeweilige System angepasst sind. Ein schnelles 1815er System hat also wohl die gleichen Defaultwerte wie mein kleineres 413er System. Ja, das ist einfach, aber eben nicht sexy. Ein dynamisches Rebalancing unter dem Gesichtspunkt der Auslastung des Systems, das wäre sexy ...

Dazu muesste man jedoch regelmaessig alle potentiellen Engpaesse des Systems (Auslastung der einzelnen Platten, CPU, RAM) betrachten und hier entsprechend eingreifen ...

Aber all das beantwortet noch nicht die Frage wieso ein Raid 5 Rebuild bei SMR langsamer sein soll ...

Gruß
Roger

 

[Puppetmaster]

Aber all das beantwortet noch nicht die Frage wieso ein Raid 5 Rebuild bei SMR langsamer sein soll ...

Nein, das tut es nicht, aber du hast es ja gezeigt, dass es so ist. Oder bei dir, deiner DS, kamen/kommen noch andere, uns unbekannte Faktoren hinzu.
Ein Rebuild dauert im Allgemeinen eben nicht so lange, wüsste jetzt hier auch keine Berichte aus dem Forum, dass dem so ist. Es gibt allenfalls Probleme, wenn defekte Platten dabei sind und der ganze Prozess hängt - oder eben wie jetzt SMR im Spiel ist.

Ich möchte hier nichts erklären, warum und wieso das so ist. Für mich ist dein Thread einfach die Bestätigung dessen, dass SMR in einer DS einfach keine gute Idee ist.
Ich selbst habe noch eine DS112, die ich mit einer 6TB SMR Platte bestückt habe. Beim reinen Lesen ist die Platte noch ok, aber kommt auch nur ein bisschen Logging dazu, dann ist das einfach nicht mehr performant und spürbar träge.

 

[dil88]

@Roger: Du hast aber recht, dass von den intakten Platten gelesen und auf die getauschte Platte geschrieben wird. Der letzte Satz in Beitrag 25 ist Quatsch, ich war gedanklich bei einem normalen Schreibvorgang.

 

[Shadowblues]

Gut, danke .. dachte schon ich bin da ganz falsch ... Schreibzugriffe hätte ich auch nur bei einer Erweiterung gesehen, da wird ja alles auf links gezogen ...

Ich werde das jetzt mal beobachten wie sich die weiteren Plattenwechsel verhalten..

Auf jeden Fall ist eine aktuell laufende Neuformatierung der SMR Platte auch arg lahm .. und das ist kein Raid

 

[frankyst72]

@Puppetmaster

Für mich ist dein Thread einfach die Bestätigung dessen, dass SMR in einer DS einfach keine gute Idee ist.
Ich selbst habe noch eine DS112, die ich mit einer 6TB SMR Platte bestückt habe. Beim reinen Lesen ist die Platte noch ok, aber kommt auch nur ein bisschen Logging dazu, dann ist das einfach nicht mehr performant und spürbar träge.

ich hatte mit dem Gedanken gespielt, zusätzlich zu meinem RAID5 aus 3 x 4TB WD Red, meine 8TB SMR als "Basis" einzubinden und dort meine Filme zu lagern (billiger einfacher Storage). Würdest Du davon abraten, wegen den gespiegelten Systempartitionen, weil Schreibvorgänge auf diesen Auswirkungen auf die ganze DS-Performance haben?

 

[Puppetmaster]

Damit habe ich so gesehen keine Erfahrung. Heißt konkret, ich kann nicht einschätzen wie sich die Performance bei mehr als einer Platte in der DS auf die SMR Platte auswirkt.
Für den reinen Lesebetrieb bei nur einer verbauten Platte ist das jedenfalls ok.

Da kann dann vielleicht auch eher @Shadowblues eine Einschätzung geben, der hat ja auch RAID aus diesen Platten betrieben. Das sollte ja keinesfalls besser laufen, als es eine zusätzlich Basis-Platte tun würde.

 

[Shadowblues]

Also ich sehe bei der reinen Systempartition keinen grossen Performanceimpact der SMR Platten - viel wird ja in so einem System nicht geschrieben.

Per USB Einbinden ist aber in diesem Fall besser, da dort weder SYSTEM noch SWAP draufliegen.

Gruß
Roger

 

[Shadowblues]

Sodelle .. mal wieder ein paar Informationen:

1. Alles zurück zum Start ... keine Ahnung was das Teil so macht, aber es ist folgendes passiert: Ich war am Wochenende nicht da und habe daher meinen Grossen die Platten tauschen lassen. ich sagte: Platte 3 - er nahm Platte 2. Naja, das war genau die Platte, welche ich davor schonmal getauscht hatte .. Mir ist das beim Remote Rebuild Start nicht aufgefallen .. Selber doof .. Auf jeden Fall hat also der erste Rebuild der Platte 2 nun 7 Tage gebraucht (NAS-Platte), der zweite Rebuild (Desktop-Platte) unter 3 Tagen .. Ich koennt mich in den Ar.... beissen ... OK, nun läuft Platte 3 ...
Aufgefallen ist das, als ich die Archive HDD nach dem Reformat ausbauen wollte und da "IronWolf" draufstand ...

2. Jetzt weiss ich wieso er zweimal den Rebuild macht: Man muesste sich nur mal auf die Kommandozeile schalten, dann wirds offensichtlich: Bei der Erweiterung des Raids hat er irgendwann mal den oberen Teil der Platten als zweites Raid angelegt. Daher zählt er jetzt zweimal durch .. Liebe Synology: Wenn man schon ein SHR baut und das zusammenstückelt, dann gebt doch in der GUI wenigstens eine konsistente Anzeige aus .. . Für mich als User ist das ein Volume - also erwarte ich einen Counter von 0 bis 100% .. und nicht 2 oder 3 ..

Also aktuell gibt er eine ETA von 320 Minuten an für den ersten Raidpart .. 102K/Sec sind 5800 Millionen Blocks von ca, 23000 Millionen Blocks ..

Jetzt drehen wir mal n bissl an den Werten ,,,

EDIT: Glücklicherweise davor nochmal auf den Performance Counter geschaut. Beim ersten Rebuild war da noch massig Luft. Jetzt ist aber die SHR Platte im Read bei 100% - also ganz klar der limitierende Faktor. Ok, aber mit 5200RPM war das ja irgendwie klar. So sieht es auch fein aus ... 120K Rate und klare Limits im PerfMon erkennbar ... so ists gut Interessant ist jetzt aber, dass die Desktopplatte bei ca. 90% liegt, die NAS Platte bei ca. 55% und die SMR Platte bei 100%. Demnach wird die Desktop Platte der nächste Engpass ... die fliegt wohl doch noch raus ,,,

Gruß
Roger

 

[Shadowblues]

Hier mal mein Performance Graph. Was macht das Teil eigentlich nachts mit den SSDs?
Wie man sieht, war die SMR HDD im ganzen Rebuild zu 90-100% belastet (Platte 4), die Desktop HDD ST8000DM002 in der ganzen Zeit bei 80% (Disk 2). Die NAS HDD (ST8000VN0022 - Disk 3) war beim ersten Rebuild nur zu 60% belastet, bei Rebuild der zweiten Partition war die Auslastung jedoch weit höher - analog der Desktop-HDD. Kann das jemand erklären?

Edit: Dieser Rebuild war nun nach 18h beendet ... das mach ich noch n paarmal und bin dann in n paar Minuten durch .. Haette ich gewusst, dass das so schnell geht, hätte ich die nächste Platte gleich vorbereitet ... aber ich dachte das braucht wieder Tage ...

 

[Shadowblues]

Sodelle, jetzt kam doch nochmal Antwort vom Support:

Keine SMR Platten nutzen (Jaja .. )

Interessant finde ich die Aussage, dass bei einem Raid Rebuild alle Platten beschrieben werden. Das kannte ich bis jetzt von der Theorie nicht so. Wieso ist das so? Kann mir das jemand erklären?

Gruß
Roger