Przesiadka na DFS

Przesiadka na DFS

  • Comments 4
  • Likes

DFS to dobra rzecz. I choć stwierdzenie to pasuje również do DFS rozumianego jako mechanizm replikacji, to tym razem mam na myśli zintegrowaną z domeną AD przestrzeń nazw. Dla nieświadomych szybkie przybliżenie tematu:

Tradycyjny dostęp do sieciowych zasobów plikowych realizowany jest w taki sposób, że są serwery, na serwerach udziały a klient sięga do konkretnego udziału na konkretnym serwerze. Czy sięgnie przez ścieżkę UNC (po nazwie albo IP) czy zamapuje dysk, to już nie ma większego znaczenia. W przypadku DFS, na serwerze publikowana jest przestrzeń nazw zintegrowana z domeną i udziały plikowe na poszczególnych serwerach podłączane są do "wirtualnej" ścieżki \\nazwa.domeny\nazwa_DFS\nazwa_udziału. Piękno tego rozwiązania polega między innymi na tym, że jeżeli podłączymy klienta do takiego udziału DFS, to możemy "pod spodem" dowolnie żonglować serwerami, udziałami i ścieżkami a klient zostanie automatycznie przekierowany we właściwe miejscie i nie zauważy żadnych zmian. Czyli na przykład łatwo wyobrazić sobie, że mając serwer z dziesięcioma udziałami sieciowymi, w miarę rozwoju firmy podzielimy go na dwa albo więcej serwerów, a klienci nic w codziennej pracy nie odczują. Oczywiście to samo możnaby uzyskać przemapowując wszystkie dyski na stacjach roboczych, ale przecież IT jest po to, żeby administratorzy nie musieli robić rzeczy żmudnych i nieciekawych.

W mojej prywatnej ocenie, mając DFS do dyspozycji (a jest on wspierany przez każdy współczesny system Windows) nie wypada z niego nie skorzystać. Kłopot jednak w tym, że w żywych środowiskach, tradycyjne sposoby dostępu do plików są tak rozpowszechnione, że tytułowa przesiadka na DFS wymaga "wyłapania" wszystkich sięgających przez \\serwer\udział i poprawienia ich konfiguracji. Wbrew pozorom może tego być sporo. Skrypty, polisy, mapowane dyski, skróty, odwołania w dokumentach... Tak więc zdecydowanie skuteczniejsze jest wykrywanie takiego dostępu po stronie serwera niż po stronie klientów. Oczywiście można wyłączyć tradycyjny udział i zobaczyć u kogo przestało działać, ale chyba nie jest to moja ulubiona metoda.

W efekcie, administrator chcący poważnie użyć DFSa w swoim środowisku musi sprawdzić, kto do jego serwera plików przychodzi przez DFS a kto bezpośrednio. Przyznaję się bez bicia, że zidentyfikowanie tego trochę mnie przerosło. Żadna znana mi metoda pozyskania informacji o nawiązanych połączeniach nie pozwala na rozróżnienie sposobu dostępu. Być może przegapiłem jakąś oczywistość (za wskazanie której będę oczywiście wdzięczny), ale nawet dłubiąc po API nie byłem w stanie odróżnić klienta przychodzącego do udziału X przez DFS od tych, którzy podłączyli się do niego "na skróty".

Poszedłem więc trochę inną drogą. Każdy udział serwera udostępniłem jeszcze raz, z sufiksem _dfs$. Czyli mając na początku \\serwer\home, \\serwer\biuro i \\serwer\magazyn zrobiłem dodatkowo \\serwer\home_dfs$, \\serwer\biuro_dfs$ i \\serwer\magazyn_dfs$. W konsolce zarządzającej DFS wyłączyłem odwołania do oryginalnych udziałów i dodałem te nowe. Można to zrobić "w locie" ponieważ operacja w żaden sposób nie jest zauważalna dla użytkowników. Teraz wystarczy "wmic /node:serwer path Win32_ServerConnection get ComputerName, ShareName, UserName" i już widzę z którego komputera jaki użytkownik sięga bez użycia DFS. Pozostaje tylko dojść, z czego taki dostęp wynika, poprawić i polować na kolejne.

Na końcu dostanę środowisko, w którym dostęp będzie opierać się w całości na DFS, co znacząco ułatwi mi kolejne zmiany. Choćby takie jak wyłączenie mocno wiekowego serwera plików.

Autor: Grzegorz Tworek [MVP]

Comments
  • Dwa krótkie pytanka:

    - cluster?

    - udostępniane zasoby są na zewnętrznej macierzy, czy na fizycznych dyskach serwerów?

    m.

  • Masz racje DFS jest fajny - do przezroczystej dla uzytkownika zmiany serwerow, sciezek etc

    ale... :D

    są problemy takie jak

    - uzytkownicy pracujacy na 1 pliku na 2 serwerach

    - limity dfs związane z replikacją, iloscią plikow etc.

    - integracja z oprogramowaniem do backupu (np netbackup przerywa replikacje)

    - dodatkowa ilosc miejsca potrzebna na katalog dfsprivate

  • Tu skupiłem się na DFS-N bardziej niż na replikacji. Replikacja jest też niezła, ale dokładnie tak, jak piszesz - ma poważne ograniczenia... nexor ostatnio sporo z replikacją walczył i jak Go znam, to na pewno rezultatami się podzieli.

  • Jest jakiś sposób, żeby udziały sieciowe z serwerów podłączać na różnych poziomach struktury DFS czy ciągle jest to możliwe wyłącznie do głównym poziomie?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment