Synchrone vs. asynchrone Replikationsstrategie
& & & Die moderne Geschäftswelt wächst mit jeder Sekunde, was bedeutet, dass es immer mehr sensible Daten gibt, die geschützt werden müssen. Im Falle einer Katastrophe muss jedes Unternehmen über eine Reihe von Strategien für die Wiederherstellung verfügen, um geschäftskritische Prozesse so schnell wie möglich zu schützen und wiederherzustellen. Daher entsteht ein Bedarf an Fernreplikation, was bedeutet, dass geschäftskritische Daten zur zuverlässigen Speicherung und schnellen Wiederherstellung außerhalb des Standorts gesendet werden müssen.
Was ist Remote-Replikation?
Remote-Replikation ist ein wesentlicher Bestandteil der Datensicherheit und der Wiederherstellung. Früher wurde die Replikation hauptsächlich zum Kopieren und Speichern von Anwendungsdaten an externen Standorten verwendet. Mit der Zeit hat sich diese Technologie jedoch erheblich weiterentwickelt. Derzeit ermöglicht die Replikation die Erstellung einer synchronisierten Kopie einer VM auf einem Remote-Zielhost. Die Kopie der VM wird als Replikbezeichnet und funktioniert genau wie eine normale VM, die auf einem Quellhost verfügbar ist. VM-Replikate können auf jede geeignete Hardware übertragen und dort ausgeführt werden. Sie können innerhalb von Sekunden hochgefahren werden, falls die ursprüngliche VM ausfällt. Diese Technologie kann Ausfallzeiten erheblich reduzieren und potenzielle Geschäftsrisiken und Verluste im Zusammenhang mit Katastrophen mindern.
Vor der Ausführung eines Replikationsauftrags sollten die folgenden Faktoren berücksichtigt werden:
- Entfernung – Je größer die Entfernung zwischen den Standorten ist, desto größer ist die Latenz.
- Bandbreite – Die Internetgeschwindigkeit und das Netzwerk sollten ausreichend sein, um eine schnelle und sichere Datenübertragung zu gewährleisten.
- Datenrate – Die Datenrate sollte niedriger sein als die verfügbare Bandbreite, um das Netzwerk nicht zu überlasten.
- Replikationstechnologie – Replikationsaufträge sollten parallel (gleichzeitig) ausgeführt werden, um das Netzwerk effizient zu nutzen.
Diese Faktoren helfen dabei, zu bestimmen, welche Art der Replikation bei einer bestimmten Art von Katastrophe vorzuziehen ist.
Synchrone vs. asynchrone Replikationsstrategien
Es lassen sich zwei Haupttypen der Datenreplikation unterscheiden: synchron und asynchron.
Synchrone Replikation
Hier werden Daten gleichzeitig mit der Erstellung oder Aktualisierung neuer Daten im primären Rechenzentrum an einen sekundären Remote-Standort repliziert. Dies ermöglicht eine nahezu sofortige Replikation, sodass Ihre Replikate nur wenige Minuten älter als das Quellmaterial sind. Im Wesentlichen bleiben sowohl Host- als auch Zielquellen vollständig synchronisiert, was für eine erfolgreiche Disaster Recovery (DR) von entscheidender Bedeutung ist.
Aufgrund der Tatsache, dass Daten atomar an mehreren Remote-Standorten aktualisiert werden, werden die Leistung und Verfügbarkeit des Netzwerks beeinträchtigt. Atomare Operationen sind definiert als eine Abfolge von Operationen, die ohne Unterbrechung abgeschlossen werden müssen, bevor eine andere Aufgabe ausgeführt werden kann. Im Zusammenhang mit der synchronen Replikation bedeutet dies, dass der Schreibvorgang erst dann als fertiggestellt gilt, wenn sowohl der lokale als auch der Remote-Speicher dessen Fertigstellung bestätigen. Dadurch wird zwar ein Datenverlust von Null garantiert, aber die Leistung wird verlangsamt.
Asynchrone Replikation
In diesem Fall wird die Replikation nicht gleichzeitig mit den Änderungen im primären Speicher durchgeführt. Die Daten werden nur in vorab festgelegten Zeiträumen (stündlich, täglich oder wöchentlich) repliziert. Die Replik kann an einem entfernten DR-Standort gespeichert werden, da sie nicht in Echtzeit mit dem primären Standort synchronisiert werden muss.
Bei der asynchronen Replikation werden die Daten nicht atomar an mehreren Standorten aktualisiert, was bedeutet, dass die Anwendung mit dem Schreiben von Daten fortfährt, die noch nicht vollständig repliziert sind. Somit gilt ein Schreibvorgang als abgeschlossen, sobald der lokale Speicher ihn bestätigt. Bei der asynchronen Replikation werden die Leistung und Verfügbarkeit der Netzwerke verbessert, ohne die Bandbreite zu beeinträchtigen. Dies liegt daran, dass die Replikate nicht in Echtzeit aktualisiert werden. Der Nachteil ist, dass im Katastrophenfall die DR-Site möglicherweise nicht die zuletzt vorgenommenen Änderungen enthält, sodass einige wichtige Daten verloren gehen könnten.
Synchrone vs. asynchrone Replikation: Hauptunterschiede
| Synchron | Asynchron | |
| Entfernung | Funktioniert besser, wenn die Standorte nahe beieinander liegen (die Leistung nimmt proportional zur Entfernung ab). | Funktioniert über größere Entfernungen (solange eine Netzwerkverbindung zwischen den Rechenzentren verfügbar ist). |
| Kosten | Teurer | Kostengünstiger |
| Ziele der Wiederherstellungspunkte (RPO) | Null | Von 15 Minuten bis zu einigen Stunden |
| Wiederherstellungszeit-Ziel (RTO) | Kurz | Kurz |
| Netzwerk | Erfordert mehr Bandbreite und ist von Latenzzeiten betroffen; kann durch WAN-Unterbrechungen beeinträchtigt werden (da die Übertragung replizierter Daten nicht auf später verschoben werden kann). | Die Anforderungen sind geringer und die Daten werden nicht von Latenz beeinträchtigt; sie werden nicht von WAN-Unterbrechungen beeinträchtigt (da die Kopie der Daten am lokalen Standort gespeichert werden kann, bis der WAN-Dienst wiederhergestellt ist). |
| Datenverlust | Null- | Möglicher Verlust der letzten Datenaktualisierungen. |
| Resilienz | Ein einzelner Ausfall kann zu einem Dienstausfall führen. Viren oder andere schädliche Komponenten, die zu Datenbeschädigungen führen, können auf die zweite Kopie der Daten repliziert werden. | Nach zwei Ausfällen kann es zu einem Dienstausfall kommen. |
| Leistung | Niedrig (wartet auf Netzwerkbestätigung vom sekundären Standort). | Hoch (wartet nicht auf Netzwerkbestätigung vom sekundären Standort). |
| MANAGEMENT | Erfordert möglicherweise spezielle Hardware; Unterstützt durch hochwertige blockbasierte Speicher-Arrays und netzwerkbasierte Replikationsprodukte. | Bessere Kompatibilität mit anderen Produkten; Unterstützt durch Array-, Netzwerk- und hostbasierte Replikationsprodukte. |
| Verwendungsfälle | Die beste Lösung für sofortige Disaster Recovery und Projekte, bei denen absolut kein Datenverlust toleriert werden kann. | Die beste Lösung für den Speicher weniger sensibler Daten und die sofortige Disaster Recovery von Projekten, bei denen ein teilweiser Datenverlust toleriert werden kann. |
Was ist besser: Synchrone oder asynchrone Replikation?
Es gibt keine eindeutige Antwort auf diese Frage; Ihre Wahl hängt ganz von Ihren geschäftlichen Prioritäten ab. Asynchrone Replikation eignet sich am besten für Projekte, die sich über große Entfernungen erstrecken und nur über ein minimales Budget verfügen. Sie ist auch für Unternehmen geeignet, die einen teilweisen Datenverlust verkraften können. Synchrone Replikation wird hingegen durchgeführt, wenn ein zuverlässiger und langfristiger Speicher erforderlich ist und das Unternehmen sich keinen Verlust kritischer Daten leisten kann. Sie ist nützlich, wenn RTOs und RPOs kurz sind.
Es gibt jedoch einen Mittelweg: Sie können sowohl synchrone als auch asynchrone Replikationsstrategien auf verschiedenen Ebenen der Infrastruktur verwenden. Beispielsweise kann die synchrone Replikation zum Übertragen und Sichern von Daten über ein lokales Netzwerk (LAN) verwendet werden, während die asynchrone Replikation wichtige Daten an einen entfernten DR-Standort sendet.
Replikation in NAKIVO Backup & Replikation
Replikationsmodus
vSphere Replication in NAKIVO Backup & Die Replikation erfolgt immer inkrementell. Bei der ersten Replikation wird die gesamte VM kopiert, bei den folgenden Replikationsaufträgen werden jedoch nur die Änderungen an den Daten in der Replik (Inkremente) gespeichert. Darüber hinaus wird nach jedem Replikationsauftrag ein Wiederherstellungspunkt erstellt, der auf alle für die Wiederherstellung der VM erforderlichen Datenblöcke verweist. Dieser Replikationsmodus sorgt für eine geringere Netzwerkbelastung und spart Ihnen Zeit, die Sie sonst für vollständige Replikationsaufträge aufwenden müssten.
Kompatible Plattformen
NAKIVO Backup & Replikation bietet eine schnelle Bereitstellung auf verschiedenen Hardware- und Softwareplattformen:
- VMware VA. Die vorkonfigurierte VMware Virtual Appliance kann einfach heruntergeladen und dann in VMware vSphere importiert werden.
- NAS. Durch die Installation von NAKIVO Backup & Replication direkt auf einem NAS-Gerät können Sie Ihre eigene VM-Backup-Appliance erstellen.
- AWS AMI. NAKIVO Backup & Replication kann in der Cloud als vorkonfiguriertes Amazon Machine Image (AMI) bereitgestellt werden.
- NAKIVO Backup & Die Replikation kann mit einem einzigen Befehl auf einer physischen oder virtuellen Maschine unter Linux installiert werden.
- NAKIVO Backup & Die Replikation kann mit einem einzigen Klick auf einer physischen oder virtuellen Maschine unter Windows installiert werden.
Replikationsfunktionen
Ein Snapshot erfasst den Zustand eines Systems zu einem bestimmten Zeitpunkt. Mit NAKIVO Backup & Replikation werden VM-Replikate mithilfe von VM-Snapshots erstellt, die zum Abrufen aktueller VM-Daten verwendet werden. Bei jeder Ausführung eines Replikationsauftrags wird ein temporärer VM-Snapshot erstellt, die geänderten Daten werden identifiziert und alle Aktualisierungen werden zum Replikat hinzugefügt. Nach dem Auftrag wird der Snapshot gelöscht.
Changed Block Tracking
NAKIVO Backup & Replication nutzt VMware CBT (Changed Block Tracking) und Hyper-V RCT (Resilient Change Tracking), um die seit der letzten Replikation in einer VM vorgenommenen Änderungen zu identifizieren und zu kopieren. Diese Technologie verbessert die Geschwindigkeit von Replikationsaufträgen erheblich. Wenn CBT und RCT nicht verfügbar sind, verwendet NAKIVO Backup & Replication eine integrierte eigene Methode zur Verfolgung von Änderungen.
Live-Anwendungsunterstützung
NAKIVO Backup & Replication ist eine Application-Aware-Lösung. VMs werden zum Ausführen aller Arten von geschäftskritischen Anwendungen verwendet, darunter Microsoft Exchange, Active Directory, SQL, SharePoint usw. Bei diesen Programmen mit häufigen Ein- und Ausgabevorgängen ist es unerlässlich, dass die Anwendungsdaten stets konsistent sind, insbesondere wenn ein Replikationsauftrag ausgeführt wird. Wenn also ein Schnappschuss erstellt wird, speichern die Anwendungen innerhalb der VM alle Transaktionen im Arbeitsspeicher, um keine laufenden Vorgänge zu unterbrechen.
Containerschutz
NAKIVO Backup & Replikation & Die Replikation erleichtert den Schutz kritischer VMs, indem Sie diese in Containern wie Ressourcenpools, Ordnern oder Clustern organisieren können. Ein gesamter Container kann zu einem bestimmten Replikationsauftrag hinzugefügt werden. Sie können Elemente ganz einfach zum Container hinzufügen oder daraus entfernen, wobei diese Änderungen automatisch in den entsprechenden Replikationsaufträgen berücksichtigt werden. Die Funktion ist flexibel: Sie können auch bestimmte VMs in einem Container von einem Replikationsauftrag ausschließen. In diesem Fall wird der gesamte Container mit Ausnahme der ausgeschlossenen VMs geschützt.
Screenshot-Überprüfung
Mit dieser Funktion können Sie automatisch überprüfen, ob die VM-Replikation erfolgreich abgeschlossen wurde. Sobald ein Replikationsauftrag fertiggestellt ist, wird die Netzwerkverbindung in der Replik deaktiviert und diese Replik wird kurzzeitig eingeschaltet, um einen Screenshot zu erstellen. Anschließend wird die Replik wieder ausgeschaltet und auf den letzten Wiederherstellungspunkt zurückgesetzt. Der Benutzer erhält einen E-Mail-Bericht mit einem Screenshot des testweise gebooteten Betriebssystems.
Jobgruppierung
NAKIVO Backup & Mit Replication können Sie Replikationsaufträge in Gruppen (Ordnern) organisieren, um Anwendungen, Dienste und Standorte in logischen Strukturen anzuordnen. Darüber hinaus können Massenaktionen für alle oder ausgewählte Aufträge einer Gruppe einfach ausgeführt werden.
Automatische Berichte
Wenn Sie über den Status Ihrer Replikationsaufträge auf dem Laufenden bleiben möchten, kann NAKIVO Backup & Replikation & Replication Sie darüber informieren, indem es Ihnen automatisch E-Mail-Berichte sendet, entweder nach Zeitplan oder auf Anfrage.
Jobplanung
Mit NAKIVO Backup & Replikation & können Sie Replikationsaufträge so konfigurieren, dass sie entweder auf Anfrage oder nach Plan (täglich, wöchentlich, monatlich und jährlich) ausgeführt werden. Sie können sogar Aufträge so einrichten, dass sie nach einem benutzerdefinierten Plan ausgeführt werden, der Ihren spezifischen Geschäftsanforderungen entspricht, z. B. alle 20 Minuten, alle 5 Tage oder am ersten Dienstag jedes Monats. Sie können auch Zeitfenster festlegen, innerhalb derer ein Auftrag gestartet und beendet werden soll.
Staging-VM-Replikation (Seeding)
Die anfängliche (vollständige) Replikation größerer VMs kann aufgrund ihrer Größe sehr lange dauern. Um den Prozess zu beschleunigen, kann NAKIVO Backup & Replication eine stufenweise VM-Replikation durchführen. Mit dieser Funktion können Sie zunächst die ersten VM-Replikate auf Wechselmedien übertragen („Seeding“). Anschließend können diese Replikate an den neuen Standort transportiert werden, wo ein neuer Replikationsauftrag mit den übertragenen VMs ausgeführt wird. Danach wird nur noch eine inkrementelle Replikation durchgeführt.
Wiederherstellungspunkte
Ein Wiederherstellungspunkt repräsentiert eine VM zu einem bestimmten Zeitpunkt, der dann für die Wiederherstellung der VM verwendet wird. Mit NAKIVO Backup & Replikation können Sie bis zu 30 Wiederherstellungspunkte pro VM-Replik speichern. Das Produkt ermöglicht Ihnen die Speicherung von Wiederherstellungspunkten gemäß den unten beschriebenen Grandfather-Father-Son (GFS)-Aufbewahrungsrichtlinien. Diese Methode stellt sicher, dass Wiederherstellungspunkte für VM-Replikate mit festgelegten Intervallen (z. B. täglich, wöchentlich, monatlich und jährlich) am DR-Standort gespeichert werden.
- Behalten Sie einen Wiederherstellungspunkt pro Woche für X Wochen: Der letzte Wiederherstellungspunkt jeder Woche wird für die angegebene Anzahl von Wochen gespeichert.
- Einen Wiederherstellungspunkt pro Monat aufbewahren für X Monate: Der letzte Wiederherstellungspunkt von jedem Monat wird für die angegebene Anzahl von Monaten gespeichert.
- Behalten Sie einen Wiederherstellungspunkt pro Jahr für X Jahre: Der letzte Wiederherstellungspunkt von jedem Jahr wird für die angegebene Anzahl von Jahren gespeichert.
- RTO und RPO: Ein Ziel der Wiederherstellungspunkte (RPO) ist der früheste Zeitpunkt, zu dem Ihre VM während der DR zurückgesetzt werden sollte. Damit definiert es die Datenmenge, die verloren gehen kann, ohne Ihrem Unternehmen unangemessenen Schaden zuzufügen. Mit Replikation können Sie kürzere RPOs erreichen, da Ihre Replikationsaufträge nach Ihren Wünschen mit den von Ihnen festgelegten benutzerdefinierten Plänen ausgeführt werden können.
Die VM-Replikation kann Ihnen auch dabei helfen, kurze Wiederherstellungszeit-Ziele (RTOs) einzuhalten. Das Wiederherstellungszeit-Ziel ist der festgelegte Zeitraum, innerhalb dessen Ihre Geschäftsabläufe nach einer Katastrophe wiederhergestellt sein müssen. Mit der Replikation kann die VM sofort wiederhergestellt werden, indem einfach das Replikat eingeschaltet wird.
Verwendungsfälle
Die VM-Replikation kann Ihre geschäftskritischen Dienste vor einer Reihe von Problemen schützen, darunter solche, die von dem Verlust/Ausfall kritischer VMs, dem Ausfall von Hosts/Datenspeichern oder Naturkatastrophen verursacht werden. Die VM-Replikation wird in der Regel eingesetzt, wenn Projekte mit sensiblen Daten arbeiten und/oder keinen Datenverlust tolerieren können. Die Replikation ist für diese Fälle geeignet, da die VM-Wiederherstellung im Katastrophenfall einfach und fast sofort durchgeführt werden kann.
Die Replikationsfunktionalität wird in den folgenden Verwendungsfällen verwendet:
- Disaster Recovery mit Replik
Mit NAKIVO Backup & Replikation lassen sich die negativen Auswirkungen von Systemausfällen, wie Ausfallzeiten und Umsatzverluste, weitgehend abmildern. Mit der VM-Replikation können Sie eine gesamte VM mithilfe ihrer Replikate fast sofort wiederherstellen und so eine hohe Verfügbarkeit Ihrer Unternehmensdienste sicherstellen.
- Failover und Failback
Wenn eine Katastrophe Ihre primäre Datenbank lahmlegt, kann Ihr Unternehmen schwerwiegende Auswirkungen davontragen – es sei denn, Sie verfügen über einen wirksamen DR-Plan. Hier kommt Failover ins Spiel. Failover ist der Prozess der Umstellung von einer Quelle-VM auf ein VM-Replikat, um geschäftskritische Workloads von einem betroffenen Standort auf einen DR-Standort zu verlagern.
Sobald Sie Ihren primären Standort wiederhergestellt haben, können Sie den Geschäftsbetrieb wieder auf die ursprüngliche VM umstellen. Dieser Vorgang wird als Failback bezeichnet und ermöglicht Ihnen die Synchronisierung von Daten zwischen dem primären Standort und dem DR-Standort.
- Standortwiederherstellung
Mit NAKIVO Backup & Replication können Sie Standortwiederherstellungs-Aufträge (Aufträge) erstellen, bei denen es sich um einfach zusammenstellbare benutzerdefinierte Algorithmen für die Automatisierung und Orchestrierung des Disaster Recovery-Prozesses handelt. Die manuelle Umsetzung eines Disaster Recovery-Plans kann eine zeitaufwändige und ressourcenintensive Aufgabe sein. Glücklicherweise können Sie mit NAKIVO Backup & Replikation Aktionen in Standortwiederherstellungs-Aufträge zusammenfassen, die mit nur wenigen Klicks ausgeführt werden können. Sie können spezielle Standortwiederherstellungs-Aufträge erstellen, um jede Art von DR-Ereignis zu bewältigen.
Die folgenden Aktionen und Bedingungen können in Ihre Standortwiederherstellungs-Workflows aufgenommen werden:
- Failover-VMs. Failover zu einem bereits erstellten VM-Replikat.
- Failback-VMs. Übertragen Sie Workloads von einem VM-Replikat an einem DR-Standort zurück zu einer Quelle an einem Produktionsstandort.
- Starten Sie VMs. Starten Sie eine oder mehrere VMs.
- VMs stoppen. Eine oder mehrere VMs stoppen.
- Aufträge ausführen. Führen Sie Datensicherungsaufträge (Backup, Replikation usw.) aus, die Sie bereits für VMs erstellt haben.
- Aufträge stoppen. Laufende VM-Datensicherheits-Aufträge stoppen.
- Skript ausführen. Führen Sie Ihr eigenes Skript vor oder nach dem Auftrag auf einem Windows- oder Linux-Rechner aus.
- Repository anhängen. Ein Backup-Repository anhängen.
- Repository trennen. Ein angehängtes Backup-Repository trennen.
- E-Mails senden. E-Mail-Benachrichtigungen mit Details zu den Ergebnissen nach Abschluss einer bestimmten Aktion erhalten.
- Warten. Warten Sie eine bestimmte Zeit, bevor Sie mit der weiteren Aktion fortfahren.
- Bedingung prüfen. Prüfen Sie, ob eine Ressource vorhanden ist, ob eine Ressource ausgeführt wird oder ob eine IP/ein Hostname erreichbar ist, bevor Sie mit der weiteren Aktion fortfahren.
Fazit
Jedes Unternehmen kann Opfer einer unerwarteten Katastrophe oder eines Systemausfalls werden, die die Integrität geschäftskritischer Daten gefährden können. Daher ist ein effektiver DR-Plan in der modernen Geschäftswelt, in der hohe Verfügbarkeit und Geschäftskontinuität von größter Bedeutung sind, absolut unerlässlich.
Replikation kann ein unschätzbares Werkzeug für DR sein. Synchrone und asynchrone Replikationsstrategien sollten je nach Ihren geschäftlichen Prioritäten und Anforderungen intelligent implementiert werden. Asynchrone Replikation ist eine kostengünstige Strategie, die weniger Bandbreite und keine zusätzliche Hardware erfordert. Sie kann zum Speichern weniger sensibler Daten und zum Übertragen von Daten über große Entfernungen verwendet werden. Obwohl die synchrone Replikation in hohem Maße von der Netzwerkverbindung und der Latenz abhängt, garantiert sie einen Null-Datenverlust und ermöglicht Ihnen die sofortige Wiederherstellung geschäftskritischer Vorgänge.
NAKIVO Backup & Replication ist eine schnelle und flexible Lösung, mit der Sie Ihre VMs an einem oder mehreren Remote-Standorten für eine zuverlässige Speicherung replizieren können. Mit dieser Lösung können Sie Ihre Replikate im Katastrophenfall einfach einschalten und so Umsatzverluste und langfristige Ausfälle vermeiden.