Zuverlässigkeit

Definition

Zuverlässigkeit bezieht sich auf die Fähigkeit eines Dienstes oder Systems, bei Bedarf die erwartete Funktion zu erfüllen. Die Zuverlässigkeit eines Systems kann anhand des Niveaus seiner Betriebsqualität innerhalb eines bestimmten Zeitraums gemessen werden. Im Gegensatz dazu steht Resilienz, die sich auf die Fähigkeit eines Systems bezieht, sich dynamisch und zuverlässig nach Infrastruktur- oder Serviceunterbrechungen zu erholen.

Weitere Informationen darüber, wie Verfügbarkeit und Resilienz zur Messung der Zuverlässigkeit verwendet werden, finden Sie in der Zuverlässigkeitssäule des AWS Well-Architected Framework.

Die wichtigsten Fragen

Verfügbarkeit

Verfügbarkeit ist der Prozentsatz der Zeit, für den eine Workload zur Verfügung steht. Zu den allgemeinen Zielen gehören 99% (3,65 Tage zulässige Ausfallzeit pro Jahr), 99,9% (8,77 Stunden) und 99,99% (52,6 Minuten), wobei die Anzahl der neun in dem Prozentsatz abgekürzt wird („zwei Neunen“ für 99%, „drei Neunen“ für 99,9% usw.). Die Verfügbarkeit der Netzwerklösung zwischen AWS und dem lokalen Rechenzentrum kann sich von der Verfügbarkeit der Gesamtlösung oder der Anwendung unterscheiden.

Zu den wichtigsten Fragen zur Verfügbarkeit einer Netzwerklösung gehören:

• Können meine AWS Ressourcen weiterarbeiten, wenn sie nicht mit meinen lokalen Ressourcen kommunizieren können? Umgekehrt?

• Sollte ich geplante Ausfallzeiten für geplante Wartungsarbeiten als in der Verfügbarkeitsmetrik eingeschlossen oder ausgeschlossen betrachten?

• Wie werde ich die Verfügbarkeit der Netzwerkschicht unabhängig vom allgemeinen Zustand der Anwendung messen?

Der Abschnitt Verfügbarkeit des Well-Architected Framework Reliability Pillar enthält Vorschläge und Formeln für die Verfügbarkeit von Berechnungen.

Ausfallsicherheit

Unter Ausfallsicherheit versteht man die Fähigkeit einer Workload, sich von Infrastruktur- oder Serviceunterbrechungen zu erholen, Datenverarbeitungsressourcen dynamisch zur Erfüllung des Bedarfs anzufordern und Unterbrechungen zu minimieren, die beispielsweise aus Fehlkonfigurationen oder vorübergehenden Netzwerkproblemen entstehen. Wenn eine redundante Netzwerkkomponente (Link, Netzwerkgeräte usw.) nicht ausreichend verfügbar ist, um die erwartete Funktion eigenständig bereitzustellen, ist sie wenig widerstandsfähig gegenüber Ausfällen. Die Folge ist eine schlechte und verschlechterte Benutzererfahrung.

Zu den wichtigsten Fragen zur Ausfallsicherheit einer Netzwerklösung gehören:

• Mit wie vielen gleichzeitigen, diskreten Ausfällen sollte ich rechnen?

• Wie kann ich einzelne Fehlerquellen sowohl bei den Konnektivitätslösungen als auch bei meinem internen Netzwerk reduzieren?

• Was ist meine Sicherheitslücke gegenüber Distributed-Denial-of-Service (DDoS) -Ereignissen?

Technische Lösung

Zunächst ist es wichtig zu beachten, dass nicht jede hybride Netzwerkverbindungslösung ein hohes Maß an Zuverlässigkeit erfordert und dass ein steigendes Maß an Zuverlässigkeit mit einem entsprechenden Anstieg der Kosten einhergeht. In einigen Szenarien sind für einen primären Standort möglicherweise zuverlässige (redundante und belastbare) Verbindungen erforderlich, da sich die Ausfallzeit stärker auf das Unternehmen auswirkt, wohingegen regionale Standorte aufgrund der geringeren Auswirkungen auf das Geschäft im Falle eines Ausfalls möglicherweise nicht dasselbe Maß an Zuverlässigkeit erfordern. Es wird empfohlen, sich an die AWS Direct Connect Resilienz-Empfehlungen zu halten, da darin die AWS bewährten Methoden zur Sicherstellung einer AWS Direct Connect hohen Ausfallsicherheit beim Design erläutert werden.

Um eine zuverlässige hybride Netzwerkverbindungslösung im Kontext der Ausfallsicherheit zu erreichen, müssen beim Entwurf die folgenden Aspekte berücksichtigt werden:

• Redundanz: Ziel ist es, jeden einzelnen Fehlerpunkt im Hybrid-Netzwerkverbindungspfad zu eliminieren, einschließlich, aber nicht beschränkt auf Netzwerkverbindungen, Edge-Netzwerkgeräte, Redundanz zwischen Availability Zones und DX-Standorten sowie Gerätestromquellen, Glasfaserpfade und Betriebssysteme. AWS-Regionen Für Zweck und Umfang dieses Whitepapers konzentriert sich Redundanz auf die Netzwerkverbindungen, Edge-Geräte (z. B. Gateway-Geräte von Kunden), den AWS DX-Standort und AWS-Regionen (für Architekturen mit mehreren Regionen).

• Zuverlässige Failover-Komponenten: In einigen Szenarien ist ein System möglicherweise funktionsfähig, erfüllt seine Funktionen jedoch nicht auf dem erforderlichen Niveau. Eine solche Situation tritt häufig bei einem einzelnen Ausfall auf, bei dem festgestellt wird, dass geplante redundante Komponenten nicht redundant betrieben wurden. Ihre Netzwerklast kann aufgrund der Auslastung nicht an einen anderen Ort geleitet werden, was zu einer unzureichenden Kapazität für die gesamte Lösung führt.

• Failover-Zeit: Die Failover-Zeit ist die Zeit, die eine sekundäre Komponente benötigt, um die Rolle der primären Komponente vollständig zu übernehmen. Die Failover-Zeit hängt von mehreren Faktoren ab: wie lange es dauert, bis der Fehler erkannt wird, wie lange es dauert, die sekundäre Konnektivität zu aktivieren, und wie lange es dauert, bis der Rest des Netzwerks über die Änderung informiert wird. Die Fehlererkennung kann mithilfe von Dead Peer Detection (DPD) für VPN Links und Bidirectional Forwarding Detection (BFD) für AWS Direct Connect Links verbessert werden. Die Aktivierung der sekundären Konnektivität kann sehr kurz sein (wenn diese Verbindungen immer aktiv sind), es kann sich um ein kurzes Zeitfenster handeln (wenn eine vorkonfigurierte VPN Verbindung aktiviert werden muss) oder länger (wenn physische Ressourcen verschoben oder neue Ressourcen konfiguriert werden müssen). Die Benachrichtigung des restlichen Netzwerks erfolgt in der Regel über Routing-Protokolle innerhalb des Kundennetzwerks, von denen jedes unterschiedliche Konvergenzzeiten und Konfigurationsoptionen hat — deren Konfiguration würde den Rahmen dieses Whitepapers sprengen.

• Verkehrstechnik: Die Verkehrstechnik im Kontext eines robusten hybriden Netzwerkkonnektivitätsdesigns zielt darauf ab, zu regeln, wie der Verkehr in normalen Szenarien und in Ausfallszenarien über mehrere verfügbare Verbindungen fließen sollte. Es wird empfohlen, das Konzept des Entwurfs für Ausfälle zu befolgen, bei dem Sie prüfen müssen, wie die Lösung in verschiedenen Ausfallszenarien funktioniert und ob sie für das Unternehmen akzeptabel ist oder nicht. In diesem Abschnitt werden einige der häufigsten Anwendungsfälle der Verkehrstechnik erörtert, mit denen die allgemeine Ausfallsicherheit der hybriden Netzwerkkonnektivitätslösung verbessert werden soll. Dieser AWS Direct Connect Abschnitt befasst sich BGP mit dem Routing und geht auf verschiedene verkehrstechnische Optionen zur Beeinflussung des Verkehrsflusses ein (Gemeinden, BGP lokale Präferenz, AS-Pfadlänge). Um eine effektive verkehrstechnische Lösung zu entwickeln, müssen Sie genau wissen, wie die einzelnen AWS Netzwerkkomponenten das IP-Routing im Hinblick auf die Routenbewertung und -auswahl handhaben und welche Mechanismen zur Beeinflussung der Routenauswahl möglich sind. Die Einzelheiten dazu würden den Rahmen dieses Dokuments sprengen. Weitere Informationen finden Sie unter Reihenfolge der Routenbewertung von Transit Gateway, Site-to-Site VPNRoutenpriorität und Direct Connect-Routing sowie bei Bedarf in der BGP Dokumentation.

