Jaki protokół udostępniania plików w sieci ma najlepszą wydajność i niezawodność? [Zamknięte]

Mamy konfigurację z kilkoma serwerami WWW równoważonymi obciążeniem. Chcemy mieć jakąś współdzieloną pamięć sieciową, do której dostęp mogą mieć wszystkie serwery sieciowe. Będzie używany jako miejsce do przechowywania plików przesłanych przez użytkowników. Wszystko działa pod Linuksem.

Czy powinniśmy używać NFS, CIFS, SMB, bezpiecznika + sftp, bezpiecznika + ftp? Istnieje wiele opcji protokołów sieciowego udostępniania plików, więc bardzo trudno jest wybrać jeden. Zasadniczo chcemy po prostu trwale zamontować ten jeden udział na wielu komputerach. Funkcje bezpieczeństwa są mniej ważne, ponieważ nie będą dostępne w sieci z dowolnego miejsca innego niż serwery, które to instalują. Chcemy tylko, aby działał niezawodnie i szybko.

Z którego powinniśmy skorzystać?

Głosuję za NFS.

NFSv4.1 dodał funkcję ParFS NFS pNFS, która umożliwia równoległy dostęp do danych. Zastanawiam się, jakiego rodzaju klienci używają magazynu, jeśli tylko uniksowi, to wybrałbym NFS na podstawie wydajności.

Krótka odpowiedź brzmi: użyj NFS. Według tej strzelaniny i własnego doświadczenia jest szybsza.

Ale masz więcej opcji! Należy rozważyć klaster FS, taki jak GFS, który jest systemem plików, z którego może korzystać wiele komputerów jednocześnie. Zasadniczo współużytkujesz urządzenie blokowe przez iSCSI, który jest systemem plików GFS. Wszyscy klienci (inicjatorzy w języku iSCSI) mogą odczytywać i zapisywać na nim. Redhat ma oficjalny dokument . Możesz również użyć klastra Oracle OCFS do zarządzania tym samym.

Redhat ma dobrą robotę, wymieniając zalety i wady klastra FS vs. NFS. Zasadniczo, jeśli chcesz dużo miejsca do skalowania, GFS jest prawdopodobnie warte wysiłku. Ponadto w przykładzie GFS wykorzystano SAN Fibre Channel jako przykład, ale równie dobrze może to być RAID, DAS lub iSCSI SAN.

Na koniec zajrzyj do ramek Jumbo, a jeśli integralność danych ma kluczowe znaczenie, użyj sumy kontrolnej CRC32, jeśli używasz iSCSI z ramkami Jumbo.

Mamy 2-klastrowy klaster internetowy obciążający serwer. Wypróbowaliśmy następujące metody synchronizacji zawartości między serwerami:

• Lokalne dyski na każdym serwerze synchronizowane z RSYNC co 10 minut
• Centralny udział CIFS (SAMBA) dla obu serwerów
• Centralny udział NFS dla obu serwerów
• Współużytkowany dysk SAN z uruchomionym OCFS2 zamontował oba serwery

Rozwiązanie RSYNC było najprostsze, ale pojawienie się zmian zajęło 10 minut, a RSYNC tak obciążył serwery, że musieliśmy go dusić niestandardowym skryptem, aby wstrzymywać go co sekundę. Ograniczyliśmy się również tylko do zapisu na dysku źródłowym.

Najszybszym dyskiem współdzielonym był dysk klastrowany OCFS2 aż do momentu, gdy oszalał i rozbił klaster. Nie byliśmy w stanie utrzymać stabilności dzięki OCFS2. Gdy tylko więcej niż jeden serwer uzyskuje dostęp do tych samych plików, obciążenie przechodzi przez dach i serwery zaczynają się ponownie uruchamiać. Może to być niepowodzenie szkolenia z naszej strony.

Następnym najlepszym był NFS . Jest wyjątkowo stabilny i odporny na uszkodzenia. To jest nasza obecna konfiguracja.

SMB (CIFS) miał pewne problemy z blokowaniem. W szczególności serwery WWW nie widziały zmian w plikach na serwerze SMB. SMB miał również tendencję do zawieszania się podczas awarii serwera SMB

Doszliśmy do wniosku, że OCFS2 ma największy potencjał, ale wymaga dużo analizy przed użyciem go w produkcji. Jeśli chcesz czegoś prostego i niezawodnego, polecam klaster serwerów NFS z Heartbeat do przełączania awaryjnego.

