Accueil Nos publications Blog Service Discovery avec Consul
Architecture
Niveau
05/07/2016 6 min

Service Discovery avec Consul

consul-ioDéveloppé par HashiCorp, Consul est un projet récent constitué d’un ensemble de composants qui fournissent des fonctionnalités de découverte et de configuration de services, à l’échelle d’une infrastructure. Le “Service Discovery” est une idée générale, qui tend à se développer dans les conceptions de systèmes d’informations, non seulement en raison d’architectures orientées services et microservices, mais aussi dans les environnements de calculs de plus en plus dynamiques, voire éphémères, à l’instar d’un EC2 ou d’un Azure.

Il combine les fonctionnalités suivantes :

feature-discovery

Service Discovery

Les clients Consul enregistrent des services comme une base de données ou une API. D’autres clients peuvent ainsi utiliser Consul afin de découvrir l’emplacement de ces services via des requêtes DNS ou REST.

feature-health

HealthCheck

Les Clients Consul publient des HealhChecks associés aussi bien à des applications, du plus simple (Etat de la base de données, Réponse valide du Web Service) au plus complexe (Nombre d’utilisateurs/sessions actives, temps de réponse moyen des requêtes), mais aussi à des états des machines (Consommation Mémoire, utilisation CPU). Ces informations servent à la fois au monitoring du cluster ainsi qu’au système de découverte afin d’éviter de router des requêtes vers des nœuds inaccessibles.

feature-config

Key/Value Store

Les applications peuvent utiliser Consul comme un système de stockage clé/valeur hiérarchique au travers d’une simple API REST.

feature-multi

Multi Datacenter capabilities

Consul fournit de facto le support multiple Datacenter, évitant ainsi l’intégration d’une couche d’abstraction supérieure.

Comment ça marche ?

Consul est construit autour d’un exécutable, l’Agent, qui est utilisable au travers de deux configurations, les ‘Serveurs’ et les ‘Clients’:

L’Agent

L’agent est un daemon qui s’exécute sur tous les membres du cluster Consul. Un agent peut s’exécuter en mode ‘Client’ ou ‘Serveur’. Tous les agents exposent les interfaces DNS et REST. Ils sont aussi responsables de l’exécution des HealhChecks et maintiennent la synchronisation des services.

Clients

Les Clients sont des agents dont les seuls rôles sont de faire suivre les requêtes aux Serveurs et de participer au ‘LAN GOSSIP’. Ils ne consomment donc que peu de ressources locales et réseaux.

Serveur

Au nombre minimum de trois par Datacenter, les Serveurs ont la charge de participer à la gestion du consensus au travers de l’algorithme RAFT (RAFT quorum), monitorer l’état du cluster, faire suivre les requêtes aux leaders et aux autres datacenters, répondre aux requêtes et participer aux échanges du ‘WAN GOSSIP’.

GOSSIP Protocol

Le GOSSIP Protocol, aussi appeler Epidemic Protocol, est la pièce maitresse des échanges d’information au sein du cluster Consul.

On peut facilement illustrer son fonctionnement par l’analogie de diffusion d’une rumeur.

Explication :
Toutes les heures, un ensemble de collègues se retrouve autour de la machine à café. Ils se regroupent en petits groupes aléatoires et partagent la dernière rumeur.

Au début de la journée, Alice échange avec Bob une nouvelle rumeur à propos de Charlie.
A la réunion suivante, Bob va partager cette information avec David, tandis qu’Alice fera de même avec Eve.

gossip

On peut grossièrement dire qu’à chaque réunion, le nombre de personnes informées de la rumeur a doublé, jusqu’à atteindre l’ensemble des personnes présentes.

La robustesse de ce protocole réside dans sa diffusion de l’information. En effet, si David n’a pas compris ce que Bob lui a dit, il sera informé lors d’une des réunions suivantes.

Dans Consul, ce protocole se décline en deux formes :

LAN

Il a pour but de diffuser l’information dans un même datacenter au travers de tous les nœuds présents.

WAN

Celui-ci est réservé uniquement aux nœuds en mode ‘Serveur’, afin de partager les informations de leur datacenter avec tous les autres Serveurs présents dans le cluster et ainsi propager la liste des applications et leur état dans tous les datacenters.

Fonctionnalités avancées

Depuis la version 0.6, Consul nous offre de nouvelles fonctionnalités très intéressantes.

Network Tomography

En intégrant une implantation de l’algorithme Vivaldi, Consul maintient une table de RTT (Round Trip delay Time) entre chacun des nœuds du cluster.


