Windows DFSR - Zmieniono uprawnienia do replikowanego katalogu, a teraz ma ponad 350 000 zaległości na ponad tydzień

Pytanie: Czy istnieje sposób, aby przyspieszono uzupełnienie tego 350 000 plików? Dla prawie każdego pliku jedyną zmianą była zmiana listy ACL dla każdego pliku, którego dotyczy problem. Niektóre pliki zmieniły treść, ale nie jest to częsty przypadek w tej sytuacji.

To może zostać naprawione. Zredaguję ten tekst, aby potwierdzić sukces / porażkę po pewnym czasie i weryfikacji. Pod koniec tego pytania szczegółowo opisałem ostatnio wprowadzone zmiany, które mogły go naprawić.

Mamy grupę replikacji DFSR z około 450 000 plików i zajmuje 1,5 TB miejsca. W tej sytuacji istnieją dwa serwery Windows Server 2008 R2, które są oddalone od siebie o około 500 mil. Istnieją inne serwery, ale nie są one zaangażowane w tę grupę replikacji. Serwer ALPHA to główny serwer, z którego korzysta większość pracowników. Serwer BETA to serwer w zdalnym biurze i jest mniej zajęty.

Oto wykres zaległości dla tej grupy replikacji (PNG hostowany na Dysku Google) pokazujący postęp powolnej synchronizacji.

Musiałem usunąć wpis uprawnień, który był w katalogu głównym tej grupy replikacji, który oczywiście został odziedziczony w większości podfolderów. Wprowadziłem tę zmianę na serwerze ALPHA. Zaraz potem DFSR miał 350 000 zaległości w plikach. Minęło ponad tydzień, a teraz jest to 267 000. Jedyną rzeczą, która zmieniła się (początkowo) była zmiana pojedynczego uprawnienia.

Tak się stało (to nie jest rozwiązanie, tylko kolejne wyjaśnienie tego, co stało się przyczyną tego problemu): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -ponieważ-to-okazuje się-piątek-noc-był-w porządku-do-walki.aspx # dfsr

Wszelkie zmiany zachodzące na serwerze BETA są bardzo szybko replikowane na serwerze ALPHA, ponieważ w tym kierunku nie ma zaległości. Wszelkie pliki zmienione w BETA bez problemu trafiają do ALPHA.

Replikuje 24/7 z pełną prędkością na jednym końcu połączenia 50 Mb / s na światłowodzie 100 Mb / s na drugim końcu. Obszar przemieszczania wynosi 100 GB na każdym serwerze. W dziennikach zdarzeń nie ma nic interesującego. Istnieje niepowiązane zdarzenie wysokiego znaku wodnego, które pojawia się dla niepowiązanej grupy replikacji, która nie jest ani dla tej konkretnej replikacji, ani dla tej pary serwerów ALPHA / BETA. W szczególności nie ma wpisów w dzienniku zdarzeń dotyczących wysokiego znaku wodnego ani błędów połączenia.

Widok ALPHA na grupę replikacji:

Oszczędności przepustowości : redukcja 99,83% (replikacja 30,85 MB zamiast 18,1 GB)

Uważam, że 30,85 MB / 18,1 GB wydarzyło się od ostatniego uruchomienia usługi DFSR na platformach ALPHA i BETA. Jeśli tak, to pokazuje, że chociaż zajmuje to bardzo dużo czasu (dłużej niż uważam, że powinno to zająć), tak naprawdę nie przenosi zawartości pliku przez drut.

Replikowany folder : 1,46 TB (rzeczywisty rozmiar), 439 387 (pliki), 52 886 (foldery)

Folder konfliktów i usunięć: 100,00 GB (rozmiar skonfigurowany), 34,01 GB (rozmiar rzeczywisty), 19620 (pliki), 2393 (foldery)

Folder przemieszczania: 200,00 GB (rozmiar skonfigurowany), 92,54 GB (rozmiar rzeczywisty)

Wystąpił jeden błąd wysokiego znaku wodnego w dziennikach (14 maja, 19:00) i dlatego podniosłem limit miejsca do 200 GB ze 100 GB. Wiem, że zatwierdzona przez Microsoft trasa ma wzrosnąć o 20%, ale nie bawię się tym. Mamy dużo miejsca na dysku do macierzy dyskowych.

Wyłączenie antywirusa na wszystkich serwerach nie pomogło, choć myślałem, że trochę by pomogło. Na razie mam ponownie włączony program antywirusowy, ale ustawiłem ścieżkę grupy replikacji do wykluczenia ze skanowania w celu usunięcia tej zmiennej z równania.

Czy istnieje sposób, aby przyspieszyć? Chciałbym tylko dokonać tej zmiany na serwerze BETA, jak również, ale są pliki, które zostały zmienione na ALPHA ale nie replikowane do beta i poprzez odziedziczone zmiana zezwolenia na BETA doprowadziłaby STARE plików z Beta Alpha (bo zdaje się DFSR ignoruj ​​znaczniki czasu pliku podczas porównywania, który plik jest zwycięzcą w kolizji). A gdyby tak się stało, byłoby to raczej złe.

