Accord sur les niveaux de service (SLA) relatif à la disponibilité de Event Streams

plan Standard

Le plan Standard Event Streams fournit une architecture hautement disponible par déploiement de région multizone. Dans un emplacement multizone, le service Event Streams est réparti sur trois zones de disponibilité, ce qui signifie que le cluster est résilient à l'échec d'une zone unique ou d'un composant de cette zone.

Le service d' Event Streams s est fourni avec une disponibilité de 99.99 % sur le Plan Standard. Pour plus d'informations sur l'accord SLA des services à haute disponibilité dans IBM Cloud®, voir Accords sur les niveaux de service pour IBM Cloud(cloud public).

Plan Enterprise

Le plan Enterprise Event Streams fournit une architecture hautement disponible par déploiement de région multizone. Dans un emplacement multizone, le service Event Streams est réparti sur trois zones de disponibilité, ce qui signifie que le cluster est résilient en cas d'échec d'une zone unique ou d'un composant de cette zone.

Dans le cadre d'un déploiement régional multi-zones, le service d' Event Streams s est fourni avec une disponibilité de 99.99 % sur le plan Entreprise. Pour plus d'informations sur l'accord SLA des services à haute disponibilité dans IBM Cloud, voir Accords de niveau de service pour IBM Cloud(Public Cloud).

Lorsque le service d' Event Streams s est exécuté dans une configuration non hautement disponible, telle que des emplacements à zone unique, la disponibilité est de 99.9 %. Pour plus d'informations sur l'accord sur les niveaux de service pour les services qui ne sont pas à haute disponibilité dans IBM Cloud, voir Accords de niveau de service pour IBM Cloud(Public Cloud).

Comment la mesurer ?

Les instances de service font l'objet d'une surveillance continue des performances, des taux d'erreur et de leur réponse aux opérations synthétiques. Les indisponibilités sont enregistrées. Pour plus d'informations, voir Service status for Event Streams.

La disponibilité fait référence à la capacité des applications à produire et à utiliser des messages provenant de rubriques Kafka.

Que devez-vous prendre en compte pour atteindre cette disponibilité ?

Pour atteindre des niveaux de disponibilité élevés du point de vue de l'application, vous devez tenir compte de la connectivité, du débit ainsi que de la cohérence et de la durabilité des messages. Les utilisateurs ont pour responsabilité de concevoir leurs applications pour qu'elles optimisent ces trois éléments pour leur entreprise.

Connectivité

En raison de la nature dynamique du cloud, les applications doivent s'attendre à des ruptures de connexion. Une rupture de connexion n'est pas considérée comme une défaillance de service.

Nombre de nouvelles tentatives

Les clients Kafka fournissent une logique de reconnexion, mais vous devez explicitement activer les reconnexions pour les producteurs. Pour plus d'informations, consultez la propriété retries. Les connexions sont rétablies dans un délai de 60 secondes.

Doublons

Les tentatives d'activation peuvent créer des doublons de messages. Selon le moment où la connexion est interrompue, le fournisseur peut ne pas être en mesure de déterminer si un message a été traité avec succès par le serveur et s'il doit être renvoyé à la reconnexion. Concevez des applications pour qu'elles s'attendent à des messages en double.

Si les doublons ne peuvent pas être tolérés, vous pouvez utiliser la fonction de production idempotent (à partir de Kafka 1.1) pour éviter les doublons pendant les nouvelles tentatives. Pour plus d'informations, consultez la propriété enable.idempotence.

Débit

Le débit est exprimé en nombre d'octets par seconde pouvant être envoyés et reçus dans un cluster.

Conseils spécifiques au plan Standard

Pour plus d'informations sur le débit, voir Limites et quotas - Standard.

Conseils spécifiques au plan Entreprise

Pour obtenir des informations sur le débit, voir Limites et quotas - Enterprise.

Mesure

Instrumentez les applications pour connaître leurs performances. Par exemple, le nombre de messages envoyés et reçus, les tailles des messages et les codes de retour. Comprendre l'utilisation d'une application vous aide à correctement configurer ses ressources, par exemple la durée de conservation des messages sur certaines rubriques.

Saturation

Lorsque la limite du trafic pouvant être produit dans le cluster approche, les producteurs commencent à être régulés, la latence augmente et, en fin de compte, des erreurs telles que des erreurs de délai d'attente se produisent. Selon la configuration, la cohérence et la durabilité des messages peuvent également être affectées. Pour plus d'informations, voir Cohérence et durabilité des messages.

Cohérence et durabilité des messages

Kafka atteint sa disponibilité et sa durabilité en répliquant les messages qu'il reçoit sur d'autres nœuds du cluster, qui peuvent ensuite être utilisés en cas d'échec. Event Streams utilise trois répliques (default.replication.factor = 3), ce qui signifie que chaque message reçu par un nœud est répliqué sur deux autres nœuds dans des zones de disponibilité différentes. De cette manière, la perte d'un noeud ou d'une zone de disponibilité peut être tolérée sans perte de données ou de fonction.

