Subaru Community

Hallo,

bin selbst Informatiker und habe von dem Problem gelesen, musste mich soeben auch selbst wieder neu im Forum anmelden, weil alles weg war.

Wie ich Eure Ausführungem im Thread "Reset des Forums" verstanden habe, vermutet ihr, dass der Raid-Controller die Daten fehlerhaft auf die HDDs speichert. Darf ich fragen, wie ihr das eruiert habt? Ich meine, wie habt ihr festgestellt, dass der Datenstrom nach dem verlassen des Controllers auf seinen Ports, aber noch vor dem Erreichen der HDDs Fehler enthält?

Das was ihr beschreibt - so wie ich es verstand - ist das typische Verhalten bei sog. Silent Data Corruption.

In der Regel ist der Controller dabei aber ganz unschuldig. Er schreibt in der Regel die Daten schon richtig weg, diese Daten werden aber entweder durch die Verkabelung (SAS oder SATA Kabel) verändert, oder durch Anschlüsse in den Bakplanes oder meistens ist die Festplatte defekt.

In den einigen Fällen, wo ich Zeuge von Silent Data Corruption wurde, war der Controller grundsätzlich nicht daran schuld.

Der meiste Grund war, dass es die Festplatten waren, welche die Daten auf den Magnetscheiben fehlerhaft weggeschrieben haben. Ein Verify der Daten findet nämlich nicht statt. Die HDD bekommt die Daten und schreibt sie einfach weg. Ob sie auf den Magnetscheiben korrekt geschrieben wurden oder nicht, wird nicht geprüft, sondern darauf vertraut. Sehr oft passiert dieser Fehler im Übrigen, wenn SSDs statt HDDs verwendet werden.

Der zweite Fehler war die Verkabelung: Und zwar immer in einem bestimmten Fall:

Habt ihr einen SAS Controller, der auf SAS Platten schreibt, kann man den Fehler in der Verkabelung fast ausschließen, weil SAS ein Protokoll ist, welches Fehler bei Datenübertragungen zu 99% ausschließen kann.

Verwendet ihr aber SATA Festplatten an einem SAS/SATA-Controller, kann es zu folgendem Szenario kommen: Wenn ihr Festplatten verwendet, die SATA III (Sata 6G) fähig sind, versucht der Controller sie ebenfalls mit dem SATA III Protokoll anzusprechen. Die Erfahrung hat aber gezeigt, dass SATA III Kabel und das Protokoll sehr störanfällig sind. Daher wird dazu geraten, auch wenn SATA III fähige HDDs verwendet werden, unbedingt am Controller das SATA II (Sata 3G) Protokoll als Maximalgeschwindigkeit einzustellen. Man verliert dabei nicht an Geschwindigkeit und die Daten kommen deutlich sicherer an den Festplatten ohne korrumpiert worden zu sein.

Sind es zufällig SATA III HDDs die ihr nutzt? Dann stellt doch probeweise am Controller den SATA III Modus ab und aktiviert als maximum den SATA II Modus. Falls es geht natürlich. An den meisten Areca und LSI Controllern geht das.

Zum Backup kann ich sagen, dass es Software gibt, welche eine Datenüberprüfung nach der Sicherung vornimmt. Dadurch dauert das Backup doppelt so lange. Allerdings hat man damit nur gewonnen, dass es sichergestellt ist, dass die gleichen Daten im Backup landen, welche auf dem Server sind. Sind die Daten auf dem Server bereits fehlerhaft, werden die fehlerhaften Daten auch in die Backups gespielt.

Um Fehler im Dateisystem zu vermeiden, gibt es unter Linux einige besondere Dateisysteme, die eine Fehlerkorrektur und Überwachung bieten.

Wollte hiermit mit meinen Anregungen nur helfen. Aber als Hauptursache - aus eigener Erfahrung - sehe ich tatsächlich die Problematik, dass eben das SATA III Protokoll eingestellt ist und / oder, dass HDDs aus dem Desktop-Bereich verwendet wurden, statt echte Nearline oder Enterprise HDDs. Man sollte daher immer für ein Raid beispielsweise auf die Constellation Serie von Seagate ausweichen.

Was für HDDs oder Controller ihr verwendet ist mir nicht bekannt. Auch nicht, ob ihr physischen Zugriff auf den Server habt. Daher alles bitte als Schuss ins Blaue verstehen. Vielleicht hilft's aber.

Gruss
kawakawa

Hallo,

aah, ein "alter" HP Controller. Ist das ggf. ein umgelabelter LSI oder Adaptec? HP stellt ja keine Controller selbst her (so wie ich es im Kopf habe). Nehme an, der komplette Rest des Servers ist auch HP?

Was für Festplatten hängen dran, wo die Daten drauf sind?

Ich persönlich habe wenig Erfahrung mit den HP-Servern, weil die meisten, welche die geschäftlich nutzen, den HP-Service mit buchen.

Aber ich kann mich umhören, ob es bei diesem Controller Probleme gibt. Was für Fehler hat die ACU genau gemeldet? Bzw. welchen Fehler hat der Controller registriert?

Habt ihr den Server in einem Rechenzentrum gebucht / gemietet oder habt ihr nur den Platz im Rack gemietet und habt den eigenen Server reingestellt oder steht der Server irgendwo sonst und ist ans WAN angebunden?

Gruss
kawakawa

Hallo Andreas,

ich weiß es nicht, wie der Write-Back Cache an Deinem Controller implementiert ist, aber wenn es so ist wie üblich, also ein ECC-RAM Modul auf dem Controller und ein anschließbares Batterie-Modul, wie bei Areca, LSI und Konsorten, dann verursacht der Ausfall der Batterie selbst keine Schreibfehler. Der Ausfall des RAMs, sobald also ECC-Fehler erkannt werden, hagelt es so viele Fehlermeldungen, dass man es kaum übersehen kann.

In der Regel wird bei ECC-Fehlern des RAM Moduls auch automatisch der Write-Back Cache abgeschaltet und auf Write-Through umgeschaltet. So machen es die meisten aktuellen Controller.

Bist Du Dir 100% sicher, dass ihr damit wirklich die Probleme beseitigt habt???

Gruss
kawakawa

Hallo,

was Du genau beruflich machst, war mir nicht bekannt. Ebensowenig, dass Du bereits mehr Erfahrung mit genau diesen Servern hättest. Ich ging davon aus, dass bis dato die genaue Fehlerquelle nicht exakt eingegrenzt worden wäre, sondern es nur "am wahrscheinlichsten" am BBWC gelegen haben müsste.

Dass es keine 100% Garantie gibt, ist mir schon klar.

Gruss
kawakawa