Hardware-Lifecycle 4-8-4: Ein MetroCluster-Umbau ohne Produktionsausfall

Wenn Storage-Hardware das Ende ihres Lebenszyklus erreicht, stehen Betreiber vor einer Grundsatzfrage: Rip-and-Replace mit Downtime-Fenster, oder ein kontrollierter Parallelbetrieb, bei dem alte und neue Systeme für eine Übergangszeit gemeinsam laufen? Bei einem aktuellen Kundenprojekt haben wir uns für Letzteres entschieden – mit dem Ziel, eine produktive NetApp-MetroCluster-IP-Umgebung von vier auf acht Nodes zu erweitern, den kompletten Workload auf die neue Generation zu heben, und die Altsysteme anschließend sauber aus dem Verbund zu lösen. Ein klassisches 4-8-4-Lifecycle-Muster, ergänzt um eine Erweiterung der Netzwerk-Fabric um zwei zusätzliche Switche mit eigenen ISL-Strecken.

Dieser Beitrag beschreibt den Weg dorthin – inklusive der Stolpersteine, die in keiner Schritt-für-Schritt-Anleitung stehen.

Ausgangslage

Die Umgebung: zwei Standorte, verbunden per MetroCluster IP, synchron gespiegelte Storage-Systeme der vorherigen Plattformgeneration. Die Aufgabe: vier neue All-Flash-Nodes integrieren (zwei je Standort), den kompletten produktiven Workload – CIFS-Freigaben, iSCSI-LUNs für Virtualisierungscluster, Fibre-Channel-LUNs für Hyper-V-CSVs – dorthin migrieren, und danach die Altgeneration kontrolliert abschalten. Parallel wurde die Ethernet-Fabric um zwei zusätzliche Switche erweitert, um die neuen Systeme mit ausreichend ISL-Bandbreite zwischen den Standorten anzubinden.

Auf dem Papier ein Standardvorgang, für den NetApp eine dokumentierte Prozedur bereitstellt. In der Praxis zeigte sich schnell: Die Dokumentation beschreibt den Idealfall. Reale Umgebungen mit Vorgeschichte – frühere Erweiterungsversuche, gewachsene Netzwerktopologien, unterschiedliche Hardware-Generationen im selben Cluster – bringen eigene Herausforderungen mit.

Problem 1: Eine hängende Transaktion aus einem früheren Anlauf

Noch bevor die neue Hardware überhaupt eingebaut war, zeigte ein Blick in die Cluster-Konfiguration: Ein früherer Erweiterungsversuch war nicht sauber abgeschlossen worden. Auf Diagnose-Ebene ließ sich eine hängende Transaktion in der internen Konfigurationsdatenbank nachweisen – ein Zustand, den man in der MetroCluster-Welt tunlichst vermeidet, denn er blockiert nachfolgende Konfigurationsänderungen an der DR-Gruppen-Struktur.

Die Lösung: Statt die Transaktion forciert zu löschen, haben wir einen kontrollierten Switchover/Switchback-Zyklus gefahren. Der reguläre Failover-Mechanismus hat die hängende Transaktion dabei sauber zu Ende geführt – ein Vorgehen, das Datenintegrität und Support-Fähigkeit wahrt, anstatt an interner Systemlogik vorbeizuoperieren.

Lektion: Vor jeder Erweiterung eines bestehenden MetroCluster-Systems lohnt sich ein gründlicher Gesundheitscheck der Konfigurationshistorie – nicht nur der aktuelle Status, sondern auch, ob frühere Change-Vorgänge tatsächlich vollständig abgeschlossen wurden.

Problem 2: Automatische Disk-Partitionierung folgt der falschen Logik

Moderne All-Flash-Systeme nutzen Advanced Drive Partitioning, um Kapazität flexibel zwischen lokalem Storage und Root-Aggregaten aufzuteilen. Das Verfahren ist beim Erststart eines Nodes vollautomatisch – mit einer Einschränkung, die selten thematisiert wird: Zum Zeitpunkt der Erstinitialisierung kannte das System nur die lokalen High-Availability-Partner, nicht aber die Partnersysteme am anderen Standort, da die MetroCluster-Verbindungen naturgemäß erst nach dem Cluster-Beitritt aufgebaut werden.

Ergebnis: Die automatische Partitionierung verteilte die Kapazität nach dem Muster eines lokalen HA-Paars – nicht nach dem für MetroCluster erforderlichen Cross-Site-Spiegelungsmuster. Als wir versuchten, die Root-Aggregate standortübergreifend zu spiegeln, quittierte das System den Vorgang mit „nicht genügend passende Spare-Disks“ – exakt an dieser Stelle war ein früherer Erweiterungsversuch bereits gescheitert.

Die Lösung: Eine vollständige, partitionsgenaue Neuzuweisung der Festplatten-Ownership zwischen den Standorten – nicht auf Ebene ganzer Disks, sondern auf Ebene einzelner Partitionen. Ein Vorgang, der Sorgfalt erfordert (jede Partition einzeln der richtigen Seite zuweisen), aber ohne jedes Risiko für bestehende Daten durchführbar ist, da zu diesem Zeitpunkt sämtliche betroffenen Partitionen noch ungenutzte Spares waren.

