Microsoft Windows DFS

Materiały dla prelegenta

DFS - co to jest?

Firma Microsoft wraz z nadejściem systemu NT 4.0 wprowadziła na rynek nowy „system plików”. Motto, które towarzyszy temu systemowi można zobaczyć na pierwszym slajdzie.

Wprowadzenie – cd.

Zajmijmy się analizą sytuacji przed wprowadzeniem DFS, czyli, po co on w ogóle jest potrzebny? Dostęp do zasobów w sieciach opartych, na Windows opiera się na stosowaniu konwencji UNC: \\serwer\sciezka do zasobu.

Powoduje to niestety konieczność pamiętania przez użytkownika, administratora dużej ilości zbędnych informacji dotyczących ilości serwerów z danymi, ich nazw, nazw udostępnionych udziałów, itp. Ponadto użytkownik dla swojej wygody mapuje te zasoby na stałe jako kolejne dyski w swoim systemie, ta metoda też ma wady ze względu na ograniczoną ilość liter w alfabecie. Jednym słowem nie jest to najszczęśliwsze rozwiązanie, szczególnie w porównaniu z rozwiązaniami stosowanymi z sukcesem przez innych producentów.

Microsoft doszedł do wniosku, że coś należałoby zmienić.

DFS – założenia

Wymyślono, żeby na istniejąca strukturę fizyczną sieci wraz z dotychczasowym rozwiązaniem udostępniania zasobów nałożyć jakąś logiczną nakładkę, która pozwoli na łatwiejszy dostęp do danych i uwolni korzystających z myślenia o fizycznej strukturze sieci. Tak właśnie powstała koncepcja DFS.

Koncepcja jednego drzewa zasobów w sieci, które spinałoby wszystkie udostępnione zasoby w jedna strukturę.

DFS – „ładny” rysunek

Tutaj widać mniej więcej, co chcemy uzyskać. Po prawej stronie jest widok od strony użytkownika, dla którego jest to pojedyncze drzewo plików, folderów ( a informacja o fizycznej strukturze jest niewidoczna).

Natomiast po prawej stronie widać jak to jest zorganizowane od strony administratora. Kolejne foldery są tak naprawdę zamapowanymi udziałami z innych serwerów. Informacja ta jest dostępna tylko administratorowi. Dla niektórych zasobów (\\public\users\bob) widać, że jest możliwość dublowania udziałów, co to znaczy o, po co to jest zaraz zostanie objaśnione.

DFS – cechy i zalety

To jest lista niewątpliwych zalet, którymi się szczyci Microsoft. Jak się okaże w trakcie prezentacji część z nich jest zbyt szumnie nazwana atutem, bądź nowoczesnym rozwiązaniem. Słuchaczom znającym system AFS, powinna się narzucić duża zbieżność w zakresie terminologii, jak również przyjętych założeń.

Widać, że projektanci wzorowali się na tym systemie w wielu aspektach, ale niestety większość z nich potraktowali „po łebkach”.

- jednolita struktura – chodzi o to, że teraz wszystkie dane są dostępne w jednym drzewie, dzięki temu ułatwiamy pracę użytkowników

- przejrzystość nazw – użytkownicy teraz nie muszą pamiętać nazw wszystkich serwerów w sieci i udostępnionych udziałów

- elastyczne zarządzanie przechowywaniem – teraz administratorzy mogą w łatwy sposób dodać dodatkowe woluminy dyskowe, zwiększyć pojemność dysków, folderów, zmienić organizację fizyczną sieci, a wszystko to w niezauważalny sposób dla użytkownika

- administracja graficzna – interfejs graficzny dla administratora- to nie wymaga komentarza

- dzielenie obciążenia – możliwość podłączenia „lustrzanych” udziałów do jednego miejsca w gałęzi drzewa DFS, dzięki temu klient losowo wybiera udział z którego korzysta, dzięki temu równoważymy obciążenie (ale żeby nie było zbyt pięknie to więcej na ten temat będzie później)

- dostępność – dzięki wykorzystaniu „mirrorów” z poprzedniego punktu w przypadku awarii jednego serwera, użytkownik automatycznie przełączy się na korzystanie z drugiego serwera, zatem nie dotyczą już go również awarie serwerów

- integracja zabezpieczeń – tutaj Microsoft lekko przesadził, pisze o listach ACL, kontroli dostępu, a tak naprawdę jej nie oferuje. Więcej na ten temat będzie trochę później, ale nie wygląda to tak różowo....

