Update der Firmware von Seagate SSDs in einem Scale-Out File Server
Das Thema Scale-Out File Server ist momentan sehr gefragt. Wir haben in letzter Zeit einige Beiträge zu Aufbau und Administration solch eines Aufbaus geschrieben. Dieser Artikel beschreibt die Wartung solch eines Systems, genauer gesagt geht es um ein Update der Firmware, die in den SSDs zum Einsatz kommt. Wir nutzen SSDs der Firma Seagate, welche derzeit nicht mit der aktuellsten Firmware betrieben werden. Weitere Informationen, warum in unserem Fall die aktuellste Firmware benötigt wird, finden Sie in diesem Artikel: Windows-Update im Scale-Out Fileserver erzeugt Probleme bei der Arbeit mit Datenträgern im Failover Cluster
Eines ist uns in Bezug auf diesen Artikel sehr wichtig: Die hier durchgeführten Möglichkeiten zum Update stellen keinerlei Empfehlungen dar! Wir wissen nicht ob die Maßnahmen immer fehlerfrei genau so in anderen Umgebungen mit anderen SAS-HBAs, JBODs usw. funktionieren. Ein aktuelles Backup der Daten ist absolute Pflicht, alles Andere ist mehr als grob fahrlässig! Wir tragen keinerlei Verantwortung für jegliche Probleme, Fehler oder Verluste, die durch ein Update der Firmware passieren!
Gerne stehen wir für Fragen oder den eigentlichen Update-Vorgang zu Verfügung, treten Sie einfach in Kontakt mit uns.
Bei dem Update der SSDs haben wir festgestellt, dass es nicht funktioniert, wenn das JBOD mit mehreren SAS-Kabeln an den Server angebunden ist, der das Update durchführt. Dies bedeutet, es darf nur eine einzige Verbindung vorhanden sein.
Die verschiedenen Möglichkeiten eines Updates – Die Theorie
Wir haben gemeinsam überlegt, welche Update-Möglichkeiten vorhanden sind, und sind zu drei Varianten gekommen:
- Ein Update der SSD im laufenden Betrieb.
- Ein Update einer SSD, die während dieser Zeit mit dem Status “Verbindung verloren” auftaucht.
- Ein Update einer SSD, die manuell auf den Status “Retired” gesetzt wird.
1. Ein Update der SSD im laufenden Betrieb.
Diese erste Möglichkeit wird von Seagate ausdrücklich nicht empfohlen! Im Vergleich zu den anderen beiden Möglichkeiten ist dies aber die Einzige, bei der keine SSD aus dem System entfernt werden muss. Wir schauen uns später an, ob dies technisch möglich ist und welche Voraussetzungen hierfür geschaffen werden müssen.
2. Ein Update einer SSD, die während dieser Zeit mit dem Status “Verbindung verloren” auftaucht.
Wenn Sie im laufenden Betrieb einen Datenträger aus dem JBOD entfernen, wechselt der Status dieses Datenträgers auf
3. Ein Update einer SSD, die manuell auf den Status “Retired” gesetzt wird.
Der korrekte Weg, einen Datenträger aus einem Pool zu entfernen, ist eine vorherige Markierung des Datenträgers als “retired”. Standardmäßig befinden sich alle Datenträger im Zustand “Auto-Select”.
Die verschiedenen Möglichkeiten eines Updates – Die Praxis
Ich habe die verschiedenen Möglichkeiten des Updates nicht in der Reihenfolge durchgeführt, in der sie hier beschrieben sind, sondern ich habe erst Variante 2 (lost connection), dann Variante 3 (retired) und danach Variante 1 (im laufenden Betrieb) getestet. Dies liegt daran, dass bei Variante 1 alle Datenträger von einem Typ gleichzeitig geupdatet werden und ich so bei Erfolg der Möglichkeit keine weiteren SSDs mehr habe, die ich testen kann.
Ein Update der SSD im laufenden Betrieb
Bei dieser Art von Update soll die Firmware direkt auf die laufenden SSDs eingespielt werden. Wir haben so etwas noch nie durchgeführt. Dieser Beitrag ist demnach also die Premiere eines solchen Vorgangs. Laut Seagate-Techniker ist diese Art von Update nicht empfohlen und sollte möglichst vermieden werden. Das hier genutzte System läuft nicht produktiv, daher kann ich in meinem Fall das Ganze recht schmerzfrei durchführen.
Damit wir ein Update machen können müssen die gleichen Bedingungen wie bei einer anderen Art von Firmware-Update erfüllt sein: Ein mit Linux vorbereiteter Stick wird als temporäres Bootmedium genutzt und es darf nur eine Verbindung zu dem Datenträger vorhanden sein. Die Vorgehensweise ist somit:
- Aktivierung des Wartungsmodus für einen der beiden FileServer-Knoten
- Entfernung aller SAS-Verbindungen bis auf Eine
- Neustart des Servers
- Boot des Linux USB-Sticks
- Update der SSDs
Wir beginnen mit dem Wartungsmodus, Knoten 1 wird angehalten und es wird ein Ausgleich der Rollen gemacht.
Nun wird eins der beiden SAS-Kabel gezogen und der Server wird von dem USB-Stick gebootet.
Die Suche nach verfügbaren Datenträgern zeigt nun eine deutlich größere Anzahl an Datenträgern.
Nach dem Einspielen der Updates kann das zweite SAS-Kabel wieder eingesteckt und der Server rebootet werden. Der Knoten kann aus dem Wartungsmodus herausgenommen werden und wir können prüfen, ob ein Schwenk der Datenträger möglich ist.
Ein Auslesen der Firmware-Stände aller Datenträger sowie deren Größe zeigt die folgenden Informationen.
Die beiden Datenträger 19 und 31 hatten bereits die Version 5 der Firmware, Datenträger 21 und 32 zeigen noch die alte Version an.
An dieser Stelle habe ich eine der beiden SSDs mit der veralteten Firmware aus dem JBOD entfernt und kurze Zeit später wieder hinzugefügt um zu schauen, ob die SSD die Firmware aktiv schaltet, wenn sie stromlos gemacht wird. Dies war nicht der Fall, auch nach dem erneuten Einstecken wird die SSD mit der Firmware DA04 gemeldet. Diese Form von Update scheint nicht zu funktionieren, vermutlich liegt es daran das mehr als eine Verbindung zu der SSD aufgebaut ist und das Update somit übersprungen wird, obwohl es als erfolgreich gemeldet wird. Dies bedeutet, Sie müssen ein Update über die beiden anderen Wege weiter unten durchführen.
Ein Update einer SSD, die während dieser Zeit mit dem Status “Verbindung verloren” auftaucht
Bei dieser Art des Updates wird die SSD ohne vorherige Anpassung oder Änderung am Storage Pool wird die SSD, die geupdatet werden soll, einfach im laufenden Betrieb entfernt. Vor der Entfernung sieht dies so aus:
Nun wird die SSD aus dem Gehäuse entfernt.
Eine erneute Ausführung des PowerShell-Befehls zeigt nun eine Änderung im OperationalStatus:
Der Status der PhysicalDisk19 ändert sich in “Lost Communication”. Nun wird die SSD von dem Dell-Rahmen in den Rahmen des Intel JBODs gebaut und über das Intel JBOD an einen Server angeschlossen, über den die Aktualisierung der Firmware gemacht werden kann.
Auf diesem Server wird nun der Boot-Stick gestartet, über den das Update eingespielt werden kann.
a
Der Update-Vorgang ist nun beendet, die SSD kann aus dem Intel JBOD entfernt werden und wieder der Dell MD3060e hinzugefügt. Nachdem das System die SSD erneut erkannt hat wird diese auch wieder als “Healthy” aufgeführt.
Während dem Fehlen der SSD werden die vDisks in dem System wie folgt dargestellt.
Nachdem die SSD wieder hinzugefügt wurde ändert sich dieser Status ebenfalls wieder.
Das Update der ersten SSD ist nun durch, in meinem Fall müsste ich dies noch drei weitere Male durchführen, bis alle vier SSDs die neue Firmware besitzen. Den Unterschied zwischen dieser SSD und den Restlichen können wir uns ebenfalls per PowerShell auslesen:
Ein Update einer SSD, die manuell auf den Status “Retired” gesetzt wird.
Bei dieser Variante wird die SSD, die wir updaten möchten, vorab manuell in den Retired-Zustand versetzt. Dies bedeutet, dem Pool wird aktiv mitgeteilt, das dieser Datenträger entfernt werden soll. Nachdem wir uns den Namen des Datenträger herausgesucht haben (in meinem Fall PhysicalDisk31) wird dieser in den Zustand “Retired” gesetzt.
Im nächsten Schritt werden die virtuellen Datenträger repariert. Dies geschieht mit den folgenden Befehlen.
Nun kann der Datenträger entfernt werden. Falls Sie nicht genau wissen, an welchen Zustand sich die SSD oder die HDD befindet können Sie die LED-Benachrichtigung einschalten.
In der Hardware sieht dies wie folgt aus:
Nach dem Ausbau der SSD wird diese, genau wie sein Vorgänger, in das Intel JBOD eingebaut und mit Hilfe des USB Sticks geupdatet. Nach dem Update wird sie wieder in das Dell JBOD eingebaut, per PowerShell können wir hier sehen das die SDD wieder verfügbar ist.
Nun müssen wir den Datenträger (ebenfalls per PowerShell) in den Auto-Select-Modus versetzen, damit dieser wieder aktiv genutzt werden kann. Achten Sie hier darauf, dass die Usage auf “Auto-Select” steht, der Befehl aber “Autoselect” geschrieben wird.
In meinem Fall war nach dem Hinzufügen von PhysicalDisk31 die vDisk1 im Zustand “Degraded”. Diesen Zustand konnte ich durch den erneuten Start einer Reparatur beheben. Die Reparatur hat deutlich länger als vorher gedauert und war in dem aktiven PowerShell-Fenster auch im Vordergrund. In einem zweiten Fenster konnten die aktuell laufenden Tasks angezeigt werden.
Nach der Reparatur waren alle drei vDisks wieder in einem optimalen Zustand.
