Dwukierunkowa synchronizacja w czasie rzeczywistym dużego drzewa plików między dwoma odległymi serwerami Linux


21

Przez duże drzewo plików mam na myśli około 200 000 plików i cały czas rośnie. Jednak stosunkowo niewielka liczba plików jest zmieniana w każdej godzinie.

Przez dwukierunkowy rozumiem, że zmiany mogą wystąpić na jednym serwerze i muszą zostać przesunięte na drugi, więc rsync nie wydaje się odpowiedni.

Przez odległe rozumiem, że oba serwery są w centrach danych, ale geograficznie oddalone od siebie. Obecnie są tylko 2 serwery, ale z czasem mogą się one rozszerzać.

W czasie rzeczywistym jest ok, ponieważ istnieje niewielkie opóźnienie między synchronizacją, ale uruchamianie crona co 1-2 minuty nie wydaje się właściwe, ponieważ bardzo mała część plików może się zmieniać w dowolnej godzinie, a co dopiero w minutach.

EDYCJA : Działa na VPS, więc mogę być ograniczony rodzajami rzeczy na poziomie jądra, które mogę zrobić. Ponadto VPS nie są bogate w zasoby, więc unikałbym rozwiązań wymagających dużej ilości pamięci RAM (takich jak Gluster?).

Jakie jest najlepsze / najbardziej „akceptowane” podejście, aby to zrobić? Wydaje się, że byłaby to powszechna potrzeba, ale nie byłem jeszcze w stanie znaleźć ogólnie przyjętego podejścia, co było zaskakujące. (Szukam bezpieczeństwa mas.)

Natknąłem się na lsyncd, aby uruchomić synchronizację na poziomie zmiany systemu plików. To wydaje się sprytne, choć nie bardzo powszechne, i jestem trochę zdezorientowany różnymi podejściami lsyncd. Po prostu używa się lsyncd z rsync, ale wydaje się, że może to być niestabilne dla dwukierunkowości, ponieważ rsync nie ma pojęcia pamięci (np. Aby wiedzieć, czy usunięty plik na A powinien zostać usunięty na B, czy też jest to nowy plik na B które należy skopiować do A). LipSync wydaje się być tylko lsyncd + rsync realizacja, prawda?

Potem jest użycie lsyncd z csync2 , na przykład: https://icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ... Skłaniam się ku temu podejściu, ale csync2 jest trochę dziwaczny, chociaż przeprowadziłem udany test. Obawiam się przede wszystkim, że nie udało mi się znaleźć wielu potwierdzeń społeczności dotyczących tej metody.

Ludzie tutaj wydają się bardzo lubić Unison, ale wygląda na to, że nie jest już aktywnie rozwijany i nie jest jasne, że ma automatyczny wyzwalacz, taki jak lsyncd.

Widziałem Glustera , ale może przesadziłem z tym, czego potrzebuję?

AKTUALIZACJA: fyi- skończyłem na oryginalnym rozwiązaniu, o którym wspomniałem: lsyncd + csync2. Wydaje się, że działa całkiem dobrze i podoba mi się podejście architektoniczne polegające na tym, że serwery są bardzo luźno połączone, dzięki czemu każdy serwer może działać w nieskończoność samodzielnie, niezależnie od jakości łącza między nimi.


Jakie zmiany musisz obsłużyć? Tworzenie, usuwanie, modyfikacja EG.
sciurus

Czy spodziewasz się również konfliktów? Czy ten sam plik można zmodyfikować na obu serwerach?
sciurus

Wszystkie zmiany: tworzenie, usuwanie, modyfikacja. Możliwe są konflikty, ale powinny być rzadkie. Nie miałbym nic przeciwko, jeśli po prostu otrzymam powiadomienie o konflikcie, które muszę rozwiązać ręcznie.
dlo

Odpowiedzi:


5

Opcja DRBD w trybie Dual-Primary z serwerem proxy jest opcją.


Serwer proxy nie wydaje się być ani oprogramowaniem typu open source, ani wolnym, prawda? Nie jestem pewien, czy rozumiem konsekwencje braku posiadania serwera proxy w trybie asynchronicznym: w przypadku dłuższego przestoju, jeśli nie ma serwera proxy, bufor wyjściowy [mały?] Może się zapełnić i stracimy synchronizację? Czy trudno jest z tego wyjść?
dlo

Zobacz moją odpowiedź powyżej. Nie sądzę, że proxy jest tym, czego potrzebujesz. Nawet podczas krótkiego przestoju drbd-meta-urządzenie oznaczy „brudne” bloki i prześle je po ponownym nawiązaniu połączenia. Myślę, że główna różnica między trybem proxy a trybem asynchronicznym polega na tym, że tryb asynchroniczny wykorzystuje maksymalny bufor niektórych MB. Następnie synchronizuje się przed ponownym zapełnieniem bufora. Serwer proxy prawdopodobnie pozwala na większy bufor (potrzebny, jeśli masz duże opóźnienia lub możesz pisać znacznie szybciej lokalnie niż zdalnie).
Nils

