{"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":"Stellen Sie sich das vor.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Stellen<\/p>\n

Welche Firmware-Version ist die \"richtige\" und \"funktionsf\u00e4hige\"? Wenn das Speichersystem eine Ausfallsicherheit von 99,9999 % garantiert, bedeutet das dann, dass es auch ohne Software-Updates kontinuierlich arbeiten wird? Oder ist es im Gegenteil notwendig, um maximale Ausfallsicherheit zu erreichen, immer die neueste Firmware zu installieren? Wir werden versuchen, diese Fragen basierend auf unserer Erfahrung zu beantworten.<\/p>\n

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

Wir alle wissen, dass jede Version einer Software, sei es ein Betriebssystem oder ein Treiber f\u00fcr ein Ger\u00e4t, oft M\u00e4ngel \/ Bugs und andere \"Besonderheiten\" enth\u00e4lt, die entweder bis zum Ende der Lebensdauer der Hardware \"nicht zum Vorschein kommen\" oder sich nur unter bestimmten Bedingungen \"zeigen\". Die Anzahl und Relevanz solcher Nuancen h\u00e4ngt von der Komplexit\u00e4t (Funktionalit\u00e4t) der Software und von der Qualit\u00e4t der Tests w\u00e4hrend ihrer Entwicklung ab. <\/p>\n

H\u00e4ufig bleiben Benutzer auf der \"Werksversion\" (das ber\u00fchmte \u201efunktioniert, also nicht anfassen\") oder installieren immer die neueste Version (in ihrem Verst\u00e4ndnis bedeutet die neueste die funktionsf\u00e4higste). Wir verfolgen jedoch einen anderen Ansatz \u2013 wir schauen uns die Release-Notizen f\u00fcr alle verwendeten Software an. in der Cloud mClouds<\/a><\/noindex> Ger\u00e4te an und w\u00e4hlen sorgf\u00e4ltig die geeignete Firmware f\u00fcr jedes einzelne Ger\u00e4t. <\/p>\n

Zu dieser Erkenntnis sind wir, sozusagen, aus Erfahrung gekommen. Anhand unserer eigenen Nutzung werden wir erkl\u00e4ren, warum die versprochenen 99,9999 % Zuverl\u00e4ssigkeit des SANs nichts bedeuten, wenn Sie nicht rechtzeitig auf die Aktualisierungen und Beschreibungen der Software achten. Unser Fall eignet sich f\u00fcr Nutzer von SANs jedes Anbieters, da eine solche Situation mit der Hardware jedes Herstellers auftreten kann.<\/p>\n

Auswahl eines neuen Speichersystems<\/h3>\n

Ende letzten Jahres wurde unsere Infrastruktur um ein interessantes Datenspeichersystem erweitert: das Einstiegsmodell der IBM FlashSystem 5000-Serie, das zu dem Zeitpunkt als Storwize V5010e bekannt war. Jetzt wird es unter dem Namen FlashSystem 5010 verkauft, aber faktisch ist es dieselbe Hardware-Basis mit demselben Spectrum Virtualize. <\/p>\n

Das Vorhandensein eines einheitlichen Verwaltungssystems ist \u00fcbrigens das Hauptmerkmal des IBM FlashSystem. Bei den Modellen der Einstiegsserie unterscheidet es sich praktisch nicht von den leistungsf\u00e4higeren Modellen. Die Auswahl eines bestimmten Modells bietet lediglich die entsprechende Hardware-Basis, deren Eigenschaften es erm\u00f6glichen, die jeweilige Funktionalit\u00e4t zu nutzen oder ein h\u00f6heres Ma\u00df an Skalierbarkeit zu gew\u00e4hrleisten. Die Software identifiziert dabei den Hardware-Teil und bietet die notwendige und ausreichende Funktionalit\u00e4t f\u00fcr diese Plattform. <\/p>\n

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

Kurze Informationen zu unserem Modell 5010. Dies ist ein Blockspeichersystem der Einstiegsklasse mit zwei Controllern. Es unterst\u00fctzt die Installation von NLSAS-, SAS- und SSD-Laufwerken. NVMe-Unterst\u00fctzung ist nicht verf\u00fcgbar, da dieses Modell als L\u00f6sung f\u00fcr Aufgaben positioniert ist, die keine NVMe-Leistung erfordern.<\/p>\n

Das Speichersystem wurde f\u00fcr die Speicherung von Archivinformationen oder Daten angeschafft, auf die nicht h\u00e4ufig zugegriffen wird. Daher war uns das Standardfunktionsset ausreichend: Tiering (Easy Tier) und Thin Provisioning. Die Leistung der NLSAS-Laufwerke im Bereich von 1000-2000 IOPS war f\u00fcr uns ebenfalls ausreichend. <\/p>\n

Unsere Erfahrung \u2014 wie wir die Firmware nicht rechtzeitig aktualisiert haben<\/h3>\n

Nun zur eigentlichen Softwareaktualisierung. Zum Zeitpunkt des Erwerbs hatte das System bereits eine etwas veraltete Version der Software Spectrum Virtualize, n\u00e4mlich 8.2.1.3.<\/strong><\/p>\n

Wir haben die Firmware-Beschreibungen studiert und ein Update auf 8.2.1.9<\/strong>geplant. H\u00e4tten wir uns etwas schneller bewegt, g\u00e4be es diesen Artikel nicht \u2014 mit einer neueren Firmware w\u00e4re dieser Fehler nicht aufgetreten. Aus bestimmten Gr\u00fcnden wurde das Update dieses Systems jedoch verschoben.<\/p>\n

Infolgedessen f\u00fchrte eine kleine Verz\u00f6gerung bei der Aktualisierung zu einem \u00e4u\u00dferst unangenehmen Bild, wie in der Beschreibung im 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. Er \u00e4u\u00dfert sich wie folgt: Unter Last beginnt der Cache unter bestimmten Umst\u00e4nden zu \u00fcberlaufen, wonach das System in den Schutzmodus wechselt, in dem der Ein- und Ausgabe f\u00fcr den Pool deaktiviert wird. In unserem Fall bedeutete das die Deaktivierung von 3 Laufwerken f\u00fcr eine 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 mit der Struktur und der Benennung der logischen Entit\u00e4ten im Kontext von IBM Spectrum Virtualize nicht vertraut ist, werde ich jetzt kurz dar\u00fcber berichten.<\/p>\n

\"StellenStruktur der logischen Elemente von SAN<\/p>\n

Die Festplatten werden in Gruppen zusammengestellt, die als MDisk (Managed Disk) bezeichnet werden. Eine MDisk kann ein klassisches RAID (0, 1, 10, 5, 6) oder ein virtualisiertes RAID \u2013 DRAID (Distributed RAID) sein. Der Einsatz von DRAID erm\u00f6glicht eine Steigerung der Array-Leistung, da alle Festplatten der Gruppe verwendet werden, und reduziert die Rebuild-Zeit, da nur bestimmte Bl\u00f6cke und nicht alle Daten von der ausgefallenen Festplatte wiederhergestellt werden m\u00fcssen.<\/p>\n

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

Dieses Diagramm zeigt die Logik des DRAID-Rebuilds im Falle eines Ausfalls einer Festplatte:<\/p>\n

\"StellenLogik 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- oder DRAID-Niveaus auf Festplatten desselben Typs zu verwenden. Wir m\u00f6chten hier nicht zu sehr ins Detail gehen, da wir dies in einem der n\u00e4chsten Artikel behandeln wollen. Der Pool wird in Volumes unterteilt, die \u00fcber einen bestimmten Blockzugriffsprotokoll an die Hosts pr\u00e4sentiert werden.<\/p>\n

Nun, aufgrund der in APAR HU02104<\/em>, beschriebenen logischen Ausfalls von drei Festplatten, wurde die MDisk, die wiederum zum Ausfall des Pools und der entsprechenden Volumes f\u00fchrte, unbrauchbar.<\/p>\n

Da diese Systeme recht \"intelligent\" sind, k\u00f6nnen sie mit dem Cloud-Monitoring-System IBM Storage Insights verbunden werden, das automatisch bei einem Fehler eine Wartungsanfrage an den IBM-Support sendet. Es wird ein Ticket erstellt und die Spezialisten von IBM f\u00fchren remote eine Diagnose durch und kontaktieren den Benutzer des Systems. <\/p>\n

Dank dessen wurde das Problem recht z\u00fcgig gel\u00f6st, und wir erhielten von dem Support-Team eine schnelle Empfehlung, unser System auf die bereits zuvor von uns ausgew\u00e4hlte Firmware 8.2.1.9 zu aktualisieren, in der dieser Fehler bereits behoben war. Das best\u00e4tigt die entsprechende Release Note<\/u><\/a><\/noindex>.<\/u><\/p>\n

Fazit und unsere Empfehlungen<\/h3>\n

Wie man so sch\u00f6n sagt: \u201eGut ist, was gut endet\u201c. Der Fehler in der Firmware f\u00fchrte nicht zu ernsthaften Problemen \u2013 die Server wurden in k\u00fcrzester Zeit ohne Datenverlust wiederhergestellt. Bei einigen Kunden mussten virtuelle Maschinen neu gestartet werden, aber insgesamt waren wir auf gravierendere Konsequenzen vorbereitet, da wir t\u00e4glich Sicherungskopien aller Elemente der Infrastruktur und der Kundenmaschinen erstellen. <\/p>\n

Wir haben die Best\u00e4tigung erhalten, dass selbst zuverl\u00e4ssige Systeme mit einer versprochenen Verf\u00fcgbarkeit von 99,9999 % Aufmerksamkeit und rechtzeitige Wartung erfordern. Angesichts der Situation haben wir eine Reihe von Schlussfolgerungen gezogen und teilen unsere Empfehlungen:<\/p>\n