Dual-Controller, Cache und BBU in Speichersystemen: Warum sie benötigt werden und wie sie die Fehlertoleranz beeinflussen

Ein Storage-System mit zwei Controllern, geschütztem Cache und einem intakten BBU-Modul oder Superkondensator ist nicht deshalb zuverlässiger als ein einfaches Array, weil es „mehr Hardware“ enthält. Es ist zuverlässiger, weil es redundante Wege für den Datenzugriff und einen Mechanismus zum Schutz von Schreibvorgängen hat. Für Virtualisierung, Datenbanken, ERP, Dateispeicher und andere kritische Services sollte man mindestens ein Storage-System mit zwei Controllern wählen. Wichtig ist aber, nicht nur die Ausstattung zu prüfen, sondern die gesamte Kette: Controller, Cache, Cache-Schutzmodul, Firmware, Ports, Multipathing und Fehlerprotokolle.

Ein Enterprise-Storage fällt selten „mit einem Knopfdruck“ komplett aus. Häufig beginnt das Problem mit einer einzelnen Komponente: Controller, Port, Kabel, Cache-Batterie, Netzteil, Firmware oder Disk-Gruppe. Eine gute Architektur ist nötig, damit ein solcher Einzeldefekt nicht das gesamte Geschäftssystem stoppt.

Deshalb sollte man bei der Auswahl eines Storage-Systems nicht nur auf Kapazität und Anzahl der Laufwerke achten. Zwei Storage-Systeme mit gleicher Kapazität können sich in der realen Fehlertoleranz stark unterscheiden, wenn eines zwei Controller, geschützten Cache und geprüfte Pfade zu den Servern besitzt, während das andere nur einen Controller und einen unbekannten Batteriestatus hat.

Our most popular storage systems

Was ein Storage-Controller macht

Ein Controller ist das Verwaltungsmodul eines Storage-Systems. Er nimmt Anfragen von Servern entgegen, arbeitet mit Festplatten, RAID-Gruppen oder Pools, verwaltet Volumes, Cache, externe Ports und die interne Logik des Arrays.

Vereinfacht gesagt spricht ein Server in einem vollwertigen Storage-System nicht direkt mit jeder einzelnen Festplatte. Er kommuniziert mit dem Storage-Controller, und dieser entscheidet, wie die Anfrage innerhalb des Arrays verarbeitet wird.

Der Controller ist für mehrere wichtige Aufgaben verantwortlich:

• Entgegennahme von Lese- und Schreibbefehlen von Servern;
• Verteilung von Operationen auf Festplatten, SSDs, RAID-Gruppen oder Pools;
• Verwaltung von Volumes, Snapshots, Replikation und anderen Storage-Funktionen;
• Bedienung des Lese- und Schreibcaches;
• Arbeit mit Zugriffsports wie Fibre Channel, iSCSI, SAS oder anderen Schnittstellen;
• Übertragung von Daten an die Verwaltungsoberfläche;
• Protokollierung von Fehlern in Ereignisprotokollen;
• Beteiligung an Firmware-Updates und Lastumschaltung bei Ausfällen.

Deshalb sollte ein Controller nicht wie eine gewöhnliche RAID-Karte betrachtet werden. In einem Enterprise-Storage erfüllt er mehr Funktionen und hat einen deutlich größeren Einfluss auf die Datenverfügbarkeit.

Wenn nur ein Controller vorhanden ist, wird er zu einem potenziellen Single Point of Failure. Die Laufwerke können intakt sein und die Netzteile funktionieren, aber beim Ausfall des einzigen Controllers verlieren die Server den Zugriff auf die Volumes.

Ein Controller oder zwei: Was ist der reale Unterschied?

Ein Storage-System mit nur einem Controller kann für unkritische Aufgaben eine sinnvolle Option sein. Zum Beispiel für eine Testumgebung, ein Labor, ein temporäres Archiv oder eine zusätzliche Storage-Ebene, bei der Ausfallzeiten akzeptabel sind.

Die Vorteile einer solchen Architektur sind klar:

• geringere Kosten;
• einfachere Konfiguration;
• weniger Komponenten für die Wartung;
• einfachere Erstkonfiguration.

Die Einschränkungen sind jedoch ebenfalls erheblich:

• ein Controller-Ausfall bedeutet häufig Stillstand;
• ein Firmware-Update kann eine Abschaltung erfordern;
• der Austausch eines Controllers ohne Einfluss auf Services ist schwieriger;
• eine vollwertige Architektur mit redundanten Pfaden lässt sich nicht aufbauen;
• ein Teil der Hochverfügbarkeitsfunktionen ist nicht verfügbar oder eingeschränkt.

Ein Storage-System mit zwei Controllern ist anders aufgebaut. Es besitzt zwei Verwaltungsmodule, und bei korrekter Konfiguration kann der zweite Controller einen Teil der Last übernehmen oder den Betrieb fortsetzen, wenn der erste Controller ausfällt.

Zwei Controller bieten mehrere Vorteile:

