NFS Version 4


Autor: Piotr Kowalski


O prezentacji

Prezentacja powstała jako projekt w ramach zajęć z Systemów Operacyjnych na Wydziale Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego. Autorem prezentacji i materiałów jest Piotr Kowalski. Prezentacja została przeprowadzona przy użyciu slajdów, których miniatury znajdują się w prawej części tej strony. Materiały HTML zostały opracowane jako uzupełnienie znajdujących się tam haseł.

Obecnie opracowywana jest jedynie specyfikacja protokołu a nie sam serwer NFS V4. Dlatego też nie może być mowy o konkretnych algorytmach stosowanych w implementacji NFS, jako że pełna implementacja jeszcze przez pewien czas nie ujrzy światła dziennego. Opisywanie NFS V4 może jedynie bazować na opracowywanej specyfikacji samego protokołu. To, jak te wszystkie założenia zostaną zrealizowane przez serwery sieciowego systemu plików leży w kwestii przyszłych programistów.

Kto opracowuje?

NFS, czyli Network File System powstał w firmie Sun Microsystems. Wersja 2.0 została opracowana w 1985 roku, a 3.0 w roku 1994. Obecnie trwają prace nad zbudowaniem standardu NFS wersji 4 i właśnie planowane zmiany będą przedmiotem tej prezentacji. Autor zakłada znajomość NFS w wersji 3.0 (prezentowanej na wykładzie z SO) przez czytelnika.

Konieczność rozbudowania istniejącej wersji NFS była wyraźnie widoczna już w połowie lat 90. Dynamiczny rozwój Internetu i upowszechnienie się sieci WAN w znaczący sposób zmeniło środowisko pracy systemów sieciowych. Niezbędna stała się szybka i przezroczysta dla użytkownika możliwość przesyłania plików w sieciach rozległych, gdyż istniejące protokoły (FTP) nie udostępniały wystarczająco elastycznej funkcjonalności. Z kolei NFS V3 został skonstruowany dla szybkich sieci lokalnych, w których transmisja była szybka, a odpowiedź serwera błyskawiczna. Nowe środowisko wymusiło opracowanie nowego standardu. Wiele firm i organizacji pokusiło się o próbę stworzenia wydajnego rozproszonego systemu plików (IBM, Microsoft), jednak popularność NFS V3 zobligowała firmę Sun Microsystems do wytężonych prac.

Obecnie NFS V4 nie jest opracowywany wyłącznie przez Sun Microsystems. Podjęta została decyzja o upublicznieniu prac nad specyfikajcą w ramach Internet Engineering Task Force (IETF), w ramach której powstała grupa osób pracująca nad specyfikacją protokołu. W kierownictwie tej grupy znajdują się także ludzie z Sun Microsystems.

IETF planuje zgłoszenie ostateczniej wersji protokołu NFS V4 do zatwierdzenia jako tzw. "draft standard" przez IESG we wrześniu 2003 roku.

Priorytety prac

