System plików rozproszonego przechowywania - Który / Czy jest gotowy do użycia produkt?

Z Hadoop i CouchDB na blogach i pokrewnych wiadomościach, co to właściwie jest rozproszona pamięć (silnik) odporna na awarie.

• CouchDB tak naprawdę nie ma wbudowanych żadnych funkcji dystrybucji, o ile wiem, po prostu brakuje kleju do automatycznej dystrybucji wpisów, a nawet całych baz danych.
• Hadoop wydaje się być bardzo szeroko stosowany - przynajmniej zyskuje dobrą prasę, ale wciąż ma jeden punkt awarii: NameNode. Ponadto można go zamontować tylko za pomocą FUSE, rozumiem, że HDFS nie jest tak naprawdę głównym celem Hadoop
• GlusterFS ma wspólną koncepcję niczego, ale ostatnio przeczytałem kilka postów, które doprowadziły mnie do opinii, że nie jest tak stabilna
• Luster ma również jeden punkt awarii, ponieważ wykorzystuje dedykowany serwer metadanych
• Ceph wydaje się być graczem z wyboru, ale strona główna twierdzi, że wciąż jest w fazie alfa.

Pytanie brzmi, który rozproszony system plików ma następujący zestaw funkcji (bez określonej kolejności):

• Kompatybilny z POSIX
• łatwe dodawanie / usuwanie węzłów
• koncepcja „nic wspólnego”
• działa na tanim sprzęcie (procesory klasy AMD Geode lub VIA Eden)
• wbudowane uwierzytelnianie / autoryzacja
• sieciowy system plików (chciałbym móc montować go jednocześnie na różnych hostach)

Miło jest mieć:

• pliki dostępne lokalnie: mogę zdjąć węzeł z partycji za pomocą standardowego lokalnego systemu plików (ext3 / xfs / cokolwiek ...) i nadal uzyskiwać dostęp do plików

Ja nie szukam aplikacji hostowanych, a raczej coś, co pozwoli mi wziąć powiedzieć 10GB każdy z naszych skrzynek sprzętowych i mają że przechowywanie dostępne w naszej sieci, łatwo montowany na wielu hostach.

Myślę, że będziesz musiał zrezygnować z wymogu POSIX, bardzo niewiele systemów to implementuje - w rzeczywistości nawet NFS tak naprawdę (myśl blokuje itp.) I nie ma nadmiarowości.

Każdy system korzystający z replikacji synchronicznej będzie działał wolno; każdy system, który ma asynchroniczną replikację (lub „ostateczną spójność”) narusza reguły POSIX i nie będzie zachowywał się jak „konwencjonalny” system plików.

Nie mogę rozmawiać z resztą, ale wydaje się, że jesteś zdezorientowany między „silnikiem pamięci rozproszonej” a „rozproszonym systemem plików”. Nie są tym samym, nie należy ich mylić z tym samym i nigdy nie będą tym samym. System plików to sposób na śledzenie położenia rzeczy na dysku twardym. Mechanizm pamięci, taki jak hadoop, jest sposobem na śledzenie fragmentu danych identyfikowanych przez klucz. Pod względem koncepcyjnym niewielka różnica. Problem polega na tym, że system plików jest zależny od silnika pamięci masowej ... w końcu potrzebuje sposobu zapisu na urządzeniu blokowym, prawda?

Poza tym mogę mówić o użyciu ocfs2 jako rozproszonego systemu plików w środowisku produkcyjnym. Jeśli nie chcesz drobnych szczegółów, przestań czytać po tym wierszu: To trochę fajne, ale może oznaczać więcej przestojów, niż myślisz.

Od kilku lat działamy w systemie ocfs2 w środowisku produkcyjnym. Jest OK, ale nie nadaje się do wielu aplikacji. Naprawdę powinieneś spojrzeć na swoje wymagania i dowiedzieć się, jakie one są - może się okazać, że masz dużo więcej swobody na błędy niż się spodziewałeś.

Na przykład ocfs2 ma dziennik dla każdej maszyny w klastrze, która ma zamontować partycję. Powiedzmy, że masz cztery maszyny sieciowe, a kiedy tworzysz tę partycję za pomocą mkfs.ocfs2, określasz, że będzie ich sześć, aby dać sobie trochę miejsca na rozwój. Każdy z tych czasopism zajmuje miejsce, co zmniejsza ilość danych, które można przechowywać na dyskach. Powiedzmy, że musisz skalować do siedmiu maszyn. W tej sytuacji musisz zdjąć całośćklaster (tzn. odmontuj wszystkie partycje ocfs2) i użyj narzędzia tunefs.ocfs2, aby utworzyć dodatkowy dziennik, pod warunkiem, że jest dostępne miejsce. Wtedy i tylko wtedy możesz dodać siódmą maszynę do klastra (co wymaga dystrybucji pliku tekstowego do reszty klastra, chyba że używasz narzędzia), przywróć wszystko, a następnie zamontuj partycję na wszystkich siedmiu maszyny

