Apache ZooKeeper to system klient/serwer do rozproszonej koordynacji, który udostępnia interfejs podobny do systemu plików, w którym każdy węzeł (nazywany znakiem ) może zawierać dane i zbiór dzieci. Każdy znode ma nazwę i można go zidentyfikować za pomocą ścieżki podobnej do systemu plików (na przykład /root-znode/sub-znode/my-znode).
W Apache HBase ZooKeeper koordynuje, komunikuje się i udostępnia stan między serwerami głównymi i regionalnymi. HBase ma politykę projektową polegającą na używaniu ZooKeeper tylko do danych przejściowych (to znaczy do koordynacji i komunikacji stanu). Tak więc, jeśli dane ZooKeeper HBase zostaną usunięte, dotyczy to tylko operacji przejściowych — dane mogą być nadal zapisywane i odczytywane do/z HBase.
W tym poście na blogu otrzymasz krótką prezentację użycia znodesów HBase. Wersja HBase użyta do odniesienia to 0.94 (dostarczana wewnątrz CDH 4.2 i CDH 4.3), ale większość znodów jest obecna w poprzednich wersjach i prawdopodobnie będzie tak również w przyszłych wersjach.
Ścieżkę do głównego węzła HBase można skonfigurować za pomocą hbase-site.xml, a domyślna lokalizacja to „/hbase”. Wszystkie znode, o których mowa poniżej, będą poprzedzone domyślną lokalizacją /hbase, a właściwość konfiguracji, która pozwala zmienić nazwę konkretnego znode, zostanie wyświetlona obok domyślnej nazwy znode i wyróżniona pogrubioną czcionką.
ZooKeeper zapewnia interaktywną powłokę, która umożliwia eksplorację stanu ZooKeeper — uruchom ją za pomocą hbase zkcli i przejdź przez znode przez ls , jak w typowym systemie plików. Możesz również uzyskać informacje o zawartości znode, używając get polecenie.
$ 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 ...
Operacje
Węzły, które najczęściej zobaczysz, to te, które koordynują operacje, takie jak przypisanie regionu, dzielenie dziennika i główne przełączanie awaryjne, lub śledzą stan klastra, taki jak lokalizacja tabeli ROOT, lista serwerów regionalnych online i lista nieprzypisanych regionów .
| /hbase (zookeeper.znode.parent) | Główny węzeł, który będzie zawierał wszystkie znody utworzone/używane przez HBase |
| /hbase/hbaseid (zookeeper.znode.clusterId) | Inicjowane przez Master z identyfikatorem UUID, który identyfikuje klaster. Identyfikator jest również przechowywany na HDFS w hdfs:/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | Zawiera lokalizację serwera obsługującego region ROOT. Jest pytany przez klienta, aby zidentyfikować RegionServer odpowiedzialny za ROOT i poprosić o lokalizacje META. (W 0.96 tabela ROOT została usunięta jako część HBASE-3171, a ten znode został zastąpiony przez /hbase/meta-region-server [zookeeper.znode.metaserver], który zawiera lokalizację serwera hostującego META.) |
| /hbase/rs (zookeeper.znode.rs) | Na starcie każdy RegionServer utworzy podrzędne źródło (np. /hbase/rs/m1.host), które ma opisywać stan „online” RegionServer. Master monitoruje ten węzeł, aby uzyskać listę „online” RegionServer i używać jej podczas przypisywania/równoważenia. |
| /hbase/nieprzypisany (zookeeper.znode.unassigned) | Zawiera numer podrzędny dla każdego nieprzypisanego regionu (np. /hbase/unassigned/ |
| /hbase/master (zookeeper.znode.master) | „Aktywny” master zarejestruje swój własny adres w tym znode podczas uruchamiania, czyniąc ten znode źródłem prawdy dla identyfikacji, który serwer jest Master. |
| /hbase/mastery kopii zapasowych (zookeeper.znode.backup.masters) | Każdy nieaktywny Master zarejestruje się jako zapasowy Master, tworząc pod-zródło (hbase/backup-master/m1.host). Ten węzeł służy głównie do śledzenia, które maszyny są dostępne do zastąpienia Mastera w przypadku awarii. |
| /hbase/zamknięcie (zookeeper.znode.state) | Opisuje stan klastra, „Czy klaster działa?” Jest tworzony przez Master podczas uruchamiania i usuwany przez Master podczas wyłączania. Jest obserwowany przez RegionServers. |
| /hbase/opróżnianie (zookeeper.znode.draining.rs) | Używany do likwidacji więcej niż jednego serwera regionalnego na raz poprzez tworzenie pod-zn w postaci nazwa_serwera,port,kod startowy (na przykład /hbase/draining/m1.host,60020,1338936306752). Pozwala to na likwidację wielu serwerów RegionServer bez ryzyka, że regiony zostaną tymczasowo przeniesione na serwer RegionServer, który zostanie zlikwidowany później. Przeczytaj to, aby dowiedzieć się więcej o /hbase/draining. |
| /hbase/tabela (zookeeper.znode.masterTableEnableDisable) | Używane przez mastera do śledzenia stanu tabeli podczas przypisywania (na przykład wyłączanie/włączanie stanów). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Używany przez rozdzielacz dziennika do śledzenia oczekującego dziennika do ponownego odtworzenia i jego przypisania. (Przeczytaj to, aby dowiedzieć się więcej o dzieleniu dziennika). |
Bezpieczeństwo
Lista kontroli dostępu (ACL) i koprocesory dostawcy tokena dodają dwa dodatkowe z-węzły:jeden do synchronizowania dostępu do list ACL tabeli, a drugi do synchronizowania kluczy szyfrowania tokenów w węzłach klastra.
| /hbase/acl (zookeeper.znode.acl.parent) | Węzeł acl służy do synchronizowania zmian dokonanych w tabeli _acl_ przez polecenia grant/revoke. Każda tabela będzie miała numer podrzędny (/hbase/acl/tableName) zawierający listy ACL tabeli. (Przeczytaj to, aby uzyskać więcej informacji o kontrolerze dostępu i interakcji ZooKeeper.) |
| /hbase/tokenaut (zookeeper.znode.tokenath.parent) | Dostawca tokenów jest zwykle używany, aby umożliwić zadaniu MapReduce dostęp do klastra HBase. Gdy użytkownik poprosi o nowy token, informacje będą przechowywane w podzodzie utworzonym dla klucza (/hbase/tokenauth/keys/key-id). |
Replikacja
Zgodnie z ogólną zasadą, wszystkie znody są efemeryczne, co oznacza, że opisują stan „tymczasowy” — więc nawet jeśli usuniesz wszystko z ZooKeepera, HBase powinien być w stanie je odtworzyć. Chociaż znody replikacji nie opisują stanu tymczasowego, mają być źródłem prawdy dla stanu replikacji, opisując stan replikacji każdej maszyny. (Przeczytaj to, aby dowiedzieć się więcej o replikacji).
| /hbase/replikacja (zookeeper.znode.replication) | Strona główna, która zawiera wszystkie informacje o stanie replikacji HBase |
| /hbase/replikacja/rówieśniki (zookeeper.znode.replication.peers) | Każdy peer będzie miał pod-node (np. /hbase/replication/peers/ |
| /hbase/replikacja/peers/ | Odbicie lustrzane węzła /hbase/replication/peers, ale tutaj każdy węzeł podrzędny (/hbase/replication/peer-state/ |
| /hbase/replikacja/stan (zookeeper.znode.replication.state) | Wskazuje, czy replikacja jest włączona. Replikację można włączyć, ustawiając konfigurację hbase.replication na true lub włączyć/wyłączyć za pomocą polecenia start/stop w powłoce HBase. (W 0.96 ten węzeł został usunięty, a powyższy węzeł stanu równorzędnego jest używany jako odniesienie.) |
| /hbase/replikacja/rs (zookeeper.znode.replication.rs) | Zawiera listę serwerów regionalnych w głównym klastrze (/hbase/replication/rs/ |
Procedury tworzenia migawek online
Migawki online są koordynowane przez jednostkę główną za pomocą ZooKeeper do komunikowania się z serwerami RegionServers przy użyciu dwufazowej transakcji podobnej do zatwierdzania. (Przeczytaj to, aby uzyskać więcej informacji na temat migawek.)
| /hbase/migawka-online/pozyskana | Pozyskany węzeł opisuje pierwszy krok transakcji migawki. Master utworzy sub-znode dla migawki (/hbase/online-snapshot/acquired/ |
| /hbase/migawka-online/osiągnięto | Gdy każdy RegionServer dołączył do nabytego węzła, Master utworzy osiągnięty węzeł dla zrzutu (/hbase/online-snapshot/reached/ |
| /hbase/migawka-online/przerwij | Jeśli coś ulegnie awarii po stronie Master lub RegionServer, zostanie utworzony węzeł przerwania dla migawki, informujący wszystkich, że coś poszło nie tak ze zrzutem i przerwać zadanie. |
Wniosek
Jak widać, ZooKeeper jest podstawową częścią HBase. Wszystkie operacje wymagające koordynacji, takie jak przypisywanie regionów, przełączanie awaryjne, replikacja i migawki, są oparte na ZooKeeper. (Możesz dowiedzieć się więcej o tym, dlaczego i jak używać ZooKeepera w swoich aplikacjach tutaj.)
Chociaż większość znodes jest przydatna tylko dla HBase, niektóre — takie jak lista serwerów regionów (/hbase/rs) lub lista nieprzypisanych regionów (/hbase/unassigned) — mogą być używane do debugowania lub monitorowania. Lub, jak w przypadku /hbase/draining, możesz wchodzić z nimi w interakcję, aby poinformować HBase, co robisz z klastrem.
Matteo Bertozzi jest inżynierem oprogramowania w Cloudera i Committerem w projekcie HBase.
