Co dokładnie robi Gluster?

Bawię się glusterem przez ostatnie 2 dni i zadaję pytania tutaj oraz w ich systemie pytań. Naprawdę nie rozumiem niektórych rzeczy. Widzę ludzi mówiących takie rzeczy

Skonfiguruj replikowane klocki między serwerami (ponieważ używasz tylko 3, replikacja byłaby bezpieczniejsza), a każdy serwer będzie widział pliki wszystkich innych serwerów jako „lokalne” - nawet jeśli jeden serwer ulegnie awarii, pliki zostały zreplikowane na inne serwery.

lub

Gluster zachowa synchronizację plików między woluminami (cegłami) i ma możliwości „samonaprawiania”, które poradzą sobie z wszelkimi niespójnościami wynikającymi z tego, że jeden serwer jest offline.

Ponieważ ja zamontować zdalny wolumin z serwera do klienta (e) w jaki sposób brak uchwytu gluster węzła serwera, jeden tomy montowane są z? Z tego, co próbowałem, folder na kliencie, na którym zamontowano wolumin, staje się niedostępny i muszę go użyć do odblokowania umount. A potem nie ma treści z serwera.

Jest to w zasadzie to, czego nie widzę ujęte w żadnych wyjaśnieniach: co dzieje się, gdy węzeł serwera ulega awarii i czy rzeczywiście można replikować zawartość, tak jak robi to unison lub rsync?

Niedawno rozpoczęliśmy badania GlusterFS na własny użytek, więc to pytanie było dla mnie interesujące. Gluster używa tak zwanych „tłumaczy” na kliencie FUSE do obsługi sposobu przechowywania danych. Istnieje kilka rodzajów tłumaczy, które zostały tu przedstawione:

http://www.gluster.com/community/documentation/index.php/GlusterFS_Translators_v1.3

Ten, o który konkretnie pytasz, nazywa się Automatycznym tłumaczeniem replikacji plików lub AFR i jest szczegółowo opisany tutaj:

http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator

Patrząc na kod źródłowy, wydaje się, że dane są faktycznie zapisywane jednocześnie do węzłów, znacznie lepiej niż rsync!

Jeśli chodzi o naprawę po awarii, znalazłem jedną ciekawą notatkę. System Gluster różni się od Ceph tym, że nie jest aktywnie świadomy zmian stanu replikacji i musi zostać „wyzwolony”. Więc jeśli stracisz węzeł w klastrze, musisz wyszukać każdy plik, aby Gluster upewnił się, że jest on replikowany:

http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

Nie udało mi się znaleźć dobrej strony opisującej mechanizmy scenariusza awarii, na przykład sposobu, w jaki klient wykrywa problemy. Jednak po pobraniu kodu źródłowego i przejrzeniu klienta wydaje się, że istnieją różne limity czasu używane przez niego do poleceń i sonda, które tak często robią w przypadku innych systemów w klastrze. Wygląda na to, że większość z nich ma znaki DO ZROBIENIA i nie można ich obecnie konfigurować, chyba że poprzez modyfikację kodu źródłowego, co może być dla ciebie problemem, jeśli czas zbieżności ma kluczowe znaczenie.

Przy replikacji zaledwie 2 węzłów gluster nie różni się niczym od automatycznego skryptu rsync. Rzeczy naprawdę zaczynają być interesujące dopiero, gdy masz 4 lub więcej węzłów pamięci - twoje komputery klienckie widzą pulę miejsca, ale pliki składowe są rozłożone na wszystkie węzły pamięci (cegły). Oznacza to, że jeśli twoje 4 serwery mają 10 TB przestrzeni lokalnej, twoje komputery klienckie mogą zobaczyć pojedynczą przestrzeń nazw o wielkości 20 TB (zreplikowana lub 40 TB niechronionej pamięci).

Widziałem krótką czkawkę - może około 30 sekund - na komputerze klienckim, gdy próbuje IO po tym, jak cegła pamięci staje się niedostępna. Jednak po czkawce operacje we / wy będą kontynuowane normalnie, dopóki będą dostępne serwery online, które nadal przechowują pełny zestaw danych woluminu.

Opisujesz nieoczekiwane zachowanie - skonsultuję się z #gluster na irc.freenode.net lub gluster-users@gluster.org lub http://community.gluster.org/

-John Mark Gluster Community Guy

Gdy serwer naprzeciwko klienta zawiedzie (tj. Serwer, którego IP / DNS został użyty przez klienta do zamontowania systemu plików), wówczas cały wolumin przechodzi w tryb offline dla tego klienta, tzn. Nie może czytać / zapisywać na woluminie.

Jeśli jednak klient zamontował go za pomocą adresu IP / DNS innego serwera, wolumin nadal będzie dostępny dla tego klienta. Jednak odczyt / zapis nie przejdzie do nieudanej / zawieszonej instancji.