ZFS/zpool setzt scheinbar zufällig SSDs auf FAULTED

[dittertp]

Hallo Zusammen,

ich konnte leider keinen besseren Titel finden, der das Problem bestmöglich umschreibt. Konkret geht es hier vermutlich eher um ein Hardware-Problem, welches aber einen unserer PVE-Server betrifft. Das System wird verwendet um VMs und Container zu betreiben, als "Backend" wird ein lokaler ZFS Mirror Pool verwendet.

Zur Hardware:

Gehäuse: Supermicro CSE-216BAC-R920LPB (2HE, 24 2,5 Zoll Festplatteneinschübe, direct attached Backplane (jede Festplatte hat also eine direkte Verbindung zum Controller))
Mainboard: Gigabyte MZ31-AR0 (16*SATA über SlimSAS)
Prozessor: AMD Epyc AMD 7401P (24Kerne/48Threads)
RAM: 512GB Crucial ECC Ram
SSD fürs System: Intel 480GB md raid 1
SSDs für ZFS: 9* Micron 5200 PRO SSD - 1920 GB (4*Mirror + 1 HotSpare)

Die Backplane ist/war direkt mit den 4 SlimSAS Anschlüssen auf dem Mainboard verbunden.

Software:
- Proxmox 6.1 KVM/Container
- alle Pakete aktuell, Problem war aber sowohl mit zfs 0.8.1 als auch 0.8.3 vorhanden


Zum Problem:

