Apache ZooKeeper е система клиент/сървър за разпределена координация, която разкрива интерфейс, подобен на файлова система, където всеки възел (наречен znode ) може да съдържа данни и набор от деца. Всеки znode има име и може да бъде идентифициран чрез път, подобен на файловата система (например /root-znode/sub-znode/my-znode).
В Apache HBase ZooKeeper координира, комуникира и споделя състоянието между главните и регионалните сървъри. HBase има политика за проектиране да използва ZooKeeper само за преходни данни (тоест за координация и комуникация на състоянието). По този начин, ако данните от ZooKeeper на HBase бъдат премахнати, ще бъдат засегнати само преходните операции — данните могат да продължат да се записват и четат към/от HBase.
В тази публикация в блога ще получите кратка обиколка на използването на HBase znodes. Версията на HBase, използвана за справка тук, е 0.94 (доставя се в CDH 4.2 и CDH 4.3), но повечето от znodes присъстват в предишни версии и вероятно ще бъдат и в бъдещи версии.
Пътят на HBase root znode може да се конфигурира с помощта на hbase-site.xml и по подразбиране местоположението е „/hbase“. Всички snode, посочени по-долу, ще бъдат с префикс, използвайки местоположението по подразбиране /hbase, а свойството за конфигурация, което ви позволява да преименувате конкретния znode, ще бъде изброено до името на znode по подразбиране и ще бъде подчертано с удебелен шрифт.
ZooKeeper предоставя интерактивна обвивка, която ви позволява да изследвате състоянието на ZooKeeper - стартирайте го с помощта на hbase zkcli и преминете през znode чрез ls , както в типична файлова система. Можете също да получите информация за съдържанието на znode, като използвате get команда.
$ 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 ...
Операции
Знодите, които най-често ще виждате, са тези, които координират операции като присвояване на регион, разделяне на регистрационни файлове и главен отказ при отказ или проследяват състоянието на клъстера, като местоположението на ROOT таблицата, списък с онлайн сървъри на региони и списък с неприсвоени региони .
| /hbase (zookeeper.znode.parent) | Корен znode, който ще съдържа всички znode, създадени/използвани от HBase |
| /hbase/hbaseid (zookeeper.znode.clusterId) | Инициализира се от Главния с UUID, който идентифицира клъстера. Идентификаторът също се съхранява в HDFS в hdfs:/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | Съдържа местоположението на сървъра, хостващ ROOT региона. Клиентът иска да идентифицира RegionServer, отговорен за ROOT, и да поиска META местоположенията. (В 0.96 ROOT таблицата беше премахната като част от HBASE-3171 и този znode е заменен от /hbase/meta-region-server [zookeeper.znode.metaserver], който съдържа местоположението на сървъра, хостващ META.) td> |
| /hbase/rs (zookeeper.znode.rs) | При стартиране всеки RegionServer ще създаде sub-znode (напр. /hbase/rs/m1.host), който трябва да описва „онлайн“ състоянието на RegionServer. Главният монитор наблюдава този znode, за да получи „онлайн“ списъка на RegionServer и да го използва по време на присвояване/балансиране. |
| /hbase/unassigned (zookeeper.znode.unassigned) | Съдържа под-znode за всеки неприсвоен регион (напр. /hbase/unassigned/<име на регион>). Този znode се използва от Мениджъра на присвояване, за да открие регионите за присвояване. (Прочетете това, за да научите повече за мениджъра на задания.) |
| /hbase/master (zookeeper.znode.master) | „Активният“ главен обект ще регистрира свой собствен адрес в този znode при стартиране, което прави този znode източник на истина за идентифициране кой сървър е главният. |
| /hbase/backup-masters (zookeeper.znode.backup.masters) | Всеки неактивен Master ще се регистрира като резервен Master чрез създаване на sub-znode (hbase/backup-master/m1.host). Този znode се използва главно за проследяване кои машини са налични за замяна на главния в случай на повреда. |
| /hbase/изключване (zookeeper.znode.state) | Описва състоянието на клъстера:„Клъстерът е включен?“ Създава се от Главния при стартиране и се изтрива от Главния при изключване. Гледа се от RegionServers. |
| /hbase/източване (zookeeper.znode.draining.rs) | Използва се за извеждане от експлоатация на повече от един RegionServer наведнъж чрез създаване на sub-znodes с формата serverName,port,startCode (например /hbase/draining/m1.host,60020,1338936306752). Това ви позволява да изведете от експлоатация множество RegionServer, без да имате риск регионите временно да бъдат преместени към RegionServer, който ще бъде изведен от експлоатация по-късно. Прочетете това, за да научите повече за /hbase/draining. |
| /hbase/таблица (zookeeper.znode.masterTableEnableDisable) | Използва се от главния за проследяване на състоянието на таблицата по време на присвояване (например деактивиране/активиране на състояния). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Използва се от разделителя на регистрационни файлове за проследяване на чакащия дневник за повторно възпроизвеждане и неговото присвояване. (Прочетете това, за да научите повече за разделянето на регистрационни файлове). |
Сигурност
Списъкът за контрол на достъпа (ACL) и копроцесорите на доставчика на токени добавят още два znode:единият за синхронизиране на достъпа до ACL на таблицата, а другият за синхронизиране на ключовете за криптиране на маркери в възлите на клъстера.
| /hbase/acl (zookeeper.znode.acl.parent) | Acl znode се използва за синхронизиране на промените, направени в таблицата _acl_ от командите grant/revoke. Всяка таблица ще има под-znode (/hbase/acl/tableName), съдържащ ACL на таблицата. (Прочетете това за повече информация относно контролера за достъп и взаимодействието на ZooKeeper.) |
| /hbase/tokenauth (zookeeper.znode.tokenauth.parent) | Доставчикът на токен обикновено се използва, за да позволи на задание MapReduce достъп до HBase клъстера. Когато потребител поиска нов токен, информацията ще се съхранява в под-znode, създаден за ключа (/hbase/tokenauth/keys/key-id). |
Репликация
Като общо правило, всички znodes са ефимерни, което означава, че описват „временно“ състояние – така че дори и да премахнете всичко от ZooKeeper, HBase трябва да може да ги пресъздаде. Въпреки че репликационните znodes не описват временно състояние, те са предназначени да бъдат източник на истина за състоянието на репликация, описвайки състоянието на репликация на всяка машина. (Прочетете това, за да научите повече за репликацията).
| /hbase/репликация (zookeeper.znode.replication) | Root znode, който съдържа цялата информация за състоянието на репликация на HBase |
| /hbase/репликация/пиърс (zookeeper.znode.replication.peers) | Всеки партньор ще има под-znode (напр. /hbase/replication/peers/ |
| /hbase/replication/peers/ | Огледало на /hbase/replication/peers znode, но тук всеки под-znode (/hbase/replication/peer-state/ |
| /hbase/репликация/състояние (zookeeper.znode.replication.state) | Показва дали репликацията е активирана. Репликацията може да бъде активирана чрез задаване на конфигурацията hbase.replication на true или може да бъде активирана/деактивирана чрез използване на командата start/stop в обвивката на HBase. (В 0.96 този znode беше премахнат и znode с равностойно състояние по-горе се използва като справка.) |
| /hbase/replication/rs (zookeeper.znode.replication.rs) | Съдържа списъка с регионални сървъри в основния клъстер (/hbase/replication/rs/ |
Процедури за онлайн снимки
Онлайн моментните снимки се координират от Главния, използвайки ZooKeeper, за да комуникират с RegionServers с помощта на двуфазна транзакция, подобна на комит. (Прочетете това за повече подробности относно моментните снимки.)
| /hbase/online-snapshot/acquired | Придобитият znode описва първата стъпка от транзакция за моментна снимка. Главният ще създаде sub-znode за моментната снимка (/hbase/online-snapshot/acquired/<име на снимката>). Всеки RegionServer ще бъде уведомен за създаването на znode и ще подготви моментната снимка; когато са готови, те ще създадат под-znode с името на RegionServer, което означава „Готово съм“ (/hbase/online-snapshot/acquired/<име на снимка>/m1.host). |
| /hbase/онлайн снимка/достигнато | След като всеки RegionServer се присъедини към придобития znode, главният ще създаде достигнатото znode за моментната снимка (/hbase/online-snapshot/reached/ |
| /hbase/online-snapshot/abort | Ако нещо не успее от страна Master или от страната на RegionServer, znode за прекратяване ще бъде създаден за моментната снимка, като уведомява всички, че нещо се е объркало със снимката и да прекратят заданието. |
Заключение
Както можете да видите, ZooKeeper е основна част от HBase. Всички операции, които изискват координация, като присвояване на региони, Master-Failover, репликация и моментни снимки, са изградени на ZooKeeper. (Можете да научите повече за това защо/как бихте използвали ZooKeeper във вашите приложения тук.)
Въпреки че повечето znodes са полезни само за HBase, някои - като списъка с регионални сървъри (/hbase/rs) или списък с неразпределени региони (/hbase/unassigned) - могат да се използват за отстраняване на грешки или цели за наблюдение. Или, както в случая с /hbase/draining, можете да взаимодействате с тях, за да уведомите HBase какво правите с клъстера.
Матео Бертоци е софтуерен инженер в Cloudera и сътрудник на проекта HBase.
