Wie stelle ich sicher, dass Sicherheitspatches meine Client-E/A nicht stören?

Kurzbeschreibung

Amazon Managed Streaming für Apache Kafka (Amazon MSK) verwendet fortlaufende Updates, um die hohe Verfügbarkeit aufrechtzuerhalten und Cluster-E/A beim Patchen zu unterstützen. Amazon MSK startet die Broker nacheinander neu und wartet darauf, dass die Partitionen auf dem zuletzt neu gestarteten Broker den Datenstand vollständig aufgeholt haben, bevor der nächste Broker neu gestartet wird. Während dieses Aktualisierungsvorgangs treten möglicherweise vorübergehende Verbindungsfehler auf den Clients auf.

Erstelle hochverfügbare Cluster, um Ausfallzeiten während eines Sicherheits-Patchings zu vermeiden.

Lösung

Einen Cluster mit drei Availability Zones einrichten

Um Ausfallzeiten zu vermeiden, wenn eine Availability Zone ausfällt, richte einen Cluster mit drei Availability Zones ein.

Hinweis: Standardmäßig verteilen Express-Broker deine Daten auf drei Availability Zones.

Amazon MSK legt die Brokereigenschaft broker.rack auf Availability-Zone-Ebene fest, um zum Zweck der Fehlertoleranz eine Rack-bewusste Replikationszuweisung zu erreichen. Wenn du einen Cluster mit drei Availability Zones mit einem Replikationsfaktor (RF) von 3 verwendest, befindet sich jedes der drei Partitionsreplikate in einer separaten Availability Zone.

Hinweis: Ein Cluster mit zwei Availability Zones mit einem RF von 3 kann nicht jedes der drei Partitionsreplikate so ablegen, dass es sich in einer separaten Availability Zone befindet. Amazon MSK erlaubt es dir nicht, einen Cluster in einer einzelnen Availability Zone zu erstellen.

Den Replikationsfaktor auf die Anzahl der Availability Zones einstellen

Wenn du einen Broker während des Sicherheits-Patchings neu startest, ist der Leader nicht mehr verfügbar. Infolgedessen wählt der Cluster eines der Follower-Replikate zum neuen Leader, damit er weiterhin Clients bedienen kann.

Ein RF von 1 kann während eines fortlaufenden Updates zu Offline-Partitionen führen, da der Cluster keine Replikate hat, die zum neuen Leader hochgestuft werden können. Ein RF von 2 mit mindestens einem synchronen Replikat (minISR) von 1 kann zu Datenverlust führen, selbst wenn die Producer-Bestätigung (acks) auf alle.gesetzt ist. Damit ein Schreibvorgang erfolgreich ist, muss bei einem minISR von 1 nur der Leader den Schreibvorgang bestätigen. Wenn der Broker des Leader-Replikats unmittelbar nach der Bestätigung ausfällt, aber bevor das Follower-Replikat den Datenstand aufgeholt hat, kommt es zu einem Datenverlust. Weitere Informationen zu minISR findest du unter min.insync.replicas auf der Apache-Kafka-Website.

Hinweis: Wenn du Express-Broker verwendest, ist die Replikation standardmäßig auf 3 festgelegt.

minISR auf RF -1 oder niedriger einstellen

Wenn du das minlSR auf den Wert des RF setzt, kann es zu Producer-Ausfällen kommen, wenn ein Broker außer Betrieb ist. Wenn die Replikate an den Producer keine Bestätigung zum Schreiben senden, löst der Producer eine Ausnahme aus. Wenn beispielsweise die Availability Zone 3 und der RF 3 ist, wartet der Producer darauf, dass alle drei Partitionsreplikate, einschließlich des Leaders, die Meldungen bestätigen. Wenn einer der Broker außer Betrieb ist, geben nur zwei der drei Partitionen die Bestätigungen zurück, und das führt zu einer Producer-Ausnahme.

Hinweis: Wenn du Express-Broker verwendest, ist das minISR standardmäßig auf 2 gesetzt.

Wenn du Producer-acks auf alle setzt, geht der Datensatz nicht verloren, solange mindestens ein synchrones Replikat aktiv ist. Weitere Informationen zu Producer-acks findest du unter acks auf der Apache-Kafka-Website.

Hinweis: minISR hat Einstellungen auf Themenebene und Einstellungen auf Broker-Ebene. Einstellungen auf Themenebene haben immer Vorrang vor den Einstellungen auf Broker-Ebene.

Mindestens einen Broker aus jeder Availability Zone in die Client-Verbindungszeichenfolge aufnehmen

Der Client verwendet den Endpunkt eines einzelnen Brokers, um den Verbindungsaufbau zum Cluster zu starten. Während der ersten Client-Verbindung sendet der Broker Metadaten mit Informationen über die Broker, auf die der Client zugreifen muss.

Wenn ein Broker nicht verfügbar ist, schlägt die Verbindung fehl. Du hast beispielsweise nur einen Broker in der Verbindungszeichenfolge eines Clients. Beim Patchen kann der Client keine Erstverbindung mit dem Cluster herstellen, wenn du den Broker neu startest.

Oder du hast mehrere Broker in einer Client-Verbindungszeichenfolge. In diesem Fall lässt die Verbindungszeichenfolge des Clients ein Failover zu, wenn der Broker, den du zum Herstellen der Verbindung verwendest, offline geht. Weitere Informationen zum Einrichten einer Verbindungszeichenfolge mit mehreren Brokern findest du unter Die Bootstrap-Broker für einen Amazon-MSK-Cluster abrufen.

Wiederholungsversuche zulassen

Wenn du einen Broker neu startest, sind die Leader-Partitionen auf diesem Broker nicht mehr verfügbar. Infolgedessen stuft Apache Kafka Replikat-Partitionen als neue Leader auf einem anderen Broker hoch. Der Client fordert nun ein Metadaten-Update an, um die neuen Leader-Partitionen zu finden. Während dieser Änderung kann es beim Client zu vorübergehenden Fehlern kommen.

Standardmäßig sind in den Clients Wiederholungsversuche eingebaut, um diese Art von vorübergehenden Fehlern zu behandeln. Vergewissere dich, dass du den Client für Wiederholungsversuche konfiguriert hast. Weitere Informationen zur Konfiguration von Wiederholungsversuchen findest du unter retries (Wiederholungsversuche) auf der Apache-Kafka-Website.

Ähnliche Informationen

Patchen auf von MSK bereitgestellten Clustern