Dyskusyja ostatnio rozgorzała na forum wss.pl o tym jakie to wnętrzności w taki kontroler domeny włożyć dla danej liczby użytkowników. Dyskusyja forumowa jak każda taka tendencje miała do zbaczania ale też przyniosła przepisów kilka – od prostych po wykwintne bardzo, rdzeniami usiane jak dobre ciasto i przykryte grubymi plastrami RAMu. Okazja jest więc się znowu uzewnętrznić – to jak z tworzeniem tego DC jest?
Disklajmer zwyczajowy: poglądy tutaj przedstawiane są wynikiem moich własnych przemyśleń i doświadczeń. Wierzyć w nie można albo i nie. Jeżeli ktoś zastosuje się do tychże w swoich działaniach to robi to na własną odpowiedzialność, a jeżeli odpowiedzialności chce mojej – proszę bardzo, mogę przygotować projekt.
Z usługą katalogową i jej skalowaniem problem jest taki, że Microsoft jako taki nie opublikował czegoś na kształt “przewodnika skalowalności”. Najbliższym wydawnictwem w tym zakresie jest “Active Directory Performance for 64-bit Versions of Windows Server 2003”. I potem to już nic. Oczywiście byłoby miło takie przewodnik, uzależniony od ilości obiektów (bo to jest wyznacznik pewien) lub użytkowników (a to inny). Ano i właśnie, względem czego skalować taki DC?
Niby kontroler domeny rzecz prosta, ale DC może być DC nie równy. Inny jest profil obciążenia kontrolera domeny pracującego w biurze oddziałowym obsługującym niewielką liczbę użytkowników. Inny dla kontrolera domeny, który obsługuje również użytkowników, ale w centralnej lokacji, do której potencjalnie mogą trafić użytkownicy z innych lokacji.
Inny dla Exchange, inny dla kontrolerów domeny obsługujących aplikacje (co jest nagminne – znaczy się wyznaczanie konkretnych kontrolerów domeny dla aplikacji, jak i często mocno obciążające ponieważ aplikacje bywają źle napisane). Inny też dla kontrolerów domeny w hubie obsługujące replikację danych w sieci.
Jak widać profili obciążenia tak prostej usługi jak DC może być sporo. Dla którego więc stworzyć takie zalecenia? Ano właśnie … to może bardziej ogólnie porozmawiajmy. Na jakie elementy skalowania kontrolera domeny należy zwracać uwagę? I jak.
Procesory …
… liczba rdzeni, procesorów i szybkość. To, co porywa administratora. Pytanie czy kontroler domeny jest usługą mocno obciążającą procesory? Przy obecnych procesorach, w większości przypadków w zasadzie nie i przy standardowym użyciu DC w celu obsługi logowania użytkowników rzadko raczej procesor będzie wąskim gardłem DC. Jeżeli posłużymy się wspomnianym wcześniej artykułem jako pewnego rodzaju wzorcem, to osiągane tam wysokie obciążenie procesorów występowało dla baz danych o liczbie obiektów odpowiednio 100k i 3 mln, które w naszych warunkach często nie występują. Ale i testy wykonywane były lat temu 4 kiedy procesory słabsze były. A wymagania DC się zbytnio nie zmieniły.
Oczywiście w naszej sieci należy wziąć pod uwagę syndrom siódmej rano (wszyscy naraz się logują), awarie (DC w branch office może paść i obsługę przejmie DC w centrali), dla kontrolerów domeny w centrali wymaganie na liczbę partnerów replikacji i czas replikacji jak i wymagania dotyczące D&R ( o tym słów jeszcze kilka dalej).
Skalując procesory dla kontrolerów domeny w danej lokacji należy wziąć pod uwagę również wymagania aplikacji, które w niej mogą pracować. Jeżeli wiemy, że w danej lokacji pracuje kilkanaście aplikacji mocno używających zapytań LDAP to uwzględnijmy to w konfiguracji DC i monitorujmy wydajność zapytań na nich przetwarzanych. Jeżeli tworzymy lokację dla Exchange, weźmy pod uwagę zalecenia co do liczby rdzeń dla GC obsługujących Exchange.
Jeżeli planujemy wdrożenie na DC oprogramowania antywirusowego, to należy założyć, że dla AV wymagany będzie jeden dodatkowy rdzeń, jak i należy pamiętać o wykluczeniach związanych z działaniem AV na DC.
Mierzmy też siły na wymagania – jeżeli mamy biuro oddziałowe z 50 użytkownikami, to o ile w ogóle rozważać postawienie tam DC to nie będzie on miał wymagań takich jak serwer w centrali obsługujący kilka tysięcy ludzi.
Pamięć …
Skalowanie w przypadku pamięci jest bardzo proste. Dostępna w systemie pamięć RAM powinna pozwalać na przechowanie w pamięci jak największej części bazy danych NTDS.DIT. W najlepszym wypadku całości. W trakcie pracy kontrolera domeny wyniki poszczególnych zapytań są przechowywane w pamięci RAM tak długo jak nie należy jej zwolnić. Ponieważ operacje dyskowe są drogie, to przechowywanie wyników odczytanych z dysków w pamięci znacznie wpływa na wydajność działania kontrolera.
Tak że reguła kciuka jest taka, że w kontrolerze domeny rozmiar pamięci powinien być zbliżony (w domyśle równy lub wyższy) rozmiarowi pliku NTDS.DIT (a w zasadzie ilości danych w tym pliku).
Jak w przypadku każdej dobrej reguły należy do niej podejść z rozsądkiem i przewidzieć wyjątki. Nawet jeżeli nasz DIT ma 2 GB a kontroler domeny będzie stał w lokacji z małą liczbą użytkowników i nie działają tam katalogożerne aplikacje, to raczej nigdy cały DIT nie zostanie w pamięci załadowany. Tak że z rozsądkiem drodzy projektujący AD.
Dyski …
W idealnej sytuacji na kontrolerze domeny baza danych NTDS.DIT powinna być na osobnych spindlach niż logi tejże bazy danych. Tak by było perfekcyjnie. Pytanie czy to jest zawsze wymagane. I jak powyżej – wszystko zależy od konkretnego przypadku. Jeżeli nasza sieć ma kilkuset użytkowników to praktycznie nie ma to większego znaczenia. Jeżeli ma ich kilka tysięcy – na tych kontrolerach domeny, które będą obsługiwały ich większąliczbę lub aplikacji – może to być wskazane. Przy dużych liczbach użytkowników – zalecane jak najbardziej a nawet wymagane jeżeli planujemy wszystko tak jak być powinno.
To o bazie danych DIT, ale nie zapominajmy, że na DC dyski to nie tylko DIT ale i SYSVOL. A SYSVOL potrafi rosnąć (chociaż da się to ograniczać) i może wymagać dodatkowej przestrzeni w procesie replikacji danych na staging area. To należy uwzględnić przy planowaniu ile przestrzeni dyskowej jest wymagane.
Wszerz czy wzwyż…
Czyli jak naszą agrokulturę DC hodować – ilościowo czy na masę? W zasadzie usługi kontrolerów domeny skalować się powinno w większości wypadków wszerz, czyli z punktu widzenia i wydajności i redundancji usługi lepiej jest postawić tych kontrolerów kilka niż jedną super maszynę.
Oczywiście skalowanie w siłę też wymagane być może w połączeniu ze skalowaniem wszerz nawet, jeżeli w naszym środowisku działają aplikacje, które mocy przetwarzania zapytań LDAP lub liczy uwierzytelnień w sekundzie wymagają dużej. Wtedy nie pozostaje nam nic innego, niż gdy osiągamy granice wydajności sprzętu po prostu go przeskalować pod obciążenie.
Sama wydajność to nie wszystko …
Zapewnienie odpowiedniej wydajności pod konkretne obciążenie robocze to nie wszystko. W większych środowiskach należy dodatkowo pomyśleć o tym, jak wyglądać będzie procedura odbudowy usługi katalogowej czy odbudowy SYSVOL. Które DC będą brały w nim udział i jak to wpływa na wymagania, co do ich wydajności, skalowania dysku i pamięci. Tworząc plany z tym związane, należy zwrócić uwagę właśnie na takie elementy, aby w chwili krytycznej okazało się, że DC który wyznaczyliśmy do roli serwera, z którego odtwarzany jest SYSVOL nie posiada odpowiedniej ilości miejsca na dyskach do obsłużenia tego procesu.
I to by był koniec …
Wyszedł z tego bardzo konsultancki wpis pod wezwaniem “To zależy”, ale taka jest też i natura zagadnienia, którego on dotyczy. Oczywiście dla małej sieci, z niedużą liczbą użytkowników można po prostu określić metodą ekspercką (palec mokry na wiatr wystawiony bardzo dobrze się w tej roli sprawdza), na podstawie doświadczenia parametry dla kontrolera domeny. Dla większego lub bardziej skomplikowanego pod względem liczy i jakości usług środowiska jednak poświęciłbym chwilę na to, aby elementy opisane powyżej przeanalizować, zanim wystawione zostanie zamówienie na te wszystkie błyszczące zabawki i radiatory.
… gdyby nie wirtualizacja
Czyli jak skalowanie fizycznego DC ma się do DC wirutalnego. W testach dla Hyper-V w wersji 2008 wykazano że DC wirtualny operuje na około 90% mocy fizycznego o tych samych parametrach. W chwili obecnej jednak wpływ wirutalizacji na wydajność DC jest w zasadzie pomijalny, o ile zapewnione są odpowiednie zasoby po stronie hosta utrzymującego te zasoby wirtualne.
P.S. #1 Dla tych którzy byli na MTS 2010 nadal aktualne zostaje przypomnienie o ankietach, które być może nadal czekają na wasze oceny. Pamiętajcie o nich – do 27-go października linki pozostają aktualne. Ogólny link do ankiet po konferencji jak i bezpośredni do moich dwóch sesji:
Podobało się, nie podobało – wejdź, wypełnij.