AWS-Verfügbarkeitszonen, -Regionen und -Platzierungsgruppen erklärt

Unternehmen nutzen Anwendungen, die unterschiedliche Verfügbarkeitsstufen und verschiedene SLA-Ziele erfordern. Wie kritisch oder anspruchsvoll eine Anwendung betrachtet wird, steht im Verhältnis zu ihren Anforderungen an Durchsatz, Reaktionsfähigkeit und Wiederherstellungszeit im Falle eines Ausfalls. Die gleichen Überlegungen gelten auch bei der Entwicklung von AWS-Hochverfügbarkeits-Best Practices.

Abhängig von den spezifischen Anforderungen der Bereitstellung ist die Verteilung von Rechenleistung und Speicher über AWS Availability Zones in Kombination mit Placement Groups eine Möglichkeit, diese Herausforderung in der AWS-Hochverfügbarkeit zu adressieren. Eine optimierte Kombination dieser Optionen zusammen mit einer Cloud Volumes ONTAP HA-Bereitstellung kann die Anforderungen jeder Ebene erfüllen.

In diesem Artikel werden wir diese AWS-Hochverfügbarkeits-Best-Practices sowie Anwendungsfälle für einzelne und mehrere Availability Zones und Placement Groups betrachten. Wir betrachten außerdem die zusätzlichen Vorteile, die Cloud Volumes ONTAP HA als Lösung auf der Speicherebene bieten kann.

In diesem Artikel erfahren Sie:

• Was sind AWS-Regionen und Availability Zones?
• Parameter, die bei der Auswahl einer AWS-Region zu berücksichtigen sind
• Was ist eine Multi-AZ-Bereitstellung?
• AWS Placement Groups
  • Cluster Placement Groups
  • Partition Placement Groups
  • Spread Placement Groups
• Cloud Volumes ONTAP HA für AWS

Was sind AWS-Regionen und Availability Zones?

Availability Zones sind hochverfügbare Rechenzentren innerhalb jeder AWS-Region. Eine Region stellt ein separates geografisches Gebiet dar. Jede Availability Zone verfügt über unabhängige Stromversorgung, Kühlung und Netzwerkanbindung. Fällt eine gesamte Availability Zone aus, kann AWS Workloads auf eine der anderen Zonen in derselben Region umschalten – eine Fähigkeit, die als „Multi-AZ“-Redundanz bekannt ist.

Jede AWS-Region ist isoliert und arbeitet unabhängig von anderen Regionen, aber die Availability Zones innerhalb einer Region sind über Verbindungen mit niedriger Latenz miteinander verbunden, um Replikation und Fehlertoleranz zu ermöglichen. Wenn Sie alle Ihre Daten und Instanzen in einer einzigen Availability Zone hosten, die von einem Ausfall betroffen ist, sind diese nicht verfügbar.

Der Zweck dieser Isolation ist es, Workloads mit hoher Datenhoheit und Compliance-Anforderungen zu bedienen, die es nicht erlauben, dass Benutzerdaten eine bestimmte geografische Region verlassen. Solche Workloads profitieren von der Struktur der AWS Availability Zones mit niedriger Latenz und vollständiger Trennung von anderen Regionen.

Siehe eine vollständige Liste der verfügbaren Regionen innerhalb der globalen AWS-Infrastruktur.

AWS-Regionen vs. Availability Zones

Es gibt zwei wesentliche betriebliche Unterschiede zwischen dem Betrieb Ihrer Workloads in verschiedenen Regionen und in verschiedenen Availability Zones innerhalb derselben Region.

Geografische Verteilung

Die geografische Verteilung der AWS-Regionen und Availability Zones spielt auch eine bedeutende Rolle für die Performance und Zuverlässigkeit Ihrer Anwendungen.

Wenn Sie Ihre Anwendung über mehrere Availability Zones in einer Region bereitstellen, erreichen Sie ein gewisses Maß an Hochverfügbarkeit und Fehlertoleranz, aber weniger als bei der Bereitstellung in verschiedenen Regionen. Fällt eine Availability Zone aus, kann Ihre Anwendung in einer anderen Availability Zone ohne Unterbrechung weiterlaufen. Fällt jedoch die gesamte Region aus, fällt auch Ihre Anwendung aus.

