Beheben von Problemen mit Ihrem Network Load Balancer - Elastic Load Balancing

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 Zustandsprüfungen für Ihre Zielgruppen.

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

Eine Sicherheitsgruppe erlaubt keinen Datenverkehr

Die mit einer Instance verbundenen Sicherheitsgruppen müssen Datenverkehr vom Load Balancer über den Zustandsprüfungsport und das Zustandsprüfungsprotokoll zulassen. Weitere Informationen finden Sie unter Zielsicherheitsgruppen.

Eine Netzwerk-Zugriffskontrollliste (ACL) erlaubt keinen Datenverkehr

Die Netzwerk-ACL, die den Subnetzen für Ihre Instances und den Subnetzen für Ihren Load Balancer zugeordnet ist, muss Datenverkehr und Zustandsprüfungen durch den Load Balancer zulassen. Weitere Informationen finden Sie unter Netzwerk-ACLs.

Anfragen werden nicht an Ziele weitergeleitet.

Überprüfen Sie Folgendes:

Eine Sicherheitsgruppe erlaubt keinen Datenverkehr

Die den Instances zugeordneten Sicherheitsgruppen müssen den Datenverkehr auf dem Listener-Port von Client-IP-Adressen (falls Ziele nach Instance-ID angegeben sind) oder Load Balancer-Knoten (falls Ziele nach IP-Adresse angegeben sind) erlauben. Weitere Informationen finden Sie unter Zielsicherheitsgruppen.

Eine Netzwerk-Zugriffskontrollliste (ACL) erlaubt keinen Datenverkehr

Die den Subnetzen für Ihre VPC zugeordneten Netzwerk-ACLs müssen dem Load Balancer und den Zielen die Kommunikation in beide Richtungen auf dem Listener-Port erlauben. Weitere Informationen finden Sie unter Netzwerk-ACLs.

Die Ziele befinden sich in einer Availability Zone, die nicht aktiviert ist.

Wenn Sie Ziele in einer Availability Zone registrieren, aber die Availability Zone nicht aktivieren, erhalten diese registrierten Ziele keinen Datenverkehr vom Load Balancer.

Die Instance befindet sich in einer per Peering verbundenen VPC.

Wenn sich Instances in einer VPC befinden, die mit der Load Balancer-VPC per Peering verbunden ist, müssen Sie sie nach IP-Adresse und nicht nach Instance-ID bei Ihrem Load Balancer registrieren.

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:

  • Deaktivieren Sie die Erhaltung der Client-IP.

  • Stellen Sie sicher, dass sich Container, die kommunizieren müssen, in unterschiedlichen Container-Instances befinden.

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.

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.

  • Wenn die registrierten Ziel-Instances in Availability Zone A fehlerhaft werden, wird die entsprechende IP-Adresse der Availability Zone A für den Network Load Balancer aus dem DNS entfernt.

  • Wenn zwei der aktivierten Availability Zones keine fehlerfreien registrierten Ziel-Instances haben, werden die jeweiligen beiden IP-Adressen des Network Load Balancer aus dem DNS entfernt.

  • Wenn keine fehlerfreien registrierten Ziel-Instances in allen aktivierten Availability Zones vorhanden sind, ist der Fail-Open-Modus aktiviert und DNS stellt im Ergebnis alle IP-Adressen der drei aktivierten AZs bereit.

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 Network Load Balancer Balancer-Ressourcenübersicht.

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.

Anmerkung

Die Option „Ressourcendetails anzeigen“ muss aktiviert sein, damit die Zusammenfassung der Integritätsprüfung und die Fehlermeldungen für alle entsprechenden Ressourcen in der Ressourcenübersicht angezeigt werden können. Wenn diese Option nicht aktiviert ist, müssen Sie jede Ressource auswählen, um ihre Details anzuzeigen.

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:

  • Fehlerhaft: Das Zeitlimit für die Anfrage wurde überschritten

    • Stellen Sie sicher, dass die Sicherheitsgruppen und Network Access Control Lists (ACL), die Ihren Zielen und dem Network Load Balancer zugeordnet sind, die Konnektivität nicht blockieren.

    • Stellen Sie sicher, dass das Ziel über ausreichend Kapazität verfügt, um Verbindungen vom Network Load Balancer anzunehmen.

    • Die Antworten des Network Load Balancers auf die Systemdiagnose können in den Anwendungsprotokollen der einzelnen Ziele eingesehen werden. Weitere Informationen finden Sie unter Ursachencodes für Gesundheitschecks.

  • Ungesund: FailedHealthChecks

    • Stellen Sie sicher, dass das Ziel auf dem Health Check-Port auf Datenverkehr wartet.

      Bei Verwendung eines TLS-Listeners

      Sie wählen aus, welche Sicherheitsrichtlinie für Front-End-Verbindungen verwendet wird. Die für Back-End-Verbindungen verwendete Sicherheitsrichtlinie wird automatisch auf der Grundlage der verwendeten Front-End-Sicherheitsrichtlinie ausgewählt.

      • Wenn Ihr TLS-Listener eine TLS 1.3-Sicherheitsrichtlinie für Front-End-Verbindungen verwendet, wird die ELBSecurityPolicy-TLS13-1-0-2021-06 Sicherheitsrichtlinie für Back-End-Verbindungen verwendet.

      • Wenn Ihr TLS-Listener keine TLS 1.3-Sicherheitsrichtlinie für Front-End-Verbindungen verwendet, wird die ELBSecurityPolicy-2016-08 Sicherheitsrichtlinie für Back-End-Verbindungen verwendet.

      Weitere Informationen finden Sie unter Sicherheitsrichtlinien.

    • Stellen Sie sicher, dass das Ziel ein Serverzertifikat und einen Schlüssel im richtigen Format bereitstellt, das in der Sicherheitsrichtlinie angegeben ist.

    • Stellen Sie sicher, dass das Ziel eine oder mehrere übereinstimmende Chiffren und ein vom Network Load Balancer bereitgestelltes Protokoll zur Einrichtung von TLS-Handshakes unterstützt.