• Server können über unterschiedliche physische Pfade mit dem Storage-System verbunden werden;
• der Ausfall eines Controllers muss nicht zum Verlust des Datenzugriffs führen;
• einige Wartungsarbeiten können ohne vollständige Abschaltung des Arrays durchgeführt werden;
• die Widerstandsfähigkeit gegenüber Ausfällen von Ports, Kabeln, Adaptern oder Switches steigt;
• der Schreibcache kann zwischen den Controllern gespiegelt werden.

Bei vielen Dell EMC Storage-Systemen basiert die Fehlertoleranz beispielsweise auf zwei Controllern, mehreren Ports und einer korrekt geplanten Verbindung zu den Servern. Die Bezeichnung Dual Controller allein garantiert jedoch keinen unterbrechungsfreien Betrieb. Wenn ein Server mit nur einem Kabel ausschließlich an einen Controller angeschlossen ist, existiert der zweite Controller zwar physisch, der Pfad zu ihm wird aber nicht genutzt.

Dual Controller schützt nicht vor allem. Er ersetzt keine Backups und schützt nicht vor:

• Löschung von Daten durch Benutzer;
• Beschädigung des Dateisystems;
• Ransomware;
• Fehlern des Administrators;
• fehlerhaften Firmware-Updates;
• Ausfall einer Disk-Gruppe über das tolerierbare RAID-Niveau hinaus;
• falsch konfigurierten Pfaden auf dem Server.

Korrekt ist es, zwei Controller als Grundlage für eine fehlertolerante Architektur zu betrachten, nicht als fertige Garantie für null Ausfallzeit.

Was passiert, wenn ein Controller ausfällt?

Das verständlichste Szenario ist der Ausfall eines von zwei Controllern. Ursache kann ein Hardwaredefekt, ein Hänger, ein Firmware-Fehler oder ein erzwungener Neustart während der Wartung sein.

In einer korrekt konfigurierten Umgebung sieht der Ablauf so aus:

1. Ein Controller stellt die Bedienung von Operationen ein.
2. Das Storage-System überträgt seine Ressourcen auf den verbleibenden Controller.
3. Die Server sehen die Volumes weiterhin über andere verfügbare Pfade.
4. Multipathing auf Serverseite wählt einen funktionierenden Pfad aus.
5. Anwendungen können eine Pause oder höhere Latenz bemerken, sollten aber den Datenzugriff nicht vollständig verlieren.

In der Praxis hängt vieles von der Anschlussarchitektur ab. Wenn jeder Server zwei Adapter, zwei unabhängige Pfade und eine korrekte Pfadauswahlrichtlinie besitzt, führt der Ausfall eines Controllers normalerweise nicht zu einem vollständigen Stillstand. War der Server jedoch nur mit dem ausgefallenen Controller verbunden, hilft der zweite Controller nicht automatisch: Es gibt keinen physischen Weg zu ihm.

Dasselbe gilt für Wartung. In Storage-Systemen mit zwei Controllern ist es häufig möglich, Controller nacheinander zu ersetzen oder neu zu starten. In der Dell PowerVault ME5-Dokumentation umfasst das Verfahren zum Austausch eines Controller-Moduls beispielsweise die Prüfung des Controller-Status, die Bestätigung der Bereitschaft zur Entnahme und die Kennzeichnung der Kabel vor dem Trennen. Das ist ein gutes Beispiel dafür, warum selbst „Hot“-Wartung Disziplin erfordert und nicht nach Gefühl durchgeführt werden sollte: Dell PowerVault ME5: Controller austauschen.

Vor dem Austausch oder Update eines Controllers sollte geprüft werden:

• ob die Server alle Pfade zu den Volumes sehen;
• ob auf dem zweiten Controller bereits Fehler vorhanden sind;
• ob der Cache synchronisiert ist;
• ob die Firmware-Versionen übereinstimmen;
• ob es Warnungen zu Netzteilen, Lüftern und Laufwerken gibt;
• ob ein aktuelles Backup vorhanden ist;
• ob ein Wartungsfenster mit niedriger Last gewählt wurde.

Auch wenn der Hersteller Wartung ohne vollständige Abschaltung erlaubt, ist ein geplantes Wartungsfenster sinnvoll. Eine fehlertolerante Architektur reduziert das Risiko von Ausfallzeiten, macht aber nicht jede Operation automatisch sicher.

Pfadverlust: Kabel, Port, Adapter oder Switch

In realen Infrastrukturen fällt häufiger nicht der gesamte Controller aus, sondern ein einzelner Pfad. Zum Beispiel:

• ein SFP-Modul fällt aus;
• ein Kabel wird beschädigt;
• ein Port am Controller fällt aus;
• ein SAN-Switch hängt;
• es gibt ein Problem mit dem Netzwerkadapter des Servers;
• die VLAN- oder iSCSI-Netzwerkkonfiguration ändert sich.

Wenn die Pfade korrekt aufgebaut sind, greift der Server weiterhin über eine andere Route auf dasselbe Volume zu. Dafür wird Multipathing verwendet: ein Mechanismus, bei dem das Betriebssystem oder der Hypervisor mehrere physische Pfade zu einem Storage-System sieht und sie als eine logische Festplatte behandelt.

Für Fibre Channel sieht eine typische Architektur so aus:

