Apache ZooKeeper est un système client/serveur pour la coordination distribuée qui expose une interface similaire à un système de fichiers, où chaque nœud (appelé znode ) peut contenir des données et un ensemble d'enfants. Chaque znode porte un nom et peut être identifié à l'aide d'un chemin de type système de fichiers (par exemple, /root-znode/sub-znode/my-znode).
Dans Apache HBase, ZooKeeper coordonne, communique et partage l'état entre les Masters et les RegionServers. HBase a pour politique de conception d'utiliser ZooKeeper uniquement pour les données transitoires (c'est-à-dire pour la coordination et la communication d'état). Ainsi, si les données ZooKeeper de HBase sont supprimées, seules les opérations transitoires sont affectées :les données peuvent continuer à être écrites et lues vers/depuis HBase.
Dans cet article de blog, vous obtiendrez une brève présentation de l'utilisation des znodes HBase. La version de HBase utilisée ici à titre de référence est la 0.94 (fournie avec CDH 4.2 et CDH 4.3), mais la plupart des znodes sont présents dans les versions précédentes et le seront probablement également dans les versions futures.
Le chemin du znode racine HBase est configurable à l'aide de hbase-site.xml, et par défaut l'emplacement est "/hbase". Tous les znodes référencés ci-dessous seront préfixés à l'aide de l'emplacement par défaut /hbase, et la propriété de configuration qui vous permet de renommer le znode particulier sera répertoriée à côté du nom de znode par défaut et mise en surbrillance en gras.
ZooKeeper fournit un shell interactif qui vous permet d'explorer l'état de ZooKeeper — exécutez-le en utilisant hbase zkcli et parcourez le znode via ls , comme dans un système de fichiers typique. Vous pouvez également obtenir des informations sur le contenu du znode en utilisant le get commande.
$ hbase zkcli [zk: localhost:2181(CONNECTED) 0] ls / [hbase, zookeeper] [zk: localhost:2181(CONNECTED) 1] ls /hbase [splitlog, online-snapshot, unassigned, root-region-server, rs, backup-masters, draining, table, master, shutdown, hbaseid] [zk: localhost:2181(CONNECTED) 2] get /hbase/root-region-server 3008@u1310localhost,60020,1382107614265 dataLength = 44 numChildren = 0 ...
Opérations
Les znodes que vous verrez le plus souvent sont ceux qui coordonnent les opérations telles que l'affectation de région, le fractionnement de journaux et le basculement principal, ou gardent une trace de l'état du cluster, tel que l'emplacement de la table ROOT, la liste des RegionServers en ligne et la liste des régions non affectées. .
| /hbase (zookeeper.znode.parent) | Le znode racine qui contiendra tous les znodes créés/utilisés par HBase |
| /hbase/idhbase (zookeeper.znode.clusterId) | Initialisé par le maître avec l'UUID qui identifie le cluster. L'ID est également stocké sur HDFS dans hdfs :/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | Contient l'emplacement du serveur hébergeant la région ROOT. Il est interrogé par le client pour identifier le RegionServer responsable de ROOT et demander les emplacements META. (Dans 0.96, la table ROOT a été supprimée dans le cadre de HBASE-3171, et ce znode est remplacé par /hbase/meta-region-server [zookeeper.znode.metaserver] qui contient l'emplacement du serveur hébergeant META.) |
| /hbase/rs (zookeeper.znode.rs) | Au démarrage, chaque RegionServer créera un sous-znode (par exemple /hbase/rs/m1.host) censé décrire l'état "en ligne" du RegionServer. Le maître surveille ce znode pour obtenir la liste RegionServer "en ligne" et l'utiliser pendant l'affectation/l'équilibrage. |
| /hbase/non attribué (zookeeper.znode.unassigned) | Contient un sous-znode pour chaque région non attribuée (par exemple, /hbase/unassigned/ |
| /hbase/maître (zookeeper.znode.master) | Le maître "actif" enregistrera sa propre adresse dans ce znode au démarrage, faisant de ce znode la source de vérité pour identifier quel serveur est le maître. |
| /hbase/maîtres de sauvegarde (zookeeper.znode.backup.masters) | Chaque maître inactif s'enregistrera comme maître de sauvegarde en créant un sous-znode (hbase/backup-master/m1.host). Ce znode est principalement utilisé pour savoir quelles machines sont disponibles pour remplacer le maître en cas de panne. |
| /hbase/arrêt (zookeeper.znode.état) | Décrit l'état du cluster, « Le cluster est-il opérationnel ? » Il est créé par le maître au démarrage et supprimé par le maître à l'arrêt. Il est surveillé par les RegionServers. |
| /hbase/drainage (zookeeper.znode.draining.rs) | Utilisé pour désactiver plus d'un RegionServer à la fois en créant des sous-znodes avec la forme serverName,port,startCode (par exemple, /hbase/draining/m1.host,60020,1338936306752). Cela vous permet de mettre hors service plusieurs RegionServers sans risquer que des régions soient temporairement déplacées vers un RegionServer qui sera mis hors service ultérieurement. Lisez ceci pour en savoir plus sur /hbase/draining. |
| /hbase/table (zookeeper.znode.masterTableEnableDisable) | Utilisé par le maître pour suivre l'état de la table lors des affectations (états de désactivation/activation, par exemple). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Utilisé par le séparateur de journaux pour suivre le journal en attente de relecture et son affectation. (Lisez ceci pour en savoir plus sur le fractionnement des journaux). |
Sécurité
La liste de contrôle d'accès (ACL) et les coprocesseurs du fournisseur de jetons ajoutent deux znodes supplémentaires :l'un pour synchroniser l'accès aux ACL de table et l'autre pour synchroniser les clés de chiffrement des jetons sur les nœuds du cluster.
| /hbase/acl (zookeeper.znode.acl.parent) | Le znode acl est utilisé pour synchroniser les modifications apportées à la table _acl_ par les commandes grant/revoke. Chaque table aura un sous-znode (/hbase/acl/tableName) contenant les ACL de la table. (Lisez ceci pour plus d'informations sur le contrôleur d'accès et l'interaction ZooKeeper.) |
| /hbase/tokenauth (zookeeper.znode.tokenauth.parent) | Le fournisseur de jetons est généralement utilisé pour permettre à une tâche MapReduce d'accéder au cluster HBase. Lorsqu'un utilisateur demande un nouveau jeton, les informations sont stockées dans un sous-znode créé pour la clé (/hbase/tokenauth/keys/key-id). |
Réplication
En règle générale, tous les znodes sont éphémères, ce qui signifie qu'ils décrivent un état "temporaire" - donc, même si vous supprimez tout de ZooKeeper, HBase devrait pouvoir les recréer. Bien que les znodes de réplication ne décrivent pas un état temporaire, ils sont censés être la source de vérité pour l'état de réplication, décrivant l'état de réplication de chaque machine. (Lisez ceci pour en savoir plus sur la réplication).
| /hbase/réplication (zookeeper.znode.réplication) | Znode racine contenant toutes les informations d'état de réplication HBase |
| /hbase/réplication/pairs (zookeeper.znode.replication.peers) | Chaque pair aura un sous-znode (par exemple /hbase/replication/peers/ |
| /hbase/replication/peers/ | Miroir du znode /hbase/replication/peers, mais ici chaque sous-znode (/hbase/replication/peer-state/ |
| /hbase/réplication/état (zookeeper.znode.replication.état) | Indique si la réplication est activée. La réplication peut être activée en définissant la configuration hbase.replication sur true, ou peut être activée/désactivée à l'aide de la commande start/stop dans le shell HBase. (Dans la version 0.96, ce znode a été supprimé et le znode d'état homologue ci-dessus est utilisé comme référence.) |
| /hbase/réplication/rs (zookeeper.znode.replication.rs) | Contient la liste des RegionServers dans le cluster principal (/hbase/replication/rs/ |
Procédures d'instantané en ligne
Les instantanés en ligne sont coordonnés par le maître à l'aide de ZooKeeper pour communiquer avec les serveurs de région à l'aide d'une transaction de type validation en deux phases. (Lisez ceci pour plus de détails sur les instantanés.)
| /hbase/instantané en ligne/acquis | Le znode acquis décrit la première étape d'une transaction d'instantané. Le maître créera un sous-znode pour l'instantané (/hbase/online-snapshot/acquired/ |
| /hbase/instantané en ligne/atteint | Une fois que chaque RegionServer a rejoint le znode acquis, le maître créera le znode atteint pour l'instantané (/hbase/online-snapshot/reached/ |
| /hbase/instantané en ligne/abandon | Si quelque chose échoue du côté maître ou du côté RegionServer, le znode d'abandon sera créé pour l'instantané indiquant à tout le monde que quelque chose s'est mal passé avec l'instantané et d'abandonner le travail. |
Conclusion
Comme vous pouvez le constater, ZooKeeper est un élément fondamental de HBase. Toutes les opérations nécessitant une coordination, telles que l'affectation des régions, le basculement principal, la réplication et les instantanés, sont basées sur ZooKeeper. (Vous pouvez en savoir plus sur pourquoi/comment vous utiliseriez ZooKeeper dans vos applications ici.)
Bien que la plupart des znodes ne soient utiles qu'à HBase, certains, tels que la liste des RegionServers (/hbase/rs) ou la liste des régions non attribuées (/hbase/unassigned), peuvent être utilisés à des fins de débogage ou de surveillance. Ou, comme dans le cas de /hbase/draining, vous pouvez interagir avec eux pour faire savoir à HBase ce que vous faites avec le cluster.
Matteo Bertozzi est ingénieur logiciel chez Cloudera et Committer sur le projet HBase.
