Hochverfügbarkeitsdesign für Ihre Workloads

{ IBM Cloud unterstützt hochverfügbare Anwendungsbereitstellungen innerhalb einer einzelnen Zone, über mehrere Zonen in einer Region mit mehreren Zonen und über mehrere Regionen hinweg.

Ausfalldomänen bestimmen den Grad des Schutzes vor Infrastrukturausfällen für jede Bereitstellungsoption. Eine Anwendungsinstanz, die in einer einzigen Zone bereitgestellt wird, ist nicht gegen einen Ausfall dieser Zone geschützt. Anwendungsinstanzen, die in mehreren Verfügbarkeitszonen eingesetzt werden, sind gegen den Ausfall einer einzelnen Zone geschützt. Die verschiedenen Verfügbarkeitszonen befinden sich im selben Ballungsraum und sind durch Netzwerkverbindungen mit geringer Latenz verbunden, die eine synchrone Replikation der Daten über die Zonen hinweg ermöglichen. Anwendungsinstanzen, die in mehreren Regionen eingesetzt werden, sind gegen den Ausfall einer gesamten Region geschützt. Die verschiedenen Regionen befinden sich in verschiedenen Ländern oder in verschiedenen Teilen eines Landes. Die Entfernung zwischen den Regionen erlaubt in der Regel nur eine asynchrone Replikation der Daten.

Die folgende Tabelle zeigt die Anwendungsbereitstellungsoptionen auf der Grundlage der in einer öffentlichen Cloud verfügbaren Fehlerdomänen.

Hochverfügbarkeitsoptionen und ihre jeweilige Verfügbarkeit, Fehlerdomäne sowie Kosten und Komplexität bei der Wartung.
Deployment	Verfügbarkeit	Bereich des Scheiterns	Kosten und Komplexität
Einzelzone, Einzelregion	Niedrig/Med	Virtueller Server / Physischer Host	Niedrig
Multi-Zone, Einzel-Region	Hoch	Zone	Mittel
Multi-Zone, multi-region	Sehr hoch	Bereich	Hoch

Einsatz in einer Zone

Bei der Einzelzonenbereitstellung werden mehrere Anwendungsinstanzen in einer Zone bereitgestellt. Wenn eine Anwendungsinstanz in einem einzelnen virtuellen Server ausgeführt wird, können diese virtuellen Server mit Hilfe von Platzierungsgruppen auf separaten physischen Hosts bereitgestellt werden. VPC Autoscale kann verwendet werden, um eine dynamische Kapazitätsanpassung auf der Grundlage von Änderungen der Arbeitslast zu ermöglichen. Die Bereitstellung in einer einzigen Zone bietet kostengünstige Lösungen mit einer Infrastrukturverfügbarkeit 99.9. Dieser Einsatz kann für nicht produktive Umgebungen oder nicht geschäftskritische Anwendungen geeignet sein. Die Bereitstellung in einer einzigen Zone bietet jedoch keinen Schutz vor Ausfällen in einer Zone.

Bei der Verwendung dieses Bereitstellungsmodells empfiehlt es sich, Ungleichgewichte zwischen den Zonen zu vermeiden. Ein Zonenungleichgewicht liegt vor, wenn die Kapazität – beispielsweise VPC Virtual Server Instances (VSIs) – nicht gleichmäßig auf die Zonen verteilt ist. Betrachten wir ein Beispiel, bei dem eine Workload mit 70 % ihrer VSI-Kapazität in Zone 1, 20 % in Zone 2 und 10 % in Zone 3 bereitgestellt wird. Sollte Zone 1 ausfallen, ist die Workload möglicherweise weiterhin verfügbar, jedoch nur mit 30 % ihrer Kapazität. Eine Lösung besteht darin, bei einem Ausfall in Zone 1 mehr Ressourcen bereitzustellen; allerdings kann der Ausfall zu einem ungewöhnlichen Anstieg des Kapazitätsbedarfs in den verbleibenden Zonen führen. Eine bessere Lösung besteht darin, das Ungleichgewicht zu beseitigen und sicherzustellen, dass die erforderliche Kapazität auf die Zonen verteilt wird, wobei in jeder Zone ein zusätzlicher Puffer von etwa 17 % vorgesehen wird, um den Ausfall einer einzelnen Zone auszugleichen. Dadurch wird sichergestellt, dass die Workload auch bei Ausfall einer Zone verfügbar bleibt und mit voller Kapazität weiterarbeiten kann.

Einsatz in mehreren Zonen und einer Region

Bei einer Bereitstellung mit mehreren Zonen und einer Region werden mehrere Anwendungsinstanzen in zwei oder mehr Verfügbarkeitszonen innerhalb der Region bereitgestellt. Bereitstellungen mit mehreren Verfügbarkeitszonen innerhalb einer Region können eine Infrastrukturverfügbarkeit von bis zu 99.99 % bieten, wenn die Anwendung über drei Verfügbarkeitszonen verteilt bereitgestellt wird. Diese Bereitstellung schützt die Anwendung vor Ausfällen in einzelnen Zonen und eignet sich für Unternehmens-Workloads im Produktionsbetrieb mit einer Verfügbarkeitsanforderung von > 99.9 %. Die tatsächliche Verfügbarkeit der Anwendung hängt vom Hochverfügbarkeitsdesign der Anwendung ab.

Vermeiden Sie bei der Verwendung dieses Bereitstellungsmodells Ungleichgewichte zwischen den Zonen. Ein Zonenungleichgewicht tritt auf, wenn Kapazitäten – beispielsweise IBM Cloud® Virtual Servers for Virtual Private Cloud (VSIs) – nicht gleichmäßig auf die Zonen verteilt sind. Betrachten wir ein Beispiel, bei dem eine Workload mit 70 % ihrer VSI-Kapazität in Zone 1, 20 % in Zone 2 und 10 % in Zone 3 bereitgestellt wird. Fällt Zone 1 aus, bleibt die Workload möglicherweise verfügbar, jedoch nur mit 30 % ihrer Kapazität. Sie könnten bei einem Ausfall zwar weitere Ressourcen bereitstellen, doch ein Ausfall kann zu einem ungewöhnlichen Anstieg des Kapazitätsbedarfs in den verbleibenden Zonen führen. Beseitigen Sie stattdessen das Ungleichgewicht, indem Sie die erforderliche Kapazität gleichmäßig auf die Zonen verteilen, wobei pro Zone ein zusätzlicher Puffer von etwa 17 % einkalkuliert wird, um den Ausfall einer einzelnen Zone auszugleichen. Dadurch wird sichergestellt, dass die Workload verfügbar bleibt und bei Ausfall einer Zone mit voller Kapazität weiterarbeiten kann.

Einsatz in mehreren Zonen und Regionen

Ein Einsatz in mehreren Zonen und Regionen bietet Schutz vor regionalen Ausfällen. Diese Bereitstellung wird für unternehmenskritische Anwendungen empfohlen, die eine kontinuierliche oder nahezu kontinuierliche Verfügbarkeit erfordern. Diese Bereitstellung unterstützt auch die Notfallwiederherstellung außerhalb der Region und die Geschäftskontinuität für Anwendungen mit geografischen oder spezifischen Entfernungsanforderungen.

Multi-Zone-Implementierungen beruhen auf anwendungsorientierter Datenreplikation über Verfügbarkeitszonen hinweg und unterstützen aktiv-aktive und aktiv-standby Architekturmuster. Bereitstellungen in mehreren Zonen und Regionen unterstützen Architekturmuster für Unternehmensanwendungen mit kontinuierlicher Verfügbarkeit und Always-on-Anforderungen. Die folgenden Tabellen zeigen einen Vergleich der verschiedenen Einsatzmöglichkeiten und der empfohlenen Verwendung.

Empfehlungen für den Einsatz von Hochverfügbarkeit
Deployment	Verfügbarkeit	Beschreibung	Empfohlene Verwendung
Einzelne Zone	99.9%	Mehrere Recheninstanzen in einer Zone Schutz vor Infrastrukturausfällen Niedrige/mittlere Kosten	Anwendungen mit niedriger bis mittlerer Priorität Unkritische Produktionsworkloads
Multi-Zone, einzelne Region	99.99%	Mehrere Recheninstanzen über 2 oder mehr Verfügbarkeitszonen Synchrone Datenreplikation über Zonen hinweg Schutz vor Zonenausfällen Mittlere/hohe Kosten	Kerngeschäftsanwendungen Arbeitslasten auf Produktionsebene mit strengen Anforderungen an die Ausfallsicherheit Geschäftskontinuitätsrichtlinien mit länderspezifischen oder geografischen Beschränkungen der Datenresidenz
Multi-Zone, Multi-Region	99.99%	Mehrere Recheninstanzen in mehreren Verfügbarkeitszonen in 2 oder mehr Regionen Asynchrone Datenreplikation zwischen Regionen Schutz vor Ausfällen in Regionen Hohe Kosten	Unternehmenskritische Anwendungen mit Anforderungen an kontinuierliche oder nahezu kontinuierliche Verfügbarkeit Geschäftskontinuitätsrichtlinien mit geografisch übergreifenden oder spezifischen Entfernungsanforderungen Disaster Recovery

Das folgende Architektur-Framework enthält Designüberlegungen und Architekturentscheidungen für die Bereitstellung robuster Anwendungen auf der IBM Cloud Virtual Private Cloud (VPC)-Infrastruktur. Sie deckt die folgenden Lösungsaspekte und Bereiche ab:

Vernetzungen: Lastausgleich, Domänennamensystem
Sicherheit: Datensicherheit
Ausfallsicherheit: Hochverfügbarkeit, Sicherung und Wiederherstellung, Notfallwiederherstellung
Dienstverwaltung: Überwachung, Protokollierung, Auditing, Alarmierung

Entwurfsbereich der VPC-Resilienzarchitektur

Das Architecture Design Framework bietet einen konsistenten Ansatz für die Entwicklung von Cloud-Lösungen, indem es die Anforderungen in einer Reihe von Aspekten und Bereichen berücksichtigt. Die Domänen sind architektonische Bereiche, die bei jeder Unternehmenslösung berücksichtigt werden müssen, unabhängig von der Technologie.

Client-Wiederholungslogik für hochverfügbare Anwendungen

Sie sind für die Entwicklung von Client-Anwendungen verantwortlich, die mit temporären Fehlern effektiv umgehen können. Zu den vorübergehenden Fehlern gehören Netzwerkfehler und vorübergehende Ausfälle, die durch die Hochverfügbarkeitsimplementierung eines Dienstes verursacht werden, z. B. wenn sich ein regionaler Dienst von einem zonalen Ausfall erholt. Weitere Informationen zu bestimmten IBM Cloud finden Sie in der Dokumentation der Dienste für Hochverfügbarkeit und Disaster Recovery.

Viele der IBM Cloud SDKs beruhen auf dem IBM Cloud SDK Common auf, das automatische Wiederholungsversuche unterstützt, die für die Behandlung bestimmter HTTP wie 429 und 503 ausgelegt sind. Das SDK behandelt nicht alle Fehler automatisch. Um die Vorteile der Wiederholungslogik zu nutzen, müssen Sie das SDK korrekt konfigurieren.

Einige IBM Cloud Dienste unterstützen Open-Source-Protokolle, und es kann sinnvoll sein, Open-Source-SDKs zu verwenden. Prüfen Sie diese SDKs, um festzustellen, ob sie für Ihre Anwendung nützlich sind und geeignete Wiederholungsfunktionen bieten.

Die Wiederholungslogik variiert je nach Art des IBM Cloud und der Art der Operation. Einige fehlgeschlagene Vorgänge führen zu versuchsfreundlichen Statuscodes, andere zu nicht versuchsfreundlichen Statuscodes. Fehlgeschlagene Lese- und HTTP können in der Regel durch exponentielles Backoff mit einer festen Zeitspanne wiederholt werden. Exponential Backoff ist eine Wiederholungsstrategie zur Verwaltung von Wiederholungsversuchen nach einem fehlgeschlagenen Vorgang, z. B. einer Netzwerkanfrage oder einem API-Aufruf. Die Verzögerung zwischen den Wiederholungsversuchen wird schrittweise exponentiell erhöht, wodurch die Gefahr einer Überlastung des Systems verringert wird. Die Fehler, die wiederholt werden sollten, hängen von der Art des Fehlers und dem spezifischen IBM Cloud ab. Weitere Informationen finden Sie im SDK und in der Dokumentation zu den einzelnen IBM Cloud.

Fehlgeschlagene Schreib-, HTTP PUT-, POST-, DELETE- und andere Operationen können wahrscheinlich nicht durch einen einfachen Wiederholungsmechanismus wiederhergestellt werden, es sei denn, es ist klar, dass die Operation nicht abgeschlossen wurde und die dokumentierte Client-Logik zeigt, dass eine Wiederholung angemessen ist. Wenn ein Vorgang, der den Zustand eines Systems ändert, wie z. B. die Erstellung einer Ressource, fehlschlägt, ist oft unklar, was den Fehler verursacht hat. Aufgrund dieser Ungewissheit können Sie sich nicht auf eine einfache Wiederholungslogik verlassen, um das Problem zu beheben. Verwenden Sie stattdessen fortgeschrittenere Methoden, die speziell für den Dienst IBM Cloud entwickelt wurden.

Die Wiederholung von Clients verbessert die Verfügbarkeit eines einzelnen Clients, und Arbeitslasten können sich aus vielen Clients zusammensetzen. Die Protokollierung von Client-Ausfällen in einem zentralen Protokollierungsdienst wie IBM Cloud Logs ermöglicht die Ausfall- und Verfügbarkeitsanalyse der gesamten Arbeitslast.