• im Server sind zwei HBA-Adapter installiert;
• es gibt zwei unabhängige SAN-Switches;
• jeder Server ist mit beiden Fabrics verbunden;
• das Storage-System hat Ports auf Controller A und Controller B;
• das Volume ist über mehrere Pfade verfügbar.

Bei iSCSI ist die Logik ähnlich, doch statt FC-Fabrics werden klassische Netzwerkschnittstellen und isolierte Netzwerke verwendet:

• mindestens zwei Netzwerkports am Server;
• zwei separate iSCSI-Netze oder VLANs;
• unterschiedliche Switches;
• unterschiedliche Storage-Ports;
• aktiviertes MPIO auf Windows, Linux oder Hypervisor-Seite.

Microsoft weist darauf hin, dass MPIO Hochverfügbarkeit und Fehlertoleranz für Storage in Hyper-V-, Cluster- und Virtualisierungsumgebungen unterstützt, Konfigurationsfehler jedoch zu Pfadverlust, Performanceproblemen und unerwarteten Ausfällen führen können.

Häufige Fehler in solchen Architekturen sind:

• beide Kabel sind an denselben Controller angeschlossen;
• beide Pfade führen über denselben Switch;
• MPIO ist nicht installiert oder nicht aktiviert;
• der Server sieht ein Volume als mehrere unterschiedliche Festplatten;
• die Pfadauswahlrichtlinie ist zufällig konfiguriert;
• iSCSI-Traffic läuft gemeinsam mit dem normalen Benutzernetz;
• Jumbo Frames sind nur auf einem Teil der Strecke aktiviert;
• ein Controller ist überlastet, während der zweite fast nicht genutzt wird.

Deshalb muss Dual Controller immer zusammen mit den Pfaden bewertet werden. Zwei Controller im Storage-System und ein einziges Kabel zum Server sind keine fehlertolerante Architektur, sondern nur die Möglichkeit, sie später aufzubauen.

Active-active, active-passive und ALUA einfach erklärt

In Beschreibungen von Storage-Systemen tauchen häufig die Begriffe active-active und active-passive auf. Man sollte sie nicht als Marketing-Etiketten verstehen, sondern als Beschreibung dafür, wie Controller Volumes bedienen.

Im Active-active-Modus können beide Controller an der Verarbeitung von Operationen beteiligt sein. Das ist nützlich, weil die Ressourcen des Arrays vollständiger genutzt werden. Es bedeutet aber nicht immer, dass jeder Pfad für jedes Volume gleich gut ist. In einigen Storage-Systemen hat ein Volume trotzdem einen bevorzugten Controller, über den Operationen schneller ausgeführt werden.

Im Active-passive-Modus bedient ein Controller das Volume aktiv, während der zweite auf einen Ausfall oder Rollenwechsel wartet. Diese Architektur ist einfacher, aber die Umschaltung kann deutlicher spürbar sein. Die Performance hängt davon ab, wo sich der Eigentümer des Volumes befindet und wie die Pfade konfiguriert sind.

ALUA ist ein Mechanismus, der dem Server hilft zu verstehen, welche Pfade zu einem Volume optimal sind und welche zwar verfügbar, aber weniger bevorzugt sind. Ein Server kann dasselbe Volume beispielsweise über beide Controller sehen, der beste Pfad führt jedoch über den Controller, dem dieses Volume aktuell gehört.

Broadcom VMware weist darauf hin, dass bei ALUA-Unterstützung die Round-Robin-Richtlinie standardmäßig aktive optimierte Pfade nutzt, während die erzwungene Nutzung nicht optimierter Pfade die Performance verschlechtern kann.

In der Praxis bedeutet das:

• nicht alle sichtbaren Pfade sind gleich nützlich;
• I/O sollte nicht blind über alle Pfade verteilt werden;
• für VMware, Windows und Linux sollten die konkreten Empfehlungen des Storage-Herstellers geprüft werden;
• wenn der Controller-Eigentümer eines Volumes wechselt, muss die Pfadrichtlinie korrekt reagieren;
• ALUA-Fehler können wie „seltsame“ Latenzen ohne offensichtlichen Ausfall aussehen.

Wenn die Performance nach dem Anschluss eines Dual-Controller-Storage-Systems niedriger als erwartet ist, sollte man nicht nur Laufwerke und Netzwerk prüfen, sondern auch, über welche Pfade die Last tatsächlich läuft.

Warum ein Storage-System Cache braucht

Cache ist schneller Speicher im Controller. Er wird benötigt, um den Unterschied zwischen der Geschwindigkeit der Server und der Geschwindigkeit des Festplattensubsystems abzufedern.

Cache kann für Lesevorgänge genutzt werden, wenn häufig verwendete Daten direkt aus dem Cache geliefert werden. Noch interessanter ist jedoch der Schreibcache.

Server können viele kleine Schreiboperationen senden. Für Festplatten und sogar für manche SSDs sind solche Operationen nicht immer schnell: Sie erzeugen zufällige Last, Warteschlangen und Latenzen. Der Storage-Controller nimmt diese Operationen an, legt sie vorübergehend im Cache ab und schreibt sie anschließend effizienter auf die Medien.

Cache hilft dabei:

• Schreiboperationen schneller zu bestätigen;
• kleine Schreibvorgänge zu Operationen zusammenzufassen, die für das Array günstiger sind;
• Lastspitzen zu glätten;
• wiederholte Lesevorgänge zu beschleunigen;
• Latenzen bei kurzen Aktivitätsspitzen zu reduzieren;
• den Betrieb von virtuellen Maschinen und Datenbanken stabiler zu halten.

Cache macht eine langsame Disk-Gruppe jedoch nicht unendlich schnell. Wenn die Last die Möglichkeiten der Laufwerke längere Zeit überschreitet, füllt sich der Cache, und das Storage-System arbeitet mit der realen Geschwindigkeit des Arrays. Deshalb ist Cache besonders bei variabler Last nützlich: bei Spitzen, Warteschlangen, vielen kleinen Operationen und periodischen Schreibbursts.

Für Datenbanken, Virtualisierung und Dateidienste ist Schreibcache oft wichtiger, als es aus trockenen Spezifikationen scheint. Zwei Storage-Systeme mit ähnlichen Laufwerken können sich unterschiedlich verhalten, wenn eines mehr Cache hat, dieser geschützt ist und im richtigen Modus arbeitet, während beim anderen der Cache wegen eines Batteriefehlers deaktiviert wurde.

Write-back und write-through: Warum der Cache-Modus so wichtig ist

In Storage-Systemen gibt es normalerweise zwei grundlegende Schreibmodi: write-through und write-back.

Write-through ist der vorsichtigere Modus. Das Storage-System bestätigt dem Server den Schreibvorgang erst, nachdem die Daten tatsächlich auf Festplatten oder SSDs geschrieben wurden. Das ist sicher, aber langsamer.

Write-back ist der leistungsstärkere Modus. Das Storage-System bestätigt den Schreibvorgang, nachdem die Daten den Controller-Cache erreicht haben. Das physische Schreiben auf die Laufwerke erfolgt später. Dieser Modus beschleunigt den Betrieb, erfordert aber geschützten Cache.

In der Dell PowerVault ME5-Dokumentation steht, dass in einem System mit zwei funktionierenden Controllern write-back standardmäßig aktiviert ist, während bei nur einem Controller oder beim Ausfall eines Controllers write-through als sichererer Modus verwendet wird. Dort wird auch die Rolle des Superkondensators beim Cache-Schutz bei Stromverlust erklärt.

Der Unterschied zwischen den Modi ist besonders bei schreibintensiven Lasten spürbar:

• Datenbanken;
• Virtualisierung;
• Anwendungsprotokolle;
• Terminalserver;
• VDI;
• Dateiserver mit vielen Benutzern;
• Backup mit Deduplizierung;
• Videoüberwachung mit konstantem Schreibstrom.

Wenn der Cache geschützt ist, bietet write-back normalerweise eine bessere Reaktionsfähigkeit. Wenn der Cache-Schutz fehlerhaft ist, kann das Array automatisch auf write-through umschalten. Aus Sicht des Administrators sieht das wie ein plötzlicher Einbruch der Schreibgeschwindigkeit aus. Aus Sicht des Storage-Systems ist es aber keine „Laune“, sondern eine Schutzreaktion: Das System bestätigt Schreibvorgänge nicht mehr schnell, solange es nicht sicher ist, dass Daten im Cache nicht verloren gehen.

BBU, Superkondensator und CacheVault: Was sie schützen

BBU, also Battery Backup Unit, ist ein Modul zur Notstromversorgung des Caches. In älteren Systemen wurden häufiger Batterien verwendet, in neueren dagegen Superkondensatoren und nichtflüchtiger Speicher. Der Zweck ist derselbe: Daten zu schützen, die vom Storage-System bereits angenommen, aber noch nicht auf die Medien geschrieben wurden.

Wichtig ist: Eine BBU versorgt nicht das gesamte Storage-System mit Strom und ersetzt keine UPS. Sie ist nicht dafür gedacht, dass das Array nach einem Stromausfall stundenlang weiterarbeitet. Ihre Aufgabe ist enger gefasst: den Inhalt des Schreibcaches zu erhalten oder dem Controller Zeit zu geben, diese Daten in nichtflüchtigen Speicher zu übertragen.

Eine klassische Batterie:

• versorgt den Cache bei einem Ausfall mit Strom;
• hat eine begrenzte Lebensdauer;
• altert mit der Zeit;
• kann einen Austausch erfordern;
• führt bei Fehlern häufig zur Deaktivierung von write-back.

Heute werden statt Batterien häufiger Superkondensatoren eingesetzt, die etwas anders arbeiten:

• sie liefern eine kurze Energiereserve;
• sie helfen, Daten aus dem Cache schnell zu sichern;
• sie sind normalerweise nicht für eine langfristige Stromversorgung ausgelegt;
• sie werden oft zusammen mit Flash-Speicher verwendet;
• sie halten länger als Batterien, erfordern aber ebenfalls regelmäßige Prüfungen und bei Bedarf Austausch.

CacheVault ist eine dieser Cache-Schutzvarianten, bei der Daten bei Stromverlust aus dem Cache-RAM in nichtflüchtigen Flash-Speicher übertragen werden. Nach Wiederherstellung der Stromversorgung kann der Controller die Daten zurückholen und den Schreibvorgang korrekt abschließen.

HPE verknüpft in der Beschreibung der Smart Storage Battery das Batteriemodul mit der Unterstützung des Datenschutzes im Cache für Controller und Storage-Geräte.

Beim Kauf oder bei der Wartung eines Storage-Systems sollte man nicht nur auf den Namen der Technologie achten, sondern auf den tatsächlichen Zustand:

• ob der Cache geschützt ist oder nicht;
• ob die Batterie geladen ist oder einen Fehler meldet;
• ob der Superkondensator die Diagnose besteht;
• ob es Ereignisse zur Umschaltung auf write-through gibt;
• ob Meldungen zu dirty cache vorhanden sind;
• ob die Firmware-Versionen der Controller übereinstimmen;
• ob das Modul ohne lange Ausfallzeit ersetzt werden kann;
• ob ein kompatibles Ersatzteil verfügbar ist.

Wenn die BBU fehlerhaft ist, kann das Storage-System weiterarbeiten, aber es ist nicht mehr die Konfiguration, für die beim Kauf bezahlt wurde. Formal sind die Volumes verfügbar, doch die Schreibleistung kann sinken und einige Cache-Modi stehen nicht mehr zur Verfügung.

Cache-Spiegelung zwischen Controllern

In Storage-Systemen mit zwei Controllern wird der Schreibcache häufig zwischen den Controllern dupliziert. Das schützt vor einer Situation, in der ein Controller Daten in den Cache annimmt, den Schreibvorgang gegenüber dem Server bestätigt, aber die Daten nicht mehr rechtzeitig auf die Laufwerke schreiben kann.

Der Prozess lässt sich so darstellen:

1. Der Server sendet einen Schreibvorgang an Controller A.
2. Controller A legt die Daten in seinem Cache ab.
3. Die Daten werden in den Cache von Controller B kopiert.
4. Das Storage-System bestätigt den Schreibvorgang gegenüber dem Server.
5. Wenn Controller A ausfällt, schließt Controller B die Operation ab.

Deshalb sind in einem fehlertoleranten Storage-System nicht nur zwei Controller als physische Platinen wichtig, sondern auch eine funktionierende Verbindung zwischen ihnen. Wenn der Cache nicht synchronisiert wird, ein Controller fehlerhaft ist, Firmware-Versionen voneinander abweichen oder der Inter-Controller-Kanal instabil ist, wird die Fehlertoleranz fragwürdig.

In den Ereignisprotokollen sollte man prüfen:

• Fehler bei der Cache-Synchronisierung;
• Meldungen zu dirty cache;
• Warnungen zu Batterie oder Superkondensator;
• Umschaltungen auf write-through;
• Controller-Neustarts;
• Verlust der Kommunikation zwischen Controllern;
• Port- und Pfadfehler.

Für refurbished Storage-Systeme ist das besonders wichtig. Ein Array kann sich einschalten lassen, Laufwerke anzeigen und sogar einen Basistest bestehen, obwohl es eine Historie kritischer Cache-Ereignisse hat. Dieses Risiko erkennt man nicht nur auf einem Foto der Frontseite.

Stromausfall: Was die BBU schützt und was die UPS schützen sollte

Ein Stromausfall sollte in mehrere Ebenen unterteilt werden.

1. Stromversorgung des gesamten Racks oder Serverraums. Hier helfen UPS-Systeme, zwei Einspeisungen, unterschiedliche PDUs, korrekte Phasenlast und ein sauberes Verfahren zum Herunterfahren.
2. Stromversorgung des Storage-Systems selbst. Hier sind zwei Netzteile wichtig, die an unterschiedliche Quellen angeschlossen sind. Wenn beide Netzteile in derselben PDU stecken, ist die reale Redundanz geringer, als es scheint.
3. Daten im Cache. Genau hier werden BBU, Superkondensator oder ein ähnlicher Schutz benötigt.

Wenn die Stromversorgung vollständig ausfällt, nimmt das Storage-System keine neuen Operationen mehr an. Für Daten, die dem Server bereits bestätigt wurden und sich noch im Cache befinden, ist jedoch eine andere Frage entscheidend: Kann der Controller sie bis zur Wiederherstellung der Stromversorgung erhalten?

BBU und UPS ersetzen einander nicht:

• eine UPS schützt die Infrastruktur vor einem sofortigen Stromausfall;
• eine BBU schützt den Controller-Cache;
• zwei Netzteile schützen vor dem Ausfall eines PSU oder einer Stromleitung;
• ein Backup schützt vor logischen Fehlern und Datenbeschädigung.

Eine zuverlässige Architektur nutzt alle diese Ebenen. Es ist gefährlich zu glauben, dass der BBU-Status im Storage-System unwichtig ist, nur weil im Rack eine UPS vorhanden ist. Die UPS kann überlastet, falsch angeschlossen, entladen oder während der Wartung getrennt sein. Der Cache-Schutz ist lokal im Array eingebaut.

BBU-Ausfall und Einbruch der Schreibleistung

Ein häufiger, nicht offensichtlicher Fall: Ein Storage-System beginnt plötzlich langsam zu schreiben, obwohl die Laufwerke intakt sind, das Netzwerk nicht überlastet ist und die Server normal arbeiten.

