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
• Zieltyp
• IP-Adresstyp
• Registrierte Ziele
• Zielgruppenattribute
• Zustand der Zielgruppe
• Erstellen einer Zielgruppe für Ihren Network Load Balancer
• Aktualisieren Sie die Zielgruppen-Gesundheitseinstellungen für Ihren Network Load Balancer
• Gesundheitschecks für Network Load Balancer Balancer-Zielgruppen
• Zielgruppenattribute für Ihren Network Load Balancer bearbeiten
• Registrieren Sie Ziele für Ihren Network Load Balancer
• Verwenden Sie Application Load Balancer als Ziele eines Network Load Balancer
• Kennzeichnen Sie eine Zielgruppe für Ihren Network Load Balancer
• Löschen Sie eine Zielgruppe für Ihren Network Load Balancer

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 mithilfe von Zertifikaten, die Sie auf den Zielen installieren, TLS Verbindungen zu den Zielen her. 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 Datenverkehr 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 istip, können Sie IP-Adressen aus einem der folgenden Blöcke angeben: CIDR

• Die Subnetze der VPC für die Zielgruppe

• 10.0.0.0/8 (1918) RFC

• 100,64,0,0/10 (6598) RFC

• 172,16,0,0/12 RFC (1918)

• 192.168,0,0/16 (RFC1918)

Wichtig

Sie können keine öffentlich weiterleitungsfähigen IP-Adressen angeben.

Alle unterstützten CIDR Blöcke ermöglichen es Ihnen, die folgenden Ziele bei einer Zielgruppe zu registrieren:

• AWS Ressourcen, die über IP-Adresse und Port adressierbar sind (z. B. Datenbanken).

• Lokale Ressourcen, die AWS über eine AWS Direct Connect oder eine VPN Site-to-Site-Verbindung miteinander verknüpft sind.

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 einem gemeinsam genutzten Amazon VPC (als Teilnehmer) starten, können Sie nur Ziele in Subnetzen registrieren, die mit Ihnen geteilt 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 Verbindung AWS Direct Connect oder eine VPN Site-to-Site-Verbindung verknüpft sind, können als Ziel dienen, wenn der Zieltyp ist. ip

Wenn Sie lokale Ressourcen verwenden, müssen die IP-Adressen dieser Ziele dennoch aus einem der folgenden CIDR Blöcke stammen:

• 10.0.0.0/8 (1918) RFC

• 100,64,0,0/10 (6598) RFC

• 172,16,0,0/12 RFC (1918)

• 192.168,0,0/16 (RFC1918)

Weitere Informationen zu finden Sie unter Was AWS Direct Connect 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. Die Standardauswahl ist IPv4. IPv6Zielgruppen können nur Dual-Stack-Network-Loadbalancern zugeordnet werden.

Überlegungen

• Alle IP-Adressen innerhalb einer Zielgruppe müssen denselben IP-Adresstyp haben. Sie können beispielsweise kein Ziel bei einer IPv4 Zielgruppe registrieren. IPv6

• IPv6Zielgruppen können nur mit dualstack Loadbalancern mit TCP oder einem TLS Listener verwendet werden.

• IPv6Zielgruppen unterstützen Ziele vom Typ IP und Instance.

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, CG2CR1, G1, G2,,HI1, M1HS1, 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 IPv6Adressen im EC2Amazon-Benutzerhandbuch

• Bei der Registrierung von Zielen anhand der Instance-ID müssen sich Instances im selben Amazon VPC wie der Network Load Balancer befinden. Sie können Instances nicht anhand der Instance-ID registrieren, wenn sie sich in einem befindenVPC, das mit dem Load Balancer verbunden ist VPC (dieselbe Region oder eine andere Region). Sie können diese Instances nach IP-Adresse registrieren.

• Wenn Sie ein Ziel anhand der IP-Adresse registrieren und sich die IP-Adresse in derselben Adresse VPC wie der Load Balancer befindet, überprüft der Load Balancer, ob es sich um ein Subnetz handelt, das er 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 des Load Balancers befinden VPC oder wenn sie einen der folgenden Instance-Typen verwenden: C1,,CC1,CC2,CG1, CG2CR1, G1, G2,HI1,HS1, M1, M2, M3 oder T1. Ziele, die sich außerhalb des Load Balancers befinden VPC oder einen nicht unterstützten Instance-Typ verwenden, können möglicherweise Traffic vom Load Balancer empfangen, dann aber nicht antworten.

