DSM 7.2 SNMP friert durch defekte SSD ein

[jonas.franz]

Guten Tag,

wir betreiben eine RackStation mit DSM 7.2.2. Das System wird mittels Telegraf und SNMP überwacht. Vor kurzem ist eine Cache-SSD gestorben. Seitdem funktioniert das SNMP Monitoring nicht mehr. Nach Problemsuche haben wir festgestellt das der smartctl Prozess welcher vom SNMP service gestartet wird sich permanent aufhängt da er auf eine Antwort der Festplatte wartet, welche aber natürlich nie kommt. Wenn eine SNMP-Anfrage gestellt wird welche nur ansatzweise mit Festplatten, S.M.A.R.T. Werten oder Speicher zusammenhängt kommt es in irgendeiner Form zu diesem Fehlerzustand, welcher sich nur durch einen manuellen Neustart des systemd-Services beheben lässt.

Da das Monitoring genutzt werden voll um Festplattenausfälle zu erkennen, bzw. auch vorzuwahnen kann es natürlich nicht sein dass das Monitoring eben genau im Fehlerzustand nicht funktional ist. Gibt es jemanden der schon ähnliche Erfahrungen gemacht hat, oder evtl. einen Workaround, wie z.B. einen Timeout für den smartctl Prozess?

MfG

 

[metalworker]

hattest den Cache nicht als Raid1 betrieben?

 

[maxblank]

Hallo @jonas.franz und Willkommen im Forum,
wurde die SSD mittlerweile erfolgreich ersetzt? Läuft der Cache ansonsten wieder wie gewohnt? Welche RS genau?
Es fehlen doch relativ viele Infos um wirkungsvoll helfen zu können.

Viele Grüße
maxblank

 

[jonas.franz]

Guten Tag,

danke für die schnellen Antworten. Es handelt sich um eine RS3617xs+. Der Cache bestand aus einem RAID1 aus zwei identischen SSDs, im Read/Write Modus. Die SSDs haben keine Form von PLP. Die SSD wurde noch nicht ersetzt, der Cache wurde beim Verlust der SSD automatisch deaktiviert, und ist es bisher immer noch. Der Pool selbst besteht aus 10 HDDs in RAID10.

Es ist zwar nochmal ein separates Thema, dennoch evtl. interessant hierfür: als die Cache SSD gestorben ist haben unsere Virtualisierungshosts und besonders die VMs welche den Synology als Datastore nutzen teils Datenverlust erfahren. Einige der VMs mussten einfach nur neu gestartet werden, in einigen VMs sind aber Datenbanken, e.g. etcd korrumpiert. Da der Cache in RAID1, sowie die HDDs in RAID10 laufen waren wir beim Aufsetzen der Annahme das ein solcher Datenverlust nicht möglich sei.

Da unser Workload auf den HDDs recht gering ist macht es Performance-Technisch aktuell keine Schwierigkeiten das der Cache noch deaktiviert ist. Da es sich zudem nicht um Produktiv- sondern Entwicklungs-Systeme handelt sind wir aktuell noch damit beschäftigt die Monitoring-Probleme zu analysieren, sowie den oben genannten Datenverlust.

Im folgenden nochmal eine genauere Fehler-Analyse:

SNMP scheint sich immer aufzuhängen wenn es von Telegraf gescraped wird. Selbes Problem tritt auch lokal auf dem NAS auf. Der SNMP-Walk scheint anfangs zu funktionieren:



bis:



Danach ist der SNMP Service nicht mehr erreichbar und man bekommt durchgehend Timeouts, bis man ihn mit `sudo systemctl restart snmpd` neu startet. Manche Queries laufen ohne Fehler durch, andere resultieren in Timeout:



Bei Betrachtung des Service-Status:



Manuelles ausführen von `sudo smartctl -a /dev/sdk` resultiert darin das sich smartctl permanent aufhängt. Bei /dev/sdk handelt es sich um unsere tote SSD. Daher die Vermutung: jedes mal wenn SNMP in irgendeiner Form Daten von der Platte erhalten möchte hängt sich der Subprozess auf der von SNMP erstellt wird auf, und SNMP selbst wartet bis in alle Ewigkeit auf eine Antwort. Auszug aus dmesg:



Falls weitere Infos benötigt werden bitte schreiben.

VG

 

[maxblank]

Danke für deine Ausführungen und Screenshots - sehr interessant. Ich vermute, dass es hier allerdings vorher schon ein Problem gab oder ein schleichendes Fortschreiten stattfindet - evtl. mit dem Filesystem.
Nutzt ihr BTRFS oder ext4? ECC-RAM kommt zum Einsatz (ohne das ich jetzt geprüft habe, ob die RS3617xs+ diesen unterstützt)?

