Warum geht mein Amazon-MSK-Cluster in den Status HEALING über?

Lösung

Ihr Amazon MSK-Cluster wechselt in den Status HEALING, wenn der Service einen internen Vorgang ausführt, um ein Problem zu beheben (Beispiel: Broker reagieren nicht). Sie können den Cluster jedoch verwenden, um Daten zu produzieren und zu nutzen. Sie können keine Amazon MSK-API- oder AWS Command Line Interface (AWS CLI)-Aktualisierungsvorgänge auf dem Cluster ausführen, bis dieser wieder in den Status ACTIVE zurückkehrt.

Verwenden Sie die Amazon CloudWatch-Metriken für Amazon MSK, um zu sehen, warum sich der Cluster im Status HEALING befindet:

1. Öffnen Sie die CloudWatch-Konsole.
2. Wählen Sie im Navigationsbereich Metriken und dann Alle Metriken aus.
3. Wählen Sie auf der Registerkarte Durchsuchen die Option AWS/Kafka aus.
4. Wählen Sie unter Metriken die Option Clustername aus.
5. Wählen Sie den Cluster aus, den Sie überwachen möchten.
   Wenn Sie Spitzen in den Metriken ActiveControllerCount oder OfflinePartitionsCount feststellen, deuten diese darauf hin, dass einer oder mehrere Broker fehlerhaft sind. Dies könnte dazu geführt haben, dass Ihr Cluster in den Zustand HEALING übergegangen ist.
6. Wählen Sie für Metriken auf Brokerebene unter Metriken die Option Broker-ID, Clustername aus.
7. Wählen Sie aus der Liste die Einträge mit dem Clusternamen und den Metriken CpuUser und CpuSystem aus. Prüfen Sie, ob die Summe dieser beiden Werte für alle Einträge einen Durchschnitt von mehr als 60 % für den Cluster erreicht. In diesem Fall könnte eine hohe CPU-Auslastung dazu geführt haben, dass der Broker in den Status HEALING übergegangen ist. Weitere Informationen zur Überwachung der CPU-Auslastung finden Sie unter Bewährte Methoden – Überwachung der CPU-Auslastung.

Im Folgenden sind die häufigsten Gründe aufgeführt, warum ein Amazon MSK-Cluster in den Status HEALING übergeht:

• Ein Knoten oder ein Amazon Elastic Block Store (Amazon EBS)-Volumen muss aufgrund eines Hardwarefehlers ersetzt werden.
• Ein Knoten erfüllt die Amazon MSK-Leistungs-SLA für den Broker nicht und der Knoten muss ausgetauscht werden, um eine optimale Leistung zu erzielen.

Beachten Sie, dass Amazon MSK ein vollständig verwalteter Service ist. Daher verfügen Makler über selbstverwaltete Workflows, die Korrekturmaßnahmen an sich selbst vornehmen, z. B. den Austausch von Knoten in Ausfallsituationen. Wenn ein Amazon EBS-Volumen in einem Broker fehlerhaft wird, beobachtet Amazon MSK den Status des Volumens für einen bestimmten Zeitraum. Wenn das Volumen während dieser Zeit wieder funktionsfähig wird, wird keine Aktion ausgeführt. Wenn das Volumen nach diesem Zeitraum weiterhin fehlerhaft ist, ersetzt Amazon MSK dieses Volumen automatisch. Der Cluster geht in den Status HEALING über, wenn Amazon MSK diese Aktionen ausführt. Dies hat jedoch keinen Einfluss auf die Verfügbarkeit des Amazon MSK-Clusters, solange Sie die Bewährten Verfahren befolgen. Selbst wenn sich der Broker im Status HEALING befindet, kann der Cluster Anfragen von Produzenten und Verbrauchern bearbeiten.

In seltenen Fällen kann es vorkommen, dass Ihr Cluster in einen permanenten Status HEALING übergeht. Dies kann folgende Ursachen haben:

• Der Workload auf dem Cluster ist hoch und die Broker werden kontinuierlich ausgetauscht. Um dieses Problem zu vermeiden, empfiehlt es sich, keine t3.small-Instances für das Hosten von Produktionsclustern zu verwenden. Wenn Sie m5-Instances verwenden, stellen Sie sicher, dass Sie die richtige Größe für Ihren Cluster ausgewählt haben. Sie können die Größe Ihres Clusters anhand Ihres Workloads und durch Überwachung Ihrer CPU-Auslastung bestimmen. Stellen Sie außerdem sicher, dass die Anzahl der Partitionen pro Broker den empfohlenen Wert nicht überschreitet.
• Die Auto-Scaling-Gruppe kann keine neue Instance starten. Dies kann auf ein internes Problem oder eine fehlende Abhängigkeit zurückzuführen sein. Beispielsweise kann auf den Schlüssel des AWS Key Management Service (AWS KMS), der bei der Clustererstellung angegeben wurde, möglicherweise nicht mehr zugegriffen werden.
• Ein seltenes internes Ereignis beeinträchtigte die Verfügbarkeit der zugrundeliegenden Amazon Elastic Compute Cloud (Amazon EC2)-Instances oder verursachte Amazon EBS-Latenz in einer Verfügbarkeitszone oder AWS-Region.

Wenn Ihr Cluster in einem permanenten HEALING-Status verbleibt, der nicht lastbedingt ist, wenden Sie sich an den AWS-Support.

Ähnliche Informationen

Cluster-Zustände