Apache ZooKeeper je systém klient/server pro distribuovanou koordinaci, který odhaluje rozhraní podobné souborovému systému, kde každý uzel (nazývaný znode ) může obsahovat data a množinu dětí. Každý uzel má název a lze jej identifikovat pomocí cesty podobné souborovému systému (například /root-znode/sub-znode/my-znode).
V Apache HBase ZooKeeper koordinuje, komunikuje a sdílí stav mezi Masters a RegionServers. HBase má návrhovou politiku používat ZooKeeper pouze pro přechodná data (to znamená pro koordinaci a státní komunikaci). Pokud jsou tedy data ZooKeeperu HBase odstraněna, budou ovlivněny pouze přechodné operace – data lze nadále zapisovat a číst do/z HBase.
V tomto příspěvku na blogu získáte krátkou prohlídku použití HBase znodes. Verze HBase, která je zde použita jako reference, je 0.94 (dodává se v rámci CDH 4.2 a CDH 4.3), ale většina znodes je přítomna v předchozích verzích a pravděpodobně tomu tak bude i ve verzích budoucích.
Cesta kořenového uzlu HBase je konfigurovatelná pomocí hbase-site.xml a ve výchozím nastavení je umístění „/hbase“. Všechny níže uvedené uzly budou mít předponu pomocí výchozího umístění /hbase a vlastnost konfigurace, která vám umožní přejmenovat konkrétní uzel, bude uvedena vedle výchozího názvu uzlu a zvýrazněna tučným písmem.
ZooKeeper poskytuje interaktivní prostředí, které vám umožní prozkoumat stav ZooKeeper – spusťte jej pomocí hbase zkcli a projděte znode přes ls , jako v typickém souborovém systému. Některé informace o obsahu znode můžete také získat pomocí get příkaz.
$ 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 ...
Operace
Znody, které nejčastěji uvidíte, jsou ty, které koordinují operace, jako je přiřazení oblasti, rozdělení protokolu a hlavní selhání, nebo sledují stav clusteru, jako je umístění tabulky ROOT, seznam online serverů RegionServer a seznam nepřiřazených oblastí. .
| /hbase (zookeeper.znode.parent) | Kořenový uzel, který bude obsahovat všechny uzly vytvořené/používané HBase |
| /hbase/hbaseid (zookeeper.znode.clusterId) | Inicializováno Master pomocí UUID, které identifikuje cluster. ID je také uloženo na HDFS v hdfs:/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | Obsahuje umístění serveru hostujícího oblast ROOT. Klient je požádán, aby identifikoval RegionServer odpovědný za ROOT a požádal o umístění META. (Ve verzi 0.96 byla ROOT tabulka odstraněna jako součást HBASE-3171 a tento uzel je nahrazen /hbase/meta-region-server [zookeeper.znode.metaserver], který obsahuje umístění serveru hostujícího META.) |
| /hbase/rs (zookeeper.znode.rs) | Při spuštění každý RegionServer vytvoří podznode (např. /hbase/rs/m1.host), který má popisovat „online“ stav RegionServeru. Master monitoruje tento uzel, aby získal „online“ seznam RegionServer a použil jej během přiřazení/vyvažování. |
| /hbase/nepřiřazeno (zookeeper.znode.unassigned) | Obsahuje dílčí uzel pro každou nepřiřazenou oblast (např. /hbase/unassigned/ |
| /hbase/master (zookeeper.znode.master) | Aktivní hlavní server zaregistruje svou vlastní adresu v tomto uzlu při spuštění, čímž se tento uzel stane zdrojem pravdy pro identifikaci serveru, který je hlavním serverem. |
| /hbase/backup-masters (zookeeper.znode.backup.masters) | Každý neaktivní Master se zaregistruje jako záložní Master vytvořením dílčího uzlu (hbase/backup-master/m1.host). Tento uzel se používá hlavně ke sledování, které stroje jsou k dispozici pro výměnu Master v případě selhání. |
| /hbase/vypnutí (zookeeper.znode.state) | Popisuje stav clusteru, "Je cluster v provozu?" Je vytvořen Master při spuštění a vymazán Master při vypnutí. Sleduje ho server RegionServers. |
| /hbase/vypouštění (zookeeper.znode.draining.rs) | Slouží k vyřazení více než jednoho RegionServeru najednou vytvořením poduzlů ve tvaru serverName,port,startCode (například /hbase/draining/m1.host,60020,1338936306752). To vám umožní vyřadit z provozu více RegionServerů, aniž byste museli riskovat dočasné přesunutí regionů na RegionServer, který bude vyřazen z provozu později. Přečtěte si toto, abyste se dozvěděli více o /hbase/draining. |
| /hbase/tabulka (zookeeper.znode.masterTableEnableDisable) | Používá se masterem ke sledování stavu tabulky během přiřazení (například deaktivace/aktivace stavů). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Používá jej rozdělovač protokolů ke sledování čekajícího protokolu k přehrání a jeho přiřazení. (Přečtěte si toto, abyste se dozvěděli více o dělení protokolů). |
Zabezpečení
Koprocesory Access Control List (ACL) a Token Provider přidávají další dva uzly:jeden pro synchronizaci přístupu k tabulkovým ACL a druhý pro synchronizaci tokenových šifrovacích klíčů napříč uzly clusteru.
| /hbase/acl (zookeeper.znode.acl.parent) | Uzel acl se používá pro synchronizaci změn provedených v tabulce _acl_ příkazy grant/revoke. Každá tabulka bude mít podznode (/hbase/acl/název_tabulky) obsahující ACL tabulky. (Přečtěte si zde další informace o řadiči přístupu a interakci ZooKeeper.) |
| /hbase/tokenauth (zookeeper.znode.tokenauth.parent) | Poskytovatel tokenu se obvykle používá k povolení přístupu úlohy MapReduce ke clusteru HBase. Když uživatel požádá o nový token, informace se uloží do dílčího uzlu vytvořeného pro klíč (/hbase/tokenauth/keys/key-id). |
Replikace
Obecně platí, že všechny uzly jsou pomíjivé, což znamená, že popisují „dočasný“ stav – takže i když ze ZooKeeperu odeberete vše, HBase by je měl být schopen znovu vytvořit. Ačkoli uzly replikace nepopisují dočasný stav, mají být zdrojem pravdy pro stav replikace, popisující stav replikace každého počítače. (Přečtěte si toto, chcete-li se dozvědět více o replikaci).
| /hbase/replikace (zookeeper.znode.replication) | Kořenový uzel, který obsahuje všechny informace o stavu replikace HBase |
| /hbase/replikace/peers (zookeeper.znode.replication.peers) | Každý peer bude mít podznode (např. /hbase/replication/peers/ |
| /hbase/replication/peers/ | Zrcadlo z uzlu /hbase/replication/peers, ale zde bude každý poduzel (/hbase/replication/peer-state/ |
| /hbase/replikace/stav (zookeeper.znode.replication.state) | Ukazuje, zda je replikace povolena. Replikaci lze povolit nastavením konfigurace hbase.replication na hodnotu true nebo ji lze povolit/zakázat pomocí příkazu start/stop v prostředí HBase. (Ve verzi 0.96 byl tento uzel odstraněn a výše uvedený uzel typu peer-state je použit jako referenční.) |
| /hbase/replication/rs (zookeeper.znode.replication.rs) | Obsahuje seznam RegionServers v hlavním clusteru (/hbase/replication/rs/ |
Postupy online snímkování
Online snímky jsou koordinovány Master pomocí ZooKeeper pro komunikaci s RegionServers pomocí dvoufázové transakce podobné závazku. (Další podrobnosti o snímcích si přečtěte zde.)
| /hbase/online-snapshot/získané | Získaný uzel popisuje první krok transakce snímku. Master vytvoří dílčí uzel pro snímek (/hbase/online-snapshot/acquired/ |
| /hbase/online-snapshot/reached | Jakmile se každý RegionServer připojí k získanému uzlu, Master vytvoří dosažený uzel pro snímek (/hbase/online-snapshot/reached/ |
| /hbase/online-snapshot/abort | Pokud se na hlavní straně nebo na straně RegionServeru něco nezdaří, pro snímek se vytvoří uzel přerušení, který všem sdělí, že se se snímkem něco pokazilo, a přeruší úlohu. |
Závěr
Jak můžete vidět, ZooKeeper je základní součástí HBase. Všechny operace, které vyžadují koordinaci, jako je přiřazení regionů, Master-Failover, replikace a snímky, jsou postaveny na ZooKeeper. (Další informace o tom, proč/jak byste ZooKeeper ve svých aplikacích používali, se můžete dozvědět zde.)
Ačkoli většina uzlů je užitečná pouze pro HBase, některé – jako například seznam RegionServers (/hbase/rs) nebo seznam nepřiřazených oblastí (/hbase/unassigned) – lze použít pro účely ladění nebo monitorování. Nebo, jako v případě /hbase/draining, můžete s nimi komunikovat a dát HBase vědět, co s clusterem děláte.
Matteo Bertozzi je softwarový inženýr ve společnosti Cloudera a pověřenec projektu HBase.