Apache ZooKeeper é um sistema cliente/servidor para coordenação distribuída que expõe uma interface semelhante a um sistema de arquivos, onde cada nó (chamado de znode ) pode conter dados e um conjunto de filhos. Cada znode tem um nome e pode ser identificado usando um caminho semelhante ao sistema de arquivos (por exemplo, /root-znode/sub-znode/my-znode).
No Apache HBase, o ZooKeeper coordena, comunica e compartilha o estado entre os Masters e RegionServers. O HBase tem uma política de design de usar o ZooKeeper apenas para dados transitórios (ou seja, para coordenação e comunicação de estado). Assim, se os dados do ZooKeeper do HBase forem removidos, apenas as operações transitórias serão afetadas — os dados podem continuar a ser gravados e lidos de/para o HBase.
Nesta postagem do blog, você fará um breve tour pelo uso de znodes do HBase. A versão do HBase usada para referência aqui é 0.94 (enviada dentro do CDH 4.2 e CDH 4.3), mas a maioria dos znodes está presente em versões anteriores e provavelmente também estará em versões futuras.
O caminho do znode raiz do HBase é configurável usando hbase-site.xml e, por padrão, o local é “/hbase”. Todos os znodes mencionados abaixo serão prefixados usando o local padrão /hbase, e a propriedade de configuração que permite renomear o znode específico será listada ao lado do nome do znode padrão e destacada com negrito.
O ZooKeeper fornece um shell interativo que permite explorar o estado do ZooKeeper — execute-o usando hbase zkcli e percorra o znode via ls , como em um sistema de arquivos típico. Você também pode obter algumas informações sobre o conteúdo do znode usando o comando get comando.
$ 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 ...
Operações
Os znodes que você verá com mais frequência são aqueles que coordenam operações como atribuição de região, divisão de log e failover mestre, ou acompanham o estado do cluster, como o local da tabela ROOT, lista de RegionServers online e lista de regiões não atribuídas .
| /hbase (zookeeper.znode.parent) | O znode raiz que conterá todos os znodes criados/usados pelo HBase |
| /hbase/hbaseid (zookeeper.znode.clusterId) | Inicializado pelo Mestre com o UUID que identifica o cluster. O ID também é armazenado no HDFS em hdfs:/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | Contém a localização do servidor que hospeda a região ROOT. É consultado pelo cliente para identificar o RegionServer responsável pelo ROOT e solicitar as localizações META. (Na versão 0.96, a tabela ROOT foi removida como parte do HBASE-3171, e esse znode foi substituído por /hbase/meta-region-server [zookeeper.znode.metaserver] que contém a localização do servidor que hospeda o META.) |
| /hbase/rs (zookeeper.znode.rs) | Na inicialização, cada RegionServer criará um sub-znode (por exemplo, /hbase/rs/m1.host) que deve descrever o estado “online” do RegionServer. O mestre monitora este znode para obter a lista RegionServer “online” e usá-la durante a atribuição/balanceamento. |
| /hbase/não atribuído (zookeeper.znode.unassigned) | Contém um sub-znode para cada região não atribuída (por exemplo, /hbase/unassigned/ |
| /hbase/mestre (zookeeper.znode.master) | O mestre “ativo” registrará seu próprio endereço neste znode na inicialização, tornando este znode a fonte de verdade para identificar qual servidor é o mestre. |
| /hbase/backup-masters (zookeeper.znode.backup.masters) | Cada mestre inativo se registrará como mestre de backup criando um sub-znode (hbase/backup-master/m1.host). Este znode é usado principalmente para rastrear quais máquinas estão disponíveis para substituir o Master em caso de falha. |
| /hbase/desligar (zookeeper.znode.state) | Descreve o estado do cluster, “O cluster está ativo?” Ele é criado pelo Mestre na inicialização e excluído pelo Mestre no desligamento. Ele é assistido pelos RegionServers. |
| /hbase/drenagem (zookeeper.znode.draining.rs) | Usado para encerrar mais de um RegionServer por vez criando sub-znodes com o formulário serverName,port,startCode (por exemplo, /hbase/draining/m1.host,60020,1338936306752). Isso permite descomissionar vários RegionServers sem correr o risco de regiões serem movidas temporariamente para um RegionServer que será descomissionado posteriormente. Leia isto para saber mais sobre /hbase/draining. |
| /hbase/tabela (zookeeper.znode.masterTableEnableDisable) | Usado pelo mestre para rastrear o estado da tabela durante as atribuições (estados de desabilitação/habilitação, por exemplo). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Usado pelo divisor de log para rastrear o log pendente para reprodução e sua atribuição. (Leia isto para saber mais sobre a divisão de logs). |
Segurança
Os coprocessadores Access Control List (ACL) e Token Provider adicionam mais dois znodes:um para sincronizar o acesso às ACLs de tabela e o outro para sincronizar as chaves de criptografia de token nos nós do cluster.
| /hbase/acl (zookeeper.znode.acl.parent) | O acl znode é usado para sincronizar as alterações feitas na tabela _acl_ pelos comandos grant/revoke. Cada tabela terá um sub-znode (/hbase/acl/tableName) contendo as ACLs da tabela. (Leia isto para obter mais informações sobre o controlador de acesso e a interação do ZooKeeper.) |
| /hbase/tokenauth (zookeeper.znode.tokenauth.parent) | O provedor de token geralmente é usado para permitir que um trabalho MapReduce acesse o cluster HBase. Quando um usuário solicita um novo token, as informações serão armazenadas em um sub-znode criado para a chave (/hbase/tokenauth/keys/key-id). |
Replicação
Como regra geral, todos os znodes são efêmeros, o que significa que eles estão descrevendo um estado “temporário” – então, mesmo se você remover tudo do ZooKeeper, o HBase poderá recriá-los. Embora os znodes de replicação não descrevam um estado temporário, eles devem ser a fonte de verdade para o estado de replicação, descrevendo o estado de replicação de cada máquina. (Leia isto para saber mais sobre replicação).
| /hbase/replicação (zookeeper.znode.replication) | Znode raiz que contém todas as informações de estado de replicação do HBase |
| /hbase/replicação/peers (zookeeper.znode.replication.peers) | Cada par terá um sub-znode (por exemplo, /hbase/replication/peers/ |
| /hbase/replication/peers/ | Espelho do /hbase/replication/peers znode, mas aqui cada subznode (/hbase/replication/peer-state/ |
| /hbase/replicação/estado (zookeeper.znode.replication.state) | Indica se a replicação está habilitada. A replicação pode ser habilitada definindo a configuração hbase.replication como true, ou pode ser habilitada/desabilitada usando o comando start/stop no shell do HBase. (Na versão 0.96, este znode foi removido e o znode peer-state acima é usado como referência.) |
| /hbase/replicação/rs (zookeeper.znode.replication.rs) | Contém a lista de RegionServers no cluster principal (/hbase/replication/rs/ |
Procedimentos de instantâneo on-line
Os instantâneos online são coordenados pelo Mestre usando o ZooKeeper para se comunicar com os RegionServers usando uma transação semelhante ao commit de duas fases. (Leia isto para obter mais detalhes sobre instantâneos.)
| /hbase/online-snapshot/adquirido | O znode adquirido descreve a primeira etapa de uma transação de instantâneo. O mestre criará um sub-znode para o instantâneo (/hbase/online-snapshot/acquired/ |
| /hbase/online-snapshot/alcançado | Uma vez que cada RegionServer tenha se unido ao znode adquirido, o Mestre criará o znode alcançado para o instantâneo (/hbase/online-snapshot/reached/ |
| /hbase/online-snapshot/abort | Se algo falhar no lado Master ou no lado RegionServer, o znode abort será criado para o snapshot informando a todos que algo deu errado com o snapshot e para abortar o trabalho. |
Conclusão
Como você pode ver, o ZooKeeper é uma parte fundamental do HBase. Todas as operações que exigem coordenação, como atribuição de regiões, Master-Failover, replicação e instantâneos, são criadas no ZooKeeper. (Você pode aprender mais sobre por que/como você usaria o ZooKeeper em seus aplicativos aqui.)
Embora a maioria dos znodes seja útil apenas para o HBase, alguns — como a lista de RegionServers (/hbase/rs) ou a lista de regiões não atribuídas (/hbase/unassigned) — podem ser usados para fins de depuração ou monitoramento. Ou, como no caso de /hbase/draining, você pode interagir com eles para informar ao HBase o que você está fazendo com o cluster.
Matteo Bertozzi é engenheiro de software na Cloudera e Committer no projeto HBase.
