{"id":95870,"date":"2020-10-04T13:41:59","date_gmt":"2020-10-04T11:41:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999"},"modified":"2020-10-04T13:41:59","modified_gmt":"2020-10-04T11:41:59","slug":"pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/pochemu-vazhno-proverit-po-na-vashej-shd-vysokoj-dostupnosti-999999","title":{"rendered":"Warum es wichtig ist, die Software auf Ihrem hochverf\u00fcgbaren (99,9999%) Speichersystem zu \u00fcberpr\u00fcfen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Warum<\/p>\n

Welche Firmware-Version ist die \"richtige\" und \"stabile\"? Wenn ein Speichersystem eine Verf\u00fcgbarkeit von 99,9999 % garantiert, bedeutet das, dass es auch ohne Software-Updates durchgehend funktionieren wird? Oder muss man im Gegenteil die neueste Firmware installieren, um die maximale Verf\u00fcgbarkeit zu gew\u00e4hrleisten? Wir versuchen, diese Fragen basierend auf unserer Erfahrung zu beantworten.<\/p>\n

Eine kurze Einf\u00fchrung<\/h3>\n

Wir alle verstehen, dass in jeder Softwareversion, sei es ein Betriebssystem oder ein Treiber f\u00fcr ein Ger\u00e4t, h\u00e4ufig Unzul\u00e4nglichkeiten\/Bugs und andere \"Besonderheiten\" enthalten sind, die m\u00f6glicherweise bis zum Ende der Lebensdauer der Hardware nicht offensichtlich sind oder nur unter bestimmten Bedingungen \"zutage treten\". Die Anzahl und Bedeutung solcher Nuancen h\u00e4ngt von der Komplexit\u00e4t (Funktionalit\u00e4t) der Software und der Qualit\u00e4t der Tests w\u00e4hrend ihrer Entwicklung ab. <\/p>\n

H\u00e4ufig bleiben Benutzer auf der \"Werksversion\" (das ber\u00fchmte - \"wenn es funktioniert, lass es\") oder installieren immer die neueste Version (in ihrem Verst\u00e4ndnis bedeutet neueste die stabilste). Wir hingegen verfolgen einen anderen Ansatz - wir schauen uns die Release-Notes f\u00fcr alle verwendeten Komponenten an. in der Cloud mClouds<\/a><\/noindex> Wir w\u00e4hlen sorgf\u00e4ltig die passende Firmware f\u00fcr jede Hardware aus. <\/p>\n

Diese Erkenntnis haben wir durch unsere Erfahrungen gewonnen. Anhand unserer eigenen Nutzung erl\u00e4utern wir, warum die versprochenen 99,9999 % Verf\u00fcgbarkeit von Speichersystemen bedeutungslos sind, wenn Sie die Software-Updates und Beschreibungen nicht rechtzeitig \u00fcberwachen. Unser Fall eignet sich f\u00fcr Nutzer von Speichersystemen jeder Marke, da eine solche Situation mit der Hardware jedes Herstellers auftreten kann.<\/p>\n

Die Auswahl eines neuen Speichersystems<\/h3>\n

Ende des letzten Jahres haben wir unserem Infrastrukturangebot ein interessantes Speichersystem hinzugef\u00fcgt: das Einstiegsmodell der IBM FlashSystem 5000-Serie, das zum Zeitpunkt des Kaufs als Storwize V5010e bekannt war. Jetzt wird es unter dem Namen FlashSystem 5010 verkauft, aber es handelt sich faktisch um dieselbe Hardware-Basissstruktur mit derselben Spectrum Virtualize Software. <\/p>\n

Das Vorhandensein eines einheitlichen Managementsystems ist \u00fcbrigens das Hauptunterscheidungsmerkmal der IBM FlashSystem. Bei den Modellen der Einstiegsserie unterscheidet es sich praktisch nicht von den leistungsst\u00e4rkeren Modellen. Die Wahl eines bestimmten Modells bietet lediglich die entsprechende Hardware-Basiskonfiguration, deren Spezifikationen es erm\u00f6glichen, entweder bestimmte Funktionen zu nutzen oder ein h\u00f6heres Ma\u00df an Skalierbarkeit zu gew\u00e4hrleisten. Die Software identifiziert dabei die Hardware und stellt die erforderlichen und ausreichenden Funktionen f\u00fcr diese Plattform bereit. <\/p>\n

\"WarumIBM FlashSystem 5010<\/p>\n

Ein kurzer \u00dcberblick \u00fcber unser Modell 5010. Es handelt sich um ein zweikontrollerbasiertes, blockbasiertes Speichersystem der Einstiegsklasse. Es unterst\u00fctzt die Verwendung von NLSAS-, SAS- und SSD-Laufwerken. NVMe-Integration ist bei diesem Modell nicht verf\u00fcgbar, da es f\u00fcr Anwendungen konzipiert ist, die keine NVMe-Leistung erfordern.<\/p>\n

Das Speichersystem wurde f\u00fcr die Ablage von Archivinformationen oder Daten angeschafft, die nicht h\u00e4ufig abgerufen werden. Daher war uns der Standardfunktionsumfang ausreichend: Tiering (Easy Tier), Thin Provisioning. Die Leistung auf NLSAS-Laufwerken im Bereich von 1000-2000 IOPS war ebenfalls f\u00fcr uns v\u00f6llig zufriedenstellend. <\/p>\n

Unsere Erfahrung \u2013 wie wir das Firmware-Update verpasst haben<\/h3>\n

Jetzt zum eigentlichen Thema des Software-Updates. Zum Zeitpunkt des Kaufs hatte das System bereits eine etwas veraltete Version der Software Spectrum Virtualize, und zwar die 8.2.1.3.<\/strong><\/p>\n

Wir haben die Beschreibung der Firmware untersucht und ein Update auf 8.2.1.9<\/strong>geplant. W\u00e4ren wir etwas z\u00fcgiger gewesen, g\u00e4be es diesen Artikel nicht \u2013 mit einer aktuelleren Firmware w\u00e4re dieser Fehler nicht aufgetreten. Aus bestimmten Gr\u00fcnden wurde das Update dieses Systems jedoch verschoben.<\/p>\n

Infolge einer kleinen Verz\u00f6gerung beim Update kam es zu einem \u00e4u\u00dferst unangenehmen Zustand, wie in der Beschreibung unter dem Link: https:\/\/www.ibm.com\/support\/pages\/node\/6172341<\/u><\/a><\/noindex>. <\/p>\n

Ja, in der Firmware dieser Version war gerade der sogenannte APAR (Authorized Program Analysis Report) HU02104 relevant. Dies \u00e4u\u00dfert sich folgenderma\u00dfen: Unter Last beginnt der Cache unter bestimmten Umst\u00e4nden zu \u00fcberlaufen, woraufhin das System in den Schutzmodus wechselt, in dem der Ein- und Ausgabe f\u00fcr den Pool deaktiviert wird. In unserem Fall sah es aus wie das Deaktivieren von 3 Disks f\u00fcr die RAID-Gruppe im RAID 6-Modus. Die Deaktivierung dauert 6 Minuten. Danach wird der Zugriff auf die Volumes im Pool wiederhergestellt.<\/p>\n

Falls jemand nicht mit der Struktur und Benennung logischer Entit\u00e4ten im Kontext von IBM Spectrum Virtualize vertraut ist, werde ich jetzt kurz darauf eingehen.<\/p>\n

\"WarumStruktur der logischen Elemente von Speichersystemen<\/p>\n

Die Festplatten werden in Gruppen zusammengefasst, die als MDisk (Managed Disk) bezeichnet werden. Ein MDisk kann ein klassisches RAID (0, 1, 10, 5, 6) oder ein virtualisiertes System \u2013 DRAID (Distributed RAID) \u2013 darstellen. Der Einsatz von DRAID erm\u00f6glicht eine h\u00f6here Leistung des Arrays, da alle Festplatten der Gruppe genutzt werden, und verringert die Rebuild-Zeit, da nur bestimmte Bl\u00f6cke und nicht alle Daten von der ausgefallenen Festplatte wiederhergestellt werden m\u00fcssen.<\/p>\n

\"WarumVerteilung der Datenbl\u00f6cke auf die Festplatten bei Verwendung von Distributed RAID (DRAID) im RAID-5-Modus.<\/p>\n

Dieses Schema zeigt die Logik des DRAID-Rebuilds, wenn eine Festplatte ausf\u00e4llt:<\/p>\n

\"WarumLogik des DRAID-Rebuilds bei Ausfall einer Festplatte<\/p>\n

Ein oder mehrere MDisk bilden einen sogenannten Pool. Innerhalb eines Pools wird nicht empfohlen, MDisk mit unterschiedlichen RAID-\/DRAID-Niveaus auf dasselbe Festplattentyp zu verwenden. Wir werden hier nicht zu sehr ins Detail gehen, da wir dies in einer der folgenden Artikel behandeln m\u00f6chten. Der Pool wird in Volumes unterteilt, die \u00fcber ein mehr oder weniger verwaltetes Protokoll f\u00fcr blockorientierten Zugriff an Hosts pr\u00e4sentiert werden.<\/p>\n

Wir bedanken uns daf\u00fcr, dass wir in einer Situation sind, die sich aus APAR HU02104<\/em>, einem logischen Ausfall von drei Laufwerken, der den MDisk unbrauchbar machte, was wiederum zum Ausfall des Pools und der entsprechenden Volumes f\u00fchrte.<\/p>\n

Da diese Systeme ziemlich \"intelligent\" sind, k\u00f6nnen sie mit dem Cloud-\u00dcberwachungssystem IBM Storage Insights verbunden werden, das automatisch bei einem Ausfall eine Supportanfrage an den IBM-Support sendet. Ein Ticket wird erstellt, und die IBM-Spezialisten f\u00fchren eine Fern-Diagnose durch und setzen sich mit dem Benutzer des Systems in Verbindung. <\/p>\n

Dank dessen wurde das Problem recht z\u00fcgig gel\u00f6st, und der Support hat eine zeitnahe Empfehlung zur Aktualisierung unseres Systems auf die bereits von uns gew\u00e4hlte Firmware 8.2.1.9 gegeben, in der das Problem zu diesem Zeitpunkt bereits behoben war. Das best\u00e4tigt das entsprechende Release-Note<\/u><\/a><\/noindex>.<\/u><\/p>\n

Zusammenfassungen und unsere Empfehlungen<\/h3>\n

Wie man sagt: \u201eGut ist, was gut endet\u201c. Der Fehler in der Firmware f\u00fchrte nicht zu ernsthaften Problemen \u2013 der Betrieb der Server wurde in k\u00fcrzester Zeit wiederhergestellt und es gab keinen Datenverlust. Bei einigen Kunden mussten virtuelle Maschinen neu gestartet werden, aber insgesamt waren wir auf negativere Folgen vorbereitet, da wir t\u00e4glich Sicherungskopien aller Elemente der Infrastruktur und der Kundensysteme erstellen. <\/p>\n

Wir haben die Best\u00e4tigung erhalten, dass selbst zuverl\u00e4ssige Systeme mit einer zugesicherten Verf\u00fcgbarkeit von 99,9999 % Aufmerksamkeit und rechtzeitige Wartung erfordern. Aus der Situation haben wir mehrere Erkenntnisse gewonnen und teilen unsere Empfehlungen:<\/p>\n