początkowo założenie było takie:

  • na podstawie starych doświadczeń z DFSem i FRSem szybciutko postawię małą infrastrukturę
  • szybko przetestuję
  • napiszę panegiryk o tym jak wspaniała i wydajna jest to usługa.

miało być tak pięknie, a wyszło jak zwykle. może najpierw słowo wstępu dla tych, którzy z DFSem do czynienia nie mieli:

Distributed File System to [w skrócie] rozproszony system plików z redundancją. idea jest trywialna: definiuje się ‘namespace’ – czyli taki ‘share’, tyle że *nie* wskazuje on na konkretny katalog na konkretnym serwerze. jest wirtualnym tworem, pozwalającym zdefiniować wiele odnośników do kilku prawdziwych udziałów [shares] na serwerach. te kilka udziałów [konkretniej – dane przez nie wskazywane] są automatycznie replikowane/synchronizowane. w rezultacie użytkownik dostaje się pod określną nazwę typu “\domain.adfileserverABC” a system decyduje gdzie znajduje się najbliższy serwer i przekierowuje tam usera. jeśli serwer strzeli, to użytkownik zostanie [po jakimś czasie – to nie działa tak szybko jak klaster] przekierowany na inny, działający udział z tymi samymi danymi.

DFS powstał wraz z Windows 2ooo i wykorzystywał do replikacji usługę FRS – File Replication Services. cały system sprawował się świetnie w scenariuszach w sieci lokalnej, jednak ze względu na słabą wydolność FRS nie za dobrze radził sobie z replikacją przez sieć o słabych parametrach. największym problemem była wstępna replikacja – podczas której muszą zostać skopiowane wszystkie dane.

usługa z wersji na wersję była wzbogacana o nowe funkcjonalności. podstawową było zastąpienie FRS usługą DFSR [Distributed File System Replication] w Windows 2oo3 R2. podstawą ‘genialności’ i przewagi DFSR ma być wykorzystanie algorytmu RDC – Remote Differential Compression.

celem tego wpisu nie ma być deep-down DFSa [jeśli jest takie zapotrzebowanie to mogę taki cykl napisać] a raczej wyżycie się i wykrzyczenie na ten produkt. po raz kolejny eMeS pokazuje jak wspaniała idea i z definicji świetne narzędzie, może zostać spier*&ne i doprowadzić do białej gorączki. otóż po 3 tygodniach od utworzenia niemal najprostszej możliwej konfiguracji, nadal nie udało mi się zreplikować wszystkich danych. DFS jest jak księżniczka na ziarnq grochu – wystarczy pierdnąć w pobliżu serwera, żeby coś nie zadziałało prawidłowo.

scenariusz, jaki sobie wymyśliłem jest bardzo nieskomplikowany: chcę mieć HUB Server w centrali, na który replikowane są dane z serwerów branch-office’owych. te dane, będzie można łatwo zbackupować lokalnie. testy backupu przy pomocy Backup Exec Remote Agent były co najmniej niezadawalające – ponieważ kopia niezbyt dużej dawki danych trwała ok. tygodnia. zdalne serwery połączone są stosunkowo słabymi łączami 2/2MBps. DFS ze swoim wspaniałym DFSR korzystającym super-duper-hiper RDC wydawał się być lekiem na całe zło i nadzieją na system backupu. nie wspominając o oszczędności wynikającej z dużo mniejszej ilości licencji na BE Remote Agent.

Pierwszy fackup na jaki się natknąłem to [imho] beznadziejny model bezpieczeństwa. są dwa typy replikacji – ‘multipuprose’ oraz ‘data collection’:

image

o ile typ multipurpose wymaga zdefiniowania ‘namespace’ w którym będzie tworzyć się udziały, o tyle typ data collection tego nie wymaga – jest prostym wykorzystaniem DFSR do replikacji danych. jakie są limity:

  • w przypadku ‘multipurpose’ wymagane są uprawnienia ‘Domain Admin’ – name space rejestrowany jest w AD. nie da się wydelegować tworzenia name space – najpierw trzeba go utworzyć, potem można delegować. to ma jakiś sens, chociaż imho powinno dać się wydelegować możliwość utworzenia namespace. [hint –> być może da się ręcznie poustawiać ACL w AD?]
  • te same ograniczenia dotyczą ‘data collection’ z jedną dodatkową poważną głupotą… przy data collection nie jest tworzony name space, a mimo to może założyć go wyłącznie osoba z uprawnieniami Domain Admin!

DFSR, podobnie jak FRS faktycznie robi wpisy w AD i korzysta z niego jako ‘katalogu informacji’ – wystarczy spojrzeć do “CN=DFSR-GlobalSettings,CN=System,DC=domain,DC=ad” żeby zobaczyć, że są tam informacje o grupach replikacji i topologii. zakładając, że nie da się tego zrobić inaczej [dane muszą być w AD i nie można utworzyć DFSa w postaci AD-Free na member serverach] sprawdźmy dalej.