Proponuję Ci POHMELFS - jest stworzony przez rosyjskiego programistę Evgeniya Polyakova i jest naprawdę bardzo szybki.

Jeśli chodzi o niezawodność i bezpieczeństwo, prawdopodobnie CIFS (alias Samba), ale NFS „wydaje się” znacznie lżejszy, a przy starannej konfiguracji możliwe jest całkowite ujawnienie cennych danych wszystkim innym komputerom w sieci ;-)

Żadnej zniewagi dla BEZPIECZNIKA, ale wciąż wydaje się ... świeży, jeśli wiesz, co mam na myśli. Nie wiem, czy jeszcze mu ufam, ale to może być po prostu mój stary mglisty, ale stary mglisty charakter jest czasem uzasadniony, jeśli chodzi o cenne dane przedsiębiorstwa.

Jeśli chcesz na stałe zamontować jeden udział na wielu komputerach i możesz grać razem z niektórymi dziwnościami (głównie problemy z UID / GID), użyj NFS. Używam go i mam od wielu lat.

NFS. Jest to wypróbowane i prawdziwe, i możesz mieć solidną konfigurację. Wydajność GFS jest ogólnie okropna, szczególnie w systemach plików z dużą liczbą małych plików. Nie korzystałem z OCFS, ale generalnie marszczę brwi z powodu koncepcji systemu plików klastra. Potem jest Luster, ale to kolejna puszka robaków ...

Odradzałbym NFS. Mówiąc najprościej - mieliśmy farmę serwerów WWW, w której JBoss, Apache, Tomcat i Oracle korzystały z udziałów NFS do wspólnych plików konfiguracyjnych i logowania.

Kiedy udział NFS zniknął (co prawda zdarza się rzadko), cała sprawa po prostu się zawaliła (naprawdę przewidywalne, i odradziłem „devlaterom” ten skrót czasu konfiguracji).

Wydaje się, że występuje problem z wersją NFS, z której korzystaliśmy, jeśli cel zniknie podczas zapisu, klient wpadnie w niekończącą się pętlę oczekiwania, czekając na powrót celu NFS. Nawet jeśli pole NFS zostanie ponownie podłączone - pętla nadal się nie kończy.

Używaliśmy mieszanki RHEL 3,4,5. Pamięć masowa była na RHEL4, serwery na RHEL5, sieć pamięci była oddzielną siecią LAN i nie działała na sieciach VLAN.

Jeśli fronton jest wyważony pod kątem obciążenia, sprawdzanie pojedynczego miejsca do przechowywania - czy nie spowoduje to wąskiego gardła w systemie?

Czy rozważałeś połączenie iSCSI tylko do odczytu z pamięcią, ze skryptem sterowanym zdarzeniami, aby przenieść przesłany plik do magazynu za pomocą ftp / scp podczas przesyłania pliku?

Jedyny raz, kiedy wdrożyłem udane scentralizowane przechowywanie wielu głowic czytających, miałem macierz pamięci EMC ... Wszystkie inne opłacalne próby miały swoje wady.

Uważany za GFS? GFS jest systemem plików klastra i według mojego doświadczenia jest dość niezawodny. Może mieć więcej niż jeden dziennik, skaluje się całkiem dobrze

Ale musisz zainstalować niektóre usługi klastrowe, a GFS nie jest dokładnie znany ze swojej szybkości. Oto zawsze było dla mnie wystarczająco szybkie, ale ymmv.

Rozmyślasz nad rozproszonym FS, takim jak GFS, a iSCSI to przesada.

Jeśli chcesz prosto, skorzystaj z NFS. Jest prosty i szybki, a dzięki miękkim mocowaniom dość solidny. Rozważ także wyłączenie wszystkich blokujących śmieci, które się z tym wiążą. Mam komputery stacjonarne z systemem Linux, które pobierają cały katalog domowy i aplikacje z systemu plików NFS, działa dobrze.

Jeśli chcesz oburzającej prędkości, skorzystaj z Lustera, który jest znacznie łatwiejszy do skonfigurowania niż GFS i jest podobny do RAID NFS. Używamy Lustra dla naszych klastrów.

