Stellen Sie sich das vor.

Welche Firmware-Version ist die „richtige“ und „funktionsfähige“? Wenn ein SAN eine Ausfallsicherheit von 99,9999 % garantiert, bedeutet das dann, dass es auch ohne Software-Updates unterbrechungsfrei funktioniert? Oder muss im Gegenteil für maximale Ausfallsicherheit immer die neueste Firmware installiert werden? Wir werden versuchen, diese Fragen basierend auf unserer Erfahrung zu beantworten.

Eine kleine Einführung

Wir alle verstehen, dass jede Version von Software, sei es ein Betriebssystem oder ein Treiber für ein bestimmtes Gerät, oft Mängel / Bugs und andere „Besonderheiten“ enthält, die sowohl bis zum Ende der Lebensdauer der Hardware nicht „auftreten“ können als auch nur unter bestimmten Bedingungen „sichtbar“ werden. Die Anzahl und Bedeutung solcher Nuancen hängt von der Komplexität (Funktionalität) der Software und von der Qualität der Tests während ihrer Entwicklung ab. 

Häufig bleiben die Nutzer bei der „Werksversion“ (das berühmte „funktioniert, also nicht draufgehen“) oder installieren immer die neueste Version (in ihrem Verständnis ist die letzte die funktionsfähigste). Wir verfolgen jedoch einen anderen Ansatz – wir schauen uns die Release-Notizen für alle verwendeten in der Cloud mClouds Geräte an und wählen sorgfältig die geeignete Firmware für jedes einzelne Gerät.

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

Auswahl eines neuen Speichersystems

Ende des letzten Jahres kam eine interessante Speichersystem zu unserer Infrastruktur hinzu: das Einstiegsmodell der IBM FlashSystem 5000-Serie, das zum Zeitpunkt des Kaufs den Namen Storwize V5010e trug. Heute wird es unter dem Namen FlashSystem 5010 verkauft, aber tatsächlich handelt es sich um dasselbe Hardware-Basis mit demselben Spectrum Virtualize im Inneren. 

Das Vorhandensein eines einheitlichen Verwaltungssystems ist übrigens das Hauptmerkmal des IBM FlashSystem. Bei den Modellen der unteren Serie unterscheidet sich dies praktisch nicht von den leistungsfähigeren Modellen. Die Wahl eines bestimmten Modells bietet lediglich die entsprechende Hardwarebasis, deren Eigenschaften es ermöglichen, den einen oder anderen Funktionsumfang zu nutzen oder ein höheres Maß an Skalierbarkeit zu gewährleisten. Die Software identifiziert dabei die Hardware und stellt die notwendige und ausreichende Funktionalität für diese Plattform zur Verfügung.

IBM FlashSystem 5010

Kurze Informationen zu unserem Modell 5010. Dies ist ein Blockspeichersystem der Einstiegsklasse mit zwei Controllern. Es unterstützt die Installation von NLSAS-, SAS- und SSD-Laufwerken. NVMe-Unterstützung ist nicht verfügbar, da dieses Modell als Lösung für Aufgaben positioniert ist, die keine NVMe-Leistung erfordern.

Das Speichersystem wurde für die Speicherung von Archivinformationen oder Daten angeschafft, auf die nicht häufig 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ür uns ebenfalls ausreichend.

Unsere Erfahrung — wie wir die Firmware nicht rechtzeitig aktualisiert haben

Nun zur eigentlichen Softwareaktualisierung. Zum Zeitpunkt des Erwerbs hatte das System bereits eine etwas veraltete Version der Software Spectrum Virtualize, nämlich 8.2.1.3.

. Wir haben die Firmwarebeschreibungen studiert und ein Update auf 8.2.1.9geplant. Hätten wir uns etwas schneller bewegt, gäbe es diesen Artikel nicht — mit einer neueren Firmware wäre dieser Fehler nicht aufgetreten. Aus bestimmten Gründen wurde das Update dieses Systems jedoch verschoben.

Infolgedessen führte eine kleine Verzögerung bei der Aktualisierung zu einem äußerst unangenehmen Bild, wie in der Beschreibung im Link: https://www.ibm.com/support/pages/node/6172341. 

