Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Zielgruppen für Ihre Network Load Balancers
Jede Zielgruppe wird verwendet, um Anfragen an ein oder mehrere registrierte Ziele weiterzuleiten. Wenn Sie einen Listener erstellen, geben Sie eine Zielgruppe für die Standardaktion an. Der Datenverkehr wird an die in der Listener-Regel angegebene Zielgruppe weitergeleitet. Sie können unterschiedliche Zielgruppen für verschiedene Arten von Anfragen erstellen. Erstellen Sie beispielsweise eine Zielgruppe für allgemeine Anfragen und andere Zielgruppen für Anfragen an die Microservices für Ihre Anwendung. Weitere Informationen finden Sie unter Network-Load-Balancer-Komponenten.
Sie definieren Zustandsprüfungseinstellungen für Ihren Load Balancer pro Zielgruppe. Jede Zielgruppe verwendet die standardmäßigen Zustandsprüfungseinstellungen, es sei denn, Sie überschreiben diese, wenn Sie die Zielgruppe erstellen, oder ändern sie später. Nachdem Sie eine Zielgruppe in einer Regel für einen Listener angegeben haben, überwacht der Load Balancer kontinuierlich den Zustand aller mit der Zielgruppe registrierten Ziele, die in einer Availability Zone vorhanden sind, die für den Load Balancer aktiviert ist. Der Load Balancer leitet Anfragen an die registrierten Ziele weiter, die fehlerfrei sind. Weitere Informationen finden Sie unter Gesundheitschecks für Network Load Balancer Balancer-Zielgruppen.
Inhalt
Weiterleitungskonfiguration
Ein Load Balancer leitet standardmäßig mithilfe des Protokolls und der Portnummer, die Sie beim Erstellen der Zielgruppe angegeben haben, Anfragen an die Ziele weiter. Alternativ können Sie den für Weiterleitung von Datenverkehr zu einem Ziel verwendeten Port überschreiben, wenn Sie es bei der Zielgruppe registrieren.
Zielgruppen für Network Load Balancers unterstützen die folgenden Protokolle und Ports:
-
Protokolle: TCP, TLS, UDP, TCP_UDP
-
Ports: 1-65535
Wenn eine Zielgruppe mit dem TLS-Protokoll konfiguriert ist, stellt der Load Balancer TLS-Verbindungen mit den Zielen her, wobei er die auf den Zielen installierten Zertifikate verwendet. Der Load Balancer überprüft diese Zertifikate nicht. Daher können Sie selbstsignierte Zertifikate oder Zertifikate verwenden, die abgelaufen sind. Da sich der Load Balancer in einer Virtual Private Cloud (VPC) befindet, wird der Verkehr zwischen dem Load Balancer und den Zielen auf Paketebene authentifiziert, sodass kein Risiko von man-in-the-middle Angriffen oder Spoofing besteht, selbst wenn die Zertifikate auf den Zielen nicht gültig sind.
In der folgenden Tabelle finden Sie eine Zusammenfassung der unterstützten Kombinationen der Einstellungen für Listener-Protokoll und Zielgruppe.
| Listener-Protokoll | Protokoll der Zielgruppe | Zielgruppentyp | Health check protocol (Zustandsprüfungsprotokoll) |
|---|---|---|---|
|
TCP |
TCP | TCP_UDP |
instance | ip |
HTTP | HTTPS | TCP |
|
TCP |
TCP |
alb |
HTTP | HTTPS |
|
TLS |
TCP | TLS |
instance | ip |
HTTP | HTTPS | TCP |
|
UDP |
UDP | TCP_UDP |
instance | ip |
HTTP | HTTPS | TCP |
|
TCP_UDP |
TCP_UDP |
instance | ip |
HTTP | HTTPS | TCP |
Zieltyp
Wenn Sie eine Zielgruppe erstellen, können Sie ihren Zieltyp angeben, der bestimmt, wie Sie ihre Ziele angeben. Nachdem Sie eine Zielgruppe erstellt haben, können Sie ihren Zieltyp nicht mehr ändern.
Die folgenden Zieltypen sind möglich:
instance-
Die Ziele werden nach Instance-ID angegeben.
ip-
Die Ziele werden nach IP-Adresse angegeben.
alb-
Das Ziel ist ein Application Load Balancer.
Wenn der Zieltyp ip ist, können Sie IP-Adressen von einem der folgenden CIDR-Blöcke angeben:
Wichtig
Sie können keine öffentlich weiterleitungsfähigen IP-Adressen angeben.
Mit allen unterstützten CIDR-Blöcken können Sie die folgenden Ziele bei einer Zielgruppe registrieren:
-
AWS Ressourcen, die über IP-Adresse und Port adressierbar sind (z. B. Datenbanken).
-
Lokale Ressourcen, mit denen AWS über eine VPN-Verbindung AWS Direct Connect oder eine Site-to-Site VPN-Verbindung verbunden ist.
Wenn die Client-IP-Erhaltung für Ihre Zielgruppen deaktiviert ist, kann der Load Balancer rund 55 000 Verbindungen pro Minute für jede Kombination aus Network-Load-Balancer-IP-Adresse und eindeutigem Ziel (IP-Adresse und Port) unterstützen. Werden diese Verbindungen überschritten, steigt das Risiko von Port-Zuordnungsfehlern. Falls Port-Zuordnungsfehlern auftreten, fügen Sie der Zielgruppe mehrere Ziele hinzu.
Wenn Sie einen Network Load Balancer in einer gemeinsam genutzten Amazon VPC (als Teilnehmer) starten, können Sie nur Ziele in Subnetzen registrieren, die für Sie freigegeben wurden.
Wenn der Zieltyp alb ist, können Sie einen einzelnen Application Load Balancer als Ziel registrieren. Weitere Informationen finden Sie unter Verwenden Sie Application Load Balancer als Ziele eines Network Load Balancer.
Network Load Balancers unterstützen den Zieltyp lambda nicht. Application Load Balancers sind die einzigen Load Balancers, die den Zieltyp lambda unterstützen. Weitere Informationen finden Sie unter Lambda-Funktionen als Ziele im Benutzerhandbuch für Application Load Balancers.
Wenn Sie Microservices auf Instances haben, die bei einem Network Load Balancer registriert sind, können Sie den Load Balancer nicht für die Kommunikation zwischen den Instances verwenden, es sei denn, der Load Balancer ist mit dem Internet verbunden oder die Instances sind nach IP-Adresse registriert. Weitere Informationen finden Sie unter Verbindungen überschreiten bei Anfragen von einem Ziel an dessen Load Balancer das Zeitlimit..
Routing- und IP-Adressen anfordern
Wenn Sie Ziele unter Verwendung einer Instance-ID angeben, wird Datenverkehr an Instances unter Verwendung der primären privaten IP-Adresse weitergeleitet, die in der primären Netzwerkschnittstelle für die Instance angegeben ist. Der Load Balancer schreibt die Ziel-IP-Adresse aus dem Datenpaket neu, bevor er sie an die Ziel-Instance weiterleitet.
Wenn Sie Ziele unter Verwendung von IP-Adressen angeben, können Sie den Datenverkehr über eine beliebige private IP-Adresse aus einer oder mehreren Netzwerkschnittstellen an eine Instance weiterleiten. Auf diese Weise können mehrere Anwendungen auf eine Instance denselben Port verwenden. Beachten Sie, dass jede Netzwerkschnittstelle eine eigene Sicherheitsgruppe haben kann. Der Load Balancer schreibt die Ziel-IP-Adresse neu, bevor sie an das Ziel weitergeleitet wird.
Weitere Informationen zum Ermöglichen von Datenverkehr zu Ihren Instances finden Sie unter Zielsicherheitsgruppen.
On-Premises-Ressourcen als Ziele
Lokale Ressourcen, die über eine VPN-Verbindung AWS Direct Connect oder eine Site-to-Site VPN-Verbindung verknüpft sind, können als Ziel dienen, wenn der Zieltyp istip.
Bei der Verwendung von On-Premises-Ressourcen müssen die IP-Adressen dieser Ziele dennoch aus einem der folgenden CIDR-Blöcke stammen:
Weitere Informationen zu finden Sie AWS Direct Connect unter Was ist? AWS Direct Connect
Weitere Informationen zu AWS Site-to-Site VPN finden Sie unter Was ist AWS Site-to-Site VPN?
IP-Adresstyp
Wenn Sie eine neue Zielgruppe erstellen, können Sie den IP-Adresstyp Ihrer Zielgruppe auswählen. Dadurch wird die IP-Version gesteuert, die für die Kommunikation mit Zielen und die Überprüfung ihres Status verwendet wird. Network Load Balancer unterstützen beide IPv4 IPv6 Zielgruppen.
Überlegungen
-
Alle IP-Adressen innerhalb einer Zielgruppe müssen denselben IP-Adresstyp haben. Sie können beispielsweise kein IPv4 Ziel bei einer IPv6 Zielgruppe registrieren.
-
IPv6 Zielgruppen unterstützen IP- und Instanz-Typ-Ziele.
-
Sie müssen eine IPv6 Zielgruppe mit einem
dualstackLoad Balancer verwenden. -
Sie können keine IPv4 Zielgruppe mit einem UDP-Listener für einen
dualstackLoad Balancer verwenden.
Registrierte Ziele
Ihr Load Balancer dient als zentraler Kontaktpunkt für Clients und verteilt eingehenden Datenverkehr an die fehlerfreien registrierten Ziele. Jede Zielgruppe muss mindestens ein registriertes Ziel in jeder Availability Zone haben, die für den Load Balancer aktiviert ist. Sie können jedes Ziel bei einer oder mehreren Zielgruppen registrieren.
Wenn die Nachfrage nach Ihrer Anwendung steigt, können Sie zusätzliche Ziele bei einer oder mehreren Zielgruppen registrieren, um die Nachfrage zu bewältigen. Der Load Balancer leitet den Datenverkehr an ein neu registriertes Ziel weiter, sobald der Registrierungsprozess abgeschlossen ist und das Ziel die erste erste Zustandsprüfung bestanden hat, unabhängig vom konfigurierten Schwellenwert.
Wenn die Nachfrage nach Ihrer Anwendung sinkt oder Sie Ihre Ziele warten müssen, können Sie die Registrierung von Zielen bei Ihren Zielgruppen aufheben. Bei der Aufhebung der Registrierung eines Ziels wird es aus Ihrer Zielgruppe entfernt. Ansonsten hat dies keine Auswirkungen auf das Ziel. Der Load Balancer stoppt das Weiterleiten von Datenverkehr an ein Ziel, sobald die Registrierung des Ziels aufgehoben wird. Das Ziel wechselt in den Zustand draining, bis laufende Anfragen abgeschlossen wurden. Sie können das Ziel erneut bei der Zielgruppe registrieren, wenn es bereit ist, wieder Datenverkehr zu erhalten.
Wenn Sie Ziele nach Instance-ID registrieren, können Sie Ihren Load Balancer mit einer Auto-Scaling-Gruppe verwenden. Nachdem Sie eine Zielgruppe einer Auto-Scaling-Gruppe angefügt haben, registriert Auto Scaling Ihre Ziele bei der Zielgruppe für Sie, wenn es sie startet. Weitere Informationen finden Sie unter Einen Load Balancer zu Ihrer Auto Scaling Scaling-Gruppe hinzufügen im Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch.
Anforderungen und Überlegungen
-
Sie können Instances nicht anhand der Instance-ID registrieren, wenn sie einen der folgenden Instance-Typen verwenden: C1, CC1,, CC2, CG1, CG2 CR1, G1, G2,, HI1, M1 HS1, M2, M3 oder T1.
-
Bei der Registrierung von Zielen anhand der Instanz-ID für eine IPv6 Zielgruppe müssen die Ziele über eine zugewiesene primäre IPv6 Adresse verfügen. Weitere Informationen finden Sie unter IPv6 Adressen im EC2 Amazon-Benutzerhandbuch
-
Bei der Registrierung von Zielen anhand der Instance-ID müssen sich Instances in derselben Amazon-VPC wie der Network Load Balancer befinden. Sie können Instances nicht nach Instance-ID registrieren, wenn sie sich in einer VPC befinden, die mit der Load-Balancer-VPC gekoppelt ist (dieselbe Region oder eine andere Region). Sie können diese Instances nach IP-Adresse registrieren.
-
Wenn Sie ein Ziel nach IP-Adresse registrieren und sich die IP-Adresse in derselben VPC wie der Load Balancer befindet, überprüft der Load Balancer, ob das Ziel zu einem Subnetz gehört, das es erreichen kann.
-
Der Load Balancer leitet Datenverkehr nur an Ziele in aktivierten Availability Zones weiter. Ziele in Zonen, die nicht aktiviert sind, werden nicht verwendet.
-
Registrieren Sie Instances für UDP- und TCP_UDP-Zielgruppen nicht anhand der IP-Adresse, wenn sie sich außerhalb der Load Balancer-VPC befinden oder wenn sie einen der folgenden Instance-Typen verwenden: C1,,,,, CC1, G1 CC2 CG1, G2 CG2 CR1,,, M1, M2 HI1 HS1, M3 oder T1. Ziele, die sich außerhalb der Load-Balancer-VPC befinden oder einen nicht unterstützten Instance-Typ verwenden, können möglicherweise Datenverkehr vom Load Balancer empfangen, dann aber nicht antworten.
Zielgruppenattribute
Sie können eine Zielgruppe konfigurieren, indem Sie ihre Attribute bearbeiten. Weitere Informationen finden Sie unter Zielgruppenattribute bearbeiten.
Die folgenden Zielgruppenattribute werden unterstützt. Sie können diese Attribute nur ändern, wenn der Zielgruppentyp instance oder ip ist. Wenn der Zielgruppentyp alb ist, verwenden diese Attribute immer ihre Standardwerte.
deregistration_delay.timeout_seconds-
Die Zeitspanne, wie lange Elastic Load Balancing wartet, bevor der Status eines deregistrierten Ziels von
draininginunusedgeändert wird. Der Bereich liegt zwischen 0 und 3 600 Sekunden. Der Standardwert beträgt 300 Sekunden. deregistration_delay.connection_termination.enabled-
Gibt an, ob der Load Balancer Verbindungen am Ende des Timeouts der Abmeldung beendet. Der Wert ist entweder
trueoderfalse. Für neue UDP/TCP_UDP-Zielgruppen ist die Standardeinstellungtrue. Andernfalls ist die Standardeinstellungfalse. load_balancing.cross_zone.enabled-
Gibt an, ob zonenübergreifendes Load Balancing aktiviert ist. Der Wert ist entweder
true,falseoderuse_load_balancer_configuration. Der Standardwert istuse_load_balancer_configuration. preserve_client_ip.enabled-
Zeigt an, ob die IP-Erhaltung des Clients aktiviert ist. Der Wert ist entweder
trueoderfalse. Der Standardwert ist deaktiviert, wenn der Zielgruppentyp die IP-Adresse ist und das Zielgruppenprotokoll TCP oder TLS ist. Andernfalls ist die Standardeinstellung aktiviert. Die IP-Erhaltung des Clients kann für die Zielgruppen UDP und TCP_UDP nicht deaktiviert werden. proxy_protocol_v2.enabled-
Gibt an, ob die Proxy-Protokoll-Version 2 aktiviert ist. Das Proxy-Protokoll ist standardmäßig deaktiviert.
stickiness.enabled-
Gibt an, ob Sticky Sessions aktiviert sind. Der Wert ist entweder
trueoderfalse. Der Standardwert istfalse. stickiness.type-
Die Art der „Sticky Sessions“. Der mögliche Wert ist
source_ip. target_group_health.dns_failover.minimum_healthy_targets.count-
Die Mindestanzahl von Zielen, die fehlerfrei sein müssen. Wenn die Anzahl der fehlerfreien Ziele unter diesem Wert liegt, markieren Sie die Zone im DNS als fehlerhaft, sodass der Datenverkehr nur an fehlerfreie Zonen weitergeleitet wird. Die möglichen Werte sind
offoder eine ganze Zahl von 1 bis zur maximalen Anzahl von Zielen. WennoffDNS-Failaway deaktiviert ist, d. h. selbst wenn alle Ziele in der Zielgruppe fehlerhaft sind, wird die Zone nicht aus DNS entfernt. Der Standardwert ist 1. target_group_health.dns_failover.minimum_healthy_targets.percentage-
Der Mindestprozentsatz der Ziele, die fehlerfrei sein müssen. Wenn der Prozentsatz fehlerfreier Ziele unter diesem Wert liegt, markieren Sie die Zone im DNS als fehlerhaft, sodass der Datenverkehr nur an fehlerfreie Zonen weitergeleitet wird. Die möglichen Werte sind
offoder eine Ganzzahl von 1 bis 100. WennoffDNS-Failaway deaktiviert ist, d. h. selbst wenn alle Ziele in der Zielgruppe fehlerhaft sind, wird die Zone nicht aus DNS entfernt. Der Standardwert istoff. target_group_health.unhealthy_state_routing.minimum_healthy_targets.count-
Die Mindestanzahl von Zielen, die fehlerfrei sein müssen. Wenn die Anzahl fehlerfreier Ziele unter diesem Wert liegt, senden Sie Datenverkehr an alle Ziele, einschließlich nicht fehlerfreier Ziele. Der Bereich reicht von 1 bis zur maximalen Anzahl von Zielen. Der Standardwert ist 1.
target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage-
Der Mindestprozentzatz der Ziele, die fehlerfrei sein müssen. Wenn der Prozentsatz fehlerfreier Ziele unter diesem Wert liegt, senden Sie Datenverkehr an alle Ziele, einschließlich nicht fehlerfreier Ziele. Die möglichen Werte sind
offoder eine Ganzzahl von 1 bis 100. Der Standardwert istoff. target_health_state.unhealthy.connection_termination.enabled-
Gibt an, ob der Load Balancer Verbindungen mit fehlerhaften Zielen beendet. Der Wert ist entweder
trueoderfalse. Der Standardwert isttrue. target_health_state.unhealthy.draining_interval_seconds-
Die Wartezeit von Elastic Load Balancing, bevor der Status eines fehlerhaften Ziels von
unhealthy.drainingzuunhealthygeändert wird. Der Bereich liegt zwischen 0 und 360000 Sekunden. Der Standardwert ist 0 Sekunden.Hinweis: Dieses Attribut kann nur konfiguriert werden, wenn
target_health_state.unhealthy.connection_termination.enabledes ist.false
Zustand der Zielgruppe
Standardmäßig gilt eine Zielgruppe als fehlerfrei, solange sie mindestens ein fehlerfreies Ziel hat. Wenn Sie eine große Flotte haben, reicht es nicht aus, nur ein fehlerfreies Ziel zu haben, das den Datenverkehr bereitstellt. Stattdessen können Sie eine Mindestanzahl oder einen Prozentsatz von Zielen angeben, die fehlerfrei sein müssen, und angeben, welche Aktionen der Load Balancer ergreift, wenn die fehlerfreien Ziele unter den angegebenen Schwellenwert fallen. Dies verbessert die Verfügbarkeit.
Maßnahmen bei fehlerhaftem Zustand
Sie können fehlerhafte Schwellenwerte für die folgenden Aktionen konfigurieren:
-
DNS-Failover – Wenn die fehlerfreien Ziele in einer Zone unter den Schwellenwert fallen, markieren wir die IP-Adressen des Load-Balancer-Knotens für die Zone im DNS als fehlerhaft. Wenn Clients den DNS-Namen des Load Balancers auflösen, wird der Datenverkehr daher nur an fehlerfreie Zonen weitergeleitet.
-
Routing-Failover – Wenn die fehlerfreien Ziele in einer Zone unter den Schwellenwert fallen, sendet der Load Balancer den Datenverkehr an alle Ziele, die für den Load-Balancer-Knoten verfügbar sind, einschließlich fehlerhafter Ziele. Dies erhöht die Wahrscheinlichkeit, dass eine Client-Verbindung erfolgreich ist, insbesondere wenn Ziele vorübergehend die Integritätsprüfungen nicht bestehen, und verringert das Risiko, dass die fehlerfreien Ziele überlastet werden.
Anforderungen und Überlegungen
-
Wenn Sie beide Arten von Schwellenwerten für eine Aktion angeben (Anzahl und Prozentsatz), ergreift der Load Balancer die Aktion, wenn einer der Schwellenwerte überschritten wird.
-
Wenn Sie Schwellenwerte für beide Aktionen angeben, muss der Schwellenwert für DNS-Failover größer oder gleich dem Schwellenwert für Routing-Failover sein, sodass der DNS-Failover entweder mit oder vor dem Routing-Failover erfolgt.
-
Wenn Sie den Schwellenwert als Prozentsatz angeben, berechnen wir den Wert dynamisch auf der Grundlage der Gesamtzahl der Ziele, die bei den Zielgruppen registriert sind.
-
Die Gesamtzahl der Ziele hängt davon ab, ob zonenübergreifendes Load Balancing deaktiviert oder aktiviert ist. Wenn zonenübergreifendes Load Balancing deaktiviert ist, sendet jeder Knoten Datenverkehr nur an die Ziele in seiner eigenen Zone, was bedeutet, dass die Schwellenwerte für die Anzahl der Ziele in jeder aktivierten Zone separat gelten. Wenn zonenübergreifende Load Balancing aktiviert ist, sendet jeder Knoten Datenverkehr an alle aktivierten Ziele, was bedeutet, dass die angegebenen Schwellenwerte für die Gesamtanzahl der Ziele in allen aktivierten Zonen gelten. Weitere Informationen finden Sie unter Zonenübergreifendes Load Balancing.
-
Beim DNS-Failover entfernen wir die IP-Adressen für die fehlerhaften Zonen aus dem DNS-Hostnamen für den Load Balancer. Der DNS-Cache des lokalen Clients kann diese IP-Adressen jedoch enthalten, bis die time-to-live (TTL) im DNS-Eintrag abläuft (60 Sekunden).
-
Wenn ein DNS-Failover auftritt, wirkt sich dies auf alle Zielgruppen aus, die dem Load Balancer zugeordnet sind. Stellen Sie sicher, dass Sie in Ihren verbleibenden Zonen über genügend Kapazität verfügen, um diesen zusätzlichen Datenverkehr zu bewältigen, insbesondere wenn das zonenübergreifende Load Balancing deaktiviert ist.
-
Wenn beim DNS-Failover alle Load-Balancer-Zonen als fehlerhaft eingestuft werden, sendet der Load Balancer Datenverkehr an alle Zonen, einschließlich der fehlerhaften Zonen.
-
Neben der Frage, ob genügend fehlerfreie Ziele vorhanden sind, die zu einem DNS-Failover führen könnten, gibt es noch andere Faktoren, z. B. den Zustand der Zone.
Beispiel
Im folgenden Beispiel wird veranschaulicht, wie Zustandseinstellungen für Zielgruppen angewendet werden.
Szenario
-
Ein Load Balancer, der zwei Availability Zones, A und B, unterstützt
-
Jede Availability Zone enthält 10 registrierte Ziele
-
Die Zielgruppe hat die folgenden Zustandseinstellungen für Zielgruppen:
DNS-Failover – 50 %
Routing-Failover – 50 %
-
Sechs Ziele fallen in der Availability Zone B aus
Wenn zonenübergreifendes Load Balancing deaktiviert ist
-
Der Load-Balancer-Knoten in jeder Availability Zone kann Datenverkehr nur an die 10 Ziele in seiner Availability Zone senden.
-
In der Availability Zone A gibt es 10 fehlerfreie Ziele, sodass der erforderliche Prozentsatz fehlerfreier Ziele erreicht wird. Der Load Balancer verteilt weiterhin den Datenverkehr zwischen den 10 fehlerfreien Zielen.
-
In der Availability Zone B gibt es nur 4 fehlerfreie Ziele, was 40 % der Ziele für den Load-Balancer-Knoten in Availability Zone B entspricht. Da dies weniger ist als der erforderliche Prozentsatz fehlerfreier Ziele, ergreift der Load Balancer die folgenden Aktionen:
-
DNS-Failover – Die Availability Zone B ist im DNS als fehlerhaft markiert. Da Clients den Load-Balancer-Namen nicht in den Load-Balancer-Knoten in Availability Zone B auflösen können und Availability Zone A fehlerfrei ist, senden Clients neue Verbindungen zur Availability Zone A.
-
Routing-Failover – Wenn neue Verbindungen explizit an Availability Zone B gesendet werden, verteilt der Load Balancer den Datenverkehr an alle Ziele in Availability Zone B, einschließlich der fehlerhaften Ziele. Dadurch werden Ausfälle bei den verbleibenden fehlerlosen Zielen verhindert.
-
Wenn zonenübergreifendes Load Balancing aktiviert ist
-
Jeder Load-Balancer-Knoten kann Datenverkehr an alle 20 registrierten Ziele in beiden Availability Zones senden.
-
Es gibt 10 fehlerfreie Ziele in Availability Zone A und 4 fehlerfreie Ziele in Availability Zone B, also insgesamt 14 fehlerfreie Ziele. Das sind 70 % der Ziele für die Load-Balancer-Knoten in beiden Availability Zones, wodurch der erforderliche Prozentsatz fehlerfreier Ziele erreicht wird.
-
Der Load Balancer verteilt den Datenverkehr zwischen den 14 fehlerfreien Zielen in beiden Availability Zones.
Verwenden des Route-53-DNS-Failover für Ihren Load Balancer
Wenn Sie mithilfe von Route 53 DNS-Abfragen an Ihren Load Balancer leiten, können Sie mithilfe von Route 53 auch DNS-Failover für Ihren Load Balancer konfigurieren. In einer Failover-Konfiguration prüft Route 53 die Integrität der Zielgruppen für den Load Balancer, um zu ermitteln, ob diese verfügbar sind. Wenn keine funktionsfähigen Ziele für den Load Balancer registriert sind oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 den Datenverkehr an eine andere verfügbare Ressource, z. B. einen fehlerfreien Load Balancer oder eine statische Website in Amazon S3, weiter.
Beispiel: Sie haben eine Webanwendung www.example.com und möchten, dass redundante Instances hinter zwei Load Balancers in verschiedenen Regionen laufen. Sie möchten, dass der Datenverkehr in erster Linie auf den Load Balancer in einer Region weitergeleitet wird, und der Load Balancer in der anderen Region soll bei Ausfällen als Sicherung dienen. Wenn Sie DNS Failover konfigurieren, können Sie einen primären und einen sekundären (Sicherung) Load Balancer festlegen. Route 53 leitet den Datenverkehr direkt zum primären Load Balancer, und wenn dieser nicht verfügbar ist, wird der Datenverkehr zum sekundären Load Balancer geleitet.
Verwenden von „Zielintegrität auswerten“
-
Wenn die Option „Zielintegrität auswerten“ für einen Aliaseintrag für einen Network Load Balancer auf
Yesfestgelegt ist, wertet Route 53 die Integrität der durch denalias target-Wert angegebenen Ressource aus. Für einen Network Load Balancer verwendet Route 53 die mit dem Load Balancer verknüpften Zustandsprüfungen für Zielgruppen. -
Wenn alle Zielgruppen in einem Network Load Balancer fehlerfrei sind, markiert Route 53 den Aliaseintrag als fehlerfrei. Wenn eine Zielgruppe mindestens ein gesundes Ziel enthält, ist die Zustandsprüfung für die Zielgruppe erfolgreich. Route 53 gibt dann Datensätze gemäß Ihrer Routing-Richtlinie zurück. Wenn die Failover-Routing-Richtlinie verwendet wird, gibt Route 53 den primären Datensatz zurück.
-
Wenn eine der Zielgruppen in einem Network Load Balancer fehlerhaft ist, besteht der Aliaseintrag die Route-53-Zustandsprüfung (Fail-Open) nicht. Bei Verwendung von „Zielintegrität auswerten“ würde dies die Failover-Routing-Richtlinie nicht erfüllen.
-
Wenn alle Zielgruppen in einem Network Load Balancer leer sind (keine Ziele), betrachtet Route 53 den Datensatz als fehlerhaft (Fail-Open). Bei Verwendung von „Zielintegrität auswerten“ würde dies die Failover-Routing-Richtlinie nicht erfüllen.
Weitere Informationen finden Sie unter Konfigurieren von DNS-Failover im Entwicklerhandbuch für Amazon Route 53.
