Utilisation de la mise en miroir
La mise en miroir permet aux messages d'une instance de service Event Streams d'être copiés en continu dans une seconde instance. La résilience des applications peut être améliorée en utilisant la mise en miroir comme si la première instance de service n'était plus disponible, les applications peuvent se reconnecter à la deuxième instance et poursuivre leur fonctionnement normal.
Cette fonction fait partie du service entièrement géré et ne peut être utilisée qu'entre les instances de service qui utilisent le plan Enterprise Event Streams.
Fonctions de la mise en miroir:
- Les rubriques miroir, les données de message et les décalages de groupe de consommateurs entre deux instances de service Event Streams, qui peuvent être mises à disposition dans différents comptes IBM Cloud.
- SLA de 99.99% de disponibilité, cohérent avec le service Event Streams.
- Peut être surveillé à l'aide de IBM Cloud® Monitoring.
Limitations de la mise en miroir:
- Unidirectionnel: les données ne peuvent être mises en miroir que dans une seule direction à la fois entre deux instances de service. Cela signifie que la mise en miroir offre un style de haute disponibilité "active-passive" et non "active-active".
- Asynchrone: les messages doivent être produits avec succès dans l'instance source pour pouvoir être mis en miroir dans l'instance cible. Cela signifie qu'en cas de défaillance, il est possible que le cluster cible ne dispose pas de tous les messages jusqu'au moment exact de la défaillance en raison du décalage de réplication et que certaines données de message soient perdues.
- Consommation de messages au moins une fois: lorsqu'un consommateur passe d'une instance à l'autre, il peut être nécessaire de retraiter les messages qu'il a déjà traités.
Avant de commencer la mise en miroir, tenez compte des points suivants:
- Il peut être nécessaire de modifier les applications pour tirer le meilleur parti de la mise en miroir.
- Vérifiez que la capacité disponible est suffisante pour le trafic réseau utilisé pour la mise en miroir des données entre les instances.
Pour activer la mise en miroir, voir la rubrique Guide de configuration de la mise en miroir.
Présentation de la mise en miroir
La mise en miroir des rubriques sélectionnées est effectuée entre deux clusters et est unidirectionnelle, ce qui signifie que les données sont mises en miroir dans un sens, depuis un seul cluster source vers un seul cluster cible. Chaque cluster
possède un alias de mise en miroir. Dans ce document, A est utilisé pour l'alias de cluster source et B pour l'alias de cluster cible. Les alias sont configurables lorsque la mise en miroir est activée. Par exemple,
ils peuvent être "us-south" et "us-east".
Un sujet appelé mytopic dans le groupe source (A) apparaît dans le groupe cible (B) comme mytopic.A, indiquant qu'il provient de A. Ce type de sujet est appelé sujet distant car il provient du
cluster distant (source). En revanche, toutes les rubriques créées directement par les utilisateurs sur le groupe cible sont appelées rubriques locales.
Pour sélectionner les rubriques à mettre en miroir, il est possible de configurer un modèle d'expression régulière à l'aide des contrôles utilisateur de mise en miroir.
La mise en miroir convertit automatiquement les décalages de consommateur entre les instances source et cible. Dans les versions précédentes de Event Streams, les consommateurs devaient utiliser une rubrique spéciale appelée A.checkpoints.internal (où A est l'alias du cluster source). Cela n'est plus nécessaire, mais la rubrique de point de contrôle continue d'être créée et mise à jour par le processus de mise en miroir pour la compatibilité en amont avec les applications
existantes. Les applications qui souhaitent utiliser la rubrique de points de contrôle peuvent utiliser Kafka MirrorClient pour simplifier l'accès aux données contenues dans cette rubrique.
Enfin, en raison de la dénomination des rubriques distantes:
- Evitez d'utiliser des alias de cluster dans le cadre des noms de ressource Kafka.
- Vérifiez que le nom de rubrique distante (par exemple, rubrique source et alias de cluster source) ne dépasse pas la limite de longueur pour les rubriques Kafka (249 caractères). Si un nom de rubrique distante dépasse cette limite, les messages ne seront pas mis en miroir pour la rubrique.
Planification de la capacité
L'utilisation du réseau et la situation géographique des instances de service source et cible doivent être prises en compte lors de la planification de la capacité.
Bande passante du réseau
La largeur de bande du réseau nécessaire à la mise en miroir des sujets sélectionnés doit être prise en compte dans l'allocation de la largeur de bande des instances de service source et cible. Par exemple, si les applications de l'instance de service source produisent un trafic de messages de 10 MB/s vers les sujets mis en miroir, une bande passante sortante supplémentaire de 10 MB/s est nécessaire pour mettre en miroir ces messages dans l'instance cible. Cela doit être pris en compte en même temps que la bande passante sortante existante qui est déjà utilisée par les applications consommatrices. Les tableaux de bord de surveillance peuvent être utilisés pour déterminer l'utilisation du réseau dans une instance de service. Pour plus d'informations, voir Surveillance des métriques Event Streams.
Emplacement géographique
Comme pour tout réseau, le débit maximal atteignable dépend de la distance sur laquelle les données sont transmises (en raison de l'augmentation du temps d'attente et de la perte de paquets). Cela affecte le débit maximal qui peut être atteint entre les instances source et cible. Placer les instances de service cibles dans un endroit aussi proche que possible de la source.
Le tableau suivant fournit des indications sur le débit réalisable lors de la mise en miroir à partir d'une instance source d'une capacité de 150 Mo/s.
| Régions | Débit maximal par partition | Débit total maximal |
|---|---|---|
| us-south <-> us-east | 1,5 Mo/s | 35 Mo/s |
| eu-gb <-> eu-de | 2,5 Mo/s | 35 Mo/s |
| au-syd <-> jp-tok | 0,4 Mo/s | 12 Mo/s |
| dans la même région eu-gb <-> eu-gb | 2,5 Mo/s | 35 Mo/s |
Les nombres indiquent ce qui suit :
- Débit total maximal : Nombre total de Mo/s maximal pouvant être reproduit pour toutes les rubriques sélectionnées.
- Débit par partition maximal : Nombre maximal de Mo/s pouvant être reproduit dans une seule partition. Sélectionnez le nombre de partitions configurées pour les rubriques source afin de vous assurer que la charge par partition reste comprise dans cette limite.
Le dépassement des limites entraîne un décalage croissant entre les données des instances source et cible. Un décalage de données important peut entraîner la perte d'une plus grande quantité de données de message en cas d'échec de l'instance source. Même si le décalage entre les instances est égal à zéro, car la mise en miroir est asynchrone, vous devez prévoir que certaines données peuvent être perdues si l'instance source échoue. Les tableaux de bord de surveillance peuvent être utilisés pour déterminer le temps d'attente pour chaque rubrique. Pour plus d'informations, voir Surveillance de la mise en miroir.
Les conseils sur le débit réalisable ont été générés à l'aide de messages 100K générés sur 50 partitions de rubrique. Si votre charge de travail utilise des tailles de message plus petites (par exemple, sous 1K) ou moins de partitions, la mise en miroir risque de ne pas atteindre ces niveaux de débit.
Suppression de rubriques cible redondantes
Pour éviter la suppression accidentelle des données dans l'instance cible, les rubriques ne sont pas automatiquement supprimées de l'instance cible lorsqu'elles sont supprimées de la source. Il est de la responsabilité de l'utilisateur de supprimer les rubriques de l'instance cible. Si des rubriques en miroir sont fréquemment supprimées et créées, une plus grande capacité de disque et de partition peut être consommée dans le cluster cible. L'utilisation peut être surveillée à l'aide du tableau de bord de surveillance dans le cluster cible. Voir Surveillance des métriques Event Streams. Vous pouvez supprimer des rubriques qui ne sont plus nécessaires à l'aide de l'interface de ligne de commande, de l'interface utilisateur ou des interfaces d'administration.
Règles d'accès IAM pour la mise en miroir
Comme les applications doivent avoir accès aux clusters source et destination, les politiques d'accès IAM doivent être configurées sur les deux clusters et utiliser la clé API de l'identifiant de service auquel les politiques sont attachées. Il est possible d'utiliser les fonctions d'utilisation de caractères génériques d'IAM (Affectation de droits d'accès à l'aide de règles de caractère générique) pour simplifier les règles d'accès qui contrôlent l'accès aux ressources miroir.
Si vous débutez avec les règles d'accès IAM, voir Fonctionnement d' IBM Cloud IAM et Gestion de l'authentification auprès de vos instances Event Streams pour plus de détails.
Définir les politiques d'accès IAM suivantes sur les deux clusters, où
A.checkpoints.internal.
| Type de ressource | ID de ressource | Rôle |
|---|---|---|
| grappe | Lecteur | |
| groupe | <RESOURCE_NAME>.* | Comme l'exige l'application |
| sujet | <RESOURCE_NAME>.* | Comme l'exige l'application |
| txnid | <RESOURCE_NAME>.* | Comme l'exige l'application |
| rubrique (spécifique à la rubrique de point de contrôle) |
|
Lecteur |
Accordez des règles d'accès à granularité fine à des applications individuelles. Par exemple, pour les applications qui utilisent simplement l'accès Lecteur uniquement.
Pour les contrôles utilisateur de la mise en miroir, vous devez disposer des autorisations suivantes sur le cluster cible.
| Type de ressource | ID de ressource | Rôle |
|---|---|---|
| grappe | Responsable |
Restrictions basées sur le contexte et contrôles de sécurité du réseau avec Mirroring
La mise en miroir suit un modèle basé sur l'extraction où le cluster cible initie la connexion pour extraire des données du cluster source. Ce modèle de mise en miroir basé sur la traction applique des contrôles réseau au niveau du cluster source, garantissant que seul le cluster cible autorisé peut accéder aux données du cluster source.
Lorsque les contrôles de sécurité du réseau, tels que la restriction basée sur le contexte (CBR) ou la liste d'autorisations CSE, sont activés, un chemin sécurisé au niveau du réseau et de l'identité de sécurité est défini par l'ajout d'une liste d'autorisations de point final de service au cluster source, qui inclut l'IP du pod de mise en miroir du cluster cible. Cette configuration permet d'appliquer un contrôle d'accès très fin au niveau de l'infrastructure, en autorisant uniquement le point d'extrémité de la mise en miroir (le cluster cible) à extraire des données du cluster source.
Les informations d'identification partagées entre le cluster source et le cluster cible sont strictement réservées au processus de mise en miroir et n'autorisent pas l'accès à d'autres ressources entre les déploiements de Event Streams. Cela signifie que le processus de mise en miroir est isolé et sécurisé, empêchant tout accès non autorisé à d'autres ressources.
Ces contrôles de sécurité du réseau doivent être activés avant la mise en place du miroir. Si des restrictions contextuelles sont appliquées après la mise en place de la mise en miroir, celle-ci ne démarrera pas tant que le cluster n'aura pas été mis à jour.
Si CBR est activé après la mise en miroir :
- Créer un ticket d'assistance.
- Attendez le prochain cycle de mise à jour du cluster (au moins 24 heures) pour que les modifications prennent effet.
- Incluez les adresses de vos nœuds miroirs dans vos règles CBR.
- Désactiver et réactiver la mise en miroir dans le cluster cible.
Considérations à prendre en compte lorsque vous partagez des clusters entre plusieurs entités
Lorsque plusieurs entités, telles que différentes unités commerciales, partagent une instance et ont besoin d'être isolées les unes des autres, suivez les directives de dénomination pour simplifier la gestion et le fonctionnement des clusters en miroir.
Nommez les ressources Kafka à l'aide du modèle suivant: <ENTITY_PREFIX>
Où :
- < ENTITY_PREFIX > est le préfixe de l'entité qui utilise cette rubrique.
-
est un caractère facultatif utilisé pour séparer facilement les noms des entités et des ressources. -
est le nom de la ressource Kafka.
Par exemple, si l'unité commerciale Comptabilité a besoin d'un thème intitulé Factures, vous pouvez l'appeler accounting.invoices.
Les règles d'accès requises doivent être ajustées. Par exemple, pour l'unité métier de comptabilité, les règles suivantes sont requises sur le cluster B :
| Type de ressource | ID de ressource | Rôle |
|---|---|---|
| grappe | Lecteur | |
| groupe | accounting.* | Comme l'exige l'application |
| sujet | accounting.* | Comme l'exige l'application |
| txnid | accounting.* | Comme l'exige l'application |
| topic (spécifique à la rubrique de point de contrôle) | A.checkpoints.internal | Lecteur |
Le cluster A doit avoir les mêmes politiques d'accès à l'exception de la dernière qui doit être sur B.checkpoints.internal.
Contrôles utilisateur de mise en miroir
Vous pouvez configurer la mise en miroir à l'aide de l'interface de ligne de commande ou de l'API REST d'administration. Tous les contrôles utilisateur de mise en miroir sont exécutés sur le cluster cible.
Configuration de la sélection de rubriques
La sélection de la mise en miroir est effectuée sur la base des noms des sujets sur le cluster source en utilisant des motifs d'expression régulière (regex). Choisissez soigneusement les noms des rubriques de votre cluster source en prenant en compte les conseils de la section Remarques relatives au partage de clusters entre plusieurs entités.
Avec des noms de sujet bien structurés, tels que l'ajout d'un préfixe à des rubriques faisant partie du même groupe ou application, il est facile de contrôler la mise en miroir. Avec une telle convention de dénomination en place, tous les sujets futurs qui correspondent au modèle sont automatiquement reflétés sans qu'il soit nécessaire d'apporter d'autres modifications.
La sélection du sujet est donnée sous la forme d'une liste d'une ou plusieurs expressions rationnelles. Une rubrique est sélectionnée si elle correspond à l'un des modèles de la liste.
Exemples de modèles permettant de sélectionner des rubriques pour la mise en miroir :
| Exemples de modèles | Explication |
|---|---|
^topic1$ |
Noms de rubrique complets. Cela correspond uniquement à la rubrique unique nommée topic1. |
^topic1$,^topic2$ |
Liste des modèles correspondant aux noms de rubrique complets. Cela correspond aux deux rubriques nommées topic1 et topic2. |
^aaa.* |
Correspond au préfixe. Correspond à tout nom de rubrique commençant par aaa. |
^aaa.*,^bbb.* |
Liste des modèles correspondant au préfixe. Correspond à tout nom de rubrique commençant par aaa ou bbb. |
^branch_[0-9]{3}_[a-z]*$ |
Modèle d'expression régulière plus complexe permettant d'apparier des noms de rubrique. Il correspond à tout nom de rubrique commençant par branch_, suivi de exactement 3 chiffres, suivi de _ et d'un nombre
quelconque de lettres minuscules. |
.* |
Mise en miroir de toutes les rubriques source. |
Lors de l'utilisation de l'interface de ligne de commande, les canevas sont fournis sous la forme d'une liste séparée par des virgules. Par exemple, la commande suivante sélectionne toutes les rubriques dont le nom comporte le préfixe accounting ou hr.
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
La commande suivante montre comment effectuer la même sélection à l'aide de l'API REST d'administration. Les modèles se présentent sous la forme d'un tableau JSON nommé "includes".
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^accounting.*", "^hr.*"]}'
La mise à jour d'une sélection de thèmes remplace l'ensemble actuel de motifs.
Pour supprimer la sélection afin qu'aucune rubrique ne soit mise en miroir, utilisez l'option --none avec l'interface de ligne de commande ou un canevas vide avec l'API REST d'administration, comme suit.
ibmcloud es mirroring-topic-selection-set --none
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":[""]}'
Pour désactiver sélectivement la mise en miroir, appliquez à nouveau la sélection de thèmes en omettant les motifs que vous souhaitez désactiver. Par exemple, lorsque topic1, topic2, topic3 sont actuellement mis en miroir, les commandes suivantes désactivent la mise en miroir pour topic2 mais laissent les deux autres activés.
ibmcloud es mirroring-topic-selection-set --select '^topic1$,^topic3$'
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^topic1$","^topic3$"]}'
Extraction de la sélection de rubriques
Vous pouvez récupérer la sélection de la mise en miroir en utilisant les interfaces suivantes :
Interface CLI:
ibmcloud es mirroring-topic-selection
API REST :
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
Extraction des rubriques actives
Vous pouvez récupérer les rubriques qui font l'objet d'une mise en miroir active en utilisant les interfaces suivantes :
Interface CLI:
ibmcloud es mirroring-active-topics
API REST :
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
Création d'applications prenant en charge la mise en miroir
Producteurs
Nous recommandons aux producteurs de ne produire que des sujets locaux. Le changement de fournisseur entre les instances nécessite généralement un changement de configuration, de sorte que le fournisseur utilise les noeuds finaux et les données d'identification appropriés pour se connecter.
Consommateurs
Les consommateurs doivent s'abonner à des rubriques locales et distantes et consommer dans celles-ci. Ce qui est possible avec un abonnement permettant l'utilisation de caractères génériques. Par exemple, pour consommer à partir de accounting.invoice et de accounting.invoice.<ALIAS>, utilisez l'abonnement à accounting.invoice.*.
Lorsque vous consommez des rubriques locales et distantes, vérifiez si l'application requiert un ordre strict. Dans ce cas, les sujets éloignés doivent d'abord être entièrement consommés avant de commencer à consommer les sujets locaux. De cette façon, les messages sont traités dans l'ordre selon lequel ils ont été produits.
Positions de consommateur
Lorsque les données de message sont mises en miroir entre deux instances, il existe un certain nombre de raisons pour lesquelles les décalages affectés au message dans l'instance source peuvent ne pas correspondre au décalage utilisé dans l'instance cible. Exemple :
- Suppression et recréation d'une rubrique portant le même nom dans l'instance source.
- Mise en miroir de rubriques avec une stratégie de nettoyage compacte.
- Génération de messages à l'aide de transactions.
Une partie du processus de mise en miroir des messages suit les décalages dans l'instance source qui sont équivalents aux décalages dans l'instance cible. Pour des raisons d'efficacité, seul un petit nombre de décalages équivalents sont suivis, les emplacements proches de la tête de la rubrique étant favorisés. Lorsque des décalages sont validés pour des groupes de consommateurs dans l'instance source, ils sont convertis en décalage équivalent le plus proche dans l'instance cible et un décalage correspondant est validé pour le groupe dans l'instance cible. Cette conversion est destinée à garantir qu'un consommateur qui bascule sur le cluster cible ne passe pas par les messages qui ont été mis en miroir. Cependant, comme tous les décalages équivalents ne sont pas suivis par le processus de mise en miroir, lorsqu'un consommateur bascule vers l'instance cible, il est probable qu'il retraite les données qu'il a déjà consommées dans l'instance source.
Lorsque vous écrivez des applications qui suivent la progression du consommateur en validant des décalages, tenez compte des éléments suivants:
- Les décalages de consommateur ne sont mis en miroir que si le groupe de consommateurs correspondant n'est pas activement utilisé dans l'instance cible.
- Prévoyez de retraiter certaines données de message lorsque le consommateur se déplace vers l'instance cible.
- Plus un consommateur se trouve derrière la tête de la rubrique lorsqu'il se déplace vers l'instance cible, plus il aura besoin de données à reconsommer.
- Si vous souhaitez réduire la quantité de données réconsommées et que vous pouvez gérer avec précaution les applications de commutation entre les instances, l'ensemble d'étapes recommandé pour ce faire est le suivant:
- Arrêtez de générer des messages sur l'instance source.
- Attendez que le consommateur rattrape la tête du sujet.
- Validez un décalage à cet emplacement.
- Basculez le consommateur vers l'instance cible.
Surveillance de la mise en miroir
Vous pouvez surveiller la mise en miroir en utilisant IBM Cloud Monitoring. Pour activer la surveillance, voir Surveillance des métriques Event Streams. Le tableau de bord Surveillance est disponible sur le cluster cible.
Le tableau de bord Mise en miroir Event Streams présente les métriques suivantes :
- Débit de mise en miroir : nombre d'octets par seconde du débit de mise en miroir à partir de l'instance Event Streams source. Cette fonction est utile pour savoir si la mise en miroir est active et pour planifier la capacité.
- Temps d'attente de la mise en miroir : temps d'attente, en secondes, de la mise en miroir par rubrique à partir de l'instance Event Streams source. Cette métrique est utile pour déterminer le retard d'une rubrique sur le cluster cible.
Les données produites dans la fenêtre de latence peuvent ne pas être encore présentes sur le cluster cible et peuvent encore être perdues si un désastre survient sur le cluster source. Néanmoins, si la mise en miroir est à jour, une reprise en ligne sans perte de données est possible lorsque l'intégrité des deux clusters est préservée.
Description des objectifs de reprise avec la mise en miroir
Dans un plan de protection des données tel que la mise en miroir, l'objectif de point de reprise (RPO) et l'objectif de temps de reprise (RTO) sont des paramètres clés. Vous devez comprendre les décisions associées à ces objectifs.
Vous pouvez surveiller l'objectif du point de récupération en utilisant la mesure de latence de la mise en miroir fournie dans le tableau de bord de la mise en miroir. Cette métrique montre le décalage entre les deux clusters, de sorte que vous pouvez estimer la quantité de perte de données en cas de sinistre. Il vous incombe de contrôler cette valeur et de veiller à ce qu'elle s'inscrive dans votre RPO.
L'objectif de temps de reprise est entièrement contrôlé par les utilisateurs et se compose des périodes suivantes :
- Le temps nécessaire à l'utilisateur pour décider de basculer.
- Le temps nécessaire à l'utilisateur pour basculer ses applications.
Tests
Testez la reprise après incident lorsque vous avez rendu vos applications compatibles avec la mise en miroir. Effectuez les étapes décrites dans l'exemple de scénario de reprise après incident et utilisez les tableaux de bord Surveillance pour vous assurer que toutes les étapes se terminent comme prévu.
Suppression et recréation de sujets portant le même nom sur le cluster source
Lorsque des rubriques sont supprimées sur le cluster source, les rubriques correspondantes sur le cluster cible ne sont pas automatiquement supprimées. Si vous recréez ensuite la rubrique sur le cluster source, les données de la nouvelle rubrique dans le cluster source seront ajoutées à la fin de la rubrique existante dans le cluster cible.
Remarques relatives à Kafka Streams et Kafka Connect
Kafka Streams et Kafka Connect s'appuient sur des rubriques internes portant un nom spécifique pour stocker l'état et la configuration. Lorsque ces rubriques sont mises en miroir, elles sont renommées sur le cluster cible. Pour cette raison, les applications Kafka Streams et Kafka Connect ne peuvent pas basculer et revenir en arrière entre les clusters. Tenez compte de ce point lorsque vous planifiez la reprise après incident de ces applications.