Sicherungsdienste

Vor nichts fürchten sich IT-Mitarbeiter mehr als vor einem Datenverlust. Die effektivste Strategie zum Verhindern von Datenverlust ist das Sichern der Speichervolumes, virtuellen Computer, Datenbanken und anderen Systeme, die Daten speichern, sodass deren Daten wiederhergestellt werden können. Clouddienstanbieter bieten Sicherungsdienste nur zu diesem Zweck. Im Allgemeinen können diese Dienste zum Sichern von lokal sowie in der Cloud gespeicherten Daten verwendet werden. Zudem können Sicherungen geografisch repliziert und verteilt werden, um sie vor Ereignissen zu schützen, die zu einem Datenverlust in einem gesamten Rechenzentrum oder einer gesamten Region führen.

Die öffentliche Cloud bietet flexible Ressourcen in hohen Volumen – nicht nur große Speicher sondern hochgradig skalierbare Speicherpools. Sie sind mindestens so vielseitig, in einigen Fällen sogar vielseitiger, als die Sicherungsspeichersysteme und Bandlaufwerke, die sie ersetzen. Zudem eröffnen sie neue Möglichkeiten für Organisationen, Redundanzen, Failover und Sicherheitsnetze zu implementieren, die sich viele zu Zeiten, als alle Ressourcen mit Arbeitskapital gekauft werden mussten, nicht hätten leisten können. Speicheroptionen in der öffentlichen Cloud erfüllen eine Rolle, die Rechenzentren immer schon dringend benötigt haben, die bis kürzlich jedoch schwer zu erfüllen war.

Cloudbasierte Sicherungsdienste

Eine charakteristische Eigenschaft moderner Sicherungsdienste, die von Anbietern öffentlicher Clouddienste (CSP) bereitgestellt werden, ist deren Methode, die Infrastruktur ihrer Kunden zu erweitern. Bevor diese Dienste verfügbar waren, umfasste die Sicherungsstrategie einer Organisation in der Regel zwei Stufen: das Sichern von Datenvolumes, die Datenbanken hosteten, und das Sichern von Images virtueller Computer, die wichtige Workloads hosteten. Die Theorie hinter einer Sicherung besagte, dass ein Server durch einen von einem Systemfehler ausgelösten Ausfall abstürzt. Als Sofortmaßnahme wurde dann der Zustand dieses Servers aus einem Sicherungsimage wiederhergestellt.

Neben der cloudbasierten Infrastruktur gilt diese frühere Sicherungstheorie nun als veraltet. In modernen Systemen bestehen Server aus Software, nicht aus Hardware. Virtuelle Server werden entweder von einer hypervisorbasierten virtuellen Infrastruktur wie NSX von VMware gehostet oder aus Containern zusammengestellt und von virtualisierten Betriebssystemen gehostet. In beiden Fällen werden die Softwareimages der Workloads für Anwendungen und Dienste stetig verwaltet, aktualisiert und geschützt. Tatsächlich sind die aktiven Softwarekomponenten selbst Replikate dieser sicheren Masterinstanzen, oder bei der Containerisierung die Produkte ursprünglicher Masterinstanzen, die in Containerrepositorys gespeichert sind und nach Bedarf automatisch zusammengestellt werden. Ein Hardwarefehler, der zum Absturz eines Serverknotens führt, verursacht lediglich, dass die von diesem Knoten gehosteten Server vorübergehend nicht verfügbar sind. Die Infrastruktur leitet Datenverkehr einfach um diesen Knoten herum und bemüht sich in der Zwischenzeit nach besten Kräften darum, ihn zu ersetzen. Der Verwalter der Infrastruktur unternimmt nichts, was er nicht auch schon im Rahmen der üblichen Systemverwaltung unternommen hat.

