etcd : base de données pour les paires clé-valeur

Les systèmes distribués, tels que les plateformes sur le Cloud, gagnent en importance. Dans ce contexte, les bases de données individuelles cèdent la place à des clusters flexibles et évolutifs. Cela pose plusieurs nouveaux défis à de nombreux gestionnaires : pannes de réseau, ralentissements, débits de données limités, composants système à petite échelle et sécurité de la transmission des données sont autant d’enjeux auxquels les opérateurs doivent faire face de manière intensive.

Une solution possible consiste à centraliser les informations modifiables dans un endroit sûr, résistant aux pannes et cohérent, comme la très pratique base de données clé-valeur (Key Value Store) etcd.

etcd est une Key Value Store distribuée, qui a été développée par l’équipe de développement CoreOS et écrite, comme le sont de nombreux outils utilisés dans un environnement Docker, dans le langage de programmation « Go » de Google. L’objectif de ce développement était de créer un espace de stockage sécurisé pour les données sensibles provenant d’applications distribuées et qui rende la gestion gérable.

Dans les systèmes d’exploitation GNU/Linux, le nom du répertoire des fichiers de configuration reprend les lettres « /etc », tandis que le « d » qui y est attaché signifie « distribué ». Désormais, etcd est géré en tant que logiciel open source par la Cloud Native Computing Foundation.

Pour comprendre etcd, il est important de connaître les trois concepts clés du cluster d’applications pour la gestion du stockage :

• Chef (leader)
• Élections (elections)
• Période (terms)

Dans les systèmes Raft, le cluster élit un chef pour une période donnée. Il traite toutes les demandes de stockage qui correspondent au consensus du cluster. Les demandes qui ne nécessitent pas le consentement du cluster, comme les accès en lecture, peuvent être traitées indépendamment par chaque membre du cluster. Si le chef accepte un changement, etcd s’assure qu’il reproduit l’information aux nœuds successeurs. Dès réception de la confirmation, le chef prend en charge le changement.

La coordination du chef avec les nœuds du cluster via une base de données etcd est particulièrement précieuse pour les applications distribuées. Si des changements affectent le fonctionnement d’un nœud, celui-ci peut bloquer les changements. Cela permet de stabiliser l’application et réduire au minimum les problèmes ultérieurs.

Si le chef échoue ou ne répond pas pendant une longue période, les nœuds restants du cluster élisent un nouveau chef après un certain temps. Le temps nécessaire à un nœud pour demander une nouvelle élection et se désigner comme candidat varie d’un nœud à l’autre. Ceci est déterminé par un « chronomètre » dont dispose chaque nœud. Cela permet aux nœuds d’intervenir en tant que chefs le plus rapidement possible.

Pour garantir une majorité à chaque élection, le nombre de nœuds du cluster doit être impair. Pour des raisons de performance, il est recommandé de ne pas utiliser un cluster comportant plus de sept nœuds.

Outre le fait que l'application fonctionne de manière stable, une base de données etcd présente de nombreux autres avantages :

• Entièrement réplicable : toute la mémoire est disponible sur chaque nœud du cluster.
• Haute disponibilité : les bases de données etcd évitent les sources d’erreur comme les problèmes de matériel ou de réseau.
• Cohérent : chaque opération de lecture renvoie la dernière opération d’écriture sur plusieurs hôtes.
• Simple : etcd contient une API orientée utilisateur (gRPC) bien définie, basée sur REST et JSON.
• Sécurisé : etcd met automatiquement en place une transmission sécurisée via SSL/TLS. En option, vous pouvez utiliser l’authentification par certificat client.
• Rapide : l’évaluation comparative atteint plus de 10 000 opérations d’écriture par seconde.
• Fiable : l’algorithme Raft garantit toujours une distribution correcte de la mémoire.

Dès 2014, les développeurs ont mis en place etcd dans Kubernetes, ce qui a conduit à une croissance rapide de la communauté etcd. Les fournisseurs de services dans le Cloud tels que AWS, Google Cloud Platform et Azur ont suivi le mouvement en déployant avec succès etcd dans leurs environnements de production.

Mais revenons sur le premier exemple d’etcd mentionné : Kubernetes. Kubernetes est lui-même un système distribué fonctionnant sur un cluster de plusieurs machines. Par conséquent, il bénéficie largement d’un stockage de données distribué comme etcd, qui permet de conserver les données sensibles en toute sécurité. Dans Kubernetes, la base de données etcd sert de magasin de données principal, dans lequel sont stockés les données de configuration, l’état et les métadonnées. Si des modifications sont apportées, etcd garantit que tous les nœuds du cluster Kubernetes peuvent lire et écrire les données. En même temps, etcd surveille l’état actuel ou souhaité du système. Si les états diffèrent, Kubernetes apporte des modifications pour les remettre en conformité.