Network File System NFS Michał Kowalczyk

1. Network File System NFS Michał Kowalczyk

2. Plan prezentacji • Historia • Specyfikacje • Założenia projektowe • NFS wersja 3 • NFS wersja 4 • Przykładowa implementacja Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

3. Historia NFS (ang. Network File System), czyli sieciowy system plików został stworzony przez firmę Sun Microsystems w latach osiemdziesiątych jako wysoce wydajne (jak na owe czasy) rozwiązanie udostępniające poprzez sieć lokalną system plików na komputerach klienckich nie wyposażonych w dyski twarde. NFS jest otwartym standardem implementującym architekurę klient-serwer dla dzielenia plików, który jest wspierany przez rozmaite systemy: od komputerów osobistych, poprzez stacje robocze, na „mainframe’ach” kończąc. Pierwsza wersja została zaprezentowana w roku 1985. Ciekawostką jest fakt, że miała ona numer 2, ponieważ wersja o numerze 1 nie została nigdy opublikowana. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

4. Historia Od tego momentu NFS ewoluował i rozwijał się, by spełnić nowe wymagania, które pojawiły się na początku lat dziewięćdziesiątych (dotyczące zwłaszcza rozproszonego systemu plików dla sieci globalnych). Upowszechnił się szeroko w środowiskach przemysłowych, akademickich oraz laboratoriach badawczych, jako że firma Sun postanowiła udostępnić definicje podstawowych interfejsów oraz przykładową implementację. Ponad 300 firm i organizacji dołączyło do swoich produktów wsparcie dla tego standardu, więc jest on dostępny na niemal wszystkie platformy programowe (m.in. MS-DOS, Windows, Unix) i sprzętowe (m.in. Intel, SPARC, Alpha). Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

5. Specyfikacje • NFS wersja 2 – RFC 1094 – marzec 1989 • NFS wersja 3 – RFC 1813 – czerwiec 1995 • NFS wersja 4 – RFC 3530 – kwiecień 2003 Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

6. Założenia projektowe • Przezroczystość • Przenośność i niezależność od protokołu sieciowego • Szybki powrót do pracy po awarii • Wydajność • Bezpieczeństwo Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

7. Przezroczystość Przezroczystość oznacza, że użytkownicy i aplikacje mogą używać zdalnych plików tak, jakby znajdowały się one lokalnie (system jest postrzegany jako całość bez wyraźnie zaznaczonych składowych). Różne rodzaje przezroczystości: • dostępu – umożliwia dostęp do lokalnych i odległych obiektów i informacji za pomocą identycznych działań • położenia – umożliwia dostęp do obiektów i informacji bez znajomości lokalizacji • współbieżności – umożliwia wielu procesom niezakłócone działanie z użyciem wspólnych obiektów informacji • zwielokrotniania – pozwala na użycie wielu kopii obiektów informacji w celu zwiększenia niezawodności i wydajności bez wiedzy użytkowników i programów użytkowych o zwielokrotnieniach Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

8. Przezroczystość (II) • awarii – umożliwia wykrywanie uszkodzeń, pozwalając użytkownikom i programom użytkowym na kończenie zadań pomimo awarii sprzętu lub składowych oprogramowania • wędrówki – pozwala na przemieszczanie obiektów informacji w obrębie systemu bez wpływu na działania użytkowników lub programów użytkowych • wydajności – umożliwia rekonfigurowanie systemu w celu poprawy działania przy zmianie obciążenia • skalowania – umożliwia systemowii jego zastosowaniom rozszerzanie skali bez zmiany struktury systemu lub algorytmów użytkowych Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

