Memoria persistente per Apache Mesos

Question

Recentemente ho scoperto una cosa come un Apache Mesos.

Sembra tutto incredibilmente in tutte le demo e gli esempi. Potrei facilmente immaginare come si farebbe per i lavori apolidi - che si adatta naturalmente a tutta l'idea.

Bot come gestire i lavori di lunga durata con stato?

Dire, ho un cluster costituito da N macchine (e che è pianificato tramite Marathon). E voglio eseguire un server postgresql lì.

Questo è tutto - inizialmente non voglio nemmeno che sia altamente disponibile, ma semplicemente un singolo lavoro (in realtà Dockerized) che ospita un server postgresql.

1- Come organizzarlo? Vincolare un server a un particolare nodo del cluster? Usa alcune FS distribuite?

2- DRBD, MooseFS, GlusterFS, NFS, CephFS, quali di questi funzionano bene con Mesos e servizi come postgres? (Sto pensando qui alla possibilità che Mesos/marathon possa trasferire il servizio se scende)

3- Si prega di dire se il mio approccio è sbagliato in termini di filosofia (DFS per i server di dati e qualche tipo di passaggio per i server come postgres sulla parte superiore della Mesos)

_{^{domanda in gran parte copiato da Persistent storage for Apache Mesos, chiesto da zerkms su Programmers Stack Exchange.}}

Answer 1

Ottima domanda. Ecco alcune funzionalità imminenti in Mesos per migliorare il supporto per i servizi di stato e le soluzioni alternative corrispondenti.

1. Persistent volumes (0,23): Quando si lancia un compito, è possibile creare un volume che esiste al di fuori della sandbox del compito e persisterà sul nodo anche dopo che il compito muore/completata. Quando l'attività termina, le sue risorse, incluso il volume persistente, possono essere restituite al framework, in modo che il framework possa avviare di nuovo la stessa attività, avviare un'attività di ripristino o avviare una nuova attività che consumi l'output dell'attività precedente come suo input.
   • Soluzione corrente: mantenere il proprio stato in una posizione nota all'esterno della sandbox e fare in modo che le attività provino a ripristinarlo manualmente. Magari lo persistono in un filesystem/database distribuito, in modo che sia accessibile da qualsiasi nodo.
2. DiskIsolation (0,22): Applicare limiti di quota disco su sandboxes nonché volumi permanenti. Ciò garantisce che il framework di archiviazione pesante non sia in grado di intasare il disco e impedire l'esecuzione di altre attività.
   • Soluzione corrente: Monitorare l'utilizzo del disco fuori banda ed eseguire processi di pulizia periodici.
3. Dynamic Reservations (0,23): Su lancio di un compito, è possibile prenotare le risorse utilizzata dal tuo compito (compresi i volumi permanenti) per garantire che essi sono offerti di nuovo voi all'uscita compito, invece di andare a seconda di quale quadro è più lontana sotto la sua giusta quota.
   • Soluzione corrente: utilizzare il flag --resources dello slave per riservare in modo statico le risorse per il framework all'avvio dello slave.

quanto riguarda il tuo caso d'uso specifico e domande:

1a) come si potrebbe organizzare esso? È possibile farlo con Marathon, magari creando un'istanza Marathon separata per i servizi di stato, in modo da poter creare prenotazioni statiche per il ruolo "stateful", in modo tale che solo la maratona di stato garantisca tali risorse.

1b) Vincolare un server a un particolare nodo del cluster? È possibile farlo facilmente in Marathon, vincolando un'applicazione a un nome host specifico o qualsiasi nodo con un valore di attributo specifico (ad esempio NFS_Access = true). Vedi Marathon Constraints. Se si desidera eseguire solo le attività su un set specifico di nodi, sarà necessario solo creare le prenotazioni statiche su tali nodi. E se hai bisogno di scoprire questi nodi, dovresti dare un'occhiata a Mesos-DNS e/o Marathon's HAProxy integration.

1c) Utilizzare alcuni FS distribuiti? La replica dei dati fornita da molti file system distribuiti garantisce che i dati possano sopravvivere al fallimento di qualsiasi singolo nodo. Persistere in un DFS fornirebbe inoltre una maggiore flessibilità in cui è possibile pianificare le attività, anche se al costo della differenza di latenza tra la rete e il disco locale. Mesos ha il supporto integrato per il recupero di file binari da uris HDFS e molti clienti utilizzano HDFS per il trasferimento di file binari dell'esecutore, file di configurazione e dati di input per gli slave in cui verranno eseguite le attività.

2) DRBD, MooseFS, GlusterFS, NFS, CephFS? Ho sentito parlare di clienti che usano CephFS, HDFS e MapRFS con Mesos. Anche NFS sembrerebbe una soluzione facile. Non importa a Mesos ciò che usi finché il tuo compito sa come accedervi da qualunque nodo in cui è collocato.

Spero che questo aiuti!