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.

Zielgruppenattribute für Ihren Network Load Balancer bearbeiten

Nachdem Sie eine Zielgruppe für Ihren Network Load Balancer erstellt haben, können Sie deren Zielgruppenattribute bearbeiten.

Client-IP-Erhaltung

Network Load Balancers können die Quell-IP-Adresse von Clients beibehalten, wenn Anforderungen an Back-End-Ziele weitergeleitet werden. Wenn Sie die Client-IP-Erhaltung deaktivieren, ist die Quell-IP-Adresse die private IP-Adresse des Network Load Balancer.

Standardmäßig ist die Client-IP-Erhaltung für Instance- und IP-Typ-Zielgruppen mit den UDP Protokollen und TCP _ aktiviert (UDPund kann nicht deaktiviert werden). Sie können jedoch die Client-IP-Erhaltung für TCP Zielgruppen mithilfe des TLS preserve_client_ip.enabled Zielgruppenattributs aktivieren oder deaktivieren.

Um die Client-IP-Erhaltung zu aktivieren oder zu deaktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem preserve_client_ip.enabled Attribut.

Verwenden Sie z. B. den folgenden Befehl, um die Client-IP-Erhaltung zu deaktivieren.

aws elbv2 modify-target-group-attributes --attributes Key=preserve_client_ip.enabled,Value=false --target-group-arn ARN

Die Ausgabe sollte in etwa wie folgt aussehen.

{
    "Attributes": [
      {
        "Key": "proxy_protocol_v2.enabled", 
        "Value": "false"
      }, 
      {
        "Key": "preserve_client_ip.enabled", 
        "Value": "false" 
      },
      {
        "Key": "deregistration_delay.timeout_seconds", 
        "Value": "300"
      } 
    ]
}

Verzögerung der Registrierungsaufhebung

Wenn die Registrierung eines Ziels aufgehoben wird, stellt der Load Balancer keine neuen Verbindungen zum Ziel her. Der Load Balancer stellt mit Connection Draining sicher, dass in Übertragung befindlicher Datenverkehr auf den vorhandenen Verbindungen abgeschlossen wird. Wenn das Ziel mit aufgehobener Registrierung fehlerfrei bleibt und sich eine vorhandene Verbindung nicht im Leerlauf befindet, kann der Load Balancer mit dem Senden von Datenverkehr an das Ziel fortfahren. Um sicherzustellen, dass bestehende Verbindungen geschlossen werden, können Sie eine der folgenden Maßnahmen ergreifen: Aktivieren Sie das Zielgruppenattribut für die Beendigung von Verbindungen, stellen Sie sicher, dass die Instance fehlerbehaftet ist, bevor Sie sie deregistrieren, oder schließen Sie regelmäßig Client-Verbindungen.

Der Ausgangszustand eines Ziels, dessen Registrierung aufgehoben wirddraining, ist, dass das Ziel keine neuen Verbindungen mehr empfängt. Aufgrund von Verzögerungen bei der Übertragung der Konfiguration kann das Ziel jedoch weiterhin Verbindungen empfangen. Standardmäßig ändert der Load Balancer den Status eines Ziels, dessen Registrierung aufgehoben wird, nach 300 Sekunden in unused. Wenn Sie die Zeitspanne ändern möchten, die der Load Balancer wartet, bevor er den Status eines Ziels, dessen Registrierung aufgehoben wird, in unused ändert, aktualisieren Sie den Wert für die Verzögerung der Registrierungsaufhebung. Wir empfehlen, einen Wert von mindestens 120 Sekunden anzugeben, um sicherzustellen, dass die Anfragen abgeschlossen sind.

Wenn Sie das Zielgruppenattribut für den Verbindungsabbruch aktivieren, werden Verbindungen zu abgemeldeten Zielen kurz nach Ablauf des Abmelde-Timeouts geschlossen.

Um die Abmelde-Attribute zu aktualisieren, verwenden Sie AWS CLI

Verwenden Sie den Befehl modify-target-group-attributes.

Proxy-Protokoll

Network Load Balancers verwenden die Proxy-Protokoll-Version 2 zum Senden zusätzlicher Verbindungsinformationen, z. B. Quell- und Zieladresse. Proxy-Protokoll-Version 2 bietet eine binäre Codierung des Proxy-Protokoll-Headers. Bei TCP Listenern stellt der Load Balancer den Daten einen Proxyprotokoll-Header voran. TCP Es werden keine vorhandenen Daten verworfen oder überschreiben, auch keine eingehenden, vom Client gesendeten Proxy-Protokoll-Header oder andere Proxys, Load Balancers oder Server im Netzwerkpfad. Deshalb kann mehr als ein Proxy-Protokoll-Header empfangen werden. Wenn außerdem ein anderer Netzwerkpfad zu Ihren Zielen Ihres Network Load Balancer führt, ist der erste Proxy-Protokoll-Header nicht unbedingt der Ihres Network Load Balancer.

Wenn Sie Ziele nach IP-Adressen angeben, hängen die Quell-IP-Adressen, die Ihren Anwendungen zur Verfügung gestellt werden, wie folgt vom Protokoll der Zielgruppe ab:

Wenn Sie Ziele unter Verwendung der Instance-ID angeben, sind die für Ihre Anwendungen bereitgestellten Quell-IP-Adressen die Client-IP-Adressen. Wenn Sie dies bevorzugen, können Sie jedoch auch das Proxy-Protokoll aktivieren und die Client-IP-Adressen aus dem Proxy-Protokoll-Header abrufen.

Zustandsprüfungsverbindungen

Nachdem Sie das Proxy-Protokoll aktiviert haben, ist der Proxy-Protokoll-Header auch in Zustandsprüfungsverbindungen vom Load Balancer enthalten. Bei Zustandsprüfungsverbindungen werden die Client-Verbindungsinformationen jedoch nicht im Proxy-Protokoll-Header gesendet.

VPCEndpunktdienste

Bei Datenverkehr, der von Servicenutzern über einen VPCEndpunktdienst kommt, sind die Quell-IP-Adressen, die Ihren Anwendungen zur Verfügung gestellt werden, die privaten IP-Adressen der Load Balancer-Knoten. Wenn Ihre Anwendungen die IP-Adressen der Servicenutzer benötigen, aktivieren Sie das Proxy-Protokoll und rufen Sie sie aus dem Proxy-Protokoll-Header ab.

Der Proxy-Protokoll-Header enthält außerdem die ID des Endpunkts. Diese Informationen werden mithilfe eines benutzerdefinierten Vektors Type-Length-Value (TLV) wie folgt codiert.

Ein Beispiel, das den TLV Typ 0xEA analysiert, finden Sie unter /tree/master/proprot. https://github.com/aws/ elastic-load-balancing-tools

Aktivierung des Proxy-Protokolls

Bevor Sie das Proxy-Protokoll bei einer Zielgruppe aktivieren, stellen Sie sicher, dass Ihre Anwendungen den Proxy-Protokoll-Header Version 2 erwarten und parsen können, da die Aktion andernfalls fehlschlagen kann. Weitere Informationen finden Sie in den Protokollversionen 1 und 2. PROXY

Um das Proxy-Protokoll v2 zu aktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl.

Sticky Sessions

Sticky Sessions sind ein Mechanismus, um Clientdatenverkehr an dasselbe Ziel in einer Zielgruppe weiterzuleiten. Dies ist nützlich für Server, die Zustandsinformationen verwalten, um Clients eine kontinuierliche Erfahrung zu bieten.

Um Sticky Sessions zu aktivieren, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem stickiness.enabled Attribut.

Zonenübergreifendes Load Balancing für Zielgruppen

Die Knoten für Ihren Load Balancer verteilen Anforderungen von Clients auf registrierte Ziele. Wenn zonenübergreifendes Load Balancing aktiviert ist, verteilt jeder Load Balancer-Knoten den Datenverkehr gleichmäßig auf die registrierten Ziele in allen registrierten Availability Zones. Wenn zonenübergreifendes Load Balancing deaktiviert ist, verteilt jeder Load Balancer-Knoten den Datenverkehr gleichmäßig nur auf die registrierten Ziele in seiner Availability Zone. Dies könnte verwendet werden, wenn zonale Ausfalldomains regionalen vorzuziehen sind, um sicherzustellen, dass eine fehlerfreie Zone nicht von einer fehlerhaften Zone beeinträchtigt wird, oder um die allgemeine Latenz zu verbessern.