Jedoch handelt es sich, wie selbst bei einer oberflächlichen Begutachtung moderner Rechenzentren klar würde, nicht bei jeder modernen Infrastruktur um eine cloudbasierte Infrastruktur. Dienste werden immer noch auf Computern ohne Betriebssystem in lokalen Rechenzentren gehostet. Es sind immer noch viele Client/Server-Netzwerke mit Middleware vorhanden. Zudem müssen in einem Hybridsystem, bei dem ein vor einigen Jahren entworfener Teil mit einem anderen Teil verbunden wird, der im letzten Jahrhundert entworfen wurde, immer noch genügend Informationen zum Verantwortungsbereich eines Systems gespeichert werden, sodass das System im Notfall an einem neuen Speicherort rekonstruiert werden kann. Dies sollte möglichst zügig durch geeignete Mittel und mit möglichst wenig Auswirkungen auf Servicelevel geschehen. Bei modernen Sicherungsstrategien könnte dieser neue Speicherort die öffentliche Cloud sein, selbst wenn sich das System, von dem eine Momentaufnahme erstellt wird, außerhalb der Cloud befindet.

AWS Backup

Im Frühjahr 2019 hat Amazon Web Services seinen cloudbasierten Sicherungsdienst für die Hybrid Cloud-Umgebungen der Kunden neu entworfen. Im Mittelpunkt des neuen AWS Backup-Diensts, dessen browserbasierte Konsole in Abbildung 2 dargestellt ist, steht eine Richtlinien-Engine, die Regelentscheidungen ähnlich wie für eine Firewall trifft. Mithilfe dieser Engine schreibt der Sicherungsadministrator Regeln, die Folgendes bestimmen:

• Welche Ressourcen in einem System müssen gesichert werden?

• Wie und wie oft soll jede Sicherung durchgeführt werden?

• Wo sollen die Images von Sicherungen gespeichert werden?

• Wie und wie oft soll die Integrität von Sicherungsimages überwacht werden?

• Wie lange sollen Sicherungsimages beibehalten werden?

• Unter welchen Umständen sollten Wiederherstellungen stattfinden?

Die vollständige Beschreibung mit allen aktiven Richtlinien wird als Sicherungsplan bezeichnet. Hier bezieht sich jede Regel auf Ressourcen innerhalb der AWS-Cloud, die ihrer Markierung nach gesichert werden müssen. Bei dieser Markierung handelt es sich um einen beliebigen Namen, der vom Administrator vergeben wird. Damit eine Ressource wie ein EBS-Volume (Elastic Block Storage) in einen Sicherungsplan aufgenommen wird, muss der Administrator dieser Ressource ihr einfach einen Markierungsnamen geben, den AWS Backup wiedererkennt. Auf diese Weise muss der Administrator oder Verwalter mit Verantwortung für eine AWS-Ressource nicht die AWS Backup-Konsole verwenden, nur um eine Ressource, für die er verantwortlich ist, zu einem vorhandenen Sicherungsplan hinzuzufügen.

Abbildung 2: Die AWS Backup-Konsole [Mit Genehmigung von Amazon]

Lokale Ressourcen können mithilfe von AWS Storage Gateway in einen Sicherungsplan aufgenommen werden. Zum Zwecke von AWS Backup agiert Storage Gateway als API-Wrapper um physische Speichervolumes und -geräte, um diese für AWS-Dienste zugänglich zu machen.

Ursprünglich ermöglichte Storage Gateway das Ersetzen vorhandener physischer Speicherressourcen durch cloudbasierte Gegenstücke mithilfe derselben Schnittstelle. Ein lokales iSCSI-Volume konnte beispielsweise in ein von AWS sogenanntes zwischengespeichertes Volume eingeschlossen werden. Durch diese Umschließung wird der Cloudspeicher für vorhandene lokale Anwendungen zugänglich, ohne dass Kunden diese Anwendungen neu entwickeln müssen. Daten, auf die häufig zugegriffen wird, könnten weiterhin im iSCSI-Volume als Cache gespeichert werden, wobei die entstehende Wartezeit reduziert wird. Alternativ dazu können kürzlich vorgenommene Änderungen am Inhalt des Gatewayvolumes lokal als Momentaufnahmen gespeichert werden. Storage Gateway unterstützt jedoch auch gespeicherte Volumes, in denen das lokale Gerät weiterhin eine vollständige lokale Kopie des Volumes beibehält, die dann von Storage Gateway in die Cloud gespiegelt wird. Der neue AWS Backup-Dienst nutzt den Rollentausch von Storage Gateway zusammen mit physischen Volumes, um die lokale Kopie als Sicherung des cloudbasierten Volumes festzulegen. Dabei fügt er eine zentrale Richtlinienverwaltungskonsole mit Regeln hinzu, die bestimmen, wie beide Replikate verwaltet werden sollen.

