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. # Zustandsprüfungen für Zielgruppen von Network Load Balancer Sie können Ihre Ziele bei einer oder mehreren Zielgruppen registrieren. Der Load Balancer leitet Anfragen an ein neu registriertes Ziel weiter, sobald der Registrierungsprozess abgeschlossen ist und die Ziele die ersten Zustandsprüfungen bestanden haben. Es kann einige Minuten dauern, bis der Registrierungsvorgang abgeschlossen ist und die Zustandsprüfungen gestartet werden. Network Load Balancers verwenden aktive und passive Zustandsprüfungen, um zu ermitteln, ob ein Ziel für die Verarbeitung von Anforderungen verfügbar ist. Standardmäßig leitet jeder Load Balancer-Knoten Anfragen nur an störungsfreie Ziele in seiner Availability Zone weiter. Wenn das zonenübergreifende Load Balancing aktiviert ist, leitet jeder Load Balancer-Knoten Anforderungen an störungsfreie Ziele in allen aktivierten Availability Zones weiter. Weitere Informationen finden Sie unter [Zonenübergreifendes Load Balancing](network-load-balancers.md#cross-zone-load-balancing). Mit passiven Zustandsprüfungen beobachtet der Load Balancer, wie Ziele auf Verbindungen reagieren. Passive Zustandsprüfungen ermöglichen dem Load Balancer, ein fehlerhaftes Ziel zu erkennen, bevor es von den aktiven Zustandsprüfungen als fehlerhaft gemeldet wird. Sie können passive Zustandsprüfungen nicht deaktivieren, konfigurieren oder überwachen. Passive Zustandsprüfungen werden für UDP-Verkehr und Zielgruppen mit aktivierter Sperrfunktion nicht unterstützt. Weitere Informationen finden Sie unter [Sticky Sessions](edit-target-group-attributes.md#sticky-sessions). Wenn ein Ziel fehlerhaft wird, sendet der Load Balancer 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 Zielgruppen in einer aktivierten Availability Zone kein fehlerfreies Ziel haben, entfernen wir die IP-Adresse für das entsprechende Subnetz vom DNS, so dass in dieser Availability Zone keine Anfragen an Ziele weitergeleitet werden können. Beim Load Balancer erfolgt ein Fail-Open, wenn alle Ziele gleichzeitig die Zustandsprüfungen in allen aktivierten Availability Zones nicht bestehen. Network Load Balancers können auch nicht geöffnet werden, wenn Sie eine leere Zielgruppe haben. Der Effekt des Fail-Open ist, dass der Datenverkehr zu allen Zielen in allen aktivierten Availability Zones zugelassen wird, unabhängig von ihrem Zustand. Wenn eine Zielgruppe mit HTTPS-Zustandsprüfungen konfiguriert ist, schlagen ihre registrierten Ziele Zustandsprüfungen fehl, wenn sie nur TLS 1.3 unterstützen. Diese Ziele müssen eine frühere Version von TLS unterstützen, z. B. TLS 1.2. Bei HTTP- oder HTTPS-Zustandsprüfungsanforderungen enthält der Host-Header anstelle der IP-Adresse des Ziels und des Zustandsprüfungs-Ports die IP-Adresse des Load Balancer-Knotens und des Listener-Ports. Wenn Sie Ihrem Network Load Balancer einen TLS-Listener hinzufügen, führen wir einen Test der Listener-Konnektivität durch. Da das Beenden von TLS auch eine TCP-Verbindung beendet, wird eine neue TCP-Verbindung zwischen Ihrem Load Balancer und Ihren Zielen hergestellt. Daher werden die TCP-Verbindungen für diesen Test möglicherweise von Ihrem Load Balancer an die Ziele gesendet, die bei Ihrem TLS-Listener registriert sind. Sie können diese TCP-Verbindungen identifizieren, da sie die Quell-IP-Adresse Ihres Network Load Balancer haben und die Verbindungen keine Datenpakete enthalten. Bei UDP- und QUIC-Diensten kann die Zielverfügbarkeit mithilfe von Zustandsprüfungen, die nicht auf UDP basieren, an Ihrer Zielgruppe getestet werden. Sie können jede verfügbare Zustandsprüfung (TCP, HTTP oder HTTPS) und jeden Port auf Ihrem Ziel verwenden, um die Verfügbarkeit Ihres Dienstes zu überprüfen. Wenn der Service, der die Zustandsprüfung empfängt, fehlschlägt, wird Ihr Ziel als nicht verfügbar betrachtet. Um die Genauigkeit der Zustandsprüfungen für Ihren Dienst zu verbessern, konfigurieren Sie den Dienst, der den Health Check-Port überwacht, so, dass er den Status Ihres UDP- oder QUIC-Dienstes verfolgt und die Zustandsprüfung nicht besteht, wenn der Dienst nicht verfügbar ist. Weitere Informationen finden Sie unter [Zustand der Zielgruppe](load-balancer-target-groups.md#target-group-health). **Topics** + [Zustandsprüfungseinstellungen](#health-check-settings) + [Zustandsstatus des Ziels](#target-health-states) + [Ursachencodes für Zustandsprüfungen](#target-health-reason-codes) + [Überprüfen Sie den Zustand Ihres Ziels](check-target-health.md) + [Aktualisieren Sie die Einstellungen für die Integritätsprüfung](modify-health-check-settings.md) ## Zustandsprüfungseinstellungen Sie können aktive Zustandsprüfungen für die Ziele in einer Zielgruppe mit den folgenden Einstellungen konfigurieren. Wenn die Integritätsprüfungen **UnhealthyThresholdCount**aufeinanderfolgende Fehler überschreiten, nimmt der Load Balancer das Ziel außer Betrieb. Wenn die Zustandsprüfungen **HealthyThresholdCount**aufeinanderfolgende Erfolge überschreiten, nimmt der Load Balancer das Ziel wieder in Betrieb. | Einstellung | Description | Standard | | --- | --- | --- | | **HealthCheckProtocol** | Das Protokoll, das der Load Balancer für die Zustandsprüfungen der Ziele verwendet. Möglichen Protokolle sind HTTP, HTTPS und TCP. Das Standardprotokoll ist TCP. Wenn der Zieltyp `alb` ist, sind die unterstützten Zustandsprüfungsprotokolle HTTP und HTTPS. | TCP | | **HealthCheckPort** | Der Port, den der Load Balancer für die Zustandsprüfungen der Ziele verwendet. Standardmäßig wird der Port verwendet, auf dem jedes Ziel Datenverkehr vom Load Balancer empfängt. | Port, auf dem jedes Ziel Datenverkehr vom Load Balancer empfängt. | | **HealthCheckPath** | [HTTP/HTTPS-Zustandsprüfungen] Der Pfad zur Integritätsprüfung, der das Ziel auf den Zielen für Zustandsprüfungen ist. Der Standardwert ist /. | / | | **HealthCheckTimeoutSeconds** | Die Anzahl der Sekunden, in denen keine Antwort von einem Ziel bedeutet, dass die Zustandsprüfung fehlgeschlagen ist. Der Bereich liegt zwischen 2 und 120 Sekunden. Die Standardwerte sind 6 Sekunden für HTTP- und 10 Sekunden für TCP- und HTTPS-Zustandsprüfungen. | 6 Sekunden für HTTP- und 10 Sekunden für TCP- und HTTPS-Zustandsprüfungen. | | **HealthCheckIntervalSeconds** | Der etwaige Zeitraum in Sekunden zwischen den Zustandsprüfungen der einzelnen Ziele. Der Bereich liegt zwischen 5 und 300 Sekunden. Standardmäßig ist ein Zeitraum von 30 Sekunden festgelegt. 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 konfigurierte Anzahl von Zustandsprüfungen. Wenn Sie die Auswirkungen auf Ihre Ziele bei HTTP-Zustandsprüfungen reduzieren möchten, verwenden Sie ein einfacheres Ziel bei den Zielen, z. B. eine statische HTML-Datei, oder wechseln Sie zu TCP-Zustandsprüfungen. | 30 Sekunden | | **HealthyThresholdCount** | Die Anzahl der aufeinanderfolgenden erfolgreichen Zustandsprüfungen, die erforderlich ist, damit ein fehlerhaftes Ziel als stabil eingestuft wird. Der Bereich liegt zwischen 2 und 10. Der Standardwert ist 5. | 5 | | **UnhealthyThresholdCount** | Die Anzahl fortlaufender fehlgeschlagener Zustandsprüfungen, die erforderlich ist, damit ein Ziel als nicht betriebsbereit eingestuft wird. Der Bereich liegt zwischen 2 und 10. Der Standardwert ist 2. | 2 | | **Matcher** | [HTTP/HTTPS-Zustandsprüfungen] Die HTTP-Codes, die verwendet werden, um ein Ziel auf eine erfolgreiche Antwort zu überprüfen. Der Bereich liegt zwischen 200 und 599. Der Standard ist 200–399. | 200-399 | ## Zustandsstatus des Ziels Bevor der Load Balancer eine Zustandsprüfungsanforderung an ein Ziel sendet, müssen Sie dieses Ziel in einer Zielgruppe registrieren, die Zielgruppe in einer Listener-Regel spezifizieren und sicherstellen, dass die Availability Zone des Ziels für den Load Balancer aktiviert ist. Die folgende Tabelle beschreibt die möglichen Werte für den Zustandsstatus eines registrierten Ziels. | Wert | Description | | --- | --- | | `initial` | Der Load Balancer befindet sich im Prozess der Registrierung eines Ziels oder der Durchführung der anfänglichen Zustandsprüfungen für das Ziel. Zugehörige Ursachencodes: `Elb.RegistrationInProgress` \$1 `Elb.InitialHealthChecking` | | `healthy` | Das Ziel ist fehlerfrei. Zugehörige Ursachencodes: Keine | | `unhealthy` | Das Ziel hat auf eine Integritätsprüfung nicht geantwortet, hat die Integritätsprüfung nicht bestanden oder das Ziel befindet sich im Status „Gestoppt“. Zugehöriger Ursachencode: `Target.FailedHealthChecks` | | `draining` | Die Registrierung für das Ziel wird aufgehoben, und Connection Draining wird durchgeführt. Zugehöriger Ursachencode: `Target.DeregistrationInProgress` | | `unhealthy.draining` | Das Ziel hat auf die Zustandsprüfungen nicht geantwortet oder hat die Zustandsprüfungen nicht bestanden und tritt in eine Übergangsfrist ein. Das Ziel unterstützt bestehende Verbindungen und akzeptiert während dieser Übergangszeit keine neuen Verbindungen. Zugehöriger Ursachencode: `Target.FailedHealthChecks` | | `unavailable` | Die Zielintegrität ist nicht verfügbar. Zugehöriger Ursachencode: `Elb.InternalError` | | `unused` | Das Ziel ist nicht bei einer Zielgruppe registriert, die Zielgruppe wird nicht in einer Listener-Regel verwendet oder das Ziel befindet sich in einer Availability Zone, die nicht aktiviert ist. Zugehörige Ursachencodes: `Target.NotRegistered` \$1 `Target.NotInUse` \$1 `Target.InvalidState` \$1 `Target.IpUnusable` | ## Ursachencodes für Zustandsprüfungen Wenn der Status eines Ziels einen anderen Wert als `Healthy` aufweist, gibt die API einen Ursachencode und eine Beschreibung des Problems zurück und die Konsole zeigt die gleiche Beschreibung in einer QuickInfo an. Beachten Sie, dass Ursachencodes, die mit `Elb` beginnen, ihren Ursprung auf dem Load Balancer und Grundcodes, die mit `Target` beginnen, ihren Ursprung auf der Ziel-Seite haben. | Ursachencode | Description | | --- | --- | | `Elb.InitialHealthChecking` | Anfängliche Zustandsprüfungen in Bearbeitung | | `Elb.InternalError` | Zustandsprüfungen aufgrund eines internen Fehles fehlgeschlagen | | `Elb.RegistrationInProgress` | Zielregistrierung wird durchgeführt | | `Target.DeregistrationInProgress` | Zielregistrierung wird aufgehoben | | `Target.FailedHealthChecks` | Zustandsprüfungen fehlgeschlagen | | `Target.InvalidState` | Ziel hat den Status „Angehalten“ Ziel hat den Status „Beendet“ Ziel hat den Status „Beendet oder Angehalten“ Ziel hat den Status „Ungültig“ | | `Target.IpUnusable` | Die IP-Adresse kann nicht als Ziel verwendet werden, da sie von einem Load Balancer verwendet wird. | | `Target.NotInUse` | Zielgruppe ist nicht konfiguriert, um Verkehr vom Load Balancer zu erhalten Ziel ist in einer Availability Zone, die nicht für den Load Balancer aktiviert ist | | `Target.NotRegistered` | Ziel ist nicht in der Zielgruppe registriert | # Überprüfen Sie den Zustand Ihrer Network Load Balancer Balancer-Ziele Sie können den Zustand der Ziele, die in Ihren Zielgruppen registriert sind, überprüfen. Hilfe bei fehlgeschlagenen Zustandsprüfungen finden Sie unter [Problembehandlung: Ein registriertes Ziel ist nicht in Betrieb](load-balancer-troubleshooting.md#target-not-in-service). ------ #### [ Console ] **So überprüfen Sie den Zustand Ihrer Ziele** 1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Wählen Sie im Navigationsbereich unter **Load Balancing** die Option **Load Balancer** aus. 1. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen. 1. Auf der Registerkarte „**Details**“ werden die Gesamtzahl der Ziele sowie die Anzahl der Ziele für jeden Gesundheitsstatus angezeigt. 1. In der Registerkarte **Ziele** gibt die Spalte **Zustandsstatus** den Status der einzelnen Ziele wider. 1. Wenn der Status einen anderen Wert als `Healthy` hat, enthält die Spalte **Details zum Zustand** weitere Informationen. **So erhalten Sie E-Mail-Benachrichtigungen über fehlerhafte Ziele** Verwenden Sie CloudWatch Alarme, um eine Lambda-Funktion auszulösen, um Details über fehlerhafte Ziele zu senden. step-by-stepAnweisungen finden Sie im folgenden Blogbeitrag: [Identifizieren fehlerhafter Ziele Ihres Load Balancers](https://aws.amazon.com/blogs/networking-and-content-delivery/identifying-unhealthy-targets-of-elastic-load-balancer/). ------ #### [ AWS CLI ] **Um den Zustand Ihrer Ziele zu überprüfen** Verwenden Sie den Befehl [describe-target-health](https://docs.aws.amazon.com/cli/latest/reference/elbv2/describe-target-health.html). In diesem Beispiel wird die Ausgabe so gefiltert, dass sie nur Ziele enthält, die nicht fehlerfrei sind. Für Ziele, die nicht fehlerfrei sind, enthält die Ausgabe einen Ursachencode. ``` aws elbv2 describe-target-health \ --target-group-arn target-group-arn \ --query "TargetHealthDescriptions[?TargetHealth.State!='healthy'].[Target.Id,TargetHealth.State,TargetHealth.Reason]" \ --output table ``` Es folgt eine Beispielausgabe. ``` ---------------------------------------------- | DescribeTargetHealth | +--------------+---------+-------------------+ | 172.31.0.57 | unused | Target.NotInUse | | 172.31.0.50 | unused | Target.NotInUse | +--------------+---------+-------------------+ ``` ------ ## Zielstatus und Ursachencodes Die folgende Liste zeigt die möglichen Ursachencodes für jeden Zielstaat. **Zielstatus ist healthy** Ein Ursachencode ist nicht angegeben. **Zielstatus ist initial** + `Elb.RegistrationInProgress`- Das Ziel wird gerade beim Load Balancer registriert. + `Elb.InitialHealthChecking`- Der Load Balancer sendet dem Ziel immer noch die Mindestanzahl an Integritätsprüfungen, die zur Bestimmung seines Integritätsstatus erforderlich sind. **Der Zielstatus ist unhealthy** + `Target.FailedHealthChecks`- Der Load Balancer hat beim Herstellen einer Verbindung zum Ziel einen Fehler erhalten, oder die Zielantwort war falsch formatiert. **Der Zielstatus ist unused** + `Target.NotRegistered`- Das Ziel ist nicht bei der Zielgruppe registriert. + `Target.NotInUse`- Die Zielgruppe wird von keinem Load Balancer verwendet oder das Ziel befindet sich in einer Availability Zone, die für den Load Balancer nicht aktiviert ist. + `Target.InvalidState`- Das Ziel befindet sich im Status „Gestoppt“ oder „Beendet“. + `Target.IpUnusable`- Die Ziel-IP-Adresse ist für die Verwendung durch einen Load Balancer reserviert. **Der Zielstatus ist draining** + `Target.DeregistrationInProgress`- Das Ziel wird gerade abgemeldet und die Frist für die Abmeldung ist noch nicht abgelaufen. **Der Zielstatus ist unavailable** + `Elb.InternalError`- Der Zustand des Ziels ist aufgrund eines internen Fehlers nicht verfügbar. # Aktualisieren Sie die Einstellungen für die Zustandsprüfung einer Network Load Balancer Balancer-Zielgruppe Sie können die Einstellungen für den Gesundheitscheck für Ihre Zielgruppe jederzeit aktualisieren. Eine Liste der Einstellungen für die Gesundheitsprüfung finden Sie unter[Zustandsprüfungseinstellungen](target-group-health-checks.md#health-check-settings). ------ #### [ Console ] **So aktualisieren Sie die Einstellungen für die Zustandsprüfung** 1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Wählen Sie im Navigationsbereich unter **Load Balancing** die Option **Load Balancer** aus. 1. Wählen Sie den Namen der Zielgruppe aus, um deren Detailseite zu öffnen. 1. Wählen Sie in der Registerkarte **Health checks (Zustandsprüfungen)** die Option **Edit (Bearbeiten)** aus. 1. Ändern Sie auf der Seite **Einstellungen für die Integritätsprüfung** bearbeiten die Einstellungen nach Bedarf. 1. Wählen Sie **Änderungen speichern ** aus. ------ #### [ AWS CLI ] **Um die Einstellungen für die Gesundheitsprüfung zu aktualisieren** Verwenden Sie den Befehl [modify-target-group](https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group.html). Im folgenden Beispiel werden die **HealthCheckTimeoutSeconds**Einstellungen **HealthyThresholdCount**und aktualisiert. ``` aws elbv2 modify-target-group \ --target-group-arn target-group-arn \ --healthy-threshold-count 3 \ --health-check-timeout-seconds 20 ``` ------ #### [ CloudFormation ] **Um die Einstellungen für die Gesundheitsprüfung zu aktualisieren** Aktualisieren Sie die [AWS::ElasticLoadBalancingV2::TargetGroup](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-elasticloadbalancingv2-targetgroup.html)Ressource so, dass sie die aktualisierten Einstellungen für die Integritätsprüfung enthält. Im folgenden Beispiel werden die **HealthCheckTimeoutSeconds**Einstellungen **HealthyThresholdCount**und aktualisiert. ``` Resources: myTargetGroup: Type: 'AWS::ElasticLoadBalancingV2::TargetGroup' Properties: Name: my-target-group Protocol: TCP Port: 80 TargetType: instance VpcId: !Ref myVPC HealthyThresholdCount: 3 HealthCheckTimeoutSeconds: 20 ``` ------