Widzisz co mam na myśli? Ma to być wysoka dostępność, co powinno oznaczać „zawsze online”, ale właśnie tam masz mnóstwo przestojów ... i niech Bóg cię zatłoczony dla miejsca na dysku. Nie chcesz zobaczyć, co się stanie, gdy zatłoczysz się o ocfs2.

Należy pamiętać, że evms, który był kiedyś „preferowanym” sposobem zarządzania klastrami ocfs2, przeszedł drogę ptakowi dodo na korzyść clvmd i lvm2. (I dobra wściekłość na evms.) Również bicie serca szybko zamieni się w projekt zombie na korzyść stosu openais / rozrusznika serca. (Poza tym: Podczas wykonywania początkowej konfiguracji klastra dla ocfs2 możesz określić „pcmk” jako silnik klastra zamiast bicia serca. Nie, nie jest to udokumentowane.)

Za to, co jest warte, wróciliśmy do NFS zarządzanych przez rozrusznik serca, ponieważ kilka sekund przestoju lub kilka upuszczonych pakietów Tcp, gdy pacemaker migruje udział NFS na inną maszynę, jest trywialny w porównaniu do ilości przestojów, które widzieliśmy dla podstawowego współużytkowane operacje przechowywania, takie jak dodawanie komputerów podczas korzystania z ocfs2.

Być może nie rozumiem twoich wymagań, ale czy spojrzałeś na http://en.wikipedia.org/wiki/List_of_file_systems#Distribut_file_systems

Żeby wrzucić tutaj moje 0,02 €: czy OpenAFS nie może robić tego, co chcesz?

Spójrz na ćwierkają http://www.cse.nd.edu/~ccl/software/chirp/ i papugi http://www.cse.nd.edu/~ccl/software/parrot/

Co powiesz na Xtreemfs ? wersja 1.4 (listopad 2012 r.) jest uważana za Jakość produkcji.

Jest kompatybilny z POSIX i ma wyjątkową automatyczną odporność na uszkodzenia.

Luster pozwala na przechowywanie wielu metadanych w konfiguracji aktywnej / pasywnej w celu zapewnienia redundancji, więc nie ma pojedynczego punktu awarii.

Warto również przyjrzeć się OCFS2.

Należy pamiętać, że wyeliminowanie wymogu jednoczesnego dostępu do wielu sieci umożliwia przełączenie na coś takiego jak iSCSI, a nawet cifs lub nfs. Minusem jest to, że musisz „wykroić” kawałki swojego uberArray w kęsy dla każdego serwera, który potrzebuje miejsca.

O ile nie jest to do celów akademickich / rozwojowych, do tego rodzaju rzeczy należy podchodzić od ogólnych wymagań dotyczących projektu. Większość rozproszonych systemów plików nie jest wystarczająco dojrzała do poważnego wdrożenia - na przykład, co robisz, jeśli całość się powiedzie. Jeśli jest to do celów akademickich / rozwojowych, to jest to naprawdę dobra rzecz, ponieważ możesz się wiele nauczyć i naprawić wiele błędów.

Komentarz kwestionujący, czy naprawdę potrzebujesz semantyki POSIX, jest dobrym początkiem. Semantyka systemu plików innego niż POSIX może być o wiele bardziej elastyczna, co prowadzi do znacznie bardziej niezawodnych systemów.

Jeśli jest to starsza aplikacja, naprawdę zastanawiam się, dlaczego nowoczesny rozproszony system plików można uznać za najlepsze rozwiązanie.

Nie zrozum mnie źle - to niezwykle zabawne zabawki. Po prostu nie chciałbym być odpowiedzialny za złożone, współzależne rozwiązanie, które nie jest powszechnie stosowane i byłoby bardzo trudne do naprawienia, gdy się rozwinie.

Czy naprawdę, absolutnie pozytywnie potrzebujesz semantyki POSIX? Życie staje się znacznie łatwiejsze, jeśli możesz użyć niestandardowego magazynu danych. Mamy wewnętrznie zapisany magazyn danych, który jest w rzeczywistości bardzo dużym rozproszonym magazynem kluczy i wartości. Przechowujesz w nim plik i odzyskujesz token. Jeśli chcesz odzyskać plik, podaj mu token, który otrzymałeś wcześniej. Jest rozproszony, nie jest udostępniany, dane są replikowane trzykrotnie, węzły można dowolnie dodawać i usuwać, zarówno serwery pamięci, jak i serwery sterujące.

Luster ma również jeden punkt awarii, ponieważ wykorzystuje dedykowany serwer metadanych

Luster jest zaprojektowany do obsługi przełączania awaryjnego, a MDS / MDT / OSS może mieć wiele adresów, z którymi można się skontaktować, a pulsu można użyć do migracji usługi.

Należy pamiętać, że niektóre najnowsze wersje miały problemy, w których odmontowywanie wydaje się działać, ale nadal istnieją dane w locie na dysk, jednak ochrona podwójnego montażu powinna była pomóc (oprócz interesujących problemów, które miały) ...

Polecam używać MooseFS (odporny na awarie, skalowanie w górę, rozproszony system plików w sieci). Jest zgodny z POSIX, a od wersji 1.6 MooseFS oferuje proste uwierzytelnianie / autoryzację podobne do NFS. Zobacz także wymagania sprzętowe .