etcd
En savoir plus sur etcd, la base de données tolérante aux défaillance, à valeur clé et code source ouvert, qui sert de structure de données primaire pour Kubernetes et les autres plateformes distribuées.
Base de données
Arrière-plan noir et bleu
Qu'est-ce qu'etcd ?

etcd est un magasin à valeur clé distribué et à code source ouvert utilisé pour maintenir et gérer les informations critiques dont les systèmes distribués ont besoin pour continuer à fonctionner. Plus particulièrement, il gère les données de configuration, les données d'état et les métadonnées de Kubernetes, la plateforme d'orchestration de conteneur bien connue.

Comme toutes les charges de travail distribuées, les charges de travail conteneurisées ont des exigences de gestion complexes qui deviennent plus complexes fur et à mesure que la charge de travail augmente. Kubernetes simplifie le traitement de la gestion de ces charges de travail en coordonnant des tâches telles que la configuration, le déploiement, la reconnaissance de service, l'équilibrage de charge, l'ordonnancement des travaux et la surveillance de la santé à travers tous les clusters, qui peuvent fonctionner sur de multiples machines à de multiples endroits.

Mais pour réaliser cette coordination, Kubernetes a besoin d'un magasin de données qui fournit une code source unique et cohérent de la vérité sur le statut du système — tous ses clusters et pods et les applications qu'ils contiennent — à tout moment dans le temps. etcd est le magasin de données utilisé pour créer et maintenir cette version de la vérité.

etcd remplit un rôle similaire pour Cloud Foundry (lien hors ibm.com) - la plateforme sous forme de services (PaaS) multicloud à code source ouvert - et est une option viable pour coordonner le système critique et les métadonnées entre les clusters de toute application distribuée. Le nom « etcd » provient d'une convention de dénomination au sein de la structure de répertoire Linux : sous UNIX, tous les fichiers de configuration système d'un système unique sont contenus dans un dossier appelé « /etc; » dont « d » signifie « distribué ».

Voir la vidéo « C'est quoi etcd ? » pour une plongée plus profonde (6:09) :

Produits à la une

Bases de données pour etcd


Pourquoi etcd ?

Servir de structure des données qui maintient le fonctionnement d'une charge de travail distribuée n'est pas une mince affaire. Mais etcd est construit pour cette tâche, conçu depuis le début pour les qualités suivantes :

  • Entièrement répliqué : chaque nœud d'une grappe etcd a accès au magasin de données complet.
  • Hautement disponible : etcd est conçu pour n'avoir aucun point de défaillance unique et tolérer gracieusement les défaillances matérielles et les partitions réseau.
  • Fiable et cohérent : chaque donnée « lue » renvoie aux données les plus récentes « écrites » sur tous les clusters.
  • Rapide : etcd a été évalué à 10 000 écritures par seconde.
  • Sécurisé : etcd prend en charge supports le protocole TLS et l'authentification par certificat client de couche Secure Sockets Layer (SSl) facultative. Étant donné qu'etcd stocke des données de configuration vitales et hautement sensibles, les administrateurs doivent implémenter des contrôles d'accès basé sur les rôles au sein du déploiement et assurer que les membres des équipes qui interagissent avec etcd sont limités au niveau d'accès le moins privilégié nécessaire pour effectuer leurs tâches.
  • Simple : toute application, des applications web simples aux moteurs d'orchestration de conteneur hautement complexes tels que Kubernetes, peut lire ou écrire des données sur etcd en utilisant les  outils standard HTTP/JSON.

Notez qu'étant donné que les performance d'etcd dépendent fortement de la vitesse du disque de stockage, il est fortement recommandé d'utiliser des SSD dans les environnements etcd. Pour plus d'informations à ce propos et sur les exigences du stockage etcd, consulter « Utiliser Fio pour savoir si votre stockage est assez rapide pour etcd. »

 


Algorithme consensus Raft

etcd est construit sur l'algorithme consensus Raft pour assurer la cohérence du magasin de données entre tous nœuds d'une grappe - le principal enjeu d'un système distribué tolérant aux pannes.

Raft réalise cette cohérence via un nœud principal élu qui gère la réplication pour les autres nœuds de la grappe, appeléssuiveurs. Le nœud principal accepte les demandes des clients, qu'il transmet ensuite aux nœuds suiveurs. Une fois que le nœud principal s'est assuré qu'une majorité des nœuds suiveurs ont enregistré chaque nouvelle requête en tant qu'entrée de journal, il applique l'entrée à son automate local et renvoie le résultat de cette exécution — une « écriture » — au client. Si les abonnés tombent en panne ou que les paquets réseau sont perdus, le nœud principal réessaye jusqu'à ce que tous les suiveurs aient enregistré tout l'historique de manière cohérente.

Si un nœud suiveur ne parvient pas à recevoir un message du nœud principal dans un intervalle de temps spécifié, une élection est organisée pour sélectionner un nouveau nœud principal. Le suiveur se déclarecandidat, et les autres suiveurs votent pour lui ou tout autre nœud en fonction de leur disponibilité. Une fois le nouveau nœud principal élu, il commence à gérer la réplication, et le processus se répète. Ce processus permet à tous nœuds etcd de maintenir des copies hautement disponibles et systématiquement répliquées du magasin de données.


etcd et Kubernetes

