Rozdział 20
Sztuka szacowania rozmiarów Active Directory
Zależnie od rozmiarów i złożoności otoczenia sieciowego korporacji i liczby wąskich gardeł sieci WAN możemy obawiać się dodatkowego obciążenia, jakie wywoła Active Directory w istniejącej infrastrukturze serwerów i sieci komputerowej. No cóż, najlepszym sposobem na pokonanie strachu jest wiedza — którą Czytelnik będzie mógł zdobyć w bieżącym rozdziale. Rozdział ten pokaże od środka, czego oczekiwać od Active Directory pod względem rozmiarów bazy danych, oraz obciążenia kontrolerów domeny i wykazów globalnych, jak również dodatkowego obciążenia sieci powodowanego replikacjami. Jego lektura pozwoli oszacować sytuację instalacji w tych dwóch najważniejszych obszarach. Co ważniejsze, Czytelnik będzie w stanie wykorzystać tę wiedzę do rozwiązywania problemów i optymalizacji wydajności w tych żywotnych dziedzinach.
Osoby wdrażające Active Directory w sieciach rozległych czekają wartościowe informacje w dalszej części rozdziału, gdzie zamieściłem swoje dość rozległe doświadczenia z sieciami WAN. Proszę mi wierzyć iż można tam znaleźć kilka z trudem zdobytych informacji których, o ile wiem, Czytelnik nie znajdzie nigdzie indziej.
Pod sam koniec rozdziału znajdziemy krótki opis sposobów szacowania wymagań sprzętowych dla serwerów przeznaczonych na DC i GC. Wobec tego, po pomyślnym ukończeniu tego rozdziału Czytelnik powinien być w stanie odpowiedzieć na następujące pytania:
Jak szacować rozmiary kontrolerów domen (DC)?
Jak szacować rozmiary serwerów Wykazu globalnego (GC)?
Jak ruch sieciowy replikacji wpłynie na planowanie przestrzeni nazw?
Jak efektywnie sieć fizyczna obsługuje przestrzeń nazw usługi katalogowej?
Bieżący rozdział nie omawia automatyzacji zapełniania katalogu danymi. Po takie informacje odsyłam do rozdziału 19., który zawiera podrozdział poświęcony masowemu wprowadzaniu danych do Active Directory. Rozdział bieżący nie obejmuje też testów pilotowego wdrożenia Active Directory. Etap planowania takich testów został omówiony do pewnego stopnia w dodatku A, podczas gdy rozdziały 17. i 18. zawierają mnóstwo porad dotyczących fazy implementacji. Aby znaleźć szczegółowe omówienie testowania pilotowego Czytelnik będzie musiał zwrócić się do książek o bardziej praktycznej orientacji.
Wnętrze Active Directory
Aby odświeżyć wiedzę o funkcjonowaniu Active Directory proszę przejrzeć podrozdział „Gdzie Active Directory mieści się w architekturze Windows 2000 Server” w rozdziale 4., gdzie zostało wyjaśnione (między innymi), iż Active Directory jest ulepszoną wersją --> aparatu [Author:AJ] bazy danych używanej w Microsoft Exchange Server, nazwanej Extensible Storage Engine (lub po prostu ESE) — a także, iż aparat bazy danych rezerwuje miejsce tylko na składowanie właściwości używanych w każdym obiekcie. Aby jednak zrozumieć bardziej szczegółowe właściwości Active Directory związane z rozmiarami bazy danych (a co za tym idzie, dysku twardego), musimy dokładnie wiedzieć, jak działa aparat bazy danych ESE — co przedstawia bieżący podrozdział.
Ponieważ baza danych ESE jest płaska (więc nie może bezpośrednio wyrażać hierarchicznej przestrzeni nazw, takiej jak Active Directory), Warstwa bazy danych (DB - DataBase Layer) udostępnia abstrakcyjną hierarchię obiektów. Czynnikiem, łączącym nazwy wyróżniające (DN - Distinguished Name) i względne nazwy wyróżniające (RDN - Relative Distinguished Name) używane przez interfejs protokołu LDAP (Lightweight Directory Access Protocol) Active Directory z leżącymi poniżej wpisami w bazie danych ESE, jest globalnie unikatowy identyfikator GUID (Globally Unique Identifier), którego nie można zmienić po utworzeniu obiektu, przydzielany do każdego obiektu bazy danych.
Chociaż więc interfejs LDAP przedstawia obiekty za pomocą nazw DN i RDN, ich wartości są wewnętrznie przetwarzane na GUID każdego obiektu, do którego chcą się odnieść. To z kolei zapewnia, iż odsyłacz zawsze wskazuje na ten sam obiekt, nawet jeśli obiekt ten zostanie przemianowany lub przeniesiony. I ponownie LDAP automatycznie przekształca GUID z powrotem na nazwy DN, dzięki czemu klient LDAP odczytujący atrybuty otrzymuje nazwę wyróżniającą a nie GUID.
Uwaga
Gdyby system musiał zawsze zapisywać i porównywać nieporęczne identyfikatory GUID, identyfikacja obiektu w obrębie tabeli w bazie danych ESE trwałaby zbyt długo; wobec czego każdy obiekt jest również identyfikowany za pomocą znacznika nazwy wyróżniającej (DNT - Distinguished Name Tag). DNT jest czterobajtową wartością DWORD, przyrastającą przy tworzeniu nowego obiektu w magazynie, przez co reprezentuje wiersz bazy danych dla danego obiektu. Powiązanie nadrzędny-podrzędny każdego obiektu jest zapisane w postaci znacznika nazwy wyróżniającej obiektu nadrzędnego (PDNT - Parent Distinguished Name Tag), dzięki czemu rozwiązywanie powiązań nadrzędny-podrzędny jest zoptymalizowane — ponieważ DNT i PDNT są polami indeksowanymi bazy danych.
Baza ESE posiada dwie główne tablice:
Tablica danych — czasem nazywana tablicą obiektów; tablica ta zawiera zwykłe obiekty i atrybuty, jak np. użytkowników, drukarki, dane aplikacji i praktycznie wszelkie inne informacje składowane w Active Directory od chwili zainstalowania. W tablicy tej wiersze reprezentują obiekty a kolumny atrybuty. Można wybierać pomiędzy kolumnami --> stałymi [Author:AJ] i kolumnami cechowanymi.
Tablica łączy — tablica, w której wyrażone są relacje pomiędzy obiektami. Tablica ta zawiera dane reprezentujące atrybuty --> łączone[Author:AJ] , które zawierają wartości odnoszące się do innych obiektów w Active Directory (na przykład, atrybut MemberOf obiektu użytkownika zawiera wartości odsyłające do grup, do których użytkownik należy).
Oprócz tych podstawowych tablic możemy jeszcze znaleźć tablicę schematu, będącą schematem Active Directory z definicjami obiektów i atrybutów oraz stosunkami pomiędzy nimi. Jednakże ani tablica schematu, ani tablica łączy nie jest tak naprawdę zbyt ważna pod względem rozmiarów bazy danych, ponieważ obie powinny być o wiele mniejsze od tablicy danych (która reprezentuje większość faktycznych informacji zapisanych w Active Directory). Ponieważ tablica danych we wszystkich rzeczywistych instalacjach jest o wiele większa od tablic łączy i schematu, na niej będzie skupiać się pozostała część tego podrozdziału.
Zapoznanie z tablicą danych
Chociaż tablica danych jest w rzeczywistości płaskim plikiem, można wyobrazić sobie, że zawiera wiersze (każdy z nich odpowiada egzemplarzowi obiektu, np. użytkownikowi) oraz kolumny (z których każda reprezentuje atrybut schematu, jak np. userPrincipalName). Tablica danych zawiera kolumnę (lub: pole) dla każdego atrybutu w schemacie. Każda kolumna może być jednego z poniższych typów:
Kolumna stała — pamięć przydzielona jest do kolumny w każdym wierszu, co oznacza zużycie maksymalnej przestrzeni dozwolonej dla danego atrybutu, niezależnie od tego, czy jest wykorzystany przez obiekt.
Kolumna cechowana — pamięć przydzielana jest tylko dla istniejących wartości, przez co kolumna zużywa dokładnie tyle pamięci, ile trzeba do zapisania wartości w obiektach.
Tablica danych domyślnie zawiera tylko stosunkowo niewielką liczbę kolumn stałych i dużą liczbę kolumn cechowanych. Kolumny stałe są zasadniczo używane wyłącznie do obsługi struktury katalogu i nie są przez to widoczne dla klientów, podczas gdy kolumny cechowane zawierają atrybuty widziane i potrzebne dla klientów. Jeśli więc odnosimy wrażenie, iż Active Directory jest żarłoczna na przestrzeń dyskową, możemy przynajmniej pocieszyć się, iż mogło być o wiele gorzej.
Każda z tych kolumn może dalej należeć do jednego z dwóch typów z uwagi na wymiary:
--> Wymiary [Author:AJ] stałe — zawiera dane typu liczb całkowitych (integer lub long integer)
Wymiary zmienne — zazwyczaj zawiera typy łańcuchowe (np. łańcuchy Unicode i atrybuty wielowartościowe). Baza danych przydziela tylko tyle miejsca, ile kolumna o zmiennych wymiarach potrzebuje; na przykład, 16 bitów dla łańcucha Unicode o długości 1 znaku, 160 bitów dla 10-znakowego łańcucha Unicode i tak dalej.
Tabela 20.1 przedstawia podzbiór pól rzeczywistej tablicy danych z jedną kolumną stałą (DNT) i czterema kolumnami cechowanymi, aby dać pojęcie, jak wygląda tablica danych. Proszę pamiętać, że wszystkie atrybuty zdefiniowane w schemacie (schemat Active Directory standardowo zawiera około 800 atrybutów) są wprowadzone do każdego wiersza, niezależnie od tego, czy są wykorzystane lub czy stosują się do obiektu w danym wierszu. Tablica danych nie zawiera reguł strukturalnych; do tego służy agent usługi katalogowej (DSA - Directory Service Agent) w połączeniu z tablicą schematu. Wobec tego tabela 20.1 pokazuje tylko maleńki podzbiór kolumn dostępnych w rzeczywistej tablicy danych.
Tabela 20.1
Tablica danych z czterema kolumnami cechowanymi i jedną stałą
Nagłówek kolumny |
DNT |
CN |
objectclass |
OS |
userPassword |
Wiersz x |
3512 |
JDavies |
Top# person# organizational Person# user |
|
****** |
Wiersz y |
4092 |
KJensen |
Top# person# organizational Person# user |
Windows 2000 |
******** |
Ponieważ preferowane są kolumny cechowane, dokładna ilość pamięci użytej do przechowywania obiektu w bazie danych zależy zarówno od liczby atrybutów, dla których wartości są ustawione, jak od rozmiarów tych wartości. Na przykład, jeśli weźmiemy dwa obiekty użytkowników o tych samych rozmiarach i długości, a następnie dodamy 20-znakowy opis do jednego z atrybutów dostępnych dla pierwszego użytkownika (typu łańcucha znaków Unicode), przestrzeń zajęta przez pierwszego użytkownika będzie o 40 bajtów większa od drugiego.
Uwaga
Obecny aparat bazy danych ESE nie pozwala rekordom rozciągać się na więcej niż jedną stronicę bazy danych, wobec czego każdy obiekt jest ograniczony do 8 kB. Jednakże niektórych wartości atrybutów ta granica nie dotyczy w pełni. Wartości długie, o zmiennej długości, mogą być składowane w innej stronicy niż rekord obiektu, pozostawiając za sobą tylko 9-bajtowy odsyłacz. W ten sposób obiekt z wszystkimi atrybutami może rozrosnąć się ponad limit 8 kB.
Jak działa baza danych
Jak już wspomniano, usługa Active Directory jest zaimplementowana na podstawie aparatu bazy danych ESE. ESE jest menedżerem tablic o indeksowanej sekwencyjnej metodzie dostępu (ISAM - indexed sequential access method). Wcześniejsze wersje ESE nosiły nazwę Jet i zostały wykorzystane w usłudze WINS, usłudze certyfikatów, FRS, Edytorze konfiguracji zabezpieczeń (SCE) i różnych innych składnikach systemu Windows 2000 Server.
Plik zawierający bazę danych ESE (a wobec tego bazę danych Active Directory) nosi nazwę ntds.dit i mieści się w katalogu, który został podany w Kreatorze instalacji usługi Active Directory (domyślnym ustawieniem jest folder WINNT\NTDS). ESE jest transakcyjnym systemem bazy danych, korzystającym z plików dziennika do obsługi semantyki odtwarzania transakcji, aby zapewnić dokonanie transakcji w bazie danych. Inaczej mówiąc, każda zmiana w bazie danych odbywa się jako pojedyncza operacja, tak że za każdym razem, gdy cokolwiek zostaje zmienione w bazie danych, cztery poniższe czynności zachodzą jako grupa (tzn. jeśli zawiedzie jedna, zawiodą wszystkie):
Zapis do dziennika.
Zapis w pamięci.
Potwierdzenie transakcji.
Zapis do ntds.dit.
Uwaga
Po zapełnieniu bieżącego dziennika — to znaczy, gdy dziennik osiągnie ustaloną liczbę plików — należy zdecydować, czy system powinien utworzyć nowy plik dziennika (non-circular logging - rejestrowanie niecykliczne), czy zastąpić najstarszy plik dziennika (circular logging - rejestrowanie cykliczne). Domyślnie ustawione jest rejestrowanie niecykliczne. Aby to ustawienie zmienić, wystarczy zmodyfikować klucz Rejestru HKEY_Local_Machine\CurrentControlSet\NTDS\Parameters\CircularLogging z 0 na 1. Jeśli zdecydujemy się pozostać przy rejestrowaniu niecyklicznym, proszę pamiętać, iż zapisywane są wówczas wszystkie zmiany w bazie danych, które następnie nie zostaną usunięte w procesie porządkowania, zanim wszystkie wpisy nie zostaną zaimplementowane w bazie danych.
Pliki dziennika powinny mieć zawsze rozmiar 5MB — inny rozmiar najprawdopodobniej oznacza uszkodzenie pliku. Wszystkie pliki dziennika używane przez ESE łatwo jest zauważyć, ponieważ mają rozszerzenie .log.
Dlatego też w idealnych warunkach baza danych systemu (ntds.dit) oraz pliki dziennika (*.log) powinny mieścić się na osobnych napędach dyskowych. Jeśli rozdzielimy te odmienne typy plików, zauważymy polepszenie wydajności, zaś w przypadku poważnej awarii dysku odzyskiwanie będzie o wiele lepiej obsługiwane. Zysk wydajności będzie proporcjonalny do ilości zapisów w domenie Active Directory — jak niektórzy mogą pamiętać z Exchange Server 4 i 5, mającego takie same zalecenia projektowe. Aby zapobiec utracie danych spowodowanych uszkodzeniem twardego dysku, należy też optować za dyskami RAID na partycje zawierające system, bazę danych i pliki dziennika.
Mówiąc o wnętrzach baz danych, Czytelnik powinien też być zaznajomiony z podstawami --> czyszczenia pamięci[Author:AJ] (garbage collection, dosł. „zbieranie śmieci”). Czyszczenie pamięci jest dość prozaicznym określeniem odnoszącym się do faktu, iż Active Directory musi od czasu do czasu dokonać porządków samej siebie. Proces czyszczenia pamięci uruchamiany jest niezależnie w każdym DC (domyślnie co 12 godzin nieprzerwanej pracy), usuwając obiekty i pliki już niepotrzebne dla Active Directory. Mówiąc dokładniej, proces czyszczenia pamięci wykonuje następujące zadania:
Usuwa niepotrzebne pliki dziennika — plik dziennika przestaje być potrzebny po zapisaniu wszystkich zmian (również z wszystkich poprzednich plików dziennika) do pliku bazy danych.
Usuwa nagrobki — zamiast fizycznie usuwać obiekty z bazy danych, Active Directory usuwa większość atrybutów, a następnie oznacza obiekt jako będący w stanie „ --> schowanym[Author:AJ] ” (dosł. „kamienia nagrobnego” - tombstone), aby ostrzec wszystkich partnerów replikacji, iż obiekt został usunięty. Baza danych usuwa nagrobki po okresie możliwym do skonfigurowania ( --> domyślnie jest to 60 dni[Author:AJ] ; we wszelkich sytuacjach z wyjątkiem szczególnych okoliczności nie należy zmieniać tej wartości domyślnej, ponieważ nagrobki służą do replikacji usuwania obiektów).
Defragmentuje na bieżąco bazę danych — aby zaktualizować plik bazy danych, system bazy danych stosuje najszybszą metodę, która nie zawsze jest najbardziej wydajna: po prostu zapełnia stronice bazy danych. Defragmentacja zmienia rozkład danych zapisanych w bazie, aby zapełnić stronice bazy danych bardziej wydajnie. Defragmentacja w trybie online, wykonywana przez proces czyszczenia pamięci, nie zmniejsza rozmiarów bazy danych (w tym celu trzeba wykonać defragmentację w trybie offline), lecz zwiększa ilość miejsca dostępnego dla nowych obiektów i optymalizuje rozplanowanie bazy danych.
Plik ntds.dit w praktyce Całe wykorzystanie bazy danych ntds.dit jest obsługiwane przez usługę lsass.exe. Gdy więc Active Directory potrzebuje dostępu do danych, lsass.exe ładuje do pamięci stronice z pliku ntds.dit. Program ten rezerwuje pulę pamięci dla tych operacji i przenosi stronice pomiędzy bazą danych i pulą na podstawie najdawniejszego użycia (LRU - least recently used). Niektóre stronice w pamięci i pliku bazy danych tracą synchronizację za każdym razem, gdy DSA dokonuje operacji zapisu w obiekcie. Aby naprawić tę sytuację, wszystkie stronice w pamięci są opróżniane do pliku bazy danych za każdym razem, gdy baza danych zostaje wyłączona. DC przenosi też stronice z pamięci z powrotem na dysk twardy (w tle) zawsze, gdy znajduje się w stanie bezczynnym lub mało obciążonym. Wszelkie zmiany dokonywane są w kopiach obiektów katalogowych znajdujących się w pamięci. Dokonywana transakcja w pierwszej kolejności jest zapisywana w pliku dziennika. Zapis zmian w dzienniku jest o wiele szybszy niż w pliku bazy danych, ponieważ zapis do plików dziennika jest sekwencyjny (co eliminuje czas wyszukiwania). Ponadto obecność dziennika zwiększa zdolność do odzysku, ponieważ pliki dziennika mogą posłużyć do przywrócenia zmian w przypadku uszkodzenia pliku bazy danych spowodowanego awarią sprzętu, pod warunkiem że posiadamy nietknięte kopie zapasowe plików dziennika. Pliki te zwykle mieszczą się na innym dysku fizycznym niż pliki magazynu danych i bazy danych katalogu, aby zapewnić, by awaria mająca wpływ na bazę danych nie uszkodziła plików dziennika. Wszelkie dane nie zapisane w kopii zapasowej, lecz zapisane w dziennikach transakcji mogą być „odegrane” aby przywrócić plik bazy danych. W ramach swoich działań drugoplanowych aparat bazy danych nieustająco aktualizuje plik bazy danych przez ostatnio dokonane zmiany, pobierając je bezpośrednio z pamięci (nie z plików dziennika). Dokonując masowych operacji wprowadzania danych do Active Directory możemy zauważyć, iż proces lsass.exe zajmuje więcej i więcej pamięci. Jest to zachowanie zamierzone, powodowane przez przydział buforów pamięci systemowej bazy danych. Baza danych przydziela pamięć tak długo, dopóki jej żądania przydziału kolejnych buforów nie zostaną odrzucone przez system operacyjny. W swoich dążeniach do wyciśnięcia z serwera jak największej wydajności baza danych usiłuje zapanować nad jak największą możliwą ilością pamięci. Po późniejszej aktualizacji bazy danych bufory pamięci są ponownie zwalniane i proces lsass.exe „kurczy się”. Jeśli DC nie może wyłączyć się w sposób zaplanowany, lub usługa Active Directory zostanie nagle zatrzymana, istnieje możliwość iż część najnowszych zmian nie zostanie wprowadzonych do bazy danych, ponieważ najświeższe stronice pamięci nie zostaną zapisane na dysku. W takiej sytuacji w grę wchodzą pliki dziennika, ponieważ mogą posłużyć do odzyskania zmian zapisanych w pamięci, lecz nie wysłanych na dysk. Takie operacje odzysku są wykonywane automatycznie przy następnym uruchomieniu DC. |
Ostrzeżenie
Jeśli przywrócimy serwer z taśmy kopii zapasowej starszej od czasu chowania (tombstone lifetime), serwer nie będzie wiedział o niektórych operacjach usunięcia, co spowoduje przywrócenie usuniętych obiektów do Active Directory — o ile aplikacja kopii zapasowej nie weźmie poprawki na takie niezgodności, powiadamiając DC Active Directory iż dokonywane jest przywracanie nieautorytatywne (patrz rozdział 18.). Ponadto, aby dostosować się do ewentualnych przerw w replikacji, spowodowanych awariami łączy (oraz do czasu transportu sprzętu, jeśli kontrolery domen Active Directory są przygotowywane centralnie, a następnie odłączane aby przetransportować je do miejsca przeznaczenia), należy ustawić czas chowania znacznie dłuższy od najgorszych spodziewanych opóźnień replikacji.
Wskazówka
Można zmienić czas chowania (domyślnie 60 dni, minimalnie 1 dzień) oraz interwał czyszczenia pamięci (domyślnie 12 godzin, minimalnie 1 godzina) używane w całym lesie, zmieniając odpowiednio atrybuty tombstoneLifeTime oraz garbageCollPeriod w kontenerze DirectoryServices, mieszczącym się w kontenerze Configuration w cn=WindowsNT,cn=Services, replikowanym do każdego DC Active Directory.
Jak wykonać defragmentację w trybie offline Aby dokonać defragmentacji pliku ntds.dit w trybie offline, należy:
Uruchomienie w trybie przywracania usług katalogowych tymczasowo przekształca DC w serwer autonomiczny, możemy więc oczekiwać niepowodzeń w uruchamianiu niektórych usług, szczególnie zintegrowanych z usługą katalogową (a co za tym idzie, znacznie dłuższego czasu rozruchu systemu). Ponadto w trybie przywracania usług katalogowych system używa minimalnego zestawu definicji użytkowników i grup składowanego w Rejestrze, wobec czego nie będziemy mogli wykorzystać wszystkich grup i użytkowników z Active Directory. Jeśli DC nie jest zabezpieczony fizycznie, należy zabezpieczyć hasłem dostęp do tego trybu uruchomienia, aby uniknąć wszelkich tylnych wejść z tej strony. |
Jeżeli DC będzie działał nieprzerwanie przez więcej niż 12 godzin, proces czyszczenia pamięci zadba o wszelkie potrzebne prace porządkowe. Wobec tego, defragmentacja w trybie offline powinna być potrzebna tylko w jednej — rzadko spotykanej — sytuacji, gdy zawartość bazy danych znacząco zmaleje (na przykład, gdy GC w dużym lesie zostanie zredukowany do samego DC), a przestrzeń dyskowa będzie potrzebna do innych zastosowań.
Chociaż w środowisku produkcyjnym najprawdopodobniej nie będzie trzeba nigdy dokonać defragmentacji w trybie offline, może to okazać się potrzebne w celu testowania rozmiarów bazy danych, ponieważ testy takie zazwyczaj wymagają metody ustalenia „uczciwych” rozmiarów pliku ntds.dit. Jednakże w środowisku produkcyjnym prawdopodobnie będziemy mogli ustalić najwyżej rozmiary fragmentowanego pliku ntds.dit, co uniemożliwi określenie, ile przestrzeni naprawdę zajmują obiekty w pliku bazy danych.
Jeśli chcemy poznać rozmiary sfragmentowanego pliku ntds.dit musimy uważać na metodę sprawdzania, ponieważ Active Directory otwiera plik bazy danych przy uruchomieniu DC i nie zamyka go aż do zamknięcia systemu. Niestety, NTFS zapisuje rozmiar pliku tylko w chwili otwarcia i nie odświeża informacji aż do ponownego zamknięcia pliku. Wobec tego nie można wykorzystać po prostu wielkości pliku ntds.dit zgłaszanej przez Eksploratora Windows lub z wiersza poleceń, aby ustalić jego rzeczywiste obecne rozmiary.
Aby ustalić dokładne rozmiary pliku ntds.dit, należy zawsze stosować jedną z poniższych metod:
Okno dialogowe Właściwości w Eksploratorze Windows dla partycji zawierającej plik ntds.dit zawsze podaje poprawną ilość wolnego miejsca na dysku.
Restart DC zamyka plik i otwiera ponownie po restarcie usługi katalogowej — co pozwala NTFS zgłaszać poprawny rozmiar pliku aż do dokonania pierwszego zapisu w pliku bazy danych.
Szacowanie rozmiarów i optymalizacja bazy danych Active Directory
W środowisku produkcyjnym należy zawsze wybierać defragmentację w trybie online (poza przypadkami ekstremalnymi), ponieważ daje ona takie same wyniki jak proces offline bez konieczności wyłączania kontrolera domeny. Aby przetestować wzrost rozmiarów bazy danych jednakże należy zastosować defragmentację bazy danych w trybie offline po masowym wprowadzeniu obiektów, ponieważ tylko wersja bazy danych katalogu zdefragmentowana w trybie offline pozwala oszacować rzeczywistą ilość miejsca zajmowanego przez obiekty (porównując zdefragmentowany plik bazy danych przed i po wprowadzeniu danych).
Jak wykonać własne testy, aby ustalić rozmiary bazy danych
Ponieważ tylko zdefragmentowana baza danych wykazuje faktyczne zużycie miejsca na dysku, powinniśmy polegać na rozmiarach bazy danych podanych jedynie bezpośrednio po defragmentacji. Aby przeprowadzić testy przyrostowe, należy dokonać testów o następującym przebiegu:
Wprowadź zbiór obiektów.
Uruchom ntdsutil.exe i przeprowadź defragmentację bazy danych w trybie offline.
Odczytaj rozmiary bazy danych.
Według tych kroków należy postępować w każdym testowanym scenariuszu. Proszę jednak zwrócić uwagę, iż taka metoda testowania daje poprawne wyniki dotyczące minimalnych rozmiarów bazy danych (czyli ilości przestrzeni potrzebnej na obiekty dodawane do Active Directory), nie rzeczywistych rozmiarów używanej bazy danych, ponieważ w środowisku produkcyjnym nie będziemy dokonywać defragmentacji w trybie offline. Warto więc ustalić rozmiary bazy danych także przed defragmentacją, aby móc oszacować, jak efektywnie (lub nieefektywnie) Active Directory dodaje nowe obiekty i atrybuty w różnych warunkach.
Nabieramy pojęcia o rozmiarach bazy danych
Podczas gdy duże i złożone instalacje Active Directory mogą wymagać szczegółowych badań rozmiarów bazy danych, w przeciętnym środowisku prawdopodobnie nie będzie trzeba przeprowadzać zbyt wielu testów. W tym kontekście „przeciętne” oznacza konfigurację wykorzystującą standardowe opcje Active Directory (tzn. do bez dodatkowych obiektów i atrybutów w schemacie), w środowisku zawierającym kilka tysięcy użytkowników i komputerów rozmieszczonych w miarę równomiernie w kilku lokacjach, połączonych stosunkowo stabilnymi łączami o sporej dostępnej przepustowości.
Zasadniczo korzystając z informacji zawartych w tym podrozdziale Czytelnik będzie w stanie zoptymalizować wymagania dotyczące rozmiarów w przeciętnym środowisku. Dla konfiguracji większych lub bardziej złożonych również zalecam przestudiować dostępne tu informacje, aby zaaklimatyzować się w Active Directory, lecz przypuszczalnie wymagane będą testy pilotowe obejmujące pomiary wielkości bazy danych.
Wartości i tabele zawarte w tym i następnym podrozdziale zostały dostarczone przez Microsoft. Początkowo były one skopiowane z publikacji Active Directory Database Sizing: Optimizing Size Requirements for Growth in Directory Service („Ustalanie rozmiarów bazy danych Active Directory: optymalizacja wymogów przestrzeni dla rozwoju usługi katalogowej”), którą Microsoft udostępniał przez czas jakiś na swojej witrynie WWW (a następnie, po zaledwie kilku tygodniach, tajemniczo zniknęła). Według informacji zawartych w publikacji, stanowi ona wyjątek z książki Optimizing Network Traffic (Optymalizacja ruchu sieciowego), należącej do serii „Notes from the Field” (Notatki polowe) Microsoft Press. Być może to jest powodem szybkiego zniknięcia publikacji.
Ku memu wielkiemu zaskoczeniu, publikacja ta pojawiła się ponownie w Internecie w forum TechNet (można ją obecnie pobrać z adresu www.microsoft.com/TechNet/win2000/win2ksrv/technote/adsize.asp), co jest bardzo dziwne, ponieważ informacje zawarte w publikacji — oraz w książce — są obecnie niepoprawne. Liczne drobne zmiany zaimplementowane pomiędzy edycją systemu Windows 2000 Server Beta 2 i wydaniem Windows 2000 Server w rzeczywistości zwiększyły objętość większości obiektów katalogowych.
Wskazówka
Niektóre z testów omówionych w publikacji można również znaleźć w rozdziale 3 Distributed System Guide z Windows 2000 Server Resource Kit. Chociaż więc dokonane testy są identyczne z oryginalnymi, zaktualizowałem dane zawarte w bieżącym rozdziale, aby odzwierciedlić rzeczywiste wyniki na dzień dzisiejszy.
Microsoft przeprowadził zasadniczo dwa rozdaje testów. Pierwsza seria (ładowanie pojedynczych obiektów) zapełniała bazę danych dużą liczbą identycznych obiektów, aby pokazać wzrost bazy danych przy wprowadzaniu obiektów i ilość miejsca zajmowaną przez te typy obiektów. Aby zbliżyć się bardziej do warunków rzeczywistych, w drugiej serii (scenariuszu obciążenia korporacyjnego) tworzono przykładową firmę z obiektami użytkowników, grup i udziałami plików. Seria ta została zaprojektowana by pokazać, do jakich rozmiarów urośnie baza danych dla małych, średnich i dużych firm. Wszystkie cytowane wyniki liczbowe testów dotyczą zdefragmentowanego pliku bazy danych.
Wskazówka
Ponieważ aparat bazy danych zajmuje miejsce tylko dla atrybutów którym przydzielono wartości, liczba atrybutów posiadających wartości w obiekcie zmienia drastycznie rozmiary tego obiektu. Proszę więc uważnie obserwować, co zostało dokonane w każdym przedstawionym teście, oraz porównać wyniki z własną sytuacją.
Wprowadzanie pojedynczych obiektów
Tabela 20.2 przedstawia wzrost rozmiarów bazy danych Active Directory zawierającej do 500 000 użytkowników, z krokiem 100 000 użytkowników. W tym teście ustawione były tylko atrybuty obowiązkowe. Proszę zauważyć liniowe zależności wzrostu pliku bazy danych. Wzrost pomiędzy dwoma operacjami wprowadzania był zawsze niemal identyczny: każdy obiekt użytkownika zajmuje ok. 4 370 bajtów. Test przedstawiony w tabeli 20.2 został również przeprowadzony przez firmę Compaq z 16 milionami obiektów użytkowników, z takimi samymi rezultatami. Możemy być więc pewni liniowego wzrostu dla obiektów użytkowników, niezależnie od rozmiarów firmy.
Wskazówka
Aby zobaczyć efektowną demonstrację olbrzymiej skalowalności Active Directory, zalecam zajrzeć pod adres www.demo.esc.compaq.com/phonebook/. Znajdziemy tu kontroler domeny Active Directory zawierający około 100 milionów obiektów i 1,3 miliarda atrybutów, co daje plik ntds.dit o wielkości 268 GB. W istocie nie jest to tylko ciekawy pokaz — można zrobić z tymi danymi coś użytecznego, ponieważ zostały zbudowane na podstawie książki telefonicznej abonentów prywatnych USA.
Podobne testy przeprowadzone na kontaktach pokazują, iż każdy obiekt typu contact zajmuje ok. 1 700 bajtów. Tabela 20.3 pokazuje wzrost rozmiarów bazy danych Active Directory zapełnionej do 16 000 OU z krokiem 2 000 OU. W tym teście były wprowadzane tylko obowiązkowe atrybuty. Ponownie wzrost pliku bazy danych jest dość liniowy, z wyjątkiem drugiej rundy wprowadzania danych, w której OU sprawiają wrażenie nieco mniejszych; przypuszczalnie powodem była niezdolność do pełnej optymalizacji bazy danych o raczej niewielkich rozmiarach przez proces defragmentacji. Poza tymi pierwszymi operacjami wprowadzania danych, przyrosty były w przybliżeniu identyczne po każdej operacji: każdy obiekt OU zajmuje około 2 000 bajtów.
Tabela 20.2
Wprowadzanie pojedynczych obiektów typu user
Liczba użytkowników |
Rozmiary ntds.dit [kB] |
Wzrost [kB] |
Bajty na użytkownika |
0 |
10 256 |
|
|
100 000 |
436 240 |
428 032 |
4 362 |
200 000 |
864 272 |
428 032 |
4 373 |
300 000 |
1 290 256 |
425 984 |
4 369 |
400 000 |
1 716 240 |
425 984 |
4 367 |
500 000 |
2 142 224 |
425 984 |
4 366 |
Tabela 20.3
Wprowadzanie pojedynczych obiektów typu OU
Liczba OU |
Rozmiary ntds.dit [kB] |
Wzrost [kB] |
Bajty na OU |
0 |
10 256 |
|
|
2 000 |
14 352 |
2 048 |
2 097 |
4 000 |
16 400 |
2 048 |
1 573 |
6 000 |
22 544 |
4 096 |
2 097 |
8 000 |
26 640 |
2 048 |
2 097 |
10 000 |
28 688 |
2 048 |
1 887 |
12 000 |
32 784 |
2 048 |
1 922 |
14 000 |
36 880 |
2 048 |
1 947 |
16 000 |
40 976 |
2 048 |
1 966 |
Tabela 20.4 pokazuje następną serię testów, w których do obiektów użytkowników dodano od 1 do 11 dodatkowych atrybutów. Atrybuty te były zdefiniowane w schemacie jako atrybuty o wartościach łańcuchowych o długości 10 znaków każdy. Test rozpoczął się od magazynu zawierającego 100 000 obiektów typu user z ustawionymi tylko atrybutami obowiązkowymi. DC został zdegradowany, wypromowany ponownie i ponownie zapełniony 100 000 obiektami typu user, tym razem z jednym dodatkowym atrybutem i tak dalej, aż do osiągnięcia poziomu 11 atrybutów.
Tabela 20.4
Dodawanie po jednym atrybucie do obiektów użytkowników katalogu
Liczba dodatkowych atrybutów |
Rozmiary ntds.dit [kB] |
Bajty na użytkownika |
Bajty na atrybut |
0 |
436 020 |
4 362 |
|
1 |
430 080 |
4 404 |
42 |
2 |
434 176 |
4 446 |
40 |
3 |
434 176 |
4 446 |
27 |
4 |
438 272 |
4 488 |
30 |
5 |
442 368 |
4 530 |
33 |
6 |
442 368 |
4 530 |
27 |
7 |
448 512 |
4 593 |
32 |
8 |
448 512 |
4 593 |
28 |
9 |
454 656 |
4 656 |
32 |
10 |
540 672 |
5 536 |
117 |
11 |
540 672 |
5 536 |
106 |
Ten test daje znacznie mniej przewidywalny wzór wzrostu rozmiarów pliku bazy danych. Możemy jednak wyciągnąć ogólny wniosek, iż każdy 10-znakowy łańcuch dodaje co najwyżej 100 bajtów do rozmiarów obiektu użytkownika. Wzrost rozmiarów zdefragmentowanej bazy danych nie jest liniowy - wzrasta skokowo w pewnych miejscach (co może być powodowane przez naturę bazy danych ESE, w której miejsce przydzielane jest stronicami), a następnie pozostaje na danym poziomie przez jakiś czas.
Z braku miejsca nie odpowiemy tutaj szczegółowo na ważne pytanie, ile miejsca zajmuje w bazie danych Active Directory każdy obiekt typu grupy. Nie poskąpię jednak wyników końcowych:
Grupa zabezpieczeń zajmuje ok. 2 100 bajtów.
Grupa dystrybucyjna (nie-zabezpieczeń) również zajmuje około 2 100 bajtów.
Następne jest pytanie, ile dodatkowego miejsca zajmie każdy członek grupy:
Każdy członek dodaje ok. 200 bajtów do rozmiaru grupy.
Po przekroczeniu liczby 100 członków możemy oczekiwać, że każdy członek będzie zajmować tylko 100 bajtów.
Pracując z naprawdę ogromnymi grupami (ponad 500 członków) powinniśmy zredukować szacunkowe dane o kolejne 30% — do 70 bajtów na członka.
Powyższe liczby będą takie same zarówno dla grup zabezpieczeń, jak dystrybucyjnych.
Tabela 20.5 przedstawia wzrost objętości obiektów użytkowników przy zainstalowaniu certyfikatów klucza publicznego (certyfikatów X.509 v3 wydawanych przez Usługę certyfikacji systemu Windows 2000 Server) w bazie danych Active Directory, zawierającej 100 000 użytkowników. Certyfikat X.509 zapisany jako plik ma rozmiary 1 294 bajtów.
Liczba certyfikatów |
0 |
1 |
2 |
3 |
Zdefragmentowany magazyn przed zainstalowaniem certyfikatów |
434 192 |
577 552 |
790 544 |
1 003 536 |
Wzrost rozmiarów bazy danych po zainstalowaniu certyfikatów |
0 |
143 360 |
212 992 |
212 992 |
Rozmiary konta użytkownika w zdefragmentowanej bazie danych po zainstalowaniu certyfikatów (bajty na użytkownika) |
4 341 |
5 809 |
7 990 |
10 171 |
Wzrost konta użytkownika na dodatkowy certyfikat (bajty na użytkownika) |
0 |
1 468 |
2 181 |
2 181 |
Jak pokazują wyniki testu, obiekt typu user rośnie o jakieś 2 100 bajtów, czyli znacznie więcej niż powinniśmy oczekiwać w porównaniu z wartością teoretyczną, wynoszącą 1 294 bajtów.
Powyższy test jest dość interesujący z dwóch powodów:
W ciągu najbliższych lat wiele przedsiębiorstw najprawdopodobniej zacznie stosować certyfikaty kluczy publicznych, co wynika z pełnej obecnie integracji tej technologii z systemem operacyjnym (proszę pamiętać o tym przy podsumowaniu potrzebnych rozmiarów bazy danych).
Klucze publiczne są większe od większości pozostałych atrybutów w katalogu, dzięki czemu test daje wgląd w to, jak dobrze baza danych radzi sobie z atrybutami o większych rozmiarach.
Według wczesnych doświadczeń, każda drukarka i wolumin zajmują odpowiednio 2 400 i 1 600 bajtów.
Scenariusze korporacyjne
Modelowanie różnych scenariuszy korporacyjnych może dać bardziej realistyczne spojrzenie na rozmiary bazy danych. W tym przypadku największy scenariusz korporacyjny obejmuje 100 000 komputerów, 100 000 użytkowników, 10 000 grup, 10 000 drukarek i 10 000 woluminów. Do każdej grupy należy 25 członków.
W każdym cyklu testowym wprowadzana była 1/10 pełnego scenariusza korporacyjnego — to znaczy, w każdej rundzie do bazy danych dodawanych było 10 000 użytkowników i tak dalej. Tabela 20.6 przedstawia scenariusz korporacyjny z minimalną liczbą użytych atrybutów (tylko atrybutom obowiązkowym zostały przydzielone wartości). Wzrost w tabeli 20.6 jest zasadniczo liniowy — w przybliżeniu 88 MB na każdym etapie (to znaczy, dla każdych wprowadzonych 10 procent pełnego scenariusza).
Tabela 20.7 pokazuje, jak baza danych reaguje na dodawanie atrybutów. W tym teście do obiektów użytkowników dodano 30 często występujących atrybutów (imię, nazwisko, numer biura, telefon i tak dalej), 8 atrybutów dodano do stacji roboczych, 4 do grup i 4 do woluminów. Wszystkie atrybuty zostały wypełnione 10-znakowymi łańcuchami.
Tabela 20.6
Scenariusz korporacyjny z samymi atrybutami obowiązkowymi
Cykl wprowadzania danych |
Rozmiary ntds.dit [kB] |
Wzrost [kB] |
Stan początkowy |
10 256 |
|
1 |
98 320 |
88 064 |
2 |
184 336 |
86 016 |
3 |
272 400 |
88 064 |
4 |
360 464 |
88 064 |
5 |
448 528 |
88 064 |
6 |
534 544 |
86 016 |
7 |
622 608 |
88 064 |
8 |
708 624 |
86 016 |
9 |
798 736 |
90 112 |
10 |
884 752 |
86 016 |
Tabela 20.7
Scenariusz korporacyjny z dodatkowymi atrybutami
Cykl wprowadzania danych |
Rozmiary ntds.dit [kB] |
Wzrost [kB] |
Stan początkowy |
10 256 |
|
1 |
139 280 |
129 024 |
2 |
268 304 |
129 024 |
3 |
397 328 |
129 024 |
4 |
526 352 |
129 024 |
5 |
655 376 |
129 024 |
6 |
784 400 |
129 024 |
7 |
913 424 |
129 024 |
8 |
1 042 448 |
129 024 |
9 |
1 171 472 |
129 024 |
10 |
1 300 496 |
129 024 |
Ponownie wzrost jest zbliżony do liniowego — około 130 MB na każdym etapie. Warto zauważyć, iż zdefiniowany tu scenariusz dość dobrze pasuje do większości rzeczywistych przypadków, wobec czego powyższe wyniki mogą posłużyć jako dobra miara wielkości bazy danych Active Directory w scenariuszach firm.
Tabela 20.8 przedstawia wyniki testów dla kolejnego ważnego tematu: wpływu delegowania praw dostępu na rozmiary bazy danych. Wpływ ten powinien być znaczący, ponieważ usługa Active Directory jest zbudowana na statycznym dziedziczeniu ACE. Oznacza to, że wszelkie zmiany w ACL powodowane przez delegowanie praw dostępu do kontenerów Active Directory są propagowane do wszystkich obiektów objętych zmianami (bezpośrednio lub przez dziedziczenie zdefiniowane przez strukturę hierarchiczną wewnątrz domeny). Wobec tego w obiektach objętych delegowaniem dany ACE zostanie dodany do ACL. Z tego powodu należy delegować prawa dostępu do obiektów katalogowych jedynie do grup zamiast określonych wystawców zabezpieczeń.
Tabela 20.8 przedstawia też wyniki dodawania ACE przyznanego grupie do wszystkich obiektów w całej domenie w DC zapełnionym 10 OU i 100 000 użytkowników. Każdy krok pokazuje dodanie ACE do wszystkich obiektów użytkowników w domenie. Wyniki testu pokazują, iż każdy obiekt typu użytkownika rośnie o 29 do 105 bajtów — taki duży rozrzut powodowany jest faktem, iż rozmiary ntds.dit wzrastają skokowo co każde pięć ACE dodanych w domenie — możemy więc bezpiecznie założyć, iż każdy dodany ACE zajmie przeciętnie ok. 75 bajtów dla każdego obiektu w zasięgu delegacji uprawnień administracyjnych.
Tabela 20.8
Podzbiór rezultatów dodawania ACE w całej domenie
Liczba ACE |
Rozmiary ntds.dit [kB] |
Bajty na użytkownika |
Bajty na ACE |
0 |
436 240 |
4 362 |
|
1 |
436 240 |
4 467 |
105 |
2 |
440 336 |
4 509 |
74 |
3 |
440 336 |
4 509 |
49 |
4 |
440 336 |
4 509 |
37 |
5 |
440 336 |
4 509 |
29 |
6 |
481 296 |
4 928 |
94 |
7 |
481 296 |
4 928 |
81 |
8 |
481 296 |
4 928 |
71 |
9 |
481 296 |
4 928 |
63 |
10 |
481 296 |
4 928 |
57 |
15 |
483 344 |
4 949 |
39 |
17 |
552 976 |
5 662 |
76 |
20 |
552 976 |
5 662 |
65 |
Wpływ Exchange 2000 Server na rozmiary obiektów Exchange 2000 Server jest pierwszą aplikacją, która zastąpiła własny katalog przez Active Directory. Jako taka aplikacja, Exchange 2000 Server wprowadza bardzo dużą liczbę nowych obiektów i atrybutów, niemal podwajając zarówno liczbę obiektów jak atrybutów znajdujących się w Active Directory, oraz zwiększając przez to ntds.dit o 4 MB. Ponieważ Exchange 2000 Server najprawdopodobniej będzie zaimplementowany w dużej ilości środowisk Active Directory, nie chciałbym pozbawiać Czytelnika wczesnych doświadczeń dotyczących szacowania rozmiarów obiektów:
Wszelkie pozostałe wytyczne dotyczące szacowania rozmiarów bazy danych nie ulegną zmianie po zaimplementowaniu Exchange 2000 Server. |
Obciążenie replikacjami Active Directory
Active Directory jest usługą katalogową na poziomie lasu, w której aktualizacja kontrolerów domen i wykazów globalnych odbywa się przez replikacje. Dla administratorów sieciowych replikacja nasuwa pytania, w jakim stopniu i jak często sieci (zarówno LAN jak WAN) będą pod wpływem ruchu sieciowego replikacji. Na pytania te nie jest łatwo odpowiedzieć, ponieważ Active Directory udostępnia kilka opcji kontroli nad harmonogramem występowania replikacji. Można jednakże ustalić, ile danych musi zostać przesłanych pomiędzy kontrolerami domen i wykazami globalnymi.
Gdy idzie o replikacje, trzeba pamiętać, iż istnieją dwa różne typy replikacji, których wybór zależy od infrastruktury sieci:
Replikacja wewnątrzlokacyjna — wszelkie replikacje zachodzące w obrębie jednej lokacji. Topologia używana wewnątrz lokacji jest domyślnie tworzona przez Knowledge Consistency Checker (KCC)
Replikacja międzylokacyjna — wszelkie replikacje zachodzące pomiędzy lokacjami. Topologię replikacji międzylokacyjnej tworzy się przez definiowanie lokacji i łączenie ich za pomocą różnego rodzaju łączy lokacji. Jednakże zadaniem zarządzania pomniejszymi szczegółami topologii obarczony jest KCC.
Uwaga
Oprócz kontroli nad replikacjami infrastruktura lokacji udostępnia tzw. pokrewieństwo klientów, co oznacza kontrolę nad tym, jak klienty znajdują DC i GC (zawsze optują za DC i GC należącymi do tej samej lokacji co klient) i pozwala aplikacjom korzystać z informacji o lokacjach. Jest to duży krok naprzód w porównaniu ze starszymi wersjami systemów, w których nie mieliśmy kontroli nad lokalizacją DC. Klient po prostu logował się do DC który odpowiedział jako pierwszy (z wyjątkiem Windows NT 4 Workstation SP4 i późniejszych, które pozwalają podać preferowany DC Windows NT 4).
Chociaż niżej podpisany jeszcze nie wyrobił sobie zdania o mniej widocznych szczegółach replikacji (głównie z przyczyn niedostatków dokumentacji w tej dziedzinie), wszelkie informacje potrzebne aby ogólnie zrozumieć ten temat są łatwo dostępne i zawarte w następnych podrozdziałach.
Replikacje międzylokacyjne DC
Replikacje DC wewnątrz lokacji są zawsze wykonywane za pomocą protokołu DS-RPC (RPC przez IP), który przyjmuje, iż wszystkie DC są połączone dobrymi, stosunkowo stabilnymi łączami sieciowymi. Ponadto nie jest stosowana kompresja danych, ponieważ Microsoft przyjął, iż będziemy chcieli wykorzystać moc obliczeniową procesorów w DC na potrzeby użytkowników końcowych, a nie na kompresję danych przesyłanych pomiędzy DC w obrębie lokacji.
Kontrolery domen powiadamiają okresowo swoich partnerów replikacji (domyślnie co pięć minut), czy zaszły jakieś zmiany od ostatniej replikacji. Ponieważ powiadomienia odbywają się, jak widać, dość często, rezygnacja z kompresji jest jak najbardziej sensowna. Zazwyczaj w każdym pięciominutowym cyklu nie spotkamy zbyt wielu zmian, wobec czego kompresja w istocie mogłaby zwiększyć obciążenie replikacjami w porównaniu do scenariusza bez kompresji (potrzebne są spore ilości danych, zanim użycie kompresji zacznie się opłacać).
Dane dostępne na temat replikacji wewnątrzlokacyjnej DC tworzą następujący obraz:
Minimalny rozmiar replikacji dla obiektów katalogowych (łącznie z uzgadnianiem) wynosi około 4 kB, z przyrostami co 16 bajtów od tej wielkości wzwyż.
Każdy obiekt użytkownika ma około 4 kB.
Każdy obiekt grupy globalnej lub uniwersalnej nie zawierającej żadnych członków ma ok. 2,1 kB.
Każdy obiekt woluminu ma około 1,8 kB.
Zacytowane rozmiary obiektów katalogowych obowiązują tylko przy jednoczesnym replikowaniu ponad 100 obiektów. Wobec tego, replikacja tylko jednego z wyżej wymienionych obiektów katalogowych zajmie około 12 kB.
Wprowadzenie do testów obciążenia replikacjami Ruch sieciowy replikacji można zobaczyć za pomocą jednego z poniższych narzędzi, zawartych na płycie CD-ROM Windows 2000 Server:
Monitor sieci rejestruje wszystkie pakiety wchodzące i wychodzące z określonego DC. Oznacza to wszystkie pakiety, łącznie z pochodzącymi od innych usług. Można obejść ten problem, na przykład, identyfikując port IP używany przez replikacje. Jest to łatwe dla replikacji używających jako transportu SMTP, ponieważ ten protokół zawsze wykorzystuje port 25 — wobec czego możemy znaleźć cały ruch związany z replikacją, filtrując ten port w Monitorze sieci (pod warunkiem, iż podczas testowania nie będzie SMTP przesyłana żadna poczta elektroniczna). Jednakże nie jest łatwo odizolować replikacji RPC przez IP, ponieważ dla zwiększenia bezpieczeństwa używają one dynamicznego mapowania portów. Można jednak skonfigurować każdy DC Active Directory tak, by używał określonego portu (co może przydać się, gdy będziemy mieć do czynienia z sieciami VPN i zaporami), dodając w Rejestrze wartość HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\TCP/IP Port. Jeśli, na przykład, zdecydujemy by ustawić tę wartość na 1349 (dziesiętnie), będziemy mogli filtrując ten port zobaczyć wszystkie replikacje. Operację taką musimy powtórzyć we wszystkich DC, w których chcemy zmierzyć obciążenie przez replikacje. Alternatywnie można użyć liczników replikacji Monitora wydajności, które podają sumę wchodzących i wychodzących bajtów replikacji (dla replikacji międzylokacyjnej zarówno przed, jak po kompresji). Chociaż nie otrzymamy tu poszczególnych pakietów do analizy, lecz dostaniemy wartości liczbowe przepustowości łącz zużytej przez każdy DC. Na koniec, jeśli ciekawi nas tylko wygląd topologii replikacji w danej lokacji, możemy wypróbować Active Directory Replication Monitor (REPLMON), znajdujący się w Windows 2000 Support Tools. REPLMON pozwala zobaczyć w uproszczonej postaci graficznej topologię replikacji pomiędzy DC w tej samej lokacji lub lesie (aczkolwiek moje doświadczenia wskazują, że w opcji widoku graficznego są błędy, więc nie należy zbyt ufać wyświetlanym obrazom), lecz co najważniejsze, udostępnia informacje o niskopoziomowym statusie i wydajności zachodzących replikacji oraz — opcjonalnie — o GPO, FSMO i innych szczegółach w żywotny sposób obsługujących struktury Active Directory. Warto jeszcze wypróbować narzędzie Replication Diagnostics (REPADMIN), również mieszczące się w Windows 2000 Support Tools. REPADMIN, między innymi, pozwala wymuszać replikacje, co powinno być korzystne dla przyspieszenia testów replikacji. Wykorzystanie narzędzia REPADMIN do tego celu ma jednak jedną wadę: dla tej określonej replikacji pomijane z oczywistych powodów są powiadomienia pomiędzy partnerami replikacji — przez co obciążenie przez replikację jest nieco mniejsze niż byłoby w rzeczywistości, więc REPADMIN nie nadaje się do testowania wydajności. |
Dodatkowe obciążenie na członka grupy zawsze wynosi około 180 bajtów. Niestety, rozmiary replikacji dla najczęściej zachodzących zmian w bazie danych Active Directory — zmiany haseł — mają duży rozrzut. Każda zmiana hasła zdaje się zajmować od 400 do 600 bajtów, zależnie od liczby zmian hasła, które nastąpiły od ostatniej replikacji (z wyjątkiem przypadku zmiany tylko jednego hasła; wówczas jest to około 1,8 kB).
Wewnątrzlokacyjne replikacje GC
GC składa się z częściowych kopii (zdefiniowanych przez schemat) wszystkich domen w lesie, oraz pewnych dodatkowych obiektów (dokładnie grup uniwersalnych). Replikacje GC wewnątrz lokacji są wykonywane w taki sam sposób jak w przypadku DC, za pomocą DS-RPC bez kompresji i z powiadomieniami co pięć minut.
Dane dotyczące wewnątrzlokacyjnej replikacji są następujące:
Każdy obiekt użytkownika zajmuje około 3,0 kB.
Każdy obiekt grupy globalnej lub uniwersalnej nie zawierającej żadnych członków ma ok. 2,1 kB.
Każdy obiekt woluminu ma około 1,8 kB.
Znów liczby te są słuszne tylko dla jednoczesnej replikacji ponad 100 obiektów. Na przykład, replikacja tylko jednego z wyżej wymienionych obiektów katalogowych zajmie około 12 kB.
Dodatkowe obciążenie na członka grupy uniwersalnej wynosi około 200 bajtów. Członkostwo w grupach globalnych nie zwiększa obciążenia, ponieważ grupy te nie są publikowane w GC. Jak widać, większość zachodzących replikacji GC ma mniejszą objętość od porównywalnych replikacji DC. Tak też dokładnie być powinno, ponieważ GC zawiera tylko podzbiór atrybutów przechowywanych w kontrolerach domen. Różnica ta powinna się jeszcze zwiększyć, gdy zaczniemy używać więcej atrybutów składowanych w DC a nie replikowanych do GC. I odwrotnie, proszę pamiętać iż GC w środowisku złożonym z wielu domen zawiera więcej obiektów niż każdy DC z osobna.
Międzylokacyjne replikacje DC
Replikacje DC między lokacjami odbywają się w sposób bardzo podobny jak wewnątrz lokacji, poza tym, iż używają kompresji danych, co niemal zawsze zmniejsza ruch sieciowy replikacji w łączach (im więcej danych, tym lepszy stosunek kompresji), lecz kosztuje czas procesora.
Ponadto mamy pełną kontrolę nad tym, jak często i kiedy partnerzy replikacji komunikują się ze sobą. Lecz inaczej niż w replikacji wewnątrzlokacyjnej DC, kontrolery domeny tworzą kanał łączności za każdym razem (co zwiększa nieco obciążenie, lecz zmniejsza prawdopodobieństwo zamieszania powodowanego niestabilnym połączeniem). Z powodu tej różnicy też nie zachodzi powiadamianie pomiędzy dwoma partnerami. Zamiast tego dla każdego kontekstu nazewniczego żądany jest przesył zmian.
Dostępne dane na temat replikacji międzylokacyjnej DC dają obraz przedstawiony w tabeli 20.9 przy replikacji 10, 100 i 1000 z wymienionych obiektów katalogowych. Porównując te liczby z replikacjami wewnątrz lokacji możemy zobaczyć, iż kompresja naprawdę czyni cuda — zaś zyski rosną z liczbą replikowanych obiektów. Zasadniczo, jeśli musimy dokonać replikacji 100 lub więcej obiektów, obciążenie sieci zostanie zmniejszone do 10 - 15% wartości potrzebnych dla replikacji DC wewnątrz lokacji (przy mniejszych ilościach obiektów obciążenie danymi przesyłanymi w obu przypadkach będzie mniej więcej porównywalne). Nie warto więc replikować danych między lokacjami częściej, niż trzeba, ponieważ rzadsze replikacje w identycznych warunkach niosą większy ładunek danych, a co za tym idzie, dają optymalny współczynnik kompresji.
Tabela 20.9
Międzylokacyjna replikacja DC
Typ obiektu |
Rozmiar pojedynczego obiektu przy 10 obiektach |
Rozmiar pojedynczego obiektu przy 100 obiektach |
Rozmiar pojedynczego obiektu przy 1000 obiektów |
Użytkownik |
4 560 bajtów |
400 bajtów |
290 bajtów |
Grupa globalna lub uniwersalna bez członków |
2 675 bajtów |
295 bajtów |
200 bajtów |
Wolumin |
2 170 bajtów |
230 bajtów |
155 bajtów |
Międzylokacyjne replikacje GC
Replikacje GC między lokacjami można wykonywać dokładnie tak samo jak w przypadku DC — z wykorzystaniem DS-RPC (RPC przez IP) z kompresją. Jednakże dla międzylokacyjnej replikacji GC mamy dodatkową opcję: SMTP jako transport replikacji. Wybór SMTP ma sens w przypadku niestabilnych warunków łącza (ponieważ SMTP jest protokołem asynchronicznym), lub w sytuacjach, gdy nie będziemy mogli użyć TCP/IP i (lub) RPC.
Uwaga
Transport SMTP jest zbudowany na składniku SMTP, dostarczanym jako element internetowych usług informacyjnych (IIS 5), zawartych na płycie CD-ROM Windows 2000 Server.
Dane dostępne dla międzylokacyjnej replikacji GC przez DS-RPC dają obraz przedstawiony w tabeli 20.10 przy replikacji 10, 100 i 1000 z wymienionych obiektów katalogowych. Dane dostępne dla międzylokacyjnej replikacji GC z wykorzystaniem SMTP dają obraz przedstawiony w tabeli 20.11 przy replikacji 10, 100 i 1000 z wymienionych obiektów katalogowych.
Ponownie większość replikacji GC ma mniejszą objętość niż porównywalne replikacje DC — dokładnie tak, jak powinno być. Ponadto replikacje używające transportu RPC powodują mniejszy ruch sieciowy niż przy użyciu transportu SMTP. Należy więc zawsze wybierać RPC, o ile nie istnieją ważne powody przeciwko temu.
Tabela 20.10
Międzylokacyjna replikacja GC przez DS-RPC
Typ obiektu |
Rozmiar pojedynczego obiektu przy 10 obiektach |
Rozmiar pojedynczego obiektu przy 100 obiektach |
Rozmiar pojedynczego obiektu przy 1000 obiektów |
Użytkownik |
3 600 bajtów |
325 bajtów |
235 bajtów |
Grupa globalna lub uniwersalna bez członków |
2 680 bajtów |
290 bajtów |
195 bajtów |
Wolumin |
2 320 bajtów |
245 bajtów |
170 bajtów |
Tabela 20.11
Międzylokacyjna replikacja GC przez SMTP
Typ obiektu |
Rozmiar pojedynczego obiektu przy 10 obiektach |
Rozmiar pojedynczego obiektu przy 100 obiektach |
Rozmiar pojedynczego obiektu przy 1000 obiektów |
Użytkownik |
5 290 bajtów |
600 bajtów |
440 bajtów |
Grupa globalna lub uniwersalna bez członków |
4 040 bajtów |
555 bajtów |
395 bajtów |
Wolumin |
3 540 bajtów |
415 bajtów |
350 bajtów |
Jak zrozumieć i zoptymalizować zachowanie sieci
Jeśli sieć komputerowa w całym naszym przedsiębiorstwie nie ma dużej przepustowości, i to dostępnej przez cały czas, powinniśmy poświęcić trochę czasu by zrozumieć zachowania sieci, które można przypisać Active Directory. Zapoznanie się z zaledwie kilkoma ważnymi zagadnieniami powinno postawić Czytelnika w pozycji, z której można zmniejszyć wpływ Active Directory na sieci WAN.
Pierwsza i najważniejsza lekcja dotyczy tworzenia projektu Active Directory, który będzie poprawnie odwzorowywał infrastrukturę sieci. Było to tematem rozdziału 12., więc nie będę tutaj drążył tego tematu dalej.
Lecz nadal można nauczyć się kilku ważnych rzeczy ze szczegółów. Aby zrozumieć zachowania sieci przypisywane Active Directory, musimy skoncentrować się na dwóch bardzo odmiennych zagadnieniach:
Ruch sieciowy serwera — replikacje pomiędzy kontrolerami domen i wykazami globalnymi, oraz dostęp użytkowników do serwerów. Chociaż zasadniczo nie można przewidzieć wpływu użytkowników na obciążenie serwerów, ruch sieciowy replikacji może być przewidziany dość dokładnie, ponieważ zależy od projektu przestrzeni nazw i liczby zmian obiektów w jednostce czasu.
Ruch sieciowy klienta — logowanie klientów i faktyczne wykorzystanie komputera. Generalnie nie da się przewidzieć obciążenia generowanego przez użytkowników, lecz ruch sieciowy logowania klientów jest dość dobrze udokumentowany.
Zrozumienie dynamiki logowania klientów może okazać się całkiem interesujące, ponieważ pozwoli przewidzieć obciążenie sieci w przedsiębiorstwie, gdzie większość użytkowników loguje się o tej samej porze. Ruch sieciowy replikacji też nie jest całkiem nieciekawy, ponieważ powinien stanowić poziom odniesienia dla minimalnego dodatkowego obciążenia istniejących linii WAN, spowodowanego wdrożeniem Active Directory do produkcji.
Logowanie klienta
Zasadniczo powinniśmy spodziewać się, iż każde logowanie klienta wytworzy ruch sieciowy w zakresie od 95 kB do 170 kB (co kontrastuje silnie z ok. 50 kB generowanymi przy logowaniu z komputera Windows 9x). Pierwsza podana liczba dotyczy „szkieletowego” logowania klienta, nie obejmującego niczego poza domyślnym zestawem opcji (tzn. dla najprostszego konta klienta nie zawierającego żadnych zaawansowanych opcji Active Directory); druga liczba powinna być widziana jako przypadek klienta wykorzystującego sporą liczbę opcji GPO.
Im więcej przynależności do grup, ustawień zasad grup, ustawień zabezpieczeń i dystrybucji oprogramowania zastosujemy, tym większe rozmiary logowania uzyskamy.
Logowanie klienta składa się z dwóch części:
Uruchomienie komputera — „szkieletowy” rozruch komputera wymaga około 57 kB.
Logowanie użytkownika — „szkieletowy” proces logowania wymaga około 36 kB.
Kroki związane z uruchomieniem komputera zostały naszkicowane poniżej. W zależności od liczby opcji zasad grup i przynależności do grup, w wyniku tego procesu przez sieć przechodzi około 60 do 90 kB danych:
Komputer wysyła żądanie DHCP i otrzymuje potwierdzenie z serwera DHCP, po czym serwer DHCP rejestruje adres wskaźnika wyszukiwania wstecz, dostarczony przez serwer DDNS. W celu sprawdzenia ewentualnych duplikatów adresu IP otrzymanego z serwera DHCP wysyłane są trzy rozgłoszenia ARP. Około 700 bajtów.
Komputer rozgłasza grupowo pod adres 224.0.0.2 (rutera ICMP) zapytując o najbliższe rutery, a następnie odpytuje serwer DNS o kontrolery domen należące do domeny komputera i mieszczące się w lokalnej lokacji. Około 1 500 bajtów.
DC jest odpytywany o szereg rekordów w celu ustalenia nazwy i kontekstu serwera logowania. Około 2 000 bajtów.
DDNS jest odpytywany o adres IP preferowanego DC i komputer nawiązuje sesję TCP dla konwersacji MS RPC w celu dostępu do usługi NETLOGON. Około 3 000 bajtów.
Dokonywana jest synchronizacja czasu (TimeSync) z preferowanym DC za pomocą protokołu NTP (Network Time Protokol) przez UDP na porcie 123. Około 150 bajtów.
Kroki 2 i 3 są wykonywanie ponownie, serwer jest PINGowany i nowa sesja zostaje nawiązana na potrzeby sesji SMB. Około 1 150 bajtów.
Odbywa się uwierzytelnianie konta komputera za pomocą usługi Kerberos, co powinno zakończyć się otrzymaniem przez komputer biletu przyznającego bilety (TGT - Ticket Granting Ticket). Około 12 000 bajtów (może być trochę więcej, zależnie od liczby grup do których komputer należy).
Komputer łączy się z udziałem IPC$ w DC i pobiera przy tym z serwera wszystkie odsyłacze DFS. Około 6 000 bajtów.
DC jest ponownie odpytywany, podobnie jak w kroku 3. Około 550 bajtów.
Funkcja port mapper RPC jest uruchamiana, komputer żąda biletu TGT dla usługi DC$ (konto kontrolera domeny), przeprowadzanie są trzy wywołania Active Directory i DC jest pingowany. Około 10 000 bajtów.
Komputer żąda biletu TGT dla usługi LDAP.DC.domena.com (konto kontrolera domeny) i odpytuje Active Directory o szereg podstawowych danych, w tym obsługiwane atrybuty LDAP. Komputer żąda biletu TGT dla usługi WS$ (stacja robocza) i żąda GPO dla lokacji, domeny i stacji roboczej. Około 16 000 bajtów (zależnie od liczby GPO).
GPO dotyczące komputera są pobierane. Około 12 000 bajtów lub więcej (zależnie od tego, czy dodaliśmy kolejne GPO dotyczące komputera).
Żądany jest rekord SOA (Start of Authority), do bazy danych usługi DDNS dodane zostają rekordy CNAME i A dla komputera, o które serwer DDNS jest następnie odpytywany aby sprawdzić, czy po jego stronie wszystko działa. Około 1 000 bajtów.
Wszystkie połączenia są zrywane i komputer gotowy jest na przyjęcie logowania użytkownika. Około 1 500 bajtów.
Kroki związane z logowaniem użytkownika są przedstawione poniżej. W zależności od liczby opcji zasad grup i przynależności do grup, w wyniku tego procesu przez sieć przechodzi około 40 do 100 kB danych:
Bilety Kerberosa zostają wymienione pomiędzy komputerem i DC (to znaczy, komputer żąda biletu TGT, otrzymuje go, a następnie odsyła z powrotem, aby uzyskać bilet przyznający usługę (Ticket Granting Service). Około 8 000 bajtów (zależnie od liczby grup, do których należy użytkownik).
Uruchomione zostaje zapytanie wyszukiwania w usłudze LDAP, zawierające GUID domeny komputera i SID domeny. DC zwraca nazwę i kontekst dla serwera LOGON. Około 500 bajtów.
Funkcja port mapper RPC jest uruchamiana, przeprowadzanie są trzy wywołania Active Directory i bilety Kerberosa zostają wymienione ponownie. Około 12 000 bajtów (zależnie od liczby grup, do których należy użytkownik).
Istniejąca sesja RPC wykonuje następne trzy wywołania Active Directory i sesja zostaje zerwana. Około 7 000 bajtów.
Uwierzytelnienie LDAP zostaje ustanowione i wykorzystane do wykonania wyszukiwana w usłudze LDAP obiektów GPO dla lokacji, a następnie dla domeny. Około 12 000 bajtów (zależnie od liczby GPO).
Bilety Kerberosa są wymieniane. Około 9 000 bajtów (zależnie od liczby grup, do których należy użytkownik).
Sesja SMB zostaje nawiązana aby pobrać stosowne GPO. Około 6 000 bajtów.
Bilety Kerberosa są ponownie wymieniane. Około 11 000 bajtów (zależnie od liczby grup, do których należy użytkownik).
Pobierane są odpowiednie GPO. Około 20 000 bajtów lub więcej (zależnie od tego, czy dodaliśmy kolejne GPO dotyczące komputera).
Komputer PINGuje DC, wszystkie pozostające połączenia TCP i SMB są zrywane i użytkownik zostaje zalogowany. Około 500 bajtów.
Ponieważ podczas logowania użytkownika zachodzi tak wiele wymian biletów Kerberosa, przynależność do grup ma o wiele większy wpływ na logowanie użytkownika niż na uruchomienie komputera. Możemy oczekiwać bardziej liniowego wzrostu ruchu sieciowego pomiędzy uruchomieniem komputera i logowaniem klienta, jeśli ładowana jest taka sama liczba GPO (i o takich samych rozmiarach). Rozmiary każdego obiektu GPO można sprawdzić w folderze SYSVOL\Sysvol (patrz rozdział 10.).
Uwaga
Po pobraniu i zastosowaniu u klienta Zasad grup, kolejne logowania generują mniejszy ruch sieciowy, ponieważ obiekty GPO są pobierane przez klienta tylko w przypadku zmian od ostatniego pobrania, lub dodania nowych GPO do klienta (komputera).
Trzeba pamiętać, iż dystrybucja oprogramowania za pomocą GPO, a zwłaszcza profile użytkowników mobilnych wynoszą ruch sieciowy na poziomy całkiem odmienne niż podawane i omawiane powyżej.
Oprócz tego musimy zawsze zwracać uwagę na poniższe opcje, które mogą dodatkowo znacznie obciążyć sieć (lecz zwykle nieporównywalnie słabiej niż GPO oprogramowania i profile użytkowników mobilnych):
Pliki i foldery offline
Przekierowanie folderów
Uwaga na profile użytkowników mobilnych Profile użytkowników mobilnych przechowują preferencje użytkownika dotyczące hiperłączy, pozycji menu Start, ustawień systemu i aplikacji, jak również wszystkie dokumenty mieszczące się w folderze Moje dokumenty i jego podfolderach. Informacje tymczasowe i lokalne dla komputera nie przemieszczają się razem z użytkownikiem — to znaczy, profil użytkownika mobilnego nie zawiera następujących pozycji:
Gdy użytkownik loguje się, profil składowany w serwerze zostaje połączony z lokalnie składowaną kopią podręczną profilu użytkownika (jeśli takowa istnieje). Gdy użytkownik loguje się w komputerze po raz pierwszy, wszystkie informacje z profilu, w tym dostosowanie menu Start i folder Moje dokumenty, są kopiowane na lokalny dysk twardy. Jak można się spodziewać, dodanie profilu użytkownika mobilnego zwiększa ilość danych przy logowaniu użytkownika. „Szkieletowy” profil użytkownika zwykle dodaje 270 kB ruchu sieciowego i więcej, gdy użytkownik zacznie dodawać dane do swojego profilu. Czekają nas jednak jeszcze gorsze rzeczy: chociaż wylogowanie bez profilu użytkownika mobilnego wymaga około 1 kB ruchu sieciowego, objętość danych przesyłanych przy wylogowaniu rośnie do kolosalnych 521 kB i więcej, jeśli użytkownik zacznie dodawać dane do swojego profilu. Rozmiary profilu rosną znacząco z dodaniem kolejnych aplikacji i danych użytkownika. Należy zwrócić uwagę, iż algorytm łączenia używany przez Windows 2000 zmniejsza ilość danych przesyłanych przez sieć, ponieważ tylko zmienione dane kopiowane są do stacji roboczej przy logowaniu i do serwera sieciowego przy wylogowaniu. Jednak doświadczenia polowe prowadzą do nieciekawych konkluzji, iż algorytm ten niewiele pomaga dla danych przesyłanych podczas wylogowania; w absolutnie najlepszych warunkach ruch sieciowy przy wylogowaniu zmniejszany jest o jakieś 50 procent. Inaczej mówiąc, należy wykonać pewną liczbę prób terenowych i na podstawie wyników porównać zyski z załączenia tej opcji z generowanym przez nią ruchem w sieci. W zależności od infrastruktury sieciowej profile użytkowników mobilnych mogą postawić administratora w dość krytycznej sytuacji. W takim przypadku pocieszy nas nieco fakt, iż można ustawić przydziały objętości profilu użytkownika i zarządzać centralnie ustawieniami użytkowników. Najbardziej elegancką metodą zapewnienia, by profile użytkowników mobilnych nie wymknęły się spod kontroli, jest przekierowanie foldera Moje dokumenty i udostępnienie go offline. |
Replikacje serwera
Jak już wspomniano w tym rozdziale. replikacje Active Directory są łatwe do przewidzenia — zasadniczo wykazują wzrost niemal liniowy.
Replikacje usługi Active Directory można dość dokładnie oszacować za pomocą poniższych praktycznych reguł:
Ruch sieciowy nawiązywania replikacji wewnątrz lokacji: żaden.
Ruch sieciowy nawiązywania replikacji międzylokacyjnych: około 13 kB na każdy kontekst nazewniczy.
Replikacje wewnątrz lokacji (bez kompresji danych): 110 do 120 procent rzeczywistej objętości
Replikacje międzylokacyjne (z kompresją): 10 do 15 procent rzeczywistej objętości, jeśli danych jest więcej niż 100 kB.
Uwaga
Jedynymi większymi wyjątkami od tych reguł są międzylokacyjne replikacje danych binarnych i wstępnie skomprymowanych (na przykład haseł, dla których uzyskamy najwyżej 50 % kompresji, o ile zachodzi sporo zmian haseł).
Lecz przed pójściem dalej Czytelnik powinien zapoznać się z kilkoma innymi ważnymi szczegółami. Po pierwsze, w środowisku prawdopodobnie zachodzi kilka innych typów replikacji, obejmujących:
Replikacje usługi replikacji plików (FRS) — zachodzą między wszystkimi DC w każdej domenie, wykorzystując topologię replikacji zdefiniowaną przez administratora i KCC. FRS używa RPC bez kompresji, więc może znacząco zwiększyć obciążenie sieci WAN.
Active Directory Connector (ADC) — jeśli używamy systemu Exchange Server 5.5, opcja ta prawdopodobnie będzie nam potrzebna prędzej czy później. ADC łączy się z Exchange Server 5.5, DC i GC za pomocą protokołu LDAP przez RPC.
Replikacje usługi DNS — jeśli nie zdecydujemy się wykorzystać opcji usługi DDNS zintegrowanej z Active Directory, potrzebna będzie odrębna topologia replikacji DNS.
Nie można obejść replikacji RPC w obrębie każdego obszaru (z powodu FRS), wobec czego bardzo trudno jest za pomocą zapór firewall podzielić różne podsieci w obrębie jednego obszaru na odrębne granice zabezpieczeń. Ściśle mówiąc, chociaż zapory można zaimplementować zawsze, nie będzie można ich zabezpieczyć do wysokiego stopnia, ponieważ cały ruch RPC musi przechodzić przez nie.
Po drugie, trzeba zapewnić dość wysoką stabilność łączy, ponieważ RPC cieszy się złą sławą małej tolerancji na niestabilne połączenia. Jednakże doświadczenia polowe pokazują, iż ulepszony stos TCP/IP w Windows 2000 znacznie zwiększa tolerancję Active Directory na złe warunki w porównaniu z poprzednimi wersjami.
I po trzecie, trzeba pamiętać że DC i GC Active Directory są dość gadatliwe. Domyślnie co 3 - 10 minut zachodzą wymiany kilku małych pakietów sieciowych, przez co serwery nie nadają się dla łączy telefonicznych. Chociaż bez wątpienia nie jest to problem dla dużych przedsiębiorstw, firmy małe i rozrzucone geograficznie może przyprawić o ból głowy.
Jak wspomniano w następnym podrozdziale - „Jak radzić sobie z wolnymi łączami WAN”, dostępnych jest kilka czynności pomagających poprawić tę sytuację. Chociaż w dużym stopniu zmniejszy to zużycie pasma przepustowości (oraz wrodzoną gadatliwość Active Directory), nie możemy oczekiwać uzyskania więcej niż 30 minut pomiędzy kolejnymi „sesjami pogaduszek”. A gdy zaczniemy dodawać aplikacje innych producentów, najprawdopodobniej okaże się, iż one też generują odrobinę „gadania”. Wobec tego, według mojego doświadczenia powinniśmy przywyknąć do faktu, iż usługa Active Directory nie jest stworzona dla linii telefonicznych.
Uwaga na pełne replikacje
Pełna replikacja do DC lub GC jest z pewnością najgorszym scenariuszem, z jakim możemy się zetknąć. Dlatego też należy wiedzieć, że następuje ona w poniższych sytuacjach:
Instalacja DC lub GC — przy każdej promocji serwera do statusu kontrolera domeny lub wykazu globalnego Active Directory zachodzi duży ruch replikacji. Dlatego też trzeba sprawdzić, kiedy replikacje będą przesyłane przez łącza WAN, a kiedy nie. Takie replikacje oczywiście czekają nas przy instalowaniu pierwszego DC lub GC w lokacji, lecz można się z nimi spotkać także w kilku innych sytuacjach.
DC był odłączony od sieci przez czas dłuższy od czasu chowania — każdy DC, który nie był połączony z innymi DC Active Directory dłużej niż wynosi okres chowania (tombstone period, domyślnie 60 dni), otrzyma pełną replikację z najbliższego DC (i GC) po ponownym przyłączeniu do sieci.
Zmiany w zestawie atrybutów replikowanych do GC — wszelkie zmiany w liście atrybutów dostępnych w GC powoduje synchronizację wszystkich GC w lesie.
Zazwyczaj rozsądnie jest zmienić wszystkie stosowne atrybuty zaraz po zainstalowaniu pierwszych dwóch DC i GC. Ponadto, aby nie przeciążać sieci WAN, można instalowac DC i GC w lokacji centralnej, a nie w miejscu przeznaczenia.
Microsoft nie bez podstaw twierdzi, że kontrolery domen i wykazy globalne są od początku zoptymalizowane pod kątem redukcji użycia sieci. Gdy więc zdecydujemy, jak często i w jakich porach dni tygodnia replikacje będą dozwolone dla różnych łączy replikacji międzylokacyjnych, nie pozostanie nam wiele do optymalizowania. W końcu replikacje są wynikiem codziennego zarządzania środowiskiem — czyli tworzenia i usuwania użytkowników, dodawania i usuwania przynależności do grup, tworzenia obiektów nie będących wystawcami zabezpieczeń (drukarek, woluminów, komputerów itp.) — dlatego nie można ich odkładać w nieskończoność.
Uwaga
Chociaż protokół SMTP lepiej toleruje niestabilne łącza, lecz zużywa więcej pasma (i jest znacznie trudniejszy do skonfigurowania). Nie należy więc nigdy używać SMTP, jeśli można tego uniknąć.
Pozostaje jednak jeszcze kilka możliwych skutecznych działań poza obszarem replikacji.
NetBIOS: wciąż żyje i ma się dobrze
Łatwo namierzyć administratorów obarczonych zadaniem optymalizacji użycia przepustowości sieci w domenach Windows NT 4. Wystarczy napomknąć coś o usłudze NetBIOS i łączności sieciowej, usiąść i zaczekać na reakcje. I w istocie zaszłości usługi NetBIOS nadal dręczą Active Directory mimo początkowych obietnic Microsoftu, iż Active Directory radykalnie zerwie z przeszłością pod względem łączności sieciowej.
Gdyby przyjrzeć się z bliska ruchowi w sieci, zauważymy że ukrywa się w nim sporo NetBIOS-u. Wobec tego śledząc łączność sieciową pomiędzy DC Active Directory zobaczymy mnóstwo pakietów protokołu NetBIOS.
Uwaga
Nawet jeśli nie mamy zbytniego doświadczenia z sieciami komputerowymi, całkiem łatwo można zorientować się we wkładzie łączności NetBIOS w obraz ogólny. Wystarczy zainstalować Monitor sieci i kazać mu obserwować wszystkie pakiety wychodzące z lokalnego DC (GC) gdy nikt nie korzysta z serwera, zanotować liczbę bajtów przesłanych w ciągu kilku godzin, wyłączyć NetBIOS w karcie sieciowej i ponowić pomiar.
Jeden powtarzający się zestaw pakietów NetBIOS-u wyróżnia się spośród innych — jest to ruch sieciowy przeglądarki głównej i przeglądarek zapasowych, który również w systemie Windows NT Server cieszył się złą sławą.
Co to jest przeglądanie? Przeglądanie (browsing) zachodzi, gdy użytkownik spojrzy na Otoczenie sieciowe. Chociaż opcja ta jest doskonała dla sieci równorzędnych LAN, w środowisku klient-serwer nie jest aż tak bardzo interesująca. Aby wydajnie lokalizować zasoby sieciowe, Microsoft Windows 2000 Server stosuje przeglądanie — podobnie jak jego poprzednik. Przeglądanie odbywa się przez łączenia klienta z przeglądarką główną (master browser) lub zapasową (backup browser). Jest ono ograniczone do własnej domeny lub grupy roboczej klienta. Wszystkie komputery ze składnikami serwerowymi — czyli zdolnością do udostępniania zasobów sieciowych — ogłaszają się w przeglądarce głównej swojej lokalnej domeny. Ponadto, serwery funkcjonujące w dowolnym stopniu jako przeglądarki potencjalne, zapasowe lub główne biorą również udział w kilku innych typach łączności:
Podstawy procesu przeglądania są następujące:
Wszystkie hosty posiadające składnik serwera — jak komputery z systemem Windows for Workgroups, Windows 95, Windows NT Workstation i Windows 2000 Professional — ogłaszają swoją obecność co 12 minut lokalnej przeglądarce głównej. Pozwala to zamieścić listę przeglądania dla domeny. Podział pojedynczej domeny przez rutery (co obecnie stanowi powszechnie spotykany scenariusz) utrudnia przeglądanie, ponieważ proces przeglądania opiera się na komunikatach rozgłoszeniowych. Lecz dzięki przeglądarce głównej i przeglądarkom zapasowym możliwe jest przeglądanie całej domeny w sieci WAN, nawet jeśli podsieci są oddzielone ruterami IP, za pomocą usługi WINS (która rejestruje przeglądarkę główną domeny). |
Przeglądarki dodają przynajmniej 17 kB ruchu sieciowego (do tego dochodzą wpisy w przeglądarce głównej oraz listach przeglądania domeny; każdy wpis w liście przeglądania zajmuje 27 bajtów plus ewentualne komentarze) za każdym razem, gdy wybierana jest przeglądarka główna. Domyślnie odbywa się to co 12 minut co oznacza, iż w ciągu godziny przez sieci WAN przechodzi około 85 kB danych tylko po to, by zadowolić usługę NetBIOS.
Przyznaję, że wartość ta nie wygląda z początku tak groźnie — w końcu to tylko marnowanie żałosnych 24 bitów na sekundę. Lecz ponieważ przeglądarka główna jest wybierana w każdej podsieci TCP/IP (oraz dla każdej domeny reprezentowanej w sieci, oraz dla każdego protokołu zainstalowanego i powiązanego z usługą), zobaczymy że NetBIOS dodaje 2 MB obciążenia na domenę w każdej lokalizacji WAN, dzień za dniem. Jeśli więc dana sieć składa się ze 100 lokalizacji (podsieci), w każdej przeciętnie DC dla dwóch domen z dwoma zainstalowanymi protokołami, codziennie marnuje się 800 MB ruchu sieciowego — a co gorsza, każde 200 MB z tego ruchu kieruje się do DC grającego rolę Emulatora PDC dla odpowiedniej domeny.
Na szczęście można bardzo łatwo pozbyć się wyborów przeglądarki głównej, jak również przeglądarki zapasowej, co możemy zrobić jednocześnie, ponieważ jedno i drugie modyfikowane jest za pomocą dwóch ustawień Rejestru:
MasterPeriodicity — ustala, jak często przeglądarka główna kontaktuje się z przeglądarką główną domeny. Wartość domyślna wynosi 720 sekund (12 minut), minimalna 300 sekund a maksymalna 0x418937 (4 294 967 sekund). Parametr dodawany jest jako REG_DWORD i może być zmieniany dynamicznie bez restartu komputera.
BackupPeriodicity — ustala, jak często przeglądarka zapasowa kontaktuje się z przeglądarką główną. Wartość domyślna BackupPeriodicity wynosi 720 sekund, minimalna 300 sekund a maksymalna 0x418937 (4 294 967 sekund). Parametr dodawany jest jako REG_DWORD i do zmiany wymaga restartu komputera. Parametr ten nie powinien wpływać na sieci WAN (pod warunkiem, że komputery należące do każdej podsieci nie są łączone siecią WAN), ponieważ przeglądarki zapasowe zawsze komunikują się z lokalną przeglądarką główną, nigdy ze zdalną. Lecz na wszelki wypadek warto zmienić też ten parametr.
Ostrzeżenie
Przeglądarka główna wymaga obecności usługi WINS, aby zlokalizować przeglądarkę główną domeny. Z tego powodu każda przeglądarka główna generuje mnóstwo błędów w każdej podsieci. Trzeba więc zająć się tą funkcją niezależnie od tego, czy w danej sieci działa usługa WINS czy nie.
Oba klucze Rejestru znajdują się w HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters. Aby mieć całkowitą pewność, że nie będziemy marnować na to przepustowości sieci, trzeba zmienić te ustawienia we wszystkich komputerach Windows (łącznie z klientami).
Ostrzeżenie
Jedyną alternatywą zmian w kluczach Rejestru jest wyłączenie składnika serwera lub protokołu NetBIOS we wszystkich komputerach w całej firmie. Ani jedno, ani drugie nie nadaje się do zastosowania w większości środowisk, zaś wyłączenie protokołu NetBIOS uniemożliwi komputerom pracę z innymi aplikacjami NetBIOSu — co nie jest zalecane, ponieważ dziesiątki tysięcy starych aplikacji NetBIOS nadal są w użytku.
Co trzeba wiedzieć o hasłach
Kolejnym zagadnieniem, któremu trzeba się przyjrzeć, jest traktowanie zmian haseł w naszych domenach. Chociaż hasła dla kont można zmieniać w dowolnym DC, zmiana ta zostaje natychmiast wysłana przez dany DC do kontrolera grającego rolę Emulatora PDC w danej domenie. Inaczej mówiąc, zależnie od ilości zmian haseł zachodzących w każdej lokalizacji, może występować spora liczba połączeń z DC grającym rolę Emulatora PDC, powodowanych zmianami haseł.
Powód jest prosty: musi dla haseł istnieć punkt odniesienia zapewniający, iż użytkownik który właśnie zmienił hasło w DC1 i próbuje zalogować się za pomocą DC2, do którego hasło nie zostało jeszcze replikowane, nie spotka się z potraktowaniem nowego hasła jako niepoprawnego (co może spowodować zablokowanie konta), tylko dlatego, że próbował z takiego czy innego powodu zalogować się do innego DC.
W systemie Windows NT 4 Server, jeśli uwierzytelnienie zawiedzie w BDC, przekazywane jest do PDC. Active Directory zachowuje się podobnie: próba uwierzytelnienia jest ponawiana w Emulatorze PDC, jeśli uwierzytelnienie zawiedzie w którymkolwiek innym DC. Jeśli możemy sobie poradzić bez zatrudniania Emulatora PDC w roli arbitra (i chcemy zaoszczędzić na łączności sieciowej zużywanej na przekazywanie nowych haseł), funkcjonalność tę można wyłączyć ustawiając wartość klucza Rejestru HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\AvoidPdcOnWan na 1 dla wszystkich DC w domenie. Parametr AvoidPdcOnWan („Unikaj PDC w sieciach WAN”) jest typu REG_DWORD i można go wyłączyć usuwając klucz Rejestru lub ustawiając wartość 0.
Proszę pamiętać, iż trzeba brać pod uwagę dwa rodzaje zmian haseł — użytkowników i komputerów — przy obliczaniu wykorzystania sieci WAN przez te zadania.
Wskazówka
Jesteśmy w stanie zaoszczędzić jeszcze trochę ruchu sieciowego zużywanego na zmiany haseł, przechodząc z Windows 9x lub Windows NT na Windows 2000 Professional, ponieważ wszystkie klienty inne niż Windows 2000 Professional usiłują łączyć się dla zmiany hasła bezpośrednio z serwerem grającym rolę PDC (jest to zaszłość z systemu Windows NT 4 Server).
Podobnie warto zwrócić uwagę, iż w Active Directory cztery typy zdarzeń wywołują natychmiastową replikację:
Blokada konta.
Zmiana klucza tajnego RSA.
Zmiany stanu w roli Menedżera RID.
Zmiany haseł międzydomenowych relacji zaufania (pomiędzy domeną A i B) z wszelkimi kontrolerami zapasowymi domen Windows NT 4 Server — tylko w przypadku domen Active Directory działających w trybie mieszanym.
Niestety nie można w tych czterech zdarzeniach niczego zoptymalizować. Jedyną pociechą jest fakt, iż wszelkie inne replikacje Active Directory zachodzą jedynie w odstępach czasu zdefiniowanych przez administratora.
Trzymać się z dala domeny głównej lasu
Inna technika optymalizacji warta wykorzystania koncentruje się na rekordach DNS. Po pierwsze, należy absolutnie upewnić się, by wszystkie stosowne rekordy DNS były składowane w jednym lub wielu bazach danych DNS w jednej lokacji, a nie rozrzuconych po sieci WAN. Warto też może zastosować opcję integracji usługi DNS z Active Directory (patrz rozdział 7.), aby zaoszczędzić sobie trochę pasma zużywanego na utrzymanie odrębnej topologii replikacji DNS oprócz topologii replikacji Active Directory.
Co może być jednak bardziej interesujące, należy oddelegować strefę _msdcs.<nazwa_lasu> i w każdej lokalizacji skonfigurować jeden lub kilka serwerów wtórnych DNS dla tej strefy. Powodem, dla którego zaoszczędzi to nieco cennej przepustowości łączy, jest fakt, iż wspomniana strefa DNS zawiera rekordy zasobów dla znajdowania DC i GC za pomocą identyfikatora GUID — jedne i drugie są często wyszukiwane przez DC i GC.
Uwaga
Taka technika pomoże zaoszczędzić na przepustowości łączy tylko wtedy, gdy las Active Directory zawiera więcej niż jedną domenę, lub jeśli nie używamy usługi DNA zintegrowanej z Active Directory.
Opcje usługi WINS
Jak wspomniano w rozdziale 7., należy zaimplementować usługę WINS w środowisku sieciowym, aby uniknąć wszelkich kłopotów związanych z wyszukiwaniem nazw NetBIOS. I podobnie jak w przypadku systemu Windows NT Server, należy włożyć trochę wysiłku w projekt, aby zmiany w bazie danych WINS nie były replikowane zbyt często (lub zbyt rzadko). Ponadto tylko serwery powinny rejestrować się w usłudze WINS, chyba że istnieje dobre uzasadnienie zezwolenia na to także klientom.
Jak radzić sobie z wolnymi łączami WAN
Z moich doświadczeń wynika, iż usługa Active Directory jest w istocie bardzo stabilna gdy ma do czynienia z wolnymi łączami. Replikacje sprawują się dobrze (chociaż ich dokonanie zajmuje sporo czasu) dla przepustowości nawet do 19 200 bitów na sekundę (b/s).
Błędy przekroczenia czasu oczekiwania zaczynają się przy łączach 9 600 b/s i 2 400 b/s, lecz takie szybkości transmisji nadal są zdatne do użytku, pod warunkiem zoptymalizowania stosu protokołu TCP/IP. Jednakże zależnie od ustawień (liczby obiektów zmienianych dziennie, ryzyka konieczności ponownej replikacji całego kontekstu GC, objętości ruchu sieciowego FRS itp.) może okazać się, że czas poświęcany na każdą replikację będzie tak długi, iż po prostu łącza nie da się wykorzystać w danej sytuacji.
Oprócz działań wspomnianych w poprzednim podrozdziale, aby zoptymalizować usługę Active Directory dla wolnych łączy WAN, należy także:
Dostosować stos TCP/IP do dokładnych właściwości wolnego łącza — Windows 2000 pozwala konfigurować mnóstwo nowych interesujących właściwości stosu TCP/IP w Windows 2000. W tym celu nalegam, by przestudiować publikację „Microsoft Windows 2000 TCP/IP Implementation Details” (obecnie dostępna pod adresem www.microsoft.com/Windows2000/library/howitworks/communications/networkbasics/tcpip_implement.asp), zwracając pilnie uwagę na skalowalne rozmiary okna TCP, opóźnione potwierdzenia (Delayed Acknowledgements) i wybiórcze potwierdzenia TCP (TCP Selective Acknowledgements).
Zoptymalizować usługę Czas systemu Windows — każdy DC usiłuje okresowo synchronizować swój zegar. Wolno podać, ile minut DC początkowo odczekuje w przypadku nieudanej synchronizacji czasu (w kluczu Rejestru HKLM\System\CurrentControlSet\Services\W32Time\Parameters\GetDcBackoffMinutes), gdzie wartość początkowa będzie podwajana przy każdej ponownej próbie. Możemy też podać maksymalną liczbę minut, przez jaką usługa Czas systemu Windows może czekać (w kluczu Rejestru HKLM\System\CurrentControlSet\Services\W32Time\Parameters\GetDcBackoffMaxTimes).
Zoptymalizować czas oczekiwania dla każdego logowania wykorzystującego usługę Netlogon — interwał oczekiwania, podany w sekundach, może być skonfigurowany w HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\ExpectedDialupDelay.
Zoptymalizować obsługę haseł przez Netlogon — usługa Netlogon wykonuje zestaw operacji „oczyszczania”, w których sprawdza, czy hasło dla kanału zabezpieczonego musi zostać zmienione, lub czy kanał zabezpieczony był przez dłuższy czas bezczynny, wysyła komunikat mail slot do każdej zaufanej domeny o nie odkryty DC (jeśli protokół NetBIOS jest załączony) i usiłuje dodać nazwę <domena>[1B] w usłudze WINS (jeśli NetBIOS jest aktywny). Zadania te są wykonywane domyślnie co 15 minut, lecz interwał ten można zmienić w HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\ScavengeInterval (podany w minutach).
Zoptymalizować dynamiczną rejestrację rekordów SRV dodawanych przez usługi DC i GC — wolno podać, jak często Netlogon ma próbować ponownie rejestrować wpisy w DNS-ie pod HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DnsRefreshInterval. Domyślnie ponowne rejestracje w usłudze DNS odbywają się w takich samych odstępach czasu, jak oczyszczanie. Dodatkowo można zmienić wartość atrybutu TTL (Time-to-Live - czas życia) przypisaną do wpisów DNS rejestrowanych przez Netlogon, ustalającą jak długo klientowi wolno używać tych wpisów DNS-u, modyfikując klucz Rejestru HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DnsTtl.
Zoptymalizować okres ważności sesji RPC — domyślnie system operacyjny zrywa wszystkie sesje RPC nieaktywne przez pięć minut. Ponieważ ustanawianie (i zrywanie) każdej sesji wymaga wymiany sporej ilości danych, należy wydłużyć znacznie obecny okres ważności wynoszący pięć minut za pomocą klucza Rejestru HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Replicator RPC handle expiry check interval. Trzeba też pamiętać o zmianie wartości klucza HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Replicator inter site RPC handle lifetime, który podaje taką samą wartość dla sesji RPC wewnątrz lokacji. Oba klucze Rejestru mają wartości podane w sekundach.
Na koniec powinniśmy jeszcze wyłączyć usługę przeglądarki (lub NetBIOS, jeśli to możliwe). NetBIOS można wyłączyć w oknie właściwości TCP/IP, podczas gdy usługę przeglądarki można wyłączyć tylko przez wprowadzenie klucza Rejestru "MaintainServerList"=No w HKLM\CurrentControlSet\Services\Netlogon\Parameters.
Poprawa wydajności DC i GC kosztem obciążenia sieci
Jak wspomniano w ostatnim podrozdziale, Microsoft z powodzeniem zoptymalizował kontrolery domen i wykazy globalne pod kątem minimalizacji obciążenia sieci. I chociaż są to dobre wieści dla każdego, kto chce obyć się najmniejszym możliwym ruchem danych w sieci, lecz jednocześnie oznacza to, iż dużo zostaje do zrobienia, jeśli chcemy uzyskać optymalną wydajność DC i GC (w tym jak najmniejsze opóźnienia w dystrybucji zmian) a pasma w sieci mamy pod dostatkiem.
Aby poprawić wydajność DC i GC w porównaniu z wynikami osiąganymi z ustawieniami domyślnymi, należy przyjrzeć się poniższym opcjom:
Rozmiary pakietów sieciowych.
Liczba dozwolonych pakietów po każdym potwierdzeniu (ACK) od odbiorcy.
Wyższy priorytet dla zadań replikacji (ewentualnie przez dodanie kolejnych procesorów).
Ustawienia opóźnień:
Gdy Active Directory nie spodziewa się kolejnych zmian.
Gdy kolejny partner replikacji jest powiadamiany o nowych zmianach.
Najważniejsze wskazówki
Zachowania bazy danych Active Directory wydają się wysoce przewidywalne (mniej więcej liniowy wzrost), co jest bardzo miłe. Jednakże przyszłe wymagania dla Active Directory nie wyglądają na tak łatwe do przewidzenia, ponieważ przypuszczalnie trzeba będzie implementować o wiele więcej rozszerzeń schematu (zarówno bezpośrednio, jak pośrednio — pochodzących od aplikacji korzystających z Active Directory).
Nalegam więc na dużą ostrożność w związku z przydziałem dostępnego miejsca na plik ntds.dit. Zasadniczo ilość miejsca na dysku powinna być przynajmniej dwukrotnie większa od szacunkowych rozmiarów bazy danych Active Directory, aby poradzić sobie z chowaniem (wszystkie usunięte obiekty domyślnie pozostają w bazie danych przez 60 dni), defragmentacją bazy danych i zwiększaniem rozmiarów w przyszłości w związku z obiektami i atrybutami. Należy zastanowić się też nad możliwościami jeszcze większego wzrostu, ponieważ nikt nie jest w stanie przewidzieć przyszłych rozmiarów bazy danych Active Directory: w dużym stopniu będą zależeć od tego, ile aplikacji innych producentów zostanie zintegrowanych z Active Directory w przyszłości oraz — w pierwszej kolejności — od motywacji firmy do dopuszczenia ich do Active Directory.
Uwaga
Okres chowania (tombstone lifetime) wynoszący 60 dni oznacza, iż przez pierwsze 60 dni istnienia kontrolera domeny rozmiary bazy danych będą się zwiększać, nawet po usunięciu dużej liczby obiektów. Po 60 dniach baza danych albo będzie pozostawać bez zmian, albo nieco urośnie. Fakt, iż plik nie zmniejsza objętości po usunięciu obiektów nie oznacza, że nie przybyło dostępnego miejsca — znaczy to tylko, że przestrzeń nie została odzyskana dla innych użytkowników, co wymagałoby dokonania defragmentacji w trybie offline.
Podczas szacowania rozmiarów bazy danych Active Directory należy posługiwać się poniższymi wytycznymi (które są, przyznaję, szacunkowe i zachowawcze, lecz lepiej dmuchać na zimne):
Początkowe rozmiary Active Directory: 10,5 MB.
Każdego wystawcę zabezpieczeń należy traktować jak obiekt typu użytkownika; każdy taki obiekt ma objętość 4,4 kB.
Inne jednostki nie będące wystawcami zabezpieczeń należy traktować jak obiekty OU; każda OU ma wielkość około 2,0 kB.
Dla delegowania praw dostępu, należy dodać 75 bajtów na każdy obiekt katalogowy objęty każdym nowym ACE.
Aby oszacować rozmiary własnych rozszerzeń atrybutów, dostępne obecnie informacje prowadzą do następujących wytycznych:
Każdy kolejny atrybut łańcuchowy dodaje około 100 bajtów do każdego obiektu, do którego jest dołączony (więcej, jeśli długość łańcucha przekracza 10 znaków).
Dane binarne zajmują w bazie danych o 25 do 40 procent więcej miejsca od własnych rozmiarów.
Aby oszacować rozmiary bazy danych Active Directory w organizacji można spróbować poniższej procedury:
Znajdź w tabeli 20.7 rozmiary najlepiej przybliżające wielkość firmy i zanotuj odpowiadające im rozmiary bazy danych.
Porównaj obiekty przewidziane do użytku z liczbą obiektów użytych w przykładzie. Dla dodatkowych obiektów będących wystawcami zabezpieczeń dodaj 4 400 bajtów na egzemplarz, dla pozostałych 2000 bajtów.
Porównaj liczbę atrybutów przeznaczonych do wykorzystania w każdym typie obiektu z liczbą atrybutów użytych w przykładzie. Dla dodatkowych atrybutów dodaj 100 bajtów na atrybut. Dla danych binarnych, np. zdjęć, dodaj rozmiary pliku z naddatkiem 35%.
Oszacuj liczbę ACE, które zostaną dodane do części obiektów w domenie. Dodaj 75 bajtów na ACE na obiekt.
Aby dobrze przygotować się na przyszłość, uzyskane podstawowe rozmiary należy przynajmniej podwoić (lub potroić).
Na koniec proszę pamiętać by wziąć pod uwagę dodatkowe miejsce dla DC grającego równocześnie rolę GC. Szacowanie rozmiarów dla GC jest trochę zbyt skomplikowane z uwagi na liczbę parametrów, które trzeba uwzględnić. Jednakże próbując ustalić dodatkowe obciążenie powodowane przez GC można przyjrzeć się następującym czynnikom:
Ile obiektów mieści się we wszystkich domenach lasu?
Jakie grupy są najczęściej używane — uniwersalne czy globalne? Grupy uniwersalne są przechowywane w GC (czyli trzeba wziąć poprawkę na liczbę członków każdej grupy), podczas gdy dla grupy globalnej tylko nazwa jest rejestrowana w GC. Grupy uniwersalne są porównywalne z globalnymi pod względem ilości miejsca zajmowanego w bazie danych.
Ile atrybutów jest replikowanych do GC i ile z nich jest w przybliżeniu używanych (przez co zajmują cenną przestrzeń w bazie danych)?
Czy schemat był zmieniany, aby pomieścić w GC atrybuty domyślnie nie replikowane?
W bardzo dużym przybliżeniu powinniśmy spodziewać się skopiowania około 50 % każdej domeny do GC. Wartość ta wzrośnie w przypadku użycia grup uniwersalnych, ponieważ są one składowane razem ze swoimi członkami w GC zamiast DC. Lecz z uwagi na bardzo złożoną naturę procesu poprawnego szacowania rozmiarów GC, trzeba tu postępować bardzo ostrożnie. Ponadto GC wymaga o wiele więcej miejsca niż DC, jeśli do jednego lasu należy kilka bardzo dużych domen.
Windows 2000 Server stosuje dwa typy replikacji DC i GC: wewnątrzlokacyjną i międzylokacyjną. Należy zawsze dążyć do użycia replikacji międzylokacyjnej pomiędzy fizycznymi lokalizacjami połączonymi łączami WAN, ponieważ ten typ replikacji dokonuje kompresji danych przesyłanych łączem i daje o wiele łatwiejszą i bardziej szczegółową kontrolę nad przepływem danych przez łącze. Warto skorzystać z tej kontroli aby zapewnić, by replikacje zachodziły w porach dnia najmniej obciążonych i najrzadziej jak można — dzięki czemu najwydajniej wykorzystamy kompresję danych.
Dla replikacji międzylokacyjnej GC mamy wybór między RPC i SMTP. Należy zawsze decydować się na transport RPC, ponieważ powoduje mniejszy ruch sieciowy. Transport SMTP można wykorzystać tylko przy braku łączności IP lub bardzo zawodnym łączu.
Próbując oszacować obciążenie replikacjami w danym środowisku proszę pamiętać że, oprócz przyłączania nowej domeny i podobnych sytuacji, rozmiary replikacji zależą od liczby obiektów zmienianych w Active Directory podczas każdego cyklu. W dużych instalacjach zmiany haseł (każde hasło zajmuje 400 do 600 bajtów; zaś zmiana pojedynczego hasła około 1,8 kB) są najważniejszym źródłem powtarzających się zmian.
Ostrzeżenie
Zaleca się bardzo uważać w stosunku do przeprowadzanych przez administratorów i aplikacje zmian w liście atrybutów replikowanych do GC (tzn. opcji Replikuj ten atrybut do Wykazu globalnego).
Każda zmiana w zestawie atrybutów replikowanych do GC wywołuje pełną replikację wszystkich danych składowanych w GC. I jak widać, może to być tak dużo danych, iż sieci WAN mogą zostać na jakiś czas zatkane!
Tabela 20.12 zawiera podsumowanie objętości danych przesyłanych siecią w wyniku replikacji najczęściej występującego obiektu katalogowego - użytkownika. Proszę jednak zauważyć, iż w rzeczywistości wykorzystanie łączy na replikację podanych liczb użytkowników powinno być niższe, ponieważ rzadko kiedy przeprowadzana jest zmiana wszystkich atrybutów dla wielu obiektów użytkowników jednocześnie, która mogłaby sprowokować replikację całego obiektu.
Tabela 20.12
Możliwe scenariusze replikacji z różną liczbą obiektów użytkowników
Liczba użytkowników |
DC wewnątrz lokacji |
DC między lokacjami |
GC wewnątrz lokacji |
GC między lokacjami za pomocą RPC |
GC między replikacjami za pomocą SMTP |
1 |
13 kB |
14 kB |
12 kB |
13 kB |
22 kB |
10 |
47 kB |
46 kB |
36 kB |
36 kB |
53 kB |
100 |
386 kB |
40 kB |
273 kB |
32 kB |
60 kB |
1 000 |
3 818 kB |
291 kB |
2 641 kB |
234 kB |
440 kB |
Ostrzeżenie
Jest jeden bardzo ważny wyjątek od reguły replikacji przez Active Directory tylko danych, które uległy zmianie, obejmujący wszystkie grupy. Ponieważ członkowie każdej grupy są zapisani w atrybucie wielowartościowym, cała lista członków jest replikowana przy każdej zmianie członkostwa — jeśli więc dodamy pojedyncze konto użytkownika do grupy zawierającej 5 000 członków, cała lista 5 001 użytkowników będzie replikowana w całym zasięgu grupy (co tłumaczy się na przesłanie po kablu więcej niż 2 MB danych).
Z tego powodu Microsoft radzi utrzymywać jak najmniejsze możliwe rozmiary grup, a szczególnie powstrzymać się od tworzenia dużych grup uniwersalnych. Warto zauważyć, iż funkcjonalność zagnieżdżania grup (tylko dla domen w trybie macierzystym) pozwala na podział jednej dużej grupy na wiele mniejszych.
Mało znany szczegół dotyczący zmiany haseł Proszę nie myśleć, iż tylko hasła użytkowników trzeba brać pod uwagę. Każdy komputer Windows 2000 (oraz Windows NT) również posiada konto komputera z hasłem, które trzeba często odnawiać. Dla każdego komputera Windows 2000 należącego do domeny tworzony jest dyskretny kanał łączności (kanał zabezpieczony) z DC przy uruchomieniu komputera. Hasło kanału zabezpieczonego jest składowane razem z kontem komputera we wszystkich DC, a przez to replikowane w całej domenie. Domyślnie komputer wysyła zmianę hasła kanału zabezpieczonego co 30 dni i hasło konta komputera zostaje zaktualizowane. Inaczej mówiąc, w domenie zawierającej 1 000 komputerów zmiana hasła konta komputera zachodzi przeciętnie co 43,2 minuty. Nie jest to wyłączna cecha Windows 2000 — podobnie jest z Windows NT. Jednakże w NT domyślna częstotliwość aktualizacji hasła to raz na siedem dni, co pogarsza liczbę zachodzących replikacji. |
Podsumowanie
Wymagania przestrzeni dla bazy danych Active Directory są dość łatwe do ustalenia pod względem wzrostu — można je przybliżyć liniowo, co powinno pocieszyć każdego zaangażowanego w projektowanie Active Directory. Jak na razie nic nie wskazuje na poważniejsze niedociągnięcia Active Directory w tym zakresie.
Obliczenie dość dokładnie przybliżonych rozmiarów bazy danych dla DC jest stosunkowo łatwe, podczas gdy rozmiary GC obecnie jest trochę trudniej przewidzieć. Proszę pamiętać, iż użytkownicy nie są w stanie logować się, jeśli nigdzie w sieci WAN nie jest dostępny GC, więc dojście do ograniczeń przestrzeni dyskowej dla GC jest równie fatalne jak dla DC. Ponadto Exchange 2000 Server dodaje mnóstwo atrybutów do GC, ponieważ jest zależny od GC przy udostępnianiu klientom Outlooka globalnej listy adresowej (GAL - Global Address List) i odpowiadaniu na zapytania, co zwiększa dość znacznie obciążenie wykazów globalnych w porównaniu z „czystą” usługą Active Directory.
Ponieważ większość firm nie osiągnie w najbliższym czasie katalogu 100 000 użytkowników, wypada tu zanotować, iż pod względem zapotrzebowania na przestrzeń dyskową wymagania sprzętowe DC nie są zbyt oszałamiające — w większości przypadków baza danych będzie miała znacznie poniżej 1 GB. Aby jednak obniżyć koszt posiadania tych systemów, należy dążyć do przydzielenia trzy- lub czterokrotnie więcej przestrzeni dyskowej niż wynoszą początkowe rozmiary bazy danych. Dodatkowo dla dużych lub intensywnie używanych DC i GC należy przechowywać bazę danych i pliki dziennika na odrębnych dyskach fizycznych, aby uzyskać lepszą wydajność i stabilność.
Obciążenie sieci replikacjami Active Directory powinno być dość przewidywalne pod warunkiem, iż znane są nam rozmiary obiektów i atrybutów składowanych w Active Directory, oraz szybkość ich zmian. Jednocześnie należy pamiętać by unikać dodawania nadmiarowych informacji lub wielu dużych obiektów do Active Directory, ponieważ prowadzi to do niepotrzebnego wzrostu obciążenia replikacjami.
Szacowanie rozmiarów DC i GC Jeśli dostaniemy za zadanie ustalić wymagania sprzętowe serwerów odpowiedzialnych za uruchomienie Active Directory (oraz utrzymanie usługi w dobrej kondycji), należy wypróbować narzędzie Microsoftu Active Directory Sizer Tool (ADSIZER). Narzędzie to pozwala oszacować parametry sprzętu wymaganego do uruchomienia Active Directory w organizacji na podstawie szeregu dość trudnych pytań, sprawdzających profil organizacji, strukturę domen i topologię sieci. Trzeba podać całkowitą liczbę równoczesnych użytkowników, dzienną liczbę połączeń telefonicznych, średnią liczbę grup do których należy użytkownik, przeciętną liczbę logowań na sekundę w godzinach szczytu, liczbę komputerów Windows 2000 w domenie, liczbę innych komputerów w domenie, czy Exchange 2000 Server będzie wdrożony, oraz mnóstwo innych podobnych danych. Na podstawie dostarczonych informacji ADSIZER poda szacunkowo:
Dodatkowo ADSIZER podaje szacunkowe wartości dla:
Chociaż ADSIZER jest sympatycznym narzędziem, które pozwoli ściąć kilka zakrętów, nie powinniśmy pokładać pełnej wiary w samo to narzędzie. Po pierwsze, jego zasięg ograniczony jest do jednej domeny; po drugie, nie stanowi zastępstwa dla doświadczeń z rzeczywistą instalacją Active Directory w określonych warunkach. ADSIZER można pobrać za darmo z adresu www.microsoft.com/windows2000/downloads/deployment/sizer/default.asp. |
2 Dokument1
engine wg. Dużego słownika informatycznego. „Silnik” nie bardzo mi się podoba.
Nie jestem pewien terminologii.
Nie jestem pewien.
?
Nie najszczęśliwszy termin moim zdaniem, ale tak chce słownik...
Nie wiem, dlaczego M$ wybrał takie tłumaczenie...
”Czas życia nagrobka”.... hmm...
mogą utracić?
lub: ogólnego
Niedostępny :(
white pages?
Tu i dalej: mam pewne wątpliwości co do pomiarów...
lub: ogólne (można tłumaczyć na 2 sposoby)
„zbliżony”???
Raczej nie „mierzy”
W oryginale rozruch komputera.
Dodałem.
Przyznaję ze wstydem — nie znam polskiego odpowiednika
Tak rozumiem „everything”
?
Na pewno?
Nie znam polskiego odpowiednika.
W oryginale obiektów