Die Ursache kann im Cache liegen. Wenn Batterie oder Superkondensator eine Prüfung nicht bestehen, kann das Storage-System write-back deaktivieren und Schreibvorgänge auf write-through umstellen. In diesem Modus muss jeder Schreibvorgang erst nach dem tatsächlichen Schreiben auf das Medium bestätigt werden, daher steigen die Latenzen.

Besonders sichtbar ist das dort, wo viele kleine Schreibvorgänge auftreten:

• Datenbankprotokolle;
• virtuelle Maschinen mit aktiven Laufwerken;
• Terminalfarmen;
• VDI;
• Buchhaltungssysteme;
• Dateifreigaben mit vielen Benutzern;
• Backup mit vielen Metadaten.

Von außen kann das so aussehen:

• Benutzer klagen über „Hänger“;
• virtuelle Maschinen reagieren langsamer;
• die Datenbank bestätigt Transaktionen langsamer;
• Diagramme der Schreiblatenz steigen;
• die Laufwerksauslastung wirkt hoch, obwohl das Problem früher nicht vorhanden war.

In einer solchen Situation sollte man nicht sofort Laufwerke austauschen oder das Netzwerk modernisieren. Zuerst sollte geprüft werden:

• Status der Batterie oder des Superkondensators;
• Cache-Modus auf den Volumes;
• Ereignisse zu auto write-through;
• Fehler zu dirty cache;
• Zustand beider Controller;
• Cache-Synchronisierung;
• letzte Firmware-Updates.

Wenn das Storage-System write-back selbst deaktiviert hat, sollte die Ursache behoben werden, statt den leistungsstarken Modus um jeden Preis zwangsweise zu aktivieren. Schnelle Schreibvorgänge ohne Cache-Schutz können gefährlicher sein als eine vorübergehende Degradierung, weil sie zu ungültigen Daten führen können.

Firmware-Updates und Wartung ohne Ausfallzeit

Zwei Controller helfen dabei, Wartung sorgfältiger durchzuführen. Das bedeutet aber nicht, dass Firmware jederzeit mitten im Arbeitstag aktualisiert werden kann.

Rückseite eines Storage-Systems. Bildquelle: DELL-Dokumentation

Während eines Updates kann ein Controller neu starten, und die Last wechselt vorübergehend auf den anderen. Danach wiederholt sich der Vorgang für den zweiten Controller. Auf dem Papier laufen die Services weiter. In der Praxis können Pausen, höhere Latenzen, erneute Pfadverbindungen und Fehler auftreten, wenn Multipathing falsch konfiguriert ist.

Vor einem Update sollte geprüft werden:

• ob aktive Fehler auf dem Storage-System vorhanden sind;
• ob beide Controller intakt sind;
• ob der Cache synchronisiert ist;
• ob BBU oder Superkondensator in Ordnung sind;
• ob alle Pfade auf den Servern sichtbar sind;
• ob Treiber und DSM/MPIO-Module kompatibel sind;
• ob ein aktuelles Backup vorhanden ist;
• ob ein Rollback-Plan oder Herstelleranweisungen vorliegen.

Firmware auf einem bereits degradierten Storage-System zu aktualisieren, ist riskant. Wenn ein Controller seit Langem im Warnzustand ist, die Batterie fehlerhaft ist, einige Pfade nicht verfügbar sind und die Protokolle voller Fehler sind, muss zuerst der Zustand des Arrays untersucht werden. Andernfalls kann geplante Wartung leicht zur Notfallwiederherstellung werden.

Woran erkennt man, ob ein Storage-System wirklich fehlertolerant ist?

Fehlertoleranz ist kein einzelnes Häkchen in einer Spezifikation. Sie entsteht aus mehreren Ebenen.

Eine gute Konfiguration umfasst normalerweise:

• zwei Controller;
• zwei Netzteile;
• geschützten Schreibcache;
• eine intakte BBU oder einen intakten Superkondensator;
• Laufwerksredundanz auf RAID- oder Pool-Ebene;
• zwei unabhängige Pfade von jedem Server;
• zwei SAN-Switches oder zwei isolierte iSCSI-Netze;
• aktiviertes Multipathing;
• eine korrekte Pfadauswahlrichtlinie;
• aktuelle und kompatible Firmware;
• Ereignisüberwachung;
• regelmäßige Prüfung der Protokolle;
• getestete Umschaltung bei Ausfall;
• Backups.

Eine Konfiguration, die auf dem Papier perfekt aussieht, gilt erst dann als zuverlässig, wenn Notfallübungen und Tests durchgeführt wurden.

Eine schlechte Konfiguration sieht ebenfalls oft vertraut aus:

• das Storage-System hat zwei Controller, aber der Server ist mit nur einem Kabel verbunden;
• beide Kabel führen zu einem Switch;
• der zweite Controller ist installiert, beteiligt sich aber nicht an der Bedienung der Volumes;
• write-back ist deaktiviert, aber der Administrator hat es nicht bemerkt;
• die BBU befindet sich im Warnzustand;
• die Firmware-Versionen der Controller unterscheiden sich;
• einige Ports wurden nicht geprüft;
• Protokolle wurden nach der Lieferung nicht exportiert;
• ein Test zur Trennung eines Pfads wurde nie durchgeführt.

