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.

Beheben von Problemen mit Ihrem Network Load Balancer

Die folgenden Informationen können Ihnen helfen, Probleme bei Ihren Network Load Balancern zu beheben.

Ein registriertes Ziel ist nicht in Betrieb

Wenn es länger als erwartet dauert, bis ein Ziel den Zustand InService aufweist, besteht es möglicherweise Zustandsprüfungen nicht. Ihr Ziel ist erst betriebsbereit, wenn es eine Zustandsprüfung besteht. Weitere Informationen finden Sie unter Gesundheitschecks für Network Load Balancer Balancer-Zielgruppen.

Überprüfen Sie, ob Ihre Instance Zustandsprüfungen nicht besteht und prüfen Sie dann Folgendes:

Anfragen werden nicht an Ziele weitergeleitet.

Überprüfen Sie Folgendes:

Ziele erhalten mehr Zustandsprüfungsanfragen als erwartet.

Zustandsprüfungen für Network Load Balancers sind verteilt und verwenden einen Konsensmechanismus, um den Zustand des Ziels zu bestimmen. Daher erhalten Ziele mehr als die Anzahl der Zustandsprüfungen, die über die Einstellung HealthCheckIntervalSeconds konfiguriert wurden.

Ziele erhalten weniger Zustandsprüfungsanfragen als erwartet.

Überprüfen Sie, ob net.ipv4.tcp_tw_recycle aktiviert ist. Es ist bekannt, dass diese Einstellung Probleme mit Load Balancern verursachen kann. Die net.ipv4.tcp_tw_reuse-Einstellung wird als eine sicherere Alternative betrachtet.

Fehlerhafte Ziele erhalten Anfragen vom Load Balancer.

Dies tritt auf, wenn alle registrierten Ziele fehlerhaft sind. Wenn mindestens ein fehlerfreies registriertes Ziel vorhanden ist, leitet Ihr Network Load Balancer Anforderungen nur seine fehlerfreien registrierten Ziele weiter.

Wenn nur fehlerhafte registrierte Ziele vorhanden sind, leitet der Ihr Network Load Balancer Anforderungen an alle registrierten Ziele weiter, bekannt als Fail-open-Modus. Der Network Load Balancer tut dies, anstatt alle IP-Adressen aus dem DNS zu entfernen, wenn alle Ziele fehlerhaft sind und die jeweiligen Availability Zones kein fehlerfreies Ziel haben, an das Anforderungen gesendet werden können.

Am Ziel schlagen HTTP- oder HTTPS-Zustandsprüfungen aufgrund nicht übereinstimmender Host-Header fehl

Der HTTP-Host-Header in der Zustandsprüfungsanforderung enthält die IP-Adresse des Load Balancer-Knotens und des Listener-Ports anstelle der IP-Adresse des Ziels und des Zustandsprüfungs-Ports. Wenn Sie eingehende Anforderungen nach Host-Header zuweisen, müssen Sie sicherstellen, dass Zustandsprüfungen mit den HTTP-Host-Header übereinstimmen. Eine weitere Möglichkeit besteht darin, an einem anderen Port einen separaten HTTP-Dienst hinzuzufügen und die Zielgruppe so zu konfigurieren, dass sie stattdessen diesen Port für Zustandsprüfungen verwendet. Alternativ können Sie TCP-Zustandsprüfungen verwenden.

Einem Load Balancer konnte keine Sicherheitsgruppe zugeordnet werden

Wenn der Network Load Balancer ohne Sicherheitsgruppen erstellt wurde, kann er nach der Erstellung keine Sicherheitsgruppen unterstützen. Sie können eine Sicherheitsgruppe nur während der Erstellung einem Load Balancer oder einem vorhandenen Load Balancer zuordnen, der ursprünglich mit Sicherheitsgruppen erstellt wurde.

Es konnten nicht alle Sicherheitsgruppen entfernt werden

Wenn der Network Load Balancer mit Sicherheitsgruppen erstellt wurde, muss ihm jederzeit mindestens eine Sicherheitsgruppe zugeordnet sein. Sie können nicht alle Sicherheitsgruppen gleichzeitig aus dem Load Balancer entfernen.

Erhöhung der TCP_ELB_Reset_Count-Metrik

Für jede TCP-Anforderung, die ein Client über einen Network Load Balancer sendet, wird der Zustand dieser Verbindung nachverfolgt. Werden länger als die vorgegebene Leerlaufzeit weder vom Client noch vom Ziel Daten über die Verbindung gesendet, wird die Verbindung beendet. Wenn bis zum Ablauf des Leerlaufzeitlimits keine Daten von einem Client oder Ziel gesendet wurden, empfängt er ein TCP-RST-Paket, um anzugeben, dass die Verbindung nicht mehr gültig ist. Wenn ein Ziel fehlerhaft wird, sendet der Load Balancer außerdem ein TCP RST für Pakete, die auf den mit dem Ziel verknüpften Client-Verbindungen empfangen werden, es sei denn, das fehlerhafte Ziel veranlasst den Load Balancer zum Fail-Open.

