Vidéo: MapR, la distribution Hadoop BigData ouverte à l'échelle de l'entreprise. 2025
Zookeeper est un cluster distribué de serveurs qui fournit collectivement des services de coordination et de synchronisation fiables pour les applications en cluster. Certes, le nom "Zookeeper" peut sembler au premier abord être un choix étrange, mais quand vous comprenez ce qu'il fait pour un cluster HBase, vous pouvez voir la logique qui le sous-tend. Lorsque vous construisez et déboguez des applications distribuées "c'est un zoo là-bas", vous devriez donc mettre Zookeeper dans votre équipe.
Les clusters HBase peuvent être énormes et la coordination des opérations des serveurs MasterServers, RegionServers et des clients peut être une tâche ardue, mais c'est là que Zookeeper entre dans l'image. Comme dans HBase, les clusters Zookeeper s'exécutent généralement sur des serveurs x86 peu coûteux.
Chaque serveur x86 individuel exécute un seul processus logiciel Zookeeper (ci-après appelé un serveur Zookeeper), avec un serveur Zookeeper élu par l'ensemble comme leader et le reste des serveurs sont des suiveurs. Les ensembles de zookeeper sont régis par le principe du quorum de la majorité.
Les configurations avec un serveur Zookeeper sont supportées à des fins de test et de développement, mais si vous voulez un cluster fiable capable de tolérer une défaillance du serveur, vous devez déployer au moins trois serveurs Zookeeper pour atteindre un quorum majoritaire.
Alors, de combien de serveurs Zookeeper aurez-vous besoin? Cinq est le minimum recommandé pour l'utilisation en production, mais vous ne voulez vraiment pas aller au strict minimum. Lorsque vous décidez de planifier votre ensemble Zookeeper, suivez cette formule simple: 2F + 1 = N où F est le nombre d'échecs que vous pouvez accepter dans votre cluster Zookeeper et N est le nombre total de serveurs Zookeeper que vous devez déployer.
Cinq est recommandé car un serveur peut être arrêté pour maintenance, mais le cluster Zookeeper peut toujours tolérer une panne de serveur.
Zookeeper assure la coordination et la synchronisation avec ce qu'il appelle znodes , qui sont présentés comme une arborescence de répertoires et ressemblent aux noms de chemins de fichiers que vous verriez dans un système de fichiers Unix. Les Znodes ne stockent que peu de données - actuellement moins de 1 Mo par défaut.
L'idée ici est que Zookeeper stocke les znodes en mémoire et que ces znodes basés sur la mémoire fournissent un accès client rapide pour la coordination, le statut et d'autres fonctions vitales requises par les applications distribuées comme HBase. Zookeeper réplique les znodes dans l'ensemble. Si les serveurs tombent en panne, les données znode sont toujours disponibles tant qu'un quorum majoritaire de serveurs est encore opérationnel.
Un autre concept principal de Zookeeper concerne la façon dont les znodes sont lus (par rapport aux écritures). N'importe quel serveur Zookeeper peut gérer les lectures d'un client, y compris le leader, mais seul le responsable émet des erreurs atomic znode - écrit qui réussit complètement ou échoue complètement.
Lorsqu'une requête d'écriture znode arrive au noeud leader, le leader diffuse la requête d'écriture sur les noeuds suiveurs et attend qu'une majorité de suiveurs reconnaissent que l'écriture znode est terminée. Après l'accusé de réception, le responsable émet le znode lui-même, puis signale l'état d'achèvement réussi au client.
Les Znodes offrent des garanties très puissantes. Lorsqu'un client Zookeeper (tel qu'un HBase RegionServer) écrit ou lit un znode, l'opération est atomic . Il réussit complètement ou échoue complètement - il n'y a pas de lectures ou d'écritures partielles.
Aucun autre client concurrent ne peut provoquer l'échec de l'opération de lecture ou d'écriture. En outre, un znode est associé à une liste de contrôle d'accès (ACL) pour la sécurité et prend en charge les versions, les horodatages et les notifications aux clients lorsqu'il est modifié.
Zookeeper réplique les znodes dans l'ensemble. Si les serveurs tombent en panne, les données znode sont toujours disponibles tant qu'un quorum de serveurs majoritaire est encore opérationnel. Cela signifie que l'écriture sur un znode à partir de n'importe quel serveur Zookeeper doit être propagée dans l'ensemble. Le chef Zookeeper gère cette opération.
Cette approche d'écriture en znode peut amener les suiveurs à rester derrière le leader pendant de courtes périodes. Zookeeper résout ce problème potentiel en fournissant une commande de synchronisation. Les clients qui ne peuvent pas tolérer ce manque de synchronisation temporaire dans le cluster Zookeeper peuvent décider d'émettre une commande de synchronisation avant de lire les znodes.
