¿Diseño eficiente para un servidor python distribuido?

Question

Si quisiera distribuir Python en varios procesadores en varias computadoras, ¿cuál sería mi mejor enfoque? Si tengo 3 servidores de ocho núcleos, eso significaría que tendría que ejecutar 24 procesos de Python. Estaría usando la biblioteca de multiprocesamiento , y para compartir objetos parece la mejor idea sería usar un gerente. Quiero que todos los nodos trabajen juntos como un gran proceso, por lo que un administrador sería ideal, pero eso le daría a mi servidor un único punto de falla. ¿Hay una mejor solución? ¿Sería una buena idea replicar el almacén de objetos de un administrador?

Además, si el administrador va a hacer todas las consultas de la base de datos, ¿tendría sentido tenerlo en la misma máquina que la base de datos?

Answer 1

Tienes dos desafíos principales en la distribución de los procesos:

1. Coordinar el trabajo que se divide, distribuye y vuelve a recopilar (mapeado y reducido, se podría decir)
2. Compartir los datos en vivo correctos entre procesos co-dependientes

La respuesta al # 1 dependerá en gran medida del tipo de procesamiento que esté haciendo. Si es fácilmente particionable horizontalmente (es decir, puede dividir la tarea más grande en varias tareas independientes más pequeñas), un equilibrador de carga como HAProxy podría ser una forma conveniente de distribuir la carga.

Si la tarea no es particionable trivialmente horizontalmente, primero miraría para ver si las herramientas existentes, como Hadoop , funcionaría para mí. La gestión distribuida de tareas es una tarea difícil de realizar, y la rueda ya se ha inventado.

En cuanto al # 2, compartir el estado entre los procesos, su vida será mucho más fácil si comparte un mínimo absoluto, y luego solo lo comparte de manera explícita y bien definida. Yo personalmente usaría SQLAlchemy respaldado por su RDBMS de elección incluso para las tareas más pequeñas. La interfaz de consulta es lo suficientemente potente e indolora para proyectos pequeños y grandes por igual.

Answer 2

Creo que más información sería útil, sobre qué tipo de cosas está sirviendo, qué tipo de base de datos usaría, qué tipo de requisitos de latencia / rendimiento tiene, etc. Muchas cosas dependen de sus requisitos: por ejemplo . Si su sistema es un servidor típico que tiene muchas lecturas y no tantas escrituras, y no tiene problemas para leer datos ligeramente obsoletos, puede realizar lecturas locales en un caché en cada proceso y solo enviar las escrituras a la base de datos, transmitiendo los resultados a las cachés.

Para empezar, creo que depende de lo que el gerente tenga que hacer. Después de todo, preocuparse por puntos únicos de falla puede no tener sentido si su sistema es tan trivial que la falla no ocurrirá antes de una falla catastrófica del hardware. Pero si solo tiene uno, tenerlo en la misma máquina que la base de datos tiene sentido. Reduce la latencia y su sistema no puede sobrevivir si uno se cae sin el otro de todos modos.

Answer 3

Parece que la esencia de su pregunta es cómo compartir objetos y estados. Sería muy útil más información, particularmente el tamaño, la frecuencia, la tasa de cambio y la fuente de datos.

Para la memoria compartida entre máquinas, es probable que desee ver memcached . Puede almacenar sus datos y acceder a ellos de forma rápida y sencilla desde cualquiera de los procesos de trabajo.

Si su escenario es más un simple modelo de distribución de trabajo, es posible que desee ver un servidor de cola: coloque sus trabajos y sus datos asociados en una cola y haga que los trabajadores recojan los trabajos de la cola. Beanstalkd es probablemente una buena opción para la cola, y aquí hay una tutorial de inicio .