Deshalb ist es bei der Auswahl eines Storage-Systems für Unternehmen sinnvoll, nicht zu fragen „Hat es Dual Controller?“, sondern „Wie ist die gesamte Kette des Datenzugriffs genau aufgebaut?“.

Prüfung eines refurbished Storage-Systems vor dem Kauf

Beim Kauf eines refurbished Storage-Systems sollte man sich nicht nur auf Modell, Anzahl der Laufwerke und Preis verlassen. Für solche Systeme ist der Zustand der Komponenten besonders wichtig, die für Fehlertoleranz verantwortlich sind: Controller, Cache, Schutzmodule, Ports, Firmware und Fehlerprotokolle.

Bei refurbished Storage-Systemen sind kleine Details besonders wichtig. Ein Array kann zum Beispiel zwei Controller haben, aber ein Port kann defekt sein. Oder eine Batterie ist installiert, hält aber keine Ladung mehr. Oder der Cache ist formal aktiviert, während die Protokolle regelmäßige Ereignisse zur Umschaltung in einen sicheren Modus enthalten.

Vor dem Kauf sollte geklärt werden:

1. Hat das Storage-System einen oder zwei Controller?
2. Bestehen beide Controller die Diagnose?
3. Stimmen die Firmware-Versionen überein?
4. Wie ist der Cache-Status?
5. Ist write-back aktiviert?
6. Wenn write-back deaktiviert ist, warum?
7. Wie ist der Status von BBU, Superkondensator oder CacheVault?
8. Gibt es dirty-cache-Fehler?
9. Wurden alle Ports geprüft?
10. Gibt es ein Event Log nach dem Testen?
11. Wurde ein Test mit Trennung eines einzelnen Pfads durchgeführt?
12. Wurde ein Test mit Trennung eines Controllers durchgeführt?
13. Gibt es Garantie auf Controller und Batteriemodule?
14. Können BBU, PSU, Lüfter oder Controller separat ersetzt werden?
15. Welche Komponenten sind neu und welche refurbished?

Für Einstiegs- und Mittelklasseaufgaben werden häufig HP Storage-Systeme, Dell PowerVault, Dell Unity, NetApp und andere Plattformen betrachtet. Die Marke allein löst jedoch nicht die Zuverlässigkeitsfrage. Wichtiger sind der konkrete Zustand des Geräts, seine Konfiguration und die Diagnoseergebnisse.

Storage systems

Bei welchen Aufgaben zwei Controller besonders wichtig sind

Dual Controller sollte dort fast als Pflicht gelten, wo Ausfallzeit schnell teuer wird.

Zu solchen Aufgaben gehören:

• Virtualisierung;
• Datenbank-Cluster;
• ERP- und Buchhaltungssysteme;
• Terminalserver;
• Dateispeicher für Unternehmen;
• VDI;
• Videoüberwachung mit kontinuierlicher Aufzeichnung;
• Backup, wenn das Storage-System der zentrale Speicherort für Sicherungen ist;
• Produktionssysteme;
• medizinische, finanzielle und buchhalterische Anwendungen.

In diesen Szenarien ist nicht nur die Datenerhaltung wichtig, sondern auch die Verfügbarkeit des Services. Manchmal reichen 10–15 Minuten ohne Zugriff auf Storage bereits aus, um eine Abteilung anzuhalten, eine Schicht zu unterbrechen oder ein SLA zu verletzen.

Ein Storage-System mit nur einem Controller kann akzeptabel sein für:

• Teststände;
• Labore;
• temporären Speicher;
• Archive ohne strenge Verfügbarkeitsanforderungen;
• eine dritte Backup-Ebene;
• Aufgaben, bei denen Ausfallzeit bereits als akzeptables Risiko eingeplant ist.

Wenn auf dem Array jedoch produktive virtuelle Maschinen, Datenbanken, Benutzerprofile oder gemeinsame Unternehmensordner liegen sollen, wirkt die Einsparung am zweiten Controller oft fragwürdig.

Warum zwei Controller nicht immer mehr Geschwindigkeit bedeuten

Ein verbreiteter Irrtum lautet: Wenn es zwei Controller gibt, muss das Storage-System doppelt so schnell arbeiten. Manchmal hilft der zweite Controller tatsächlich dabei, Last zu verteilen, aber der Performancegewinn hängt von der Architektur des Arrays ab.

Die Performance wird beeinflusst durch:

• Typ der Festplatten oder SSDs;
• RAID-Level oder Pool-Struktur;
• Größe und Modus des Caches;
• Anzahl der Ports;
• Netzwerk- oder SAN-Geschwindigkeit;
• Multipathing-Richtlinie;
• Verteilung der Volumes zwischen den Controllern;
• Charakter der Workload;
• Zustand der Batterie oder des Superkondensators.

Wenn alle Volumes faktisch von einem Controller bedient werden, kann der zweite ungenutzt bleiben. Wenn Pfade falsch konfiguriert sind, kann ein Teil der Operationen über eine nicht optimierte Route laufen. Wenn write-back deaktiviert ist, können Schreibvorgänge selbst auf guten Laufwerken langsam sein.

