¿Cómo escalable se distribuye Erlang?
scalability distributed (1)
Parte A:
Erlang tiene muchas historias de éxito sobre la ejecución de agentes concurrentes, por ejemplo, los millones de chats de Facebook simultáneos. Son millones de agentes, pero, por supuesto, no son millones de CPU en una red. Estoy teniendo problemas para encontrar métricas sobre qué tan bien se escala Erlang cuando la escala es "horizontal" a través de una LAN / WAN.
Supongamos que tengo muchos (decenas de miles) nodos físicos (que ejecutan Erlang en Linux) que necesitan comunicarse y sincronizar pequeñas cantidades de datos poco frecuentes a través de la LAN / WAN. ¿En qué momento tendré cuellos de botella en las comunicaciones, no entre agentes, sino entre nodos físicos? (¿O solo funcionará, suponiendo una red estable?)
Parte B:
Entiendo (como novato de Erlang, lo que significa que podría estar totalmente equivocado) que los nodos de Erlang intentan conectarse y ser conscientes de cada uno, lo que da como resultado una red de punto a punto de conexión N ^ 2. Suponiendo que la parte A no solo funcione con N = 10K, se puede configurar Erlang fácilmente (usando la configuración lista para usar o la placa de caligrafía trivial, sin escribir una implementación completa de los algoritmos de agrupación / enrutamiento) para agrupar los nodos en algo manejable ¿Grupos y enrutamiento de mensajes en todo el sistema a través de la jerarquía de clúster / grupo?
Debemos especificar que hablamos sobre la escalabilidad horizontal de las máquinas físicas, ese es el único problema. Las CPU de una máquina serán manejadas por una máquina virtual, sin importar el número de estas.
nodo = máquina.
Para comenzar, puedo decir que de 30 a 60 nodos salen de la caja (instalación de vainilla OTP) con cualquier aplicación personalizada escrita en la parte superior de eso (en Erlang). Prueba: ejabberd.
~ 100-150 es posible con la aplicación personalizada optimizada. Es decir, tiene que ser un buen código, escrito con conocimiento acerca de GC, características de los tipos de datos, paso de mensajes, etc.
más de +150 está bien, pero cuando hablamos de números como 300, 500 requerirá optimizaciones y personalizaciones de la capa TCP. Además, nuestra aplicación debe ser consciente del costo de, por ejemplo, sincronizar llamadas en todo el clúster.
La otra cosa es la capa DB. Mnesia (incorporada) debido a sus características no será efectiva en más de 20 nodos (según mi experiencia, puedo estar equivocado). Solución: solo use otra cosa: DB de dínamo, clúster separado de MySQL, HBase, etc.
La técnica más común para aprovechar el costo de crear aplicaciones de alta calidad y escalabilidad son las federaciones de ~ 20-50 clusters de nodos. Por lo tanto, internamente es una malla eficiente de ~ 50 nodos Erlang y está conectada a través de cualquier protocolo adecuado con N grupos de otros 50 nodos. En resumen, tal sistema es la federación de clusters de Nueva York.
El erlang distribuido está diseñado para ejecutarse en un centro de datos. Si necesita más nodos geográficamente distantes, use federaciones.
Hay muchas opciones de configuración, por ejemplo, que no conectan entre sí todos los nodos. Puede ser útil, sin embargo, en ~ 50 la sobrecarga de erlang del clúster no es significativa. También puede crear un gráfico de nodos Erlang utilizando la conexión ''oculta'', que no se une a esta malla completa, pero tampoco puede beneficiarse de la conexión a todos los nodos.
El mayor problema que veo, en este tipo de sistemas, es diseñarlo como un sistema sin maestro. Si no necesitas eso, todo debería estar bien.