Wenn Sie kurz vor oder kurz vor dem Anstieg der TCP_ELB_Reset_Count-Metrik einen Anstieg der UnhealthyHostCount-Metrik feststellen, wurden die TCP-RST-Pakete wahrscheinlich gesendet, weil das Ziel mit dem Fail begann, aber nicht als fehlerhaft markiert wurde. Wenn Sie einen dauerhaften Anstieg von TCP_ELB_Reset_Count feststellen, ohne dass Ziele als fehlerhaft markiert wurden, können Sie die VPC-Flow-Protokolle für Clients überprüfen, die Daten zu abgelaufenen Flows senden.

Verbindungen überschreiten bei Anfragen von einem Ziel an dessen Load Balancer das Zeitlimit.

Prüfen Sie, ob die IP-Erhaltung des Clients für Ihre Zielgruppe aktiviert ist. NAT-Loopback, auch bekannt als Hairpinning, wird nicht unterstützt, wenn die Client-IP-Erhaltung aktiviert ist. Wenn eine Instance ein Client eines Load Balancers ist, bei dem sie registriert ist, und die Client-IP-Erhaltung aktiviert ist, ist die Verbindung nur dann erfolgreich, wenn die Anfrage an eine andere Instance weitergeleitet wird. Wenn die Anfrage an dieselbe Instance weitergeleitet wird, von der sie gesendet wurde, tritt bei der Verbindung ein Timeout auf, da die Quell- und Ziel-IP-Adressen identisch sind.

Wenn eine Instance Anfragen an einen Load Balancer senden muss, mit dem sie registriert ist, führen Sie einen der folgenden Schritte aus:

Die Leistung nimmt beim Verschieben von Zielen an einen Network Load Balancer ab.

Sowohl Classic Load Balancers als auch Application Load Balancers verwenden Verbindungsmultiplexing, Network Load Balancers jedoch nicht. Aus diesem Grund können Ihre Ziele mehr TCP-Verbindungen hinter einem Network Load Balancer erhalten. Stellen Sie sicher, dass Ihre Ziele bereit sind, die Menge der Verbindungsanforderungen zu verarbeiten, die sie erhalten könnten.

Fehler bei der Portzuweisung beim Herstellen der Verbindung AWS PrivateLink

Wenn Ihr Network Load Balancer einem VPC-Endpunktservice zugeordnet ist, unterstützt er 55 000 gleichzeitige Verbindungen oder um die 55 000 Verbindungen pro Minute für jedes Ziel (IP-Adresse und Port). Werden diese Verbindungen überschritten, steigt das Risiko von Port-Zuordnungsfehlern. Fehler bei der Portzuweisung können anhand der Metrik PortAllocationErrorCount verfolgt werden. Um Port-Zuordnungsfehler zu beheben, fügen Sie der Zielgruppe mehr Ziele hinzu. Weitere Informationen finden Sie unter CloudWatch Metriken für Ihren Network Load Balancer.

Zeitweise auftretende Verbindungsausfälle, wenn die Client-IP-Erhaltung aktiviert ist

Wenn die Client-IP-Erhaltung aktiviert ist, kann es aufgrund der beobachteten Wiederverwendung von Sockets auf den Zielen zu Einschränkungen bei der TCP/IP-Verbindung kommen. Diese Verbindungseinschränkungen können auftreten, wenn ein Client oder ein NAT-Gerät vor dem Client dieselbe Quell-IP-Adresse und denselben Quellport verwendet, wenn eine Verbindung zu mehreren Load-Balancer-Knoten gleichzeitig hergestellt wird. Wenn der Load Balancer diese Verbindungen an dasselbe Ziel weiterleitet, erscheinen die Verbindungen für das Ziel so, als kämen sie von demselben Quell-Socket, was zu Verbindungsfehlern führt. In diesem Fall können die Clients es erneut versuchen (wenn die Verbindung fehlschlägt) oder erneut eine Verbindung herstellen (wenn die Verbindung unterbrochen wird). Sie können diese Art von Verbindungsfehlern reduzieren, indem Sie die Anzahl der kurzlebigen Quellports oder die Anzahl der Ziele für den Load Balancer erhöhen. Sie können diese Art von Verbindungsfehlern verhindern, indem Sie die Client-IP-Erhaltung oder das zonenübergreifende Load Balancing deaktivieren.

Wenn die Client-IP-Erhaltung aktiviert ist, schlägt die Konnektivität möglicherweise fehl, wenn die Clients, die eine Verbindung zum Network Load Balancer herstellen, auch mit Zielen hinter dem Load Balancer verbunden sind. Um dieses Problem zu lösen, können Sie die Client-IP-Erhaltung für die betroffenen Zielgruppen deaktivieren. Alternativ können Sie Ihre Clients nur mit dem Network Load Balancer oder nur mit den Zielen verbinden, aber nicht mit beiden.

