Cómo escalable se distribuye Erlang?
Parte A:
Erlang tiene muchas historias de éxito sobre la ejecución de agentes concurrentes, por ejemplo, los millones de chats simultáneos de Facebook. Eso son millones de agentes, pero por supuesto no son millones de CPU a través de una red. Estoy teniendo problemas para encontrar métricas sobre qué tan bien se escala Erlang cuando el escalado es "horizontal" a través de una LAN/WAN.
Supongamos que tengo muchos (decenas de miles) nodos físicos (ejecutando Erlang en Linux) que necesitan comunicarse y sincronizar pequeños cantidades poco frecuentes de datos en la LAN / WAN. ¿En qué momento tendré cuellos de botella en las comunicaciones, no entre agentes, sino entre nodos físicos? (¿O esto solo funcionará, asumiendo una red estable?)
Parte B:
Entiendo (como un novato de Erlang, lo que significa que podría estar totalmente equivocado) que los nodos de Erlang intentan conectarse y ser conscientes unos de otros, lo que resulta en una red N^2 de conexión punto a punto. Asumiendo que la parte A no solo funcionará con N = 10K, puede Erlang puede configurarse fácilmente (usando configuración lista para usar o trivial boilerplate, no escribiendo una implementación completa de algoritmos de agrupación/enrutamiento yo mismo) para agrupar nodos en grupos manejables y enrutar mensajes de todo el sistema a través de la jerarquía de clúster/grupo?
1 answers
Debemos especificar que hablamos de escalabilidad horizontal de máquinas físicas that 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 ellas.
Node = máquina.
Para empezar, 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 una aplicación personalizada optimizada. Quiero decir, tiene ser un buen código, escrito con conocimiento sobre GC, características de los tipos de datos, transmisión 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 tiene que ser consciente del costo de, por ejemplo, sincronizar llamadas en todo el clúster.
La otra cosa es la capa DB. Mnesia (built-in) debido a que sus características no serán efectivas en más de 20 nodos (mi experiencia - puedo estar equivocado). Solución: simplemente use otra cosa: dynamo DBs, grupo separado de MySQLs, 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 clústeres 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 otros 50 clústeres de nodos. En resumen, tal sistema es la federación de N erlang clusters.
Distributed erlang está diseñado para ejecutarse en un centro de datos. Si necesitas más, nodos geográficamente distantes, luego use federaciones.
Hay muchas opciones de configuración, por ejemplo, que no conectan todos los nodos entre sí. Puede ser útil, sin embargo en ~50 cluster erlang overhead no es significativo. También puede crear un gráfico de nodos erlang utilizando conexión 'oculta', que no se une a esta malla completa, pero también no puede beneficiarse de la conexión a todos los nodos.
El mayor problema que veo, en este tipo de sistemas, es diseñarlo como sistema sin maestro. Si no necesito eso, todo debería estar bien.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-02-18 21:49:52