9. Przenośność i niezależność od protokołu sieciowego NFS jest niezależny zarówno od platformy sprzętowej, jak i systemu operacyjnego. To sprawia, że może on być łatwo przeniesiony na wiele różnych maszyn. Może ponadto działać z wykorzystaniem wielu istniejących protokołów (chodzi tu o warstwę transportu) jak np. UDP i TCP. Ma również możliwość współpracy z protokołami wymyślonymi w przyszłości. Ta niezależność bierze się z faktu, że NFS zbudowany jest w oparciu o TI-RPC (ang. Transport Independent Remote Procedures Calls), czyli zdalnego wywoływania procedur niezależnego od warstwy transportu, w której to metodologii zostały zaimplementowane wszystkie procedury. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

10. Szybki powrót do pracy po awarii NFS został zaprojektowany tak, aby jak najszybciej wrócić do normalnego stanu po awarii, co powoduje jedynie minimalną przerwę w dostawie usług do klientów. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

11. Wydajność i Bezpieczeństwo Projekt NFS zakładał wysoką wydajność systemu, tj. taką, aby czas dostępu do zdalnych plików był porównywalny do czasu dostępu do plików lokalnych (w przypadku lokanych sieci małej i średniej wielkości). Architektura systemu pozwala na wykorzystanie wielu mechanizmów bezpieczeństwa. Administratorzy nie są więc ograniczeni do konkretnego mechanizmu, lecz mogą wybrać ten, który najbardziej odpowiada ich środowisku pracy. Rozwiązanie to pozwala także na użycie mechanizmów wymyślonych w przyszłości. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

12. NFS wersja 3 Pomimo ogromnego sukcesu NFS 2 nie był pozbawiony wad. Dwa największe problemy, których starano się pozbyć projektując wersje 3 protokołu to: • Maksymalny rozmiar plików - 4 GB • Wymaganie wszystkich zapisów do wykonania zapisu synchronicznego powodowało wąskie gardło aplikacji intensywnie zapisujących dane. Głównym celem w NFS 3 oprócz pozbycia się powyższych problemów było uporządkowanie istniejącego protokołu oraz dodanie kilku usprawnień, ale tak, aby nie stracić na wydajności. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

13. NFS wersja 3 (II) Zapisy w Unixie są domyślnie asynchroniczne (co można jednak zmienić przekazując odpowiednie flagi do funkcji open). Wymuszanie jednak aby zapis asynchroniczny odbywał się synchronicznie znacznie zmniejsza wydajność. W NFS 3 klient może wysłać wiele asynchronicznych żądań zapisu, które później może zatwierdzić na dysku serwera przy pomocy komendy COMMIT. Kiedy serwer otrzyma takie żądanie serwer nie może normalnie pracować do momentu w którym wszystkie dane nie zostaną zapisane na dysku. Jest to duże usprawnienie gdyż pozwala to systemowi plików na serwerze lub sterownikowi dysku na zebranie wielu zapisów w jeden większy co jest bardziej efektywne. Użycie asynchronicznych zapisów nie powinno wpływać na dotychczasowe reakcje NFS’a na awarie ponieważ klient jest zobowiązany do przetrzymywania kopii wszystkich danych przekazanych do zapisania aż do wysłania komendy COMMIT. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

14. NFS wersja 3 (III) Procedura READDIRPLUS, która umożliwia zwracanie zarówno uchwytu pliku jak i jego atrybutów wyeliminowała dodatkowe żądania odczytu, ale spowodowała inne problemy. Ponieważ implementacja tej procedury jest znacząco droższa niż poprzedniej READDIR powinna być używana z rozwagą. Zazwyczaj operacja powinna być przeprowadzona tylko podczas pierwszego dostępu do pliku, a później tylko w wypadku gdy unieważniona została pamięć cache dotycząca katalogu poprzez jego modyfikację. Ponieważ NFS 3 miał również na celu zwiększenie wydajności jego sukces zależał między innymi od tego jak dobrze działał ten mechanizm. Wiele różnych testów pokazało jednak, że trzecia wersja protokołu NFS sprostała także temu zadaniu. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

