Geograficznie rozproszony system plików z preferowaną lokalizacją

Tworzę aplikację, która musi rozpowszechniać standardowy serwer plików w kilku witrynach za pośrednictwem sieci WAN. Zasadniczo każda witryna musi napisać wiele różnych plików o różnych rozmiarach (niektóre w zakresie 100 MB, ale najbardziej małe), a aplikacja jest napisana w taki sposób, aby kolizje nie stanowiły problemu. Chciałbym skonfigurować system spełniający następujące kwalifikacje:

1. Każda witryna może przechowywać pliki we wspólnej „przestrzeni nazw”. Oznacza to, że wszystkie pliki byłyby wyświetlane w tym samym systemie plików.
2. Każda witryna nie wysyła danych przez sieć WAN, chyba że jest to konieczne. Tzn. Po każdej stronie sieci WAN byłaby pamięć lokalna, która byłaby „scalona” w ten sam logiczny system plików.
3. Linux i bezpłatny ($$$) to plus

Zasadniczo coś w rodzaju centralnego udziału NFS spełniłoby większość wymagań, jednak nie pozwoliłoby, aby lokalnie zapisane dane pozostały lokalne. Wszystkie dane ze zdalnych stron sieci WAN byłyby cały czas kopiowane lokalnie.

Zajrzałem do Lustera i przeprowadziłem z nim kilka udanych testów, jednak wydaje się, że dystrybucja plików jest dość jednolita w całej rozproszonej pamięci. Przejrzałem dokumentację i nie znalazłem niczego, co automatycznie „wolałoby” lokalną pamięć masową niż zdalną. Nawet coś, co poszło z najmniejszym opóźnieniem, byłoby w porządku. To działałoby przez większość czasu, co spełniałoby wymagania tej aplikacji.

Niektóre odpowiedzi na niektóre pytania zadane poniżej:

• Węzły serwera: 2 lub 3, aby rozpocząć. Każdy serwer miałby dziesiątki jednoczesnych klientów do odczytu / zapisu.
• Topologia WAN jest pełna i niezawodna. (duża korporacja, koszt nie jest tak ograniczający jak biurokracja)
• Przełączanie awaryjne klienta: Właściwie nie myślałem o przełączeniu awaryjnym klientów (głównie dlatego, że nasza obecna aplikacja nie robi tego tylko w jednej witrynie). Podejrzewam, że praktyczną odpowiedzią jest to, że serwery w każdej geograficznie rozproszonej lokalizacji powinny stanowić pojedyncze punkty awarii dla obsługiwanych klientów. Chociaż, jeśli zastanawiasz się nad czymś konkretnym, myślę, że byłoby to dość istotne dla dyskusji.
• Roll-my-own: Myślałem o rsync / unison, ale potrzebowałbym trochę wymyślnej logiki, aby „dynamiczna” część tego dzieła działała płynnie. To znaczy, plik wydaje się być lokalny, ale jest pobierany tylko na żądanie.
• MS-DFS: Z pewnością wydaje się, że powinienem przyjrzeć się temu. Moim głównym problemem może być niepewność co do konfiguracji / niezawodności / wydajności serwera NFS w systemie Windows, ponieważ wielu klientów łączących się to klienci NFS.

Wstyd o wymaganiach dotyczących Linuksa. To właśnie robi Windows DFS. Od 2003 R2 robi to również na poziomie bloków.

Parę pytań:

• Ile węzłów „serwerowych” myślisz o uczestnictwie w tej rzeczy?

• Jak wygląda topologia łączności WAN - hub and mówił, pełna siatka? Jaka jest niezawodność?

• Czy oczekujesz, że klienci przejdą w tryb failover na geograficznie nielokalny serwer w przypadku awarii serwera lokalnego?

System Windows DFS-R z pewnością byłby tym, czego szukasz, choć wiąże się to z potencjalnie dużymi kosztami licencjonowania.

