Cloud-Failover und Replikation für den Schutz von Workloads

Sorgfältig die Zielorte für Cloud-Failover und Replikation auswählen

Replikation und Failover sind weitgehend verschiedene Technologien, die zwei Arten von Workload Protection ansprechen. Jeder Ansatz bietet außerdem verschiedene Funktionsbereiche an. Zum Beispiel kann ein Failover „kalt“, „warm“ oder „heiß“ sein, während Replikation von regelmäßigen VM-Snapshots bis zu periodisch wiederkehrenden System-Backups reichen kann.

Die Entscheidung, welche Public-Cloud-Ressourcen für jede Aufgabe in Anspruch genommen und wo sie physisch aufgestellt werden, wird womöglich eine bedeutende Auswirkung auf die Wiederherstellbarkeit der Workloads haben.

Zuerst muss man wissen, wo sich der Zielort für Failover oder Replikation befindet. Public Cloud Provider verfügen in der Regel über einen großen globalen Footprint, wo ihre Rechenzentren verteilt über verschiedene Gegenden der Welt – „regions“ genannt – aufgestellt sind. Dies ermöglicht es Unternehmen, über den Globus hinweg ihre Daten zu platzieren und ihre Rechenprozesse durchzuführen. Dieses Prinzip fügt aber auch eine gesetzmäßige und technische Komplexität wie zum Beispiel Latenzen hinzu.

Umfangreiche Replikationsprozesse über große Entfernungen hinweg können signifikante Latenzen mit sich bringen, die die Replikation verlangsamen und die Performance reduzieren. Hinzu kommt, dass es viel Zeit beanspruchen kann, eine Replikation aus einer weit entfernten Region wiederherzustellen. In manchen Fällen wird auch die Platzierung von Workloads in einer entfernten Public-Cloud-Region dazu führen, behördliche oder sonstige Anforderungen zu verletzen.

Die beste Praxis besteht hier darin, Zielorte für die Workload Protection so nah wie möglich einzurichten.

Passende Bandbreite und Konnektivität garantieren

Bandbreite ist ausschlaggebend bei Schutzaufgaben für datenintensive Workloads wie zum Beispiel bei Replikation, Snapshots und Backups. Dies ist in der Regel ein WAN-Problem, und IT-Teams sollten es deshalb mit einem angemessenen und zuverlässigen Internetzugang angehen.

Wenn ein Unternehmen über mehr Bandbreite verfügt, kann es mehr Daten in kürzerer Zeit in die Cloud verschieben – aber mehr Bandbreite kostet auch mehr Geld. Wenn Unternehmen die Public Cloud für Workload Protection nutzen, müssen sie Zeitdauer und Datenmengen mit den Kosten für Netzwerkbandbreite abwägen. In einigen Fällen wird es eventuell nötig sein, für Replikation, Snapshot, Backup oder andere Datenschutzaufgaben weniger Daten zu bewegen oder mehr Zeit in Anspruch zu nehmen.

Um die Konsistenz und Zuverlässigkeit von verfügbarer WAN-Bandbreite zu verbessern, sollte man eine direkte oder dedizierte Netzwerkverbindung zwischen On-Premises-Rechenzentren und Public-Cloud-Regionen verwenden. Services wie zum Beispiel AWS Direct Connect und Azure ExpressRoute können diese direkten Verbindungen bereitstellen, die einen dedizierten Netzwerkkanal zu dem Rechenzentrum des Cloud Providers einrichten. Das Ergebnis wird ein gleichmäßigerer Datenverkehr sein.

Den Netzverkehr organisieren

Jeder Replikations- oder Failover-Prozess braucht eine logische Ordnung oder Abfolge. Es könnte verlockend sein, eine Replikation für jeden Workload zur gleichen Zeit oder einen Failover in eine Cloud ebenfalls zur gleichen Zeit auszulösen, aber das kann die Netzwerkbandbreite belasten und diese Prozesse zu kritischen Zeitpunkten verzögern.