15. NFS wersja 4 NFS został zaprojektowany z myślą o lokalnych sieciach i rozwinął się przed erą WWW. W miarę upływu czasu pojawia się coraz większa potrzeba użycia NFS’a w rozległych sieciach. Tutaj powstają pytania o bezpieczeństwo i możliwości NFS’a w zakresie adresowania różnego rodzaju środowisk. Chociaż jednym z celów oryginalnego NFS’a było wsparcie dla nie Unix’owych platform protokół ciągle kierował się w stronę środowiska Unix’owego. Celami wersji 4 było więc pokonanie powyższych trudności oraz dostarczenie dodatkowych funkcjonalności niezaimplementowanych w wersji 3. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

16. NFS wersja 4 (II) Najważniejsze zmiany wprowadzone w wersji 4 to: Połączone procedury. Wiele operacji na plikach poprzez NFS wymaga dużej liczby wywołań procedur. W lokalnej sieci nie jest to duży problem. Operując jednak na rozległych sieciach efekt wydajnościowy jest dużo bardziej zauważalny. Poprzez łączenie wielu wywołań procedur w jedno ilość komunikacji może zostać zmniejszona co powoduje zwiększenie wydajności. Wielonarodowość. We wcześniejszej wersji protokołu nazwy plików były reprezentowane jako strumień bitów. Chociaż były one ograniczone do 7 bitowej reprezentacji US ASCII powszechnie używały 8 bitowej ISO-Latin-1. Problemy pojawiły się ponieważ nie było sposobu na wyspecyfikowanie kodowania w reprezentacji danych XDR. Ograniczało to użycie NFS’a w środowiskach z różnymi zestawami znaków. W NFS’ie 4 pliki i katalogi używają nazw kodowanych przy pomocy UTF-8, więc powyższy problem nie występuje. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

17. NFS wersja 4 (III) Ulotne uchwyty plików. NFS 2 i 3 dostarczały jednego typy uchwytów z jednym zestawem semantyk. Taki uchwyt ma ustaloną wartość na czas istnienia systemu plików do którego się odwołuje. Protokół NFS 4 rozdziela uchwyty na dwa rodzaje: • trwałe - opisujące tradycyjne uchwyty • i ulotne. W tym drugim przypadku serwer nie zawsze może określić czy dany uchwyt jest ciągle ważny. Jeżeli wykryje że uchwyt został unieważniony zwraca odpowiedni komunikat o błędzie. Jeżeli jednak nie może zdecydować czy uchwyt jest ważny czy nie wysyła inny komunikat. Klient jest w stanie wykryć czy serwer może używać trwałych i ulotnych uchwytów i odpowiednio na takie błędy zareagować. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

18. NFS wersja 4 (IV) Klasy atrybutów. Zbiór atrybutów, który był przekazywany poprzez siec był we wcześniejszych wersjach NFS’a ukierunkowany na Unixa. W niektórych środowiskach te atrybuty były bez znaczenia, a z kolei w innych serwery nie były w stanie dostarczyć aktualnych danych. W czwartej wersji NFS’a zbiór atrybutów pliku został podzielony na trzy różne klasy atrybutów: • podstawowych - informacje takie jak typ i wielkość pliku, informacje na temat wygaśnięcia uchwytu. • zalecanych - informacje o właścicielu, grupie, czasach dostępu, atrybutach quoty. Zawierała również informacje systemu plików na temat wolnej przestrzeni na dysku, liczby plików, plików dostępnych do użytku, ograniczenia systemu plików [np. długość nazwy] • nazwanych - umożliwia pojedynczemu plikowi na posiadanie wielu strumieni bitów w przeciwieństwie do tradycyjnego modelu Unixa. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