Mode acks du producteur

Bien que tous les messages soient répliqués, les applications peuvent contrôler la robustesse avec laquelle les messages qu'elles produisent sont transférés au service en utilisant la propriété mode d' acks. Cette propriété permet de choisir entre la vitesse et le risque de perte de message. Avec Kafka 3.0, le paramètre de client par défaut est acks=all (avant cette version, il s'agissait de acks=1). Le paramètre acks=all signifie que le fournisseur renvoie une réussite, dès que le courtier auquel il est connecté et au moins un autre courtier du cluster ont accusé réception du message. L'avantage d'utiliser acks=all est qu'il offre le niveau de durabilité le plus élevé et donc une protection contre la perte de données de message.

Répliques synchrones

Dans la configuration utilisée par Event Streams, Kafka choisit un courtier comme leader pour chaque réplique de partition et deux autres courtiers comme suiveurs. Les données de message des clients sont envoyées au responsable de la partition et sont répliquées sur les suiveurs. Si les suiveurs sont en phase avec le leader, ils sont considérés comme des répliques "synchronisées". Par définition, le leader est toujours considéré comme étant synchronisé.

Si le leader d'une partition devient indisponible, peut-être en raison de la maintenance appliquée au courtier, Kafka choisit automatiquement l'une des autres répliques synchronisées pour devenir le nouveau leader. Ce processus se produit rapidement et est automatiquement géré par les clients Kafka.

Élections de leader non nettoyées

Event Streams désactive les élections de leader non nettoyées. Ce paramètre ne peut pas être modifié.

Le terme unclean leader election décrit comment Kafka répond dans une situation où toutes les répliques synchronisées d'une partition deviennent indisponibles. Lorsque les élections de leader non nettoyées sont activées, Kafka effectue une reprise en faisant de la première réplique disponible le leader de la partition, qu'elle soit ou non synchronisée. Cela peut entraîner la perte de données de message si la réplique choisie comme leader n'a pas répliqué toutes les données de message du leader précédent. Lorsque les élections de leader non nettoyées sont désactivées (comme c'est le cas pour Event Streams), Kafka attend qu'une réplique synchronisée soit disponible et choisit de devenir le nouveau leader de la partition. Cela permet d'éviter la perte potentielle de données de message qui peut se produire lorsque des élections de leader non nettoyées sont activées. Le compromis est que la récupération peut prendre plus de temps car Kafka peut avoir à attendre qu'un courtier spécifique soit remis en ligne avant qu'une partition ne soit disponible pour que les clients produisent et consomment des données de message.

Déploiements dans une zone SZR (Single Zone Location Region)

Pour accéder à la plus haute disponibilité, il est conseillé d'utiliser les environnements Public à haute disponibilité, qui sont construits dans des emplacements à zones multiples. Dans un emplacement à zone multiple, les clusters Kafka sont répartis sur trois zones de disponibilité, ce qui permet au cluster de ne pas être impacté par l'échec d'une zone unique et d'un composant dans cette zone. Certains clients ont besoin d'une localisation géographique et souhaitent donc mettre en place un cluster d' Event Streams s dans une zone géographique locale mais unique. L' Event Streams prend en charge ce modèle de déploiement, mais il faut tenir compte des compromis de disponibilité suivants :

  • Dans un emplacement de zone unique, il existe des catégories d'échecs uniques qui peuvent conduire à la mise hors ligne du cluster pendant une certaine période. Par exemple, en cas d'échec d'un centre de données complet ou de la mise à jour ou de l'échec d'un composant partagé tel que l'hyperviseur sous-jacent, le réseau SAN ou le réseau. Ces échecs sont reflétés dans le contrat SLA réduit pour les zones SZR (Single Zone Location Region).

  • L'un des avantages de la répartition de l' Kafka s sur plusieurs zones est de minimiser le risque de défaillance qui pourrait entraîner la chute de tout un cluster. En revanche, il existe une faible possibilité qu'une seule défaillance puisse entraîner la chute de l'ensemble du cluster au sein d'une zone. Dans les cas extrêmes, il existe également un risque potentiel de perte de données. Par exemple, même si acks=all est utilisé par les producteurs, si tous les nœuds Kafka tombent en panne simultanément, il peut y avoir des messages dont les courtiers ont accusé réception, mais le système de fichiers sous-jacent n'a pas terminé le vidage sur le disque. Ces messages non effacés pourraient être perdus.

Pour plus d'informations, voir Accusés de réception des messages. Dans de nombreux cas d'utilisation, ce n'est pas forcément un problème. Toutefois, si une perte de message est inacceptable quelles que soient les circonstances, envisagez d'autres stratégies, telles que l'utilisation d'un cluster de zones à disponibilité multiple, une réplication entre plusieurs régions ou une vérification des messages côté producteur.

Pour plus d'informations, voir les rubriques relatives aux clusters à zone unique et à zone multiple.