Udostępnij przez

Właściwe umieszczanie kontrolerów domeny i rozważania dotyczące lokalizacji

Właściwa definicja witryny ma kluczowe znaczenie dla wydajności. Klienci, którzy tracą połączenie ze stroną, mogą doświadczać niskiej wydajności w przypadku uwierzytelniania i zapytań. Ponadto wraz z wprowadzeniem protokołu IPv6 na klientach żądanie może pochodzić z adresu IPv4 lub adresu IPv6, a usługa Active Directory musi mieć prawidłowo zdefiniowane lokacje dla protokołu IPv6. System operacyjny preferuje protokół IPv6 do IPv4, gdy obie są skonfigurowane.

Począwszy od systemu Windows Server 2008, kontroler domeny próbuje użyć rozpoznawania nazw do wyszukiwania wstecznego w celu określenia lokacji, w których powinien znajdować się klient. Może to doprowadzić do wyczerpania puli wątków ATQ, co skutkuje brakiem odpowiedzi kontrolera domeny. Odpowiednim rozwiązaniem jest prawidłowe zdefiniowanie topologii lokacji dla protokołu IPv6. Aby obejść ten problem, można zoptymalizować infrastrukturę rozpoznawania nazw, aby szybko reagować na żądania kontrolera domeny. Aby uzyskać więcej informacji, zobacz opóźnienie odpowiedzi kontrolera domeny Windows Server 2008 lub Windows Server 2008 R2 na żądania LDAP lub Kerberos.

Dodatkowym obszarem uwagi jest lokalizowanie kontrolerów domeny głównej (DC) do odczytu/zapisu w scenariuszach, w których są używane RODC. Niektóre operacje wymagają dostępu do zapisywalnego kontrolera domeny lub są kierowane do zapisywalnego kontrolera domeny, gdy wystarczy kontroler domeny Read-Only. Optymalizacja tych scenariuszy obejmuje dwie ścieżki:

  • Kontaktowanie się z zapisywalnymi kontrolerami domeny, gdy Read-Only kontroler domeny by wystarczył. Wymaga to zmiany kodu aplikacji.
  • W przypadku, gdy zapisywalny kontroler domeny może być konieczny. Umieść kontrolery domeny odczytu i zapisu w centralnych lokalizacjach, aby zminimalizować opóźnienia.

Aby uzyskać więcej informacji, zobacz:

Optymalizowanie pod kątem rekomendacji

Odesłania to sposób przekierowywania zapytań LDAP, gdy kontroler domeny nie hostuje kopii partycji, o którą zapytano. Gdy zwracane jest odwołanie, zawiera on nazwę wyróżniającą partycji, nazwę DNS i numer portu. Klient używa tych informacji do kontynuowania zapytania na serwerze, który hostuje partycję. Jest to scenariusz DCLocator, a wszystkie definicje lokacji zaleceń i umieszczanie kontrolera domeny są obsługiwane, ale aplikacje zależne od odwołań są często pomijane. Zaleca się, aby topologia usługi AD, w tym definicje lokacji i umieszczanie kontrolera domeny prawidłowo odzwierciedlały potrzeby klienta. Ponadto może to obejmować kontrolery domeny z wielu domen w jednej lokacji, dostrajanie ustawień DNS lub przeniesienie lokacji aplikacji.

Zagadnienia dotyczące optymalizacji dla relacji zaufania

W scenariuszu wewnątrz lasu relacje powiernicze są przetwarzane zgodnie z następującą hierarchią domeny: Grand-Child Domena -> Domena podrzędna -> Domena główna lasu -> Domena podrzędna -> Domena Grand-Child. Oznacza to, że bezpieczne kanały komunikacyjne w korzeniu lasu i jego każdym elemencie nadrzędnym mogą stać się przeciążone z powodu agregacji żądań uwierzytelniania przechodzących przez kontrolery domeny w hierarchii zaufania. Może to również powodować opóźnienia w Active Directory o dużym zasięgu geograficznym, gdy uwierzytelnianie musi również przechodzić przez linki o wysokim opóźnieniu, wpływając na powyższy proces. Przeciążenia mogą wystąpić w scenariuszach zaufania między lasami oraz w przypadku relacji zaufania na niższych poziomach. Następujące zalecenia dotyczą wszystkich scenariuszy:

Scenariusze zaufania między domenami to obszar, który był stale punktem bólu dla wielu klientów. Rozwiązywanie nazw oraz problemy z łącznością, często wynikające z działania zapór sieciowych, prowadzą do wyczerpania zasobów na zaufanym kontrolerze domeny, mając wpływ na wszystkich klientów. Ponadto często pomijany scenariusz optymalizuje dostęp do zaufanych kontrolerów domeny. Kluczowe obszary zapewniające, że działa to prawidłowo, są następujące:

  • Upewnij się, że rozpoznawanie nazw DNS i WINS, których używają zaufane kontrolery domeny, może rozpoznać dokładną listę kontrolerów domeny dla zaufanej domeny.

    • Statycznie dodane rekordy mają tendencję do nieaktualności i ponownego inicjowania problemów z łącznością w czasie. Przekazywanie DNS, dynamiczny DNS i scalenie infrastruktury WINS/DNS są łatwiejsze w utrzymaniu w dłuższej perspektywie.

    • Upewnij się, że właściwa konfiguracja usług przesyłania dalej, przekazywania warunkowego i kopii pomocniczych dla stref wyszukiwania do przodu i wstecznego dla każdego zasobu w środowisku, do którego klient może potrzebować dostępu. Ponownie wymaga to ręcznej konserwacji i ma tendencję do przestarzałości. Konsolidacja infrastruktury jest idealna.

  • Kontrolery domeny w domenie zaufania spróbują najpierw zlokalizować kontrolery w zaufanej domenie, które znajdują się w tej samej lokalizacji, a następnie w razie awarii przełączyć się z powrotem do lokalizatorów ogólnych.

    • Aby uzyskać więcej informacji o tym, jak działa DCLocator, zobacz Znajdowanie kontrolera domeny w najbliższym miejscu.

    • Ujednolicenie nazw lokacji między zaufanymi i ufającymi domenami w celu odzwierciedlenia kontrolera domeny w tej samej lokalizacji. Upewnij się, że mapowania podsieci i adresów IP są prawidłowo połączone z lokacjami w obu lasach. Aby uzyskać więcej informacji, zobacz Lokalizator domen w ramach zaufania lasów.

    • Upewnij się, że porty są otwarte, zgodnie z potrzebami dcLocator, dla lokalizacji kontrolera domeny. Jeśli między domenami istnieją zapory, upewnij się, że zapory są prawidłowo skonfigurowane dla wszystkich relacji zaufania. Jeśli zapory nie są otwarte, zaufany kontroler domeny nadal będzie próbował uzyskać dostęp do zaufanej domeny. Jeśli komunikacja nie powiedzie się z jakiegokolwiek powodu, kontroler domeny ufający ostatecznie upłynie czas oczekiwania na odpowiedź od kontrolera domeny zaufanego. Jednak te przestoje mogą trwać kilka sekund dla każdego żądania i mogą wyczerpać porty sieciowe na zaufanym kontrolerze domeny, jeśli liczba żądań przychodzących jest wysoka. Klient może napotkać oczekiwania powodujące przekroczenie limitu czasu na kontrolerze domeny jako zawieszone wątki, co mogłoby przełożyć się na zawieszenie się aplikacji (jeżeli aplikacja wykonuje żądanie w wątku pierwszego planu). Aby uzyskać więcej informacji, zobacz How to configure a firewall for domains and trusts (Jak skonfigurować zaporę dla domen i relacji zaufania).

    • Użyj dnsAvoidRegisterRecords, aby wyeliminować słabe wyniki lub kontrolery domeny o dużym opóźnieniu, takie jak te w lokacjach satelitarnych, od reklam do lokalizatorów ogólnych. Aby uzyskać więcej informacji, zobacz Jak zoptymalizować lokalizację kontrolera domeny lub wykazu globalnego znajdującego się poza lokacją klienta.

      Note

      Istnieje praktyczny limit około 50 do liczby kontrolerów domeny, z których klient może korzystać. Powinny one być najbardziej optymalnymi kontrolerami domeny i o największej pojemności.

    • Rozważ umieszczenie kontrolerów domeny z domen, którym się ufa, oraz domen, które ufają, w tej samej lokalizacji fizycznej.

W przypadku wszystkich scenariuszy zaufania poświadczenia są kierowane zgodnie z domeną określoną w żądaniach uwierzytelniania. Dotyczy to również zapytań do interfejsów API LookupAccountName i LsaLookupNames (jak i innych, są to tylko najczęściej używane). Gdy parametry domeny dla tych interfejsów API są przekazywane wartości NULL, kontroler domeny podejmie próbę znalezienia nazwy konta określonej w każdej zaufanej domenie dostępnej.

Dodatkowe referencje

  • Last updated on