Hattet ihr auf den Cache-SSDs die Metadaten des NAS abgelegt? Dies kann bei der Einrichtung des Caches angegeben und in den Einstellungen geprüft werden.

Normalerweise dürften bei einem gespiegeltem RAID1-Cache keinerlei Datenverluste auftreten, wenn beide SSDs bis zu diesem Zeitpunkt intakt sind und dann eine ausfällt. Habt ihr den Storage, den das NAS für den Hypervisor zur Verfügung stellt, als iSCSI oder per NFS bzw. SMB angebunden? Oder sprechen wir von VMs, die lokal per Synology VMM gelaufen sind?

Lies mal bitte die andere Cache-SSD mit dem Befehl „sudo smartctl -iA -d sat /dev/sda“ (sda bitte entsprechend anpassen) aus und poste die Ausgabe hier.

Bezüglich des Dienstes scheint der in ein Timeout zu laufen, verbleibt in diesem „schwebendem“ Zustand, da er keine Antwort bekommt. Dann ist entweder der Dienst seitens Synology nicht richtig programmiert (kann sich trotz Timeout nicht korrekt beenden oder denkt, dass er sauber läuft, obwohl er weg ist) oder, was ich eher glaube, ein korruptes Filesystem dafür verantwortlich ist und der Dienst ein „Seitendeffekt“ ist.

Der SMART-Dienst von Synology funktioniert normalerweise einwandfrei, auch wenn von dem Datenträger keine Infos mehr kommen.
Dort steht dann oftmals in der Console, dass der SMART-Befehl nicht ausgeführt werden kann.

Edit: Stoppe mal das automatische Monitoring auf dem NAS, führe dann mal noch die SMART-Abfrage auf /dev/sdk per Console aus und schaue, ob sich der Dienst dann immer noch aufhängt.

 

[jonas.franz]

Hallo,

es kam/kommt BTRFS zum Einsatz. Die VMs laufen auf externen ESXi Hosts. Es handelt sich um iSCSI Datastores. Der Ausgabe von "sudo dmidecode -t memory | grep -i ecc" nach zu Urteilen wird ECC verwendet: "Error Correction Type: Multi-bit ECC". Für die funktionierende SSD gibt der geschickte Befehl das folgende aus:



Der Vollständigkeit halber: mit deaktiviertem Monitoring und lokalem Ausführen von SMART auf der defekten SSD kommt nach ca. 3 Minuten timeout und Ausgabe: "Read Device Identity failed":



Der Befehl terminiert also irgendwann, aber erst nach einiger Zeit. Im SNMP Daemon bestand der Fehlerzustand allerdings weitaus länger, evtl. ein unglückliches Zusammenspiel?

Für den Cache ist die Option "Alle BTRFS-Metadaten speichern" aktiviert. Eine weitere Interessante Erkenntnis, der Befehl "sudo btrfs filesystem show" listet zunächst den HDD-Pool auf, hängt sich danach aber auf und liefert keinen weiteren Output.

VG

 

[ctrlaltdelete]

Wieso ist die defekte Cache SSD noch eingebaut?
Edit: Kann es sein, dass die 2. SSD auch bald fertig hat: ID 231

 

[jonas.franz]

Da der Cache-Pool deaktiviert ist sollte das möglicherweise nahende Ableben der anderen SSD hoffentlich unproblematisch sein?

Die SSD ist noch eingebaut da wir die "Gelegenheit" nutzen können um sicherzustellen das unser Monitoring/Alerting im Fehlerzustand tatsächlich funktioniert. Es kann ja nicht sein das unser Monitoring nicht funktional ist sobald eine Festplatte stirbt. Daher möchten wir den Fehlerzustand so gut es geht verstehen und diagnostizieren, und idealerweise ein Monitoring/Alerting bauen was mit diesem Zustand umgehen kann.

Edit: natürlich sollte ein Monitoring idealerweise auch vorwarnen sodass ein solcher Ausfall gar nicht erst Zustande kommt, aber das selbst schließt ja ein plötzliches Versagen nicht aus.

 

[ctrlaltdelete]

Aber wenn die tote SSD den Fehler evtl. verursacht???

 

[jonas.franz]

Die Tote SSD verursacht mit großer Wahrscheinlichkeit den Fehler, keine Frage.

