Bei der Spiegelung des Storage wird in der Regel der gesamte Plattenplatz (der ASP) Ihrer IBM i – Umgebung gespiegelt. Dies geschieht auf technischer Basis einer Kopie jedes Bits auf den Platten an eine andere Stelle, entweder durch das Betriebssystem oder das Storage-System selbst. Hierfür benötigt es (bei älteren iSeries-Servern) ein zweites Gehäuse mit eigenem Festplatten-Controller, bei neueren IBM Power – Servern nimmt man ein zweites SAN-Gerät, welches die Daten vom primären SAN erhält.

Mischbetriebe sind möglich, zum Beispiel schließt man über entsprechende Verkabelung zwei unabhängig SAN-Storagesysteme an einen Server an, der sich selbst um die Spiegelung der einzelnen logischen Platten kümmert. Diese SAN-Lösung ermöglicht weitere Sicherungsvorgänge wie das Erstellen einer FlashCopy (Sicherung auf einen Zeitpunkt) eines laufenden Servers, oder zur Duplikation einer Umgebung zwecks Aufbau eines Testsystems etc.

Mit nur einem Server ist diese Lösung aber nur die halbe Miete – gespiegelter Storage nützt nichts, wenn der einzige Server ausfällt. Also hält man einen zweiten Server offline parat, der mit möglichst ähnlicher Hardware bei Bedarf den Betrieb übernimmt. Auch alle anderen Komponenten (Verkabelung, Switche, Konsole, Stromversorgung) sollte redundant ausgelegt sein – sonst scheitert das ganze Konzept an einer Kleinigkeit…

Vorteil dieser Lösung ist der recht problemlose Betrieb, die für den Server fast nicht zu messende zusätzliche Belastung (je nach Konfiguration) und der eher einfache Umschaltprozess.

Nachteilig sind die hohen Kosten für (im Idealfall) zwei komplette Systeme, Storages und Verkabelungen, der nicht vorhandene Schutz vor einzelnen Datenverlusten (eine Datei, eine Bibliothek, ein Spoolfile), sowie die nötige Bandbreite für das Spiegeln des gesamten Storage. Es ist technisch möglich, die Storage-Spiegelung via Internet auf ein entferntes Storage zu realisieren. Allerdings benötigen Sie dann eine hohe Sende-Bandbreite, um die Latenz gering zu halten, oder Sie haben die Gefahr einer hohen Latenz – der RPO kann mehrere Minuten bemessen sein, falls Sie nicht glücklicher Betreiber einer über mehrere Kilometer langen Glasfaser-Leitung mit mehreren Gigabit Bandbreite sind…

Hier liegt auch die größte Gefahr der Storage-Spiegelung: Gerade bei IBM i – Systemen sollte der Spiegel immer konsistent sein. Denn auch nur wenige Sekunden an nicht geschriebenen Datenblöcken kann die entfernte Kopie in einem ungewissen Zustand belassen. Stellen Sie sich vor, daß 5 Sekunden nicht geschriebene Disk-Blöcke auf dem Ziel-Storage fehlen, und Sie müssen den Betrieb umschalten. Der Zielserver bemerkt im Idealfall, daß einige Dateien inkonsistent sind, weil Datenblöcke fehlen. Mit Glück müssen nur logische Dateien wieder aufgebaut werden. Mit Pech haben Sie „Lücken“ in Datendateien, die zunächst nicht auffallen…

Daher wird Storage-Spiegelung von uns (im Rahmen der wirtschaftlichen Betrachtung) nur für den lokalen Betrieb empfohlen und bei uns für Ihre wichtigen Produktiv-Umgebungen durchgeführt.

(c) 2024 RZKH GmbH