Broker offline und Client-Failover - Amazon Managed Streaming für Apache Kafka

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.

Broker offline und Client-Failover

Kafka ermöglicht einen Offline-Broker. Ein einziger Offline-Broker in einem gesunden und ausgewogenen Cluster, der sich an bewährte Methoden hält, hat keine Auswirkungen und führt auch nicht zu Produktionsausfällen oder Ausfällen bei der Produktion oder Nutzung. Das liegt daran, dass ein anderer Broker die Partitionsleitung übernimmt und dass die Kafka-Clientbibliothek automatisch ein Failover durchführt und Anfragen an die neuen Leader-Broker sendet.

Client-Server-Vertrag

Dies führt zu einem gemeinsamen Vertrag zwischen der Client-Bibliothek und dem serverseitigen Verhalten. Der Server muss erfolgreich einen oder mehrere neue Leader zuweisen, und der Client muss den Broker wechseln, um Anfragen rechtzeitig an die neuen Leader zu senden.

Kafka verwendet Ausnahmen, um diesen Ablauf zu kontrollieren:

Ein Beispiel für ein Verfahren

  1. Broker A wechselt in einen Offline-Status.

  2. Der Kafka-Client erhält eine Ausnahme (normalerweise wird das Netzwerk getrennt oder not_leader_for_partition).

  3. Diese Ausnahmen veranlassen den Kafka-Client, seine Metadaten zu aktualisieren, sodass er über die neuesten Führungskräfte informiert ist.

  4. Der Kafka-Client setzt das Senden von Anfragen an die neuen Partitionsleiter auf anderen Brokern fort.

Dieser Vorgang dauert mit dem angebotenen Java-Client und den Standardkonfigurationen in der Regel weniger als 2 Sekunden. Die Fehler auf der Clientseite sind ausführlich und wiederholen sich, geben jedoch keinen Anlass zur Sorge, wie durch die Stufe „“ gekennzeichnet ist. WARN

Beispiel: Ausnahme 1

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2

Beispiel: Ausnahme 2

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"

Kafka-Clients beheben diese Fehler automatisch in der Regel innerhalb von 1 Sekunde und höchstens 3 Sekunden. In den clientseitigen Metriken wird dies als Latenz zwischen Produktion und Verbrauch bei p99 dargestellt (typischerweise hohe Millisekunden in den 100ern). Länger als dieser Wert deutet in der Regel auf ein Problem mit der Client-Konfiguration oder der serverseitigen Controller-Auslastung hin. Weitere Informationen finden Sie im Abschnitt zur Fehlerbehebung.

Ein erfolgreicher Failover kann überprüft werden, indem die Zunahme der BytesInPerSec LeaderCount Messwerte bei anderen Brokern überprüft wird. Dies beweist, dass sich der Traffic und die Führung erwartungsgemäß entwickelt haben. Sie werden auch einen Anstieg der UnderReplicatedPartitions Metrik beobachten, der zu erwarten ist, wenn Replikate mit dem Shutdown-Broker offline sind.

Fehlerbehebung

Der oben genannte Ablauf kann unterbrochen werden, wenn der Client-Server-Vertrag gebrochen wird. Zu den häufigsten Gründen für das Problem gehören:

  • Fehlkonfiguration oder falsche Verwendung von Kafka-Clientbibliotheken.

  • Unerwartetes Standardverhalten und Fehler bei Clientbibliotheken von Drittanbietern.

  • Überladener Controller, was zu einer langsameren Zuweisung von Partitionsführern führt.

  • Es wird ein neuer Controller gewählt, was zu einer langsameren Zuweisung des Partitionsführers führt.

Um ein korrektes Verhalten beim Umgang mit Führungskräften zu gewährleisten, empfehlen wir:

  • Serverseitige Best Practices müssen befolgt werden, um sicherzustellen, dass der Controller-Broker angemessen skaliert wird, um eine langsame Zuweisung von Führungskräften zu vermeiden.

  • Für Clientbibliotheken müssen Wiederholungsversuche aktiviert sein, um sicherzustellen, dass der Client den Failover verarbeitet.

  • Für Clientbibliotheken muss retry.backoff.ms konfiguriert sein (Standard 100), um Verbindungs-/Anforderungsstürme zu vermeiden.

  • Clientbibliotheken müssen request.timeout.ms und delivery.timeout.ms auf Werte setzen, die denen der Anwendungen entsprechen. SLA Höhere Werte führen bei bestimmten Fehlertypen zu einem langsameren Failover.

  • Clientbibliotheken müssen sicherstellen, dass bootstrap.servers mindestens 3 zufällige Broker enthält, um eine Beeinträchtigung der Verfügbarkeit bei der ersten Erkennung zu vermeiden.

  • Einige Clientbibliotheken sind niedriger als andere und erwarten, dass der Anwendungsentwickler die Wiederholungslogik und die Ausnahmebehandlung selbst implementiert. Informationen zur Verwendung finden Sie in der spezifischen Dokumentation zur Clientbibliothek und stellen Sie sicher, dass die richtige Logik zum erneuten Verbindungs-/Wiederholungsversuch befolgt wird.

  • Wir empfehlen, die clientseitige Latenz für Produkte, die Anzahl erfolgreicher Anfragen und die Anzahl der Fehler bei Fehlern, die nicht erneut versucht werden können, zu überwachen.

  • Wir haben beobachtet, dass ältere Golang- und Ruby-Bibliotheken von Drittanbietern während der gesamten Offline-Zeit des Brokers sehr umfangreich bleiben, obwohl Produces- und Consume-Anfragen davon nicht betroffen sind. Wir empfehlen Ihnen, neben den Erfolgs- und Fehlerkennzahlen auch immer Ihre Kennzahlen auf Unternehmensebene zu überwachen, um festzustellen, ob Ihre Logs tatsächlich Auswirkungen haben und ob es zu Störungen kommt.

  • Kunden sollten sich nicht über vorübergehende Ausnahmen für network/not_leader informieren, da diese normal sind, keine Auswirkungen haben und im Rahmen des Kafka-Protokolls erwartet werden.

  • Kunden sollten keinen Alarm auslösen, UnderReplicatedPartitions da sie bei einem einzigen Offline-Broker normal sind, keine Auswirkungen haben und zu erwarten sind.