¿Alguien ha implementado un conjunto ZooKeeper en los centros de datos?

Para respaldar lo que Benjamin ha mencionado, nosotros (LinkedIn) seguimos el mismo patrón. Implementamos un conjunto de cuidador de zoológico en cada centro de datos. Las herramientas que ejecutamos para actualizar cualquier configuración aseguran que actualice tanto a los cuidadores del zoológico.

En general, la solución depende de su caso de uso. ¿Es generalmente de solo lectura o escritura pesada? Si solo se lee y se usa principalmente para la detección, puede ejecutarlos en centros de datos. La complejidad adicional necesaria aquí sería asegurar que el cliente se conecte a uno de los servidores zk que es local (sin entrar en detalles, puede asegurarse de esto desconectándose de zk hasta que se conecte a uno que sea local).

Si tiene dos centros de datos que abarcan un conjunto de zookeeper a través de ellos, no proporciona redundancia adicional (porque si un centro de datos está inactivo, zookeeper no puede alcanzar el quórum y, por lo tanto, todas las escrituras fallarán). Necesitará un desempate en otro lugar o un tercer centro de datos. En general, es complicado ejecutar Zookeeper en múltiples centros de datos.

Probablemente sea más fácil y seguro ejecutar conjuntos zk separados en cada centro de datos y diseñar su sistema de manera que funcione en esta configuración.

Espero que ayude.

Sí tenemos. Bueno, no exactamente como lo ha descrito … pero teníamos un sistema ZooKeeper que abarcaba 4 centros de datos diferentes.

Sin embargo, tomamos la decisión consciente de mantener los Conjuntos separados entre sí, por lo que, en esencia, teníamos 4 conjuntos diferentes. Luego tuvimos una herramienta de administración que usamos para hacer cambios en las claves de ZooKeeper. Cuando se cambiaba una clave, la herramienta de administración actualizaba la clave dentro de los cuatro conjuntos. En esencia, los 4 conjuntos siempre fueron iguales … pero los hicimos funcionar como conjuntos distintos.

Lo hicimos así por varias razones:

  1. Mantener listas de configuración de todos los servidores en los 4 centros de datos (para la elección adecuada del líder) parecía excesivo.
  2. Hubiéramos tenido que crear túneles SSH entre los DataCenters para cada ruta posible entre los servidores … nuevamente parecía una exageración y una solución que no escalaba.
  3. El enfoque que tomamos ofrecía un poco de redundancia de datos si fallaba un clúster completo. Simplemente puede recuperar el clúster sincronizándolo con uno de los otros clústeres del centro de datos.
  4. Para otros servicios que realizan replicación en diferentes centros de datos, notaríamos conexiones ocasionales o caídas de rutas, etc. Estábamos preocupados por lo que esto haría a la elección del líder Zookeeper.

Nuestro enfoque puso la latencia del centro de datos cruzados en la herramienta de administración en lugar de en el proceso de sincronización dentro del conjunto como un todo.

Nuestra implementación consistió en 4 conjuntos, cada conjunto tenía un tamaño de 5 a 11 nodos, dependiendo del tamaño del cliente para ese centro de datos.

Hemos estado utilizando este enfoque durante casi 3 años con muy poco mantenimiento o mantenimiento.

ZooKeeper es en realidad un tema fascinante para mí … Si te interesa, aquí hay algunos otros buenos hilos sobre ZooKeeper y nuestra implementación:

Reinicio continuo en Apache ZooKeeper para agregar servidores dinámicamente al conjunto
Tiempo de espera de conexión del cliente o errores de desconexión con Apache ZooKeeper
¿Cómo se monitorea el recuento de Apache ZooKeeper Connection?
¿Cuál es el tamaño límite de datos zNode para Apache ZooKeeper?
Apache ZooKeeper – Pensamientos iniciales

Si está interesado en el centro de datos cruzados, cónsul es una solución construida desde cero con esta consideración en mente. También es más escalable que el cuidador del zoológico. Solo si eso ayuda.

No es un enfoque ampliamente adoptado, pero nada te impide hacerlo. Siempre que la latencia cruzada del centro de datos tenga un límite superior razonable, esto no debería ser un problema en absoluto. Aunque depende de su aplicación, aquí hay un par de soluciones alternativas:

  • Use un DNS antiguo simple: su solución de monitoreo debe monitorear constantemente el centro de datos primario y, si falla, debe cambiar los registros DNS.
  • Utilice los mecanismos de conmutación por error del lado del cliente. La aplicación del cliente es lo suficientemente inteligente como para cambiar a otro centro de datos si algo sale mal. Esto es más difícil que la primera opción, pero no tiene que lidiar con dolores de invalidación de caché DNS.