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. Au cours de ce processus, les courtiers sont redémarrés un par un, et le courtier suivant n'est pas redémarré tant que les partitions du courtier actuellement redémarré ne se synchronisent pas complètement. Il est normal de constater des erreurs de déconnexion passagères sur vos clients au cours de ce processus de mise à jour.

Pour éviter que les clients ne soient confrontés à des interruptions de service lors de l'application de correctifs de sécurité, appliquez les bonnes pratiques suivantes pour rendre les clusters hautement disponibles.

Résolution

Configuration d'un cluster à trois AZ

En cas de défaillance d'une zone de disponibilité, un cluster à trois AZ protège contre toute interruption de service.

Amazon MSK définit la propriété broker.rack du courtier afin d'obtenir une attribution de réplication compatible avec les racks afin de garantir la tolérance aux pannes au niveau de la zone de disponibilité. Cela signifie que lorsque vous utilisez un cluster à trois AZ avec un facteur de réplication (RF) de trois, chacune des trois répliques de partition se trouve dans une zone de disponibilité distincte.

**Remarque :**Le fait de disposer d'un cluster à deux AZ avec un RF-3 ne permet pas à chacune des trois répliques de partition de se trouver dans une zone de disponibilité distincte. Amazon MSK ne vous permet pas de créer un cluster dans une seule zone de disponibilité.

Assurez-vous que le facteur de réplication est le nombre de zones de disponibilité

Lorsque vous redémarrez un courtier pendant l'application d'un correctif de sécurité, le leader n'est plus disponible. Par conséquent, l'une des répliques suivantes est élue en tant que nouveau leader afin que le cluster puisse continuer à servir les clients.

Un RF-1 peut entraîner l'indisponibilité de partitions lors d'une mise à jour progressive, car le cluster ne dispose d'aucune réplique à promouvoir en tant que nouveau leader. Un RF-2, avec au moins une réplique synchronisée (miniSR), peut entraîner une perte de données, même lorsque la reconnaissance du producteur (acks) est définie sur « tout ». Pour qu'une écriture soit réussie, un minlSR de 1 exige que seul le leader accuse réception de l'écriture. Si le courtier de la réplique principale tombe en panne immédiatement après l'accusé de réception, mais avant que la réplique suivante ne rattrape son retard, une perte de données se produit. Pour plus d'informations sur min.insync.replicas, consultez la documentation Apache Kafka.

Réglez le minlSR minimum à un maximum de RF-1

Le réglage de minlSR sur la valeur RF peut entraîner des défaillances du producteur lorsqu'un courtier est hors service en raison d'une mise à jour continue. Si les répliques n'envoient pas d'accusé de réception au producteur, celui-ci émet une exception. Par exemple, si AZ est égal à trois et RF est égal à trois, le producteur attend la copie des trois partitions (y compris la première) pour accuser réception des messages. Lorsque l'un des courtiers est hors service, seules deux des trois partitions renvoient les accusés de réception, ce qui entraîne des exceptions pour les producteurs.

Ce scénario suppose que le paramètre Producer acks est défini sur « tout ». Lorsque vous réglez les packs de production sur « tous », l'enregistrement n'est pas perdu tant qu'au moins une réplique synchronisée reste active. Pour plus de détails sur les packs destinés aux producteurs, consultez la documentation d'Apache Kafka.

Inclure au moins un courtier de chaque AZ dans la chaîne de connexion du client

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

Lorsqu'un courtier n'est plus disponible, la connexion échoue. Par exemple, vous n'avez qu'un seul courtier 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 le broker.

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

Autoriser les nouvelles tentatives

Lorsque vous redémarrez un broker, les partitions principales de ce broker ne sont plus disponibles. Par conséquent, Apache Kafka fait la promotion de répliques de partitions sur un autre courtier en tant que nouveaux leaders. Le client demande désormais une mise à jour des métadonnées pour localiser les nouvelles partitions principales. Au cours de cette modification, il est normal que votre client rencontre des erreurs passagères.

Par défaut, les clients disposent de nouvelles tentatives intégrées pour gérer ces types d'erreurs transitoires. Vérifiez que votre client est configuré pour les nouvelles tentatives. Pour plus d'informations sur la configuration des nouvelles tentatives, consultez la documentation Apache Kafka.