Comment m'assurer que les correctifs de sécurité ne perturbent pas les E/S de mon client ?

Brève description

Amazon Managed Streaming for Apache Kafka (Amazon MSK) utilise des mises à jour continues pour maintenir une haute disponibilité et prendre en charge les E/S du cluster lors de l'application de correctifs. Amazon MSK redémarre les agents un par un et attend que les partitions du dernier agent redémarré rattrapent pleinement leur retard avant de redémarrer l’agent suivant. Vous pouvez constater des erreurs de déconnexion passagères sur vos clients au cours de ce processus de mise à jour.

Pour éviter toute durée d’indisponibilité pendant un correctif de sécurité, créez des clusters hautement disponibles.

Résolution

Configurer un cluster à trois zones de disponibilité

Pour éviter toute durée d’indisponibilité en cas de défaillance d'une zone de disponibilité, configurez un cluster à trois zones de disponibilité.

Remarque : par défaut, les agents express répartissent vos données dans trois zones de disponibilité.

Pour garantir une attribution de réplication compatible avec les racks pour la tolérance aux pannes, Amazon MSK définit la propriété broker.rack de l’agent au niveau de la zone de disponibilité. Lorsque vous utilisez un cluster à trois zones de disponibilité avec un facteur de réplication (RF) de 3, chacun des trois réplicas de partition se trouve dans une zone de disponibilité distincte.

Remarque : un cluster à deux zones de disponibilité avec un RF de 3 ne peut pas placer chacun des trois réplicas de partition dans une zone de disponibilité distincte. Amazon MSK ne vous permet pas de créer un cluster dans une seule zone de disponibilité.

Définir un facteur de réplication égal au nombre de zones de disponibilité

Lorsque vous redémarrez un agent pendant l'application d'un correctif de sécurité, le leader n'est plus disponible. Par conséquent, le cluster choisit l'un des réplicas suiveurs comme nouveau leader afin de pouvoir continuer à servir ses clients.

Un RF-1 peut entraîner l'indisponibilité de partitions lors d'une mise à jour progressive, car le cluster ne dispose d'aucun réplica à promouvoir en tant que nouveau leader. Un RF-2, avec au moins un réplica synchronisé (miniSR), peut entraîner une perte de données, même lorsque l’accusé de réception du producteur (acks) est défini sur tous. Pour qu'une écriture soit réussie, un minlSR de 1 exige que seul le leader accuse réception de l'écriture. Si l’agent du réplica leader tombe en panne immédiatement après l'accusé de réception, mais avant que le réplica suiveur ne rattrape son retard, une perte de données se produit. Pour plus d'informations sur MiniSR, consultez la page min.insync.replicas sur le site Web d'Apache Kafka.

Remarque : si vous utilisez des agents Express, la réplication est définie par défaut sur 3.

Définir MiniSR sur RF - 1 ou moins

Si vous définissez le minSR sur la valeur du RF, vous risquez de recevoir des messages de panne du producteur lorsqu'un agent est hors service. Si les réplicas n'envoient pas d'accusé de réception au producteur, celui-ci émet une exception. Par exemple, si la zone de disponibilité est 3 et RF est 3, le producteur attend les trois réplicas de partition, y compris le leader pour accuser réception des messages. Lorsque l'un des agents est hors service, seules deux des trois partitions renvoient les accusés de réception, ce qui entraîne une exception pour le producteur.

Remarque : si vous utilisez des agents Express, le miniSR est défini par défaut sur 2.

Lorsque vous définissez des accusés de réception de producteur sur tous, l'enregistrement n'est pas perdu tant qu'au moins un réplica synchronisé demeure actif. Pour plus de détails sur les accusés de réception de producteur, consultez acks sur le site Web d'Apache Kafka.

Remarque : miniSR utilise des paramètres au niveau de la rubrique et des paramètres au niveau de l’agent. Les paramètres au niveau de la rubrique remplacent toujours les paramètres au niveau de l’agent.

Incluez au moins un agent de chaque zone de disponibilité dans la chaîne de connexion d’un client.

Le client utilise le point de terminaison d'un agent unique pour démarrer une connexion au cluster. Lors de la connexion initiale du client, l’agent envoie des métadonnées contenant des informations sur les agents auxquels le client doit accéder.

Lorsqu'un agent n'est plus disponible, la connexion échoue. Par exemple, vous n'avez qu'un seul agent dans la chaîne de connexion d'un client. Lors de l'application de correctifs, le client ne parvient pas à établir une connexion initiale avec le cluster lorsque vous redémarrez l’agent.

Ou bien, vous avez plusieurs agents dans une chaîne de connexion client. Dans ce cas, la chaîne de connexion du client permet le basculement lorsque l’agent utilisé pour établir la connexion se déconnecte. Pour plus d'informations sur la configuration d'une chaîne de connexion avec plusieurs agents, consultez Obtenir les agents d’amorçage pour un cluster Amazon MSK.

Autoriser les nouvelles tentatives

Lorsque vous redémarrez un agent, les partitions leader sur ce dernier ne sont plus disponibles. Par conséquent, Apache Kafka promeut des partitions de réplicas sur un autre agent en tant que nouveaux leaders. Le client demande désormais une mise à jour des métadonnées pour localiser les nouvelles partitions leader. Lors de cette modification, votre client peut rencontrer des erreurs passagères.

Par défaut, de nouvelles tentatives sont intégrées aux clients pour gérer ces types d'erreurs transitoires. Vérifiez que vous avez configuré votre client pour les nouvelles tentatives. Pour plus d'informations sur la configuration des nouvelles tentatives, consultez la page Nouvelles tentatives sur le site Web d'Apache Kafka.

Informations connexes

Application de correctifs sur les clusters provisionnés par MSK