Ja, in der Firmware dieser Version war gerade der sogenannte APAR (Authorized Program Analysis Report) HU02104 relevant. Er äußert sich wie folgt: Unter Last beginnt der Cache unter bestimmten Umständen zu überlaufen, wonach das System in den Schutzmodus wechselt, in dem der Ein- und Ausgabe für den Pool deaktiviert wird. In unserem Fall bedeutete das die Deaktivierung von 3 Laufwerken für eine RAID-Gruppe im RAID 6-Modus. Die Deaktivierung dauert 6 Minuten. Danach wird der Zugriff auf die Volumes im Pool wiederhergestellt.

Falls jemand mit der Struktur und der Benennung der logischen Entitäten im Kontext von IBM Spectrum Virtualize nicht vertraut ist, werde ich jetzt kurz darüber berichten.

Struktur der logischen Elemente von SAN

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 – DRAID (Distributed RAID) sein. Der Einsatz von DRAID ermöglicht eine Steigerung der Array-Leistung, da alle Festplatten der Gruppe verwendet werden, und reduziert die Rebuild-Zeit, da nur bestimmte Blöcke und nicht alle Daten von der ausgefallenen Festplatte wiederhergestellt werden müssen.

Verteilung der Datenblöcke auf Festplatten bei Verwendung von Distributed RAID (DRAID) im RAID-5-Modus.

Dieses Diagramm zeigt die Logik des DRAID-Rebuilds im Falle eines Ausfalls einer Festplatte:

Logik des DRAID-Rebuilds bei Ausfall einer Festplatte

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öchten hier nicht zu sehr ins Detail gehen, da wir dies in einem der nächsten Artikel behandeln wollen. Der Pool wird in Volumes unterteilt, die über einen bestimmten Blockzugriffsprotokoll an die Hosts präsentiert werden.

Nun, aufgrund der in APAR HU02104, beschriebenen logischen Ausfalls von drei Festplatten, wurde die MDisk, die wiederum zum Ausfall des Pools und der entsprechenden Volumes führte, unbrauchbar.

Da diese Systeme recht "intelligent" sind, können 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ühren remote eine Diagnose durch und kontaktieren den Benutzer des Systems. 

Dank dessen wurde das Problem recht zügig gelöst, und wir erhielten von dem Support-Team eine schnelle Empfehlung, unser System auf die bereits zuvor von uns ausgewählte Firmware 8.2.1.9 zu aktualisieren, in der dieser Fehler bereits behoben war. Das bestätigt die entsprechende Release Note.

Fazit und unsere Empfehlungen

Wie man sagt: „Gut ist, was gut endet“. Der Fehler in der Software führte nicht zu ernsthaften Problemen – die Serveroperationen wurden schnell wiederhergestellt, ohne dass Daten verloren gingen. Bei einigen Kunden musste die virtuellen Maschinen neu gestartet werden, aber insgesamt waren wir auf negativere Folgen vorbereitet, da wir täglich Backups aller Infrastruktur- und Kundenmaschinen durchführen. 

Wir haben die Bestätigung erhalten, dass selbst zuverlässige Systeme mit einer versprochenen Verfügbarkeit von 99,9999 % Aufmerksamkeit und rechtzeitige Wartung erfordern. Angesichts der Situation haben wir eine Reihe von Schlussfolgerungen gezogen und teilen unsere Empfehlungen:

• Es ist unbedingt erforderlich, die Veröffentlichung von Aktualisierungen zu verfolgen, die Release Notes auf potenziell kritische Korrekturen zu prüfen und geplante Aktualisierungen rechtzeitig durchzuführen.

  Dies ist ein organisatorischer und sogar recht offensichtlicher Punkt, auf den man eigentlich nicht näher eingehen sollte. Dennoch kann man an diesem „geraden Punkt“ ziemlich leicht stolpern. Faktisch war es genau dieser Punkt, der die beschriebenen Unannehmlichkeiten verursacht hat. Gehen Sie beim Erstellen der Upgrade-Regelung sehr sorgfältig vor und überwachen Sie deren Einhaltung ebenfalls aufmerksam. Dieser Punkt bezieht sich stärker auf das Konzept der „Disziplin“.

