Welche Version der Firmware ist die „richtige“ und „funktionsfähige“? Wenn das SAN eine Verfügbarkeit von 99,9999 % garantiert, bedeutet das dann, dass es auch ohne Software-Updates durchgängig funktioniert? Oder muss man im Gegenteil für maximale Verfügbarkeit immer die neueste Firmware installieren? Wir versuchen, diese Fragen anhand unserer Erfahrungen zu beantworten.
Eine kurze Einführung
Wir alle wissen, dass in jeder Version einer Software, sei es ein Betriebssystem oder ein Treiber für ein Gerät, oft Fehler und andere „Besonderheiten“ enthalten sind, die möglicherweise entweder bis zum Ende des Lebenszyklus der Hardware nicht „auffallen“ oder nur unter bestimmten Bedingungen „offenbart“ werden. Die Anzahl und Tragweite solcher Nuancen hängt von der Komplexität (Funktionalität) der Software und der Qualität der Tests während ihrer Entwicklung ab.
Oftmals bleiben Anwender auf der „Werkseinstellung“ (das berühmte - „fällt es nicht auf, dann lass es“) oder installieren immer die neueste Version (aus ihrer Sicht bedeutet die neueste, dass sie die funktionierendste ist). Wir verfolgen jedoch einen anderen Ansatz – wir sehen uns die Release-Notes für alle verwendeten an. Wir wählen sorgfältig die passende Firmware für jede Hardware aus.
Diese Erkenntnis haben wir durch unsere Erfahrungen gewonnen. Anhand unserer eigenen Nutzung erläutern wir, warum die versprochenen 99,9999 % Verfügbarkeit von Speichersystemen bedeutungslos sind, wenn Sie die Software-Updates und Beschreibungen nicht rechtzeitig überwachen. Unser Fall eignet sich für Nutzer von Speichersystemen jeder Marke, da eine solche Situation mit der Hardware jedes Herstellers auftreten kann.
Die Auswahl eines neuen Speichersystems
Ende letzten Jahres wurde unsere Infrastruktur um ein interessantes Speichersystem erweitert: das Einstiegsmodell der IBM FlashSystem 5000-Serie, das zum Zeitpunkt des Kaufs als Storwize V5010e bekannt war. Heute wird es unter dem Namen FlashSystem 5010 verkauft, aber es basiert faktisch auf der gleichen Hardware mit dem gleichen Spectrum Virtualize.
Das Vorhandensein eines einheitlichen Managementsystems ist übrigens das Hauptmerkmal des IBM FlashSystem. Die Modelle der Einstiegsreihe unterscheiden sich dabei kaum von den leistungsstärkeren Modellen. Die Wahl eines bestimmten Modells bietet lediglich die entsprechende Hardwarebasis, deren Eigenschaften es ermöglichen, bestimmte Funktionen zu nutzen oder ein höheres Maß an Skalierbarkeit zu gewährleisten. Die Software identifiziert dabei die Hardware und bietet die notwendige Funktionalität für diese Plattform.
IBM FlashSystem 5010
Ein kurzer Überblick über unser Modell 5010. Es handelt sich um ein zweikontrollerbasiertes, blockbasiertes Speichersystem der Einstiegsklasse. Es unterstützt die Verwendung von NLSAS-, SAS- und SSD-Laufwerken. NVMe-Integration ist bei diesem Modell nicht verfügbar, da es für Anwendungen konzipiert ist, die keine NVMe-Leistung erfordern.
Das Speichersystem wurde für die Ablage von Archivinformationen oder Daten angeschafft, die nicht häufig 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ür uns völlig zufriedenstellend.
Unsere Erfahrung – wie wir das Firmware-Update verpasst haben
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.
. Wir hatten die Firmware-Beschreibungen studiert und ein Update auf 8.2.1.9geplant. Wären wir etwas zügiger gewesen, gäbe es diesen Artikel nicht – mit einer aktuelleren Firmware wäre dieser Fehler nicht aufgetreten. Aus bestimmten Gründen wurde das Update dieses Systems jedoch verschoben.
Infolge einer kleinen Verzögerung beim Update kam es zu einem äußerst unangenehmen Zustand, wie in der Beschreibung unter dem Link: .
Ja, in der Firmware dieser Version war gerade der sogenannte APAR (Authorized Program Analysis Report) HU02104 relevant. Dies äußert sich folgendermaßen: Unter Last beginnt der Cache unter bestimmten Umständen zu überlaufen, woraufhin das System in den Schutzmodus wechselt, in dem der Ein- und Ausgabe für den Pool deaktiviert wird. In unserem Fall sah es aus wie das Deaktivieren von 3 Disks für die RAID-Gruppe im RAID 6-Modus. Die Deaktivierung dauert 6 Minuten. Danach wird der Zugriff auf die Volumes im Pool wiederhergestellt.
Falls jemand nicht mit der Struktur und Benennung logischer Entitäten im Kontext von IBM Spectrum Virtualize vertraut ist, werde ich jetzt kurz darauf eingehen.
Struktur der logischen Elemente von Speichersystemen
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 – DRAID (Distributed RAID) – darstellen. Der Einsatz von DRAID ermöglicht eine höhere Leistung des Arrays, da alle Festplatten der Gruppe genutzt werden, und verringert 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 die Festplatten bei Verwendung von Distributed RAID (DRAID) im RAID-5-Modus.
Dieses Schema zeigt die Logik des DRAID-Rebuilds, wenn eine Festplatte ausfällt:
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-/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öchten. Der Pool wird in Volumes unterteilt, die über ein mehr oder weniger verwaltetes Protokoll für blockorientierten Zugriff an Hosts präsentiert werden.
Wir bedanken uns dafür, dass wir in einer Situation sind, die sich aus APAR HU02104, einem logischen Ausfall von drei Laufwerken, der den MDisk unbrauchbar machte, was wiederum zum Ausfall des Pools und der entsprechenden Volumes führte.
Da diese Systeme ziemlich "intelligent" sind, können sie mit dem Cloud-Überwachungssystem 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ühren eine Fern-Diagnose durch und setzen sich mit dem Benutzer des Systems in Verbindung.
Dank dessen wurde das Problem recht zügig gelöst, und der Support hat eine zeitnahe Empfehlung zur Aktualisierung unseres Systems auf die bereits von uns gewählte Firmware 8.2.1.9 gegeben, in der das Problem zu diesem Zeitpunkt bereits behoben war. Das bestätigt .
Zusammenfassungen und unsere Empfehlungen
Wie das Sprichwort sagt: „Gut ist, was gut endet“. Der Bug in der Firmware hat keine schwerwiegenden Probleme verursacht — die Server wurden schnellstmöglich ohne Datenverlust wiederhergestellt. Einige Kunden mussten ihre virtuellen Maschinen neu starten, aber insgesamt waren wir auf gravierendere Konsequenzen besser vorbereitet, da wir täglich Backups aller Infrastruktur- und Kundensysteme erstellen.
Wir haben die Bestätigung erhalten, dass selbst zuverlässige Systeme mit einer zugesicherten Verfügbarkeit von 99,9999 % Aufmerksamkeit und rechtzeitige Wartung erfordern. Aus der Situation haben wir mehrere Erkenntnisse gewonnen und teilen unsere Empfehlungen:
Es ist unerlässlich, die Veröffentlichungen von Updates im Auge zu behalten, die Release Notes auf potenzielle kritische Behebungen zu prüfen und geplante Updates rechtzeitig durchzuführen.
Das ist ein organisatorischer und sogar recht offensichtlicher Punkt, dem man vermeintlich keine große Beachtung schenken sollte. Doch an diesem "glatten Ort" kann man leicht stolpern. Genau dieser Punkt hat die oben beschriebenen Probleme verursacht. Gehen Sie beim Erstellen der Aktualisierungsrichtlinien sehr sorgfältig vor und überwachen Sie deren Einhaltung mit gleicher Sorgfalt. Dieser Punkt bezieht sich stärker auf das Konzept der "Disziplin".
Es ist immer besser, das System mit der aktuellen Version der Software zu betreiben. Dabei bedeutet "aktuell" nicht, dass es sich um die Version mit der höchsten Nummer handelt, sondern um die mit dem neuesten Veröffentlichungsdatum.
Zum Beispiel hält IBM für seine Speicherlösungen mindestens zwei Softwareversionen auf dem neuesten Stand. Zum Zeitpunkt des Schreibens dieses Artikels sind das die Versionen 8.2 und 8.3. Die Updates für 8.2 erscheinen zuerst, gefolgt von einem ähnlichen Update für 8.3 mit einer kleinen Verzögerung.
Die Version 8.3 bietet eine Reihe funktionaler Vorteile, wie die Erweiterung von MDisk (im DRAID-Modus) durch das Hinzufügen einer oder mehrerer neuer Festplatten (diese Möglichkeit besteht seit Version 8.3.1). Es handelt sich um eine recht grundlegende Funktion, aber in 8.2 war diese Option leider nicht verfügbar.
Falls ein Upgrade aus irgendeinem Grund nicht möglich ist, empfiehlt der technische Support von IBM für Versionen der Software Spectrum Virtualize, die älter sind als 8.2.1.9 und 8.3.1.0 (in denen der oben beschriebene Fehler relevant ist), zur Verringerung des Risikos dessen Auftretens, die Systemleistung auf Poolniveau zu beschränken, wie unten dargestellt (der Screenshot wurde im russischen GUI erstellt). Der Wert von 10000 IOPS dient als Beispiel und wird entsprechend den Spezifikationen Ihres Systems angepasst.
Leistungsbegrenzung des IBM Storage Systems
Es ist wichtig, die Last auf Speichersysteme korrekt zu kalkulieren und Überlastungen zu vermeiden. Dazu können Sie entweder den IBM Sizer nutzen (sofern Zugang besteht), die Unterstützung von Partnern in Anspruch nehmen oder auf externe Ressourcen zurückgreifen. Es ist unbedingt erforderlich, das Lastprofil des Speichersystems zu verstehen, da die Leistung in MB/s und IOPS stark von mindestens den folgenden Parametern abhängt:
Art der Operation: Lesen oder Schreiben,
Größe des Operationblocks,
das prozentuale Verhältnis von Lese- zu Schreiboperationen im gesamten I/O-Flow.
Zudem beeinflusst die Art und Weise, wie die Datenblöcke gelesen werden – ob sequenziell oder zufällig – die Geschwindigkeit der Operationen. Bei der Durchführung mehrerer Datenzugriffsoperationen auf der Anwendungsseite gibt es das Konzept der abhängigen Operationen, was ebenfalls berücksichtigt werden sollte. All dies kann helfen, ein Gesamtbild der Daten aus den Leistungsmessungen des Betriebssystems, des Speichersystems, der Server/Hypervisoren sowie ein Verständnis für die Besonderheiten der Arbeit von Anwendungen, Datenbanken und anderen 'Ressourcennutzern' zu erhalten.
Und schließlich ist es unerlässlich, immer aktuelle und funktionsfähige Backups zu haben. Die Backup-Zeitpläne sollten basierend auf den geschäftlich akzeptablen Werten für RPO eingerichtet und die Integrität der Backups regelmäßig überprüft werden (viele Softwarehersteller für Backups haben in ihren Produkten automatisierte Prüfungen implementiert), um einen akzeptablen RTO-Wert zu gewährleisten.
Danke, dass Sie bis zum Ende gelesen haben.
Wir stehen bereit, Ihre Fragen und Anmerkungen in den Kommentaren zu beantworten. Außerdem, in dem wir regelmäßig Aktionen durchführen (Rabatte auf IaaS und Verlosungen von Gutscheincodes bis zu 100 % auf VPS), interessante Neuigkeiten schreiben und neue Artikel im Habra-Blog ankündigen.
Quelle: habr.com