- inteligentne buforowanie na kliencie – inteligencja klienta i jej wpływ na odciążenie serwera i sieci, zostanie później opisana dokładnie, więc pozwolę sobie drogiego słuchacza jeszcze chwilę potrzyma w niepewności

- wsparcie dla starszych platform Win9x – to jak rozumiem również nie wymaga komentarza szczególnie w sieciach heterogenicznych :-)

- interoperatywnośc z innymi sieciowymi systemami operacyjnymi – dzięki interoperatywności z innymi sieciowymi systemami operacyjnymi do drzewa DFS możemy podłączyć co tylko nam się podoba jednak pod warunkiem, że:

* to coś wspiera SMB jako protokół wymiany danych :-)

* lub Windows 2000 posiada interfejs do tego „czegoś” i może pełnić rolę pośrednika pomiędzy „tym czymś” i DFS

DFS – wady?

Kilka wad ten system rzeczywiście ma, szerzej zostaną one opisane w dalszej części tej prezentacji. A na końcu podsumowane.

DFS- jak to działa?

DFS jest zbudowany w architekturze klient-serwer. Usługa serwera jest uruchamiana na serwerze Windows NT lub Windows 2000. Dodatkowo jest zainstalowana konsola administracyjna. Po stronie użytkownika nie zmienia się nic. Zasoby dalej są dostępne przy zastosowaniu konwencji UNC, tylko zamiast nazwy serwera używa się nazwy węzła DFS.

DFS – od strony serwera

Usługa serwera DFS, może zostać zainstalowana w dwóch trybach: autonomicznym lub w domenie. Sposób instalacji a zarazem wersja DFS zależy od wersji systemu operacyjnego serwera, który będzie serwerem DFS. Starsza wersja DFS 4.x jest instalowana na serwerach NT 4.0. Na takim serwerze dane konfiguracyjne są przechowywane w rejestrze. Istnieje możliwość skonfigurowania tylko jednego drzewa w ramach jednego serwera NT udostępniającego usługę DFS. Nowsza wersja DFS została oparta o system operacyjny Windows 2000. W tym przepadku dane o konfiguracji są przechowywane w Active Directory. AD nie narzuca ograniczeń do jednego wystąpienia drzewa w strukturze, dlatego przy pomocy AD można rozpropagować wiele struktur DFS w ramach organizacji. Jak widać w tej implementacji usługa DFS nie jest ściśle przypisana do jednego serwera i zależna od jego kondycji. Tutaj informacja o drzewach DFS jest przenoszona wraz z AD, a więc jest dostępna w każdym miejscu gdzie jest dostępny kontroler domeny Windows 2000.

Drzewo DFS składa się z szeregu liści, które są następującego rodzaju:

InterDFSlink – to są poprostu linki łączące liść w drzewie DFS z jakimś zasobem na innym serwerze

Midlevel junction – podobno jeszcze nie zaimplementowane, choć po przeanalizowaniu algorytmu mapowania ścieżki DFS na prawdziwy zasób wygląda na to, że to już działa. W każdym bądź razie chodzi o to, że dzięki midlevel junction możemy stworzyć strukturę następującego typu(patrz rysunek za dwa slajdy).

\\serwer\public\intranet -> \\IIS\Root\Content

\\IIS\Root\Content\CorpInfo -> \\Marketing\Info\Corporate.html

chodzi o to, żeby nie było takich skoków z jednego serwera na drugi, tylko, żeby w DFSie można było przechowywać informację o mapowaniu każdego liścia (nawet takim pośrednim), czyli żeby na poziomie DFSa była informacja, że: \\serwer\public\intranet\CorpInfo -> \\Marketing\info\Corporate.html. Ma to za zadanie przyspieszyć proces wyszukiwania.

Alternate volumes – repliki, czyli lustrzane foldery, które można podczepić w to samo miejsce struktury, niestety DFS nie ma mechanizmów pozwalających na kontrolę spójności danych, ma ją tylko systemowa replikacja

Downlevel volumes – są to takie liście, które nie mogą być już dalej zagnieżdżone. Przykładem tu może być udział Netware, który da się zmapować, ale ze względu na różnice protokołów, możemy korzystać z danych, ale nie możemy zaimplementować wszystkiego co nam daje DFS, zatem taki liść został naznaczony.

PKT (Partition Knowledge Table) – informacja o połączeniach, jest to prosta tablica zawierająca pary liść drzewa DFS, jego mapowanie, więcej na ten temat za kilka slajdów

