Czy dobrym pomysłem jest przechowywanie woluminów Docker w glusterfs?

Obecnie myślę o migracji niektórych naszych serwerów i aplikacji do środowiska coreOS . Jednym z problemów, które tu widzę, jest zarządzanie trwałymi danymi, ponieważ coreOS nie obsługuje woluminów Docker podczas przenoszenia kontenera na nową maszynę. Po kilku badaniach znalazłem glusterFS, który twierdzi, że jest systemem plików klastrowych, który mógłby rozwiązać wszystkie moje problemy.

Mój obecny pomysł jest następujący: mam kontener glusterFS, który działa jako uprzywilejowany kontener na każdym z moich komputerów coreOS i udostępnia /mnt/glusterna przykład pamięć . W moich Dockerfiles określam, że wszystkie moje woluminy powinny być zamontowane na tej ścieżce.

Następną rzeczą, którą rozważałem, było to, które kontenery powinny otrzymać własne woluminy, a które powinny udostępniać jeden. Na przykład każdy mysqlkontener otrzymałby własny wolumin, ponieważ jest w stanie samodzielnie obsłużyć replikację. Nie chcę się tym bawić. Serwery WWW obsługujące tę samą witrynę prawidłowo wykorzystałyby ten sam wolumin do takich rzeczy, jak „obrazy przesłane przez użytkownika” itp., Ponieważ nie są w stanie powielić tych danych.

Czy ktoś próbował czegoś takiego lub jest coś, za czym tęskniłem?

— Jaskółka oknówka
źródło

Zrobiłem z tym dowód koncepcji i mogę powiedzieć, że to działa, ale zanim przejdziesz do Glustera, upewnij się, że rozumiesz jego profil strojenia. Ze względu na to, że Gluster jest wrażliwy na opóźnienie dysku (podobny do etcd), może sztucznie spowalniać aplikacje w imię gwarancji replikacji plików.

— Brian Redbeard

Pracujemy nad narzędziem, które zarządza woluminami dołączonymi do kontenerów dokerów. Nazywa się to „flocker”, a repozytorium github można zobaczyć tutaj: github.com/clusterhq/flocker Obecnie mamy zaplecze pamięci dla ZFS, które korzysta z funkcji migawki, aby znacznie ułatwić migrację danych, ale mamy też plany dotyczące innych backendów pamięci (np. ogólny backend urządzenia blokowego) Nie mogę powiedzieć, czy dobrym pomysłem jest montowanie woluminów dokerów za pomocą GlusterFS, ale mogę ręczyć za ogólny wzorzec projektowy - tj. uwzględnić stan wygenerowany przez kontener dokerów za pomocą „czegoś”

— Bino Carlos

Dzięki za odpowiedź. Widziałem już flokera i wygląda to bardzo obiecująco. Czy masz trudną datę wsparcia dla Coreos lub wersję 1.0 gotową do produkcji?

— Martin

Użyłem glusterfs dla woluminów z OpenStack, przed którym ma podobną konfigurację do tego, co robisz i działało świetnie.

— Ethode

@Martin My (i pracuję w ClusterHQ) Flocker pracuje nad CoreOS przy użyciu Amazon EBS. coreos.com/blog/Flocker-on-CoreOS-Linux

— Stephen Nguyen

Odpowiedzi:

Wdrożyliśmy podobną konfigurację z Atomic ( http://www.projectatomic.io/ ) zamiast CoreOS w zreplikowanym nie dystrybuowanym systemie pamięci masowej GlusterFS z trzema zestawami repliki-2. To działa bardzo dobrze.

Musisz jednak pamiętać o kilku szczególnych cechach GlusterFS. Jak już wspomniano Brian, Gluster kładzie nacisk przede wszystkim na spójność i niezawodność. Im częstsze zmiany, tym więcej replikacji. To dużo, i mam na myśli DUŻO, presji na twój system.

Uważaj, aby twój podsystem IO był szybki (duh, jest to pamięć masowa), połącz węzły Gluster z najszybszymi dostępnymi połączeniami sieciowymi. Jeśli masz tylko GBit, agreguj! Wreszcie system pamięci masowej musi mieć dużą moc obliczeniową. Gluster wykonuje wiele obliczeń, aby sprawdzić swój stan. Biorąc to pod uwagę, nawet przy dużym obciążeniu Gluster zapewnia.

Ponownie rozważ swoją strategię MySQL. Gluster wykonuje replikację za Ciebie, a także zapewnia rodzaj równoważenia obciążenia w dostawie. Korzystanie z Glustera może być szybsze.

— Bjanssen
źródło

Użycie glusterfs zależy od używanego backendu pamięci. Jako klastrowy system plików przeznaczony jest do klastrowania fizycznej pamięci masowej, aby wyglądał jak jeden duży ciągły wolumin. Ten oficjalny przewodnik szybkiego startu zawiera dobre wyjaśnienie tego procesu.

W przypadku, gdy twoja konfiguracja wykorzystuje dwa lub więcej oddzielnych serwerów pamięci wewnętrznej lub coś podobnego do przechowywania wszystkich woluminów dokera, wówczas użycie glusterfs lub innego podobnego równoległego systemu plików może zaoferować znaczące korzyści w zakresie wydajności. W takim przypadku można również rozważyć użycie Lustera , który jest powszechnie używany jako równoległy system plików w społeczności HPC.

Biorąc to pod uwagę, dostrajanie, debugowanie i konfigurowanie równoległych / klastrowych systemów plików może być czasochłonnym zadaniem, które wymaga dużej wiedzy, cierpliwości i czasami chęci ponownego uruchomienia od samego początku. Rozsądnie byłoby upewnić się, że korzyści płynące z wydajności równoległego systemu plików są warte wysiłku wymaganego do jego skonfigurowania i utrzymania.

— Matt
źródło