Cloud-Speichertipp: Amazon FSx for Windows File Server in unterschiedlichen AWS-Regionen, Teil 1 Eine Kopie fürs Disaster Recovery
Anbieter zum Thema
In unserem zweiteiligen Praxisratgeber zeigen wir Ihnen, wie Sie in fünf Schritten Amazon-FSx-for-Windows-File-Server-Daten über verschiedene AWS-Regionen replizieren. Teil eins beschäftigt sich mit der Frage, wie Sie Amazon FSx for Windows File Server in zwei Regionen aufsetzen.

Viele Kunden, die besondere gesetzliche Compliance-Anforderungen erfüllen müssen oder sehr hohe Ansprüche an ihr betriebliches Kontinuitätsmanagement stellen, wollen Daten auf dem Amazon FSx for Windows File Server (Amazon FSx) in eine anderen AWS-Region (Amazon Web Services) replizieren. Sowohl die Infrastruktur einer AWS-Region als auch Amazon FSx sorgen bereits auf verschiedenen Ebenen für Resilienz. Eine Replikation kann aber eine zusätzliche Sicherheit für die Kundendaten bieten, auch für den – wenn auch höchst unwahrscheinlichen – Ausfall einer ganzen AWS-Region im Katastrophenfall.
Insgesamt existieren aktuell 24 AWS-Regionen weltweit, die jeweils aus mehreren Availability Zones (AZ) bestehen. Eine solche Availability Zone kann mehrere Rechenzentren mit Hunderttausenden von Servern umfassen.
Dieser Beitrag widmet sich der Frage, wie eine Architektur zur Replikation der Daten von Amazon FSx für Windows File Server zwischen verschiedenen AWS-Regionen aufgesetzt werden sollte. Hier kommt der Dienst AWS DataSync zum Einsatz. Im folgenden Beispiel wird ein häufig genutztes Szenario beschrieben, in dem Kunden die Systeme für den US-amerikanischen Markt betreiben: Es soll eine Amazon-FSx-Infrastruktur an der Ostküste der Vereinigten Staaten (North Virginia) und für das Disaster Recovery (DR) eine Kopie an der Westküste (Oregon) bereitgestellt werden.
Dieser Prozess gliedert sich in fünf Schritte:
- Schritt 1: Aufsetzen von Amazon FSx for Windows File Server in der ursprünglichen AWS-Region – der Quellregion.
- Schritt 2: Einrichten der Kommunikation zwischen den AWS-Regionen.
- Schritt 3: Aufsetzen von Amazon FSx for Windows File Server in der zweiten AWS-Region. Sie fungiert als Disaster-Recovery-Region (DR).
- Schritt 4: Aufsetzen eines AWS-DataSync-Agenten in der Nähe der Quelldaten.
- Schritt 5: Konfigurieren des AWS-DataSync-Dienstes, um Daten von der Quellregion in die DR-Region zu replizieren.
In dem hier vorliegenden ersten Teil unseres Artikels erfahren Sie, wie Sie Amazon FSx for Windows File Server in den beiden Regionen aufsetzen. Ein zweiter Teil beschreibt, wie Sie den AWS-DataSync-Agenten einrichten und die Replikation konfigurieren.
Eine Übersicht über die aufzubauende Architektur und über die fünf Schritte bietet das nebenstehende Diagramm.
Eine detaillierte Schritt-für-Schritt-Anleitung befindet sich hier. Amazon FSx for Windows File Server bietet mehrere Funktionen, um die hohe Verfügbarkeit von Informationen zu sichern. Weitere Details dazu enthält diese Dokumentation.
Schritt 1: Aufsetzen von Amazon FSx for Windows File Server in der Quellregion
Zunächst sollte ein Amazon-FSx-for-Windows-File-Server-Dateisystem als Speicherort der Daten angelegt werden, falls dies noch nicht erfolgt ist. Diesen Speicherort kann man an ein vorhandenes Active Directory anbinden. Für die Verwaltung der Zugriffsrechte nutzen Sie dann die Nutzer- und Gruppenprofile aus dem bestehenden Active Directory. Details zum Aufsetzen eines solches Systems finden sich in dieser Anleitung oder in folgendem Video:
In diesem Beispiel nehmen wir ein Amazon-FSx-Dateisystem, welches sich über verschiedene AWS Availability Zones (Multi-AZ) in der North-Virginia-Region erstreckt – bei einer Kapazität von 32 GiB und einem Datendurchsatz von 16 Mbps. Beim Anlegen des Dateisystems sind folgende Parameter verfügbar:
- Die Art der Einrichtung (Deployment Type): Single-AZ oder Multi-AZ. Eine Multi-AZ-Architektur empfehlen wir vor allem dann, wenn die Daten bei einem Ausfall in einer Availability Zone (AZ) oder auch während eines Wartungsfensters für Amazon FSx verfügbar bleiben müssen. Die Multi-AZ-Architektur veranlasst Amazon FSx zu einer Block-Level-Replikation der Daten von einer Availability Zone zu einer zweiten. Während Wartungsarbeiten an Amazon FSx erfolgt zuerst ein Failover in die zweite AZ, dann werden die Wartungsarbeiten in der ursprünglichen AZ durchgeführt. Im Anschluss wird entsprechend umgeschaltet und das FSx-Dateisystem in der zweiten AZ wird gewartet.
- Die Art des Speichers (Storage Type): SSD oder HDD.
- Die Speicherkapazität (Storage Capacity).
- Die Datendurchsatzrate (Throughput Capacity). Der Dienst schlägt eine Datendurchsatzrate vor, die sich an der gewählten Speicherkapazität orientiert. Dieser Wert kann allerdings an die spezifischen Anforderungen Ihrer Anwendung angepasst werden.
- Den Windows Authentication Mode: AWS Managed Microsoft Active Directory oder Self-managed Microsoft Active Directory. Der Modus „Self-managed Microsoft Active Directory“ bietet sich an, wenn Sie eine vorhandene Active-Directory-Instanz in einem Ihrer Rechenzentren anbinden wollen oder ein von Ihnen selbst betriebenes Active Directory in der Cloud vorhanden ist. Wählen Sie die Einstellung „AWS Managed Microsoft Active Directory“ für den Fall, dass Sie den AWS-Dienst „AWS Managed Microsoft AD“ nutzen und Amazon FSx for Windows mit diesem Verzeichnis verbinden wollen.
Schritt 2: Einrichten der Kommunikation zwischen den AWS-Regionen
Um die Quellregion mit der AWS-Region, in der das Disaster Recovery stattfinden soll, zu verbinden, ist zuerst die Einrichtung einer Netzwerkverbindung nötig. Anschließend müssen die AWS-Sicherheitsgruppen modifiziert werden, um die Kommunikation über diese Verbindung zu erlauben.
Für diese regionenübergreifende Verbindung gibt es zwei Möglichkeiten: Virtual Private Cloud (VPC) Peering oder AWS Transit Gateway. Das VPC Peering eignet sich vor allem dann, wenn nur wenige AWS-Netzwerke zu verbinden sind. Wenn Sie mehrere AWS-Netzwerke (oder VPCs) verknüpfen oder falls Sie außerdem mehrere eigene Netzwerke und Standorte einbinden wollen, dann empfiehlt sich das AWS Transit Gateway.
In diesem Beispiel wird VPC Peering verwendet, weil nur die zwei VPCs – in der Quellregion und in der DR-Region – zu verbinden sind. Eine genaue Beschreibung, wie Sie dabei vorgehen, finden Sie in der AWS-Dokumentation.
Jeder Amazon FSx for Windows File Server hat eine zugeordnete „Sicherheitsgruppe“ (Security Group), die bestimmt, welche Hosts (IP-Adressen) auf den Server zugreifen können. Deswegen muss der Sicherheitsgruppe, die den Amazon FSx for Windows File Server abschirmt, der IP-Adressbereich der DR-Region bekanntgegeben werden. Ebenso ist es notwendig, dass das Amazon-FSx-Dateisystem in der DR-Region ebenfalls den IP-Adressbereich der Quellregion zum Datenaustausch zulässt.
Schritt 3: Aufsetzen des Amazon-FSx-for-Windows-File-Server-Dateisystems in der DR-Region
Dies erfolgt auf die gleiche Weise wie das Anlegen des Dateisystems in der Quellregion. Wenn Sie die verwenden, müssen Sie zuerst die aktive AWS-Region wechseln: Wählen Sie die Region, in welcher das Amazon-FSx-Dateisystem für die Datenwiederherstellung erzeugt werden soll – und zwar bevor Sie das Amazon-FSx-Dateisystem anlegen.
Nun wird das Dateisystem mit dem gleichen Active Directory verbunden wie das Quellsystem. Dann sind auch die Zugriffsrechte für die Dateien identisch, und Anwender können auch im DR-Fall weiterhin auf die gleichen Daten zugreifen.
Für das Dateisystem in der DR-Region können Sie die gleichen Spezifikationen wählen wie für das Quellsystem. Je nach Anforderung lassen sich diese auch anpassen. Die gewählten Faktoren – Multi/Single-AZ, Speicherart, Speicherkapazität und Durchsatz – bestimmen die Kosten für den Betrieb von Amazon FSx. Auf jeden Fall sollten die Speicherkapazitäten der Dateisysteme in der Quell- und in der DR-Region gleich groß sein, damit das DR-Dateisystem genug Platz für die Daten aus dem Quellsystem hat.
Der zweite Teil des Beitrags handelt vom Aufsetzen eines AWS-DataSync-Agenten in Nähe zu den Quelldaten sowie von der Konfiguration des AWS-DataSync-Dienstes, um Daten von der Quellregion in die DR-Region zu replizieren.
*Der Autor: Michael Hanisch, Head of Technology bei AWS in Deutschland
(ID:47124204)