#Get the estimated RTT from current node to another
$ consul rtt nyc3-server-1
Estimated nyc3-server-1  nyc3-server-2 rtt: 1.091 ms (using LAN coordinates)

#Get the estimated RTT between two other nodes from a third node
$ consul rtt nyc3-server-1 nyc3-server-3
Estimated nyc3-server-1  nyc3-server-3 rtt: 1.210 ms (using LAN coordinates)

#Get the estimated RTT from current server to one in another datacenter
$ consul rtt -wan sfo1-server-1.sfo1
Estimated sfo1-server-1.sfo1  nyc3-server-2.nyc3 rtt: 79.291 ms (using WAN coordinates)

L’intérêt réside dans la capacité à fournir une réponse triée par le temps de latence réseaux constatée au moment de la requête.


# Get a list of healthy nodes providing the "redis" service sorted
# relative to a specific node by RTT
$ curl localhost:8500/v1/health/service/redis?passing&near=nyc3-server-2

# Get the full list of nodes sorted relative to a specific node by RTT
$ curl localhost:8500/v1/catalog/nodes?near=nyc3-server-2

Prepared Query

Auparavant, l’interface DNS de Consul était populaire par sa simplicité d’utilisation, mais les possibilités fournies par les requêtes DNS étaient limitées. Désormais, un nouvel end point permet la construction de requêtes plus complexes qui seront stockées et propagées dans le cluster. Ces requêtes pré-enregistrées seront exécutées à chaque appel au travers de l’interface DNS comme le montre l’exemple ci-dessous.


$ curl -X POST -d \
'{
  "Name": "redis-with-failover",
  "Service": {
    "Service": "redis",
    "Failover": {
      "NearestN": 3
    },
    "Tags": ["master", "!experimental"]
  },
  "DNS": {
    "TTL": "10s"
  }
}' localhost:8500/v1/query

{"ID":"5e1e24e5-1329-f86f-18c6-3d3734edb2cd"}

Lors du DNS Lookup, Consul va executer les étapes suivantes :
1. Regarder si dans le datacenter local, les instances du service ‘redis’ sont disponibles
2. Filtrer les instances en fonctions de leurs tags (‘master’ et non ‘experimental’)
3. Si aucune instance n’est disponible, une demande sera envoyée aux trois plus proches datacenters
4. Le résultat sera renvoyé avec un TTL de 10 secondes


$ dig redis-with-failover.query.consul. ANY
; <> DiG 9.8.3-P1 <> redis-with-failover.query.consul. ANY
;; global options: +cmd

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29981
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;redis-with-failover.query.consul. IN   ANY

;; ANSWER SECTION:
redis-with-failover.query.consul. 0 IN  A   10.0.3.83
redis-with-failover.query.consul. 0 IN  A   10.0.1.109
redis-with-failover.query.consul. 0 IN  A   10.0.2.62

Alternatives

ZooKeeper

ZooKeeper est un système de ficher clustérisé. Il fournit un magasin de configurations (consistent configuration store) en privilégiant la cohérence des données à leurs disponibilités. En effet, lors d’une partition réseau, la division la plus petite s’arrêtera systématiquement. C’est un projet mature et établi qui dispose d’un écosystème riche et d’une grande qualité.

Etcd

Etcd est un magasin clé/valeur distribué, exposé via une API REST. Il embarque un algorithme de consensus qui lui permet d’être résilient face aux partitions réseaux ou aux défaillances machines. La cohérence des données est garantie par l’élection d’un leader qui est responsable de l’écriture des données et de leurs réplications vers les autres nœuds du cluster.

Eureka

Eureka est un ‘mid-tier loadbalancer” développé par Netflix et fourni en tant que projet open-source. Comme tous les projets Netflix OSS, il a été construit avant tout pour fonctionner sur la plateforme AWS. Eureka privilégie la disponibilité à la cohérence des données. Il faut être conscient des implications de ce comportement, car l’impact sur vos applications peut être important. En effet, lors d’une partition réseaux, chaque partie fonctionnera de manière autonome quitte à fournir des informations expirées ou partielles.

Conclusion

Pour finir, je dirais que Consul est un projet qui a été explicitement développé afin de proposer une réponse cohérente aux différentes problématiques que pose la découverte de services dans une infrastructure complexe. Il propose un certain nombre de fonctionnalités intéressantes afin de gérer le plus finement possible le routage de vos services. Il évolue rapidement et commence à s’implanter dans de grandes structures. C’est donc tout naturellement que je vous invite à ajouter ce projet dans votre liste de projets à suivre de près.

© SOAT
Toute reproduction interdite sans autorisation de la société SOAT

Rédigé par :

Michel VACHER