Apache ZooKeeper es un sistema cliente/servidor para la coordinación distribuida que expone una interfaz similar a un sistema de archivos, donde cada nodo (llamado znode ) puede contener datos y un conjunto de hijos. Cada znode tiene un nombre y se puede identificar mediante una ruta similar a un sistema de archivos (por ejemplo, /root-znode/sub-znode/my-znode).
En Apache HBase, ZooKeeper coordina, comunica y comparte el estado entre Masters y RegionServers. HBase tiene una política de diseño de usar ZooKeeper solo para datos transitorios (es decir, para coordinación y comunicación estatal). Por lo tanto, si se eliminan los datos de ZooKeeper de HBase, solo se verán afectadas las operaciones transitorias:los datos pueden seguir escribiéndose y leyéndose en/desde HBase.
En esta publicación de blog, obtendrá un breve recorrido por el uso de znodes de HBase. La versión de HBase utilizada como referencia aquí es 0.94 (incluida dentro de CDH 4.2 y CDH 4.3), pero la mayoría de los znodes están presentes en versiones anteriores y es probable que también lo estén en versiones futuras.
La ruta del znode raíz de HBase se puede configurar mediante hbase-site.xml y, de forma predeterminada, la ubicación es "/hbase". Todos los znodes a los que se hace referencia a continuación tendrán el prefijo con la ubicación predeterminada /hbase, y la propiedad de configuración que le permite cambiar el nombre del znode en particular aparecerá junto al nombre del znode predeterminado y se resaltará en negrita.
ZooKeeper proporciona un shell interactivo que le permite explorar el estado de ZooKeeper; ejecútelo usando hbase zkcli y camine a través del znode a través de ls , como en un sistema de archivos típico. También puede obtener información sobre el contenido de znode utilizando 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 ...
Operaciones
Los znodes que verá con más frecuencia son los que coordinan operaciones como la asignación de regiones, la división de registros y la conmutación por error maestra, o realizan un seguimiento del estado del clúster, como la ubicación de la tabla ROOT, la lista de RegionServers en línea y la lista de regiones no asignadas. .
| /hbase (zookeeper.znode.parent) | El znode raíz que contendrá todos los znodes creados/utilizados por HBase |
| /hbase/hbaseid (zookeeper.znode.clusterId) | Inicializado por el maestro con el UUID que identifica el clúster. El ID también se almacena en HDFS en hdfs:/ |
| /hbase/root-region-server (zookeeper.znode.rootserver) | Contiene la ubicación del servidor que aloja la región ROOT. El cliente solicita que identifique el RegionServer responsable de ROOT y solicite las ubicaciones de META. (En 0.96, la tabla ROOT se eliminó como parte de HBASE-3171 y este znode se reemplazó por /hbase/meta-region-server [zookeeper.znode.metaserver] que contiene la ubicación del servidor que aloja META). |
| /hbase/rs (zookeeper.znode.rs) | Al inicio, cada RegionServer creará un sub-znode (por ejemplo, /hbase/rs/m1.host) que se supone que describe el estado "en línea" del RegionServer. El maestro monitorea este znode para obtener la lista de RegionServer "en línea" y usarla durante la asignación/equilibrio. |
| /hbase/sin asignar (zookeeper.znode.unassigned) | Contiene un sub-znode para cada región sin asignar (por ejemplo, /hbase/unassigned/ |
| /hbase/maestro (zookeeper.znode.master) | El maestro “activo” registrará su propia dirección en este znode al inicio, haciendo de este znode la fuente de verdad para identificar qué servidor es el maestro. |
| /hbase/backup-masters (zookeeper.znode.backup.masters) | Cada maestro inactivo se registrará como maestro de respaldo mediante la creación de un sub-znode (hbase/backup-master/m1.host). Este znode se usa principalmente para rastrear qué máquinas están disponibles para reemplazar el maestro en caso de falla. |
| /hbase/apagar (zookeeper.znode.estado) | Describe el estado del clúster, "¿Está activo el clúster?" Es creado por el Maestro al iniciarse y eliminado por el Maestro al apagarse. Es observado por los RegionServers. |
| /hbase/drenaje (zookeeper.znode.draining.rs) | Se utiliza para desmantelar más de un RegionServer a la vez mediante la creación de sub-znodes con la forma serverName,port,startCode (por ejemplo, /hbase/draining/m1.host,60020,1338936306752). Esto le permite retirar varios RegionServers sin correr el riesgo de que las regiones se trasladen temporalmente a un RegionServer que se retirará más adelante. Lea esto para obtener más información sobre /hbase/draining. |
| /hbase/tabla (zookeeper.znode.masterTableEnableDisable) | Utilizado por el maestro para rastrear el estado de la tabla durante las asignaciones (estados de habilitación/deshabilitación, por ejemplo). |
| /hbase/splitlog (zookeeper.znode.splitlog) | Usado por el divisor de registro para rastrear el registro pendiente para reproducir y su asignación. (Lea esto para obtener más información sobre la división de registros). |
Seguridad
Los coprocesadores de la lista de control de acceso (ACL) y del proveedor de tokens agregan dos znodos más:uno para sincronizar el acceso a las ACL de la tabla y el otro para sincronizar las claves de cifrado de tokens en los nodos del clúster.
| /hbase/acl (zookeeper.znode.acl.parent) | El znode acl se utiliza para sincronizar los cambios realizados en la tabla _acl_ mediante los comandos grant/revocate. Cada tabla tendrá un sub-znode (/hbase/acl/tableName) que contiene las ACL de la tabla. (Lea esto para obtener más información sobre el controlador de acceso y la interacción de ZooKeeper). |
| /hbase/tokenauth (zookeeper.znode.tokenauth.padre) | El proveedor de tokens generalmente se usa para permitir que un trabajo de MapReduce acceda al clúster de HBase. Cuando un usuario solicita un nuevo token, la información se almacenará en un sub-znodo creado para la clave (/hbase/tokenauth/keys/key-id). |
Replicación
Como regla general, todos los znodes son efímeros, lo que significa que describen un estado "temporal", por lo que, incluso si elimina todo de ZooKeeper, HBase debería poder recrearlos. Aunque los znodes de replicación no describen un estado temporal, están destinados a ser la fuente de la verdad para el estado de replicación, describiendo el estado de replicación de cada máquina. (Lea esto para obtener más información sobre la replicación).
| /hbase/replicación (zookeeper.znode.replicación) | Znodo raíz que contiene toda la información del estado de replicación de HBase |
| /hbase/replicación/pares (zookeeper.znode.replication.peers) | Cada par tendrá un sub-znode (por ejemplo, /hbase/replication/peers/ |
| /hbase/replication/peers/ | Espejo del znode /hbase/replication/peers, pero aquí cada sub-znode (/hbase/replication/peer-state/ |
| /hbase/replicación/estado (zookeeper.znode.replicación.estado) | Indica si la replicación está habilitada. La replicación se puede habilitar estableciendo la configuración de hbase.replication en verdadero, o se puede habilitar/deshabilitar mediante el comando de inicio/detención en el shell de HBase. (En 0.96, este znode se eliminó y el znode peer-state anterior se usa como referencia). |
| /hbase/replicación/rs (zookeeper.znode.replication.rs) | Contiene la lista de RegionServers en el clúster principal (/hbase/replication/rs/ |
Procedimientos de instantáneas en línea
Las instantáneas en línea son coordinadas por el Maestro usando ZooKeeper para comunicarse con los RegionServers usando una transacción similar a la confirmación de dos fases. (Lea esto para obtener más detalles sobre las instantáneas).
| /hbase/instantánea en línea/adquirida | El znode adquirido describe el primer paso de una transacción instantánea. El maestro creará un sub-znode para la instantánea (/hbase/online-snapshot/acquired/ |
| /hbase/instantánea en línea/alcanzado | Una vez que cada RegionServer se haya unido al znode adquirido, el maestro creará el znode alcanzado para la instantánea (/hbase/online-snapshot/reached/ |
| /hbase/instantánea en línea/abortar | Si algo falla en el lado maestro o en el lado del servidor regional, se creará el znode de cancelación para la instantánea que les indicará a todos que algo salió mal con la instantánea y que cancelen el trabajo. |
Conclusión
Como puedes ver, ZooKeeper es una parte fundamental de HBase. Todas las operaciones que requieren coordinación, como la asignación de Regiones, Master-Failover, replicación e instantáneas, se basan en ZooKeeper. (Puede obtener más información sobre por qué/cómo usaría ZooKeeper en sus aplicaciones aquí).
Aunque la mayoría de los znodes solo son útiles para HBase, algunos, como la lista de RegionServers (/hbase/rs) o la lista de Regiones no asignadas (/hbase/unassigned), se pueden usar con fines de depuración o supervisión. O, como en el caso de /hbase/draining, puede interactuar con ellos para que HBase sepa lo que está haciendo con el clúster.
Matteo Bertozzi es ingeniero de software en Cloudera y responsable del proyecto HBase.