Stattdessen sollte man die Prozesse für Workload Protection auf eine Art und Weise verteilen, die die die Netzwerklast verringert und Aufgaben priorisiert. Zum Beispiel sollte man Replikationen so verteilen, dass jeder Server oder jede Server-Gruppe einen anderen Zeitplan bekommt. Und dieser Zeitplan sollte außerdem die Wichtigkeit der jeweils betroffenen Workloads berücksichtigen – geschäftskritische Workloads sollten öfter als nichtkritische repliziert werden.

Wie lautet noch mal Ihre Adresse?

Wenn ein Failover einer Workload zur Public Cloud stattfindet, wird sie eine neue Public-IP-Adresse bekommen. Diese Adresse unterscheidet sich von der vorherigen, die Workloads wie zum Beispiel Webserver und Enterprise-Anwendungen unterstützt hatte. Die IT-Teams müssen sorgfältig IP-Adressen nachbessern, so dass Anwender nach einem Failover noch immer Workloads finden und benutzen können.

Es gibt zahlreiche Methoden, wie man mit der Migration von IP-Adressen umgeht – in der Regel kommt dabei ein DNS-Service (Domain Name System) ins Spiel, der die Änderung durchführt, wenn ein Fehler entdeckt wird. Cloud-Provider wie zum Beispiel AWS bieten DNS-Services wie Amazon Route 53 an, während Services von Drittanbietern wie zum Beispiel DNS Made Easy ebenfalls den Prozess automatisieren können.

Umfangreiche Replikations-Prozesse über große Entfernungen hinweg können signifikante Latenzen mit sich bringen, die die Replikation verlangsamen und die Performance reduzieren.

Die Failover-Prozesse sollten einem ähnlichen Paradigma folgen. Zuerst sollten mehrere der besonders geschäftskritischen Systeme für ein Failover ausgewählt und fortgeführt werden, gefolgt von nachträglichen kleinen Gruppen je nach Wichtigkeit für das Unternehmen. Zum Beispiel muss zuerst ein Failover der Datenbank-Server erfolgen, bevor die Applikationen drankommen, die auf einer Datenbank aufbauen.

Die Kosten für Cloud-Daten abschätzen

Im Allgemeinen sind die Kosten von Cloud-Ressourcen in einem Failover-Szenario akzeptabel, verglichen mit den Umsatzeinbußen und sonstigen Kosten, während man offline ist. Aber Replikation, Snapshots, Backup, Archivspeicher und andere Strategien für Datenschutz in der Cloud können darüber hinaus noch zu ganz anderen finanziellen Schockerlebnissen führen.

Seitdem Public-Cloud-Provider Speicherkosten auf Basis von Kapazität und Ausgangs-Traffic erheben, sollte Replikation in die Public Cloud eine klare Linie beim Data Lifecycle Management enthalten, um Storage abzugrenzen und zu kontrollieren. Um die Speicherdauer zu limitieren und hier anfallende Kosten zu reduzieren, sollte man unbedingt alte oder nicht mehr gebrauchte Daten aus der Cloud löschen. Für Daten, die langfristig vorgehalten werden müssen wie zum Beispiel Archive, empfehlen sich Speicherdienste wie Amazon Glacier und Google Nearline, die für langfristigen und seltenen Zugang entwickelt wurden und entsprechend günstiger sind.

Die Umgebung regelmäßig testen

Es ist extrem wichtig, einen Prozess für Workload Protection zu testen, um sich zu vergewissern, dass er wirklich funktioniert.

Bei Replikation könnte dies bloß bedeuten, in einer Testumgebung einen Snapshot in einer VM wiederherzustellen. In ähnlicher Weise kann das IT-Team einen Failover manuell aktivieren und so abklären, ob der kalte, warme oder heiße Einsatz wie erwartet funktioniert.