Mogę się trochę spóźnić, używamy pamięci masowej Dell MD3220, która ma podwójny port klastra, nasze urządzenie ma 2 kontrolery, ponieważ jeden zepsuje się drugi, sprawi, że będzie działał, dopóki nie naprawimy tego problemu. Ponieważ wszystkie dyski twarde, wentylatory, zasilacze i kontrolery są Hotswap, wymieniamy części na zewnątrz i na zewnątrz. Od formatu używamy NFS.

Jeśli masz już wszędzie serwery sieciowe i dobrze je uruchamiasz, dlaczego nie rozważyć WebDAV?

Prosta odpowiedź +1 dla NFS. Mam akcje NFS, które były montowane przez lata bez przerwy.

Jeśli szukasz super niezawodności, zastanów się nad wrzuceniem DRBD do miksu, także dla rozproszonego systemu plików NFS z automatycznym przełączaniem awaryjnym.

Jedyną inną opcją (którą znam) jest iSCSI, ale konfiguracja ...

Masz wiele opcji o różnych kosztach. Współdzielony SAN z FC, iSCSI lub jednym z najnowszych dodatków. W każdym razie ich skonfigurowanie może być kosztowne, a nadal musisz uruchomić system plików obsługujący klastry. Klastrowe systemy plików to świat bólu. Aby mieć nadzieję na sukces, potrzebujesz osobnych sieci Hi-Speed ​​o niskim opóźnieniu do komunikacji w klastrze i danych. Mimo to prawdopodobnie dostaniesz usterki, które spowodują, że węzeł zostanie ogrodzony i zabity.

Jedynym systemem plików klastra, na jaki natrafiłem, który działa bezproblemowo, jest VMFS. Ale to jest tak wyspecjalizowane, że nie byłoby pożytku, nawet gdyby był dostępny do ogólnego użytku.

NFS jest prawdopodobnie najlepszym sposobem na konfigurację. Jeśli martwisz się o odporność, musisz uzyskać odpowiednie klastrowe pudełko NFS. Możesz zrobić konfigurację homebrew, ale trafiłby w powyższy problem. Najlepszy zakład (jeśli masz pieniądze), to klastrowane filtry NetApp. Jest to droga opcja, ale klastrowanie faktycznie działa bez żadnych problemów. Poza tym są bardzo szybkie.

Chciałbym powtórzyć ostrzeżenie, które niektórzy wydali przeciwko NFS - chociaż NFS jest prawdopodobnie najlepszym wyborem (dziwne, jak to brzmi).

Miałem klienta NFS, który musiałem odłączyć od prądu przemiennego, aby się wyłączyć, ponieważ serwer NFS zniknął, a klient odmówił (w jądrze) odblokowania lub zamknięcia, ponieważ serwer NFS zniknął.

Aby zrobić to dobrze, nalegałbym na NFSv4 przez cały czas, trzymałbym się połączeń TCP, używał dużych ramek i używał klastra NFS. Nie możesz pozwolić sobie na zniknięcie serwera NFS.

GFS jest poważnym czarnym voodoo. Ilość pracy wymaganej do uzyskania prostego działania dwóch klastrów klienckich jest oszałamiająca w porównaniu do alternatyw. OCFS2 jest znacznie prostszy do wdrożenia, ale jest bardzo wybredny, jeśli chodzi o wersje modułów jądra na wszystkich podłączonych serwerach - i to dopiero początek.

O ile naprawdę nie potrzebujesz takiego dostępu na niskim poziomie, jaki oferuje system plików klastra, prawdopodobnie potrzebujesz tylko NFS lub CIFS.

Na dużej farmie serwerów mieliśmy kilka milionów stron HTML utworzonych przez użytkowników. NFS nie działał tak dobrze, więc ostatecznie umieściliśmy je w tabeli mysql. Narzut w porównaniu do przejścia przez drzewo katalogów był mniej więcej taki sam.

Użyłem SFTP i działało dobrze dla moich celów - NFS było moim pierwszym rozwiązaniem, ale funkcyjność identyfikatorów użytkowników / grup sprawiła, że ​​rzuciłem go dość szybko.

Po prostu skonfiguruj autoryzację publickey, a będziesz w dużej mierze ustawiony. Może być nieco większy narzut procesora dla szyfrowania SSH, ale na plus nigdy nie napotkałem żadnych problemów z uszkodzeniem danych.

FTP może jednak pasować do twoich celów, ponieważ jest bardziej lekki. Przypuszczalnie chcesz, aby twoje serwery WWW wykonywały serwery WWW, a nie ssh.