2

Zamiast synchronizować, dlaczego nie udostępniać tego samego systemu plików przez NFS?


2
NFS jest okropny, po prostu okropny. Wszystko byłoby lepsze niż NFS
AliGibbs,

2
Jednym z głównych punktów konfiguracji wieloserwerowej jest przełączanie awaryjne / redundancja. Tak więc jeden serwer musi być w stanie kontynuować bez drugiego.
dlo

Powinieneś był o tym wspomnieć w swoim pytaniu - nie musisz głosować całkowicie rozsądną odpowiedź!
Bart B

fyi nie głosowałem za tym - ktoś inny. Ale tak, powinienem o tym wspomnieć na początek.
dlo

@Bart: Cóż - wspomniał, że istnieje dostęp do dwóch odległych stron. Tak więc nawet jeśli wprowadzisz HA-NFS, byłoby to złe rozwiązanie, ponieważ jedna strona cierpiałaby na opóźnienia podczas dostępu do NFS. I też nie głosowałem za tym. Ale jestem administratorem NFS wystarczająco długo, aby obsługiwać AliGibbs. : - /
Nils

2

Wdrożenie rozproszonego systemu plików jest prawdopodobnie lepsze niż zhakowanie go razem z narzędziami i skryptami, zwłaszcza jeśli klaster serwerów się powiększy. Będziesz także mógł lepiej obsługiwać powalony węzeł.

Nie sądzę, żeby Gluster (lub AFS) w ogóle był przesadny.


Gluster wymaga 1 GB pamięci RAM? gluster.com/community/documentation/index.php/… ... Jestem także na VPS, więc nie jestem pewien, czy wprowadzę zmiany na poziomie jądra, których może wymagać AFS. Ale zaczynam dostrzegać, że poprawna dystrybucja fs jest lepszą ścieżką.
dlo

Tak, przepraszam, że wcześniej nie złapałem, że używasz hostów VPS. Ślady pamięci Gluster, zarówno serwera, jak i klienta, nie są małe i mogą znacznie wzrosnąć. DRBD wydaje się bardziej odpowiednie.

AFS jest właściwą drogą.
Anthony Giorgio,

2

W twoim przypadku poleciłbym kombinację DRBD w trybie dual-primary i gfs lub ocfs.

Wadą DRBD w dual-pierwotnym jest to, że będzie działał w trybie synchronicznym. Ale szybkość zapisu nie wydaje się tutaj ważna, prawda?

Alternatywą dla DRBD może być Soft-Raid1 wykorzystujący wiele (2+) celów iSCSI - ale wolałbym DRBD z dwoma węzłami.


1
Tryb synchroniczny byłby zły - nie potrzebuję go i nie chciałbym obniżać wydajności, ponieważ serwery są połączone przez sieć WAN na różnych kontynentach. Ale czy nie możesz mieć dual-primary w trybie asynchronicznym?
dlo

Obecnie używam DRBD 8.3.5 - tam musisz być w trybie synchronizacji („C”), aby przejść do podwójnego trybu podstawowego. Nie mam osobistych doświadczeń z proxy DRBD, ale wydaje się, że jest podobny do Veritas Volume Replicator - ale prawdopodobnie nie jest to odpowiednie, ponieważ chcesz mieć dostęp do zapisu po obu stronach. Tryb synchronizacji na poziomie bloku może nie być tak zły, jak myślisz - być może gfs i / lub ocfs mogą buforować zapisy.
Nils,

Właśnie sprawdziłem niemiecki artykuł porównujący GFS2 i OCFS2. Z tego co najmniej OCFS2 wydaje się obsługiwać buforowany dostęp do systemu plików. W tym artykule zalecany jest GFS2, ponieważ jest starszy. Zobacz dokumentację RedHat na temat GFS2, aby uzyskać szczegółowe informacje na temat GFS2 - używa on również buforowania - ale powinieneś użyć różnych katalogów dla równoczesnych zapisów, aby uzyskać najlepszą wydajność.
Nils,

0

Jak wykazano powyżej, dostępnych jest wiele rozwiązań, z których każde ma swoje zalety i wady.

Myślę, że rozważyłbym poddanie całego drzewa kontroli wersji ( na przykład Subversion ) i okresowe sprawdzanie / aktualizowanie z obu serwerów w zadaniach cron.


0

Właśnie skończyłem trochę poszukiwania tego samego, idę z niechęcią. Jednak nie wykonałem ani nie znalazłem żadnych testów wydajności.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.