Für Zwecke der Notfallwiederherstellung bietet ein CSP als großen Vorteil die Funktion, die wichtigen Daten einer Organisation schnell an weit entfernten Standorten zu archivieren, um geografische Redundanz bzw. Georedundanz zu erreichen. AWS betreibt Cloudrechenzentren in mehr Verfügbarkeitszonen als jeder andere CSP. Der Dienst wirbt mit der nativen Funktion, für von ihm gehostete Anwendungen automatisch ein Failover in alternative Zonen auszuführen. Diese Funktion wird zudem durch die Datensicherungsredundanz erweitert. Failoverzonen befinden sich jedoch bekanntermaßen innerhalb derselben AWS-Region. In einer extremen Notfallsituation (die von Versicherungsunternehmen und somit Risikomanagern nicht berücksichtigt wird) wie einem Ausfall des Energieversorgungsnetzes kann es in angrenzenden Verfügbarkeitszonen zu Ausfällen kommen.

Ein Softwareentwickler oder ein IT-Operator mit Entwicklererfahrung kann mithilfe des AWS-Routingdiensts auf niedriger Ebene (Route 53) benutzerdefinierte Richtlinien für das bestimmte Georedundanzrouting einer Organisation schreiben. Diese Vorgehensweise ist jedoch sehr aufwendig. Neuerdings bietet AWS einen zugänglicheren Dienst namens AWS Global Accelerator, bei dem es sich um eine weitere Richtlinien-Engine handelt, die Datenverkehr und Route 53 dorthin leitet, wo Dienste und Speicher gehostet werden sollen.¹ Global Accelerator kann auch als eine Art „Überausgleich“ verwendet werden, wobei die Verteilung mehrerer Standorte für gehostete Anwendungen (und damit wichtige Daten) auf weit voneinander entfernten Verfügbarkeitszonen ermöglicht wird.

Eine andere Möglichkeit sicherzustellen, dass gesicherte Daten in ausreichend voneinander entfernten Regionen gespeichert werden, ist laut Amazon-Entwicklern das Festlegen eines Bucket (universeller Sicherungscontainer von AWS) als anfängliches Sicherungsziel, der dann an einem redundanten Standort in einer beliebigen Verfügbarkeitszone repliziert wird. AWS bietet Cross-Region Replication (regionsübergreifende Replikation, CRR) als separaten Dienst an.² AWS berechnet seine Sicherungsdienste nach Volumen, sowohl nach gespeicherten Gigabyte als auch nach wiederhergestellten Gigabyte.

Aus architektonischer Sicht ist AWS Backup als Spiegel für AWS-Ressourcen entworfen. Lokale Ressourcen können über zwei Schritte zu diesem Plan hinzugefügt werden. Zunächst werden diese lokalen Ressourcen in lokale AWS-Volumes umgewandelt (lokal von Amazon aus gesehen), dann verwenden Sie die Backup-Schnittstelle mit Wrapper um diese lokalen Ressourcen.

Azure Backup