Anmerkung

In der VPC Routentabelle können Sie auf eine Präfixliste verweisen, die zusätzliche Regeln für die Routenauswahl enthält. Weitere Informationen zu diesem Anwendungsfall finden Sie unter Routenpriorität für Präfixlisten. AWS Transit Gateway Routentabellen unterstützen auch Präfixlisten, aber sobald sie angewendet sind, werden sie auf bestimmte Routeneinträge erweitert.

Beispiel für duale Site-to-Site VPN Verbindungen mit spezifischeren Routen

Dieses Szenario basiert auf einer kleinen lokalen Site, die AWS-Region über redundante VPN Verbindungen über das Internet eine Verbindung zu AWS Transit Gateway einer einzigen herstellt. Das in Abbildung 10 dargestellte verkehrstechnische Design zeigt, dass Sie mit Hilfe der Verkehrstechnik die Pfadauswahl beeinflussen und so die Zuverlässigkeit der hybriden Konnektivitätslösung erhöhen können, indem Sie:

• Stabile Hybridkonnektivität: Redundante VPN Verbindungen bieten jeweils dieselbe Leistungskapazität, unterstützen automatisches Failover mithilfe des dynamischen Routing-Protokolls (BGP) und beschleunigen die Erkennung von Verbindungsausfällen mithilfe der VPN Dead-Peer-Erkennung.

• Leistungseffizienz: Die Konfiguration ECMP für beide VPN Verbindungen AWS Transit Gateway trägt zur Maximierung der gesamten VPN Verbindungsbandbreite bei. Alternativ kann die Last unabhängig von den beiden VPN Verbindungen verwaltet werden, indem verschiedene, spezifischere Routen zusammen mit der Site-Übersichtsroute angekündigt werden

Abbildung 10 — Beispiel für duale Site-to-Site VPN Verbindungen mit spezifischeren Routen

Beispiel für zwei lokale Standorte mit mehreren DX-Verbindungen

Das in Abbildung 11 dargestellte Szenario zeigt zwei lokale Rechenzentrumsstandorte, die sich in unterschiedlichen geografischen Regionen befinden und über das Konnektivitätsmodell mit maximaler Resilienz (beschrieben in den AWS Direct Connect Resilienzempfehlungen) AWS mithilfe von mit und verbunden sind. AWS Direct Connect DXGW VGW Diese beiden lokalen Standorte sind über einen Datencenter-Interconnect-Link () miteinander verbunden. DCI Die lokalen IP-Präfixe (192.168.0.0/16), die zu Remote-Zweigstellen gehören, werden von beiden lokalen Rechenzentrumsstandorten aus angekündigt. Der primäre Pfad für dieses Präfix sollte Rechenzentrum 1 sein. Bei einem Ausfall von Rechenzentrum 1 oder beiden DX-Standorten erfolgt ein Failover für den Datenverkehr zu und von den Remote-Zweigstellen auf Rechenzentrum 2. Außerdem gibt es für jedes Rechenzentrum ein standortspezifisches IP-Präfix. Diese Präfixe müssen direkt und über den anderen Rechenzentrumsstandort erreicht werden, falls beide DX-Standorte ausfallen.

Indem Sie BGP Community-Attribute mit den beworbenen Routen verknüpfen AWS DXGW, können Sie die Auswahl des Ausgangspfads von der Seite aus beeinflussen. AWS DXGW Diese Community-Attribute steuern AWS das BGP lokale Präferenzattribut, das der angekündigten Route zugewiesen ist. Weitere Informationen finden Sie unter AWS DX Routing Policies and BGP Communities.

