Rozproszony system plików to rozproszona implementacja klasycznego systemu plików, która wielu użytkownikom pracującym na różnych maszynach umożliwia dostęp do dzielonego zestawu plików i obszaru składowania. W wykładzie 12 zajmiemy się takimi systemami plików. Omówimy zagadnienia związane z nazewnictwem (nazwy muszą unikatowo identyfikować plik), przezroczystością (dobrze, aby użytkownik mógł nie orientować się, z jakim systemem plików ma do czynienia), pamięcią podręczną (żeby minimalizować ruch w sieci) i jej spójnością oraz kwestią replikacji plików.
Rozproszony system plików (DFS - Distributed File System) zarządza zbiorem rozproszonych urządzeń do składowania danych. Całość przestrzeni składowania DFS może być złożona z wielu rozproszonych na rozmaitych maszynach heterogenicznych (różnorakich) lokalnych dysków. Zwykle istnieje pewna zależność między tymi lokalnymi składowiskami i zbiorami plików (pliki z jednego lokalnego dysku są logicznie postrzegane jako zbiór). Oto podstawowe pojęcia, z których będziemy korzystać:
W systemie operacyjnym mamy do czynienia z co najmniej dwoma rodzajami nazw rozmaitych obiektów. Są to nazwy fizyczne, którymi posługuje się system operacyjny (umożliwiają mu one lokalizację danego zasobu) oraz nazwy logiczne, którymi posługuje się użytkownik (dają mu one wygodę posługiwania się danym zasobem). Co więcej często mamy do czynienia z wielopoziomowym nazewnictwem, np. wtedy gdy tekstowa nazwa pliku (nazwa logiczna) jest tłumaczona na jego wewnętrzny liczbowy identyfikator (nazwa fizyczna), który z kolei jest tłumaczony na adresy bloków dyskowych (nazwy fizyczne "niższego poziomu").
W wypadku DFS nazwa logiczna pliku powinna być przystępna dla użytkownika (najlepiej żeby nie różniła się od nazwy logicznej pliku lokalnego). Taka nazwa logiczna musi być tłumaczona na nazwę fizyczną, która musi umożliwiać ustalenie maszyny przechowującej ten plik oraz miejsce składowania tego pliku na tej maszynie. W wypadku gdy ma miejsce replikacja, to odwzorowanie nazwy logicznej na fizyczną powinno zwrócić zbiór lokalizacji replik.
Przezroczysty rozproszony systemów plików ukrywa przed użytkownikiem położenie pliku w sieci. W wypadku replikacji oczywiście zarówno istnienie jak i położenie replik jest ukryte przed użytkownikiem.
Możemy wskazać dwa aspekty tej przezroczystości.
Przezroczystość położenia polega na tym, że nazwa logiczna pliku nie ujawnia użytkownikowi fizycznego położenia składowiska, w którym ten plik jest przechowywany.
Niezależność od położenia polega na tym, że nazwa logiczna pliku nie musi być zmieniana w chwili przeniesienia go na inny dysk, nawet na innym komputerze. To oznacza dynamiczne odwzorowanie nazw logicznych na fizyczne, podczas gdy sama przezroczystość położenia, choć nie daje wiedzy o położeniu pliku, to jednak statycznie wiąże nazwę logiczną z konkretnym zbiorem bloków konkretnego dysku. Niezależność od położenia jest oczywiście cechą silniejsza niż przezroczystość położenia, ponieważ każdy schemat nazewniczy z niezależnością położenia musi mieć też przezroczystość położenia, ale nie odwrotnie.
Co więcej, niezależność od położenia pozwala na całkowite oddzielenie kwestii fizycznego położenia od nazwy logicznej. Oznacza to całkowitą i prawdziwą wirtualizację usługi systemu operacyjnego, jaką jest system plików. Oczywiście użytkownicy systemu z przezroczystością położenia ale bez niezależności od położenia też mogą tworzyć konwencje nazewnicze swoich plików, które w założeniu ukrywają ich położenie. Jest to jednak uciążliwe, ponieważ nazwy logiczne są wciąż powiązane z fizycznymi urządzeniami. Dopiero niezależność od położenia całkowicie eliminuje to powiązanie i umożliwia prawdziwe dzielenie przestrzeni dyskowej (skoro nie ma moich i twoich plików, bo nie wiadomo gdzie one są, to nie może być mojej i twojej przestrzeni dyskowej).
Istnieją trzy główne schematy nazewnicze w rozproszonym systemie plików.
Pierwszy z nich jest najprostszy ale wcale nie jest ani przezroczysty ani niezależny od położenia. Nazwa pliku stanowi w tym wypadku parę nazwa-maszyny:nazwa-lokalna. Te same operacje plikowe można stosować do plików lokalnych i zdalnych. Te kategorie plików różnią się tylko postacią nazwy, ale już nie sposobem dostępu. W takich warunkach łatwo też jest zapewnić globalną unikatowość nazw.
Drugie podejście jest elementem sieciowego systemu plików (NFS - Network File System), który jest obecnie dostarczany z każdym systemem UNIX i Linux. Polega ono na przyłączeniu katalogu na zdalnym komputerze do pewnego katalogu lokalnego. To daje wrażenie pracy w jednym spójnym drzewie katalogów, choć tak naprawdę przechodząc do takiego przyłączonego katalogu "przemieszczamy się" do lokalnego systemu plików innej maszyny. Przezroczysty dostęp dotyczy plików zdalnych znajdujących się w uprzednio przyłączonych katalogach. Oczywiście nie ma tu mowy o niezależności od położenia.
Trzecie podejście polega na stworzeniu całkowicie zintegrowanego systemu plików, w którym istnieje jedyna globalna przestrzeń nazw obejmująca wszystkie pliki na wszystkich maszynach. Wymaga to stworzenia dodatkowej zupełnie nowej struktury. Nie jest tak, jak w dwóch poprzednich podejściach, że w pewnym sensie korzystamy z udogodnień lokalnych systemów plików. W zamian otrzymujemy możliwość osiągnięcia niezależności od położenia.
Przechowywanie w pamięci podręcznej ostatnio pobranych i udostępnionych użytkownikowi bloków dyskowych rozproszonego systemu plików jest niezwykle ważne, ponieważ umożliwia zmniejszenie niezbędnej komunikacji sieciowej. W wypadku rozproszonego systemu plików ruch w sieci powoduje największe narzuty czasowe. Wielokrotne żądania dotyczące tych samych zdalnych plików mogą być dzięki temu obsłużone lokalnie.
Jeśli maszyna nie ma w pamięci podręcznej żądanych danych, to pobiera je z maszyny zdalnej i składa kopię tych danych w swojej lokalnej pamięci podręcznej. Wszelkie operacje dostępu są wykonywane na kopii z pamięci podręcznej. Każdy plik jest unikatowo utożsamiany ze swoją jedyną kopią główną przechowywaną na maszynie macierzystej. Może on mieć wiele kopii w pamięciach podręcznych różnych maszyn. Oczywiście powstaje tu problem spójności pamięci podręcznej, tzn. pytanie: "Czy nasza kopia z pamięci podręcznej jest wciąż aktualna?".
Gdzie lepiej składować taką pamięć podręczną? W pamięci operacyjnej? Na dysku lokalnym?
Przechowywanie na dysku lokalnym jest bardziej niezawodne, ponieważ modyfikacje danych nie są tracone w wypadku awarii. Po ponownym uruchomieniu komputera przechowane na dysku kopie plików zdalnych są wciąż dostępne i nie trzeba ich ściągać ponownie.
Przechowywanie w pamięci operacyjnej też ma wiele zalet. Można dzięki temu stosować bezdyskowe stacje robocze, a dostęp do danych jest szybszy. Pamięci operacyjne są coraz tańsze i większe, co zwiększa efektywność przechowywania podręcznego w pamięci operacyjnej. Na maszynie macierzystej plik i tak jest przechowywany podręcznie w pamięci operacyjnej (żeby przyspieszyć działanie serwera). Stosowanie u klientów przechowywania podręcznego w pamięci operacyjnej umożliwia uniwersalną implementację mechanizmów pamięci podręcznej na serwerach i u klientów. To wszystko dowodzi, że ta druga opcja jest wyraźnie lepsza.
Najprostsze i najbardziej niezawodne rozwiązanie to pisanie natychmiastowe, tzn. niezwłoczne nanoszenie na dysk zmian dokonanych w pamięci podręcznej dowolnego komputera. Ma ono jednak poważną wadę -- niską efektywność. Każda operacja pisania w pliku wymaga komunikacji sieciowej z serwerem i potwierdzenia, że zapis się udał. Komunikacja sieciowa jest zawsze wolniejsza od dostępu do dysku lokalnego. Widać więc, że tak zaprojektowany rozproszony system plików prawdopodobnie byłby odrzucony przez użytkowników.
Nieodzowne jest więc zastosowanie innej strategii-- pisania opóźnionego, przy którym zmiany są najpierw nanoszone na pamięć podręczną a dopiero później na serwerze. Dzięki temu zlecenie użytkownika polegające na zapisie do pliku kończy się szybko. Zauważmy jeszcze dodatkową korzyść: pewne zmiany w pliku są potem nadpisywane, więc nigdy tak naprawdę nie trzeba ich przesyłać na serwer. Niestety to podejście wiąże się z brakiem niezawodności -- awaria maszyny oznacza utratę wszystkich nie przekazanych modyfikacji.
Istnieją modyfikacje tej strategii. Pierwszą z nich jest okresowy przegląd -- pamięci podręczne są okresowo przeglądane (np. co 30 sekund) i w czasie takich przeglądów nanosi się zmiany na dyski serwera. Druga z nich to pisanie przy zamknięciu polegająca na zapisanie danych na serwer dopiero w chwili zamknięcia modyfikowanego pliku.
Ten problem jest związany z pytaniem: "Czy nasza kopia z pamięci podręcznej jest wciąż aktualna?" lub inaczej "Czy kopia danych na maszynie macierzystej jest zgodna z kopią na maszynie lokalnej?"
Poszukiwanie odpowiedzi na to pytanie może być złożone na barki klienta. Wówczas klient pyta serwer, czy jego kopia jest zgodna z kopią główną. Im częściej klient to robi, tym większa niezawodność, ale niższa wydajność. Można to sprawdzenie wykonywać przy każdym żądaniu dostępu, w określonych odstępach czasowych albo tylko przy pierwszym żądaniu.
Tą odpowiedzialnością można też obciążyć serwer. Serwer wie wówczas, jakie pliki są w pamięciach podręcznych klientów i wypadku modyfikacji tych plików serwer informuje klientów, że ich kopie są nieaktualne. Serwer może też monitorować żądania otwarcia plików do zapisu i wypadku konfliktu (otwarcia tego samego pliku do zapisu na co najmniej dwóch różnych maszynach), w ogóle zakazać stosowania pamięci podręcznej, co oznacza przejście do pracy w trybie obsługi zdalnej.
Obsługa zdalna oznacza komunikację z serwerem przy każdym dostępie do plików. Zobaczmy, jakie są wady i zalety pamięci podręcznej w porównaniu z obsługą zdalną.
Serwer stanowy dogląda swoich klientów i wie, jakie pliki są otwarte przez klientów. Gdy klient otwiera plik, serwer odczytuje odpowiednie informacje z dysku i przekazuje klientowi unikatowy identyfikator tego otwarcia pliku. Wykonując operacje na pliku, klient musi za każdym razem podać taki identyfikator. Serwer musi wykrywać awarie klientów i zwalniać pamięć zarezerwowaną na struktury danych utworzone na rzecz plików otwartych dla tych klientów.
Identyfikator otwarcia pliku pozwala na szybkie znalezienie informacji o pliku w pamięci operacyjnej serwera i zmniejszenie liczby niezbędnych dostępów do dysku. Serwer stanowy może też korzystać z pewnej wiedzy o trybie otwarcia pliku. Jeśli plik jest otwarty w trybie sekwencyjnym, serwer może zawczasu wczytać więcej bloków wiedząc, że zaraz będą potrzebne. To zwiększa jego wydajność, bo pozwala zagospodarować czas ewentualnej bezczynności, a pobranie naraz większej partii danych z dysku jest szybsze niż pobranie tych samych danych w mniejszych kawałkach.
Serwer bezstanowy nie przechowuje danych o klientach i połączeniach; uważa każde zlecenie za niezależne od innych. Każde zlecenie zawiera wskazanie pliku i pozycji. Nie ma więc potrzeby ustanawiania i zamykania połączeń.
W wypadku awarii serwer stanowy traci wszystkie informacje o połączeniach z klientami. Odtwarzanie stanu wymaga więc kontaktu sieciowego z klientami, w przeciwnym wypadku wszystkie operacje sprzed awarii są anulowane. Serwer musi też wykrywać awarie klientów, aby zwalniać pamięć zajmowaną przez struktury danych prowadzone na ich rzecz.
Awarii serwera bezstanowego klienci mogą nawet nie zauważyć. Serwer po ponownym uruchomieniu będzie normalnie obsługiwał każde nowe (przecież niezależne!) zlecenie.
Efektywność serwera stanowego jest znacznie lepsza, bo bezstanowość oznacza, że komunikaty z żądaniami muszą być dłuższe (każde żądanie musi zawierać pełną unikatową w systemie nazwę pliku a nie identyfikator otwarcia pliku) a przetwarzanie żądania jest wolniejsze (w pamięci operacyjnej nie ma żadnych struktur, które mogłyby coś przyspieszyć). Co więcej, serwer bezstanowy musi być zaprojektowany tak, aby ponawiane operacje miały taki sam efekt, jak pojedyncza operacja (w wypadku braku potwierdzenia ze strony serwera klient ponawia swoje żądanie). Trzeba więc zawsze posługiwać się bezwzględną odległością od początku pliku jako identyfikatorem umiejscowienia operacji.
Serwer obarczony odpowiedzialnością za spójność pamięci podręcznej musi być stanowy, ponieważ śledzi aktualność pamięci podręcznych klientów.
Uniksowy interfejs programistyczny do plików jest ze swej natury stanowy ze względu na deskryptory otwartych plików i niejawne adresy względne. Serwer musi pamiętać odwzorowanie na i-węzły i aktualne przesunięcie względem początku pliku.
Replikacja tego samego pliku na kilku niezależnych maszynach może zwiększyć efektywność dostępu do tego pliku. Zwiększa dostępność tego pliku (w wypadku awarii jednej z maszyn) oraz skraca czas obsługi.
Nazewnictwo plików musi obejmować dwa poziomy: wyższy i niższy. Na dostępnym dla użytkownika poziomie wyższym istnienie replik nie powinno być widoczne. Użytkownik odwołuje się po prostu do pliku jako logicznej jednostki informacji, a system udostępnia mu ją poprzez znalezienie "najbliższej" repliki. Poziom niższy (systemowy) musi rozróżniać repliki, żeby móc się nimi sensownie posługiwać i zarządzać.
Szczególny problem stanowi aktualizacja replik. Modyfikacja jednej z nich musi być odzwierciedlona we wszystkich pozostałych. Znów trzeba wybierać między efektywnością (opóźniona aktualizacja replik) a niezawodnością (aktualizacja natychmiastowa). Mamy tu do czynienia z podobnym problemem jak problem spójności pamięci podręcznej.
Można też rozważyć tzw. replikację na żądanie, która łudząco przypomina pamięć podręczną. Żądanie pobrania repliki nielokalnej powoduje ściągniecie danych z tej repliki i stworzenie repliki lokalnej. Od pamięci podręcznej to podejście różni się tym, że taka replika pozostaje "na zawsze", podczas gdy w wypadku pamięci podręcznej kopia lokalna jest usuwana, gdy nie jest już potrzebna.
W wykładzie 12 poznaliśmy zagadnienia związane z rozproszonym systemem plików. Taki system plików jest kolejnym etapem na drodze do wirtualizacji zasobów systemu operacyjnego. Daje użytkownikom wrażenie jednej przestrzeni składowania, mimo iż zawiera ona pliki przechowywane na odrębnych maszynach.
Dla użytkownika najlepiej byłoby, gdyby rozproszony system plików był całkowicie przezroczysty, tzn. żeby użytkownik nie musiał być świadomy rozproszenia systemu plików. Kluczową rolę odgrywa tu nazewnictwo plików. Istnieje wiele schematów nazewniczych, od zupełnie nieprzezroczystych (nazwą jest para adres maszyny i nazwa lokalna pliku) do całkowicie przezroczystych (istnieje jedna globalna przestrzeń nazw plików).
Efektywność rozproszonego systemu plików zwiększa się poprzez składowanie pobranych plików zdalnych w pamięciach podręcznych maszyn. Powoduje to pewne problemy związane z aktualizacją i spójnością pamięci podręcznej.
Serwer może być stanowy albo bezstanowy. Serwer stanowy czuwa na połączeniami ze wszystkimi klientami i śledzi otwierane przez nich pliki. Serwer bezstanowy nie przechowuje w ogóle takich informacji i traktuje każde żądanie jako odrębne.
Efektywność rozproszonego systemu plików można poprawić też poprzez replikację, czyli zwielokrotnianie tego samego pliku na kilku maszynach. Zwiększa to efektywność dostępu oraz podnosi odporność na awarie i dostępność.