Das Problem ist aber doch: was ist ein Monitoring wert wenn sobald ein Fehlerzustand herrscht keinerlei Metriken mehr auslesen werden können? Eine Option wäre einen Alert auszulösen "SNMP für Synology gibt keine Metriken mehr". Idealerweise können wir ja aber Feststellen das eben nur eine Festplatte nicht mehr antwortet um einen Alarm "Festplatte /dev/sdk tot, bitte ersetzten" zu senden.

Grundsätzlich ist es also die Frage wie mit Fehlern umgegangen wird, und die Option "es geht gar nichts mehr" ist nicht wirklich hilfreich. Ich hoffe du verstehst worauf ich hinaus will, es geht uns aktuell weniger darum den Fehler zu beheben, als zu verstehen wie wir mit dem Fehlerzustand besser umgehen können.

Edit: außerdem wäre es natürlich auch gut zu verstehen wie bei einem RAID1 / RAID10 ein Datenverlust auftreten konnte.

VG

 

[maxblank]

Ich vermute, dass die eventuell gar nicht tot ist. Sondern das NAS die schön durchgekaut und ausgespuckt hat. Synology NAS schmeißen die Cache-SSDs, wenn ein bestimmter Wert (könnte die ID 231 sein) erreicht ist, gnadenlos raus, obwohl die technisch noch einwandfrei funktionieren und lassen auch kein Einbinden im NAS mehr zu. Kannst du die mal an einem Clients bzw. Laptop mit Dockingstation gegentesten? Brauchst die SSD auch nicht formatieren, du kannst diese mit GSmarControl auslesen, auch wenn diese unter Windows nicht erkannt wird. Von GSmartControll bitte einen Screenshot der vergangenen SAMRT-Tests und der SMART-Werte generell posten.

USV scheint auch keine vorhanden zu sein, zumindest wurde die RS selbst oder die SSD siebenmal hart vom Strom getrennt.

Normalerweise sollte sich der Cache doch nicht komplett deaktivieren, sondern nur in den Read-Modus gehen, wenn nur noch eine SSD vorhanden ist.
Kann es sein, das beide SSD zeitnah ihr gemeinsames Lebensende im Synology-Zyklus erreicht haben, der Cache dadurch degradiert wurde ohne das die Metadaten übertragen wurden und es so zum Datenverlust kommen konnte?

 

[ctrlaltdelete]

Wenn SSD einen "elektrischen" Fehler hat, kann es das ganze System lahmlegen, ich würde sie mal testweise ausbauen.

 

[maxblank]

Das passt aber nicht zu den Symtomen eines elektrischen Fehlers. Raus muss die SSD sowieso zum Auslesen der SMART-Werte, falls die noch lebt.

Bei den Diensten nach deinen Tests gehe ich davon aus, dass sich mein o.a. Verdacht bestätigt hat. Hier ist nicht der Dienst von Synology das Problem, sondern der Monitoring-Dienst kann scheinbar mit der Antwort bzw. dem Timeout in diesem speziellem Fall nicht umgehen. Du hattest in der Console nach ca. 180 Sekunden die Ausgabe, die ich angesprochen hatte. Das der Synology Dienst grundsätzlich funktioniert, sieht man eigentlich daran.

Wie kommt es nun zu dem Szenario?
1. Monitoring Tool kann diese Art der Befehls-Rückgabe scheinbar nicht sauber verarbeiten, auch damit nichts anzeigen und bleibt quasi in Warteschlange oder sendet unendlich immer wieder den selben Befehl bis zu einem ungewissem Schwellenwert
2. Manuelle Abfrage der SMART-Werte per Console führen aufgrund dieses Verhalten ins Leere, da die empfangenen Befehle der Reihe nach abgearbeitet werden (Query) oder in das Timeout laufen, was den Dienst instabil werden lässt (quasi ein Buffer Overflow)
3. Resultat ist, was wir hier sehen, dass das Monitoring System nicht sauber melden kann und ggfls. den Synology Dienst in einen "schwebenden" Zustand versetzt oder abstürzen lässt

In meinen Augen allerdings kein Problem von Synology an sich, sondern eher von der Monitoring Software. Welche kommt zum Einsatz?
Hier müsste zusätzlich im Monitoring überwacht werden, ob der Dienst tatsächlich noch am laufen ist. Falls das nicht geht, sollte als Workaround per Script ein regelmäßiger Neustart des Dienstes getriggert werden. Nicht schön, sollte als Workaround allerdings funktionieren.

 

[jonas.franz]

In meinen Augen allerdings kein Problem von Synology an sich, sondern eher von der Monitoring Software. Welche kommt zum Einsatz?