Zielgruppenattribute

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 draining in unused geä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 true oder false. Für neueUDP/TCP_ UDP -Zielgruppen ist die Standardeinstellung. true Andernfalls ist die Standardeinstellung false.

load_balancing.cross_zone.enabled

Gibt an, ob zonenübergreifendes Load Balancing aktiviert ist. Der Wert ist entweder true, false oder use_load_balancer_configuration. Der Standardwert ist use_load_balancer_configuration.

preserve_client_ip.enabled

Zeigt an, ob die IP-Erhaltung des Clients aktiviert ist. Der Wert ist entweder true oder false. Die Standardeinstellung ist deaktiviert, wenn der Zielgruppentyp IP-Adresse und das Zielgruppenprotokoll TCP oder istTLS. Andernfalls ist die Standardeinstellung aktiviert. Die Client-IP-Erhaltung kann für die UDP Zielgruppen UDP und TCP _ 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.

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 als fehlerhaft inDNS, sodass der Datenverkehr nur an fehlerfreie Zonen weitergeleitet wird. Die möglichen Werte sind off oder eine ganze Zahl von 1 bis zur maximalen Anzahl von Zielen. Wenn off DNS Failaway deaktiviert ist, d. h. selbst wenn alle Ziele in der Zielgruppe fehlerhaft sind, wird die Zone nicht aus der Zone entfernt. DNS Der Standardwert ist 1.

target_group_health.dns_failover.minimum_healthy_targets.percentage

Der Mindestprozentzatz der Ziele, die fehlerfrei sein müssen. Wenn der Prozentsatz fehlerfreier Ziele unter diesem Wert liegt, markieren Sie die Zone als fehlerhaft inDNS, sodass der Verkehr nur in fehlerfreie Zonen geleitet wird. Die möglichen Werte sind off oder eine Ganzzahl von 1 bis 100. Wenn off DNS Failaway deaktiviert ist, d. h. selbst wenn alle Ziele in der Zielgruppe fehlerhaft sind, wird die Zone nicht aus der Zone entfernt. DNS Der Standardwert ist off.

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 off oder eine Ganzzahl von 1 bis 100. Der Standardwert ist off.

target_health_state.unhealthy.connection_termination.enabled

Gibt an, ob der Load Balancer Verbindungen mit fehlerhaften Zielen beendet. Der Wert ist entweder true oder false. Der Standardwert ist true.

target_health_state.unhealthy.draining_interval_seconds

Die Wartezeit von Elastic Load Balancing, bevor der Status eines fehlerhaften Ziels von unhealthy.draining zu unhealthy geä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.enabled es 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:

• DNSFailover — Wenn die fehlerfreien Ziele in einer Zone unter den Schwellenwert fallen, markieren wir die IP-Adressen des Load Balancer-Knotens für die Zone in als fehlerhaft. DNS 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 das DNS Failover größer oder gleich dem Schwellenwert für das Routing-Failover sein, sodass das Failover entweder mit oder vor dem DNS 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 Hostnamen für den Load Balancer. DNS Der lokale DNS Client-Cache kann diese IP-Adressen jedoch so lange enthalten, bis das time-to-live (TTL) im DNS Datensatz 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, leitet der Load Balancer Traffic an alle Zonen weiter, auch an die fehlerhaften Zonen.

• Neben der Frage, ob es genügend fehlerfreie Ziele gibt, die zu einem DNS Failover führen könnten, gibt es noch andere Faktoren, wie 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:

  • DNSAusfallsicherung: 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:

  • DNSFailover — Availability Zone B ist in als fehlerhaft markiert. DNS 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 Sie Route DNS 53-Failover für Ihren Load Balancer

Wenn Sie Route 53 verwenden, um DNS Abfragen an Ihren Load Balancer weiterzuleiten, können Sie den DNS Failover für Ihren Load Balancer auch mithilfe von Route 53 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 Ihre primären und sekundären (Backup-) Load Balancer angeben. 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 Yes festgelegt ist, wertet Route 53 die Integrität der durch den alias 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 Configuring DNS Failover im Amazon Route 53 Developer Guide.