Apache ZooKeeper è un sistema client/server per il coordinamento distribuito che espone un'interfaccia simile a un filesystem, in cui ogni nodo (chiamato znode ) può contenere dati e un insieme di bambini. Ogni znode ha un nome e può essere identificato utilizzando un percorso simile a un filesystem (ad esempio, /root-znode/sub-znode/my-znode).
In Apache HBase, ZooKeeper coordina, comunica e condivide lo stato tra i Master e i RegionServer. HBase ha una politica di progettazione che prevede l'utilizzo di ZooKeeper solo per i dati transitori (ovvero per il coordinamento e la comunicazione di stato). Pertanto, se i dati ZooKeeper di HBase vengono rimossi, vengono interessate solo le operazioni transitorie: i dati possono continuare a essere scritti e letti su/da HBase.
In questo post del blog, otterrai un breve tour dell'utilizzo degli znode HBase. La versione di HBase utilizzata come riferimento qui è 0.94 (spedita all'interno di CDH 4.2 e CDH 4.3), ma la maggior parte degli znode è presente nelle versioni precedenti e probabilmente lo sarà anche nelle versioni future.
Il percorso znode radice di HBase è configurabile utilizzando hbase-site.xml e per impostazione predefinita la posizione è "/hbase". Tutti gli znode a cui si fa riferimento di seguito verranno preceduti utilizzando la posizione predefinita /hbase e la proprietà di configurazione che consente di rinominare lo znode particolare verrà elencata accanto al nome znode predefinito ed evidenziata in grassetto.
ZooKeeper fornisce una shell interattiva che ti consente di esplorare lo stato di ZooKeeper — eseguilo usando hbase zkcli e attraversa lo znode tramite ls , come in un tipico filesystem. Puoi anche ottenere alcune informazioni sul contenuto di znode usando 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 ...
Operazioni
Gli znode che vedrai più spesso sono quelli che coordinano operazioni come l'assegnazione delle regioni, la suddivisione dei log e il failover principale, o tengono traccia dello stato del cluster come la posizione della tabella ROOT, l'elenco dei RegionServer online e l'elenco delle regioni non assegnate .
| /hbase (zookeeper.znode.parent) | Lo znode root che conterrà tutti gli znode creati/utilizzati da HBase |
| /hbase/hbaseid (zookeeper.znode.clusterId) | Inizializzato dal Master con l'UUID che identifica il cluster. L'ID è anche memorizzato su HDFS in hdfs:/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | Contiene la posizione del server che ospita la regione ROOT. Viene richiesto dal client di identificare il RegionServer responsabile del ROOT e richiedere le posizioni META. (Nella versione 0.96, la tabella ROOT è stata rimossa come parte di HBASE-3171 e questo znode è stato sostituito da /hbase/meta-region-server [zookeeper.znode.metaserver] che contiene la posizione del server che ospita META.) |
| /hbase/rs (zookeeper.znode.rs) | All'avvio, ogni RegionServer creerà un sub-znode (ad es. /hbase/rs/m1.host) che dovrebbe descrivere lo stato "online" di RegionServer. Il master monitora questo znode per ottenere l'elenco RegionServer "online" e utilizzarlo durante l'assegnazione/bilanciamento. |
| /hbase/non assegnato (zookeeper.znode.unassigned) | Contiene un sub-znode per ciascuna regione non assegnata (ad es. /hbase/unassigned/ |
| /hbase/master (zookeeper.znode.master) | Il master "attivo" registrerà il proprio indirizzo in questo znode all'avvio, rendendo questo znode la fonte di verità per identificare quale server è il Master. |
| /hbase/master di backup (zookeeper.znode.backup.masters) | Ogni master inattivo si registrerà come master di backup creando un sub-znode (hbase/backup-master/m1.host). Questo znode viene utilizzato principalmente per tenere traccia di quali macchine sono disponibili per sostituire il Master in caso di guasto. |
| /hbase/spegnimento (zookeeper.znode.state) | Descrive lo stato del cluster, "Il cluster è attivo?" Viene creato dal Master all'avvio e cancellato dal Master allo spegnimento. È guardato dai RegionServers. |
| /hbase/drenaggio (zookeeper.znode.draining.rs) | Utilizzato per disattivare più di un RegionServer alla volta creando sotto-znodi con il modulo serverName,port,startCode (ad esempio, /hbase/draining/m1.host,60020,1338936306752). Ciò ti consente di disattivare più RegionServer senza correre il rischio che le regioni vengano temporaneamente spostate su un RegionServer che verrà ritirato in seguito. Leggi questo per saperne di più su /hbase/draining. |
| /hbase/tabella (zookeeper.znode.masterTableEnableDisable) | Utilizzato dal master per tenere traccia dello stato della tabella durante le assegnazioni (stati di disabilitazione/abilitazione, ad esempio). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Utilizzato dal divisore di registro per tenere traccia del registro in sospeso da riprodurre e la sua assegnazione. (Leggi questo per saperne di più sulla divisione dei log). |
Sicurezza
L'elenco di controllo degli accessi (ACL) e i coprocessori del provider di token aggiungono altri due znodes:uno per sincronizzare l'accesso agli ACL delle tabelle e l'altro per sincronizzare le chiavi di crittografia dei token tra i nodi del cluster.
| /hbase/acl (zookeeper.znode.acl.parent) | Acl znode viene utilizzato per sincronizzare le modifiche apportate alla tabella _acl_ dai comandi grant/revoke. Ogni tabella avrà un sub-znode (/hbase/acl/tableName) contenente gli ACL della tabella. (Leggi questo per ulteriori informazioni sul controller di accesso e sull'interazione ZooKeeper.) |
| /hbase/tokenauth (zookeeper.znode.tokenauth.parent) | Il provider di token viene solitamente utilizzato per consentire a un lavoro MapReduce di accedere al cluster HBase. Quando un utente richiede un nuovo token, le informazioni verranno archiviate in un sub-znode creato per la chiave (/hbase/tokenauth/keys/key-id). |
Replica
Come regola generale, tutti gli znode sono effimeri, il che significa che descrivono uno stato "temporaneo", quindi, anche se rimuovi tutto da ZooKeeper, HBase dovrebbe essere in grado di ricrearli. Sebbene gli znode di replica non descrivano uno stato temporaneo, sono pensati per essere la fonte di verità per lo stato di replica, descrivendo lo stato di replica di ciascuna macchina. (Leggi questo per saperne di più sulla replica).
| /hbase/replica (zookeeper.znode.replication) | Znode root che contiene tutte le informazioni sullo stato di replica HBase |
| /hbase/replica/peer (zookeeper.znode.replication.peers) | Ogni peer avrà un sub-znode (ad es. /hbase/replication/peers/ |
| /hbase/replica/peers/ | Mirror dello znode /hbase/replication/peers, ma qui ogni sub-znode (/hbase/replication/peer-state/ |
| /hbase/replica/stato (zookeeper.znode.replication.state) | Indica se la replica è abilitata. La replica può essere abilitata impostando la configurazione hbase.replication su true oppure può essere abilitata/disabilitata utilizzando il comando start/stop nella shell HBase. (In 0.96, questo znode è stato rimosso e lo znode peer-state sopra viene utilizzato come riferimento.) |
| /hbase/replica/rs (zookeeper.znode.replication.rs) | Contiene l'elenco dei RegionServer nel cluster principale (/hbase/replication/rs/ |
Procedure di snapshot online
Gli snapshot online sono coordinati dal Master utilizzando ZooKeeper per comunicare con i RegionServer utilizzando una transazione simile a un commit in due fasi. (Leggi questo per maggiori dettagli sugli snapshot.)
| /hbase/istantanea-online/acquisita | Lo znode acquisito descrive il primo passaggio di una transazione snapshot. Il Master creerà un sub-znode per lo snapshot (/hbase/online-snapshot/acquised/ |
| /hbase/istantanea online/raggiunto | Una volta che ogni RegionServer si è unito allo znode acquisito, il Master creerà lo znode raggiunto per lo snapshot (/hbase/online-snapshot/reached/ |
| /hbase/istantanea-online/abort | Se qualcosa non riesce sul lato Master o sul lato RegionServer, verrà creato lo znode di interruzione per lo snapshot dicendo a tutti che qualcosa è andato storto con lo snapshot e di interrompere il lavoro. |
Conclusione
Come puoi vedere, ZooKeeper è una parte fondamentale di HBase. Tutte le operazioni che richiedono il coordinamento, come l'assegnazione di regioni, il master failover, la replica e gli snapshot, sono basate su ZooKeeper. (Puoi saperne di più sul perché/come useresti ZooKeeper nelle tue applicazioni qui.)
Sebbene la maggior parte degli znode siano utili solo per HBase, alcuni, come l'elenco dei RegionServers (/hbase/rs) o l'elenco delle regioni non assegnate (/hbase/unassigned), possono essere utilizzati per scopi di debug o monitoraggio. Oppure, come nel caso di /hbase/draining, puoi interagire con loro per far sapere a HBase cosa stai facendo con il cluster.
Matteo Bertozzi è Software Engineer presso Cloudera e Committer del progetto HBase.