Deshalb sollte man bei der Performance-Diagnose nicht nur auf „Hardware“, sondern auch auf die Betriebslogik achten:

• welcher Controller Eigentümer des Volumes ist;
• welche Pfade aktiv sind;
• welche Pfade optimiert sind;
• wie I/O verteilt wird;
• ob Schreibcache aktiviert ist;
• ob Fehler beim Cache-Schutz vorhanden sind;
• ob ein bestimmter Port überlastet ist.

Zwei Controller sind ein Werkzeug für Fehlertoleranz und Lastverteilung, aber keine automatische Garantie für doppelte Geschwindigkeit.

Typische Missverständnisse über Dual Controller, Cache und BBU

„Dual Controller schützt Daten vor Verlust“

Er erhöht die Verfügbarkeit, ersetzt aber keine Backups. Wenn ein Benutzer eine Datei löscht, eine Datenbank logisch beschädigt wird oder Ransomware eine Freigabe verschlüsselt, bringt der zweite Controller die Daten nicht zurück. Dafür braucht man Backups, Snapshots, Replikation und Wiederherstellungsprozesse.

„Wenn eine UPS vorhanden ist, braucht man keine Cache-Batterie“

UPS und BBU lösen unterschiedliche Aufgaben. Eine UPS hält die Stromversorgung der Geräte aufrecht. Eine BBU oder ein Superkondensator schützt Daten, die dem Server bereits bestätigt wurden und sich noch im Cache befinden. Eine zuverlässige Architektur nutzt beide Ebenen.

„Write-back ist immer besser“

Write-back ist schneller, aber nur mit geschütztem Cache. Wenn der Cache-Schutz fehlerhaft ist, ist es sicherer, langsamer im write-through-Modus zu arbeiten, als Schreibvorgänge schnell ohne Garantie für Datenerhalt und Integrität zu bestätigen (!).

„Refurbished Storage-Systeme sind per Definition gefährlich“

Das Risiko hängt nicht vom Wort refurbished ab, sondern von der Diagnose. Ein refurbished Storage-System mit geprüften Controllern, intaktem Cache, sauberen Protokollen und Garantie kann eine sinnvolle Option sein. Ein solches Array ohne Prüfung von BBU, Firmware und Ports zu kaufen, ist jedoch eine schlechte Idee.

„Es reicht, ein Storage-System mit zwei Controllern zu kaufen“

Nein. Server müssen trotzdem korrekt angeschlossen, Multipathing konfiguriert, ALUA geprüft, Pfad- und Controller-Ausfall getestet, der Cache-Zustand bestätigt und Protokolle überwacht werden.

Wie man Fehlertoleranz in einer Spezifikation korrekt beschreibt

Die Formulierung „Das Storage-System ist fehlertolerant, weil es Dual Controller hat“ ist zu allgemein. Sie sagt nichts darüber aus, wie das Array angeschlossen ist, ob der Cache geschützt ist, ob die Ports intakt sind oder ob die Pfade konfiguriert wurden.

Eine genauere Formulierung wäre:

„Das Storage-System ist mit zwei Controllern, zwei Netzteilen, geschütztem Schreibcache und einem intakten BBU- oder Superkondensator-Modul ausgestattet. Server werden über zwei unabhängige Pfade mit konfiguriertem Multipathing an das Array angeschlossen. Vor der Inbetriebnahme werden Controller-Ausfall, Pfadverlust, Cache-Zustand, Firmware-Versionen und Ereignisprotokolle geprüft“.

Diese Formulierung bildet die Realität besser ab. Fehlertoleranz ist keine einzelne Komponente, sondern das Ergebnis der gesamten Architektur: Storage-System, Server, Adapter, Switches, Kabel, Firmware und Betriebssystemeinstellungen.

Worauf man zuerst achten sollte

Wenn ein Storage-System schnell bewertet werden muss, sollte man nicht mit der Kapazität beginnen, sondern mit Fragen zu Ausfallrisiken.

Prüfen Sie:

• ob zwei Controller installiert sind;
• ob beide Controller intakt sind;
• ob der Schreibcache geschützt ist;
• in welchem Modus der Cache arbeitet;
• ob BBU oder Superkondensator intakt sind;
• ob dirty cache vorhanden ist;
• ob Firmware-Versionen übereinstimmen;
• ob alle Ports funktionieren;
• ob zwei unabhängige Pfade von den Servern vorhanden sind;
• ob Multipathing konfiguriert ist;
• ob ein Pfadausfalltest durchgeführt wurde;
• ob aktuelle Protokolle ohne kritische Fehler vorliegen.

Für kritische Services ist es besser, ein Array mit geringerer Kapazität, aber zwei intakten Controllern, geschütztem Cache und geprüfter Anschlussarchitektur zu wählen, als ein größeres Storage-System mit unklarem Batterie-, Port- und Ereignisprotokollstatus. Bei der Datenspeicherung wird Zuverlässigkeit nicht nur durch die Anzahl der Terabyte bestimmt, sondern dadurch, was im Moment eines Ausfalls passiert.