Friday, October 22nd, 2010...11:22 pm

Kilogram dysku, procesorów pięć sztuk, posypać RAMem czyli przepis na DC

Jump to Comments

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?

(cc) melomane

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.

5 Comments

  • Z doświadczenia wiem, że to dywagacje raczej akademickie, bo większość obecnego sprzętu klasy serwer bez żadnego tuningu spokojnie i bez spocenia się (a wręcz nudząc się) uciągnie z 98% różnych AD, które zostanią zaprojektowane. Przy pozostałych 2 % i tak pewnie będą konsultanci MS 🙂
    Ale mam też 3 grosze. Z wirtualkami – to zależy 🙂
    Ostatnio robiliśmy testy pewnych rozwiązań z wykorzystaniem wirtualnych DC. Osoba testująca aplikację zakomunikowała nam wyraźny i zauważalny spadek wydajności rozwiązania po wskazaniu jakiegoś wirtualnego DC. Faktycznie – farma jes u nas mocno utylizowana. Więc jeśli jest możliwość zagwarantowania zasobów to OK, jeśli nie to zonk…
    PS1: Pierwszy raz widzę regułę kciuka nie w lengłydżu, strasznie mnie zaskoczyła w tej formie 🙂
    PS2: Fajne słowo ci wyszło – proceros 🙂 Takie hiszpańskie 😉

  • Bastiuszu, Ty to wiesz, ja to wiem … a ludzie nadal się pytają i odpowiedzi są różne. Przykładem najlepszym jest ten wątek na WSS.PL. Zauważ co tam zostało zaproponowane – nie wiem czy Wy nawet macie taki sprzęt w tej chwili :). Dlatego pomyślałem, że się w temacie spiszę.

    Z drugiej strony u Was jest to nieźle poukładane ale w są w PL i takie środowiska gdzie DC jest 300+ i na przykład jeszcze na W2000. I w takim hubie replikacji to już o skalowanie odpowiednie DC to warto zadbać. Więc jak konsultant powiem – jak zwykle to zależy :).

    Co co Twoich 3 groszy to bardzo cenne bo wynikające z praktyki. Ciekawsze by było gdyby wiadomo było, czy spadek wydajności wynikał tylko z natury wirtualności czy też dlatego, że host utrzymujący tą VM takie tylko zasoby mógł jej przydzielić w danym momencie i na przykład odczyt z dysku szybszy być nie mógł. A to na zapytania LDAP w szczególności wpływać może (BTW – w W2008R2 a to już macie są dodatkowe statystyki, które pokazują też liczbę odczytów z dysku przy zapytania LDAP – chyba nawet wystawione w perfmon).

    Co do hiszpańskiego słowa – czas nauczyć się jezyków, zacznę od polskiego. Dzięki 🙂

  • Ja nie do treści nawet, bo tu ani dodać ani ująć nic nie mógłbym. No może chciałbym poczytać Tomka jeszcze więcej 🙂
    Ja ze swoją minikrucjatą językową…
    Bastiusz pisze: “farma jes u nas mocno utylizowana”. To chyba dobrze… Złom elektroniczny (a takim na pewno są stare DC) zaśmieca środowisko i właściwa utylizacja jest naprawdę istotną kwestią. http://sjp.pwn.pl/szukaj/utylizacja
    I tak oto polszczyzna zdominowała technologię. Ale to chyba dobrze 😉

  • […] Poprzedni wpis był poniekąd teoretyczny i ten też taki trochę będzie. A i temat będzie taki, który już kiedyś poruszałem. Co ja poradzę, że pytania w temacie przychodzą  i  przychodzą. Temat dzisiejszego odcinka – po co komu dodatkowy kontroler domeny? Dzisiaj może  w trochę innym ujęciu – jak przekonać kogoś, że takowy jest nam w firmie potrzebny. […]

  • Tomku, niestety to była produkcja, więc nie za bardzo dają się nam na takich systemach “wyżyć”. Po stwierdzeniu, że zmiana nie odniosła zamierzonego skutku trzeba zrobić rollback. Ups – wycofać zmianę 🙂 He he, Grzesio, uderzę się w pierś 🙂 Też jestem zwolennikiem poprawnego pisania. Oczywiście, że “utylizacja” powinno zabrzmieć inaczej… Niestety pewnie to wina obcowania ze zbyt dużą ilością tekstów w barbarzyńskich językach i podświadome dążenie do skrócenia przekazu.

    Ale ostatnio usłyszałem od jednego znajomego, że jego inny kolega z pracy, który mocno stara się zaprzestać stosowania takich różnych kalk językowych (zresztą to zalecenie szefa) powiedział: “udało mi się sfokusować na tym, żeby zamiast autentykacja używać słowa uwierzytelnianie”. Po tym jak to powiedział to podobno po prostu usiedli z niemocy i śmiechu 🙂 Smaczek – cała trójca jest z byłej tomkowej korporacji-matki. Przypuszczam, że po części spowodowane jest to znaczącą obcojęzycznością komunikacji wewnętrznej w firmie.

    Jeszcze powrócę na chwilę do takich DC 300+ środowisk: przy dzisiejszych cenach łączy telekomunikacyjnych, kosztach utrzymania sprzętu (licencje, wsparcie, prąd, czasami klima) oraz kosztach jego szeroko pojętej obsługi (wystarczy comiesięczne aktualizowanie) policzenie prostego ROI dla konsolidacji pokaże, że nie ma ŻADNEGO ekonomicznego uzasadnienia trzymanie takiego środowiska. A już Windows 2000? Toż to chociażby z punktu widzenia wsparcia systemu (a właściwie jego braku), możliwości wdrożenia nowszych produktów (w zasadzie również jej braku) czy też zwykłej replikacji – co najmniej nieodpowiedzialność.

    Pamiętam jak u nas zaczynaliśmy wycinkę od DC ~170, ostało się w sumie 10 do obsługi produkcji i 4 pomocnicze (domena nadrzędna i domena testowa). I działa. W dodatku już w tej ilości wszystko jest na podwójnym zapasie (w razie padu jednego całego datacenter – opcja “nieostrożny operator koparki” – będzie działać drugie).

    Ale czy faktycznie da się aż tak zmniejszyć ilość DC? To oczywiście zależy! 🙂

Leave a Reply