TCP-Verbindungsverzögerungen

Wenn sowohl zonenübergreifendes Load Balancing als auch Client-IP-Erhaltung aktiviert sind, kann ein Client, der eine Verbindung zu verschiedenen IPs auf demselben Load Balancer herstellt, an dasselbe Ziel weitergeleitet werden. Wenn der Client für beide Verbindungen denselben Quellport verwendet, erhält das Ziel eine scheinbar doppelte Verbindung, was zu Verbindungsfehlern und TCP-Verzögerungen beim Aufbau neuer Verbindungen führen kann. Sie können diese Art von Verbindungsfehlern verhindern, indem Sie das zonenübergreifende Load Balancing deaktivieren. Weitere Informationen finden Sie unter Zonenübergreifendes Load Balancing.

Möglicher Fehler bei der Bereitstellung des Load Balancers

Einer der Gründe, warum ein Network Load Balancer bei der Bereitstellung ausfallen könnte, ist, wenn Sie eine IP-Adresse verwenden, die bereits an anderer Stelle zugewiesen wurde (z. B. als sekundäre IP-Adresse für eine EC2-Instance zugewiesen). Diese IP-Adresse verhindert, dass der Load Balancer eingerichtet wird, und sein Zustand ist failed. Sie können dieses Problem lösen, indem Sie die Zuordnung der zugehörigen IP-Adresse aufheben und den Erstellungsvorgang erneut versuchen.

Die DNS-Namensauflösung enthält weniger IP-Adressen als aktivierte Availability Zones

Idealerweise stellt Ihr Network Load Balancer eine IP-Adresse pro aktivierter Availability Zone bereit, wenn mindestens ein fehlerfreier Host in der Availability Zone vorhanden ist. Wenn es in einer bestimmten Availability Zone keinen fehlerfreien Host gibt und das zonenübergreifende Load Balancing deaktiviert ist, wird die IP-Adresse des Network Load Balancer für diese AZ aus dem DNS entfernt.

Nehmen wir zum Beispiel an, Ihr Network Load Balancer hat drei Availability Zones aktiviert, die alle mindestens eine fehlerfreie registrierte Ziel-Instance haben.

Beheben Sie fehlerhafte Ziele mithilfe der Ressourcenübersicht

Wenn Ihre Network Load Balancer Balancer-Ziele die Integritätsprüfungen nicht bestehen, können Sie die Ressourcenübersicht verwenden, um fehlerhafte Ziele zu finden und auf der Grundlage des Fehlerursachencodes Maßnahmen zu ergreifen. Weitere Informationen finden Sie unter Sehen Sie sich die Network Load Balancer Balancer-Ressourcenübersicht an.

Die Ressourcenübersicht bietet zwei Ansichten: Übersicht und Karte mit fehlerhaften Zielen. Overview ist standardmäßig ausgewählt und zeigt alle Ressourcen Ihres Load Balancers an. Wenn Sie die Ansicht Unhealthy Target Map auswählen, werden nur die fehlerhaften Ziele in jeder Zielgruppe angezeigt, die dem Network Load Balancer zugeordnet ist.

In der Spalte Zielgruppen wird eine Zusammenfassung der gesunden und ungesunden Ziele für jede Zielgruppe angezeigt. Auf diese Weise kann festgestellt werden, ob alle Ziele die Zustandsprüfungen nicht bestehen oder nur bestimmte Ziele nicht bestehen. Wenn alle Ziele in einer Zielgruppe die Gesundheitschecks nicht bestehen, überprüfen Sie die Einstellungen für die Gesundheitsprüfung der Zielgruppe. Wählen Sie den Namen einer Zielgruppe aus, um deren Detailseite in einem neuen Tab zu öffnen.

In der Spalte Ziele werden die TargetID und der aktuelle Status der Integritätsprüfung für jedes Ziel angezeigt. Wenn ein Ziel fehlerhaft ist, wird der Code für die Ursache des Fehlers bei der Integritätsprüfung angezeigt. Wenn ein einzelnes Ziel eine Integritätsprüfung nicht besteht, stellen Sie sicher, dass das Ziel über ausreichende Ressourcen verfügt. Wählen Sie die ID eines Ziels aus, um die zugehörige Detailseite in einer neuen Registerkarte zu öffnen.

Wenn Sie Exportieren auswählen, haben Sie die Möglichkeit, die aktuelle Ansicht der Ressourcenübersicht Ihres Network Load Balancers als PDF zu exportieren.

Stellen Sie sicher, dass Ihre Instance die Integritätsprüfungen nicht besteht, und überprüfen Sie dann anhand des Fehlerursachencodes auf die folgenden Probleme: