F

Wie sich mit AWS-DR Performance-Verlust vermeiden lässt

Stephen Bigelow erklärt, wie Anwender verschiedene Workloads in AWS operieren können, ohne Performance-Verlust oder hohe Latenzen fürchten zu müssen.

Dieser Artikel behandelt

Public Cloud

ÄHNLICHE THEMEN

Unser Unternehmen lässt verschiedene unternehmenskritische, aber auch unkritische Workloads in Amazon Web Services...

laufen. Wie können wir Regionen und Verfügbarkeitszonen einrichten, um Latenzen zu minimieren und die Anwendungs-Performance zu gewährleisten?

Eine Option, AWS-Disaster-Recovery und -Business-Continuity zu garantieren, ist die Implementierung redundanter Anwendungskonfigurationen über multiple Verfügbarkeitszonen hinweg. Diese Zonen befinden sich oft in verschiedenen geografischen Regionen.

Für ein AWS-DR kann das Unternehmen eine Aktiv-Aktiv-Workload-Konfiguration einrichten. Dafür lässt sich der Service Amazon Route 53 DNS nutzen. Dieser Service leitet einen Teil des Traffics an die duplizierten Implementierungen, die simultan operieren, um die Workloads zusammen zu verarbeiten. Das ist ein ähnliches Prinzip, als würde das Unternehmen ein lokales Rechenzentrum und AWS nutzen.

Eine geschäftskritische Workload wird beispielsweise einen Applikationsserver und einen Datenbankserver benötigen. IT-Administratoren können duplizierte Installationen in zwei unterschiedlichen Verfügbarkeitszonen einrichten. Amazon Route 53 DNS sendet den Traffic an beide Instanzen dieser Cloud-Konfiguration. Der Traffic wird gleichmäßig auf diese Regionen/Zonen verteilt, in der Annahme, dass sie identisch konfiguriert sind. Allerdings kann die Aufteilung auch unterschiedlich sein, zum Beispiel wenn der zweite AWS-Standort in einer anderen geografischen Region liegt und höhere Latenzen drohen.

Der Traffic an beiden AWS-Instanzen durchläuft einen Load Balancer und einen Proxy-Server, danach wird er an den Applikationsserver gesendet, der wiederum mit dem Datenbankserver interagiert. Beide AWS-Seiten können eine gemeinsame Datenbank während der Produktion nutzen, wobei die redundante Datenbank stets synchronisiert wird. Hier liegt eine Master-Slave-Datenbank-Konfiguration vor.

Sollte eine Region oder Verfügbarkeitszone ausfallen, übernimmt die zweite Workload-Instanz. AWS Auto Scaling kann die Prozessorressourcen der verbleibenden Seite erweitern, damit diese den gesamten Workload-Traffic verarbeiten kann. Ist die Störung der ersten Instanz behoben, werden die Daten re-synchronisiert und der Traffic wird wieder an beide Seiten gesendet. Auto Scaling reduziert dann die Rechnerkapazität der zweiten Instanz, um die Kosten gering zu halten.

Replikation zwischen Applikationen in AWS

Sieht der DR-Plan vor, dass die gleiche Anwendung aktiv an mehreren Standorten läuft, so spielt die Integrität multipler Datenquellen eine große Rolle. Bei einem einfachen Backup wird eine Datenquelle an ein anderes lokales Volume oder an eine Cloud repliziert. Probleme entstehen, wenn mehrere Standorte sich die Datenverarbeitung teilen. Für AWS-DR kann das bedeuten, eine Multi-Standort-Strategie zu erstellen, die lokale und Public-Cloud-Redundanzen ebenso umfasst wie das Duplizieren von Implementierungen über mehrere Verfügbarkeitszonen und Regionen hinweg. Wird unterschiedlicher Traffic an verschiedene Anwendungsinstanzen gesendet, so führt dies zu unterschiedlichen Daten im Data Store oder der Datenbank. Kommt es zu einem Ausfall und der Traffic wird an einen alternativen Standort gesendet, so können die Datenunterschiede zu ernstzunehmenden Fehlern und Störungen führen.

Um die Daten zwischen den redundanten Standorten in Echtzeit zu synchronisieren, sollte ein redundanter Data Store oder eine Datenbank als „primär“ angelegt werden, den/die beide AWS-Standorte dann als primäre Datenquelle nutzen. Änderungen am primären Data Store werden dann an die sekundäre Datenquelle am zweiten Standort gespiegelt. Das funktioniert gut in AWS, wo die Instanzen der Elastic Compute Cloud einfach Daten replizieren können. Fällt dann eine Seite aus, so kann sich der zweite Standort auf eine aktuelle Version der Datenbank verlassen.

Es ist wichtig, die Verfügbarkeitszonen und Regionen so auszuwählen, dass sie Latenz- und Performance-Ansprüchen, aber auch AWS-DR-Anforderungen entsprechen. Anwendungsmigrationen zwischen Verfügbarkeitszonen und Regionen kann sowohl Verfügbarkeits- als auch Performance-Erwartungen bedienen.

Wählt ein Unternehmen verschiedene Verfügbarkeitszonen in der gleichen Region, so sind die Latenzen gering und die Datensynchronisation erfolgt zügig. Diese Strategie macht Workloads aber anfällig für Störungen in anderen Regionen. Wählt die Firma Verfügbarkeitszonen in verschiedenen Regionen, so ist sie gegen die meisten geografischen Risiken abgesichert, erhöht damit aber die Latenz und beeinflusst eventuell die Performance der Anwendung.

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

Artikel wurde zuletzt im Februar 2016 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Public Cloud

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close