5.9. Service registry

Le service registry est le composant permettant à chaque service de localiser les services dont il dépend ; par conséquent, son bon fonctionnement est particulièrement critique pour le bon fonctionnement du système VITAM.

5.9.1. Architecture

Un déploiement Consul est composé de 2 types de noeuds différents :

  • Les noeuds serveurs : ils persistent l’état des données stockées dans Consul ; les données sont répliquées entre eux, et eux seuls participent à l’élection du maître (ils forment un cluster Raft). Un quorum de ces noeuds doit toujours être déclaré ; dans le cas contraire, on entre dans un cas de désastre de cluster (Cf. la documentation sur l‘“outage recovery” ) ; le nombre de serveurs doit être impair, avec un minimum conseillé de 3 noeuds (pour des problématiques de maintien de quorum).
  • Les noeuds client : ils exposent les API d’accès aux structures de données Consul, et réalisent les healthchecks des services dont ils ont la définition. Ils communiquent avec les serveurs.

Un noeud Consul est également appelé un agent.

Note

Les noeuds serveurs sont en fait des noeuds clients réifiés, i.e. ils ont également les capacités des clients.

Dans le cadre de VITAM, le déploiement des noeuds Consul doit correspondre aux principes suivants :

  • Un cluster de serveurs Consul sur un nombre impair de noeuds dédiés, chacun d’entre eux étant configuré pour exposer l’IHM de suivi ;
  • 1 client par serveur hébergeant un service VITAM.

Note

Préconisation : Le fonctionnement de Consul via trois noeuds master au minimum nous prémunit de la perte d’un de ces noeuds sans perturbation du service. Un seul noeud Consul est très déconseillé.

5.9.2. Résolution DNS

Les résolutions de noms de service se font via l’API dns de Consul ; un resolver externe doit être configuré pour les requêtes externes.

Chaque client agit comme serveur DNS local ; il écoute sur le port udp 53 (sur la boucle locale - 127.0.0.1), et est configuré comme serveur DNS de l’OS (typiquement dans le fichier /etc/resolv.conf).

Prudence

Cela rend Consul incompatible avec d’autres implémentations de serveur DNS qui seraient lancées sur l’OS, et en particulier les cache DNS installés par défaut dans certaines distributions linux (ex: dnsmasq). En outre, il faut prendre garde à l’écrasement de la configuration du resolv.conf, qui doit garder 127.0.0.1 comme premier serveur DNS.

Note

Pour pouvoir écouter sur le port 53, Consul nécessite la capacité CAP_NET_BIND_SERVICE (Cf. la section suivante).

Lorsque le système fait une requête DNS, cette dernière arrive à l’agent Consul local et la séquence suivante est exécutée :

Note

Consul a pour l’instant été configuré en mode allow_stale = false (cf. la directive de configuration), ce qui signifie que chaque requête DNS se traduit par un appel RPC au noeud leader des serveurs Consul. Cela permet d’assurer la consistance des réponses DNS, mais peut potentiellement poser des problèmes de performance sur des larges déploiements. Il est possible de changer ce comportement (clés de configuration allow_stale et max_stale - qui permettent de préciser la durée maximum pendant laquelle le noeud répond aux requêtes DNS sans interroger le leader), et également de changer le TTL des réponses DNS (qui est par défaut gardé à 0).

5.9.3. Packaging

Vitam intègre des packages OS (rpm & deb) dédiés pour Consul ; ces packages permettent essentiellement :

  • De configurer Consul en tant que service systemd ;
  • De permettre le lancement de Consul sous l’utilisateur vitam ;
  • Enfin, ils intègrent une directive setcap de post-install pour attribuer la capacité CAP_NET_BIND_SERVICE au binaire /vitam/vitam-consul/bin/consul afin de permettre à ce dernier d’exposer une interface DNS sur le port 53 sans pour autant nécessiter les droits root.

5.9.4. Monitoring

Chaque instance de service doit être déclarée dans Consul ; cette déclaration se fait en déposant un fichier de configuration dans le répertoire de configuration de Consul. Ce fichier contient notamment l’identifiant du service ainsi que son port d’écoute, ainsi qu’une liste de healthchecks qui permettent à Consul de connaître l’état du service. Pour les services VITAM, ces healthchecks s’appuient sur les API de supervision qui ont été décrites dans la section dédiée.

Consul permet d’exposer une IHM Web permettant d’accéder à la topologie des services déployés (i.e. quel service sur quel noeud) et à leur état instantané.