¿Cómo se distribuye Erlang?

Question

Parte A:

Erlang tiene una gran cantidad de casos de éxito sobre la ejecución de los agentes concurrentes, por ejemplo, los millones de chats simultáneos en Facebook. Son millones de agentes, pero, por supuesto, no son millones de CPU en una red. Tengo problemas para encontrar métricas sobre qué tan bien Erlang escala 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 infrecuentes de datos a través de LAN/WAN. ¿En qué momento tendré cuellos de botella en las comunicaciones, no entre agentes, sino entre nodos físicos? (¿O será ésta sólo trabajo, asumiendo una red estable?)

Parte B:

entiendo (como un novato de Erlang, lo que significa que podría estar totalmente equivocado) que Erlang los nodos intentan todo conectarse y estar conscientes el uno del otro, lo que da como resultado una conexión N-2 de red punto a punto. Suponiendo que la parte A no solo funcione con N = 10K, ¿se puede configurar fácilmente Erlang (usando una configuración predeterminada o un texto repetitivo trivial, sin escribir una implementación completa de los algoritmos de agrupación/enrutamiento yo mismo) en nodos del clúster en manejables? grupos y enrutar mensajes de todo el sistema a través de la jerarquía de clúster/grupo?

Answer 1

Debemos especificar que hablamos de la escalabilidad horizontal de las máquinas físicas: ese es el único problema. Las CPU en una máquina serán manejadas por una máquina virtual, sin importar el número de ellas.

node = máquina.

Para comenzar, puedo decir que 30-60 nodos se obtienen de la caja (instalación OTP vainilla) 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. Quiero decir, tiene que ser un buen código, escrito con conocimiento sobre GC, característica de los tipos de datos, mensaje que pasa, etc.

sobre +150 está bien pero cuando hablamos de números como 300, 500 requerirá optimizaciones & personalizaciones de la capa TCP. Además, nuestra aplicación debe conocer el costo de, p. sincronizar llamadas en el clúster.

La otra cosa es la capa de DB. Mnesia (incorporado) debido a sus características no será efectivo en más de 20 nodos (mi experiencia, puedo estar equivocado). Solución: simplemente use algo más: dynamo DBs, 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 federaciones de ~ 20-50 clústeres de nodos. Así que internamente es una malla eficiente de ~ 50 nodos erlang y está conectada a través de cualquier protocolo adecuado con N otros 50 clústeres de nodos. En resumen, un sistema de este tipo es la federación de clusters de N erlang.

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, p. que no conectan todos los nodos entre sí. Puede ser útil, sin embargo, en ~ 50 clúster, la sobrecarga de erlang no es significativa. También puede crear un gráfico de nodos erlang usando 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.