Software RAID5 läuft aus dem Sync

[ddm3ve]

Anders als im Betreff fällt mir nun nicht ein, wie ich es beschreiben könnte.
Problem:
Auf dem Server läuft ein FTP Dienst und es werden Daten übertragen.
Das Raid ist aus 4 Platten aufgebaut, insgesamt neu und unverbraucht..
Werden Daten auf das System geladen, z.B. zur Sicherung mit ca. 100 MBIT dann gerät das Raid aus dem Sync:

Code: Select all

Personalities : [raid1] [raid6] [raid5] [raid4] 
md127 : active raid5 sdc4[2] sdd4[4] sdb4[1] sda4[0]
      29285147904 blocks super 1.0 level 5, 128k chunk, algorithm 2 [4/4] [UUUU]
      [=========>...........]  check = 45.8% (4475426736/9761715968) finish=501.0min speed=175851K/sec
      bitmap: 2/73 pages [8KB], 65536KB chunk

md0 : active raid1 sdc1[2] sdb1[1] sdd1[3] sda1[0]
      523712 blocks super 1.2 [4/4] [UUUU]

Einen SMART Fehler auf den Platten konnte ich bisher nicht ausmachen.
Sprich laut Monitoring scheint das alles ok zu sein.
Durchsatz Rate ist beim sync auch i.O. Da fällt keine Platte negativ auf.
Was ich nicht verstehe, warum mir das regelmässig so aus dem Ruder läuft, oder ist das "normal"?

Passiert btw. auf mehrere Servern, die als Storage Server eingebunden sind. Bei einem Backup geraten die Systeme aus dem sync und sind entsprechend langsam und am Limit.

[Joe User]

Eventuell hilft das ja schon weiter: https://www.thomas-krenn.com/en/wiki/Md ... y_function


Ich selbst bin ansonsten keine grosse Hilfe, da ich nur noch FreeBSD mit Raid1 einsetze.

[gierig]

Code: Select all

[=========>...........]  check = 45.8% (4475426736/9761715968) finish=501.0min speed=175851K/sec

das ist der übliche automatische check. Der ist nicht schlimm. Du wirst einen Cron Job dafür haben. (oder nen Timer event im SystemD)
je nach OS

Rsync oder Recovery würde da ansonsten stehen wenn einer der beiden fälle auftritt.

[ddm3ve]

Wo Du recht hat, widerspreche ich erstmal nicht.

Da bin ich wohl selber auf die Anzeige rein gefallen.
Es kommt allerdings bei starker Lat dennoch vor, dass das System / Raid us em Sync gerät.
Statt check steht dann tatsächlich rsync. Problem allerdings ist, der Server wird dann extrem langsam. Das war auch beim check so.
Ziemlich viel IO-Wait ohne, dass es sonderlich Last auf dem System gab.

Ich bin dran und schauen wir mal, was sich ergibt.

[ddm3ve]

Folgendes habe ich heraus gefunden.
Bei Hetzner hatte ich über installimage mein eigenes opensuse 15.2 Image installiert.
Mit der Installation erstellt installimage eine eigene raid Konfiguration basierend auf devicemapper.
Hier flog mir das Raid regelmässig um die Ohren. Spätestens bei höherer Lese und Schreib- Last, krachte schlussendlich das System. Das Raid beruhigte sich gar nicht mehr und ich musste das System resetten.

Nachdem ich das System ohne Devicemapper per VNC installiert habe, läuft das Raid weitestgehend stabil.
Allerdings kann es vereinzelt immer noch zu Aussetzer kommen. Zumindet, dass das Raid plötzlich neu synct.
Passiert meist, bei einem Vollbackup.
-> Es werden hierbei lediglich alle Daten als tgz gezippt. Also reine Fileoperation.

[gierig]

und ich wollte noch was dazu geschrieben haben....

Diese unbestimmten un untypischen Fehler fühlen sich immer irgendwie nach Hardware an.
ein doofes SATA Kabel, eine halbkalte Lötstelle unter dem Southbridge BGA der das HDD Interface anbindest
oder auch nur das doofe Netzteil das Periodisch zusammensackt oder burst ausspuckt und die Empfindliche "mechanik"
durcheinanderbringt.

Andrerseits. Hat du mal in die Richtung gedacht das da ggf. der Storage Treiber für deine Hardware buggy sein könnte ?
Da reicht ja mitunter eine andere Hardware Revision. Du sagtest ja ohne Device Mapper (ein LVM oder handgeknüpft mit DMsetup ?)
Läuft es ein wenig besser aber immer noch nicht Störungsfrei.

Kernel ist 5.3.x ? (du Erwähntest Suse 15.2) Kannst du einen aus 5.4 testen ? oder ggf. älteren.

[ddm3ve]

Hi,

also aktuell habe ich rund 15 Maschinen bei Hetzner stehen. Unterschiedliche Systeme, Teils 4 * Sata HDD, Teils 2 * Sata SSD teils 2 * NVME.

Für Cloud Storage aufgaben nutzen wir 2 getrennte Systeme mit jeweils 4 SATa Platten einmal 10 TB das andere mal 6 TB.
Jeweils Raid 5.
Bei beiden Systeme flog uns das Raid reihenweise um die Ohren, als wir es noch in der Kombination Device Mapper und Raid betrieben haben.
Das ist mit der Neuinstallation per VNC und dem Raid händische einrichten, weg.
Bei allen anderen Systemen mit SSD Platten besteht ein Raid 1. Anfang ebenfalls per Device Mapper. Das, was hierbei das Installimage draus gemacht hat.

Der Fehlerfall sieht wie folgt aus (bei allen Systemen), bzw. macht sich wie folgt bemerkbar.
Das System, auch wenn es z.B. gar keine Aufgaben hat, tritt mit steigender Last speziell IOWait in Erscheinung.
Dies wiederum meldete das Monitoring. Ebenfalls in dem Zug, begann ein rsync der md raids.
Das System wird dann kaum nutzbar langsam und endet je nach dem, ob man schnell genug war für einen reboot, in einem einfrieren des Systems.
Nach einem erfolgreichen reboot kann es sein, dass der resync noch läuft, aber das system ist wieder nutzbar schnell.
In einigen Fällen war aber das Raid wieder betriebsbereit ohne sync oder rebuild etc. als wäre nichts gewesen.

-> Dieses Phanomen ist inzwischen erledigt, nachdem eben das System per VNC installiert wurde.

In einzelnen Fällen hoher Last, ist das Problem oben aufgefallen, dass plötzlich das Raid degraded ist bzw. ein rsync läuft.
Hardwaretest liefert leider keine Ergebnisse.
Gestern wiederum auf einem Server mit nvme Disks:
Eine der disks war plötzlich weg. Das Monitoring meldet lediglich (check_smart) das device gibt es nicht.
Ein Hardwaretest bei Hetzner hat leider nichts ergeben. Kulanzhalber wurde die Hardware getauscht.
Harren wir mal der Dinge.

Btw. die Probleme hate ich auch schon mit Opensuse 15.1 damals wars nicht so dramatisch, weil die Systeme keinen Produktivstatus hatten. Alerdings erfolgte die Umstellung des Raids erst mit Version 15.2.