Zur Optimierung der Anwendungsverfügbarkeit braucht jedes Unternehmen, unabhängig von seiner Größe, einen Sekundärstandort, um Disaster Recovery (DR) zu gewährleisten. Mit modernen Technologien können Workloads sofort an einen Sekundärstandort übertragen werden, wenn es am Primärstandort zu Problemen kommt.

Früher kamen DR-Standorte aus verschiedenen Gründen nur für große Unternehmen in Frage. Durch neue Technologien und Serviceangebote, wie Disaster-Recovery-as-a-Service (DRaaS), sind DR-Standorte heute allerdings für alle Unternehmen verfügbar und erschwinglich.

Der Virtualisierungs-Boom

Es steht außer Frage, dass die enorme Zunahme an Disaster Recovery-Lösungen mit der Virtualisierung zusammenhängt. Früher war man bei der Replikation von Daten und Anwendungen an einem Sekundärstandort auf Speicher-Arrays angewiesen, doch nicht jede Lösung beinhaltete auch native Replikationsfunktionalitäten. Außerdem bringt die Replikation auf Speicherebene zwei weitere Herausforderungen mit sich:

  1. Technologische Voraussetzung für die Replikation auf Speicherebene ist, dass beide Standorte dasselbe Speichermodell oder dieselbe Marke für das Speichersystem nutzen, da jede Replikationstechnologie proprietär ist. Für große Unternehmen ist das kein Problem. Sie können für den Sekundärstandort denselben Umfang und dieselbe Performance wie für den Primärstandort bereitstellen. Kleinere und mittlere Unternehmen haben allerdings nicht den finanziellen Spielraum oder sind schlicht nicht bereit, dasselbe Budget für Primär- und Sekundärstandorte auszugeben. Sie brauchen eine erschwingliche Lösung.
  2. Die Replikation auf Speicherebene bietet nicht die Granularität, die nötig ist, um granularen Replikationsrichtlinien gerecht zu werden. Ein Speicher-Array unterscheidet nicht zwischen den einzelnen Workloads auf den Hosts. Sind eine Datenbank und ein Dateiserver am selben Standort gespeichert, werden sie anhand derselben Richtlinie repliziert. Es ist daher schwierig, unterschiedliche Normen zu definieren und je nach Workload unterschiedliche RPOs und RTOs einzuhalten, wenn die Administratoren die Workloads nicht in isolierten Silos verwalten. Das führt allerdings häufig zu einem zusätzlichen Management- und Monitoring-Aufwand und erfordert zusätzliche IT-Ressourcen.

Mit der Virtualisierung sind der Zugriff, die Konfiguration und der Einsatz von Replikationsservices problemlos möglich, der zusätzliche Aufwand entfällt. RTOs und RPOs lassen sich spezifisch für jeden Workload festlegen, denn statt riesiger, starrer Speicher-Arrays werden jetzt flexible, einzelne virtuelle Maschinen verwaltet. IT-Administratoren können für bestimmte Workloads Prioritäten definieren. So können Sie beispielsweise eine Replikationslösung für den wichtigen Datenbankserver festlegen, die nahezu kontinuierlich (alle 15 Minuten) Kopien am Sekundärstandort erstellt, während für den Dateiserver dies nur einmal pro Stunde oder einmal pro Tag erfolgt. Die Virtualisierung hat die Hardwareebene abstrahiert, so dass verstärkt granulare Steuermöglichkeiten zur Replikation zur Verfügung stehen, Ergebnisse optimiert und IT-Ressourcen effizienter ausgelastet werden.

Der Bedarf eines Sekundärstandorts

Disaster Recovery bietet eine hervorragende Lösung für eine verbesserte Verfügbarkeit in modernen Rechenzentren. Dabei werden die Vorteile der Virtualisierung und modernster Replikationstechnologien optimal ausgenutzt, um externe Replikate virtueller Maschinen zu erstellen.

Aber auch bei der Planung eines DR-Standorts ergeben sich Herausforderungen: Viele Unternehmen stellt der Investitionsaufwand für den Aufbau und die Verwaltung des Sekundärstandorts vor Probleme. An einem Sekundärstandort, egal ob im eigenen Besitz oder gemietet (etwa in einer Co-Location-Umgebung), muss neue Hardware oder Software passend für die Produktivumgebung bereitgestellt werden. Diese muss dann konfiguriert und verwaltet werden, was den IT-Infrastrukturaufwand praktisch verdoppelt. Und da diese Produktiv-Workloads vor allem am Primärstandort genutzt werden, sind sie am Sekundärstandort kaum im Einsatz. Im Vergleich zum Mehrwert ergeben sich damit noch höhere Kosten, so dass es nicht einfach ist, den ROI gegenüber der Geschäftsführung zu rechtfertigen.

