Software-basierte Replikationstechnologien heben Hardware-Beschränkungen auf

Software-basierte Replikation ist dabei, array-basierte Technologien abzulösen. Besonders Virtualisierung und Cloud unterstützen diesen Prozess.

Array-basierte Data Replication ist immer als die Musterlösung für eine Disaster-Recovery-Strategie betrachtet worden, wenn es darum geht, Kopien von Daten zu erzeugen. Jedoch sind inzwischen neue Wege entstanden, wie Applikationen eingesetzt werden: Das hat die Konsequenz, dass Data Protection statt über Hardware- nun über Software-Lösungen erreicht werden kann. 

Außerdem können einige der Methoden und Beschränkungen von Hardware-basierter Replikation mit Software-Lösungen überwunden werden: Diese liefern größere Flexibilität und mehr Auswahl darin, wie Daten effektiv zu schützen sind.

Array-basierte Techniken

Replikation auf Array-Basis gibt es schon fast so lange wie Integrated Cached Disk Array (ICDA), auch als das heutige SAN-Speichernetzwerk bekannt. ICDA kombiniert Festplatten, Cache Memory und Microcode-Intelligenz miteinander, um optimierte I/O-Leistung sowie Datenreplikation von einem Speicherplatz zu einem anderen zu liefern.

Funktionen wie Symmetrix Remote Data Facility (SRDF) von EMC oder TrueCopy von Hitachi kennzeichnen die Entwicklung von Peer-to-Peer-Kopiertechnologien, wie sie ursprünglich bei IBMs Mainframe-Speicher eingesetzt wurden. Daten wurden auf der Basis von Hardware, d. h. durch das I/O-Subsystem, repliziert. Mit Array-basierter Replikation verschob man den mühseligen Replikationsprozess weg vom Prozessor hin zum Array. Die Array-basierte Replikation lieferte (und liefert immer noch) eine Reihe von deutlichen Vorteilen:

Workloads. Das Speicher-Array führt alle Replikationsaufgaben aus, wobei Prozessor- und Memory-Ressourcen auf dem Host eingespart werden.

Daten-Konsistenz: Das Array ist selbst verantwortlich für die Write-Order-Integrität, indem es Updates durchführt, wenn Daten an einen anderen Standort kopiert worden sind. Dies garantiert eine gleichmäßige Daten-Konsistenz.

Performance. Das Array ist in der Lage, an beiden Orten I/O-Prozesse in nicht-flüchtigem Memory zwischenzuspeichern (Caching) und so die Performance von synchronen und asynchronen Datenübertragungen zu verbessern.

Granularität. Mit Arrays kann man heute auf mehreren Ebenen Daten replizieren und einen Failover durchführen: Dies gilt für ein einzelnes LUN, eine Gruppe von LUNs (auch als Consistency Group bezeichnet) oder die Daten eines kompletten Arrays.

Datenintegrität. Wenn die Daten bei einem Failover zu einem Ziel-Array kopiert worden sind, ist das Array in der Lage, Änderungen an den Daten zu verfolgen und zu speichern. Wenn Daten zu einem späteren Zeitpunkt auf das primäre Gerät zurückgespielt werden sollen, werden nur diese Änderungen übertragen. 

Das bedeutet, dass man keine vollständige Re-Synchronisation anstoßen muss. Dies ist besonders wichtig in kompletten Failover-Szenarios, in denen der Rückspielvorgang bei einer vollständigen Re-Synchronisation für eine bestimmte Zeit zu einem ungeschützten Zustand des Arrays führen könnte.

Optimierung. Replikationsprozesse optimieren in der Regel die Bandbreite in der Vernetzung zwischen zwei Standorten, indem sie nur die geänderten Daten auf Block-Level versenden. Die zugrundeliegende Speicherarchitektur ist auf Basis von Blöcken oder Tracks (wie man in der guten alten Mainframe-Zeit sagte) organisiert.

Effizientes Scaling. Ein Failover auf Array-Level führt zu Replikation der Daten von vielen Servern und macht sie innerhalb kürzester Zeit wieder auf einem entfernten Speicherplatz verfügbar. Dieser Prozess kann zusammen mit speziellen Scripts für eine automatische Skalierung sorgen, was viele Speicheradministratoren davon befreit, sich selbst um die Failover-Abläufe zu kümmern.

Failover versus Failback

Failover: Darunter versteht man den Prozess, bei dem primäre Daten-I/O-Operationen von einem Array zu einem anderen verschoben werden.

Failback: Dies ist der Prozess, bei dem die I/O-Operationen zu dem primären Array zurückkehren.

