Mamy klaster GlusterFS, którego używamy do naszej funkcji przetwarzania. Chcemy zintegrować z nim system Windows, ale mamy problemy z ustaleniem, jak uniknąć pojedynczego punktu awarii, jakim jest serwer Samba obsługujący wolumin GlusterFS.
Nasz przepływ plików działa w następujący sposób:
- Pliki są odczytywane przez węzeł przetwarzania systemu Linux.
- Pliki są przetwarzane.
- Wyniki (mogą być małe, mogą być dość duże) są zapisywane z powrotem do woluminu GlusterFS po ich zakończeniu.
- Wyniki można zamiast tego zapisać do bazy danych lub zawierać kilka plików o różnych rozmiarach.
- Węzeł przetwarzania odbiera inne zadanie z kolejki i GOTO 1.
Gluster jest świetny, ponieważ zapewnia wolumin rozproszony, a także natychmiastową replikację. Odporność na katastrofy jest miła! Lubimy to.
Ponieważ jednak system Windows nie ma rodzimego klienta GlusterFS, potrzebujemy jakiegoś sposobu, aby nasze oparte na systemie Windows węzły przetwarzania współpracowały z magazynem plików w podobny sposób odporny. Dokumentacja GlusterFS stwierdza, że sposobem na zapewnienie dostępu do systemu Windows jest skonfigurowanie serwera Samba na zamontowanym woluminie GlusterFS. Doprowadziłoby to do takiego przepływu plików:
Dla mnie to wygląda na jeden punkt awarii.
Jedną z opcji jest klastrowanie Samby , ale wydaje się, że jest ona oparta na niestabilnym kodzie w tej chwili i dlatego nie działa.
Więc szukam innej metody.
Niektóre kluczowe szczegóły dotyczące rodzajów danych, które przekazujemy:
- Oryginalne rozmiary plików mogą wynosić od kilku KB do kilkudziesięciu GB.
- Przetwarzane rozmiary plików mogą wynosić od kilku KB do GB lub dwóch.
- Niektóre procesy, takie jak wczytywanie pliku archiwum, takiego jak .zip lub .tar, mogą powodować DUŻO dalszych zapisów, gdy zawarte pliki są importowane do magazynu plików.
- Liczba plików może dostać się do dziesiątków milionów.
To obciążenie nie działa z konfiguracją Hadoop „statycznego rozmiaru jednostki roboczej”. Podobnie oceniliśmy magazyny obiektów w stylu S3, ale okazało się, że ich brakuje.
Nasza aplikacja napisana jest w języku Ruby na zamówienie i mamy środowisko Cygwin w węzłach Windows. To może nam pomóc.
Jedną z rozważanych przeze mnie opcji jest prosta usługa HTTP na klastrze serwerów, na których zamontowano wolumin GlusterFS. Ponieważ wszystko, co robimy z Glusterem, to zasadniczo operacje GET / PUT, wydaje się, że można je łatwo przenieść na metodę przesyłania plików opartą na HTTP. Umieść je za parą loadbalancer, a węzły Windows mogą HTTP PUT do zawartości ich małego niebieskiego serca.
Nie wiem, w jaki sposób utrzymywana byłaby spójność GlusterFS . Warstwa proxy HTTP wprowadza wystarczające opóźnienie między momentem, w którym węzeł przetwarzający zgłasza, że jest to zrobione z zapisem, a faktycznym widocznością na woluminie GlusterFS, że obawiam się, że późniejsze etapy przetwarzania, które będą próbowały pobrać plik, Znajdź to. Jestem prawie pewien, że skorzystanie z direct-io-mode=enableopcji mount pomoże, ale nie jestem pewien, czy to wystarczy . Co jeszcze powinienem zrobić, aby poprawić spójność?
A może powinienem stosować zupełnie inną metodę?
Jak zauważył Tom poniżej, NFS to kolejna opcja. Więc przeprowadziłem test. Ponieważ wyżej wymienione pliki mają nazwy dostarczone przez klienta, które musimy zachować i mogą występować w dowolnym języku, musimy zachować nazwy plików. Więc zbudowałem katalog z tymi plikami:
Kiedy montuję go z systemu Server 2008 R2 z zainstalowanym klientem NFS, pojawia się następujący katalog katalogów:
Najwyraźniej Unicode nie jest zachowywany. Więc NFS nie będzie dla mnie działać.
ctdbstabilny i gotowy do użytku produkcyjnego, a pierwsze zdanie w podanym linku powoduje, że drugie zdanie jest nieprawidłowe, ponieważ nigdy nie zostało zaktualizowane. Planowałem to ustalić, ale zanim do tego doszedłem, zmieniłem zadania na środowisko prawie wolne od okien.