Lektion: „Automatisch konfiguriert“ bedeutet nicht zwangsläufig „korrekt für die Zielarchitektur konfiguriert“. Bei MetroCluster-Erweiterungen sollte die tatsächliche Disk-Verteilung nach der Ersteinrichtung immer verifiziert werden, bevor der nächste Schritt (Root-Mirror) angestoßen wird.

Problem 3: Zwei zusätzliche Switche – dieselbe Sorgfalt für Monitoring wie für Konnektivität

Die Erweiterung der Fabric um zwei neue Switche brachte einen Aspekt mit, der leicht übersehen wird: Konnektivität ist nicht gleich Monitoring-Fähigkeit. Die neuen Switche kommunizierten technisch einwandfrei mit dem Storage-Cluster – die Health-Überwachung des Clusters meldete sie jedoch als nicht überwachbar, weil die SNMP-Community für das Cluster-Switch-Health-Monitoring bei der initialen Konfiguration schlicht nicht auf die neuen Geräte übertragen worden war.

Die Lösung: Ein Abgleich der erwarteten Monitoring-Konfiguration zwischen Storage-System und Switch-Konfiguration – zwei Zeilen Konfiguration pro Switch, danach vollständige Sichtbarkeit inklusive Modell- und Versionserkennung.

Lektion: Bei jeder Fabric-Erweiterung gehört die Monitoring-Integration auf dieselbe Checkliste wie die reine Datenkonnektivität. Ein Switch, der Daten transportiert, aber vom Health-Monitoring nicht gesehen wird, ist ein blinder Fleck – gerade in einer Architektur, die im Ernstfall automatisiert reagieren soll.

Problem 4: Der „unsichtbare Wächter“ kannte die neue Hälfte des Clusters nicht

MetroCluster-Umgebungen mit automatischem Failover-Schutz nutzen häufig einen externen Tiebreaker-Dienst, der bei einem vollständigen Standortausfall die Entscheidung für einen automatischen Switchover trifft. Dieser Dienst war beim Kunden bereits vor der Erweiterung im Einsatz – kannte aber naturgemäß nur die vier ursprünglichen Nodes.

Bei der Reaktivierung nach der Erweiterung zeigte sich eine zusätzliche Komplikation: Der Dienst lief auf einer seit Jahren nicht aktualisierten Version, deren Registrierungsmechanismus nicht mehr sauber mit der aktuellen Storage-Software-Version harmonierte.

Die Lösung: Eine kontrollierte Neu-Registrierung des Tiebreaker-Dienstes für die komplette Acht-Node-Konfiguration, verbunden mit der Empfehlung, den Dienst zeitnah auf eine aktuelle Version zu heben – ältere Versionen funktionieren zwar in der Regel weiter, verzichten aber auf Sicherheitsaktualisierungen, die in einer produktiven Umgebung nicht optional sein sollten.

Lektion: Komponenten, die „einfach laufen“, ohne dass sie im Tagesgeschäft auffallen, geraten leicht aus dem Patch-Zyklus. Ein Hardware-Lifecycle-Projekt ist der richtige Anlass, auch diese Nebenkomponenten auf den Prüfstand zu stellen.

Das Ergebnis

Nach Abschluss der Migration lief die komplette Produktion – Dateifreigaben, virtualisierte Umgebungen, Hyper-V-Cluster – auf der neuen Hardware-Generation, bei durchgehender Verfügbarkeit für die Endanwender. Die Kapazität wurde dabei nicht nur ersetzt, sondern gezielt nach Workload-Charakteristik neu zugeschnitten: ein groß dimensioniertes, gespiegeltes Aggregat je Standort für die Hauptlast, ein kleineres, bewusst freigehaltenes Aggregat als Wachstumsreserve für künftige Anforderungen.

Die Altsysteme laufen aktuell in einer Beobachtungsphase mit, bevor sie im nächsten Schritt formal aus dem MetroCluster-Verbund gelöst werden – ein Vorgang, der aufgrund seiner Tragweite bewusst als eigenständiges, mit dem Hersteller abgestimmtes Projekt behandelt wird.

Fazit

Ein 4-8-4-Hardware-Lifecycle in einer produktiven MetroCluster-Umgebung ist mit der richtigen Vorbereitung ohne Downtime realisierbar – vorausgesetzt, man plant nicht nur den Idealpfad, sondern auch die Abweichungen davon ein: gewachsene Konfigurationshistorie, automatisierte Prozesse, die nicht immer die Zielarchitektur kennen, und Nebenkomponenten wie Monitoring und Tiebreaker-Dienste, die ebenso sorgfältige Behandlung verdienen wie die Hauptmigration selbst.

Sie planen eine Erweiterung oder Migration Ihrer NetApp-MetroCluster- oder SAN-Infrastruktur? Sprechen Sie uns an – wir bringen 13 Jahre Enterprise-Storage- und SAN-Projekterfahrung mit NetApp MetroCluster und Brocade SAN Fabric Design mit.