Der Failover- und Failback-Prozess sollte nach Möglichkeit den Zustand jeder Speicherlokation festhalten, um so die Rückkehr zu normalen Datenoperationen zu erleichtern. Dabei sollten nur die geänderten Daten synchronisiert werden.

Trotz dieser beträchtlichen Vorteile hat Array-basierte Replikation auch einige nicht zu vernachlässigende Nachteile:

Kosten. Replikation kann eine teure Lösung sein, weil Hersteller in der Regel ihren Einsatz per Terabyte berechnen. Man sollte sie deshalb nur für Daten benutzen, die unbedingt repliziert werden müssen. Diese Technologie erfordert außerdem teure Netzwerke, die in vielen Fällen sogar als dedizierte, sehr effektive Fibre-Channel-Verbindungen eingerichtet sind, was sich noch einmal bei den Kosten niederschlägt.

Herstellerabhängigkeit. Array-basierte Lösungen sind häufig proprietär ausgerichtet, da sie von einem bestimmten Hersteller stammen und keine Schnittstellen zu anderen Systemen anbieten. Das Design einer Replikationslösung beruht in der Regel direkt auf der darunter liegenden physikalischen Array-Architektur, wobei die Daten auf einem Block- oder Track-Level verschoben werden. Das bedeutet, dass die Daten nicht vom Array eines Herstellers zu dem eines anderen Anbieters bewegt werden können. Für den Anwender entsteht so eine typische Lock-in-Situation.

Komplexität. Array-basierte Replikation nutzt lokalen nicht-flüchtigen Memory, um I/O zwischenzuspeichern und so die Performance zu verbessern. Zusätzliche Funktionen wie Snapshots und Cloning müssen ebenfalls im Zusammenhang mit Replikation verwaltet werden, was zu einer komplexen Konfiguration führen kann. Dies ist in der Regel kein Problem, solange nicht eine Failure-Situation oder ein Software-Fehler dazu führen, dass der Status-quo aufgehoben wird.

Crash-Kopie. Ohne Software-Agenten ist Array-basierte Replikation nicht in der Lage, die Daten selbst zur Kenntnis zu nehmen. Es werden lediglich anonyme Blocks zwischen den verschiedenen Speicherplätzen hin- und her geschoben, allerdings mit Write-Order Integrity. 

Dies bedeutet, dass sich im Failover-Fall die Systeme so darstellen, als wenn der Server selbst zusammengebrochen wäre. In der Folge können Probleme im Zusammenhang mit Data Corruption oder verlängerte Boot-Zeiten auftreten, wenn die Systeme neu gestartet werden.

Granularität. Für Block-basierte Systeme ist das minimale Replikations-Niveau die LUN-Ebene. Diese kann in virtuellen Umgebungen bereits mehrere virtuelle Maschinen (VMs) umfassen. Ein Failover für eine einzelne LUN bedeutet, dass dieser Prozess für alle VMs innerhalb dieser LUN vollzogen wird, ohne Rücksicht darauf, ob dies für jede VM erforderlich ist. (File-basierte Systeme können dagegen auf Datei-Niveau replizieren, womit eine feinere Granularität gewährleistet ist.)

Bei der Begutachtung von Array-basierter Replikation sind mehrere der genannten positiven und negativen Kategorien zu berücksichtigen. Die endgültige Entscheidung wird jeweils von der besonderen Problematik abhängen, die das Unternehmen bewältigen muss.

Was wurde eigentlich aus Netzwerk-Replikation?

In dedizierten Speicher-Netzwerken, zum Beispiel auf Basis von Fibre Channel, scheint die Daten-Replikation eine selbstverständliche Angelegenheit zu sein: Sind die Daten einmal auf dem primären Array abgelegt, können sie beliebig an andere Stellen im Netzwerk repliziert werden.

In der Praxis dagegen kämpft Netzwerk-basierte Replikation mit zu vielen Problemen: So kommt es vor, dass Daten zu einem anderen Array übertragen worden sind, bevor der Vorgang überhaupt am Ursprungsort bestätigt worden ist, was zu Integrity-Problemen führen kann. Hinzu kommt, dass die eingesetzten Software-Lösungen eine komplexe Konfiguration und dedizierte Hardware verlangen. Ein weiteres Problem ergibt sich häufig auf der Security-Ebene.

In dem Maße, wie sich eigene Storage-Netzwerke immer mehr ausbreiten und über zusätzliche Funktionen verfügen werden, wird die Netzwerk-basierte Replikation an Attraktivität verlieren und wahrscheinlich irgendwann ganz verschwinden.

Appliances für Replikation

Wenn man eine dedizierte Appliance für Replikation einsetzt, wird die Aufgabe, Daten zwischen verschiedenen Hardware-Arrays zu kopieren, auf eine eigene Hardware- oder auf eine Software-Instanz verlagert, die auf einem physischen oder auf einem virtuellen Server läuft. 