Große Unternehmen verfügten bisher stets über das nötige Budget für einen eigenen Sekundärstandort oder hatten bereits mehr als eine Niederlassung mit jeweils eigenem IT-Personal, um diese als Sekundärstandort zu nutzen. Heute müssen allerdings auch große Unternehmen Investitions- und Betriebskosten senken, während sie zugleich auf einen DR-Standort angewiesen sind.

Disaster-Recovery-as-a-Service

Hier bietet sich eine cloudbasierte Lösung an, d. h. die Nachfrage nach Disaster-Recovery-as-a-Service steigt. Ressourcen werden von einem Serviceprovider mit nutzungsbasiertem Abrechnungsmodell angemietet. Der Kunde profitiert von den Vorteilen (verfügbare CPU-, RAM-, Storage- und Netzwerkressourcen für Failover), und zwar ohne jegliche Investitionskosten und ohne den täglichen Aufwand für das Design die Implementierung und Verwaltung des DR-Standorts. Serviceprovider mit DR-Expertise übernehmen das vollständige Management der Infrastruktur. Im Gegenzug bietet der Serviceprovider ein SLA (Service Level Agreement), das dem vereinbarten Service entspricht. Die Virtualisierung ermöglicht es dem Serviceprovider, je nach Workload auch unterschiedliche SLAs anzubieten.

Der Kunde kann sich so auf die eigentliche Replikation konzentrieren, verschiedene RPOs für Anwendungen definieren und seine DR-Strategie und DR-Lösung entsprechend dem unternehmerischen Bedarf statt den IT-Anforderungen festlegen.

Die hohe Nachfrage nach DRaaS überrascht daher nicht. Dieses Trenddiagramm für Google-Suchbegriffe zeigt das stark ansteigende Interesse an DRaaS.
DRaaS popularity trends

Sucht man dagegen nach „Disaster Recovery“, wird deutlich, dass DR für sich allein an Bedeutung verliert:

demand for Disaster Recovery

Kunden suchen also nicht mehr nach einer generischen Lösung, sondern gezielt nach DRaaS-Angeboten von einem Serviceprovider.

Die Vielzahl an Lösungen, die auf dem Markt verfügbar sind, ist beeindruckend. Unternehmen jeglicher Größe, die sich für eine DRaaS-Lösung interessieren, sollten die Möglichkeiten, die die einzelnen Services bieten, genau analysieren. Sehen wir uns einige davon an.

1. Benutzerfreundlichkeit

Häufig findet die Benutzerfreundlichkeit als Eigenschaft einer DR-Lösung keine Beachtung. Von Interesse ist oft vielmehr der Funktionsumfang einer bestimmten Technologie. Ist diese Technologie jedoch sehr komplex und schwierig in der Einrichtung und Nutzung, ist Vorsicht geboten. Der versprochene ROI lässt sich dann nur mühsam realisieren und der Mehrwert für Ihr Unternehmen ist eingeschränkt. Andererseits kann eine benutzerfreundliche Lösung schneller getestet und implementiert werden und erfordert einen geringeren Aufwand. Und der wichtigste Punkt: der Anwender profitiert von einer Technologie, die bei der fortlaufenden Nutzung des Service „just works“, ohne dass immer wieder nachjustiert oder Fehler behoben werden müssen.

Auch dieser Aspekt wird häufig ignoriert: Bei DR stehen die IT-Mitarbeiter häufig unter hohem Stress wegen technischer Probleme, Ausfallzeiten und dem Druck seitens der Geschäftsführung, den Betrieb schnell wieder ans Laufen zu bringen. Mit einer benutzerfreundlichen Lösung können sie sich auf die wenigen einfachen Schritte konzentrieren, um die Anwendungen am Sekundärstandort zu starten, während eine komplexe Lösung die Probleme in den ohnehin hektischen Situationen noch verstärkt.