Zaległości powoli zmniejszają się. Bardzo, bardzo powoli. Ale idzie naprzód. Ale w tym tempie miną tygodnie, zanim się skończy. Zastanawiam się, czy po prostu wrzucić kopię zestawu danych na dysk 3 TB i wysłać ją do zdalnego biura. Czy jest lepszy sposób?

16 maja, 4 rano US PT: Co mogło rozwiązać problem (przy założeniu, że i tak jest naprawiony):

Wprowadziłem wiele zmian w DC, które powinny były zostać wprowadzone dawno temu. Problem polega na tym, że ta sieć została odziedziczona od kogoś, kto prawdopodobnie odziedziczył ją od kogoś innego itp. Nie mogę obiecać, która zmiana rozwiązała problem. Tutaj nie są w określonej kolejności:

• Wszystkie kontrolery domeny nie znajdowały się w jednostce organizacyjnej „Kontrolery domeny”. Nigdy nie widziałem domeny Windows, która miałaby swoje kontrolery domeny gdzie indziej. Przeniosłem je z powrotem do miejsca, gdzie należały. Poprzednio znajdowali się w jednostkach organizacyjnych, które były posegregowane według nazwy miasta, w którym znajduje się każde biuro. (Mam wrażenie, że mam teraz trochę pracy z hydrauliką, kiedy je przeniosłem, ale obecnie wszystko wydaje się w porządku ...)
• Program AVG Anti-Virus działa na wszystkich kontrolerach domeny i serwerach uczestniczących w DFSR. Wyłączyłem foldery replikowane i foldery przemieszczania ze skanowania aktywnego / dostępowego. Nie sądzę, że to rozwiązało problem i prawdopodobnie przetestuję go później, aby sprawdzić, czy cofnięcie tej zmiany wpłynie na szybkość replikacji DFSR. To wyzwanie na kolejny dzień.
• dcdiag.exe narzekał na problem DNS dotyczący kontrolerów RODC. Rozwiązałem ten problem, mimo że w ogóle nie mamy kontrolerów RODC w domenie. Wątpię, żeby to cokolwiek naprawiło.
• Brak jednego z _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV brakowało dla jednego z kontrolerów domeny (nie jednego z serwerów DFSR) i naprawiłem to. Nie sądzę, żeby to pomogło.
• Raz zrestartowałem serwer BETA, narzekał na złe zamknięcie bazy danych DFSR (zdarzenie 2212), a następnie odbudowanie bazy danych trwało kilka godzin. Po zakończeniu zgłosił zdarzenie 2214, aby poinformować mnie o zakończeniu. Następnie replikacja nadal działała bardzo wolno, ale mogło to pomóc w odklejeniu wszystkiego, co utknęło.
• Jeden z kontrolerów domeny nie miał 127.0.0.1 jako dodatkowego serwera DNS w konfiguracji interfejsu. Dodałem to. To nie był jeden z serwerów DFSR, więc prawdopodobnie nie miało to z tym nic wspólnego.
• Postępowałem zgodnie z blogiem TechNet: Strojenie wydajności replikacji w DFSR zalecane ustawienia rejestru dla serwerów DFSR. Użyłem wszystkich „przetestowanych wartości wysokiej wydajności”, z wyjątkiem tego, że AsyncIoMaxBufferSizeBytes ustawiono na 4194304, czyli o jeden stopień niżej niż wartość wysoka. To mogło pomóc w rozwiązaniu problemu ... a może nie. Trudno powiedzieć, kiedy zmienia się zbyt wiele zmiennych.
• dcdiag.exe narzekał na problem z komunikacją z usługą RPC na BETA, ale dopiero po wprowadzeniu powyższych zmian. Wydawało się, że jest to najbardziej prawdopodobny problem, ale nic nie zrobiłem, aby to naprawić. VPN działał poprawnie i zapora sieciowa go nie blokowała. Możliwe, że jeden z powyższych elementów spowodował, a następnie naprawił problem RPC, lub mógł to być zwykły zbieg okoliczności. Ten błąd nie pojawia się teraz, a replikacja działa teraz płynnie.

Morał tej historii jest taki: zmieniaj jedną rzecz na raz, inaczej nigdy nie dowiesz się, co to naprawiło. Ale byłem zdesperowany i zabrakło mi czasu, aby to naprawić, więc wystrzeliłem po prostu kilka kul na ten problem. Jeśli kiedykolwiek znajdę poprawkę, zgłoś to tutaj. Ale nie polegaj na mnie, że to zawężam.

