Proces odzyskiwania pamięci bazy danych usługi Active Directory i obliczanie dozwolonych interwałów

  • Artykuł

W tym artykule opisano proces odzyskiwania pamięci bazy danych usługi Active Directory i obliczenie dozwolonych interwałów.

Dotyczy: Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Oryginalny numer KB: 198793

Podsumowanie

Baza danych usługi Active Directory obejmuje proces odzyskiwania pamięci, który jest uruchamiany niezależnie na każdym kontrolerze domeny w przedsiębiorstwie.

Więcej informacji

Odzyskiwanie pamięci to proces sprzątania przeznaczony do wolnego miejsca w bazie danych usługi Active Directory. Ten proces jest uruchamiany na każdym kontrolerze domeny w przedsiębiorstwie z domyślnym okresem istnienia wynoszącym 12 godzin. Ten interwał można zmienić, modyfikując atrybut garbageCollPeriod w obiekcie konfiguracji DS (NTDS) dla całego przedsiębiorstwa.

Ścieżka obiektu w domenie Contoso.com będzie podobna do następującej:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=CONTOSO,DC=COM

Użyj narzędzia do edycji usługi Active Directory, aby ustawić atrybut garbageCollPeriod. Obsługiwane narzędzia obejmują skrypty Adsiedit.msc, Ldp.exe i Active Directory Service Interfaces (ADSI).

Po usunięciu obiektu nie zostanie on usunięty z bazy danych usługi Active Directory. Zamiast tego obiekt jest oznaczony do usunięcia w późniejszym terminie. Ten znacznik jest następnie replikowany do innych kontrolerów domeny. W związku z tym proces odzyskiwania pamięci rozpoczyna się od usunięcia szczątków wcześniej usuniętych obiektów z bazy danych. Obiekty te są nazywane nagrobkami. Następnie proces odzyskiwania pamięci usuwa niepotrzebne pliki dziennika. Na koniec proces uruchamia wątek defragmentacji, aby uzyskać dodatkowe wolne miejsce.

Ponadto istnieją dwie metody defragmentacji bazy danych usługi Active Directory. Jedną z metod jest operacja defragmentacji online, która jest uruchamiana w ramach procesu odzyskiwania pamięci. Zaletą tej metody jest to, że nie trzeba przełączać serwera w tryb offline, aby operacja mogła zostać uruchomiona. Jednak ta metoda nie zmniejsza rozmiaru pliku bazy danych usługi Active Directory (Ntds.dit). Druga metoda przenosi serwer w tryb offline i defragmentuje bazę danych przy użyciu narzędzia Ntdsutil.exe. Takie podejście wymaga uruchomienia bazy danych w trybie naprawy. Zaletą tej metody jest zmiana rozmiaru bazy danych i usunięcie nieużywanego miejsca. W związku z tym i rozmiar pliku Ntds.dit jest zmniejszona. Aby użyć tej metody, kontroler domeny musi zostać przesunięty w tryb offline.

Limity dla garbageCollPeriod:
Wartość minimalna to 1, a maksymalna to 168 dla jednego tygodnia. Wartość domyślna to 12 godzin.

Minimum dla okresu istnienia reliktu:
Minimalna wartość okresu istnienia reliktu to 2 dni dla celów obliczeń dotyczących wstrzymania wykonywania przez KCC.

Warstwa bazy danych usługi AD wymusza dodatkową metrykę. Dni TSL nie mogą być mniejsze niż trzykrotny interwał odśmiecania pamięci. Na podstawie wartości domyślnej wynoszącej 12 godzin protokół TSL wynosi co najmniej 2 dni. Jeśli interwał GC wynosi 20 godzin, minimum TSL wynosi 3 dni (musi być większe niż 60 godzin). Jeśli interwał GC wynosi 25 godzin, przekroczysz trzy dni (z 75 godzinami), a minimum TSL to 4 dni.

Przechwytywanie z sprawdza zarówno warstwy bazy danych i KCC wykonać jest to, że jeśli TSL jest niższa niż dozwolone minimum, nie przywrócić minimalną wartość 2 lub więcej dni, ale domyślnie 60 lub 180 dni.

Ważna

W przypadku, gdy protokół TSL zostanie skorygowany do wartości domyślnej z powodu niezgodności, wartość interwału odzyskiwania pamięci jest również ustawiona na wartość domyślną 12 godzin.

Domyślne okresy istnienia reliktu

Historia

Domyślny okres istnienia reliktu (TSL) w systemie Windows Server 2003 wynosił 60 dni i okazał się zbyt krótki. Na przykład wstępnie przygotowany kontroler domeny może być przesyłany dłużej niż 60 dni. Administrator może nie rozwiązać błędu replikacji ani wprowadzić kontrolera domeny w tryb offline do czasu przekroczenia protokołu TSL. System Windows Server 2003 z dodatkiem Service Pack 1 (SP1) zwiększył protokół TSL z 60 do 180 dni w następujących scenariuszach:

  • Kontroler domeny systemu Windows NT 4.0 jest uaktualniony do systemu Windows Server 2003 przy użyciu nośnika instalacyjnego systemu Windows Server 2003 z dodatkiem SP1 w celu utworzenia nowego lasu.
  • Komputer z systemem Windows Server 2003 z dodatkiem SP1 tworzy nowy las.

System Windows Server 2003 z dodatkiem SP1 nie modyfikuje wartości protokołu TSL, jeśli spełniony jest jeden z następujących warunków:

  • Domena systemu Windows 2000 jest uaktualniana do systemu Windows Server 2003 przy użyciu nośnika instalacyjnego dla systemu Windows Server 2003 z dodatkiem SP1.
  • System Windows Server 2003 z dodatkiem SP1 jest zainstalowany na kontrolerze domeny z oryginalną wersją wersji systemu Windows Server 2003.

Zwiększenie protokołu TSL dla domeny do 180 dni ma następujące korzyści:

  • Kopie zapasowe używane w scenariuszach odzyskiwania danych mają dłuższy okres użytkowania.
  • Kopie zapasowe stanu systemu, które są używane do instalacji z poziomu promocji multimediów, mają dłuższy okres użytkowania.
  • Kontrolery domeny mogą być dłużej w trybie offline. Wstępnie przygotowane komputery rzadziej zbliżają się do wygaśnięcia protokołu TSL.
  • Kontroler domeny może pomyślnie wrócić do domeny po dłuższym czasie pracy w trybie offline.
  • Znajomość usuniętych obiektów jest dłużej przechowywana na źródłowym kontrolerze domeny.

Ustawienie domyślne w lesie będzie zależeć od systemu operacyjnego przy "narodzinach" lasu i metod uaktualniania z tego miejsca, jak powyżej.

Jeśli nie masz pewności co do wartości protokołu TSL używanego w lesie, zalecamy jawne ustawienie go, a także ustawienie msDS-deletedObjectLifetime zgodnie z potrzebami.
Dokumentacja: Kosz usługi AD: opis, implementacja, najlepsze rozwiązania i rozwiązywanie problemów