igor - Fotolia

Disaster Recovery: Starker Sturm gefährdet Ihre Strategie

Stürme, die weite Flächen lahmlegen, können Ihre Disaster-Recovery-Strategie über den Haufen werfen. Oft sind alte Methoden besser als High-Tech.

Disaster Recovery heißt auch Vorsorge vor Unwettern. Stürme und Gewitter können zu Stromausfällen und sonstigen Schäden führen. Das wird auch in Deutschland durch den Klimawandel zusehends zum Problem. Vor wenigen Jahrzehnten waren hierzulande Tornados noch unbekannt, aber mittlerweile treten sie häufiger auf.

Eigentlich sollten Software-definiertes Storage (SDS) und hyperkonvergente Infrastrukturen (HCI) die Frage nach der Verfügbarkeit bei Storage Disaster Recovery beantwortet haben. Und die Cloud ist keine Gewitterwolke, sondern ein geheimnisvoller Ort, wo Daten sicher gelagert werden, wenn in der Nähe der Deich bricht.

Aber das trifft leider nicht immer zu. Wie sich beim Hurrikan Sandy an der Atlantikküste der USA vor einiger Zeit zeigte, sind Daten bei Unwettern gefährdet, egal on sie sich auf Festplatten, Flash-Laufwerken oder in Hochverfügbarkeitsumgebungen befinden.

 Die meisten von Hypervisoren kontrollierten SDS- oder HCI-Plattformen nutzen Storage auf folgende Weise:

  1. Sie schaffen Storage-Silos, die nicht effektiv verwaltet oder geteilt werden können, besonders wenn verschiedene Hypervisoren zum Einsatz kommen.
  2. Sie führen wieder zu Identitätsproblemen bei Data Protection.

Silos sind ein Problem

Silos bei Storage können zwar das Management hinter einem einzelnen Server vereinfachen, verringern aber die Nutzungseffizienz und die Gesamtallokation über heterogene Infrastrukturen mit verschiedenen SDS Stacks, die von verschiedenen Hypervisoren kontrolliert werden.

IT-Administratoren sind in einer solchen Umgebung mit einer verwirrenden Mischung an Storage-Strukturen konfrontiert, die mit komplizierten Strategien getestet und verwaltet werden müssen. Im Endeffekt werden Disaster Recovery und Data Protection aufwendiger und komplexer.

Identitätsprobleme

Identität (engl. Identicality) bei Storage Mirroring bedeutet, dass identische Medien und Geräte von der Replikationsinfrastruktur benutzt werden müssen. Administratoren müssen also am Disaster-Recovery-Standort genau die gleiche Hardware vorhalten wie am Produktionsstandort. Dies ist schwer zu erreichen, wenn man ein Zweitrechenzentrum nur anmietet oder Disaster Recovery in der Cloud nutzen will.

Identität war einst ein Fluch für Planer von Disaster Recovery, weil die Hersteller von Storage Arrays ihre Geräte proprietär gestalteten, um das einfache Kopieren von Daten auf die Hardware eines anderen Anbieters zu verhindern. Mit SDS meldete sich die Identität in neuer und stärkerer Form zurück, denn in manchen Fällen ist es unmöglich, Storage kontrolliert von Hypervisor Marke A zu benutzen, um Daten zu speichern oder zu kopieren auf Storage kontrolliert von Hypervisor Marke B.

Es ist nicht einfach, die Hindernisse zu überwinden, die durch die Frage der Identität aufgeworfen werden. Einige Anbieter von Data Protection Software wie etwa Acronis und Arcserve verfolgen eine Methode, die vom Hypervisor und der Hardware unabhängig ist, und können einen Service einrichten, der auf Daten verweist, egal wo sie gespeichert sind. Das setzt aber voraus, dass es einen Administrator gibt, der den Service einrichtet und wartet. In der heutigen IT-Welt ist dies zunehmend unwahrscheinlich, weil Storage-Spezialisten durch Generalisten abgelöst werden, die sich nur mit Virtualisierung auskennen.

Die Cloud-Methode

Natürlich kann man auch die Cloud zur Data Protection einsetzen. IBM und andere haben Cloud-Optionen in ihre Data-Protection-Software eingebaut. Diese können Client-Software mit Produktionsservern verbinden und damit Kunden universellere Data Protection bieten. Dies löst zwar einige Probleme, aber nicht alle.

Data Protection Software, die Cloud-fähig ist, ist noch lange kein Disaster Recovery as a Service (DRaaS). Die Anbieter sind keine Experten für die Nuancen der Planung von Disaster Recovery.

Viele Provider und Kolokationsexperten stürzen sich auf DRaaS, weil sie damit ihren Umsatz erhöhen können, aber nicht weil sie sich wirklich damit auskennen. Vor kurzem wurde ein Fall bekannt, bei dem ein Provider die Daten eines Kunden einfach weggeworfen hat und offensichtlich darauf wettete, dass niemals eine Restoration angefordert würde.

Selbst wenn ein DRaaS-Provider ehrlich ist, fehlt vielerorts die Bandbreite, um die Verbindung zwischen Kunde und Cloud herzustellen, vor allem wenn ein regionales Unglück geschieht. Es können sich eine Menge an Backup-Daten beim Provider ansammeln und deren Wiederherstellung zum Albtraum werden.

Eine minimale Verbindung von 10 Gbps ist nötig, um nur zehn TB binnen eines akzeptablen Zeitraums von zwei Stunden und 15 Minuten zu übertragen. Bei einem WAN ist so eine Bandbreite sehr teuer.

Günstiger ist ein Ballungsraumnetz mit Multiprotocol Label Switching (MPLS) und synchronen optischen Netzwerken. Das Problem liegt darin, dass solche Dienste auf dem flachen Land nicht zur Verfügung stehen.

Hurrikan Sandy stürmt los

Der Hurrikan Sandy hatte einen Durchmesser von 350 km. Wenn ein Rechenzentrum in New York ausfiel, war oftmals auch der Zweitstandort oder DRaaS-Provider in Philadelphia betroffen. Weil die verfügbare Bandbreite mit der Entfernung abnimmt, verlassen sich viele Firmen auf einen DRaaS-Provider, der nicht mehr als 50 km entfernt ist. Bei einem ähnlichen Sturm sind beide Standorte gefährdet.

Die Lösung besteht darin, die Daten auf einem Medium zu verschicken, sei es ein Band, eine robuste Festplatte oder ein Flash-Laufwerk. Dann wird dieses an einen Sekundärstandort gebracht, der mindestens 100 km entfernt ist. Einige Unwetter fordern sogar eine Entfernung von mindestens 200 km.

Daten per Lkw zu verschicken, scheint zwar auf den ersten Blick veraltet, wird aber von immer mehr Cloud-Providern unterstützt als eine Strategie des Cloud Seeding.     

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

Nächste Schritte

Mit diesen zehn Tipps können Sie einen Business-Continuity-Plan umsetzen

Methoden für Disaster Recovery für Ihr Unternehmen: Cloud oder Traditionell?

Bringen Software-definierte Netzwerke (SDN) Mehrwerte für Disaster Recovery?

Ausfall von Amazon Web Services: Was heißt das für Disaster Recovery?

Artikel wurde zuletzt im Juni 2017 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Disaster Recovery

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