etcd est inclus parmi les composants centraux de Kubernetes et sert de magasin de valeur clé principal pour créer un cluster Kubernetes fonctionnel et tolérant aux pannes. Le serveur API de Kubernetes stocke les données d'état de chaque grappe dans etcd. Kubernetes utilise la fonction « watch » d'etcd pour surveiller ces données et se reconfigurer lorsque des changements surviennent. La fonction « watch » stocke les valeurs qui représentent l'état réel et idéal de la grappe et peut initier une réponse quand elles créent une divergence.

Pour une présentation générale de la façon dont Kubernetes gère les clusters, les services, les nœuds d'employés, voir notre vidéo « Kubernetes Explained » :


CoreOS, antécédents et maintenance d'etcd

etcd a été créé par la même équipe que celle qui a conçu CoreOS Container Linux, un système d'exploitation de conteneur largement utilisé qui peut être opéré et géré efficacement à très grande échelle. Ils ont à l'origine construit etcd sur Raft pour coordonner les multiples copies de Container Linux simultanément, afin d'assurer la disponibilité ininterrompue de l'application.

En décembre 2018, l'équipe a fait don d'etcd à la Cloud Native Computing Foundation (CNCF), une organisation à but non lucratif qui maintient le code source, les domaines, les services hébergés, l'infrastructure de cloud d'etcd, ainsi que et d'autres propriété de projets comme les ressources à code source ouvert pour la communauté de développement cloud basée sur des conteneurs. CoreOS a fusionné avec Red Hat.

 


etcd vs ZooKeeper vs Consul

D'autres bases de données ont été développées pour gérer les informations coordonnées entre les clusters d'applications réparties. Les deux qui sont le plus couramment comparées à etcd sont ZooKeeper et Consul.

ZooKeeper

ZooKeeper a été créé à l'origine pour coordonner les données de configuration et les métadonnées entre les clusters Apache Hadoop. (Apache Hadoop (lien hors ibm.com) est un cadre de travail à code source ouvert, ou une collection d'applications, pour le stockage et le traitement de gros volumes de données sur des grappes de matériel standard.) ZooKeeper est plus ancien qu'etcd, et les leçons apprises en travaillant avec ZooKeeper ont influencé la conception d'etcd.

En conséquence, etcd possède des capacités importantes dont ZooKeeper ne dispose pas. Par exemple, contrairement à ZooKeeper, etcd peut réaliser les éléments suivants :

  • Permettre la reconfiguration dynamique de l'appartenance à un cluster.
  • Rester stable tout en effectuant des opérations lire/écrire sous de fortes charges.
  • Maintenir un modèle de données de contrôle des accès concurrents multi-version.
  • Proposer une surveillance clé fiable qui ne laisse jamais passer d'événements sans donner de notification.
  • Utiliser des primitives d'accès concurrent qui découplent les connexions des sessions.
  • Prendre en charge un large éventail de langues et de cadres de travail (ZooKeeper possède son propre proptocole Jute RPC personnalisé qui prend en charge des liaisons linguistiques limitées).

Consul

Consul est une solution de mise en réseau de services pour systèmes distribués, dont les capacités se situent quelque part entre celles d'etcd et le service maillage Istio pour Kubernetes. Comme etcd, Consul inclut un magasin de valeurs clés distribué basé sur l'algorithme Raft et supporte les interfaces de programmation d'applications (API) HHTP/JSON. Les deux proposent une configuration d'appartenance à un cluster dynamique, mais Consul ne contrôle pas aussi fort face aux multiples versions simultanées des données de configuration, et la taille maximum des bases de données avec laquelle il travaillera en confiance est plus petite.


etcd vs Redis

Comme etcd, Redis est un outil à code source ouvert, mais leurs fonctionnalités de base sont différentes.

Redis est un magasin de données mémoire et peut fonctionner comme une base de données, un cache ou un agent de messages. Redis prend en charge une plus grande variété de types et de structures de données qu'etcd et affiche des performances lire/écrire beaucoup plus rapides.

Mais ETCD dispose d'une tolérance aux pannes supérieure, d'un basculement plus solide et de capacités de disponibilité des données continues, et, le plus important, etcd fait durer toutes les données stockées dans le disque, en sacrifiant essentiellement la vitesse pour une plus grande fiabilité et une cohérence garantie. Pour ces raisons, Redis est mieux adapté pour servir de système de cache de mémoire distribué que pour le stockage et les informations de configuration de système distribué.


etcd et IBM Cloud

IBM a été l'un des premiers contributeurs au projet etcd, a soutenu le projet et a continué à contribuer depuis qu'il a été porté sur carte mère par le CNCF. L'un des neuf mainteneurs du projet est également un employé d'IBM.

IBM propose des IBM Cloud Databases for etcd, une solution de gestion de configuration de système distribué entièrement gérée, prête pour l'entreprise, hautement disponible et sécurisée.

Commencez par créer un compte IMB Cloud gratuit, et vous pourrez installer et configurer un cluster etcd dès aujourd'hui.

Produits à la une


Solutions connexes

IBM Cloud Databases for etcd

Découvrez-en plus sur IBM Cloud Databases for etcd qui offre un magasin de valeurs de clés adapté aux entreprises et entièrement géré pour contenir les données permettant de gérer votre cluster de serveurs.