Kontrola dostępu do zasobów – tak jak już wcześniej wspomniałem Microsoft szczyci się poważnymi zintegrowanymi zabezpieczeniami. Bezpieczeństwo dostępu opiera się na listach ACL. Ale nie daje tak pełnej funkcjonalności jak byśmy się spodziewali, więcej na ten temat za kilka slajdów

DFS – ładny rysunek po raz drugi

Tutaj można jeszcze raz omówić wszystkie rodzaje obiektów w drzewie DFS na podstawie wcześniejszych informacji.

PKT – serwer cd.

PKT, prosta tablica przechowywująca informację o mapowaniach, oprócz pary liść – mapowanie, przechowuje również informacje o czasie wygaszania TTL.

Tablica PKT jest przechowywana zarówno na serwerze (rejestr, AD), jak również na stacjach klienckich (cache w RAMie). Na kliencie wszystkie mapowania rozwiązane przez serwer są przechowywane w lokalnej tablicy, i przy następnym odwołaniu do zasobów w pierwszej kolejności są stąd pobierane. Żeby uniknąć przedawnienia danych został wprowadzony czas TTL, po którym dane te znikają z bufora lokalnego i wtedy jeśli klient będzie chciał skorzystać z danego mapowania, musi jeszcze raz o nie zapytać serwer DFS.

DFS – mapowanie nazw logicznych do adresów fizycznych

Algorytm jest dość dobrze pokazany na slajdach, więc tutaj się ograniczę do opisu uzupełniającego. Klient zwraca się do serwera o rozwiązanie nazwy logicznej, serwer szuka najdłuższej ścieżki którą posiada w swojej tablicy, PKT i podstawia ją jako część ścieżki do zasobu, wynik zwraca klientowi DFS. Klient otrzymuje mapowanie do fizycznego zasobu.

Jak to jest w przypadku replik? Jeśli mamy starszą implementację DFS (NT) to serwer DFS zwróci listę replik, które są podłączone do danej ścieżki logicznej. Klient DFS wybierze losowo jedną z replik z listy i spróbuje się z nią połączyć. Jeśli mamy nowszą implementację DFS (W2K), to serwer zwróci dwie listy. Pierwsza lista (priorytetowa) zawiera repliki, które są w tym samym segmencie sieci, co klient DFS (ip + maska sieci), natomiast druga lista będzie zawierała wszystkie pozostałe repliki. Klient, będzie wybierał losowo repliki najpierw z listy priorytetowej, a następnie z drugiej listy, aż mu się z sukcesem uda podłączyć do jednej z replik. Dzięki takiemu rozwiązaniu, klient w pierwszej kolejności zawsze będzie się starał korzystać z replik znajdujących się „blisko” niego.

Przełączanie pomiędzy replikami w przypadku awarii

Scenariusz pierwszy

Klient przegląda zasoby, nagle serwer „znika” z sieci, awaria prądu, interfejsu sieciowego. Klient po jakimś czasie (zależnym od protokołu sieciowego, odległości, WAN, LAN i innych ustawień) zorientuje się, że serwer jest fizycznie niedostępny. Rozpocznie wtedy procedurę przełączania się na inną replikę, w tym celu przegląda lokalną tablicę PKT i szuka w niej wpisów replik, jeśli znajdzie próbuje się połączyć, jak nie znajdzie to prosi serwer DFS o listę replik, jak ją dostanie, to próbuje się połączyć, jeśli jej nie dostanie to zwróci błąd (i ten błąd otrzyma również użytkownik)

Jeśli uda się znaleźć replikę to klient podłączy się od razu do nowej, użytkownik zobaczy wtedy nową zawartość folderu, (jeśli były one zsynchronizowane to pół biedy, ale serwer DFS nie dba o sprawdzenie tego faktu...)

Scenariusz drugi

Podobnie jak w pierwszym, tylko serwer z udziałami nagle przestaje udostępniać dany zasób, bo ma awarię jednego z dysków, ktoś zmienił uprawnienia etc.

Klient od razu stwierdza, że zasób jest niedostępny i rozpoczyna procedurę przełączania ze skutkami jak powyżej

Scenariusz trzeci i czwarty

Są one analogiczne do poprzednich, tylko dochodzi założenie, że klient nie tylko przegląda zawartość zasobów, ale również ma otwarty plik.

W tym momencie ze strony DFS procedura wygląda dokładnie tak samo, natomiast cała odpowiedzialność za prawidłowe zachowanie się w momencie utraty kontaktu z plikiem leży po stronie aplikacji na kliencie, która z pliku korzysta. Podobnie DFS nie obsługuje zadnych blokad, znaczników otwarcia plików itp., ta odpowiedzialność jest po stronie systemu plików.