po utworzeniu prościutkiej topologii, synchronizującej pojedynczą strukturę katalogów, okazało się, że nie chce się replikować. w logach sporo błędów. nie trudno było trafić na art ‘top 1o common causes…’, i zlokalizować błąd konfiguracji: za mały rozmiar ‘stage folder’. ‘katalog tymczasowy’ dla DFSR musi mieć rozmiar co najmniej sumy 32 największych plików, które będą replikowane. na tym serwerze był to pewien problem, ale dało radę zrobić. to jednak w pewien sposób determinuje scenariusze wykorzystania DFS – raczej dla małych plików. jeśli na serwerze chcemy przechowywać duże pliki [video, backup, image] to ilość przestrzeni zarezerwowanej dla katalogu tymczasowego musi być olbrzymia. ciekawe, że głupie robocopy czy xcopy nie potrzebuje żadnej przestrzeni i działa prawidłowo – czy nie można wyliczyć hasha [czy co oni tam liczą] korzystając z żywego pliq? na blogu ludziqw tworzących DFS jest wręcz informacja: “idealnym stanem jest przyznanie katalogowi roboczemu wielkości równej sumy wszystkich plików". kiedy zapytałem owe osoby czemu takie wymagania – przecież to rozbój w biały dzień – oficjalne stanowisko jest “dyski są tanie, chcesz mieć DFSa to se qp większe”. hmmm…. chyba nie qpowali ostatnio ultra wide SCSI do trochę starszego serwera ani dysków do macierzy…

co jeszcze zwróciło  moją uwagę to interfejs – pod tym trywialnym GUI, gdzie wszystko robi się kilkoma kliknięciami, oraz wspaniałymi whitepapaerami opisującymi genialność usługi, kryje się całkiem sporo wymagań dla których step-by-step guide jest tylko początkiem drogi, a sama usługa może nie działać prawidłowo… z dość znacznej ilości powodów. owe top 1o prezentuje tylko najczęstsze błędy. prawdziwa jatka zaczyna się przy kłopotach z siecią.

pomimo prawidłowej konfiguracji wielkości katalogu roboczego i zniknięciu błędów 4ooo nadal dane nie repliqją się [po 2tygodniach mam 25GB z 4oGB], a logach pojawiają się błedy z kolejnego tysiąca: 5004 i 5014. pojawiają się w tej samej sekundzie – pierwszy mówi ‘straciłem połączenie’, drugi ‘odzyskałem połączenie’. najwyraźniej chwilowy problem z siecią poniżej 1sec wystarczy, żeby re
plikacja nigdy się nie wykonała. teraz pozostaje sprawdzenia co to za problem – skoro wykonanie xcopy nie powoduje zerwań sesji i redundancja na poziomie samego TCP wystarczy, żeby transmisji nie zerwać – czemu super-hiper-duper system replikacji stworzony z myślą o słabych łączach w biurach zdalnych, nie potrafi sobie poradzić?

póki co nie mam finalnej odpowiedzi na to pytanie. nie mogę niestety restartować serwera po kilka razy dziennie, żeby sprawdzić czy tuning parametrów TCP coś zmieni. a może trzeba stuningować całego DFSR?

i tak z prostego wizarda o kilq ekranach i trywialnej usługi zaprojektowanej do tego konkretnego zastosowania, okazuje się, że konfiguracja to modyfikacja masy parametrów na poziomie rejestru, które wpływają na wydajność całego systemu, podporządkowanie całego systemu jednej usłudze… kopiującej pliki!! 

a miało być tak pięknie…

eN.

-o((:: sprEad the l0ve ::))o-

Comments (7)

  1. peki

    Odpowiedz

    Trzeba było prestagować za pomoca robocopy dfsr-a podczas tworzenia – w odrożnienia od frs-a, dfsr calkiem dobrze sobie radzi z prestagowaneim. I nie trzeba czekac mesiaca aby prestagowanie sie skończyło, czasami już po kilku dniach wszystko działa : )

  2. Odpowiedz

    a u mnie działa :)
    co prawda FRS a nie DFSR do zdalnej lokalizacji po naprawdę kijowym łączu, kopiowana jest część struktury serwera plików, ale to działa i ma się dobrze, nie odnotowaliśmy [odpukać] żadnych problemów. lokalnie też działa

  3. prymek

    Odpowiedz

    Kolejny, po cyklu „smartfon dla firmy”, bardzo dobry tekst. Przewodniki „krok po kroku” i opisy uruchomienia usługi w warunkach laboratoryjnych to jedno, a rzeczywistość to często co innego.
    Jeśli podobne doświadczenia masz/będziesz miał z DirectAccess, to ja chętnie poczytam, bo mi się te życiowe wpisy bardzo podobają.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Time limit is exhausted. Please reload CAPTCHA.