Wir haben das System anfang Dezember zusammengebaut, getestet und in Betrieb genommen. Alles hat hervorragend funktioniert. Die Performance war ausgezeichnet. Wir hatten damals (also bevor das System Produktiv wurde) kleinere Probleme mit ZFS und hoher Schreiblast auf zvols (https://github.com/openzfs/zfs/issues/7631) - das haben wir mit dem zfs module Parameter "zvol_threads" aber in den Griff bekommen. Das System lief dann unverändert (gleiche Anzahl VMS/Container) etwa 3 Monate fehlerfrei, bis eine Festplatte im Pool wegen zu vielen Write-Errors als "Faulted" markiert wurde und ein resilver auf die Hotspare platte stattgefunden hat. Wir haben uns nichts weiter gedacht, haben die Festplatte ausgetauscht. Einige Tage später ist das selbe Problem wieder mit einer anderen Festplatte passiert. bei einem "zfs scrub" ist kurz darauf erneut eine andere Festplatte ausgefallen. Währenddessen haben wir die vermeintlich defekten platten in einem anderen Server getestet und mehrere Tage unter volllast gesetzt, hier gab es jedoch keinerlei Anzeichen für ein Problem. Auch die smartwerte der Festplatten waren/sind immer einwandfrei (ein Paramter ist bei allen Platten gleich hoch - "Command_Timeout". Dieser Wert hat sich damals bei den Problemen mit zvol verändert, jedoch seitdem nicht mehr!). Wir haben dann auch eine der "defekten" Festplatten wieder in den Pool mit aufgenommen. Diese hatte seitdem auch kein Problem mehr verursacht.

Da wir also in kurzer Zeit 3 Ausfalle mit immer anderen Platten hatten, die aber weder an den smartwerten noch sonst wie als defekt erkennbar waren, haben wir uns entschlossen einen Broadcom 9305-i16 HBA einzubauen (und damit auch neue Kabel). In der Hoffnung nur hier ein Problem mit den SlimSAS Anschlüssen oder Kabeln zu haben, wollten wir die ganze Kette austauschen und auch nicht mehr den SATA Controller aus der CPU Nutzen.

Leider hatte dies absolut keinen Erfolg und die Fehler passieren und unregelmäßigen Abständen, vorwiegend in der Nacht, weiterhin. Mittlerweile dokumentieren wir den Fehler und setzen per "zpool clear" die Fehler zurück, ohne tatsächlich was an der Konfiguration zu ändern.

Hier ein "Beispiel von einem der letzen Ausfälle:

Spoiler: zpool status

pool: storage
state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
repaired.
scan: resilvered 416G in 0 days 00:25:09 with 0 errors on Mon Apr 27 08:47:19 2020
config:
NAME STATE READ WRITE CKSUM
storage DEGRADED 0 0 0
mirror-0 ONLINE 0 0 0
wwn-0x500a075122d7d2bb ONLINE 0 0 0
wwn-0x500a075122d7d759 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
wwn-0x500a075122d7d6f0 ONLINE 0 0 0
wwn-0x500a075122d808dc ONLINE 0 0 0
mirror-2 DEGRADED 0 0 0
spare-0 DEGRADED 0 0 0
wwn-0x500a075122d7d674 FAULTED 0 33 0 too many errors
wwn-0x500a075122d7d34d ONLINE 0 0 0
wwn-0x500a075122d7d818 ONLINE 0 0 0
mirror-3 ONLINE 0 0 0
wwn-0x500a075122d7d787 ONLINE 0 0 0
wwn-0x500a075122d7d3d7 ONLINE 0 0 0
spares
wwn-0x500a075122d7d34d INUSE currently in use
errors: No known data errors

die Fehler stehen auch im dmesg Log. Es sind immer die selben Fehler, und immer identisch aufgebaut. (Deshalb nur die Logs von dem einen Vorfall)

Ich musste die Logs zu pastebin auslagern, da ich das Zeichenlimit sonst überschreite
https://pastebin.com/sCsc1FfF


Ich kann leider keinen Anhaltspunkt finden was hier nun genau das Problem sein könnte. im Auszug des dmesg logs steht z.B. "FAILED Result: hostbyte=DID_TIME_OUT ". Könnte das drauf hindeuten, dass die Festplatte zu der Zeit einfach nicht erreichbar war? Irgendein Energiesparmodus?

Eine weitere Info: Es Gibt einen fast baugleichen Server für Backups (zfs snapshots) (gleiches Gehäuse, gleiches Mainboard, kleinerer Prozessor, 128GB Ram, und Micron 5210 ION 7.68TB Festplatten in reinem Raid-z2) - dieser Server wurde gleichzeitig in Betrieb genommen, nutzt die pve no-subscription Pakete (Kernel und ZFS, kein PVE), dieser Server funktioniert bis heute einwandfrei und hatte nie auch nur ein einziges Problem.


Im Moment würde für mich die Backplane als Verursacher am meisten Sinn ergeben, denn alles andere wurde bereits getauscht, es trifft immer andere Festplatten. Dass sich ein Problem mit der CPU oder mit dem RAM so äußern aber z.B sonst keine Probleme verursachen oder einen Logeintrag erzeugen halte ich auch für unwahrscheinlicher. Ich habe allerdings in meinem Berufsleben noch nie von einer defekten Backplane gehört. Interessanterweise ist noch keine der ersten 4 Festplatten ausgefallen, sondern bisher nur Festplatten der anderen 3 "Gruppen". (ein Mini SASHD Anschluss versorgt ja jeweils 4 Ports). diese 4 Festplatten teilen sich auch einen Stromanschluss, auf der Backplane sind diese also zumindest teilweise getrennt.


Was meint ihr? Wo sollte ich am ehesten suchen? Ich bin für jeden Tipp oder Gedanken dankbar.

Danke euch!

 

[fabian]

[Mon Apr 27 08:21:52 2020] sd 6:0:6:0: Power-on or device reset occurred

kabel kontrolliert? wenns immer dasselbe device ist..

 

[dittertp]

Hi,

es war immer ein anderes Device betroffen und durch den Controller (HBA) tausch, wurden auch die Kabel getauscht. Das Problem blieb aber.

 

[fabian]

hört sich auf jeden fall nach einem hardware problem an.. nachdem es scheinbar nicht die platten und nicht der controller ist, bleibt ja fast nur mehr die backplane über.. smart wert für unexpected power loss count ist auch recht hoch dafür dass die SSDs noch nicht so lange im einsatz sind (26 power cycles, 17 unexpected power loss!), kann aber auch eine falsche spur sein.

 

[dittertp]

Hi,

Hier mal ein Update: mittlerweile wurde sogut wie alles an dem System getauscht, Backplane, Mainboard, CPU, Gehäuse (inkl Netzteil), das Problem existiert weiterhin. Die Read errors sind mittlerweile auch auf den Systemplatten (Intel SSDs) aufgetreten, ein generelles Kompatiblitätsproblem mit den Micron 5200 ist es also nicht.

Kurz also zur Zusammenfassung: Das System lief ca 6 Monate einwandfrei, davon 3 Monate Produktiv (also auch unter last). Ab diesem Zeitpunkt haben wir in unregelmäßigen Abständen (5-20 Tage zwischen den Fehlern) Read/Write errors auf scheinbar komplett zufälligen SSDs des Systems, auch auf Festplatten die nicht von ZFS verwaltet werden.

Getauscht wurde: Backplane, Kabel, HBA, Mainboard, CPU, Gehäuse (inkl Netzteil).
nicht getauscht wurde: RAM (ecc), Festplatten


Hat irgendwer noch eine Idee?

 

[wigor]

Schwankungen in der Stromversorgung? Temperatur? Das wäre noch so was, was ich mir ansehen würde.

 

[dittertp]

Hi,

ich habe das Gehäuse inkl. Netzteil und allen kabeln gewechselt, das würde ich also ausschließen. Der Server befindet sich in einem klimatisiertem Serverraum. Die Temp schwankt also kaum und auch die Luftfeuchtigkeit ist im Optimalbereich.

 

[LutzHase]

Sorry ich habe keine Ahnung, aber wenn du " Read/Write errors " hast, warum tauscht man dann alles andere aber nicht das Speichermedium?
Ich weiß schon das es das teuerste Bauteil ist...
Und du bist sicher das es ecc Ram ist? "Normaler" Ram macht nämlich auch so etwas. Es dauert eben bis die Rechenfehler sich häufen und multiplizieren...

 

[dittertp]

Weil der Fehler auf allen Festplatten aufgetreten ist (13 Stück) - das Festplattenmodell müsste also generell "Inkompatibel" sein - aber inkompatibel zu was? ZFS? AMD Epyc? LSI Controller? Ich hab halt schon genug Systeme mit diesen Festplatten und einer ähnlichen Server config gesehen, welche alle einwandfrei funktionieren. Die Chance ist aus meiner Sicht groß, dass der Tausch auf Intel oder Samsung SSDs keinerlei positive Auswirkung auf das Problem hat.
Ja, es ist garantiert ECC Ram.

 

[T.Herrmann]

Hallo dieser Fehler kommt mir bekannt vor.
Wir hatten ein ähnliches Problem bei einer Kombination aus HGST SAS 12 TB HDD's mit LSI-3008 Controllern als Kombi, wo nur ein Firmware Update der HDD's das Problem hätte lösen können, was aber Western nicht bereit gestellt hatte.

Ursache:
Der SAS UpLink Speed (negotiated_linkrate) verursachte das Problem weil diese zwischen der Festplatte bzw. SSD verhandelt wird und bei einer inkompatiblen Kombination aus SAS HBA und HDD bzw. SSD verhandel das System im laufenden Betrieb neu und ändern den Speed kurzzeit von 12 auf 6 Gbps wieder zurück zu 12Gbps. (negotiated_linkrate=12.0 Gbit >> negotiated_linkrate=6.0 Gbit >> negotiated_linkrate=12.0 Gbit )
Wer das nicht glauben will kann gerne mal manuell das im laufenden Betrieb verändern und wird erleben wie ZFS die Festplatten degraded.

Lösung: Das Tool lsscsi

• apt-get install lsscsi
• prüfen der negotiated_linkrate
  • lsscsi -H -t --list | grep negotiated_linkrate=
• Festellen der negotiated_linkrate das X durch Controller Nummer und Festplatten Portnummer ersetzen.
  • echo 6.0 Gbit > /sys/class/sas_phy/phy-X\:X/maximum_linkrate
• Abschließend: zpool clean xxpool und zpool scrub xxpool

Dass könnte euer Problem lösen. Diese Lösung für unser ZFS Problem zu finden hat unseren IT-Team sehr viel Zeit gekostet und jetzt sind alle erst mal zufrieden weil 6.0 Gbit für Festplatten völlig ausreichen.

Des Weiteren noch ein wichtiger Tipp: In einem ZFS RAID keine unterschiedlichen SAS Speed negotiated_linkrate zulassen. In einem ZFS Pool der aus Zwei ZFS RAID's besteht wiederum geht das.

 

[dittertp]

Hi, vielen Dank für den Input! Hier handelt es dich zwar nur um SATA festplatten, ich werde aber definitiv das ganze mal prüfen.
Im Bugtracker habe ich einen recht passenden Issue (https://github.com/openzfs/zfs/issues/8835) in Verbindung mit Mirrors und Trim gefunden. Ich spiele mit dem Gedanken aus dem Mirror ein Raidz2 zu machen, das könnte ja dann das Problem lösen.

 

[dittertp]

Den gestrigen gedanken habe ich heute getestet und ein raid z2 neben dem mirror erstellt. Ich habe jeweils eine platte aus den mirrors entfernt und die hotspare und ersatzplatte dazugenommen, danach deb pool per send und receive gesynct. Hier hat aber nur der erste scrub fehlerfrei funktioniert. Sobald ein paar (5) vms liefen schlug der scrub immer fehl. Die ganze Arbeit war also umsonst.
Da der Mirror leichter wartbar ist, habe ich dann alles wieder zurückgebaut und zusätzlich die Backplane wieder direkt ans Mainboard angeschlossen und somit den LSI HBA mal rausgenommen. Bisher funktioniert alles einwandfrei, deutlich besser als ich erwartet hätte. Richtig viel sinn ergibt das für mich im moment nicht, da bei diesem Setup ja die initialen Probleme damals entstanden sind.

 

[T.Herrmann]

Ja, aber eigentlich kann z.B. ein normales Intel Xeon Mainboard nur 10 S-ATA Geräte native anschließen. Mehr Ports bedeutet das da ein anderer Controller noch vorhanden ist, der dann eine Fehlerquelle für ZFS sein kann. Bei AMD EPIC, mit seiner anderen Board Architektur, fehlt uns noch die Erfahrung aber wir bekommen im Okt. ein Dual Socket 7702 System mit vielen SAS SSD's und 2-TB RAM.