Replikationsmechanismen und -szenarien
Spieglein, Spieglein, …
Das Replizieren von Daten soll die wertvollen Datenbestände eines Unternehmens - und so die Kontinuität der Geschäftsprozesse sichern. Die im Gegensatz zum einfachen Backup dazu nötige Synchronizität von produktivem Betrieb und Sicherungsvorgängen macht die Replikation und deren Kosten zu einer Gleichung mit mehreren Unbekannten.
Theoretisch gilt die essenzielle, ja existenzielle Bedeutung der ständigen Verfügbarkeit von
Unternehmensdaten für den geschäftlichen Erfolg allgemein als unstrittig. In der Praxis tun sich
jedoch nach wie vor massive Lücken in den Strategien zu Sicherheit und Hochverfügbarkeit der Daten
auf. Mit einem – auch noch so zeitnahen – Backup ist es nicht getan, wenn für bestimmte
Geschäftsprozesse unternehmenskritische Daten ständig verfügbar sein müssen. Es muss gar kein
Störfall, Unfall oder Sabotage vorliegen. Schon einfache Wartungsarbeiten können den produktiven
Betrieb stören, wenn die benötigten Daten auf einem Speichermedium liegen, das gerade für Wartung,
Updates oder sonstige administrative Tätigkeiten heruntergefahren werden muss.
Was liegt also näher, als die Daten gleichzeitig doppelt oder mehrfach auf
festplattenbasierenden Storage-Systemen zu speichern, sprich zu replizieren? Klingt einfach, ist
aber bei näherer Betrachtung ein komplexer Vorgang.
Doppelpass
Zum besseren Verständnis ist es notwendig, den Prozess der Replikation im Sinne der
Geschäftskontinuität zu betrachten. Üblicherweise sieht ein solches Szenario folgendermaßen aus:
Ein lokaler Server dient als erste Datenquelle (Primary) für alle Schreib- und Lesezugriffe – ein
zweiter Server (Secondary) fungiert als Remote Server und steht als Backup-Speicher für alle Daten
des Primary Servers bereit. Basis aller Betrachtungen und Bewertungen zum Thema
Replikationsmechanismen sind zwei kritische Werte: Erstens die Recovery Point Objective (RPO) oder
der Wiederherstellungszeitpunkt. Dies ist der Moment, an dem der Primary Server ausfällt und keine
Daten mehr an den Secondary übermittelt. Zweitens die Recovery Time Objective (RTO) oder die
Wiederherstellungszeit. Dies ist der Zeitraum zwischen dem Ausfall des Primary Servers und der
Übernahme durch den Secondary Server.
Die Verbindung zwischen Primary und Secondary kann auf verschiedenen Wegen hergestellt werden,
wobei bei der Wahl der richtigen Verbindungsart die zu überbrückenden Entfernungen und die dafür
anfallenden Kosten die entscheidende Rolle spielen. Letztere sind eine keinesfalls zu
vernachlässigende Größe. In einer Grenzkostenrechnung stellen sie einen Posten dar, der häufig
höher ausfällt als die Aufwendungen für die I/O-Vorgänge zwischen Primary und Produktivservern, wie
etwa Applikations- oder E-Mail-Servern.
Auswechslung
Was passiert nun, wenn etwas passiert? Nehmen wir an, der Primary fällt - aus welchen Gründen auch immer - aus. Dann muss der Secondary umgehend einspringen und die Sicherung der Kontinuität der Geschäftsprozese übernehmen. Den Vorgang des (manuellen) Zugriffs auf die entsprechenden Volumes des Secondary und den Neustart der damit verbundenen Applikationen nennt man Failover. Sämtliche Netzwerk-Clients sehen den Secondary nun als Adressaten für ihre I/Os. In der Kostenrechnung tauchen später die Mehraufwendungen für die zusätzlichen Verbindungen auf. Diese sind jedoch meist weitaus geringer als ein Schaden, der durch Stillstand der Geschäftsprozesse entstanden wäre.
Ist der Primary Server wieder hergestellt, werden die aktuellen Daten vom Secondary zurückgespielt und er übernimmt wieder seine ursprüngliche Rolle. Prinzipiell ist dieser Prozess gleichbedeutend mit einem weiteren Failover, ist also ebenfalls mit einer Unterbrechung und anschließendem erhöhtem Datentransfervolumen verbunden, man spricht in diesem Fall von einem Failback.
Sehen wir uns in diesem Szenario die beiden Basiswerte RPO und RTO an. Fällt der Primary aus, werden von diesem Zeitpunkt an keine Daten mehr auf den Secondary repliziert. Der damit verbundene Datenverlust kann unkritisch sein, etwa bei einer Source Code Control, er kann aber auch dramatische Konsequenzen haben. Schon der Verlust innerhalb einer einzigen Sekunde kann bei elektronischen Buchungen im Bankwesen oder Flugverkehr zu nicht kompensierbaren Schäden führen. In diesem Sinne kann die RPO als die Höhe des tolerierbaren Datenverlusts verstanden werden. Bei kritischen Anwendungen muss sie dementsprechend gegen Null gehen. Anders gesagt: Es darf kein Zeitverzug zwischen I/Os auf dem Primary und der Replikation auf den Secondary auftreten. Nur dann ist gewährleistet, dass beide Datenbestände zu jedem Zeitpunkt konsistent sind.
Die RTO dagegen stellt sich dar als der Zeitpunkt, zu dem der Secondary tatsächlich die Primary-Funktionen übernimmt. Die damit verbunden Zeitspanne schließt sich chronologisch an die RPO an, und führt dementsprechend zu einem zusätzlichen Datenverlust. Der optimale RPO-Wert ist also ebenfalls Null. Die alles entscheidende Frage lautet damit: Sind diese Nullwerte technisch machbar - und wenn ja, zu welchen Kosten?
Kontrollierte Defensive
Bei der Wahl des richtigen Replikationskonzepts kommt es darauf an, RTO, RPO und die
entstehenden Kosten gegeneinander abzuwägen. Technisch gesehen ist es möglich, verzugsfrei zu
replizieren, also das Replikationsszenario mit RTO- und RPO-Werten von Null zu fahren. Aber diese
Form von Sicherheit und Hochverfügbarkeit hat ihren Preis.
Beim so genannten Active-Active Clustering/Mirroring sind Primary und Secondary gleichzeitig
aktiv, gleichen sich untereinander ab und sind somit jederzeit auch solo voll funktionsfähig. Fällt
ein Server aus, arbeitet der zweite eben temporär allein weiter, bis der Schaden behoben ist und
wieder beide gemeinsam die I/Os bearbeiten.
Technisch und im Sinne der Hochverfügbarkeit der Geschäftsdaten und Kontinuität der
Geschäftsprozesse ist dies die optimale Lösung. Zur Aufrechterhaltung der Kommunikation zwischen
den Anwendungen und dem Verbund von Primary/Secondary, sowie zwischen Primary und Secondary
untereinander sind jedoch ultraschnelle Breitbandverbindungen mit hohen Transferraten unerlässlich.
Und solche Hochleistungsverbindungen können im dislozierten Betrieb mit großen Entfernungen
zwischen den Standorten schnell sechs- oder gar siebenstellige Eurobeträge verschlingen.
Funktional kommt die synchrone Replikation im Aktiv/Passiv-Modus dieser Ideallösung am nächsten.
Hier werden die I/Os zwar ausschließlich vom Primary abgewickelt. Jede Veränderung des
Datenbestands, sprich jeder Schreibbefehl, wird jedoch vor Ausführung mit dem Secondary
abgeglichen. Erst wenn auch auf diesem die Änderung vorgenommen wurde, wird sie freigegeben. Durch
diesen Abgleich ist der Datenbestand bei beiden jederzeit identisch, die RPO erreicht den Idealwert
Null. Da aber die Anwendungen nur den Primary sehen, muss im Störfall ein Failover/Failback
durchgeführt werden, was zu RTO-Werten von mehreren Stunden führen kann. Um diese drastisch zu
reduzieren, besitzen etwa die Stortrends-Systeme eine MPIO-Funktionalität (Multi Path I/O). Sie
steuert im Störfall das automatische Umschalten vom Primary zum Secondary, ohne dass der
Administrator händisch eingreifen muss.
Auch die synchrone Replikation erfordert zwingend eine Hochleistungsverbindung zwischen Primary
und Secondary, mit den damit verbunden Kosten. Das Einsparpotenzial ergibt sich dadurch, dass die
Anwendungen nur mit dem Primary kommunizieren und damit die Verbindungskosten zum Secondary
entfallen.
Verzögerungstaktik
Unter Kostenaspekten gilt es, an der teuren Verbindung zwischen Primary und Secondary
anzusetzen. Der immense Bedarf an Bandbreite und Transferraten ergibt sich durch die synchrone
Übertragung zwischen Primary und Secondary. Was, wenn man die Daten zwischenspeichern, komprimieren
und für die Übertragung optimieren könnte? Damit würden sich die Anforderungen an die
Kommunikationsverbindungen und die damit verbundenen Kosten minimieren lassen.
Womit wir bei der Asynchronen Replikation sind. Hier werden die Daten zeitversetzt vom Primary
zum Secondary übertragen. I/Os können in Gruppen zusammengefasst und gemeinsam übertragen werden,
außerdem entfallen doppelte Schreibzugriffe zur gleichen logischen Blockadresse (LBA).
Dies reduziert nicht nur die Aufwendungen und Kosten für die Übertragungswege sondern auch die
Latenzzeit des Primary und erhöht so dessen I/O-Performance. Aber keine Rose ohne Dornen. Eine RPO
von Null oder annähernd Null ist mit dieser Methode nicht darstellbar. In vielen Anwendungsfällen
ist sie jedoch eine vernachlässigbare Größe.
Noch einen Schritt weiter geht die Snapshot- Assisted-Replikation. Hier werden in periodischen
Abständen Snapshots als Momentaufnahmen des Datenbestands gemacht. Ein Snapshot repäsentiert die
Summe aller Veränderungen zum vorhergehenden Snapshot und eliminiert alle doppelten Schreibzugriffe
während des dazwischenliegenden Zeitraums. Da sowohl alter (Secondary) als auch neuer (Primary)
Datenbestand verfügbar sind, können die zu übertragenden Daten wesentlich effektiver komprimiert
werden. Die RTO kann mit diesem Replikationskonzept geringer sein als bei der synchronen und
asynchronen Replikation. Allerdings ist die RPO üblicherweise nicht unter die Minutengrenze zu
drücken.
Von großer Bedeutung ist in diesem Zusammenhang die Zahl der maximal möglichen Snapshots.
Üblicherweise liegt sie im Bereich von acht bis 64. Mit den bei Stortrends möglichen 254 Snapshots
kann man den historischen Zeitraum verlängern und/oder die "Granularität der Zeitscheiben" erhöhen,
also etwa jeden Tag eines kompletten Geschäftsjahres per Snapshot sichern und dokumentieren.
Fehlpass
Eine häufig unterschätzte Ursache für Systemstörungen oder -ausfälle sind so genannte Link
Failures, meist kurzfristige Unterbrechungen der Netzwerkverbindungen. Zwei Dinge sind hier
entscheidend: Erstens, wie groß ist die Zeittoleranz eines Storage-Systems gegenüber Link Failures?
Zweitens, wie geht ein Storage-System mit Link Failures um, die außerhalb der Zeittoleranz liegen?
Je größer die Zeittoleranz, desto geringer die Gefahr, dass das System in den Failover-Zustand
fällt, mit all den Risiken und zusätzlichen Kosten die durch Failover und Failback entstehen. Viele
Systeme tun dies schon bei Link Failures von unter 20 Millisekunden. Mit Toleranzgrenzen von über
100 Millisekunden lassen sich diese Zustände drastisch reduzieren.
Aber auch dann, wenn das Zeitlimit zum internen Abfangen einer Verbindungsstörung überschritten
ist, gibt es Mechanismen, die die Resynchronisation vereinfachen. Bei der synchronen Replikation
ist dies das so genannte Tabbing. Im Fall eines Verbindungsfehlers wird eine Tabelle angelegt, die
eine Liste derjenigen Sektoren umfasst, die I/Os empfangen haben. Die Auflösung kann dabei durch
den neuartigen CRT-Algorithmus (Collapsible Resync Tables) so fein gewählt werden (64 KByte –
Sektorenebene), dass nur die absolut notwendige Datenmenge übertragen wird. Dies reduziert sowohl
die Datenmenge, die notwendige Bandbreite für die Übertragung, die damit verbundenen Kosten als
auch den Zeitbedarf für die Synchronisation der beiden Storageserver.
Bei der asynchronen Replikation können diese Störungen sehr elegant gelöst werden, indem das
System während der Resynchronisation in den synchronen Modus wechselt und danach wieder auf
asynchrone Replikation schaltet – wenn es das kann!
Abpfiff
Ein allgemeine Empfehlung für eine der verschiedenen Replikationsmechanismen kann generell nicht
ausgesprochen werden. Sie ergibt sich aus den individuellen Anforderungen, Netzwerkszenarien und
Kostenrechnungen innerhalb eines Unternehmens. Wichtig ist, dass ein Storage-System für alle
wichtigen Replikationsmechanismen ausgelegt ist und flexibel auf wachsende oder wechselnde
Anforderungen skaliert werden kann. Unter dem Gesichtspunkt der Hochverfügbarkeit sei noch auf ein
häufig anzutreffendes Missverständnis verwiesen: Ein Storage-System kann niemals eine HV-Lösung
sein, sondern immer nur Teil einer umfassenderen HV-Architektur, die die Hochverfügbarkeit im
gesamten Netzwerk abbildet.
Lesen Sie mehr zum Thema