Ein gutes Beispiel dafür stellt RecoverPoint von EMC dar (hervorgegangen aus der Akquisition von Kashya). Die RecoverPoint-Software sitzt auf dem Data Path, womit sie jeden Write-I/O-Prozess direkt aufnimmt und zu einer gleichartigen Appliance in einem entfernten Rechenzentrum kopiert, die sie dann zu der dort platzierten Kopie hinzufügt. Während des Kopierprozesses wird lokal eine Datensicherung per Journaling durchgeführt.

Damit unterscheidet sich dieser Prozess davon, wie auf proprietären Arrays Daten hin und her bewegt werden. Die Verwaltung der Daten gestaltet sich recht einfach, während die Datenkonsistenz erhalten bleibt. Gleichzeitig verfügen die Anwender über alle Vorteile der Array-basierten Replikation. Doch auch hier sind nicht alle Probleme gelöst, besonders auf der Konsistenzebene: Letztendlich werden die Daten noch immer von Array zu Array bewegt.

Replikation auf Hypervisor-Ebene

Werden einige der traditionellen Elemente aus dem Replikationsprozess entfernt, bedeutet das, näher an die Software heranzurücken, die die Daten verwaltet. In virtuellen Umgebungen ist das der Hypervisor, wie zum Beispiel vSphere von VMware oder Hyper-V von Microsoft. 

Da der Hypervisor den Inhalt der Daten zumindest auf der VM-Ebene versteht, ist er auch dazu geeignet, den Replikationsprozess zwischen den Speicherorten auf einem sehr granularen Niveau zu managen. Das Datenmanagement geschieht damit auf der Ebene einer virtuellen Maschine (VM), und nicht auf der einer vollständigen LUN.

Sowohl VMware als auch Microsoft bieten Replikation innerhalb ihrer Hypervisor-Technologie an. VMware vSphere stellt hierzu vSphere Replication zur Verfügung, wobei das Tool von vCenter System Recovery Manager verwaltet wird. Hyper-V liefert Replikation mit Hyper-V Replica, gemanaged durch System Center Virtual Machine Manager (SCVMM).

Natürlich muss bei beiden Programmen die Durchführung der Replikation immer noch auf einer unteren Ebene geleistet werden. Jetzt kümmert sich aber der Hypervisor um die notwendigen Erweiterungen auf der Hardware-Ebene – zum Beispiel bei Prozessorleistung, Memory oder Netzwerkbandbreite. Zu berücksichtigen ist ferner, dass diese Lösungen nicht umsonst zu haben sind: Die Nutzung des Hypervisor für Replikation ist mit einem Preisaufschlag verbunden.

Wie schon bei speziellen Appliances kann man mit Replikation per Hypervisor Daten auf Arrays mit einem geringeren Funktionsumfang oder schlicht auf billigerer Speicher-Hardware ablegen. Wer jedoch eine kostengünstigere und weniger performante Lösung für das Ziel-Array wählt, hat womöglich an der falschen Stelle gespart. Eine solche Entscheidung hängt auch von den Daten ab, die man replizieren und auf jeden Fall erhalten möchte.

Anwendungsbasierte Replikation

Im Prinzip ist Replikation direkt innerhalb der Anwendung die ideale Lösung, da Daten und Anwendung unmittelbar zusammenhängen. Beispiele für eine solche Integration sind neben anderen Data Guard von Oracle oder Integration als Bestandteil von Microsoft Exchange

Doch diese Lösungen verfügen nicht über die gleichen Skalierungseffekte wie Array-basierte Replikation. Dies betrifft besonders große Server-Farmen, in denen jedes Replikations-Paar extra verwaltet werden muss. Auf der anderen Seite ist es vorstellbar, dass anwendungsbasierte Replikation das ideale Instrument sein könnte, um Daten in Public-Cloud-Infrastrukturen hinein und wieder zurück zum Kunden zu bewegen.

Replikation innerhalb einer virtuellen Maschine (VM)

Neben dem oben beschriebenen Einsatz von Hypervisor-Tools gibt es auch die Möglichkeit, eine virtuelle Maschine (VM) für Replikation zu verwenden. Dies kann auf zwei Arten geschehen. Einige Lösungen verwenden eine VM, um Daten aus virtuellen Maschinen zu übernehmen, während andere Replikationsanwendungen eine VM so konfigurieren, dass sie als ein Proxy-Datastore für aktuelle Daten fungiert, die auf externem oder lokalem Speicher abgelegt sind. Die jeweilige „Datastore virtual machine“ sieht dann den gesamten I/O-Traffic, was ihr erlaubt, I/O-Schreibvorgänge zu einem anderen Ort oder zu einem lokalen Speicher zu replizieren.