Mówisz, że kolizje nie stanowią problemu i nie potrzebujesz rozproszonego menedżera blokady, więc możesz to zrobić za pomocą narzędzi użytkownika, takich jak rsync lub Unison, i po prostu wyeksportować wynikowy plik z NFS do lokalnych klientów. Jest to brzydkie i musiałbyś poradzić sobie ze zbijaniem jakiegoś systemu, który poradziłby sobie z generowaniem topologii replikacji i uruchamianiem narzędzi przestrzeni użytkownika, ale z pewnością byłby tani w miarę wzrostu kosztów licencji.

Czy rozważałeś AFS ?

Andrew File System (AFS) to rozproszony sieciowy system plików, który wykorzystuje zestaw zaufanych serwerów do prezentacji jednolitej przestrzeni nazw plików przezroczystej dla wszystkich stacji roboczych.

Jak rozumiem, większość ostatnich prac rozwojowych stała za projektem OpenAFS .

Nie mogę udawać, że jestem na tyle zaznajomiony z projektem, aby wiedzieć, czy dostępna jest funkcja „preferowanej lokalizacji”, ale poza tym brzmi to jak dobre dopasowanie.

Czy oglądałeś baseny OST w Luster?

Nie będzie to automatyczne, ale dzięki pulom OST możesz przypisywać katalogi / pliki do określonych OST / OSS - zasadniczo alokacja pamięci oparta na zasadach, zamiast domyślnego round-robin / striping w OST.

Możesz więc skonfigurować katalog dla każdej witryny i przypisać ten katalog do lokalnych OST dla tej witryny, co przekieruje wszystkie operacje we / wy do lokalnych OST. Nadal będzie to globalna przestrzeń nazw.

Wiele pracy wymaga poprawienia Lustera w stosunku do połączeń WAN (lokalne serwery buforujące itp.), Ale wszystko to wciąż jest w fazie intensywnego rozwoju AFAIK.

Może NFS, ale z Cachefs na serwerach aplikacji osiągną twoją część twojego celu. Rozumiem, że wszystko, co napisano, nadal trafi na serwer centralny, ale przynajmniej odczyty mogą zostać buforowane lokalnie. Może to potencjalnie znacznie opóźnić odczyt w zależności od wzorców użytkowania.

Warto też przyjrzeć się mabye UnionFS. W związku z tym myślę, że każda lokalizacja byłaby eksportem NFS, a następnie można użyć UnionFS w każdej lokalizacji, aby to i wszystkie inne podłączenia NFS z tej lokalizacji były wyświetlane jako jeden system plików. Nie mam z tym jednak doświadczenia.

Możesz zajrzeć do DRBD w celu zreplikowania dysków. http://www.drbd.org/ . Jest to linuksowe rozwiązanie wysokiej dostępności, które właśnie znalazło się w jądrze.

Ma to jednak pewne ograniczenia:

1. Można skonfigurować tylko dwa węzły
2. Sieć WAN może być zbyt zawodna, aby zapewnić niezawodność DRBD.

Jeśli chcesz to uprościć, spójrz na rsync, rozwiązuje wiele problemów i może być skryptowany.

Sprawdź chironfs .

Może może zrobić to, co chcesz, na podstawie systemu plików.

Btsync to kolejne rozwiązanie, z którym miałem dobre doświadczenia. Używa protokołu BitTorrent do przesyłania plików, więc im więcej masz serwerów, tym szybciej synchronizujesz nowe pliki.

W przeciwieństwie do rozwiązania opartego na rsync, wykrywa kiedy zmieniasz nazwy plików / folderów i zmienia ich nazwy na wszystkich węzłach zamiast usuwania / kopiowania.

Twoi klienci btsync mogą następnie udostępniać foldery w sieci lokalnej.

Jedynym minusem, który znalazłem (w porównaniu do MS DFS) jest to, że nie wykryje lokalnej kopii pliku. Zamiast tego zinterpretuje go jako nowy plik przesłany do wszystkich peerów.

Do tej pory btsync wydaje się być najlepszym rozwiązaniem do synchronizacji i można go zainstalować na urządzeniach z Windows, Linux, Android i ARM (np. NAS)