Zookeeper y HBase fiabilidad
Zookeeper es un conjunto distribuido de servidores que colectivamente provee servicios de coordinación y sincronización fiables para aplicaciones en clúster. Es cierto, el nombre " Zookeeper " puede parecer a primera vista una elección extraña, pero cuando usted entiende lo que hace para un clúster HBase, se puede ver la lógica detrás de él. Cuando usted está construyendo y depurar aplicaciones distribuidas , es un zoológico por ahí, " por lo que debe poner Zookeeper en su equipo.
Racimos HBase pueden ser enormes y coordinar las operaciones de las MasterServers, RegionServers, y los clientes puede ser una tarea desalentadora, pero ahí es donde Zookeeper entra en escena. Al igual que en HBase, cúmulos Zookeeper normalmente se ejecutan en servidores x86 de los productos básicos de bajo costo.
Cada servidor x86 individuo ejecuta un solo proceso de software Zookeeper (en adelante denominado como servidor Zookeeper), con un servidor Zookeeper elegido por el conjunto como el líder y el resto de los servidores son seguidores. Conjuntos Zookeeper se rigen por el principio de un quórum de la mayoría.
Configuraciones con un servidor Zookeeper son compatibles con fines de prueba y desarrollo, pero si quieres un grupo confiable que puede tolerar el fallo del servidor, debe implementar al menos tres servidores Zookeeper para lograr el quórum de la mayoría.
Así, el número de servidores Zookeeper se necesita? Cinco es el mínimo recomendado para uso en producción, pero que realmente no quieren ir con el mínimo indispensable. Cuando usted decide planear su conjunto Zookeeper, siga esta sencilla fórmula: 2F + 1 = N donde F es el número de fallos se puede aceptar en el clúster Zookeeper y N es el número total de servidores Zookeeper debe desplegar.
Cinco se recomienda porque un servidor puede ser cerrado por mantenimiento, pero el cúmulo Zookeeper todavía puede tolerar un fallo del servidor.
Zookeeper ofrece coordinación y sincronización con lo que llama znodes, que se presentan como un árbol de directorios, y se asemejan a los nombres de ruta de archivos que te ve en un sistema de archivos Unix. Znodes hacer almacenar datos, pero no hay mucho que hablar de - en la actualidad menos de 1 MB de forma predeterminada.
La idea aquí es que Zookeeper tiendas znodes en la memoria y que estos znodes basados en memoria proporcionan acceso de cliente rápido para la coordinación, el estado y otras funciones vitales que requieren las aplicaciones distribuidas como HBase. Zookeeper replica znodes todo el conjunto por lo que si los servidores fallan, los datos znode está todavía disponible, siempre y cuando un quórum mayoría de los servidores es todavía en funcionamiento.
Otros principales preocupaciones concepto Zookeeper cómo lee znode (contra escritura) se manejan. Cualquier servidor Zookeeper puede manejar lee de un cliente, incluyendo el líder, pero sólo las cuestiones líder atómico znode escribe - escribe que sea completamente éxito o fracasan por completo.
Cuando llega una petición znode escritura en el nodo líder, el líder transmite la solicitud de escritura a los nodos de seguidor y espera a que la mayoría de los seguidores de reconocer znode escriba completa. Después de la confirmación, el líder emite la propia escritura znode y luego informa el estado de finalización con éxito al cliente.
Znodes proporcionan algunas garantías muy poderosas. Cuando un cliente Zookeeper (tal como un RegionServer HBase) escribe o lee un znode, la operación es atómico. Es ya sea por completo tiene éxito o fracasa por completo - no lee ninguna parcial o escribe.
Ningún otro cliente compitiendo puede causar la operación de lectura o escritura falle. Además, un znode tiene una lista de control de acceso (ACL) asociadas a ella para la seguridad, y es compatible con las versiones, marcas de tiempo y la notificación a los clientes cuando cambia.
Zookeeper replica znodes todo el conjunto por lo que si los servidores fallan, los datos znode está todavía disponible, siempre y cuando un quórum mayoría de los servidores es todavía en funcionamiento. Esto significa que escribe a cualquier znode desde cualquier servidor Zookeeper debe ser propagado en todo el conjunto. El líder Zookeeper gestiona esta operación.
Este enfoque de escritura znode puede causar seguidores a caer detrás del líder por períodos cortos. Zookeeper resuelve este problema potencial al proporcionar un comando de sincronización. Los clientes que no pueden tolerar esta falta temporal de sincronización dentro del clúster Zookeeper pueden decidir emitir un comando de sincronización antes de leer znodes.