• Es ist immer besser, das System mit der aktuellen Softwareversion zu betreiben. Dabei ist die aktuelle nicht die mit der höchsten Versionsnummer, sondern die, die zeitlich später veröffentlicht wurde. 

  Beispielsweise hält IBM für seine Datenspeichersysteme mindestens zwei Softwareversionen aktuell. Zum Zeitpunkt des Schreibens dieses Artikels sind das 8.2 und 8.3. Aktualisierungen für 8.2 erscheinen früher. In der Regel folgt dann mit einer kleinen Verzögerung eine entsprechende Aktualisierung für 8.3.

  Die Version 8.3 bietet eine Reihe funktionaler Vorteile, zum Beispiel die Erweiterung von MDisk (im DRAID-Modus) durch das Hinzufügen einer oder mehrerer neuer Festplatten (diese Funktion ist seit Version 8.3.1 verfügbar). Dies ist eine recht grundlegende Funktionalität, aber in 8.2 gibt es diese Möglichkeit leider nicht.

• Wenn ein Upgrade aus irgendeinem Grund nicht möglich ist, empfiehlt der technische Support von IBM für die Softwareversionen von Spectrum Virtualize, die vor den Versionen 8.2.1.9 und 8.3.1.0 liegen (in denen der oben beschriebene Fehler relevant ist), die Systemleistung auf Poolebene zu begrenzen, wie im folgenden Bild gezeigt (der Screenshot wurde in der russisch lokalisierten Version der Benutzeroberfläche aufgenommen). Der Wert von 10000 IOPS dient als Beispiel und wird entsprechend den Spezifikationen Ihres Systems gewählt.

Leistungsbegrenzung des IBM Speichersystems

• Es ist notwendig, die Belastung auf die Speichersysteme richtig zu berechnen und eine Überlastung zu vermeiden. Dazu können Sie entweder den IBM Sizer verwenden (sofern Sie Zugriff darauf haben), die Hilfe von Partnern in Anspruch nehmen oder externe Ressourcen nutzen. Es ist auch wichtig, das Lastprofil des Speichersystems zu verstehen, da die Leistung in MB/s und IOPS erheblich variiert, je nach mindestens den folgenden Parametern:

  • Art der Operation: Lesen oder Schreiben,

  • Größe des Betriebsblocks,

  • das prozentuale Verhältnis von Lese- und Schreiboperationen im gesamten Datenfluss.

  Außerdem beeinflusst die Art und Weise, wie Datenblöcke gelesen werden, die Geschwindigkeit der Ausführung von Operationen: sequenziell oder zufällig. Bei der Ausführung mehrerer Datenzugriffsoperationen auf der Anwendungsseite gibt es den Begriff der abhängigen Operationen. Auch dies sollte berücksichtigt werden. All dies kann helfen, die Gesamtheit der Daten von den Leistungszählern des Betriebssystems, des Speichersystems, der Server-/Hypervisoren sowie das Verständnis der Besonderheiten der Arbeit von Anwendungen, Datenbankmanagementsystemen und anderen "Nutzern" von Datenträgerressourcen zu erkennen.

• Und schließlich ist es unbedingt erforderlich, regelmäßige Backups in einem aktuellen und funktionsfähigen Zustand zu haben. Der Backup-Zeitplan sollte basierend auf für das Geschäft akzeptablen RPO-Werten konfiguriert werden, und die Integrität der Backups sollte regelmäßig überprüft werden (viele Backup-Softwarehersteller haben in ihren Produkten automatisierte Überprüfungen implementiert), um ein akzeptables RTO zu gewährleisten.

Vielen Dank, dass Sie bis zum Ende gelesen haben.
Wir sind bereit, Ihre Fragen und Anmerkungen in den Kommentaren zu beantworten. Außerdem laden wir Sie ein, unserem Telegram-Kanal zu folgen., in dem wir regelmäßig Aktionen durchführen (Rabatte auf IaaS und Verlosungen von Gutscheincodes bis zu 100% auf VPS), interessante Nachrichten schreiben und neue Artikel im Habr-Blog ankündigen.

Quelle: habr.com