Gajus - Fotolia

F

Ein AWS Disaster Recovery für optimierte Performance einrichten

Wer geschäftskritische Anwendungen in der Cloud betreibt, muss diese entsprechend konfigurieren, damit kein Performance-Verlust entsteht.

Dieser Artikel behandelt

Public Cloud

ÄHNLICHE THEMEN

Unser Unternehmen betreibt geschäftskritische und weniger wichtige Workloads in Amazon Web Services. Wie können wir Regionen und Verfügbarkeitszonen konfigurieren, um Latenzen zu minimieren und die Applikations-Performance aufrecht zu erhalten?

Ein Ansatz für AWS Disaster Recovery und Business Continuity ist, redundante Anwendungskonfigurationen über verschiedene Verfügbarkeitszonen hinweg zu konfigurieren. Diese Zonen befinden sich oft in unterschiedlichen geografischen Regionen.

Für ein AWS DR kann ein Unternehmen eine Aktiv-Aktiv-Workload-Konfiguration mit Services wie Amazone Route 53 DNS einrichten. Dieser Service leitet einen Teil des Traffics an die duplizierten Implementierungen, die simultan arbeiten und sich die zu verarbeitenden Workloads teilen. Das Prinzip ähnelt dem Konzept eines lokalen Rechenzentrums, das zusätzlich AWS nutzt.

Benötigt eine geschäftskritische Anwendung beispielsweise einen Applikationsserver und einen Datenbankserver, so kann der IT-Administrator duplizierte Installationen in zwei verschiedenen Verfügbarkeitszonen (Availability Zone, AZ) einrichten, üblicherweise in verschiedenen Regionen. Amazon 53 DNS kann den Traffic an beide Instanzen der Cloud-Applikation senden, die in verschiedenen Regionen oder AZs vorgehalten werden. Der Traffic wird gleichmäßig zwischen den Regionen verteilt, in der Annahme, dass beide Installationen identisch sind. Allerdings kann die Aufteilung auch anders erfolgen, zum Beispiel, wenn sich der zweite AWS-Standort in einer anderen geografischen Region befindet oder größere Latenzen ein Problem werden.

Der Traffic, der an jede AWS-Instanz gesendet wird, durchläuft einen Load Balancer und einen Proxy-Server und dann über einen Applikations-Server, der mit einem Datenbankserver interagiert. Beide Standorte teilen sich während der normalen Produktion eine gemeinsame Datenbank, wobei die duplizierte Datenbank stets synchronisiert wird: eine Master-Slave-Datenbankbeziehung.

Kommt es zu einem Ausfall in einer Region oder einer Verfügbarkeitszone, dann übernimmt die redundante Workload-Instanz. AWS Auto Scaling erweitert typischerweise die Compute-Ressourcen der verbleibenden Instanz, damit diese die gesamte Workload verarbeiten kann. Ist die Störung der ersten Instanz wieder aufgehoben, werden alle Daten re-synchronisiert und der Traffic kann wieder über beide Instanzen laufen. Auto Scaling reduziert die Rechnerkapazitäten der zweiten Instanz wieder zum ursprünglichen Maß, so dass die Kosten niedrig bleiben.

Daten zwischen Applikationen in AWS replizieren

Wenn der DR-Plan vorsieht, Applikationen an mehreren Standorten aktiv zu betreiben – für die bessere Verfügbarkeit –, so spielt die Integrität der Datenquelle eine große Rolle. In einfachen Backup-Szenarien kann eine Datenquelle an ein anderes lokales Volume oder eine Cloud repliziert werden. Wenn multiple Standorte sich Daten und Datenverarbeitung teilen, kann das zu Problemen führen. Ein AWS DR kann eine Multi-Standort-Strategie umfassen, die lokale und Public-Cloud-Redundanzen ebenso nutzt wie die Duplizierung von Installationen über mehrere AZs und Regionen. Unterschiedlicher Traffic, der an unterschiedliche Anwendungsinstanzen geleitet wird, führt zu unterschiedlichen Datensätzen im Storage oder in der Datenbank. Fällt dann ein Standort aus und der gesamte Traffic wird an den alternativen Standort geroutet, dann führen die Unterschiede der Datensätze zu ernsthaften Fehlern und Störungen.

Um die Daten zwischen redundanten Anwendungsstandorten in Echtzeit zu synchronisieren, muss der Anwender einen der Data Stores oder Datenbanken als primär definieren. Beide Seiten benutzen dann diese primäre Datenquelle. Änderungen in dieser Datenquelle werden an die sekundäre Datenquelle am redundanten Standort gespiegelt. Das funktioniert gut mit AWS, da hier die Elastic-Compute-Cloud-Instanzen Daten einfach replizieren können. Fällt ein Standort aus, verlässt sich der redundante Standort auf die aktuelle Version der Datenbank oder des Storage.

Bei der Wahl der Verfügbarkeitszonen und Regionen ist es wichtig, an Latenzen und Anwendungs-Performance sowie die AWS-DR-Anforderungen zu denken. Durch eine Migration der Anwendungen über Verfügbarkeitszonen und Regionen hinweg erreicht man sowohl hohe Verfügbarkeit als auch Performance.

Wählt der Anwender verschiedene Verfügbarkeitszonen innerhalb einer Region, so gewährleistet dies geringe Latenzen und schnelle Synchronisationszeiten. Allerdings ist die Workload dann anfällig für Störungen oder Ausfälle, von denen andere Applikationen in anderen Regionen betroffen sind. Verfügbarkeitszonen, die in verschiedenen Regionen liegen, minimieren diese geografische Schwachstelle, allerdings können hier höhere Latenzen und eine geringere Performance die Folge sein.

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

Artikel wurde zuletzt im April 2016 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Public Cloud

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