Die Cloud-Technologie von Veeam, d. h. die VM-Replikation über Veeam Cloud Connect, ist benutzerfreundlich und ermöglicht ein einfaches Setup dank der Single-Port TCP-Konnektivität über eine sichere, zuverlässige SSL/TLS-Verbindung zum Serviceprovider Ihrer Wahl. Damit entfällt die Einrichtung und Pflege von VPN-Verbindungen oder das Öffnen mehrerer Ports in den Firewalls. Der einzelne Tunnel wird für jede Art von Datentraffic eingesetzt: für den Traffic des Replikationsmanagements, für die eigentliche VM-Datenübertragung und auch für die Kommunikation zwischen den VMs bei partiellem Failover. Die gesamte Kommunikation wird in diesem einzigen Tunnel gekapselt. Ist die Verbindung erfolgreich hergestellt, erübrigt sich jede weitere Netzwerkkonfiguration.

2. Und was ist mit dem Netzwerk?

Wichtigster Zweck von DRaaS ist die Bereitstellung von Replikationsservices. Eine Replikation allein reicht allerdings nicht aus. Die größte Herausforderung bei DR-Services ist NICHT die Replikation, sondern das Netzwerk. Für Anwendungen gelten bestimmte Netzwerkkonfigurationen. Viele moderne Services müssen über das Internet für Nutzer, Anbieter und Kunden bereitgestellt werden. Es ist relativ einfach, eine virtuelle Maschine am DR-Standort zu replizieren und zu starten. Sehr viel schwieriger ist es allerdings sicherzustellen, dass das Netzwerk korrekt konfiguriert und bei einer Konfigurationsänderung automatisch umprogrammiert wird – wobei das häufig als selbstverständlich vorausgesetzt wird. Bei einer DRaaS-Lösung sollte sich der Kunde einige wirklich spezifische Fragen stellen, um herauszufinden, was die Lösung in diesem Bereich auch tatsächlich leisten kann. Anwendungen reibungslos und transparent zwischen dem Primär- und Sekundärstandort verschieben zu können, ist extrem vorteilhaft gegenüber dem Zeitaufwand, der für die Neukonfiguration der Anwendungen beim Failover erforderlich ist.

3. Self-Service

Self-Service hat oberste Priorität für alle Cloud-Services – DRaaS ist dabei keine Ausnahme. Doch wie viele Prozesse können Serviceprovider automatisieren? Diese Frage scheint auf den ersten Blick zwar nur für den Serviceprovider relevant zu sein, doch automatisierte Services bieten auch dem Anwender viele Vorteile. Änderungen für ihre Abonnements lassen sich schneller beantragen und DRaaS-Serviceabonnements schnell und einfach anpassen. Cloud-Services sind nutzlos, wenn ein Serviceprovider stunden- oder tagelang zur Bearbeitung einer Serviceanforderung benötigt.

Die Self-Service-Funktionalität bestimmt außerdem, wie viele Prozesse Sie selbst ohne Rücksprache mit dem Serviceprovider ausführen können. Letztendlich obliegt dem Serviceprovider die Verantwortung für die zugrunde liegende Infrastruktur, während der Zuständigkeitsbereich für die Prozesse in Verbindung mit Unternehmensdaten und -Workloads beim jeweiligen Unternehmen bleiben kann.

Dafür sprechen einfache, aber wichtige Gründe: Der Kunde weiß genau, wie der Service konfiguriert oder wie er bei Bedarf rekonfiguriert werden muss.

Self-Service spielt auch bei der Minimierung der Ausfallzeit bei einem Failover eine wichtige Rolle: Kommt es zu einer schweren Störung auf Kundenseite, kann der Kunde mit Self-Service-Funktionalitäten ein schnelles Failover einleiten, ohne Zeit mit der Öffnung eines Supporttickets beim Serviceprovider zu verlieren.

Fazit

Die Nachfrage nach Disaster-Recovery-as-a-Service steigt, und viele Serviceprovider bieten diesen Service mit unterschiedlichen Technologien an. Kunden sind bei der Entscheidung für die richtige Lösung angesichts des großen Angebots häufig unsicher. Schließlich bieten nicht alle Lösungen denselben Serviceumfang und einen unterschiedlichen Mehrwert.

Serviceprovider, die Veeam Cloud Connect Replication nutzen, können ihren Kunden die in diesem Artikel aufgeführten Vorteile garantieren. Kunden benötigen lediglich eine Installation oder ein Upgrade der Veeam Availability Suite v9 und ein Serviceabonnement bei einem Veeam-powered DRaaS-Provider, um Veeam Cloud Connect nutzen zu können.

 

Mehr zur Veeam DRaaS-Lösung erfahren Sie hier:

GD Star Rating
loading...
Veeam Availability Suite — Gratis-Demo herunterladen

Luca Dell'Oca
Author: Luca Dell'Oca

Publizieren: Juli 5, 2016