Udostępniasz pliki statyczne z Nginx przez NFS?

Mam witrynę, która odbiera około 7 000 żądań na sekundę na serwerze Nginx. Ten serwer obsługuje zarówno przepisywanie na serwer Apache, jak i bezpośrednie przesyłanie plików statycznych, obrazów itp. Pliki statyczne to największa część z około 5 000 żądań.

Przy aktualizacji architektury myślę o użyciu centralnego serwera plików, który eksportuje katalog zawierający te pliki statyczne przez NFS. Dostęp do tych plików nie będzie możliwy, dlatego katalog może zostać podłączony tylko do odczytu na maszynie nginx. Moją główną troską jest:

Czy NFS jest na to wystarczająco szybki? Czy istnieje ograniczenie liczby żądań obsługiwanych przez NFS? Czy idąc w tę stronę są jakieś „niezbędne” opcje?

Bonus: czy istnieją inne alternatywy dla tej konfiguracji oprócz NFS?

Dzięki!

Konfigurując centralny serwer NFS, wprowadzasz jeden punkt awarii do swojego projektu. Samo to powinno przełamać umowę. Jeśli nie, NFS może być wystarczająco szybki dla takiego obciążenia. Krytycznymi czynnikami będą wystarczająca ilość pamięci RAM do buforowania plików, połączenia o niskim opóźnieniu (Gig-E lub lepsza) i strojenie (mniej niż poprzednio).

Należy również mocno rozważyć użycie rsync lub podobnego narzędzia do przechowywania lokalnych kopii aktualizacji plików statycznych na każdym serwerze sieciowym. Inną opcją może być SAN lub nadmiarowe rozwiązanie serwera NFS (oba będą znacznie bardziej skomplikowane i kosztowne niż pomysł rsync).

Używam cachefilesd (i najnowszego jądra Linuksa z cachefs) do buforowania plików NFS na lokalny HD. W ten sposób każdy odczyt w NFS skopiuje plik do katalogu / var / cache / fs i stamtąd będą dostarczane kolejne odczyty, a jądro sprawdzi w NFS, czy zawartość jest nadal aktualna.

W ten sposób możesz mieć centralny NFS, ale bez utraty wydajności plików lokalnych

Cachefilesd zajmie się czyszczeniem starych plików, gdy wolny rozmiar / i-węzły osiągną skonfigurowany poziom, dzięki czemu możesz obsługiwać rzadkie dane z NFS i typowe żądania z HD

Oczywiście użyj również lakieru do buforowania bardziej popularnych żądań i zapisz nginx / NFS przed wyświetleniem.

Oto mały howto podręcznego pliku

Prędkość zależy od wielu czynników:

• W jaki sposób twoje serwery będą połączone z celem NFS? Pojedynczy dwuportowy dysk SAS może wykorzystywać prędkość transferu 6 Gb / s. Pamiętaj o tym, jeśli planujesz używać sieci Ethernet 1gig (z której możesz odjąć 20% narzutu TCP).
• Jaką pamięć podręczną otrzyma serwer NFS? Czy używasz kontrolera macierzy klasy korporacyjnej z dużą ilością pamięci podręcznej? Odczytywanie pamięci podręcznej jest kluczem w tej konfiguracji
• Ile serwerów będzie jednocześnie uzyskiwać dostęp do tego samego pliku? Blokowanie NFS może zaszkodzić - bardzo

Limit otwartych plików przez NFS jest ograniczeniem systemu operacyjnego hosta. FreeBSD ma na przykład wiele różnych opcji dostrajania do obsługi dużej liczby otwartych plików, ale zależy to od ilości pamięci RAM na serwerze.

Alternatywą dla centralnego serwera plików jest użycie synchronizacji / replikacji między serwerami internetowymi (jak sugeruje Chris S.). rsync lub DRBD może być świetnym i opłacalnym wyborem.

Odradzałbym NFS, chyba że umieścisz tam trochę buforowania. Pamięć podręczna nginx jest lepsza niż nic, ale Lakier jest lepszy.

Mając to na uwadze, jeśli obciążenie zmieni się na zawartość bardziej dynamiczną niż statyczną, ważniejsze stanie się udostępnianie plików aplikacji z dysku lokalnego.

Jeśli włączysz NFS, upewnij się, że masz nadmiarowość.