Zookeeper

Publicado por

” ZooKeeper: Because coordinating distributed systems is a Zoo “

Introducción

Zookeeper es un servicio centralizado para:

  • Mantener la información de configuración
  • Nombres
  • Sincronización distribuida
  • Grupos

Cuando se implementa estos servicios, gran parte del tiempo se va en depurar errores y en comprobar condiciones de carrera1Debido a su complejidad las aplicaciones no dedican, inicialmente, el tiempo necesario a esta tarea, lo que las hace más frágiles frente a los cambios y difíciles de manejar. Incluso en los casos en que se realice correctamente, las diferentes implementaciones de los servicios harán compleja su administración cuando haya que desplegar.

El objetivo de Zookeeper es proporcionar una visión general de estos servicios a través de una interfaz muy sencilla para la coordinación centralizada de servicios distribuidos. El servicio en sí está distribuido y es altamente confiable. Los protocolos de consenso, de gestión de grupo y de presencia son implementados por zookeeper para que las aplicaciones no tengan que hacerlo.

Zookeeper permite a los procesos distribuidos poder coordinarse entre ellos a través de un sistema de jerarquía de nombres compartido en registros (a estos registros los denominamos znodes), muy parecido a un sistema de ficheros.

Zookeeper vs Sistema de ficheros

El espacio de nombre es muy parecido al de un sistema de ficheros estándar. Un nombre es una secuencia de elementos del path separados por barra “/”. Como cualquier otro sistema de ficheros un znode no se podrá borrar si contiene algún hijo.

A diferencia de los sistemas de ficheros, Zookeeper proporciona a sus clientes alto rendimiento, baja latencia, alta disponibilidad y orden estricto de acceso a los znodes. El rendimiento ofrecido por Zookeeper permite utilizarlo en grandes sistemas distribuidos. No tiene un punto crítico de fallo. Por su orden estricto de acceso permite implementar sofisticadas primitivas de sincronización en el cliente.

La mayor diferencia entre Zookepeer y un sistema de ficheros estándar es que cada znode puede tener datos asociados a él (cada fichero puede ser también un directorio y viceversa) y que los znodes están limitados a la cantidad de datos que puedan contener. Zookeeper fue diseñado para guardar datos de coordinación: información de estado, configuración, información local, etc.

Como la información del servicio es guardada en memoria, Zookeeper es capaz de ofrecer un gran rendimiento. La desventaja es que al ser una base de datos en memoria esta limitado por la memoria que pueda administrar, esta limitación nos hace pensar que hay que tener muy en cuenta la cantidad de datos que puede almacenar un znode.

Arquitectura

El servicio en sí está replicado en el conjunto de máquinas que forman el servicio. Estas máquinas mantienen una imagen en memoria del árbol de directorios junto con los registros de transacciones e instantáneas en un almacén persistente.

Los servidores que componen el servicio de Zookeeper deben conocerse unos a otros. Mientras la mayoría de los servidores estén disponibles, el servicio Zookeeper estará disponible (arquitectura Quorum2). Los clientes también deben de conocer la lista de servidores disponibles.

service

Funcionamiento

Un cliente solo se conecta a un servidor de Zookeeper. El cliente mantiene una conexión TCP a través de la cual manda peticiones, obtiene eventos de los watches3 y envía los heartbeats. Si la conexión TCP contra el servidor falla, el cliente se conecta a un servidor diferente.
Cuando un cliente se conecta por primera vez al servicio Zookeeper, el primer servidor contactado se encargará de configurar una nueva sesión. Si el cliente necesita conectarse a otro servidor, esta sesión se restablecerá en el nuevo servidor.

Las peticiones de lectura enviadas por un cliente de Zookeeper son procesadas localmente en el servidor Zookeeper al cual se encuentre conectado. Si la petición es la de registrar un watch en un znode, esté también será rastreado por el servidor local.

Las peticiones de escritura son enviadas a otros servidores Zookeeper y pasan por consenso antes de generar una respuesta. Las peticiones de sincronización también son enviadas a otros servidores, pero actualmente no cuentan con consenso.

Por esto el rendimiento de las peticiones de lectura aumenta con el número de servidores, mientras que el rendimiento de peticiones de escritura se reduce.

zkperfrw-3-2

Img: zookeeper.apache.org

 


  1. Condición de carrera: Cuando la salida o estado de un proceso es dependiente de una secuencia de eventos que se ejecutan en orden arbitrario y van a trabajar sobre un mismo recurso compartido, se puede producir un bug cuando dichos eventos no “llegan” (se ejecutan) en el orden que el programador esperaba.
  2. Arquitectura Quorum: es una red formada por un número impar de servidores para garantizar que los datos que comparten sean correctos en todo momento a pesar de los fallos y caídas. Para que el quorum se considere disponible tiene que tener activos la mitad de servidores más 1.
  3. Watch: los clientes pueden establecer watches sobre los znodes. Si se produce un cambio en ese znode se disparará el watch y después se eliminará. Cuando un watch se dispara Zookeeper envía una notificación al cliente con el cambio.

Fuente:
Apache Zookeeper

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s