Um die Zuverlässigkeit der Konnektivität auf dieser AWS-Region Ebene zu maximieren, wird jedes Paar von AWS DX-Verbindungen ECMP so konfiguriert, dass beide gleichzeitig für die Datenübertragung zwischen den einzelnen lokalen Standorten und verwendet werden können. AWS

Abbildung 11 — Beispiel für duale lokale Standorte mit mehreren DX-Verbindungen

Bei diesem Design werden die Datenflüsse, die für die lokalen Netzwerke bestimmt sind (mit derselben angekündigten Präfixlänge und BGP Community), auf die dualen DX-Verbindungen pro Standort verteilt. ECMP Wenn dies jedoch nicht für die gesamte DX-Verbindung erforderlich ECMP ist, kann dasselbe Konzept, das zuvor erörtert und in der Dokumentation zu Routing-Richtlinien und BGP Communities beschrieben wurde, verwendet werden, um die Pfadauswahl auf DX-Verbindungsebene weiter zu optimieren.

Hinweis: Wenn sich im Pfad innerhalb der lokalen Rechenzentren Sicherheitsgeräte befinden, müssen diese Geräte so konfiguriert werden, dass Datenströme, die über einen DX-Link gehen und von einem anderen DX-Link (beide Verbindungen werden verwendetECMP) innerhalb desselben Rechenzentrumsstandorts kommen, möglich sind.

VPNBeispiel für eine Verbindung als Backup zur AWS DX-Verbindung

VPNkann ausgewählt werden, um eine Backup-Netzwerkverbindung zu einer AWS Direct Connect Verbindung bereitzustellen. In der Regel wird diese Art von Konnektivitätsmodell durch die Kosten bestimmt, da es aufgrund der undeterministischen Leistung über das Internet eine geringere Zuverlässigkeit der gesamten hybriden Konnektivitätslösung bietet und für eine Verbindung über SLA das öffentliche Internet keine Garantie bietet. Es ist ein gültiges und kostengünstiges Konnektivitätsmodell und sollte verwendet werden, wenn die Kosten oberste Priorität haben und das Budget begrenzt ist, oder möglicherweise als Zwischenlösung, bis ein sekundärer DX bereitgestellt werden kann. Abbildung 12 zeigt den Entwurf dieses Konnektivitätsmodells. Eine wichtige Überlegung bei diesem Design, bei dem VPN sowohl die als auch die DX-Verbindung am enden AWS Transit Gateway, ist, dass die VPN Verbindung eine höhere Anzahl von Routen ankündigen kann als die, die über eine DX-Verbindung angekündigt werden können, mit der verbunden ist. AWS Transit Gateway Dies kann zu einer suboptimalen Routingsituation führen. Eine Option zur Lösung dieses Problems besteht darin, die Routenfilterung auf dem Kunden-Gateway-Gerät (CGW) für die über die VPN Verbindung empfangenen Routen zu konfigurieren, sodass nur die Übersichtsrouten akzeptiert werden.

Hinweis: Um die Übersichtsroute auf dem zu erstellen AWS Transit Gateway, müssen Sie eine statische Route zu einem beliebigen Anhang in der AWS Transit Gateway Routentabelle angeben, sodass die Zusammenfassung entlang der spezifischeren Route gesendet wird.

Aus Sicht der AWS Transit Gateway Routingtabelle werden die Routen für das lokale Präfix sowohl von der AWS DX-Verbindung (viaDXGW) als auch vonVPN, mit derselben Präfixlänge empfangen. Gemäß der Route-Prioritätslogik von AWS Transit Gateway haben über Direct Connect empfangene Routen eine höhere Priorität als Routen Site-to-SiteVPN, die über sie empfangen werden, und daher AWS Direct Connect wird der Pfad über den bevorzugt, um die lokalen Netzwerke zu erreichen.

Abbildung 12 — Beispiel für eine VPN Verbindung als Backup zur AWS DX-Verbindung

Die folgende Entscheidungsstruktur hilft Ihnen dabei, die gewünschte Entscheidung zu treffen, um eine stabile Hybrid-Netzwerkkonnektivität zu erreichen (was zu einer zuverlässigen) Hybrid-Netzwerkkonnektivität führt. Weitere Informationen finden Sie im AWS Direct Connect Resiliency Toolkit.

Abbildung 13 — Entscheidungsbaum zur Zuverlässigkeit