scala - disponibilidad - cluster linux
Scala+Akka: cómo desarrollar un clúster de alta disponibilidad para múltiples máquinas (4)
Estamos desarrollando un sistema de servidor en Scala + Akka para un juego que servirá a clientes en Android, iPhone y Second Life. Hay partes de este servidor que necesitan estar altamente disponibles, ejecutándose en múltiples máquinas. Si uno de esos servidores muere (por ejemplo, por un fallo de hardware), el sistema debe seguir funcionando. Creo que quiero que los clientes tengan una lista de máquinas con las que intentarán conectarse, de manera similar a cómo funciona Cassandra.
Los ejemplos de varios nodos que he visto hasta ahora con Akka me parecen centrados en la idea de escalabilidad, en lugar de alta disponibilidad (al menos con respecto al hardware). Los ejemplos de múltiples nodos parecen tener siempre un único punto de falla. Por ejemplo, hay balanceadores de carga, pero si necesito reiniciar una de las máquinas que tienen balanceadores de carga, mi sistema sufrirá algún tiempo de inactividad.
¿Hay ejemplos que muestren este tipo de tolerancia a fallos de hardware para Akka? O, ¿tienes alguna idea sobre las buenas maneras de hacer que esto suceda?
Hasta ahora, la mejor respuesta que he podido encontrar es estudiar los documentos de Erlang OTP, meditar en ellos e intentar descubrir cómo armar mi sistema utilizando los bloques de construcción disponibles en Akka.
Pero si hay recursos, ejemplos o ideas sobre cómo compartir el estado entre varias máquinas de manera que si una de ellas falla, las cosas siguen funcionando, seguro que las apreciaría, porque me preocupa que podría estar reinventando La rueda aquí. ¿Tal vez hay un contenedor STM de múltiples nodos que mantiene automáticamente sincronizado el estado compartido en múltiples nodos? O quizás esto sea tan fácil de hacer que la documentación no se moleste en mostrar ejemplos de cómo hacerlo, o quizás no haya sido lo suficientemente exhaustivo en mi investigación y experimentación todavía. Cualquier pensamiento o ideas serán apreciados.
2 centavos ..
"Cómo compartir el estado entre varias máquinas de manera que si una de ellas se apaga, las cosas siguen funcionando"
No comparta el estado entre las máquinas, en su lugar, particione el estado entre las máquinas. No sé tu dominio, así que no sé si esto funcionará. Pero esencialmente si asigna ciertos agregados (en términos de DDD) a ciertos nodos, puede mantener esos agregados en la memoria (actor, agente, etc.) cuando se están utilizando. Para hacer esto, necesitarás usar algo como un guardián del zoológico para coordinar qué nodos manejan los agregados. En caso de fallo, puede activar el agregado en un nodo diferente.
Además, si utiliza un modelo de fuente de eventos para construir sus agregados, se vuelve casi trivial tener copias en tiempo real (esclavos) de su agregado en otros nodos por parte de los nodos que escuchan los eventos y mantienen sus propias copias.
Al utilizar Akka, obtenemos la comunicación remota entre nodos casi de forma gratuita. Esto significa que cualquier nodo que maneje una solicitud que pueda necesitar interactuar con un Agregado / Entidad en otros nodos puede hacerlo con RemoteActors.
Lo que he descrito aquí es muy general, pero ofrece un enfoque de tolerancia a fallos distribuida con Akka y ZooKeeper. Puede o no puede ayudar. Espero que lo haga.
Todo lo mejor, Andy
Podrías echar un vistazo a cómo se RedDwarf y su fork DimDwarf . Ambos son servidores de aplicaciones de juego de solo bloqueo escalables horizontalmente y DimDwarf está parcialmente escrito en Scala (nueva funcionalidad de mensajería). Su enfoque y arquitectura deben coincidir con sus necesidades bastante bien :)
Si ya está listando múltiples hosts potenciales en sus clientes, entonces esos pueden convertirse efectivamente en balanceadores de carga.
Podría ofrecer un servicio de sugerencias de host y recomendar al cliente a qué máquina deben conectarse (según la carga actual, o lo que sea), luego el cliente puede determinarlo hasta que la conexión falle.
Si el servicio de sugerencias de host no está allí, entonces el cliente simplemente puede elegir un host aleatorio de la lista interna, probándolos hasta que se conecte.
Idealmente, la primera vez que se inicie, el cliente se conectará al servicio de sugerencias de host y no solo se dirigirá a un host apropiado, sino también a una lista de otros hosts potenciales. Esta lista puede actualizarse rutinariamente cada vez que el cliente se conecta.
Si el servicio de sugerencias de host está inactivo en el primer intento de los clientes (poco probable, pero ...), entonces puede desplegar previamente una lista de hosts en la instalación del cliente para que pueda comenzar a seleccionar hosts de forma aleatoria desde el principio, si es que también lo ha .
Asegúrese de que su lista de hosts sean nombres de host reales, y no IP, que le brinden más flexibilidad a largo plazo (es decir, "siempre tendrá" host1.example.com, host2.example.com ... etc. incluso si mueves infraestructura y cambias IPs.
La gestión de carga y carga es un aspecto muy importante de la escalabilidad y está disponible como parte de la AkkaSource comercial de AkkaSource .