Casi todas las aplicaciones comerciales exitosas, tarde o temprano, entran en una fase en la que se requiere escalamiento horizontal. En muchos casos, simplemente puede iniciar una nueva instancia y reducir el promedio de carga. Pero también hay casos menos triviales en los que debemos asegurarnos de que los diferentes nodos se conozcan entre sí y distribuyan cuidadosamente la carga de trabajo.
Resultó tan afortunado que Erlang, que elegimos por su sintaxis agradable y la publicidad que lo rodea, tiene una calidad de primera clase. . En teoría, esto suena completamente trivial:
El paso de mensajes entre procesos en diferentes nodos, así como entre enlaces y monitores, es transparente […]
En la práctica todo es un poco más complicado. Repartido Erlang se desarrolló cuando "contenedor" significaba una gran caja de hierro para el envío, y "estibador" era simplemente un sinónimo de estibador. EN IP4 Había muchas direcciones desocupadas, las interrupciones de la red generalmente eran causadas por ratas que mordían el cable y el tiempo de actividad promedio del sistema de producción se medía en décadas.
Ahora todos somos increíblemente autosuficientes, empaquetados y ejecutando Erlang en un entorno donde las direcciones IP dinámicas se entregan según el principio de gran aleatoriedad y los nodos pueden aparecer y desaparecer según el capricho del talón izquierdo del programador. Para evitar montones de código repetitivo en cada proyecto que ejecuta un sistema distribuido Erlang, para combatir el entorno hostil se necesita ayuda.
Nota: Soy consciente de que hay . Es realmente genial, tiene más de mil estrellas, el autor es famoso en la comunidad y todo eso. Si los métodos que ofrece este paquete para crear y mantener un clúster son suficientes para usted, me alegro por usted. Lamentablemente necesito mucho más. Quiero controlar la configuración en detalle y no ser un espectador externo en el teatro de la reorganización del cluster.
Requisitos
Lo que yo personalmente necesitaba era una biblioteca que se hiciera cargo de la gestión del clúster y tuviera las siguientes propiedades:
- Trabajo transparente con una lista codificada de nodos y descubrimiento dinámico a través de servicios. Erlang;
- devolución de llamada completamente funcional para cada cambio de topología (nodo allí, nodo aquí, inestabilidad de la red, divisiones);
- interfaz transparente para lanzar un clúster con nombres largos y cortos, como con
:nonode@nohost; - Soporte Docker listo para usar, sin tener que escribir código de infraestructura.
Esto último significa que después de probar la aplicación localmente en :nonode@nohost, o en un entorno distribuido artificialmente utilizando , solo quiero correr docker-compose up --scale my_app=3 y vea cómo ejecuta tres instancias en Docker sin ningún cambio de código. También quiero aplicaciones dependientes como mnesia - cuando la topología cambia, entre bastidores reconstruyen el clúster en vivo sin ningún impulso adicional por parte de la aplicación.
Claustro no estaba pensada para ser una biblioteca capaz de hacer de todo, desde soportar un grupo hasta preparar café. No es una solución milagrosa que pretenda abarcar todos los casos posibles, ni ser una solución académicamente completa en el sentido de que los teóricos de CS puesto en este término. Esta biblioteca está diseñada para cumplir un propósito muy claro, pero hace perfectamente su trabajo no demasiado grande. Este objetivo será proporcionar total transparencia entre el entorno de desarrollo local y un entorno elástico distribuido lleno de contenedores hostiles.
Enfoque elegido
Claustro está diseñado para ejecutarse como una aplicación, aunque los usuarios avanzados pueden trabajar con el ensamblaje y mantenimiento del clúster manualmente ejecutando directamente Cloister.Manager en el árbol supervisor de la aplicación de destino.
Cuando se ejecuta como una aplicación, la biblioteca se basa en config, de donde lee los siguientes valores básicos:
config :cloister,
otp_app: :my_app,
sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
consensus: 3, # number of nodes to consider
# the cluster is up
listener: MyApp.Listener # listener to be called when
# the ring has changedLos parámetros anteriores significan literalmente lo siguiente: Claustro utilizado para la aplicación OTP :my_app, usos descubrimiento de servicios erlang para conectar nodos, al menos tres, y MyApp.Listener módulo (implementando ) está configurado para recibir notificaciones sobre cambios de topología. Puede encontrar una descripción detallada de la configuración completa en .
Con esta configuración, la aplicación Claustro voluntad , retrasando el proceso de inicio de la aplicación principal hasta que se alcance un consenso (tres nodos están conectados y conectados, como en el ejemplo anterior). Esto le da a la aplicación principal la oportunidad de asumir que cuando se inicia, el clúster ya está disponible. Siempre que cambie la topología (habrá muchos de ellos, porque los nodos no se inician completamente sincrónicamente), se llamará al controlador . La mayoría de las veces realizamos una acción cuando recibimos un mensaje de estado. %Cloister.Monitor{status: :up}, que significa: "Hola, el clúster está ensamblado".
En la mayoría de los casos, la instalación consensus: 3 es óptimo porque incluso si esperamos que se conecten más nodos, la devolución de llamada se realizará status: :rehashing → status: :up en cualquier nodo recién agregado o eliminado.
Al iniciar en modo de desarrollo, solo necesita configurar consensus: 1 и Claustro felizmente se saltará la espera para el ensamblaje del grupo cuando vea :nonode@nohostO :node@hostO :node@host.domain - dependiendo de cómo se configuró el nodo (:none | :shortnames | :longnames).
Gestión de aplicaciones distribuidas
Las aplicaciones distribuidas que no están en el vacío generalmente incluyen dependencias distribuidas, como mnesia. Es fácil para nosotros manejar su reconfiguración desde la misma devolución de llamada. on_state_change/2. Aquí, por ejemplo, hay una descripción detallada de cómo reconfigurar mnesia sobre la marcha en .
La principal ventaja de utilizar Claustro es que realiza todas las operaciones necesarias para reconstruir el cluster después de un cambio de topología bajo el capó. La aplicación simplemente se ejecuta en un entorno distribuido ya preparado, con todos los nodos conectados, independientemente de si conocemos las direcciones IP y, por tanto, los nombres de los nodos de antemano, o si se han asignado/cambiado dinámicamente. Esto no requiere absolutamente ninguna configuración especial de la ventana acoplable y, desde el punto de vista de un desarrollador de aplicaciones, no hay diferencia entre ejecutarse en un entorno distribuido o ejecutarse en uno local. :nonode@nohost. Puedes leer más sobre esto en .
Aunque el manejo complejo de cambios de topología es posible a través de una implementación personalizada MyApp.Listener, siempre puede haber casos extremos en los que estas limitaciones de la biblioteca y sesgos de configuración resulten ser las piedras angulares de la implementación. Está bien, solo toma lo anterior. libcluster, que es de propósito más general, o incluso manejar el clúster de bajo nivel usted mismo. El objetivo de esta biblioteca de códigos no es cubrir todos los escenarios posibles, sino utilizar el escenario más común sin complicaciones innecesarias ni el engorroso copiar y pegar.
Nota: En este punto, en el original aparecía la frase "¡Feliz agrupamiento!", y Yandex, con el que traduzco (no tengo que revisar diccionarios), me ofreció la opción "¡Feliz agrupamiento!". Quizás sea imposible imaginar una traducción mejor, especialmente a la luz de la actual situación geopolítica.
Fuente: habr.com
