View a markdown version of this page

Network Load Balancers - Elastic Load Balancing
Load Balancer-StatusIP-AdresstypZeitlimit für VerbindungsleerlaufLoad Balancer-AttributeCross-zone LastenausgleichDNS-NameZonaler Zustand des Load Balancers

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.

Network Load Balancers

Ein Network Load Balancer dient als zentrale Anlaufstelle für Kunden. Clients senden Anfragen an den Network Load Balancer, und der Network Load Balancer sendet sie an Ziele wie EC2-Instances in einer oder mehreren Availability Zones.

Um Ihren Network Load Balancer zu konfigurieren, erstellen Sie Zielgruppen und registrieren dann Ziele bei Ihren Zielgruppen. Ihr Network Load Balancer ist am effektivsten, wenn Sie sicherstellen, dass jede aktivierte Availability Zone mindestens ein registriertes Ziel hat. Außerdem erzeugen Sie Listener für Verbindungsanforderungen von Clients und Listener-Regeln zum Weiterleiten von Anforderungen von Clients an Ziele in Ihren Zielgruppen.

Network Load Balancer unterstützen Verbindungen von Clients über VPC-Peering, AWS verwaltetes VPN und VPN-Lösungen von Direct Connect Drittanbietern.

Inhalt

Load Balancer-Status

Ein Network Load Balancer kann sich in einem der folgenden Zustände befinden:

provisioning

Der Network Load Balancer wird gerade eingerichtet.

active

Der Network Load Balancer ist vollständig eingerichtet und bereit, den Datenverkehr weiterzuleiten.

failed

Der Network Load Balancer konnte nicht eingerichtet werden.

IP-Adresstyp

Sie können die Arten von IP-Adressen festlegen, die Clients mit Ihrem Network Load Balancer verwenden können.

Network Load Balancer unterstützen die folgenden IP-Adresstypen:

ipv4

Clients müssen eine Verbindung über IPv4-Adressen herstellen (z. B. 192.0.2.1).

dualstack

Clients können sich sowohl über IPv4-Adressen (z. B. 192.0.2.1) als auch über IPv6-Adressen (z. B. 2001:0 db 8:85 a 3:0:0:8 a2e: 0370:7334) mit dem Network Load Balancer verbinden.

Überlegungen

  • Der Network Load Balancer kommuniziert mit Zielen auf der Grundlage des IP-Adresstyps der Zielgruppe.

  • Um die Quell-IP-Erhaltung für UDP-IPv6-Listener zu unterstützen, stellen Sie sicher, dass Präfix für IPv6-Quell-NAT aktivieren aktiviert ist.

  • Wenn Sie den Dualstack-Modus für den Network Load Balancer aktivieren, stellt Elastic Load Balancing einen AAAA-DNS-Eintrag für den Network Load Balancer bereit. Clients, die über IPv4-Adressen mit dem Network Load Balancer kommunizieren, lösen den A-DNS-Eintrag auf. Clients, die über IPv6-Adressen mit dem Network Load Balancer kommunizieren, lösen den AAAA-DNS-Eintrag auf.

  • Der Zugriff auf Ihren internen DualStack-Network Load Balancer über das Internet-Gateway ist blockiert, um unbeabsichtigten Internetzugang zu verhindern. Dies verhindert jedoch nicht den Zugriff auf andere Internetzugänge (z. B. durch Peering, Transit Gateway, oder). AWS Direct Connect Site-to-Site VPN

Weitere Informationen finden Sie unter Aktualisieren Sie die IP-Adresstypen für Ihren Network Load Balancer.

Zeitlimit für Verbindungsleerlauf

Für jede TCP-Anforderung, die ein Client über einen Network Load Balancer sendet, wird der Zustand dieser Verbindung nachverfolgt. Wenn weder vom Client noch vom Ziel länger als das Leerlauf-Timeout Daten über die Verbindung gesendet werden, wird die Verbindung nicht mehr getrackt. Wenn ein Client oder ein Ziel Daten sendet, nachdem das Leerlauf-Timeout abgelaufen ist, erhält der Client ein TCP-RST-Paket, das darauf hinweist, dass die Verbindung nicht mehr gültig ist.

Der Standardwert für das Leerlauf-Timeout für TCP-Datenflüsse beträgt 350 Sekunden, kann aber auf einen beliebigen Wert zwischen 60 und 6000 Sekunden aktualisiert werden. Clients oder Ziele können TCP-Keepalive-Pakete verwenden, um das Leerlauf-Timeout neu zu starten. Keepalive-Pakete, die zur Aufrechterhaltung von TLS-Verbindungen gesendet werden, dürfen keine Daten oder Nutzlast enthalten.

Das Zeitlimit bei der ENI-Verbindungsverfolgung stimmt nicht überein