EDYCJA 21.05.2012: Rozwiązałem to, jeżdżąc wczoraj przez około siedem godzin z zapasowym serwerem (GAMMA) do zdalnego biura. GAMMA działa teraz jako główny lokalny serwer, podczas gdy ich zwykły serwer (BETA) nadrabia zaległości w replikacji. Odkąd go umieściłem, serwery podwoiły prędkość replikacji. Chociaż mówi mi to, że może to być problem związany z VPN, jestem mniej skłonny wierzyć, że dzieje się tak, ponieważ wszystkie nowe aktualizacje zdają się replikować do GAMMA od ALPHA i działały bardzo szybko.

EDYCJA 22.05.2012: Teraz jest na 12000 i powinno być skończone za kilka godzin. Zamieszczę ładny wykres postępu od powolnego startu do szybkiego zakończenia. Problem polega na tym, że jedyną rzeczą, która tak naprawdę „naprawiła”, jest połączenie z lokalnym serwerem. Obecnie myślę, że może VPN stanowi część problemu. A jeśli tak, wydaje mi się, że na to pytanie jeszcze nie ma odpowiedzi. Po tym, jak miałem trochę więcej czasu, aby sprawdzić, jak się replikuje za pośrednictwem sieci VPN i widząc jakiekolwiek awarie, debuguję i raportuję postępy.

Jeśli coś się zmieni, zaktualizuję tutaj.

Bardzo dziwny problem, szczególnie po przejrzeniu edycji.

Sprawdziłbym dziennik debugowania DFSR, który znajduje się tutaj:% systemroot% \ debug Domyślnie powinno być 9 poprzednich plików dziennika, które zostały zarchiwizowane w GZ, i jeden, który jest obecnie zapisywany.

Otwórz to w pliku tekstowym i wyszukaj tekst „ostrzeżenie” lub „błąd”. Możesz sprawdzić tę serię blogów, aby uzyskać bardziej szczegółowe informacje na temat dzienników debugowania: http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1- Logowanie-poziomy-log-format-guid-s.aspx

Inne pytania / sugestie:

Czy patrząc na monitor zasobów jest coś nie na miejscu? Nadmiar aktywności dysku twardego lub procesora, który jest poza poziomem odniesienia?

Jeśli to możliwe, zrestartuję oba serwery Alpha i Beta. Jeśli to rozwiązuje problem, być może nigdy nie wiesz, jaki był prawdziwy problem, ale jeśli krytyczne jest, że problem zostanie wkrótce rozwiązany, warto spróbować.

Edytuj w oparciu o aktualizację pytania

Wspomniałeś o dwóch wpisach związanych z plikiem 850 MB, a także o błędzie w dzienniku debugowania DFSR.

Czy możesz spróbować zmienić lokalizację przemieszczania na inny folder lub dysk na każdym serwerze? W przypadku, gdy aktualnie przetwarzane pliki są uszkodzone lub w jakiś sposób blokują replikację.

Możesz dostosować harmonogram replikacji, aby umożliwić DFS-R replikację z pełną prędkością w czasie wolnym (lub nawet w godzinach, jeśli to konieczne).

Możesz także spróbować zwiększyć rozmiar przemieszczania na serwerze z tylnym logowaniem. Powinno to zwiększyć wydajność w tej sytuacji.

Nie wspominasz, czy jest on ograniczony, ale zakładam, że tak, ponieważ masz replikację w sieci WAN.

Z mojego doświadczenia wynika, że ​​to właśnie tak działa.

Natknąłem się na to po aktualizacji zabezpieczeń w dość małej kolekcji 4 grup replikacji DFS (550 GB danych, 58 tys. Plików, łącznie 3,4 tys. Folderów). Dane faktycznie przesyłane przewodowo są niskie, więc wydaje się, że nie przenoszą one całych plików tylko ze względu na zmiany bezpieczeństwa, ale aktywność dysku wydaje się, że cała hierarchia jest kopiowana - utrzymywane prędkości transferu dysku między 60-100 MB / s, a kolejki dysków 30, osiągając maksimum 500 na warstwowej przestrzeni dyskowej SSD.

Wydaje mi się, że DFS ma dużą zmienność w procesie przemieszczania i destrukcji, co powoduje ekstremalne operacje We / Wy dysku. Początkowy proces replikacji między dwoma gigabitowymi urządzeniami podłączonymi do sieci LAN zajmuje wiele razy więcej czasu niż te same dane, po prostu plik kopiowany między urządzeniami, co wydaje się wskazywać, że każdy replikowany bajt wymaga wielu bajtów odczytu i zapisu na dysku.

Wydaje się, że aktualizacje zabezpieczeń nie mają żadnej specjalnej logiki replikacji, która uniemożliwia korzystanie z zabezpieczeń opartych na oświadczeniach z 2012 r. (Które nie są powszechnie używane w AFAICT), co skutkuje takim samym odejściem etapowym / docelowym, jaki można uzyskać w przypadku zmian danych.