Bei Network Load Balancers ist der zonenübergreifende Load Balancing auf Load-Balancer-Ebene standardmäßig deaktiviert, Sie können ihn jedoch jederzeit aktivieren. Für Zielgruppen wird standardmäßig die Load-Balancer-Einstellung verwendet. Sie können die Standardeinstellung jedoch überschreiben, indem Sie den zonenübergreifenden Load Balancing auf Zielgruppenebene explizit ein- oder ausschalten.

Ändern des zonenübergreifenden Load Balancing für einen Load Balancer

Sie können die Option „Zonenübergreifendes Load Balancing“ jederzeit für Ihren Load Balancer deaktivieren.

Um den zonenübergreifenden Load Balancing für Ihren Load Balancer zu ändern, verwenden Sie AWS CLI

Verwenden Sie den modify-load-balancer-attributesBefehl mit dem load_balancing.cross_zone.enabled Attribut.

Zonenübergreifendes Load Balancing für eine Zielgruppe

Die Einstellung für den zonenübergreifenden Load Balancing auf Zielgruppenebene hat Vorrang vor der Einstellung auf Load-Balancer-Ebene.

Sie können das zonenübergreifende Load Balancing auf Zielgruppenebene ein- oder ausschalten, wenn der Zielgruppentyp instance oder ip ist. Wenn der Zielgruppentyp alb ist, erbt die Zielgruppe immer die Einstellung für das zonenübergreifende Load Balancing vom Load Balancer.

Um den zonenübergreifenden Lastenausgleich für eine Zielgruppe zu ändern, verwenden Sie den AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem load_balancing.cross_zone.enabled Attribut.

Verbindungsabbruch für fehlerhafte Ziele

Der Verbindungsabbruch ist standardmäßig aktiviert. Wenn das Ziel eines Network Load Balancer die konfigurierten Integritätsprüfungen nicht besteht und als fehlerhaft eingestuft wird, beendet der Load Balancer bestehende Verbindungen und beendet das Routing neuer Verbindungen zum Ziel. Wenn der Verbindungsabbruch deaktiviert ist, gilt das Ziel immer noch als fehlerhaft und empfängt keine neuen Verbindungen. Etablierte Verbindungen bleiben jedoch aktiv, sodass sie problemlos geschlossen werden können.

Der Verbindungsabbruch für fehlerhafte Ziele kann für jede Zielgruppe individuell festgelegt werden.

Um die Einstellung für den Verbindungsabbruch zu ändern, verwenden Sie AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem target_health_state.unhealthy.connection_termination.enabled Attribut.

Ungesundes Entleerungsintervall

Ziele in diesem unhealthy.draining Status gelten als fehlerhaft, empfangen keine neuen Verbindungen, behalten aber bestehende Verbindungen für das konfigurierte Intervall bei. Das Verbindungsintervall für fehlerhafte Verbindungen bestimmt, wie lange das Ziel in dem Status verbleibt, bevor er in den unhealthy.draining Status wechselt. unhealthy Wenn das Ziel während des Verbindungsintervalls für fehlerhafte Verbindungen die Zustandsprüfungen bestanden hat, wird healthy sein Status erneut geändert. Wenn eine Abmeldung ausgelöst wird, wird der Status des Ziels geändert draining und das Zeitlimit für die Abmeldeverzögerung beginnt.

Das Intervall für ungesunde Entleerungen kann für jede Zielgruppe individuell festgelegt werden.

Um das Intervall für fehlerhafte Entleerungen zu ändern, verwenden Sie den AWS CLI

Verwenden Sie den modify-target-group-attributesBefehl mit dem target_health_state.unhealthy.draining_interval_seconds Attribut.