Wenn Sie einen TCP-Leerlauf-Timeout-Wert von mehr als 350 Sekunden konfigurieren, stellen Sie sicher, dass der ENI-Verbindungs-Timeout (TcpEstablishedTimeout) Ihrer Zielinstanzen auf einen Wert gesetzt ist, der dem Network Load Balancer-Leerlauf-Timeout entspricht oder größer ist. Bei Nitro-Instances der sechsten Generation (Nitro V6+) beträgt das standardmäßige ENI-Timeout für die Verbindungsverfolgung 350 Sekunden. Wenn das Network Load Balancer-Leerlauf-Timeout das Verbindungs-Tracking-Timeout des Ziels überschreitet, kann die Netzwerkschnittstelle des Ziels den Verbindungsverfolgungseintrag löschen, während der Load Balancer die Verbindung immer noch als aktiv betrachtet, was dazu führt, dass Pakete auf der Verbindung verloren gehen. Sie können den Timeout für die Verbindungsverfolgung Ihres Ziels mithilfe von. ModifyNetworkInterfaceAttribute Weitere Informationen finden Sie unter Bewährte Methoden für die TCP-Verbindungsverwaltung auf EC2.

Das Leerlaufzeitlimit für TLS-Listener beträgt 350 Sekunden und kann nicht geändert werden. Wenn ein TLS-Listener ein TCP-Keepalive-Paket von einem Client oder einem Ziel empfängt, generiert der Load Balancer TCP-Keepalive-Pakete und sendet sie alle 20 Sekunden sowohl an die Front-End- als auch an die Back-End-Verbindungen. Sie können dieses Verhalten nicht ändern.

Während UDP verbindungslos ist, behält der Load Balancer den UDP-Datenstromstatus basierend auf den Quell- und Ziel-IP-Adressen und -Ports bei. Dadurch wird sichergestellt, dass Pakete, die zu demselben Flow gehören, konsistent an dasselbe Ziel gesendet werden. Nachdem der Timeoutwert für die Leerlaufzeit abgelaufen ist, betrachtet der Load Balancer das eingehende UDP-Paket als neuen Flow und leitet es an ein neues Ziel weiter. Elastic Load Balancing legt den Leerlauf-Timeout-Wert für UDP-Flows auf 120 Sekunden fest. Dies können nicht geändert werden.

EC2-Instances müssen innerhalb von 30 Sekunden auf eine neue Anforderung reagieren, um einen Antwortpfad bei Unzustellbarkeit einzurichten.

Weitere Informationen finden Sie unter Aktualisieren Sie den Timeout im Leerlauf.

Load Balancer-Attribute

Sie können Ihren Network Load Balancer konfigurieren, indem Sie seine Attribute bearbeiten. Weitere Informationen finden Sie unter Bearbeiten Sie die Load Balancer-Attribute.

Im Folgenden sind die Load Balancer-Attribute für Network Load Balancer aufgeführt:

access_logs.s3.enabled

Gibt an, ob in Amazon S3 gespeicherte Zugriffsprotokolle aktiviert sind. Der Standardwert ist false.

access_logs.s3.bucket

Der Name des Amazon-S3-Buckets für die Zugriffsprotokolle. Dieses Attribut ist erforderlich, wenn Zugriffsprotokolle aktiviert sind. Weitere Informationen finden Sie unter Bucket-Anforderungen.

access_logs.s3.prefix

Das Präfix für den Speicherort im Amazon-S3-Bucket.

deletion_protection.enabled

Gibt an, ob der Löschschutz aktiviert ist. Der Standardwert ist false.

ipv6.deny_all_igw_traffic

Blockiert den Internet-Gateway-Zugriff (IGW) auf den Network Load Balancer und verhindert so den unbeabsichtigten Zugriff auf Ihren internen Network Load Balancer über ein Internet-Gateway. Es ist auf für Network Load Balancer mit Internetzugriff und false für interne Network Load Balancer eingestellt. true Dieses Attribut verhindert nicht den Internetzugang, der nicht von IGW stammt (z. B. über Peering, Transit Gateway, oder). AWS Direct Connect Site-to-Site VPN

load_balancing.cross_zone.enabled

Gibt an, ob zonenübergreifendes Load Balancing aktiviert ist. Der Standardwert ist false.

dns_record.client_routing_policy

Gibt an, wie der Datenverkehr auf die Availability Zones des Network Load Balancers verteilt wird. Die möglichen Werte sind availability_zone_affinity bei 100 Prozent zonaler Affinität, partial_availability_zone_affinity bei 85 Prozent zonaler Affinität und any_availability_zone bei 0 Prozent zonaler Affinität.

secondary_ips.auto_assigned.per_subnet

Die Anzahl der zu konfigurierenden Sekundäre IP-Adressen sekundären IP-Adressen. Wird verwendet, um Fehler bei der Portzuweisung zu beheben, wenn Sie keine Ziele hinzufügen können. Der gültige Bereich liegt zwischen 0 und 7. Der Standardwert ist 0. Nachdem Sie diesen Wert festgelegt haben, können Sie ihn nicht mehr verringern.