Zabezpieczenia

Tak jak już wcześniej wspomniałem, DFS jest chroniony listami ACL, zawierającymi dość dużą możliwość konfiguracji zabezpieczeń. Nie będę się tutaj rozwodził o listach ACL, bo zakładam ich znajomość u czytająccego. Natomiast chciałbym powiedzieć, że mechanizm autoryzacji w Windowsach jest dwustopniowy. Pierwszy jest na poziomie udziałów, tzn. dając komuś prawa do czytania udziału, mamy tylko i wyłącznie pewność, że on zobaczy ten udział, nic więcej na temat zawartości i dostępu do niej nie możemy powiedzieć. Dlatego, że drugi stopień autoryzacji jest na poziomie zasobów (katalogi, pliki w systemie) i administracja nim leży po stronie serwera z udziałami. Zarządzanie w DFS pozwala tylko przypisywać prawa tylko udziałom, nie ma możliwości z poziomu DFSa zarządzać na poziomie zasobów, więc określenie docelowych praw zależy i tak tylko i wyłącznie od administratora danego serwera zdalnego. Nie ma możliwości dziedziczenia praw z DFSa w głąb nawet, jeśli jest to ten sam obszar administracyjny z tymi samymi prawami.

Architektura i opis bibliotek

Architektura jest dosyć przejrzysta, bardziej szczegółowe dane oczywiście są niedostępne. Dla ewentualnych programistów jest dostępna biblioteka netapi32.dll oferująca interfejs do DFS, przy pomocy którego można zarządzać drzewem DFS. To na wypadek gdyby ktoś chciał napisać własny program do zarządzania.

Algorytm działania raz jeszcze

Jak widać klient i serwer DFS do rozwiązywania nazw i „”dogadania się” używają RPC, natomiast do samej wymiany danych protokołu SMB. Pokazane na slajdzie 4 biblioteki, są to w zasadzie najważniejsze biblioteki odpowiedzialne za całą komunikację.

Jest tutaj powtórzony cały algorytm komunikacji, ale sądzę, że po wcześniejszych objaśnieniach nie wymaga on więcej komentarza.

Podsumowanie – zalety

Zebrałem listę niewątpliwych zalet, jest ona bardziej okrojona niż ta z Microsoftu, która została zaprezentowana na początku. Uważam, osobiście, że DFSa można i da się używać, ale nie koniecznie do takich górnolotnych zastosowań jak proponuje Microsoft. Jest on natomiast bardzo dobry, jeśli chodzi o ułatwienie pracy użytkownikom końcowym w sieci.

Podsumowanie – wady i zalety

Nazwałem tak ten slajd, bo wg mnie nie wszystko to, co Microsoft podaje jako zaleta jest nią rzeczywiście, dla mnie są małe wady.

Tak jak już wcześniej wspomniałem mamy słabą możliwość globalnego zarządzania zabezpieczeniami, replikacja świetnie się nadaje do statycznych danych, które będą raczej na 100% spójne. Algorytm replikacji, jest bardzo mało zaawansowany, kopiuje tylko całe pliki, w przypadku konfliktu wygrywa najświeższy plik, są zaimplementowane 30 minutowe stemple czasowe. Łatwo jest zauważyć, że nie można go wykorzystać w środowisku, gdzie wiele osób mogłoby na różnych replikach edytować te same dane, ponieważ nie można zagwarantować ich spójności. Równoważenie obciążenia jest również mocno okrojone, tylko do losowego przydziału do replik. Nie stosuje zadnych algorytmów opartych na sprawdzaniu właściwego obciążenia poszczególnych serwerów w oparciu o: zliczanie sesji klienckich, czasu trwania sesji, czy obciążenia).

DFS – zastosowania wg Microsoftu

Tu nie będę zbytnio komentował jest to obrazek zaczerpnięty z dokumentacji (pozycja 2). Wnikliwy obserwator po zapoznaniu się z wadami i zaletami DFSa z tej prezentacji sam będzie w stanie odnaleźć wąskie gardła takiego rozwiązania.

Materiały

Autor prezentacji, oprócz wymienionych materiałów korzystał również z własnych doświadczeń. Tak się akurat złożyło, że miałem możliwość wdrożyć i potestować DFS na żywym organizmie. W przypadku jakichkolwiek pytań służę informacjami.

Tomasz Chudzik

T.chudzik@students.mimuw.edu.pl