Andererseits bedeutet die Bereitstellung Ihrer Anwendung in mehreren Regionen, dass selbst wenn eine gesamte Region ausfällt (ein sehr unwahrscheinliches Szenario), Ihre Anwendung weiterhin funktioniert. Die Bereitstellung über Regionen hinweg bietet zusätzliche Vorteile wie geringere Latenz für Ihre globalen Nutzer und eine schnellere Notfallwiederherstellung.

Rechen- und Datentransferkosten

Wenn es um Kosten geht, kann der Standort Ihrer AWS-Ressourcen einen erheblichen Einfluss haben. Jede AWS-Region hat unterschiedliche Preise für Services, abhängig von Faktoren wie lokaler Nachfrage, Infrastrukturkosten und lokalen Steuergesetzen. Beispielsweise kostet der Betrieb einer EC2-Instanz in der Region Asien-Pazifik (Mumbai) wahrscheinlich mehr als der Betrieb derselben Instanz in der Region US East (N. Virginia). Die Kosten für den Betrieb von Workloads über verschiedene AZs in derselben Region sind jedoch in der Regel gleich.

Auch die Kosten für den Datentransfer können variieren, je nachdem, ob die Daten innerhalb derselben Region, zwischen verschiedenen Regionen oder zwischen Regionen und dem öffentlichen Internet übertragen werden. Der Datentransfer innerhalb derselben Region oder zwischen Availability Zones in derselben Region ist in der Regel günstiger als der Transfer zwischen Regionen oder ins öffentliche Internet.

Parameter, die bei der Auswahl einer AWS-Region zu berücksichtigen sind

Einige Parameter sind entscheidend, bevor Sie eine AWS-Region und AZ für das Hosting und die Bereitstellung Ihrer Anwendung auswählen, um die besten Ergebnisse zu erzielen.

Die folgende Liste enthält die wichtigsten Parameter, die zu berücksichtigen sind:

Parameter #1: Latenz und Nähe– wählen Sie die nächstgelegene Region für niedrige Latenz.
Eine schnelle Verbindung zum Server sorgt für bessere Performance in Bezug auf schnelle Lade- und Übertragungszeiten, was insgesamt zu einer besseren Nutzererfahrung führt. Dies erreichen Sie, indem Sie eine AWS-Region wählen, die der Mehrheit Ihrer Kunden am nächsten liegt. Je kürzer die Entfernung zwischen Cloud und Endnutzer, desto geringer die Latenz. Wenn beispielsweise die meisten Ihrer Kunden innerhalb der nordamerikanischen Region auf Ihre Anwendung zugreifen, erzielen Sie mit einer Availability Zone innerhalb der Regionen der USA oder Kanadas die besten Ergebnisse.

Die Preise für AWS-Services variieren je nach Region, basierend auf Faktoren wie den Kosten für physische Infrastruktur und Steuern. Die Unterschiede zwischen den Regionen können mehrere hundert Dollar betragen, daher ist die Wahl der richtigen Region entscheidend, um unnötige Kosten zu vermeiden. Sie können den offiziellen Preisrechner verwenden, um zu sehen, welche Region am besten zu Ihren Anforderungen passt. Sehen Sie sich auch NetApps AWS Calculator an, mit dem Sie die TCO einschließlich der Kosten für Speicherdienste berechnen können.

Parameter #2: Kosten– wählen Sie eine Region, die das beste Preis-Leistungs-Verhältnis bietet.

Nachfolgend finden Sie eine Referenztabelle, die die verschiedenen Preise für jede Region für einen 1-TB-Datentransfer zeigt.

Parameter #3: Regulatorische Compliance und Sicherheit – Schutz von Unternehmenswerten

Jedes Land oder jede Union hat unterschiedliche Compliance-Normen und Regeln zum Schutz von Nutzerdaten. Einige Regionen verbieten möglicherweise den Transfer zwischen ihrer Region und anderen Regionen. Ein Verstoß gegen solche Compliance-Vorschriften kann zu Klagen führen und Ihrem Unternehmen erheblichen finanziellen und Reputationsschaden zufügen. Wenn Sie weltweit Dienstleistungen anbieten, sollten Sie außerdem die Nutzung mehrerer AWS-Regionen und Availability Zones in Betracht ziehen, um Ihren Kunden den schnellsten und zuverlässigsten Service zu bieten.

Parameter #4: Service Level Agreements (SLA)– richtige Parameter für besseren Service.

AWS-Services bieten unterschiedliche SLAs, basierend auf ihrer jeweiligen Verfügbarkeit und Parametern. AWS hält SLAs am besten ein, wenn Sie die Anwendung gemäß AWS-Design bereitstellen. Berücksichtigen Sie bei der Auswahl einer Region und einer AZ alle anderen Parameter zusammen mit Ihren Anforderungen, um sicherzustellen, dass sie die beste Lösung für das Hosting und die Bereitstellung Ihrer Anwendung bieten.

Was ist eine Multi-AZ-Bereitstellung?

Bei geschäftskritischen Workloads wie Unternehmensdatenbanken – unabhängig davon, ob sie auf Amazon EC2-Instanzen oder auf Amazon nativen Datenbankdiensten (wie Amazon RDS) gehostet werden – bietet ein Multi-AZ-Verteilungsmodell hohe Verfügbarkeit, falls in einer gesamten Availability Zone ein schwerwiegender Ausfall auftritt.

Kritische Produktionsanwendungen, die sich nicht einmal moderate Ausfallzeiten leisten können, profitieren von diesem Modell und müssen diese Art von allgemeinem Ausfall als reale Möglichkeit betrachten. Das gilt auch für die oberen Tiers, aus denen diese Anwendung bestehen kann. Wenn die Webdienste einer App alle in einer AZ gehostet werden, bringt eine HA-Multi-AZ-Konfiguration der zugrunde liegenden Datenbanken wenig, wenn das Web-Tier nur in einer AZ gehostet wird.

Aus dieser Hochverfügbarkeits-Perspektive gilt: Bei einer Single-AZ-Bereitstellung, wenn die AZ ausfällt, fällt alles aus und das Recovery Time Objective steigt erheblich. Ganz zu schweigen von dem Datenverlust, der dazwischen auftritt.

Weitere wichtige Vorteile von Multi-AZ-Bereitstellungen sind:

• Keine I/O-Verzögerungen bei Backups, da Backups von der Standby-Instanz erstellt werden.
• Keine Unterbrechungen der I/O bei Patches oder Upgrades zu Wartungszwecken.
• Erhöhte Reaktionsfähigkeit, wenn Load Balancing verwendet wird. Wenn eine AZ ausgelastet ist, können die Instanzen in anderen Zonen den Traffic übernehmen.

Natürlich benötigen nicht alle Anwendungsfälle eine Multi-AZ-Bereitstellung. Temporäre Tests, Entwicklungsbereitstellungen oder nicht kritische Anwendungsfälle können in einer einzelnen AZ gehostet werden und vermeiden so die zusätzlichen Kosten, die mit einer Multi-AZ-Bereitstellung einhergehen. Es gibt sogar hochintensive, extrem mit niedriger Latenz arbeitende Anwendungsfälle, die besser zum Single-AZ-Modell passen.

AWS Placement Groups

Einfach ausgedrückt ist eine Placement Group eine Konfigurationsoption, die AWS anbietet, mit der Sie eine Gruppe voneinander abhängiger Instanzen gezielt auf der zugrunde liegenden Hardware platzieren können. Die Instanzen können eng beieinander, über verschiedene Racks oder über verschiedene Availability Zones verteilt platziert werden. Sehen wir uns die einzelnen Placement Group-Typen an, die Sie auswählen können, und die Workload-Typen, die am besten zu jeder Verteilungsoption passen:

1. Cluster Placement Groups

