Мережеві сервісиWindows 2012 - реплікація Active Directory - Self Engineering
Шлях саморозвитку ІТ інженера
Мережеві сервіси Windows 2012 – реплікація Active Directory

Нарешті зібрався переписати свої нотатки на тему з чернетки в зошиті в електронний формат. Викласти постарався максимально коротко та ємно.
- Основні відомості
- Механізми реплікації
- 2.1 Внутрішньосайтова реплікація
- 2.2 Міжсайтова реплікація
- Діагностика реплікації
1. Основні відомості
Всі дані Active Directory зберігаються у спеціалізованій базі даних на движку ESENT. Фізично вона є файлом NTDS.DIT. Всі зміни в AD виробляються на конкретному контролері домену і вносяться до його NTDS.DIT і потім ці зміни передаються інші контролери домену.
Логічно база даних складається з чотирьох розділів:
Schema - містить опис об'єктів та їх атрибутів, які можуть бути створені в AD. Змінюється рідко - при процедурі розширення схеми, яка проводиться, наприклад, при встановленні MS Exchange або апгрейді ОС контролерів домену. Розширення схеми необоротне, його не можна відкотити, крім методу відновлення всіх DC, що встигли реплікувати дані, з бекапу. Реплікацію цього розділу може ініціювати лише контролер домену, що має роль Schema master. Реплікується попри всі контролери лісу.
Configuration — містить відомості про конфігурацію AD (скільки доменів, сайтів, сайтлінків тощо). Ініціатором реплікації може бути будь-який DC. Реплікується попри всі контролери лісу.
Domain - містить облікові записи (користувачів, групи, комп'ютери, принтери ...). Ініціатором виступає будь-яка DC. Реплікується на всі контролеридомену.
Application — розділ для зберігання даних якимись програмами, що не належать до AD безпосередньо. Зокрема, якщо ви вибрали в налаштуваннях DNS-зони «інтегрована в AD», вона зберігається тут. Реплікація залежить від налаштування.
Реплікація між контролерами відбувається не аби як і не за принципом «кожен з кожним», а на основі реплікаційних зв'язків. За створення відповідає сервіс KCC (Knowledge Consistency Checker). Він стартує на кожному контролері домену раз на 15 хвилин і додає або видаляє необхідні зв'язки. Так що немає нічого страшного, якщо відразу після встановлення нового DC у мережі, він ще не вважається нічиїм партнером реплікації. Подивитися та налаштувати зв'язки можна в оснастці Active Directory Sites and Services.
Зв'язки створюються сервісом KCC на підставі правила "трьох стрибків" - тобто, щоб від одного контролера домену до будь-якого іншого було не більше трьох переходів або двох посередників.
Слід пам'ятати, що зв'язку, створені вручну, сервісом KCC не управляються, тобто відновлювати їм заміну, у разі недоступності одного з партнерів по реплікації, сервіс не буде.
Можна не чекати 15 хвилин і ініціювати створення зв'язків силами KCC примусово:
repadmin /kcc - примусове створення зв'язку для
repadmin /kccsite - примусове створення зв'язків для всіх DC у сайті
repadmin /kcc * – запустити процес на всіх контролерах доменів у лісі.2. Механізми реплікації
На кожному контролері домену ведеться облік кількості змін за допомогою лічильникаhighestCommittedUSN. Створення/зміна об'єкта включає створення/зміну кількох атрибутів, кожне з яких збільшує високізведені USN на 1. Кожен атрибут, крім інших, має параметри:
Loc.USN — значення лічильника highestCommittedUSN поточного контролера домену (що приймає змінені дані під час реплікації).
Подивитися атрибути та значення їхніх параметрів об'єкта можна командою repadmin / showmeta. Наприклад:
repadmin /showmeta "CN=User1,OU=TestOU,DC=contoso,DC=com"
У ході реплікації, контролер домену кешує значення високих об'єднаних своїх партнерів. При наступному сеансі він порівнює значення закешування з поточним. Якщо нове значення більше попереднього, цільовий контролер вирішує стягнути зміни. Для цього вихідний контролер робить вибірку об'єктів і атрибутів, у яких Loc.USN більше, ніж останній високимкомітетомUSN.
У разі конфліктів:
- порівнюється параметр Ver конфліктного атрибута. Чий вище, той і має рацію.
- якщо Ver рівні, порівнюється час зміни. Чиє пізніше, той і має рацію.
- якщо час дорівнює, то правий буде контролер домену з великим GUID.
- У випадку, якщо на двох контролерах одночасно створили обліковий запис з однаковим ім'ям, раніше буде перейменовано (старе ім'я+GUID контролера)
- У випадку, якщо на одному контролері в якійсь OU створюється об'єкт, а на іншому в цей же час видаляється OU, об'єкт, в ході реплікації, буде перенесений у службовий контейнер "Lost and Found"
Реплікація завжди відбувається в режимі Pull (витягування), оскільки кожен контролер одноосібно відповідає за цілісність бази даних.
Примусовий запуск реплікації:
repadmin /syncall — синхронізація вказаного сервера з усіма реплікаційними партнерами.2.1 Внутрішньосайтова реплікація
Через 15 секунд після внесення змін, контролер домену повідомляє своїх партнерів про необхідністьреплікації. Якщо партнерів кілька, то кожному наступному сповіщення надсилається з 3-секундною затримкою.
repadmin /notifyopt - Налаштування таймінгів оповіщень.
Зміна пароля користувача та блокування облікового запису ініціюють реплікацію без 15-секундної затримки.
Крім того, реплікація відбувається за розкладом щогодини. На випадок, якщо під час ініціювання реплікації зміни, цільовий контролер був недоступний або був зайнятий дефрагментацією бази.2.2 Міжсайтова реплікація
Для реплікації між сайтами створюються зв'язки сайтів (Site Link), в яких задається розклад («вікно» протягом якого можлива реплікація та періодичність), протокол (SMTP або IP) і вартість (Cost). За умовчанням створена DEFAULTIPSITELINK з використанням IP та реплікацією раз на 180 хвилин. Переглянути зв'язки або створити нові можна в оснастці Active Directory Sites and Services.
Вартість зв'язків враховується при виборі шляху реплікації — якщо від одного сайту до іншого можна дістатися різними шляхами, обраний буде той, вартість якого буде меншою. Якщо ціни рівні, вибирається шлях із меншою кількістю стрибків. Якщо вони рівні, вибирається просто на ім'я сайту (порівняння рядків).
За реплікацію між сайтами відповідають не всі поспіль контролери доменів, а в кожному сайті вибирається спеціально навчений - Bridgehead (сервер плацдармів). Тобто саме він займається реплікацією змін даного сайту з аналогічним bridgehead'ом іншого сайту. Як і у випадку реплікаційних зв'язків між контролерами доменів, за вибір сервера-плацдарму відповідає служба KCC. Так само ця служба не працює з призначеними вручну Bridgehead'ами і якщо така вийде з ладу, реплікація швидше за все буде неможлива (якщо небув також вручну призначений ще один-кілька).
repadmin /bridgeheads — переглянути поточні сервери плацдармів.
Варто також згадати тут таке явище, як Site Link Bridging — зв'язок між Site1 і Site3 через мережу Site2, але минаючи контролери домену, розташовані в Site2. Тобто використовуючи лише мережу, що маршрутизується. Це за умови, що між Site1 та Site3 прямого зв'язку немає, а контролери домену в Site2 з якоїсь причини виявилися недоступними.
Такий бриджинг налаштовується також автоматично горезвісною службою KCC. Можна вимкнути (галочка у властивостях протоколу-транспорту в оснастці Active Directory Sites and Services). На жаль, автоматизація включається/вимикається тільки повністю для всіх сайтів. Однак, можна створити вручну лише для потрібних, попередньо відключивши автоматику.
Якщо контролери домену в проміжному сайті знову повернулися в роботу, то й автоматичні та створені вручну мости перестають використовуватись і реплікація йде своїм природним шляхом.
На малюнку спочатку статті можна побачити два такі мости - від DC3 до DC2 і від DC8 до DC1.3. Діагностика реплікації
Докладно розписувати процедури діагностики я не буду — розуміючи механізми роботи DNS та реплікації, знаючи потрібні інструменти, базові дії зробити праці не складе.
Як відправна точка для діагностики, непоганою ідеєю буде використовувати аналіз логів Directory Services на проблемному контролері домену.
Також допоможе dcdiag /test:connectivity, а також nslookup як засіб перевірки правильної роботи DNS.
Ну і звісно repadmin. Частина його ключів описана вище, ще частину можна побачити у довідці (repadmin/?), а дещо – у розширеній довідці (repadmin/?/experthelp).