AD KCC & Bridge All Site Links Behaviour
KCC sau Knowledge Consistency Checker este procesul ce ruleaza pe domain controllere si care este responsabil de crearea si modificarea conexiunilor de replicare dintre DC-uri.
Nota: In AD nu este nevoie sa faceti conexiuni de replicare manual. KCC se ocupa de asta daca stiti sa il influentati in asa fel incat sa lucreze pentru voi. De regula cand se creaza conexiuni manual, se creaza si probleme.
Astazi o sa ma folosesc de urmatorul exemplu in care am trei site-uri A,B,C unde B este HUB site iar A si C se conecteaza la el. Fiecare site contine doar un domain controller DC1, DC2, DC3, exact ca in imaginea de mai jos.
La nivel de Active Directory in Site and Services am definit doua site link-uri, fiecare ce contine doar site-urile ce se vor replica direct.
Iar efectul acestor configurari se poate vedea in conexiunile de replicare facute de KCC.
Dupa cum se vede si mai sus nu exista conexiuni directe intre Site A si Site C.
Pe acest exemplu o sa incerc sa explic ce se intampla atunci cand DC-ul din site-ul central (Site B) nu mai este disponibil.
In titlu ati observat ca m-am referit si la optiunea Bridge All Site Links ce este ACTIVATA by default.
Prima data o sa va spun ce se intampla daca ati dezactivat aceasta optiune (nerecomandat) si DC2 devine indisponibil. Raspunsul e simplu, replicarea nu mai merge intre nici un site iar KCC nu va face nimic pentru a remedia acest lucru. Si bineinteles ca veti vedea mesaje in event viewer asemanatoare cu acesta:
In schimb daca activa Bridge All Site Links, la urmatoarea rulare a KCC acesta va genera un link de replicare temporar intre site-urile A si C.
Iar in momentul in care DC2 revine online, KCC va sterge conexiunea nou creata.
Intr-un mediu de test sau intr-unul foarte strict monitorizat si in care se intervine foarte repede, acest comportament este destul de greu de observat. Asta pentru ca exista cateva reguli ce trebuiesc indeplinite inainte de a efectua acesta masuri corective. Si anume trebuie sa exista macar o incercare de replicare esuata (si schedule-ul trebuie sa permita) si sa fi trecut cel putin 2 ore de la ultima replicare efectuata cu succes. Plus ca mai exista si intervalul de 15 minute la care ruleaza KCC. De aici si motivul pentru care nu prea vedem foarte des aceste masuri corective.
Iar acesta este scenariul simplu. Pentru ca daca in HUB Site avem mai multe DC-uri, atunci se va face fallback la urmatorul DC din site (si nu la urmatorul site) respectand regulile de mai sus (timpul explicat in regula de mai sus se va multiplica pentru fiecare DC din site). Abia cand au fost incercate toate DC-urile din site-ul central fara succes, abia atunci intreg site-ul va fi considerat deconectat si se va face failover catre alt site. Deci daca intreg site-ul a picat e posibil sa asteptam multe ore pana cand o sa vedem o conexiune temporara creata de KCC.
Dar exista si metode de a grabi acest proces. Si anume prin urmatoarele valori de tip REG_DWORD ce le gasiti in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters:
IntersiteFailuresAllowed
Value: Number of failed attempts
Default: 1
MaxFailureTimeForIntersiteLink (sec)
Value: Time that must elapse before being considered unavailable, in seconds
Default: 7200 (2 hours)
Pentru mai multe detalii despre aceste setari dar si despre KCC in general va recomand urmatorul link: http://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx
PS: Scenariul merge pe premiza ca exista conectivitate IP si intre site-urile A si C. KCC va incerca sa conecteze direct cele doua site-uri chiar si daca nu exista conectivitate intre ele atata timp cat optiunea Bridge All Site Links este activa.