Azure Backup ist gleichermaßen in der Lage, lokale Ressourcen (Server und virtuelle Computer) sowie in Azure gehostete Ressourcen zu sichern. Sein Ziel ist nicht, die vorhandene Sicherungsrichtlinie im Rechenzentrum zu ändern, nur um lokale Datenträger und Bandlaufwerke durch Cloudspeicher zu ersetzen. Der cloudbasierte Speicherort für gesicherte Dateien und Volumes in Azure wird als Recovery Services-Tresor bezeichnet. Dessen browserbasierte Konsole ist in Abbildung 3 dargestellt. Während des Setupvorgangs für diesen Tresor über das Azure-Portal lädt der Administrator den clientseitigen Agent herunter, der auch als Microsoft Azure Recovery Services-Agent oder „MARS“ bekannt ist, und installiert diesen. In Windows Server wird MARS als Anwendung ausgeführt, die stark einem System Center-Add-On ähnelt. (Alternativ kann ein Administrator auch System Center Data Protection Manager verwenden, in den die MARS-Funktionen bereits integriert sind.) Der Administrator sucht nach den Volumes und Diensten im Netzwerk, deren Daten gesichert werden müssen, und MARS verteilt seine Agents auf die für diese Komponenten verantwortlichen Serveradressen.

Abbildung 3: Konsole des Azure Recovery Services-Tresors [Mit Genehmigung von Microsoft]

Das Bereitstellungsmodell von Azure Backup basiert auf Servicelevelzielen für die Notfallwiederherstellung, die angemessene Metriken bereitstellen, mit denen bestimmt wird, wie lange eine Organisation den fehlenden Zugriff auf die Engine ihres Geschäfts ertragen und wie viele Daten sie bei einem Notfall vertretbar verlieren kann. Diese bestimmten Ziele (RPO, RTO und Aufbewahrung) werden in der nächsten Lerneinheit zur Notfallwiederherstellung behandelt.

Die Art der Wiederherstellung, mit der sich Azure Backup (im Gegensatz zu Azure Site Recovery, dem Notfallwiederherstellungsdienst von Microsoft) beschäftigt, fokussiert sich vollständig auf die Datenreplikation statt auf die Dienstwiederherstellung. Ein Kunde kann Azure Backup beispielsweise dazu verwenden, Replikate von Imagedateien virtueller Computer (VHD) zu erstellen. Jedoch wird bei der Wiederherstellung einer VHD einfach die archivierte Imagedatei im lokalen Speicher noch mal erstellt und nicht der virtuelle Server basierend auf dieser VHD neu gestartet.

Kosten für Azure Backup fallen nur für den verwendeten Speicherplatz pro Monat an, wobei keine zusätzlichen Kosten für Wiederherstellungen berechnet werden. Das Preismodell für den Speicher ist mit den Redundanzoptionen verknüpft. Derzeit bietet Azure zwei solcher Optionen an: Lokal redundanter Speicher (LRS) ist die günstigste Option und repliziert Daten dreimal innerhalb eines Azure-Rechenzentrums. Der georedundante Speicher (GRS) repliziert Daten in einer sekundären Region, die geografisch weit von der primären Region entfernt liegt.

Google Cloud Storage-Sicherung

Google bietet eine Vielzahl von Cloud Storage-Ebenen basierend auf der Klasse von Daten, die gespeichert werden, darunter beispielsweise dauerhaft verfügbare Dateien, Blockspeicher für Images virtueller Computer oder Objektspeicher für Videos. Es wird nicht explizit ein eigener Sicherungsdienst für diese Ebenen verkauft, obwohl die Speicherdienste durchaus für Sicherungen und Wiederherstellungen verwendet werden können und auch verwendet werden. Google geht zudem davon aus, dass Sicherungen zu den Hauptgründen zählen, aus denen ein Unternehmen in einen großvolumigen Cloudspeicher investieren würde.

Abbildung 4: Inhalt eines Google Cloud Storage-Bucket [Mit Genehmigung von Google]

Wie AWS bezeichnet auch Google seine universellen Speichercontainer als Bucket. Abbildung 4 zeigt einen Schritt beim Importieren von Daten aus lokalem Speicher in einen Google Cloud Storage-Bucket (GCS). Ähnlich wie Azure sein Bereitstellungsmodell auf drei Hauptparameter stützt, verwendet GCS die folgenden Hauptparameter:

• Leistung: in diesem Kontext synonym zur Verfügbarkeit (wie schnell Server auf Kundenanforderungen zum Lesen von Daten reagieren)

• Aufbewahrung: bezieht sich darauf, wie lange der Kunde erwartet, seine Daten in der Cloud zu speichern

• Zugriffsmuster: bezieht sich auf die Zugriffsmöglichkeit (wie oft der Kunde erwartet, die gespeicherten Daten zu lesen oder abzurufen)

Beim Initialisieren eines Bucket wählt der Kunde seine Speicherklasse aus, die seine Replikationsrichtlinie bestimmt. Durch diese Auswahl wird festgelegt, wie weit die gespeicherten Daten verteilt werden, sobald der Bucket für Sicherungen verwendet wird. GCS bietet derzeit drei Geolocationoptionen:

• Regional: nur in einer ausgewählten Region des Dienstgebiets von Google gespeichert

• Doppelregional: über zwei ausgewählte Dienstgebiete repliziert

• Multiregional: redundant über mehrere Dienstgebiete verteilt

Anschließend unterteilt GCS seine Bucketspeicherklassen basierend darauf, wie häufig auf sie zugegriffen wird:

• Standard/Hochverfügbarkeit: Daten, die sofort für Anwendungen und Benutzer zugänglich sein sollen

• Coldline: ermöglicht dem Kunden das Eintauschen von Teilen der monatlichen Speichergebühr für Zugriffs- und Übertragungsgebühren, und zwar für Daten, auf die nur ein paar Mal im Jahr zugegriffen werden soll

• Nearline: die mittlere Option, für Daten, auf die etwa einmal pro Monat zugegriffen werden soll

Google vermarktet seine Cloudinfrastruktur bei Unternehmen durch die Darstellung deren Dienste als eine Art unsichtbare Appliance. In dieser Hinsicht ist es für Google möglicherweise doppelter Aufwand, die Appliance an sich und deren Verwendungsweise als getrennte Dienste anzubieten, so als würde man einen Ofen und anschließend ein Kochabonnement als Mehrwert verkaufen.

Auf diese Weise wählt die GCS-Kundenorganisation die für die geplanten Aufträge erforderliche Infrastruktur aus und passt die Einstellungen dieser Infrastruktur wie die Features einer Appliance an. (Wie AWS und Azure bietet auch Google eine Einbau-Appliance für Rechenzentren für die eilige Hochgeschwindigkeitsübertragung zwischen lokalem und Cloudspeicher an.) Diese Features werden mit der Zeit dann möglicherweise optimiert, je nachdem, wie sich die Verwendung dieses Speichers ändert. Gehen wir beispielsweise davon aus, dass ein Videoproduktionsunternehmen eine große Menge an Sicherungsspeicher für Versionen eines Films benötigt, der sich in Bearbeitung befindet. Während der Bearbeitung werden diese Kopien möglicherweise relativ oft abgerufen, sodass der Kunde für den Bucket die Standardoption zum Speichern in nur regionalem Gebiet ausgewählt hat. Wenn das Video fertig ist und veröffentlicht wurde, kann es möglicherweise dennoch erforderlich sein, Kopien ein weiteres Jahr lang aufzubewahren, auch wenn möglicherweise nicht oft darauf zugegriffen wird. In diesem Fall kann der Standard-Bucket für Archiv- und Sicherheitszwecke in einen Coldline-Bucket mit doppelregionalem Gebiet verschoben werden.

Literatur

1. Amazon Web Services, Inc. Traffic management with AWS Global Acceleratorhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/ (Datenverkehrsverwaltung mit AWS Global Accelerator).

2. Amazon Web Services, Inc. Overview of Setting Up Replicationhttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html (Übersicht über die Replikationseinrichtung).