Długa pauza podczas uzyskiwania dostępu do przestrzeni nazw DFS

Niedawno przeprowadziliśmy migrację naszej sieci Windows, aby używać DFS do udostępniania plików. DFS działa dobrze, z wyjątkiem jednego irytującego problemu: użytkownicy doświadczają znacznego opóźnienia, gdy próbują uzyskać dostęp do przestrzeni nazw DFS, do której nie mieli dostępu przez pewien czas. Próbowałem rozwiązać problem, ale jak dotąd nie odniosłem żadnego sukcesu, i miałem nadzieję, że ktoś tutaj może mieć wskazówki, które pomogą rozwiązać problem.

Po pierwsze, pewne informacje na temat naszej sieci:

Sieć korzysta z domeny Active Directory na poziomie funkcjonalnym Windows 2008 z dwoma kontrolerami systemu Windows 2008 i dwoma serwerami DNS (po jednym na każdym z kontrolerów domeny). Sieć jest tylko DNS - bez WINS. Wszystkie komputery znajdują się w tej samej lokalizacji i są połączone przez Gigabit Ethernet. Mamy około 20 opartych na Domenie przestrzeni nazw DFS w trybie Windows 2008, a każda przestrzeń nazw DFS ma dwa serwery przestrzeni nazw DFS systemu Windows 2008 (te same dwa serwery dla wszystkich przestrzeni nazw). Wszystkie serwery przestrzeni nazw są w trybie FQDN, a wszystkie cele folderów są określone za pomocą ich FQDN. Wszystkie komputery są aktualne z dodatkami Service Pack i łatkami.

Rzeczywiste cele folderów (tj. SMB współużytkuje nasze foldery DFS) są rozproszone na kilku serwerach plików i aplikacji, wszystkie z systemem Windows 2008 i dwoma serwerami aplikacji, na których działa system Windows 2003 R2, bez żadnej konfiguracji replikacji (np. Obecnie wszystkie foldery DFS tylko jeden cel folderu).

Więcej szczegółów na temat problemu:

Opóźnienie dostępu do przestrzeni nazw wynosi zwykle 1–10 sekund i wydaje się, że występuje, gdy określony komputer nie uzyskał dostępu do żądanej przestrzeni nazw przez około pięć minut lub dłużej.

Na przykład, jeśli użytkownik nie uzyskał dostępu do \\ nazwa_domeny \ przestrzeń nazw1 \ przez więcej niż pięć minut i spróbuje uzyskać dostęp do \\ nazwa_domeny \ przestrzeń nazw1 \ za pomocą Eksploratora Windows, okno Eksploratora zawiesi się na 1–10 sekund, zanim w końcu wznawianie i wyświetlanie folderów istniejących w \\ domain.name \ namespace1. Jeśli następnie zamkną okno Eksploratora i spróbują uzyskać dostęp do \\ domain.name \ namespace1 \ ponownie w ciągu pięciu minut, zawartość zostanie wyświetlona prawie natychmiast - jeśli poczekają dłużej niż pięć minut, przejdzie ponownie przez 1–10 sekundową pauzę.

Po „wewnątrz” przestrzeni nazw wszystko jest fajne i szybkie, tylko początkowe połączenie z przestrzenią nazw jest wolne.

Opóźnienia przeglądania wydają się wpływać na wszystkie warianty systemu Windows, z którego korzystamy (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - być może jest nieco gorzej w Windows XP / 2003 niż w Windows 2008, ale ja nie jestem pewien, czy różnica nie jest tylko psychologiczna.

Bezpośredni dostęp do docelowych folderów leżących u podstaw nie wykazuje żadnego opóźnienia - tzn. Jeśli dostęp do udziałów SMB wskazywanych przez DFS jest uzyskiwany bezpośrednio (z pominięciem DFS), nie ma przerwy.

Podczas rozwiązywania problemów zauważyłem, że „Czas buforowania” dla wszystkich naszych korzeni DFS jest ustawiony na 300 sekund - 5 minut. Biorąc pod uwagę, że jest to tyle samo czasu potrzebnego do uruchomienia pauzy, zakładam, że to buforowanie jest w jakiś sposób powiązane, chociaż nie jestem pewien, co dokładnie jest buforowane na kliencie, a zatem co należy ponownie wyszukać po 5 minutach.

Próbując rozwiązać problem, próbowałem już / sprawdziłem następujące (bez powodzenia):

• Uruchom dcdiag na obu kontrolerach domen - nie znaleziono problemów
• Wykonałem kilka podstawowych testów serwera DNS, nie znajdując żadnych problemów - nie wiem, jak szczegółowo sprawdzić serwery DNS, ale dodam, że sieć nie wykazuje innych dziwnych zachowań, które mogłyby wskazywać na problem z DNS
• Wyłączony antywirus na klientach i serwerach
• Usuwanie jednego z serwerów przestrzeni nazw z kilku przestrzeni nazw - bez różnicy

Więc o to mi chodzi - i nie mam pomysłów. Czy ktoś może zasugerować, co może być przyczyną opóźnień i / lub co powinienem spróbować w następnej kolejności?

Wydaje się, że w końcu rozwiązaliśmy ten problem w naszym środowisku. Dla korzyści innych, oto co odkryliśmy i jak naprawiliśmy problem:

Aby uzyskać lepszy wgląd w to, co działo się przed opóźnieniami / w trakcie / po opóźnieniach, użyliśmy Wireshark na komputerze klienckim do przechwytywania / analizy ruchu sieciowego, podczas gdy klient ten próbował uzyskać dostęp do udziału DFS.

Te przechwycenia pokazały coś dziwnego: za każdym razem, gdy wystąpiło opóźnienie, między żądaniem DFS wysyłanym od klienta do kontrolera domeny a skierowaniem do serwera głównego DFS wracającego z kontrolera domeny do klienta, kontroler domeny wysyłał kilka nazw emisji wyszukiwania w sieci.

Po pierwsze, kontroler domeny wyemituje wyszukiwanie NetBIOS dla DOMAIN (gdzie DOMAIN to nasza nazwa domeny Active Directory wcześniejszej niż Windows 2000). Kilka sekund później wyemituje wyszukiwanie LLMNR dla DOMAIN. Po tym nastąpi kolejne wyszukiwanie NetBios dla DOMAIN. Po emisji tych trzech wyszukiwań (i zakładam, że upłynął limit czasu) kontroler domeny w końcu odpowie klientowi (prawidłowym) skierowaniem do serwera głównego DFS.

Te wyszukiwania nazw emisji dla DOMAIN były wysyłane tylko wtedy, gdy wystąpiło duże opóźnienie otwierania udziału DFS, i mogliśmy wyraźnie zobaczyć z przechwytywania Wireshark, że DC nie zwraca odwołania do serwera głównego DFS, dopóki wszystkie trzy wyszukiwania nie zostały wysłane ( i minęło ~ 7 sekund). Dlatego te wyszukiwania nazw emisji były oczywiście przyczyną naszych opóźnień.

Teraz, gdy wiemy, na czym polega problem, zaczęliśmy próbować dowiedzieć się, dlaczego dochodzi do wyszukiwania nazw emisji. Po nieco większej ilości Googlingu i próbach i błędach znaleźliśmy naszą odpowiedź: nie ustawiliśmy klucza rejestru DfsDnsConfig na naszych kontrolerach domen na 1, jak jest to wymagane w przypadku korzystania z DFS w środowisku tylko DNS.

Kiedy pierwotnie DFS konfiguracji w naszym otoczeniu możemy nie czytać różne artykuły o jak skonfigurować DFS dla środowiska DNS-only (np Microsoft KB244380 i inne) oraz były świadome tego klucza rejestru, ale nie misintepreted z instrukcjami wyświetlanymi na kiedy / jak Użyj tego.

KB244380 mówi:

Klucz rejestru DFSDnsConfig musi zostać dodany do każdego serwera, który będzie uczestniczył w przestrzeni nazw DFS, aby wszystkie komputery mogły zrozumieć w pełni kwalifikowane nazwy.

Myśleliśmy, że oznacza to, że klucz rejestru musi być ustawiony tylko na serwerach przestrzeni nazw DFS , nie zdając sobie sprawy, że był on również wymagany na kontrolerach domeny. Po ustawieniu DfsDnsConfig na 1 na naszych kontrolerach domen (i zrestartowaniu usługi „Przestrzeń nazw DFS”) problem zniknął.

Oczywiście jesteśmy zadowoleni z tego wyniku, ale dodam, że wciąż nie jestem w 100% przekonany, że to nasz jedyny problem - zastanawiam się, czy dodanie DfsDnsConfig = 1 do naszych kontrolerów domeny tylko rozwiązało problem, zamiast go rozwiązać . Nie mogę zrozumieć, dlaczego kontrolery domeny próbują wyszukać DOMAIN (sama nazwa domeny, a nie serwer w domenie) podczas procesu polecania DFS, nawet w środowisku innym niż DNS, i wiem też, że nie ustawiłem DfsDnsConfig = 1 na kontrolerach domen w innych (co prawda znacznie mniejszych / prostszych) środowiskach opartych tylko na DNS i nie miałem tego samego problemu. Mimo to rozwiązaliśmy nasz problem, więc jesteśmy szczęśliwi.

Mam nadzieję, że jest to pomocne dla innych, którzy doświadczają podobnego problemu - i jeszcze raz dziękuję tym, którzy zaproponowali sugestie po drodze.

Może to być spowodowane zamówieniem maski sieci serwera DNS. Ostatnio natrafiliśmy na to w Server 2003. Zależy to od twojego obecnego podsieci.

Przykład.

Witryna 1: podsieć IP 10.0.0.0/24 Witryna 2: podsieć IP 10.0.1.0/24

Klient w lokacji 2 wykonuje zapytanie DNS dla przestrzeni nazw opartej na domenie i domyślnie otrzymuje serwer DFS w lokacji 1, ponieważ serwer DNS nie zna granic IP witryny. Musisz powiedzieć serwerom DNS, jakiej maski podsieci należy użyć, aby zidentyfikować adresy IP, na które należy odpowiedzieć.

Zobacz http://support.microsoft.com/kb/842197

Blog zespołu usługi Active Directory zawiera trzyczęściowy artykuł WSZYSTKO na temat opóźnień w systemie plików DFS.

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

Obejmuje podstawy procesu rekomendacji, a następnie pokazuje, jak korzystać z różnych narzędzi, w tym dfsUtil i dfsDiag, aby odkryć faktyczną przyczynę opóźnień.

Pomogło mi to znaleźć mój problem. Okazało się, że nie ma uprawnień do odczytu katalogu udostępniania dla użytkowników domeny.

HTH, Daniel

Pachnie jak problem z DNS, ale wszystko idzie. Zdecydowanie wolałem stary FRS, ponieważ narzędzia diagnostyczne, takie jak ultradźwięki, były bardzo przydatne: 7

Czy masz coś w dzienniku zdarzeń replikacji systemu plików DFS na obiektach docelowych? (raport DFS Health sporządzi ostrzeżenia z dziennika zdarzeń)

Uruchamianie bez WINS jest miłym celem i godne podziwu, choć jestem przeciwko temu, jeśli są jakieś systemy Windows starsze niż Vista / 2008, ponieważ z mojego doświadczenia nie zawsze działa tak, jak oczekiwano lub tak szybko bez WINS - choć naprawdę nie powinno mieć znaczenia.

Klient buforuje odwołanie do systemu plików DFS, tzn. Gdy wpiszesz \ domain.name \ namespace, zbuforuje do którego serwera odnosi się nazwa domeny. Po wygaśnięciu odwołania z pamięci podręcznej klient musi po prostu „odkryć” topologię DFS od nowa, stąd opóźnienie.

Zajrzyj tutaj: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx i tutaj http://blogs.technet.com/filecab/archive/2006/01/20 /417832.aspx, aby uzyskać dodatkowe informacje o tym, jak to działa.

Możliwe rozwiązania? Trudnym rozwiązaniem tego problemu może być napisanie małego programu, który co kilka minut „utrzymuje się przy życiu”; np. program C, który otwiera pierwszy znaleziony plik i natychmiast go zamyka. Nie próbowałem tego ani nie testowałem i na pewno będziesz musiał dokładnie rozważyć, czy masz zamiar to zrobić.

Wystąpił podobnie brzmiący problem, w którym użytkownicy doświadczają opóźnień (do minuty) między kliknięciem dysku zamapowanego na udział DFS, a możliwością przeglądania i przeglądania folderów w tym udziale.

Użytkownicy mieli także dyski domowe zmapowane do innego udziału DFS na tym samym woluminie i nie mieli opóźnienia podczas uzyskiwania dostępu do folderów.

Różnica między nimi polega na wyliczeniu opartym na dostępie (ABE) - udział problemowy ma to włączone (jest to wspólny dysk dla użytkowników z tysiącami folderów - ABE oznacza, że ​​użytkownicy widzą tylko te foldery, do których mają uprawnienia).

Wyłączenie ABE całkowicie usunęło problem. Oczywiście nie jest to rozwiązanie, ponieważ użytkownicy widzą wszystkie foldery, myląc je. Jako replikę tymczasowo zreplikowałem udział DFS na serwerze z dyskiem zapasowym i nawet po włączeniu ABE w tym nowym celu opóźnienie minęło.

Serwer, na którym występuje problem, to 2k3R2, a jego czas pracy wynosi ponad 150 dni (!), Więc zostanie zrestartowany i CHKDSK będzie działał na naruszającym wolumenie. Wrócę tutaj, jeśli to ma jakiś wpływ na problem. Nowy cel znajduje się na serwerze 2k8.

dfsutil / spcflush i dfsutil / pktflush mogą być rozwiązaniem również w sieci z wieloma lokacjami. Upewnij się, że łącze DFS strony domowej pochodzi z lokalnego serwera, a nie z pamięci podręcznej.

Wiem, że oryginalny plakat nie korzystał z WINS, ale piszę dla innych, ponieważ najczęściej używaliśmy tego postu, aby rozwiązać bardzo podobny problem. Dla nas skończyło się na tym, że ktoś postanowił nazwać swoją stację roboczą taką samą nazwą jak domena. Tak więc, za każdym razem, gdy kontroler domeny sprawdzał nazwę domeny dla odwołania DFS, chciał rozstrzygnąć tę stację roboczą i powodowałby znaczne opóźnienie rzędu kilkudziesięciu sekund. W WINS umieszczono statyczny wpis 20 wskazujący na DC, co rozwiązało problem. Jeśli nie posiadałeś WINS, możesz poeksperymentować z umieszczeniem nazwy domeny jako nazwy komputera w pliku LMHOSTS wskazującym na kontroler domeny, aby uzyskać 20 wyszukiwania, i ustaw priorytet, aby LMHOSTS był pierwszym miejscem, w którym należy szukać rozwiązywania nazw Netbios.

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx Ta strona faktycznie wspomina zarówno o kontrolerach domeny, jak i DFSN, jeśli to pomaga.

Wpisy rejestru kontrolera domeny DFS i głównego serwera

Poniższe wpisy rejestru znajdują się w obszarze

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

na serwerach głównych i kontrolerach domeny. Wszystkie wpisy są REG_DWORD.

Więc użyłem tego artykułu w swoich poszukiwaniach. Ustawiłem wszystko i nadal miałem problemy. Po kilku dniach analizowania problemu i wykluczenia wszystkiego „Microsoft”, zgadłem, że to było związane z siecią. Okazało się, że problemem był nasz akcelerator WAN . Kazałem naszym pracownikom z sieci wyłączyć przyspieszenie dla naszych kontrolerów domen i wszystko się poprawiło.

Miał wiele kontrolerów, podobnie jak skrypt ( dnsdfs.cmd servername):

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs

Wspominasz, że masz 20 serwerów DFS, ale nie wspominasz, czy wszystkie serwery są w tym samym obiekcie.

Jeśli te serwery nie znajdują się w tym samym obiekcie, a każda inna witryna ma własną domenę, możesz upewnić się, że funkcja powrotu po awarii klienta jest włączona.

Dla tych, którzy kończą tutaj za pomocą wyszukiwarki Google i którzy mają ten sam problem ...

Najpierw sprawdź, czy wszystkie linki w Twojej Przestrzeni nazw są dostępne i dobre. Tak było w moim przypadku, w przestrzeni nazw nadal było łącze do serwera, który był wyłączony, więc długa przerwa podczas otwierania DNS była spowodowana tym, że szukał on tego serwera i nie powiodło się. Gdy wyłączyłem ten link w DFS, długa pauza zniknęła.

Sprawdź, czy grupa Użytkownicy uwierzytelnieni ma dostęp do listy zawartości katalogu głównego, na który jesteś mapowany. Na przykład, jeśli dysk x: jest zamapowany na \ domain.local \ departents \ Marketing, użytkownik będzie potrzebował uprawnień do listy dla \ domain.local \ departments. W roku 2008/2012 możesz określić w ramach uprawnień zaawansowanych, że ma to zastosowanie do „Tylko tego folderu”, aby nie mogły wyświetlać zawartości żadnych podfolderów, które mogą dziedziczyć uprawnienia.