Es handelt sich in seiner jetzigen Fassung um einen Telegraf Dienst mit SNMP Input Plugin, also einen Client welcher in einem definierten Zeitintervall alle SNMP Metriken erfasst.

Und ich würde dir hier wiedersprechen, das Verhalten vom snmp-Dienst auf dem Synology ist nicht wirklich "sauber". In meinen ersten geschickten Bildern kann man sehen das die SNMP Daten ausgelesen werden, bis sie zum ersten mal mit der defekten Disk in Kontakt kommen. Das diese einen Timeout liefert ist ja verständlich, aber das die SNMP-Abfrage dann insgesamt einen Timeout liefert finde ich fragwürdig, vor allem da alle folgenden Metriken in der Hierarchie, welche selbst nichts mit Disks zutun haben nicht mehr ausgelesen werden. Der Timeout sollte hier vom SNMP Daemon der Synology kommuniziert werden, und sich selbst nicht in einem Timeout aufhängen. Alternativ sollten die Abfragen nicht sequentiell, sondern parallel ausgeführt werden sodass der Timeout einer einzelnen Smartctl Abfrage auf der Synology nicht die Erfassung der restlichen Metriken behindert.

Ob das nun eine schlechte Implementierung seitens Synology ist oder ein extern entwickeltes Paket genutzt wird sei einmal dahingestellt. Der von dir vorgeschlagene Workaround den Dienst neuzustarten ist aufgrund des oben beschriebenen Verhaltens ebenfalls nicht hilfreich, da die Abfrage in jedem Fall irgendwo im SNMP-Datensatz stecken bleibt, und ab da nicht mehr ansprechbar ist. Die Abfrage von Telegraf geschieht alle 30s, und durch den Timeout werden auch viele verbleibende Metriken nicht geliefert. Der einzige Workaround aktuell ist die Disk-related Metriken manuell aus der Abfrage auszuschließen, was natürlich ebensowenig sinnvoll langfristig ist.

 

[jonas.franz]

Ich vermute, dass die eventuell gar nicht tot ist. Sondern das NAS die schön durchgekaut und ausgespuckt hat. Synology NAS schmeißen die Cache-SSDs, wenn ein bestimmter Wert (könnte die ID 231 sein) erreicht ist, gnadenlos raus, obwohl die technisch noch einwandfrei funktionieren und lassen auch kein Einbinden im NAS mehr zu. Kannst du die mal an einem Clients bzw. Laptop mit Dockingstation gegentesten? Brauchst die SSD auch nicht formatieren, du kannst diese mit GSmarControl auslesen, auch wenn diese unter Windows nicht erkannt wird. Von GSmartControll bitte einen Screenshot der vergangenen SAMRT-Tests und der SMART-Werte generell posten.

USV scheint auch keine vorhanden zu sein, zumindest wurde die RS selbst oder die SSD siebenmal hart vom Strom getrennt.

Normalerweise sollte sich der Cache doch nicht komplett deaktivieren, sondern nur in den Read-Modus gehen, wenn nur noch eine SSD vorhanden ist.
Kann es sein, das beide SSD zeitnah ihr gemeinsames Lebensende im Synology-Zyklus erreicht haben, der Cache dadurch degradiert wurde ohne das die Metadaten übertragen wurden und es so zum Datenverlust kommen konnte?

Interessante Insights und Theorien. Ich werde zeitnah diese Tests durchführen und dann berichten.

VG

 

[maxblank]

Die SSDs haben keine Form von PLP

Wenn das Kingston DC400 SSDs sind, was ich aus deinem o.a. Screenshot entnommen habe, dann haben die allerdings laut Kingston "firmware-gesteuerten Stromausfallschutz". Das aber nur am Rande, macht den Datenverlust im RAID1 während Schreiboperationen noch umwahrscheinlicher.



Quelle: https://www.kingston.com/datasheets/SEDC400S37_de.pdf

Ich werde zeitnah diese Tests durchführen und dann berichten.

Das würde mich echt interessieren, was dabei unterm Strich rausgekommen ist. Mach das bitte! Viel Erfolg.

 

[jonas.franz]

Wenn das Kingston DC400 SSDs sind, was ich aus deinem o.a. Screenshot entnommen habe, dann haben die allerdings laut Kingston "firmware-gesteuerten Stromausfallschutz". Das aber nur am Rande, macht den Datenverlust im RAID1 während Schreiboperationen noch umwahrscheinlicher.

Oh, danke für die Klarstellung, dann hatte ich das falsch in Erinnerung.

VG

 

[maxblank]

Bitte, sehr gerne. Es kann halt ein wichtiges Detail sein, wenn es um Datenverlust geht.