Wie stelle ich sicher, dass meine Client-I/O nicht aufgrund von Sicherheitspatches unterbrochen wird?

Lesedauer: 4 Minute
0

Ich möchte einige bewährte Verfahren für die Aufrechterhaltung der Hochverfügbarkeit in MSK-Clustern während des Sicherheitspatchings kennen.

Kurze Beschreibung

Amazon Managed Streaming for Apache Kafka (Amazon MSK) verwendet fortlaufende Updates, um die hohe Verfügbarkeit aufrechtzuerhalten und Cluster-I/O beim Patchen zu unterstützen. Während dieses Prozesses werden die Broker nacheinander neu gestartet, und der nächste Broker wird erst dann neu gestartet, wenn die Partitionen des aktuell neu gestarteten Brokers vollständig aufgeholt haben (in-sync). Es ist normal, dass während dieses Aktualisierungsvorgangs vorübergehende Verbindungsunterbrechungsfehler auf Ihren Clients auftreten.

Um zu verhindern, dass die Clients während des Sicherheitspatchings ausfallen, sollten Sie die folgenden bewährten Verfahren anwenden,um die Cluster hochverfügbar zu machen..

Auflösung

Einrichten eines Drei-AZ-Clusters

Wenn eine Availability Zone ausfällt, schützt ein Drei-AZ-Cluster vor Ausfallzeiten.

Amazon MSK legt die Brokereigenschaft** broker.rack** fest, um eine rack-fähige Replikationszuweisung zu erreichen, um die Fehlertoleranz auf Availability Zone-Ebene zu gewährleisten. Das bedeutet, dass sich bei einem Drei-AZ-Cluster mit einem Replikationsfaktor (RF) von drei jede der drei Partitionsreplikationen in einer eigenen Availability Zone befindet.

Hinweis: Bei einem Zwei-AZ-Cluster mit einem RF-3 kann sich nicht jedes der drei Partitionsreplikate in einer separaten Availability Zone befinden. Amazon MSK erlaubt es Ihnen nicht, einen Cluster in einer einzelnen Availability Zone zu erstellen.

Stellen Sie sicher, dass der Replikationsfaktor die Anzahl der Availability Zones ist

Wenn Sie einen Broker während des Sicherheitspatches neu starten, ist der Leader nicht mehr verfügbar. Infolgedessen wird eines der Nachfolgerreplikate zum neuen Leiter gewählt, sodass der Cluster weiterhin Kunden betreuen kann.

Ein RF-1 kann dazu führen, dass Partitionen während eines fortlaufenden Updates nicht verfügbar sind, da der Cluster über keine Replikate verfügt, die als neuer Leader heraufgestuft werden könnten. Ein RF-2 mit mindestens einem in-Sync-Replikat (miniSR) kann zu Datenverlust führen, selbst wenn Producer Acknowledgement (acks) auf „all“ gesetzt ist. „ Damit ein Schreibvorgang erfolgreich ist, muss bei einem miniSR von eins nur der Leiter den Schreibvorgang bestätigen. Wenn der Broker des Leader-Replikats unmittelbar nach der Bestätigung ausfällt, aber bevor das Nachfolgerreplikat den Betrieb aufholt, kommt es zu einem Datenverlust. Weitere Informationen zumin.insync.replicas finden Sie in derApache Kafka-Dokumentation.

Stellen Sie den Minimalwert miniSR auf höchstens RF-1 ein

Die Einstellung von miniSR auf den Wert von RF kann zu Herstellerausfällen führen, wenn ein Broker aufgrund eines fortlaufenden Updates außer Betrieb ist. Wenn die Repliken dem Produzenten keine Bestätigung zum Schreiben geben, löst der Hersteller eine Ausnahme aus. Wenn AZ beispielsweise gleich drei und RF gleich drei ist, wartet der Producer, bis alle drei Partitionsreplikate (einschließlich des Leaders) die Nachrichten bestätigt haben. Wenn einer der Broker ausfällt, geben nur zwei der drei Partitionen die Bestätigungen zurück, was zu Herstellerausnahmen führt.

Dieses Szenario geht davon aus, dass der Producer Acks auf „all“ gesetzt ist. „ Wenn Sie Producer Acks auf „all“ setzen, geht der Datensatz nicht verloren, solange mindestens ein in-Sync-Replikat aktiv ist. Weitere Informationen zu Producer-Acks finden Sie in derApache Kafka-Dokumentation.

Fügen Sie mindestens einen Broker aus jeder AZ in die Client-Verbindungszeichenfolge ein

Der Client verwendet den Endpunkt eines einzelnen Brokers, um eine Verbindung zum Cluster zu booten. 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. Beispielsweise haben Sie nur einen Broker in der Verbindungszeichenfolge eines Clients. Während des Patches kann der Client keine erste Verbindung mit dem Cluster herstellen, wenn Sie den Broker neu starten.

Oder Sie haben mehrere Broker in einer Client-Verbindungszeichenfolge. In diesem Fall ermöglicht die Verbindungszeichenfolge des Clients ein Failover, wenn der Broker, der für den Verbindungsaufbau verwendet wird, offline geht. Weitere Informationen zum Einrichten einer Verbindungszeichenfolge mit mehreren Brokern finden Sie unter Die Bootstrap-Broker für einen Amazon MSK-Cluster abrufen.

Wiederholungsversuche zulassen

Wenn Sie einen Broker neu starten, sind die Leader-Partitionen auf diesem Broker nicht mehr verfügbar. Infolgedessen wirbt Apache Kafka als neuen Marktführer für Replikat-Partitionen auf einem anderen Broker. Der Client fordert nun ein Metadaten-Update an, um die neuen Leader-Partitionen zu finden. Während dieser Änderung ist es normal, dass bei Ihrem Kunden vorübergehende Fehler auftreten.

Standardmäßig sind in den Clients Wiederholungsversuche eingebaut, um diese Art von vorübergehenden Fehlern zu behandeln. Vergewissern Sie sich, dass Ihr Client für Wiederholungsversuche konfiguriert ist. Weitere Informationen zur Konfiguration von Wiederholungsversuchen finden Sie in derApache Kafka-Dokumentation.

AWS OFFICIAL
AWS OFFICIALAktualisiert vor einem Jahr