19. NFS wersja 4 (V) Blokowanie plików. NFS 4 umożliwia osobne systemy blokowania plików dla Unixa i Windowsa. Wspiera zarówno blokowanie rekordów jak i określonych zakresów bajtów. Wbudowana ochrona. NFS korzystał z mechanizmu Unixa weryfikacji użytkowników aby zapewnić ochronę. Nie było to zazwyczaj problemem, gdyż był on używany głównie w prywatnych sieciach. Biorąc jednak pod uwagę cele wersji 4 ten poziom zabezpieczenia nie był wystarczający. Podstawowe mechanizmy bezpieczeństwa NFSa zostały poszerzone poprzez implementacje dodatkowych mechanizmów w warstwie procedur RPC, które dostarczają zestawy prywatnych i publicznych kluczy. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

20. NFS wersja 4 (VI) Cache'owanie po stronie klienta. Większość klientów NFS zapamiętuje zarówno dane z pliku jak i atrybuty. Gdy przenosimy się do rozległych sieci koszt "nie trafienia" (cache miss) może być znaczący. Problem z wersjami 2 i 3 polegał na tym, że nie dostarczały one pośredników do łączenia pomiędzy wieloma klientami, co czasami może prowadzić do przeczytania nieważnych danych. NFS 4 nie wprowadza łączników z klientami, ale definiuje minimalny zbiór danych dla których gwarantuje rezerwacje blokad (zwykłych i dzielonych) i na których klient może bez przeszkód operować. NFS 4 dostarcza także "schemat delegacji", który umożliwia klientowi podejmowanie decyzji tradycyjnie podejmowanych przez serwer. Jest to ważne przy wydajności gdyż ogranicza liczbę wywołań procedur. Gdy inny klient poprosi o dostęp do pliku, którego delegacja została komuś przyznana serwer wysyła RPC do klienta który posiada te delegację. Jest on teraz odpowiedzialny za zapisanie wszystkich zmian na serwerze a następnie oddanie delegacji. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

21. Przykładowa implementacja Konfiguracja serwera NFS NFS jest często używanym sieciowym systemem plików. Jego implementacja jest domyślnie dostępna praktycznie we wszystkich dystrybucjach Linuksa, więc bardzo łatwo go zintegrować z systemem plików po stronie gościa. W przypadku Debiana instalacja jest dosyć prosta, sprowadza się do zainstalowania odpowiedniego pakietu oraz zdefiniowania eksportowanych udziałów. Serwer NFS jest umieszczony w pakiecie o nazwie nfs-kernel-server, więc pierwszym krokiem jest jego instalacja: # aptitude install nfs-kernel-server Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

22. Przykładowa implementacja (II) Konfiguracja udostępnianych udziałów jest przechowywana w pliku /etc/exports, więc należy tam umieścić odpowiednie wpisy: /exports 192.168.0.0/24(rw,no_subtree_check) Powyższy wpis powoduje, że udział /exports będzie dostępny dla wszystkich łączących się z sieci 192.168.0.0/24 w trybie odczytu i zapisu. Aby uruchomić serwer NFS należy teraz wywołać skrypt startowy: # /etc/init.d/nfs-kernel-server start Jeżeli zmienimy konfigurację udostępnianych udziałów na działającym serwerze NFS, to aby te zmiany były widoczne należy wykonać polecenie: # exportfs -a Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

23. Przykładowa implementacja (III) Konfiguracja klienta NFS Udziały NFS mogą być zamontowane ręcznie z linii poleceń np.. Przez wykonanie polecenia: # mount jakis.serwer.com:/exports /home/exports To polecenie montuje katalog /exports z maszyny jakis.serwer.com jako katalog /home/exports na kliencie. Oczywiście, aby to polecenie zadziałało katalog /home/exports musi istnieć na kliencie oraz serwer musi być skonfigurowany tak aby klient miał odpowiedni dostęp do katalogu /exports Najczęściej udziały NFS montuje się automatycznie przy starcie systemu przez odpowiednie wpisy w pliku /etc/fstab np.: jakis.serwer.com:/exports /home/exports nfs rw,hard,intr,async,nodev,nosuid 0 0 Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego

24. Dziękuję za uwagę. Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego