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

Les systèmes dis­tri­bués, tels que les pla­te­formes sur le Cloud, gagnent en im­por­tance. Dans ce contexte, les bases de données in­di­vi­duelles cèdent la place à des clusters flexibles et évolutifs. Cela pose plusieurs nouveaux défis à de nombreux ges­tion­naires : pannes de réseau, ra­len­tis­se­ments, débits de données limités, com­po­sants système à petite échelle et sécurité de la trans­mis­sion des données sont autant d’enjeux auxquels les opé­ra­teurs doivent faire face de manière intensive.

Une solution possible consiste à cen­tra­li­ser les in­for­ma­tions mo­di­fiables 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 dis­tri­buée, qui a été dé­ve­lop­pée par l’équipe de dé­ve­lop­pe­ment CoreOS et écrite, comme le sont de nombreux outils utilisés dans un en­vi­ron­ne­ment Docker, dans le langage de pro­gram­ma­tion « Go » de Google. L’objectif de ce dé­ve­lop­pe­ment était de créer un espace de stockage sécurisé pour les données sensibles provenant d’ap­pli­ca­tions dis­tri­buées et qui rende la gestion gérable.

Dans les systèmes d’ex­ploi­ta­tion GNU/Linux, le nom du ré­per­toire des fichiers de con­fi­gu­ra­tion 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 Foun­da­tion.

Pour com­prendre etcd, il est important de connaître les trois concepts clés du cluster d’ap­pli­ca­tions 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 cor­res­pon­dent au consensus du cluster. Les demandes qui ne né­ces­si­tent pas le con­sen­te­ment du cluster, comme les accès en lecture, peuvent être traitées in­dé­pen­dam­ment par chaque membre du cluster. Si le chef accepte un chan­ge­ment, etcd s’assure qu’il reproduit l’in­for­ma­tion aux nœuds suc­ces­seurs. Dès réception de la con­fir­ma­tion, le chef prend en charge le chan­ge­ment.

La coor­di­na­tion du chef avec les nœuds du cluster via une base de données etcd est par­ti­cu­liè­re­ment précieuse pour les ap­pli­ca­tions dis­tri­buées. Si des chan­ge­ments affectent le fonc­tion­ne­ment d’un nœud, celui-ci peut bloquer les chan­ge­ments. Cela permet de sta­bi­li­ser l’ap­pli­ca­tion et réduire au minimum les problèmes ul­té­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é­ces­saire à 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 « chro­no­mètre » dont dispose chaque nœud. Cela permet aux nœuds d’in­ter­ve­nir en tant que chefs le plus ra­pi­de­ment possible.

Pour garantir une majorité à chaque élection, le nombre de nœuds du cluster doit être impair. Pour des raisons de per­for­mance, il est re­com­mandé de ne pas utiliser un cluster com­por­tant plus de sept nœuds.

Outre le fait que l'ap­pli­ca­tion fonc­tionne de manière stable, une base de données etcd présente de nombreux autres avantages :

• En­tiè­re­ment ré­pli­cable : toute la mémoire est dis­po­nible sur chaque nœud du cluster.
• Haute dis­po­ni­bi­lité : 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 uti­li­sa­teur (gRPC) bien définie, basée sur REST et JSON.
• Sécurisé : etcd met au­to­ma­ti­que­ment en place une trans­mis­sion sécurisée via SSL/TLS. En option, vous pouvez utiliser l’au­then­ti­fi­ca­tion par cer­ti­fi­cat client.
• Rapide : l’éva­lua­tion com­pa­ra­tive atteint plus de 10 000 opé­ra­tions d’écriture par seconde.
• Fiable : l’al­go­rithme Raft garantit toujours une dis­tri­bu­tion correcte de la mémoire.

Dès 2014, les dé­ve­lop­peurs ont mis en place etcd dans Ku­ber­netes, ce qui a conduit à une crois­sance rapide de la com­mu­nauté etcd. Les four­nis­seurs 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 en­vi­ron­ne­ments de pro­duc­tion.

Mais revenons sur le premier exemple d’etcd mentionné : Ku­ber­netes. Ku­ber­netes est lui-même un système distribué fonc­tion­nant sur un cluster de plusieurs machines. Par con­sé­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 Ku­ber­netes, la base de données etcd sert de magasin de données principal, dans lequel sont stockés les données de con­fi­gu­ra­tion, l’état et les mé­ta­don­nées. Si des mo­di­fi­ca­tions sont apportées, etcd garantit que tous les nœuds du cluster Ku­ber­netes 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, Ku­ber­netes apporte des mo­di­fi­ca­tions pour les remettre en con­for­mité.