zonal_shift.config.enabled

Gibt an, ob die Zonenverschiebung aktiviert ist. Der Standardwert ist false.

Cross-zone Lastenausgleich

Standardmäßig verteilt jeder Network Load Balancer-Knoten den Datenverkehr nur auf die registrierten Ziele in seiner Availability Zone. Wenn Sie den zonenübergreifenden Load Balancer-Knoten aktivieren, verteilt jeder Network Load Balancer-Knoten den Datenverkehr auf die registrierten Ziele in allen aktivierten Availability Zones. Sie können das zonenübergreifende Load Balancing auch auf Zielgruppenebene aktivieren. Weitere Informationen finden Sie unter Cross-zone Load Balancing für Zielgruppen und Cross-zone Load Balancing im Elastic Load Balancing-Benutzerhandbuch.

DNS-Name

Jeder Network Load Balancer erhält einen Standard-DNS-Namen (Domain Name System) mit der folgenden Syntax: name - id .elb. region.amazonaws.com. Beispiel: my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com.

Wenn Sie lieber einen DNS-Namen verwenden möchten, den Sie sich leichter merken können, können Sie einen benutzerdefinierten Domainnamen erstellen und ihn mit dem DNS-Namen für Ihren Network Load Balancer verknüpfen. Wenn ein Client eine Anfrage unter Verwendung dieses benutzerdefinierten Domainnamens stellt, löst der DNS-Server sie in den DNS-Namen für Ihren Network Load Balancer auf.

Registrieren Sie zunächst einen Domainnamen bei einer akkreditierten Domainnamenvergabestelle. Verwenden Sie als Nächstes Ihren DNS-Dienst, z. B. Ihren Domain-Registrar, um einen DNS-Eintrag zu erstellen, um Anfragen an Ihren Network Load Balancer weiterzuleiten. Weitere Informationen finden Sie in der Dokumentation zu Ihrem DNS-Service. Wenn Sie beispielsweise Amazon Route 53 als Ihren DNS-Service verwenden, erstellen Sie einen Alias-Datensatz, der auf Ihren Network Load Balancer verweist. Weitere Informationen finden Sie unter Weiterleiten von Datenverkehr an einen ELB Load Balancer im Entwicklerhandbuch von Amazon Route 53.

Der Network Load Balancer hat eine IP-Adresse pro aktivierter Availability Zone. Dies sind die IP-Adressen der Network Load Balancer-Knoten. Der DNS-Name des Network Load Balancers wird in diese Adressen aufgelöst. Nehmen wir zum Beispiel an, der benutzerdefinierte Domainname für Ihren Network Load Balancer lautet. example.networkloadbalancer.com Verwenden Sie den folgenden nslookup Befehl dig oder, um die IP-Adressen der Network Load Balancer-Knoten zu ermitteln.

Linux oder Mac

$ dig +short example.networkloadbalancer.com

Windows

C:\> nslookup example.networkloadbalancer.com

Der Network Load Balancer hat DNS-Einträge für seine Knoten. Sie können DNS-Namen mit der folgenden Syntax verwenden, um die IP-Adressen der Network Load Balancer-Knoten zu ermitteln:. az name- id .elb. region.amazonaws.com.

Linux oder Mac

$ dig +short us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com

Windows

C:\> nslookup us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com

Zonaler Zustand des Load Balancers

Network Load Balancer verfügen über zonale DNS-Einträge und IP-Adressen in Route 53 für jede aktivierte Verfügbarkeitszone. Wenn ein Network Load Balancer eine zonale Integritätsprüfung für eine bestimmte Availability Zone nicht besteht, wird sein DNS-Eintrag aus Route 53 entfernt. Der zonale Zustand des Load Balancers wird anhand der CloudWatch Amazon-Metrik überwacht. So erhalten Sie einen besseren Einblick in EreignisseZonalHealthStatus, die zu einem Fail-Away führen, sodass Sie präventive Maßnahmen ergreifen können, um eine optimale Anwendungsverfügbarkeit sicherzustellen. Weitere Informationen finden Sie unter Network Load Balancer-Metriken.

Network Load Balancer können zonale Zustandsprüfungen aus verschiedenen Gründen nicht bestehen, wodurch sie nicht mehr funktionieren. Im Folgenden finden Sie die häufigsten Ursachen für fehlerhafte Network Load Balancer, die durch fehlgeschlagene zonale Integritätsprüfungen verursacht werden.

Suchen Sie nach den folgenden möglichen Ursachen:

  • Es gibt keine fehlerfreien Ziele für den Load Balancer

  • Die Anzahl fehlerfreier Ziele liegt unter dem konfigurierten Minimum

  • Eine zonale Verschiebung oder eine zonale automatische Verschiebung ist im Gange

  • Aufgrund erkannter Probleme wird der Verkehr automatisch in gesunde Zonen verlagert