Produkte wie die Replikation für VMware von Zerto nutzen VMware-APIs, um Write-I/Os zu überwachen und zu übernehmen. Die Daten werden zu einem anderen Ort repliziert, wobei virtuelle Appliances auf den Ursprungs- und Ziel-Hosts verwendet werden. Zerto nennt diese Hosts „Virtual Replication Appliances“ (VRAs). 

ILIO USX von Atlantis Computing besitzt die Fähigkeit, für VMs Pools von Storage-Ressourcen und unterschiedlichen Speichertypen anzulegen. Indem Daten zwischen verschiedenen Systemen repliziert werden, soll das Tool für hohe Verfügbarkeit sorgen.

VM-basierte Replikation verbraucht Hypervisor-Ressourcen und muss deshalb genau beobachtet werden, vor allem wenn weitere virtuelle Maschinen zu einem Cluster hinzugefügt werden. Außerdem sollte man Priorisierung für die replizierende VM festlegen, um die wachsende Nachfrage nach Replikation im Griff zu behalten.

Replikation in der LVM

Logical Volume Managers (LVMs) sitzen zwischen den physischen Speicherressourcen und der logischen Darstellung von Daten in der Form von LUNs und Volumes. Insofern stellt ein LVM den perfekten Ort dar, Replikationsprozesse zu verwalten: Ein LVM sieht alle I/O-Vorgänge zwischen dem Host und den physikalischen Speicherorten. 

Produkte wie SANsymphony-V von DataCore oder Virtual SAN von StarWind Software sorgen für eine logische Volume-Abstraktion von den physischen Speicherressourcen. Außerdem fügen sie fortgeschrittene Features hinzu, darunter synchrones Mirroring, asynchrone Replikation oder eine Near-CDP (Continuous Data Protection)-Funktionalität. Diese Lösungen fügen der Speicherarchitektur einen weiteren Layer an Komplexität hinzu. Um alle zusätzlichen Features zu erhalten, mag dies allerdings zu verschmerzen sein.

Neue Lösungen

Es gibt natürlich auch die verbreitete Ansicht, nach der Point-to-Point-Replikation noch immer seine Berechtigung hat. Die Anbieter von Object Storage realisieren Data Protection durch einfaches Mirroring oder durch Data-Dispersal-Techniken wie Erasure Coding (auch bekannt als Forward Error Correction). 

Algorithmen für Erasure Coding verstreuen mehrere redundante Datenfragmente auf verschiedene Speicherorte und ermöglichen so ein Recovery, das lediglich eine Teilmenge dieser Fragmente benutzt. Data Protection und Replikation ist bei diesem Vorgehen effektiv in den Lese- und Schreibprozess der Daten integriert.

Der offensichtliche Nachteil dieser Lösungen besteht in einer schlechten Performance. Andererseits haben Hersteller wie Scality und Cleversafe Flash in ihre Architekturen integriert, um die Performance anzukurbeln. Beide Unternehmen bieten ihre Lösung auch als reines Software-Produkt an. 

Open-Source-Projekte wie Ceph offerieren verteilte Datenspeicher, auf denen man Block-, File- und Objektdaten mittels Mirroring (Data Replicas) und Erasure Coding ablegen kann. Obwohl diese Technologie noch ganz am Anfang steht, kann man schon für die nächsten Jahre einen deutlichen Reifeprozess erwarten: Der Grund dafür liegt in der Tatsache, dass Inktank – das Unternehmen, das Entwicklung und Support für Ceph anbietet – von Red Hat übernommen wurde.

Die Cloud

Tatsache ist, dass immer mehr Infrastrukturen für Private und Public Clouds genutzt werden. Mit Software-basierter Replikation ergibt sich die Möglichkeit, Daten unkomplizierter in Cloud-Infrastrukturen zu verschieben und wieder zurückzuholen. Mit Array-basierter Replikation lässt sich das nicht so einfach erreichen. 

Obwohl es die Bandbreite in der Regel nicht erlauben dürfte, komplette VMs zu verschieben, bieten Software-basierte Lösungen sowohl für Private als auch für Public Clouds den höchsten Grad an Flexibilität und Mobilität.

Einige Hardware-Hersteller bieten derzeit Lösungen an, bei denen ihre Produkte in Co-Location mit Cloud-Providern für Replikation sorgen. Dies sind lediglich kurzfristige Offerten, da wir uns eindeutig in Richtung einer heterogenen Welt bewegen, in der Software-basierte Replikation vorherrschen wird.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Februar 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Essential Guide

Mehr Datensicherheit durch Replikation und Snapshots

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close