Die Mär vom synchron gespiegelten Storage

Samstag, 1. Juni 2013

Es scheint so einfach zu sein: das zentrale Storage wird ergänzt um ein zweites (wahrscheinlich identisches), ein "synchroner Spiegel" wird zwischen den beiden eingerichtet - und fertig ist das Disaster Recovery Konzept, bei dem ganz bestimmt keine Daten verloren gehen.

Solche oder ähnliche Meinungen treffen wir durchaus oft an (interessanterweise ist diese Denkweise offensichtlich vor allem ein deutsches Phänomen).

Nur: bei genauerer Betrachtung ist es doch etwas komplizierter.

Gerne vergessen wird zum Beispiel, dass das, was zu einem bestimmten Zeitpunkt "auf der Festplatte steht" keineswegs ein konsistenter - geschweige denn vollständiger - Datenbestand sein muss. Caching, Buffer, unvollendete Transaktionen etc. führen dazu, dass - natürlich schön synchron - auf beiden beteiligten Storage Systemen inkonsistente Informationen vorhanden sind.

Beispiel Virtualisierung

Betrachten wir exemplarisch ein gängiges Szenario: zwei Storage-Systeme sind Bestandteil einer Virtualisierungsumgebung und stehen räumlich getrennt in unterschiedlichen Brandschutzabschnitten - der Einfachheit halber in einer gespiegelten aktiv/passiv-Konfiguration angenommen. Eine häufige Ausfallursache: die Stromversorgung in einem der RZ (natürlich ist bei Ihnen eine USV vorhanden - eben die ist aber gerne mal am Ausfall beteiligt).

Der HA-Mechanismus der Virtualisierung startet die virtuellen Maschinen nach einem Ausfall der Virtualisierungshosts neu. Das ist im Zweifel dann allerdings so, als würden Sie einen physischen Server aus- und wieder einschalten. Also: keineswegs sind alle Daten vorhanden - sondern die Anwendung geht in einen (applikationsspezifischen) Recovery Modus; angefangen vom Check des File Systems bis hin zum Datenbank-Recovery.

Kern des Problems ist letzlich die fehlende Kopplung des Fail Overs zwischen Hosts und Storage: Tools wie der VMware Site Recovery Manager adressieren dieses Thema. Diese basieren aber zur Sicherung der Datenkonsistenz heute eher auf Snapshot-Technologien und haben deshalb asynchronen Charakter.

Die aktuelle Kommunikation von VMware zielt auch deutlich mehr auf eine integrative Sicht: hier ist mehr die Rede von komplett virtualisierten Rechenzentren - also inklusive Netzwerk und Storage - und nicht mehr nur von Host-Farmen.

So soll der Fail Over eines kompletten RZ in eine Backup-Site durch die Virtualisierung abgebildet werden - idealerweise mit einem eng integrierten Storage, so dass die nötige Daten-Replikation möglichst effizient erfolgt.

Performance-Aspekte

Nicht vergessen werden sollten auch Leistungsaspekte: synchrone Spiegel implizieren immer einen gewissen Aufwand, die Daten zum zweiten Controller zu bringen und auf die Quittierung zu warten.

Das kann in Zeiten von deutlich steigender Performance (Stichwort "Flash") schon einen signifikanten Einfluss auf die Latenzzeiten haben, die wiederum starken Einfluss auf die tatsächlich resultierende Leistung haben.

Dies sollte bei der Konzeption berücksichtigt werden - oft gibt es hier z.B. auch "semi-synchrone" Alternativen.

Zusammenfassung

Bei der Planung von DR-Abläufen lohnt es sich, genauer hinzuschauen.

Neben den kritischen organisatorischen (wer arbeitet wie nach einem Desaster mit den Anwendungen?) und technischen (wie erfolgt der Netzwerk-Zugriff?) Fragen sollte die Basis so aufgestellt sein, dass ein zeitnahes Weiterarbeiten möglich ist - und dazu gehört natürlich ein valides Storage-Konzept.