Trwałe przechowywanie dla Apache Mesos

Question

Ostatnio odkryłem coś takiego jak Apache Mesos.

Wszystko to wygląda niesamowicie we wszystkich tych demonstracjach i przykładach. Z łatwością mogłem sobie wyobrazić, jak można pracować dla bezpaństwowców - to pasuje do całego pomysłu w sposób naturalny.

Bot jak radzić sobie z długotrwałymi zadaniami, które są stanowe?

Powiedzmy, mam klaster składający się z N komputerów (i to jest zaplanowane przez Maraton). I chcę uruchomić tam serwer PostgreSQL.

To jest to - na początku nie chcę nawet, aby był wysoce dostępny, ale po prostu pojedyncze zadanie (w rzeczywistości Dockerized), który obsługuje serwer Postgresql.

1- W jaki sposób można to zorganizować? Wiązać serwer z określonym węzłem klastra? Używasz rozproszonego FS?

2- DRBD, MooseFS, GlusterFS, NFS, CephFS, który z nich dobrze współpracuje z Mesami i usługami typu postgres? (Myślę tutaj o możliwości, że Mesos/maraton może przenieść usługę, jeśli zejdzie)

3- Proszę powiedzieć, czy moje podejście jest błędne pod względem filozofii (DFS dla serwerów danych i pewnego rodzaju przełączanie dla serwerów jak PostgreSQL na górze Mesos)

_{^{Pytanie przeważnie kopiowane z Persistent storage for Apache Mesos, zadane przez zerkms na Programmers Stack Exchange.}}

Answer 1

Doskonałe pytanie. Oto kilka nadchodzących funkcji w Mesos, aby poprawić obsługę usług stanowych i odpowiednie bieżące rozwiązania.

1. Persistent volumes (0,23): Podczas uruchamiania zadania, można utworzyć wolumin, który istnieje poza piaskownicą zadanie i będzie utrzymywać się na węźle nawet po śmierci zadanie/uzupełnia. Po zakończeniu zadania jego zasoby - w tym trwały wolumin - mogą zostać zwrócone do struktury, aby struktura mogła ponownie uruchomić to samo zadanie, uruchomić zadanie odzyskiwania lub uruchomić nowe zadanie, które pochłania poprzedni wynik zadania jako jego wejście.
   • Aktualne obejście: Utrwal swój stan w znanej lokalizacji poza piaskownicą i spróbuj wykonać zadanie ręcznie. Może utrzymywać go w rozproszonym systemie plików/bazie danych, aby można było uzyskać do niego dostęp z dowolnego węzła.
2. DiskIsolation (0.22): Egzekwowanie limitów ilości dyskowych na obszarach izolowanych oraz trwałych woluminów. Gwarantuje to, że struktura pamięci masowej nie będzie w stanie zatykać dysku i uniemożliwić działanie innych zadań.
   • Aktualne obejście: Monitoruj użycie dysku poza pasmem i uruchamiaj okresowe zadania czyszczenia.
3. Dynamic Reservations (0,23): W momencie uruchomienia zadania, które można zarezerwować zasoby twoi zastosowania zadań (w tym trwałych tomów), aby zagwarantować, że są one oferowane do ciebie po wyjściu zadań, zamiast iść do dowolnej ramy jest najdalej poniżej jego sprawiedliwego udziału.
   • Obecne obejście: Użyj flagi slave'a --resources, aby statycznie zarezerwować zasoby dla frameworka po uruchomieniu slave.

Co do konkretnej sprawy i pytania użyć:

1a) Jak można by zorganizować? Możesz to zrobić z Maratonem, być może tworząc oddzielną instancję Maratonu dla twoich usług stanowych, abyś mógł utworzyć rezerwacje statyczne dla roli "stanowej", tak, że tylko stanowy Maraton będzie miał zagwarantowane te zasoby.

1b) Wiązać serwer z określonym węzłem klastra? Możesz to łatwo zrobić w Maratonie, ograniczając aplikację do określonej nazwy hosta lub dowolnego węzła o określonej wartości atrybutu (np. NFS_Access = true). Zobacz Marathon Constraints. Jeśli chcesz tylko uruchomić swoje zadania na określonym zestawie węzłów, wystarczy utworzyć rezerwacje statyczne na tych węzłach. A jeśli potrzebujesz odkryć tych węzłów, powinieneś sprawdzić Mesos-DNS i/lub Marathon's HAProxy integration.

1c) Użyj rozproszonego FS? Replikacja danych dostarczona przez wiele rozproszonych systemów plików gwarantuje, że dane mogą przetrwać awarię dowolnego pojedynczego węzła. Utrzymanie systemu plików DFS zapewniłoby także większą elastyczność w zakresie planowania zadań, ale kosztem różnicy opóźnień między siecią a dyskiem lokalnym. Mesos ma wbudowaną obsługę pobierania plików binarnych z HDFS uris, a wielu klientów używa HDFS do przekazywania binariów executorów, plików konfiguracyjnych i danych wejściowych do urządzeń slave, w których będą uruchamiane ich zadania.

2) DRBD, MooseFS, GlusterFS, NFS, CephFS? Słyszałem o klientach korzystających z CephFS, HDFS i MapRFS z Mesos. NFS również wydaje się łatwe. To naprawdę nie ma znaczenia dla Mesos, czego używasz, o ile twoje zadanie wie, jak uzyskać do niego dostęp z dowolnego węzła, w którym jest umieszczony.

Nadzieję, że pomaga!