Grupie pracującej nad NFS V4 przyświecają następujące cele:
  • poprawienie szybkości działania w sieciach rozległych
  • zwiększenie bezpieczeństwa i dołączenie szyfrowania danych do protokołu
  • zwiększenie elastyczności systemu plików aby był zgodny z obecnymi lokalnymi FS
  • stworzenie specyfikacji łatwo rozbudowywalnej i modyfikowalnej
  • zachowanie kompatybilności z NFS 2/3 oraz popularnymi systemami operacyjnymi

    • Punkty te odzwierciedlają słabe strony NFS V3 i są głównymi ścieżkami zmian zaplanowanych na wersję 4.

    Szybkość - wywołania RPC

    NFS V3 udostępnia standardową listę komend. Każde wywołanie takiej komendy generuje jedno wywołanie RPC. W szybkich sieciach lokalnych taki ruch nie stanowił większego problemu, jako że odpowiedź serwera zwykle nadchodziła po kilkunastu do kilkudziesięciu milisekundach. W sieciach rozległych pojawił się problem. Aby np. odczytać dane z pliku należy wywołać 3 procedury NFS V3 (LOOKUP, ACCESS, READ), co generuje 3 wywołania RPC i 3 odpowiedzi. Bardziej skomplikowane operacje wymagały kilkunastu lub nawet kilkudziesięciu wywołań komend.

    Wszystkie takie złożone wywołania miały wspólną cechę - z reguły były liniowe (ciąg wykonywanych instrukcji był zawsze taki sam), a w większości wypadków nieprawidłowe wykonanie komendy przerywało całą operację. Dlatego też projektanci NFS V4 zastosowali mechanizm operacji złożonych, tzw. Compound. Operacja typu Compound składa się z kilku uszeregowanych wywołań procedur NFS V4 przesyłanych do serwera jako jedno wywołanie RPC. Serwer odpowiada podobnie - wyłącznie raz przekazując kody wykonania wszystkich zawartych procedur (patrz slajd).

    Dzięki takiemu rozwiązaniu zachowana jest kompatybilność wstecz (zawsze Compound może składać się z pojedynczego wywołania procedury) i umożliwiona jest optymalizacja pracy w sieciach rozległych.

  • RPC - Remote Procedure Call - mechanizm wołania procedur przez sieć.

    • Szybkość - cache

    Serwery NFS V3 były bezstanowe, tzn. nie przechowywały żadnych informacji o kliencie. Ponieważ protokół NFS działa nad protokołem UDP takie rozwiązanie wydawało się optymalne. Rzeczywiście - model bezstanowy jest bardziej niezawodny (za wszystko odpowiada klient) i odporny na restart serwera, gdyż żadne dane odnośnie sesji nie są tracone.

    Wadą takiego rozwiązania jest konieczność transmisji większej ilości danych przy wywołaniach RPC - trzeba każdorazowo przesłać m.in. identyfikator klienta i deskryptor otwartego pliku. Model bezstanowy również nie pozwala na efektywne cachowanie po stronie klienta.

    NFS V4 jest projektowany jako oparty o serwer stanowy. Protokołem nadal pozostaje UDP, aczkolwiek serwer przechowuje informacje o sesjach klientów. Rozwiązanie to ma wiele zalet istotnych dla środowisk rozległych - trzeba przesyłać mniej informacji przy każdym wywołaniu (serwer przechowuje m.in. uchwyt do aktualnego pliku roboczego klienta) i możliwe jest "agresywne" cachowanie danych u klienta (np. delegowanie). W protokole NFS V4 planuje się zastosowanie mechanizmu wykrywającego restarty klientów i ich identyfikację na podstawie adresu IP. Szczegóły implementacyjne cachowania nie zostały jeszcze do końca opracowane.

    Specyfikacja innego rozproszonego systemu plików - CIFS, opracowanego przez firmę Microsoft wymaga stanowości serwera. Kompatybilność NFS V4 i CIFS otrzymano tu "przy okazji".

  • UDP - protokół sieciowy nad protokołem IP umożliwiający transmisję pojedynczych pakietów bez potrzeby nawiązywania połączenia między maszynami (jak w TCP). UDP nie gwarantuje spójności danych ani pewności doręczania komunikatów.
  • delegowanie - jeśli dany klient jest jedynym, które chce odwoływać się do określonego pliku, serwer może przekazać mu operowanie na tym pliku "na wyłączność" - klient operuje na lokalnej kopii i w momencie zamykania pliku przesyła go do serwera. Drastycznie minimalizuje to liczbę wywołań RPC.

    • Bezpieczeństwo

    NFS 2 i 3 nie były zbyt bezpieczne. Opracowane na potrzeby szybkich, małych sieci lokalnych zawierały tylko słabe zabezpieczenia przed intruzami. W wersji 3 dostępne są trzy metody autoryzacji użytkowników:
  • AUTH_SYS - styl UNIXowy - UID, GID; wadą jest stosunkowo łatwa metoda podszywania się pod innych użytkowników,
  • AUTH_DH - oparta na systemie kluczów publicznych Diffie-Hellman z szyfrowaniem DES; stosowany klucz jest 192-bitowy, co na dzisiejsze czasy nie jest wystarczające w Internecie,
  • AUTH_KERB4 - wykorzystująca protokół Kerberos w wersji 4, dość słabo opracowanym mechanizmie zabezpieczeń (dotyczy tylko wersji 4 Kerberosa).
    • Aby wyjść na przeciw oczekiwaniom użytkowników Internetu wprowadzono nowy schemat zabezpieczeń do NFS V4 - RPCSEC_GSS, czyli Generic Security Services. Jest to szkielet, do którego możliwe jest podłączanie różnych algorytmów zapewniających bezpieczeństwo. Obecnie planowane są implementacje Kerberos 5, PGP i RSA. Elastyczna konstrukcja umożliwia każdemu dołączenie własnego schematu do serwera NFS.

    Ważną cechą RPCSEC_GSS jest fakt, iż operuje on między NFSem a RPC i jest dla programisty NFS przezroczysty, tzn. nie wymaga żadnego dodatkowego kodu. Programista może zażądać określonego poziomu zabezpieczeń i system zapewni mu go stosując negocjację protokółów bezpieczeństwa. Obecnie planuje się trzy poziomy zabezpieczeń:

  • bez zabezpieczeń (dla bezpiecznych i pewnych sieci LAN)
  • integrity (zapewnia spójność przesyłanej informacji; dla sieci odgrodzonych od Internetu)
  • privacy (oprócz spójności zapewnia poufność i autoryzację użytkowników, domyślny tryb pracy w Internecie)
    • Projektantów NFS V4 często pyta się dlaczego nie stosują SSL - przyczyną jest fakt, iż NFS używa protokołu UDP, który nie jest obsługiwany przez SSL.

  • SSL - Secure Sockets Layer - warstwa pośrednicząca między protokołem TCP/IP a oprogramowaniem, umożliwiająca autoryzację i szyfrowanie danych; na niej opiera się m.in. SSH (Secure SHell)

    • Elastyczny system plików

    NFS 2 i 3 zostały opracowane na bazie UNIXowego systemu plików i dlatego zawierają pewne niekompatybilności niedopuszczalne w obecnych środowiskach rozproszonych. Jednym z takich archaizmów jest ustalona lista atrybutów plików. Są to atrybuty UNIXowe.

    Aby umożliwić współpracę NFS V4 z lokalnymi systemami plików z dynamiczną listą atrybutów (np. ostatnia wersja NTFS), także w NFS V4 dodano taką możliwość. Atrybuty zostały podzielone na 3 grupy:

  • mandatory - obowiązkowe, np. rozmiar, typ (link, katalog, plik)
  • recommended - zalecane, np. wrażliwość na wielkość liter, właściciel, prawa UNIXowe, ACL
  • named - nazwane, są to rzadko występujące atrybuty, których nazwy ustalono dla zachowania przyszłej kompatybilności
    • Nowością jest także ACL, który jest zalecanym atrybutem plików.

    Innym archaizmem NFS V3 była niemożnośc przeglądania udostępnionych podsystemów plików przez klienta. Musiał on posługiwać się znanym "skąś" identyfikatorem zbioru. NFS V4 tworzy wirtualny system plików, po którym użytkownik może się porusząc i przeglądać udostępnione zasoby.

  • ACL - Access Control List - lista praw dostępu do zbioru opisująca uprawnienia każdego użytkownika (w UNIXie można tylko specyfikować prawa właściciela, grupy i pozostałych)

    • Przenośność i kompatybilność - port

    Mimo, iż port 2049 jest zatwierdzonym przez IANA portem pracy NFS, wersje 2 i 3 korzystały także z innych portów. Działo się tak za sprawą protokołu Mount, który nie miał na stałe przydzielonego portu i otrzymywał dynamicznie przydzielany numer przy każdym restarcie usługi. Na domiar złego, użytkownik łącząc się z serwerem NFS musiał co najmniej raz użyć tego protokołu. Takie rozwiązanie uniemożliwiało pracę przez firewall'e filtrujące, gdyż blokowały one transmisję danych na nieznanych im portach (a więc także dynamicznie przydzielonym porcie Mount).

    W NFS V4 wyeliminowano potrzebę używania Mounta i przez to NFS V4 pracuje tylko i wyłącznie na porcie 2049. Mount służył do tłumaczenia ścieżki i nazwy pliku na uchwyt do niego. Zamiast tego wprowadzono uchwyt "root", który może służyć za punkt wyjścia w przeglądaniu drzewa systemu plików udostępnianego przez NFS.

    Przenośność i kompatybilność - alfabet

    NFS 2 i 3 pracują na zestawach znaków 7-bitowym ASCII lub 8-bitowym ISO Latin 1. Pierwszy zawiera tylko alfabet łaciński, drugi daje nieco więcej (128 znaków rozszerzonych z najpopularniejszymi znakami diakrytycznymi), aczkolwiek zdecydowanie za mało, aby przechowywać nazwy plików w większości krajów świata. Przejście na pojemny zestaw znaków jest priorytetowym obowiązkiem projektantów NFS V4.

    Ostatecznie wybrano UTF-8, czyli zestaw, który znaki z zakresu 0-127 (alfabet łaciński) reprezentuje tak samo, jak 7-bitowy ASCII (co umożliwia szybką migrację), a w sumie pozwala na reprezentowanie wszystkich znaków, jakie zapisano w standardzie Unicode.

    Przenośność i kompatybilność - blokowanie

    NFS 2 i 3 nie udostępniają mechanizmu blokowania plików. Bazują na blokowaniu wewnątrzserwerowym NLM, którego funkcjonalność jest minimalna. Dodanie blokad do NFS V4 jest niezbędnym wymogiem nowoczesnych środowisk rozproszonych.

    NFS V4 oferuje m.in. blokady zakresowe na pliki, blokady dzielone i blokady luźne. Ich funkcjonalność jest podobna do blokad we wszelkich innych systemach plików (czytelnicy, pisarze, wyłączność itp.). Aby zachować kompatybilność z innymi rozproszonymi systemami plików wprowadzono dwa rodzaje blokad - kompatybilne z blokowaniem UNIX i kompatybilne z blokowaniem Windows (OpLocks w CIFS). Między tymi dwoma ideami istnieją pewne (drobne) różnice.

    Nowości

    Oprócz poprawiania niedociągnięć twórców NFS 2 i 3 wprowadzono także kilka nowych rzeczy. Są to m.in.:
  • przezroczystość replikacji i migracji danych - założenie to znajduje się w specyfikacji protokołu NFS V4, aczkolwiek nie zostały podane algorytmy, które wywiążą się z tego zadania. Specyfikacja zakłada m.in. listy alternatywnych źródeł danego pliku, co ma umożliwić wybór "mirrora" do ściągania i poprawia niezawodnośc systemu,
  • identyfikacja użytkownika na poziome user@domain - wcześniej użytkownik był identyfikowany za pomocą UIDa, co w Internecie nie ma sensu; wymaga się aby "domain" (lub jej sufiks) była zarejestrowaną domeną DNS co gwarantuje unikalność nazw,
  • ACL - wspomniane w rozdziale o bezpieczeństwie.

    • Więcej informacji

    Dodatkowe materiały można znaleźć tu:
  • www.nfsv4.org - strona domowa projektantów NFS V4
  • www.ietf.org - strona domowa IETF
  • www.citih.umich.edu/projects/nfs4
  • www.ietf.org/rfc - dokumenty RFC 2224, 2624, 3010

    • Refleksja na koniec

    Twórcom NFS V4 przyświeca jedna idea - masowe upowszechnienie tzw. "Internet disków". Mniej więcej w okolicach 1999 roku zaczęły pojawiać się w Internecie pierwsze serwisy udostępniające przestrzeń na swoich dyskach twardych. Te internetowe "dyski twarde" początkowo miały pojemności rzędu kilkudziesięciu MB i dostęp do nich był mocno utrudniony (FTP lub specjalne oprogramowanie). Stało się to możliwe dzięki dużemu spadkowi cen pamięci masowych. Obecnie cena 1 GB pamięci dysku twardego zbliża się do 1 USD. Taki "Internet disk" ma wiele zalet - firmy gwarantują większe bezpieczeństwo danych stosując macierze dyskowe a dostęp do nich możemy mieć z każdego miejsca na Ziemi.

    To właśnie FTP - obecnie standard transmisji plików przez sieć, mimo istnienia HTTP i HTTPS nadal utrzymuje dość mocno swoją pozycję. Pokoleniowa zmiana protokołów chyba najpierw powinna tknąć FTP, który ma wiele zaszłości z dawnych lat (np. dwa tryby przesyłu danych - ASCII i BIN) i niedoskonałości (transmisja hasła czystym tekstem, podobnie jak danych). Stworzenie szybkiego rozproszonego systemu plików, który byłby (ze względu na swoją popularność) dostępny we wszystkich systemach operacyjnych, z doskonale funkcjonującym mechanizmem zabezpieczeń i całkowitą przezroczystością dla użytkownika jest nader mocnym wyzwaniem. Większość podejmowanych do tej pory prób - półśrodków nie zyskała większego grona zwolenników, z kolei systemy dobrze sprawdzające się w sieciach LAN (np. SMB) są kompletnie nieużyteczne w Internecie.

    Wypromowanie nowego standardu, dzięki któremu coraz trudniej będzie się dowiedzieć, czy pracujemy na pliku lokalnym czy zdalnym, jest obecnie możliwe tylko za pomocą jego własnej siły. Działania marketingowe nie przyniosą tu rezultatu, gdyż w dobie Linuxa i Open Source tylko jakość może być gwarancją sukcesu i jego właśnie twórcom NFS V4 z całego serca życzę. I jedynie ironią pozostaje fakt, iż Bill Gates zbudował swoje imperium opierając się na zasadzie mówiącej, że "każdy chce mieć swoje dane tuż koło siebie". Widocznie zmiana pokoleń następuje nie tylko w sferze protokołów sieciowych.

    Piotr Kowalski