Almacenamiento persistente para Apache Mesos

Excelente pregunta. Aquí hay algunas características próximas en Mesos para mejorar el soporte para servicios con estado y las soluciones actuales correspondientes.

1. Persistent volumes (0.23): Al iniciar una tarea, puede crear un volumen que exista fuera del sandbox de la tarea y persistirá en el nodo incluso después de que la tarea muera/se complete. Cuando la tarea finaliza, sus recursos, incluido el volumen persistente, se pueden ofrecer de nuevo al framework, de modo que el framework pueda inicie la misma tarea de nuevo, inicie una tarea de recuperación o inicie una nueva tarea que consuma el resultado de la tarea anterior como entrada.
   • Solución actual: Mantenga su estado en alguna ubicación conocida fuera del sandbox y haga que sus tareas intenten recuperarlo manualmente. Tal vez persistir en un sistema de archivos distribuido/base de datos, de modo que se puede acceder desde cualquier nodo.
2. Disco Isolation (0.22): Aplique límites de cuota de disco en las cajas de arena, así como en las persistentes volumen. Esto garantiza que su marco de trabajo con mucho almacenamiento no pueda obstruir el disco y evitar que se ejecuten otras tareas.
   • Solución actual: Supervise el uso del disco fuera de banda y ejecute trabajos de limpieza periódicos.
3. Dynamic Reservations (0.23) : Al iniciar una tarea, puede reservar los recursos que su tarea usa (incluidos los volúmenes persistentes) para garantizar que se le ofrezcan al salir de la tarea, en lugar de ir a cualquier marco más por debajo de su cuota justa.
   • Solución actual: Use la bandera del esclavo --resources para reservar estáticamente recursos para su marco al iniciar el esclavo.

En cuanto a su caso de uso específico y preguntas:

1a) ¿Cómo se organizaría? Podría hacer esto con Marathon, tal vez creando una instancia Marathon separada para sus servicios con estado, de modo que pueda crear reservas estáticas para el rol 'con estado', de modo que solo el Marathon tendrá garantizados esos recursos.

1b) ¿Restringir un servidor a un nodo de clúster en particular? Puede hacer esto fácilmente en Marathon, restringiendo una aplicación a un nombre de host específico, o cualquier nodo con un valor de atributo específico (por ejemplo, NFS_Access=true). Véase Limitaciones de maratón. Si solo desea ejecutar sus tareas en un conjunto específico de nodos, solo necesitará crear las reservas estáticas en esos nodos. Y si necesita visibilidad de esos nodos, deberías revisar Mesos-DNS y/o La integración de HAProxy de Marathon .

1c) ¿Usar algunos servicios financieros distribuidos? La replicación de datos proporcionada por muchos sistemas de archivos distribuidos garantizaría que sus datos puedan sobrevivir a la falla de cualquier nodo individual. Persistir en un DFS también proporcionaría más flexibilidad en el lugar donde puede programar sus tareas, aunque a costa de la diferencia de latencia entre la red y el disco local. Mesos tiene soporte incorporado para obtener binarios de uri HDFS, y muchos clientes usan HDFS para pasar binarios ejecutores, archivos de configuración y datos de entrada a los esclavos donde se ejecutarán sus tareas.

2) DRBD, MooseFS, GlusterFS, NFS, CephFS? He oído hablar de clientes que usan CephFS, HDFS y MapRFS con Mesos. NFS también parecería un ajuste fácil. Realmente no importa a Mesos lo que uses, siempre y cuando tu tarea sepa cómo acceder a ella desde cualquier nodo donde se coloque.

Espero que ayude!