Transfert haute disponibilité avancé avec Hermes

Découvrez comment les messages sont produits et consommés dans Hermes pendant un fonctionnement normal, un transfert à haute disponibilité avancée (AHA) et des scénarios de basculement.

Les instances de production ServiceNow fonctionnent dans des centres de données géographiquement séparés. Chaque centre de données est associé à un autre centre de données pour assurer la redondance et la prise en charge du basculement. Un centre de données est désigné comme le côté actif et l’autre comme étant en veille. Par exemple, votre instance peut être configurée dans les centres de données DC1 et DC2, avec DC1 comme côté actif.

Avec l’activation de StreamConnect, LES ou IDR, un nouveau cluster Hermes Kafka est mis en service dans les deux centres de données. Pour assurer une haute disponibilité et fournir une prise en charge du basculement, Hermes utilise une paire de clusters Kafka actifs/actifs, un dans chaque centre de données.

À proximité d’une grappe

Le cluster Kafka Hermes situé dans le même centre de données que l’instance est le cluster proche.

Grappe éloignée

La grappe exécutée dans l’autre centre de données est la grappe distante. L’inverse est vrai pour l’autre instance. Sa grappe proche se trouve dans son centre de données et sa grappe éloignée s’exécute dans l’autre centre de données.

Figure 1. Proches et lointains Grappes d’Hermès Kafka

Fonctionnement normal

Dans des conditions normales de fonctionnement, les messages sont produits par l’instance ou un client externe vers le cluster Hermes proche. Par exemple, si votre instance s’exécute dans le centre de données DC1, les messages sont générés vers le cluster Hermes proche dans DC1. Les messages envoyés à partir d’un client externe sont produits sur le cluster à l’aide d’un port dans la plage 400x définie dans l’URL d’amorce du producteur.

Lorsqu’une rubrique est créée dans Hermes, elle est créée dans les deux clusters. Deux processus consommateurs sont utilisés pour consommer les messages des deux clusters, mais un seul consommateur consomme activement dans des circonstances normales. Chaque consommateur doit utiliser des URL d’amorçage distinctes, l’une dans la gamme 410x et l’autre dans la gamme 420x.

Processus de basculement

Dans les circonstances suivantes, le cluster dans lequel les messages sont produits peut changer.

Transfert d’instance à haute disponibilité avancée (AHA)

Lorsqu’une instance subit un transfert AHA, l’instance de secours devient active et l’instance précédemment active devient secondaire. Dans ce scénario, l’instance passe à l’utilisation du cluster Hermes du côté nouvellement actif.

Par exemple, si l’instance s’exécute dans les centres de données DC1 et DC2 avec DC1 comme côté actif actuel et qu’un transfert AHA se produit, l’instance passe à l’utilisation du cluster Hermes dans DC2.

Basculement Hermes

L’instance surveille activement l’intégrité du cluster Hermes. S’il détecte des problèmes avec le cluster, il passe en mode basculement. Dans ce cas, jusqu’à ce que l’instance détecte que le cluster Hermes proche a récupéré, elle utilise le cluster Hermes près de l’instance de secours.

Par exemple, si l’instance s’exécute dans les centres de données DC1 et DC2 avec DC1 comme côté actif, elle utilise le cluster Hermes dans DC1. S’il détecte un problème avec le cluster Hermes dans DC1, il passe en mode de basculement Hermes et commence à produire des messages vers le cluster DC2 jusqu’à ce que le cluster DC1 soit à nouveau sain. Après la récupération, il reprend l’utilisation du cluster Hermes dans DC1.

En cas de basculement, si les consommateurs sont en retard, les deux consommateurs peuvent potentiellement consommer des messages jusqu’à ce que l’un des consommateurs ait terminé le traitement. Par exemple, si le côté actif actuel est DC1, le consommateur qui consomme DC1 traite activement les messages. Si un problème se produit dans le cluster DC1 entraînant le basculement vers le cluster DC2, le consommateur consommateur du cluster DC2 commence à traiter les messages. Si le consommateur consommant à partir du cluster DC1 était en retard, les deux consommateurs continuent à consommer des messages jusqu’à ce que le consommateur DC1 rattrape son retard.

Maintien de l’ordre

Si le maintien de l’ordre des messages est nécessaire, il incombe à l’application consommateur de le gérer. Notez que l’ordre global des messages dépend de la façon dont la rubrique est définie dans Kafka.