Die Cluster Placement Group-Konfiguration ermöglicht es Ihnen, Ihre Gruppe von zusammenhängenden Instanzen eng beieinander zu platzieren, um den bestmöglichen Durchsatz und niedrige Latenz zu erreichen. Diese Option erlaubt es nur, die Instanzen innerhalb derselben Availability Zone zusammenzufassen, entweder in derselben VPC oder zwischen verbundenen VPCs.

Der Vorteil von Cluster Placement Groups ist, dass die Kommunikation zwischen diesen Instanzen nicht auf einen Single-Flow-Traffic von 5 Gbit/s beschränkt ist, sondern 10 Gbit/s Single-Flow (Point-to-Point) Traffic und insgesamt 25 Gbit/s für aggregierten Traffic ermöglicht. HPC (High Performance Computing) netzwerkgebundene Anwendungen sind die besten Anwendungsfälle für dieses Bereitstellungsmodell. Computational Engineering, Live-Event-Streaming, Genomsequenzierung, Astronomiemodelle und Erdklima-Computermodelle sind Beispiele für Anwendungsfälle dieser Gruppierung in der Cloud.

2. Partition Placement Groups

Mit Partition Placement Groups können Sie Ihre Instanzen in separaten logischen Partitionen gruppieren, die die Placement Group bilden. Die Idee dahinter ist, dass jede der logischen Partitionen auf separaten Hardware-Racks aufgebaut ist, um gemeinsame Hardwareausfälle zu vermeiden. Fällt ein Rack aus, betrifft das nur die Instanzen, die auf dieser logischen Partition liegen. Jede logische Partition besteht aus mehreren Instanzen. Die Partition Placement Group-Option ermöglicht es, diese Partitionen innerhalb einer einzelnen AZ oder in einer Multi-AZ-Konfiguration innerhalb derselben Region zu platzieren.

Welche Workloads passen am besten zu diesem Modell? Große Datenspeicher, die verteilt und repliziert werden müssen, sind gute Beispiele. Große Dateisysteme wie HDFS oder Cassandra sind ebenfalls sehr gut geeignet. Partition Placement Groups ermöglichen es Ihnen, zu sehen, welche Instanzen in welchen Partitionen platziert sind, sodass Sie Hadoop- oder Cassandra-Topologien berücksichtigen und die Datenreplizierung korrekt konfigurieren können. Jeder Anwendungsfall, der Big Data-Analysen, Datenberichte oder groß angelegte Indizierung benötigt, ist ebenfalls gut für Partition Placement Groups geeignet.

3. Spread Placement Groups

Mit Spread Placement Groups läuft jede einzelne Instanz auf separaten physischen Hardware-Racks. Wenn Sie also fünf Instanzen bereitstellen und sie in diese Art von Placement Group legen, befindet sich jede dieser fünf Instanzen auf einem anderen Rack mit eigenem Netzwerkzugriff und eigener Stromversorgung, entweder innerhalb einer einzelnen AZ oder in einer Multi-AZ-Architektur.

Die Spread Placement Group-Konfiguration ähnelt Partition Placement Groups, aber der Hauptunterschied ist, dass Partition Placement Groups aus mehreren Instanzen pro Partition bestehen, während Spread Groups einzelne Instanzen sind, die über verschiedene Racks oder AZs verteilt sind.

Dieses Modell wird für eine kleine Anzahl geschäftskritischer Instanzen empfohlen. Sie könnten hier beispielsweise eine kleine Anzahl von SQL database-Instanzen oder Ihr Applikations-Tier betreiben. Diese Konfiguration ist ein idealer Anwendungsfall für Redundanz, da weniger Bedarf an der hohen Rechenleistung besteht, die Partition und Cluster Placement Groups bieten.

Cloud Volumes ONTAP HA für AWS

Die Cloud Volumes ONTAP HA-Konfiguration bietet AWS-Hochverfügbarkeit. Durch den Betrieb auf zwei Amazon EC2-Compute-Instanzen und die Speicherung aller Daten im zugrunde liegenden Amazon EBS storage kann der Betrieb jeden Datenverlust im Fehlerfall verhindern und sich in weniger als 60 Sekunden erholen.

