Présentation de LinK, un gestionnaire d'IP virtuel soutenu par etcd

LinK (LinK n'est pas Keepalived) est un gestionnaire d'IP virtuelles permettant d'atteindre une haute disponibilité. Il vise à simplifier le partage d'une seule IP entre plusieurs hôtes. Nous mettons ce outil en open source aujourd'hui sous la licence MIT afin que tout le monde puisse l'utiliser et qu'il soit libre de contribuer.

Nous avons introduit les Réseaux Définis par Logiciel (SDN) dans notre infrastructure grâce à LinK et SAND tout en travaillant sur un service d'Elasticsearch clusters élastiques et hautement disponibles sur Scalingo (SAND sera introduit dans un prochain article).

LinK est un agent de mise en réseau qui permet à plusieurs hôtes de partager une IP virtuelle. Il choisit quel hôte doit lier cette IP virtuelle et informe les autres membres du réseau de l'hôte qui la possède. Un cas d'utilisation typique est lorsque vous avez quelques proxys devant un cluster. L'un est le maître et l'autre est là au cas où il y aurait un problème avec le maître. Ce proxy de basculement lie l'IP virtuelle si le maître actuel est détecté comme défaillant afin que le cluster reste accessible.

Si vous souhaitez aller lire le code source directement, le code source de LinK se trouve dans ce dépôt GitHub.

Les Objectifs

Nous avions plusieurs objectifs avant de commencer le développement de ce logiciel. Tout d'abord, aucun contrôleur central ne devrait centraliser l'information. Lorsqu'on traite avec un environnement hautement distribué, vous voulez limiter la communication autant que possible. Avoir un agent autonome sachant comment réagir en cas de problème réseau est un grand avantage. Ainsi, l'architecture de LinK devrait être : un agent par hôte et c'est tout ! Pas de contrôleur central.

Un autre objectif fort est d'avoir toujours au moins un serveur liant l'IP virtuelle. En effet, cette IP est utilisée pour une configuration hautement disponible, donc elle doit toujours être accessible. À un moment donné, deux hôtes peuvent potentiellement lier l'IP virtuelle. Cela est parfaitement acceptable car cela ne l'empêche pas d'être accessible par quelqu'un.

Dernier point mais non le moindre, nous voulons suivre la philosophie UNIX : "Faites une seule chose et faites-la bien". LinK est uniquement responsable de la partie attribution d'IP. Il ne gérera pas l'équilibrage de charge ou d'autres choses de niveau supérieur.

Pourquoi ne pas utiliser Keepalived ?

Nous utilisons déjà Keepalived pour certains de nos composants internes (DNS, équilibreur de charge, etc.) et nous voulions d'abord l'utiliser pour ce mécanisme de basculement IP. Mais en spécifiant cela, nous avons rencontré certaines limitations de Keepalived.

La limitation la plus marquante est le nombre de planificateurs IP que Keepalived permet. Dans notre configuration, chaque base de données a besoin de son propre planificateur d'IP virtuelle. Avec Keepalived, vous devez spécifier un virtual_router_id différent dans la section vrrp_instance. Comme le virtual_router_id est codé sur un seul octet dans le protocole VRRP, nous n'aurions que 256 planificateurs d'IP virtuelle dans toute notre infrastructure. Cela n'est pas acceptable car cela nous limiterait à héberger moins de 256 clusters. D'autres architectures ont été envisagées mais chacune d'elles avait des inconvénients significatifs.

En travaillant sur ce problème, nous avons regardé comment le partage d'IP fonctionnait sur Keepalived et avons vu que c'était assez simple. La complexité de Keepalived provient de la planification des IP (déterminer quel nœud doit avoir l'IP). Dans Keepalived, cela se fait grâce au protocole VRRP. Cependant, chez Scalingo, nous avons déjà un composant distribué qui sait gérer les élections et les baux : etcd. Enfin, en bonus, si nous créons notre propre gestionnaire d'IP virtuelle, nous pourrions le contrôler via une API REST. C'est bien plus simple que de modifier des fichiers de configuration sur le disque !

Architecture de LinK

L'idée de l'architecture de LinK est d'avoir un agent sur chaque hôte qui pourrait potentiellement lier l'IP. Voici un aperçu global d'une infrastructure exécutant LinK :

Chaque hôte a une IP (dans la plage 192.168.0.0/16 sur l'exemple) et exécute un agent LinK. Tous les agents peuvent lier l'IP virtuelle (dans la plage 10.0.0.0/8). Etcd est accessible pour tous les hôtes. Notez que nous ne représentons que deux hôtes mais d'autres hôtes peuvent rejoindre ce réseau LinK d'agents.

Chacun des agents exécute la machine d'état suivante :

Il a trois états différents : - ACTIVATED : cet agent lie l'IP virtuelle, - STANDBY : cet agent ne possède pas l'IP virtuelle mais est disponible pour une élection, - FAILING : les contrôles de santé pour cet hôte ont échoué, cet agent n'est pas disponible pour une élection.

Et divers événements peuvent se produire. Ces événements modifieraient l'état de l'agent : - fault : il y a eu une erreur lors de la coordination avec d'autres nœuds, - elected : cet agent a été élu pour lier l'IP virtuelle, - demoted : cet agent vient de perdre la possession de l'IP virtuelle, - health_check_fail : les contrôles de santé configurés ont échoué, - health_check_success : les contrôles de santé configurés ont réussi.

Les contrôles de santé sont configurables. C'est un moyen de détecter qu'un hôte est en train de tomber en panne et ne devrait pas lier l'IP. Actuellement, l'agent LinK utilise une connexion TCP à l'hôte qui l'exécute afin de détecter une défaillance.

Avec cette machine d'état en place, chaque agent peut connaître de manière autonome quel état il est. Il est possible que deux agents différents soient dans l'état ACTIVATED. LinK est conçu pour gérer une telle situation. Ce n'est pas un problème et les hôtes essayant de se connecter à l'IP virtuelle finiront par utiliser l'un de ces hôtes.

Un élément manquant est comment synchroniser les agents LinK sans utiliser un contrôleur central. Notre solution est d'utiliser etcd, un magasin de clés/valeurs distribué.

Synchronisation des Agents

Les hôtes peuvent détecter qu'ils doivent lier l'IP grâce à etcd. Les agents LinK utilisent la fonctionnalité de bail d'etcd : un mécanisme de verrou avec un délai d'expiration. Tous les agents LinK essaient de prendre le verrou. Celui qui réussit à l'obtenir a le verrou pendant 6 secondes et lie donc l'IP virtuelle pendant cette période. Toutes les 3 secondes, il essaie de rafraîchir le bail (c'est-à-dire prolonger le verrou pour 6 secondes). S'il échoue à rafraîchir le bail, un autre agent obtiendra le bail et liera l'IP virtuelle.

Le dernier petit problème que nous devons résoudre est l'invalidation du cache ARP (Address Resolution Protocol). Comment s'assurer que tous les hôtes du réseau local sont informés du nouvel hôte liant l'IP virtuelle ?

Un Peu de Théorie sur l'ARP

L'ARP a été conçu à l'origine comme le lien entre les protocoles Ethernet et IP. Dans un réseau local, lorsqu'un hôte souhaite communiquer avec un autre hôte mais n'a que l'adresse IP de destination, il doit découvrir l'adresse MAC de destination. Le mécanisme pour ce faire est de diffuser une requête ARP, demandant l'adresse MAC correspondant à l'IP donnée. Afin d'accélérer ce processus, chaque hôte garde un cache des paires d'adresses IP / MAC. Ce cache ARP a un TTL court.

Sur notre infrastructure d'exemple, si un hôte souhaite communiquer avec l'Hôte 1 sur son adresse IP 192.168.0.1, il envoie une requête ARP à tous les hôtes du réseau local demandant l'adresse MAC de 192.168.0.1. L'Hôte 1 répondrait avec son adresse MAC, disons MAC 1.

Revenons à la situation LinK, si l'Hôte 1 lie l'IP virtuelle 10.0.0.1 et qu'un autre hôte (Hôte 3) essaie de communiquer avec lui, l'Hôte 1 répondra MAC 1 à la requête ARP. Un peu plus tard, l'Hôte 2 obtient le bail etcd et lie l'IP virtuelle 10.0.0.1. L'Hôte 3 a une entrée dans son cache ARP pour l'adresse IP 10.0.0.1 et envoie le message à MAC 1 tandis que l'Hôte 2 lie l'IP.

Cela est résolu en utilisant une requête ARP gratuite. Lorsqu'un agent lie l'IP, il diffuse une requête ARP gratuite où l'adresse IP source et de destination est définie sur l'IP virtuelle et l'adresse Ethernet source est l'adresse Ethernet de l'agent. Ainsi, tous les hôtes du même réseau sont informés que l'adresse IP est détenue par un agent spécifique, ce qui invalide leur cache.

Nous avons conçu LinK pour garantir un mécanisme de basculement entre les deux front HAProxy pour les clusters de base de données. LinK est maintenant open source car nous sommes convaincus qu'un gestionnaire d'IP virtuel propre, simple, tolérant aux pannes et hautement distribué peut bénéficier à beaucoup d'entre vous. Nous continuerons à l'utiliser et à y travailler en interne. Les contributions externes sont plus que bienvenues, nous acceptons les demandes de tirage. N'hésitez pas à l'utiliser, le code source de LinK est disponible dans ce dépôt GitHub.

Photo par Fabio Ballasina sur Unsplash