Blog

AWS Elastic Disaster Recovery

Das Thema Disaster Recovery kann eine große Herausforderung sein, weil unterschiedlichste Szenarien bedacht werden müssen.
1. Februar 2023
Skaylink

Für Schadensfälle gut gewappnet

Bei der Entwicklung von Architekturen kann Disaster Recovery (DR) eine große Herausforderung sein – unabhängig davon, ob Sie diese vor Ort oder in der Cloud hosten. Der Grund dafür ist, dass unterschiedlichste Szenarien bedacht werden müssen. Deren Eintreffen ist zwar eher unwahrscheinlich, hat aber im Zweifelsfall eine große Auswirkung auf die Ressourcen.

Flexibel und kosteneffizient: AWS Elastic Disaster Recovery Service

Für Disaster Recovery bietet AWS einen interessanten neuen Service namens AWS Elastic Disaster Recovery (DRS). DRS wurde im November 2021 weltweit veröffentlicht und ist nun die empfohlene Disaster-Recovery-Lösung für Workloads auf Linux- oder Windows-Betriebssystemen – unabhängig davon, ob Ihre Workloads im OnPrem-Datacenter oder in der AWS-Umgebung ausgeführt werden.

DRS verwendet einen installierten Agenten, der im Speicher läuft und Schreibvorgänge auf angeschlossenen Festplatten erkennt. Mithilfe eines asynchronen Replikationsmechanismus auf Blockebene werden diese Schreibvorgänge in einen Staging-Bereich repliziert. Dieser befindet sich in der AWS-Umgebung des Kunden und nutzt eine kostengünstige EC2-Instanz und Elastic Block Stores (EBS) als Speicher. Auf diese Weise bleibt der Staging-Bereich kosteneffizient und speichert dennoch alle Daten, die zur Wiederherstellung benötigt werden.

Im Fall eines Desasters oder bei einer DR-Übung, die direkt über die Konsole getestet werden kann, verwendet DRS EBS-Snapshots, um den Wiederherstellungsbereich aufzubauen.

Die Fakten auf einen Blick

  • Failover innerhalb von Minuten, auch bei Terrabyte-Systemen
  • Recovery Point Objective (RPO) erfolgt durch aktive Replikation innerhalb von Sekunden
  • On-Premises zu AWS, Cloud zu AWS oder AWS zu AWS – DRS vereinfacht Disaster Recovery

Irrtümer über Wiederherstellungspunkte

Es ist ein weit verbreiteter Irrtum, dass einige Anwendungen wie Oracle, MS SQL oder SAP HANA anwendungskonsistente Wiederherstellungspunkte benötigen, um ohne Beschädigung wiederhergestellt werden zu können. Die meisten modernen Anwendungen und Dateisysteme können sich von absturzkonsistenten Wiederherstellungspunkten aus erholen, da sie ACID-kompatibel sind. Dies bedeutet, dass Datenbanken nicht abgeschlossene Transaktionen zurücksetzen und sie in einen konsistenten Zustand zurückversetzt werden.

Selbstverständlich gibt es Ausnahmen: Einige Anwendungen benötigen weiterhin anwendungskonsistente Snapshots. Es kann sich dabei um Anwendungen handeln, die in einem Cluster laufen und deren Knoten bei der Erstellung von Backups synchronisiert sein müssen – oder um Anwendungen, bei denen Snapshots zu einer bestimmten Tages- (oder Nachtzeit) erstellt werden müssen.

"AWS Elastic Disaster Recovery ist genau das Puzzleteil, das wir gesucht haben, um Disaster Recovery für einen herausfordernden Technologiestack umzusetzen."

Die Lösung für unseren Kunden aus der FSI-Branche

Skaylink konnte den AWS Elastic Disaster Recovery Service (DRS) bei einem FSI-Kunden nutzen, um eine DR-Architektur für eine Oracle-auf-EC2-Anwendung zu schaffen und die dafür erforderlichen Lizenzkosten zu senken. 

Die Skaylink-Expert*innen erreichten dies, indem sie die proprietäre Lösung durch DRS ersetzten und die Anzahl der aktiven Lizenzen reduzierten. Die vorherige Lösung konnte unter Einhaltung der externen regulatorischen Vorschriften für die Bankenbranche ersetzt werden.

Bei unserem Kunden konnten wir ein DRS-Setup aufbauen, das eine Oracle-Anwendung auf EC2 unterstützt, die aufgrund spezifischer Anforderungen nicht auf AWS Relational Database Service (RDS) laufen kann. DR-Drilltests zeigten eine Datenkonsistenz zwischen Quelle und Wiederherstellungsbereich, wobei der Wiederherstellungsbereich der Applikationen innerhalb von Minuten verfügbar war.  

Die Alternative zu DRS wäre Oracle DataGuard gewesen, was zusätzliche Lizenzen erfordert und weitere Kosten verursacht hätte.