In diesem Cloud Volumes ONTAP-Paar werden alle Daten zwischen den beiden Knoten gespiegelt, entweder in einer Aktiv/Aktiv-Konfiguration, bei der beide Knoten Clients bedienen, oder in einer Aktiv/Passiv-Konfiguration, bei der ein Knoten als Standby dient. In beiden Fällen werden die Daten bei jedem neuen Schreibvorgang synchron gespiegelt. Diese Konfiguration kann entweder in einem Single-AZ-Szenario oder in einem Multi-AZ-Szenario bereitgestellt werden:

• Single-AZ: Beide Cloud Volumes ONTAP-Knoten befinden sich in derselben Availability Zone. NetApp Cloud Manager stellt beide Knoten automatisch mit einer Spread Placement Group-Konfiguration bereit, um gemeinsame Compute-Ausfälle zu vermeiden.
• Multi-AZ: Jeder Cloud Volumes ONTAP-Knoten befindet sich in einer anderen Availability Zone, wodurch die AZ als Single Point of Failure eliminiert wird – eine Funktion, die die native Amazon EBS storage-Replikation nicht bietet. Mit dieser Art von Hochverfügbarkeitskonfiguration müssen Sie ein AWS Transit Gateway mit Floating-IP-Adressen einrichten, damit das Failover ordnungsgemäß funktioniert und permanenter NAS- oder sonstiger Datenzugriff bereitgestellt werden kann.

Cloud Volumes ONTAP HA benötigt drei Amazon EC2-Instanzen: zwei Hauptknoten, die alle Speicheraufgaben übernehmen, und eine kleine t2.micro-Mediator-Instanz, die für die Steuerung und Verwaltung der automatischen Failover- und Failback-Aufgaben zuständig ist. RPO (Recovery Point Objective) ist null, Ihre Daten sind immer konsistent, da sie synchron gespiegelt werden, und Ihr RTO (Recovery Time Objective) beträgt 60 Sekunden oder weniger, bis die Daten im Falle eines Failovers auf den anderen Knoten wieder verfügbar sind.

AWS bietet weitere native Redundanzfunktionen auf der Speicherebene wie Amazon EBS. Wie bereits erwähnt, repliziert Amazon EBS nur innerhalb von Servern in einer einzelnen Availability Zone. Wenn Sie Redundanz auf der Speicherebene ausschließlich mit Amazon EBS bereitstellen möchten, müssten Sie Amazon S3-Snapshots erstellen und diese in eine andere Availability Zone übertragen, was ebenfalls zusätzliche Kosten verursacht. Andere native AWS-Hochverfügbarkeitsfunktionen wie Amazon EFS exportieren die gespeicherten Daten nur über NFS und unterstützen derzeit keine Windows-Instanzen.

Fazit

Alle in diesem Artikel bereitgestellten Informationen zu AWS-Hochverfügbarkeits-Best-Practices führen zu drei Hauptschlussfolgerungen:

1. Wo immer eine Multi-AZ-Konfiguration vorhanden ist, wird ein zusätzlicher Zuverlässigkeitspunkt erreicht, da die gesamte Availability Zone selbst als Single Point of Failure ausgeschlossen wird.
2. Verschiedene Workloads haben unterschiedliche Anforderungen, die besser zu Single-AZ- oder Multi-AZ-Bereitstellungen passen.
3. Wann immer zentraler Speicher benötigt wird, ist Cloud Volumes ONTAP HA eine Lösung, die Redundanz und schnelle Wiederherstellung auf der Speicherebene bietet – unabhängig davon, ob Sie in einer Single-AZ- oder Multi-AZ-Variante bereitstellen. Dies zu einem niedrigeren oder vergleichbaren Preis im Vergleich zum Betrieb auf reinem Amazon EBS storage.

Ihre Geschäftskontinuität ist wichtig. Cloud Volumes ONTAP gibt Ihnen die Möglichkeit, diese sicherzustellen.