Apache ZooKeeper ist ein Client/Server-System für die verteilte Koordination, das eine einem Dateisystem ähnliche Schnittstelle bereitstellt, bei der jeder Knoten (genannt znode ) kann Daten und eine Reihe von untergeordneten Elementen enthalten. Jeder Znode hat einen Namen und kann anhand eines dateisystemähnlichen Pfads identifiziert werden (z. B. /root-znode/sub-znode/my-znode).
In Apache HBase koordiniert, kommuniziert und teilt ZooKeeper den Zustand zwischen den Master- und RegionServern. HBase hat eine Entwurfsrichtlinie, ZooKeeper nur für transiente Daten zu verwenden (d. h. für die Koordination und Zustandskommunikation). Wenn also die ZooKeeper-Daten von HBase entfernt werden, sind nur die vorübergehenden Vorgänge betroffen – Daten können weiterhin in/aus HBase geschrieben und gelesen werden.
In diesem Blogbeitrag erhalten Sie eine kurze Einführung in die Verwendung von HBase-Znodes. Die hier als Referenz verwendete Version von HBase ist 0.94 (im Lieferumfang von CDH 4.2 und CDH 4.3 enthalten), aber die meisten Znodes sind in früheren Versionen vorhanden und werden dies wahrscheinlich auch in zukünftigen Versionen sein.
Der HBase-Root-Znode-Pfad kann mit hbase-site.xml konfiguriert werden, und standardmäßig ist der Speicherort „/hbase“. Allen Znodes, auf die unten verwiesen wird, wird der standardmäßige /hbase-Speicherort vorangestellt, und die Konfigurationseigenschaft, mit der Sie den jeweiligen Znode umbenennen können, wird neben dem standardmäßigen Znode-Namen aufgelistet und fett hervorgehoben.
ZooKeeper bietet eine interaktive Shell, mit der Sie den Zustand von ZooKeeper erkunden können – führen Sie sie mit hbase zkcli aus und gehen Sie durch den znode über ls , wie in einem typischen Dateisystem. Sie können auch einige Informationen über den Znode-Inhalt erhalten, indem Sie get verwenden Befehl.
$ 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 ...
Operationen
Die Znodes, die Sie am häufigsten sehen, sind diejenigen, die Operationen wie Regionszuweisung, Log-Splitting und Master-Failover koordinieren oder den Clusterstatus verfolgen, wie z. B. den Speicherort der ROOT-Tabelle, die Liste der Online-RegionServer und die Liste der nicht zugewiesenen Regionen .
| /hbase (zookeeper.znode.parent) | Der Root-Znode, der alle von HBase erstellten/verwendeten Znodes enthält |
| /hbase/hbaseid (zookeeper.znode.clusterId) | Vom Master mit der UUID initialisiert, die den Cluster identifiziert. Die ID wird auch auf HDFS in hdfs:/ | gespeichert
| /hbase/root-region-server (zookeeper.znode.rootserver) | Enthält den Standort des Servers, der die ROOT-Region hostet. Es wird vom Client abgefragt, um den für ROOT verantwortlichen RegionServer zu identifizieren und nach den META-Standorten zu fragen. (In 0.96 wurde die ROOT-Tabelle als Teil von HBASE-3171 entfernt, und dieser znode wird durch /hbase/meta-region-server [zookeeper.znode.metaserver] ersetzt, der den Standort des Servers enthält, auf dem META gehostet wird.) |
| /hbase/rs (zookeeper.znode.rs) | Beim Start erstellt jeder RegionServer einen Sub-Znode (z. B. /hbase/rs/m1.host), der den „Online“-Zustand des RegionServers beschreiben soll. Der Master überwacht diesen Znode, um die „Online“-RegionServer-Liste abzurufen und diese während der Zuweisung/des Ausgleichs zu verwenden. |
| /hbase/nicht zugewiesen (zookeeper.znode.unassigned) | Enthält einen Unterknoten für jede nicht zugewiesene Region (z. B. /hbase/unassigned/ |
| /hbase/master (zookeeper.znode.master) | Der „aktive“ Master wird beim Start seine eigene Adresse in diesem Znode registrieren, wodurch dieser Znode zur Quelle der Wahrheit wird, um zu identifizieren, welcher Server der Master ist. |
| /hbase/backup-masters (zookeeper.znode.backup.masters) | Jeder inaktive Master registriert sich selbst als Backup-Master, indem er einen Sub-znode erstellt (hbase/backup-master/m1.host). Dieser Znode wird hauptsächlich verwendet, um zu verfolgen, welche Maschinen verfügbar sind, um den Master im Falle eines Ausfalls zu ersetzen. |
| /hbase/Herunterfahren (zookeeper.znode.state) | Beschreibt den Clusterzustand, „Ist der Cluster aktiv?“ Es wird vom Master beim Start erstellt und vom Master beim Herunterfahren gelöscht. Es wird von den RegionServern beobachtet. |
| /hbase/Entwässerung (zookeeper.znode.draining.rs) | Wird verwendet, um mehr als einen RegionServer gleichzeitig außer Betrieb zu setzen, indem Sub-Znodes mit der Form serverName,port,startCode erstellt werden (z. B. /hbase/draining/m1.host,60020,1338936306752). Auf diese Weise können Sie mehrere RegionServer außer Betrieb nehmen, ohne das Risiko einzugehen, dass Regionen vorübergehend auf einen RegionServer verschoben werden, der später außer Betrieb genommen wird. Lesen Sie dies, um mehr über /hbase/draining zu erfahren. |
| /hbase/table (zookeeper.znode.masterTableEnableDisable) | Wird vom Master verwendet, um den Tabellenstatus während Zuweisungen zu verfolgen (z. B. Deaktivierungs-/Aktivierungsstatus). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Wird vom Protokollsplitter verwendet, um das ausstehende Protokoll zur Wiedergabe und seine Zuweisung zu verfolgen. (Lesen Sie dies, um mehr über das Aufteilen von Protokollen zu erfahren). |
Sicherheit
Die Access Control List (ACL) und die Coprozessoren des Token-Providers fügen zwei weitere Znodes hinzu:einen zum Synchronisieren des Zugriffs auf Tabellen-ACLs und den anderen zum Synchronisieren der Token-Verschlüsselungsschlüssel über die Cluster-Nodes hinweg.
| /hbase/acl (zookeeper.znode.acl.parent) | Der acl znode wird zum Synchronisieren der Änderungen verwendet, die durch die Grant/Revoke-Befehle an der _acl_-Tabelle vorgenommen werden. Jede Tabelle hat einen Unterknoten (/hbase/acl/tableName), der die ACLs der Tabelle enthält. (Lesen Sie dies für weitere Informationen über den Zugriffscontroller und die ZooKeeper-Interaktion.) |
| /hbase/tokenauth (zookeeper.znode.tokenauth.parent) | Der Token-Anbieter wird normalerweise verwendet, um einem MapReduce-Job den Zugriff auf den HBase-Cluster zu ermöglichen. Wenn ein Benutzer nach einem neuen Token fragt, werden die Informationen in einem Unterknoten gespeichert, der für den Schlüssel erstellt wurde (/hbase/tokenauth/keys/key-id). |
Replikation
Als allgemeine Regel gilt, dass alle Znodes kurzlebig sind, was bedeutet, dass sie einen „vorübergehenden“ Zustand beschreiben – selbst wenn Sie also alles aus ZooKeeper entfernen, sollte HBase in der Lage sein, sie neu zu erstellen. Obwohl die Replikations-Znodes keinen temporären Status beschreiben, sollen sie die Quelle der Wahrheit für den Replikationsstatus sein, indem sie den Replikationsstatus jeder Maschine beschreiben. (Lesen Sie dies, um mehr über die Replikation zu erfahren).
| /hbase/Replikation (zookeeper.znode.replication) | Root-znode, der alle Informationen zum HBase-Replikationsstatus enthält |
| /hbase/replication/peers (zookeeper.znode.replication.peers) | Jeder Peer hat einen Unterknoten (z. B. /hbase/replication/peers/ |
| /hbase/replication/peers/ | Mirror des /hbase/replication/peers znode, aber hier verfolgt jeder untergeordnete znode (/hbase/replication/peer-state/ |
| /hbase/replication/state (zookeeper.znode.replication.state) | Gibt an, ob die Replikation aktiviert ist. Die Replikation kann aktiviert werden, indem die hbase.replication-Konfiguration auf „true“ gesetzt wird, oder sie kann mithilfe des start/stop-Befehls in der HBase-Shell aktiviert/deaktiviert werden. (In 0.96 wurde dieser Znode entfernt und der obige Peer-State-Znode wird als Referenz verwendet.) |
| /hbase/replication/rs (zookeeper.znode.replication.rs) | Enthält die Liste der RegionServer im Hauptcluster (/hbase/replication/rs/ |
Online-Snapshot-Verfahren
Online-Snapshots werden vom Master koordiniert, der ZooKeeper verwendet, um mit den RegionServern über eine zweiphasige Commit-ähnliche Transaktion zu kommunizieren. (Lesen Sie dies für weitere Details über Snapshots.)
| /hbase/online-snapshot/acquired | Der erworbene Znode beschreibt den ersten Schritt einer Snapshot-Transaktion. Der Master erstellt einen Unterknoten für den Snapshot (/hbase/online-snapshot/acquired/ |
| /hbase/online-snapshot/reached | Sobald jeder RegionServer dem erworbenen Znode beigetreten ist, erstellt der Master den erreichten Znode für den Snapshot (/hbase/online-snapshot/reached/ |
| /hbase/online-snapshot/abort | Wenn auf der Seite des Masters oder des RegionServers etwas fehlschlägt, wird der Abort-Znode für den Snapshot erstellt, der allen mitteilt, dass etwas mit dem Snapshot schief gelaufen ist, und den Job abzubrechen. |
Schlussfolgerung
Wie Sie sehen können, ist ZooKeeper ein grundlegender Bestandteil von HBase. Alle Vorgänge, die eine Koordination erfordern, wie Regionszuweisung, Master-Failover, Replikation und Snapshots, basieren auf ZooKeeper. (Hier erfahren Sie mehr darüber, warum/wie Sie ZooKeeper in Ihren Anwendungen verwenden würden.)
Obwohl die meisten Znodes nur für HBase nützlich sind, können einige – wie die Liste der RegionServer (/hbase/rs) oder die Liste der nicht zugewiesenen Regionen (/hbase/unassigned) – für Debugging- oder Überwachungszwecke verwendet werden. Oder, wie im Fall von /hbase/draining, können Sie mit ihnen interagieren, um HBase wissen zu lassen, was Sie mit dem Cluster tun.
Matteo Bertozzi ist Software Engineer bei Cloudera und Committer am HBase-Projekt.
