locking - ¿Alternativas de ZooKeeper?(servicio de coordinación de clúster)
cluster-computing high-availability (11)
Acabo de descubrir Accord (C) y OpenReplica/ConCoord (Python) que pueden ser soluciones interesantes
[EDIT] La tripulación de Hashicorp, de la fama de Vagrant y Packer, está cocinando "una solución descentralizada para el descubrimiento y la orquestación de servicios" llamada Serf .
[EDIT2] Hashicorp ataca de nuevo! Acaban de lanzar cónsul , construido sobre Serf. The pitch: "una solución para descubrimiento y configuración de servicios, completamente distribuida, altamente disponible, escalable a miles de nodos y servicios en múltiples centros de datos".
ZooKeeper es un servicio de coordinación altamente disponible para centros de datos. Se originó en el proyecto Hadoop. Uno puede implementar el bloqueo, la conmutación por error, la elección del líder, la membresía grupal y otros asuntos de coordinación además de eso. ¿Hay alguna alternativa a ZooKeeper? (software libre, por supuesto)
Encontré esta comparación de Zookeeper, etcd y Doozer: http://devo.ps/blog/zookeeper-vs-doozer-vs-etcd/
Serf (serfdom.io) es también una buena solución, ¡ya que es simple! Pero debe tener en cuenta que SERF es solo un administrador de clúster que le permite enviar eventos personalizados a todos los nodos del clúster. Eso es bueno, pero tienes que escribir tus propios scripts de shell (también conocidos como eventos). Vea este ejemplo: " https://www.digitalocean.com/community/articles/how-to-set-up-a-serf-cluster-on-several-ubuntu-vps "
La ventaja es que obtiene un administrador de clústeres muy simple y puede combinar esto con su configuración favorita, implementación o herramienta de integración continua.
Existen diferentes herramientas que optimizan para diferentes trade-offs de ingeniería.
- ZooKeeper Escala marginalmente para lecturas; escribe con muchos observadores puede ser lento. Está probado y tiene una comunidad considerable.
- Accord parece interesante para usos de escritura intensiva, sin embargo, los casos de uso típicos ya tienen soluciones específicas de dominio (es decir, registro, telemetría).
Los otros son algo interesantes, pero generalmente no probados. No lo malinterprete si está destinado al uso de producción.
Hay un proyecto llamado Noah en github que parece interesante, dice que está "basado libremente en Apache ZooKeeper" https://github.com/lusis/Noah con soporte REST como característica clave (ZK lo tiene como contrib / opción en vez de que construido adentro).
He buscado extensamente en Zookeeper / Curator , Eureka , etcd , y cónsul. Zookeeper / Curator y Eureka son en muchos sentidos los más pulidos y fáciles de integrar si estás en el mundo de Java. etcd es bastante genial y muy flexible, pero en realidad es solo un almacén de claves HA, por lo que tendría que escribir una gran cantidad de código para convertirlo en un sistema de descubrimiento de servicio obstinado.
Consul es (para mí) lo mejor de ambos mundos. Es un sistema de descubrimiento de servicio obstinado escrito encima de serf , que utiliza balsa para consenso de clúster y chismes para comunicación. Expone los puntos finales de descubrimiento / registro con una API REST bien documentada, y también le permite descubrir servicios con registros DNS SRV y registrar servicios con configuración (es decir, para que pueda registrar una base de datos o aplicación con la que no puede integrar un cliente; o si solo desea mantener su descubrimiento de servicio desacoplado de su aplicación)
He escrito una publicación en el blog sobre el cónsul, donde puedes obtener más información y recorrer mi demo de "prueba".
También mencioné el descubrimiento de servicios con etd & docker si desea ver más sobre cómo se verá ese código personalizado.
¡Una última cosa! etcd & consul están escritos en go, por lo que su mantenimiento es mucho más fácil que las soluciones de Java como zookeeper. Todo lo que necesitas es el binario cónsul / etcd. sin dependencias, sin bibliotecas vinculadas, sin jvm.
Parece que Corosync también es como ZooKeeper.
Sé que esta publicación es bastante antigua, pero alguien que está buscando todas las alternativas posibles, también me gustaría sugerir una biblioteca de JGroups que sea lo suficientemente madura como para ser utilizada en el entorno de producción. Lo he utilizado con éxito en uno de mis proyectos principalmente para la coordinación distribuida y para compartir mensajes entre clúster. También es compatible con el soporte de AWS además de su arquitectura flexible donde puede personalizar su stack para obtener lo que necesita. Te sugiero que lo eches un vistazo
Sí, también está Doozerd (https://github.com/ha/doozerd) . Míralo bien, es un buen servicio de coordinación distribuido binario único desarrollado por Heroku. Con enlaces / bibliotecas para java / python / ruby / node. Muy fácil para empezar y jugar.
OpenReplica/ConCoord de mi grupo de investigación es un servicio de coordinación de FOSS altamente disponible para centros de datos. Se puede usar para implementar bloqueo, conmutación por error, elección de líder, membresía grupal y otros servicios de coordinación. Difiere de ZooKeeper en dos formas fundamentales:
Utiliza una API orientada a objetos. Esto hace que sea mucho más fácil escribir servicios de coordinación. El código de sincronización para OpenReplica se ve exactamente como su contraparte de libro de texto; no es necesario dominar un archivo y una API basada en actualizaciones como en ZooKeeper y Chubby.
Permite actualizaciones de miembros dinámicos para el conjunto de réplicas. No hay necesidad de archivos de configuración estáticos. El sistema está integrado en DNS (autorizado, esclavo para OpenReplica o Amazon Route 53).
Apoyamos activamente el sistema, no dude en hacérnoslo saber si tiene más preguntas.
Existe una alternativa muy prometedora a ZooKeeper llamada etcd , escrita por el equipo de CoreOS. A diferencia de Doozerd, etcd se está desarrollando activamente.