Одна з головних рекомендацій Microsoft щодо Active Directory Domain Services (ADDS) говорить про необхідність розгортання у виробничому середовищі мінімум двох контролерів домену. Реальна ж життя показує, що в середніх і великих компаніях кількість контролерів може досягати декількох десятків і навіть сотень. Коли системний адміністратор починає працювати у великій мережі на базі ADDS однією з найважливіших турбот стає реплікація Active Directory.
І навіть якщо врахувати, що цей механізм повністю автоматизований і при правильній початкової конфігурації рідко вимагає втручання, не варто забувати про такі реалії життя як вимикання світла, повільні і нестабільні канали, помилки адміністраторів і просто позаштатна робота служби, викликана спалахами на сонці або місячним затемненням . Якраз для боротьби з перерахованими вище недугами і необхідне розуміння механізмів реплікації, а також способів управління нею.
Вперше з'явившись в Windows Server 2000 технологія Active Directory (це перш за все транзакційна база даних містить інформацію про об'єкти вашої мережі і глибоко інтегрована з системою безпеки Windows) більш ніж за 9 років зазнала деяких змін, але навіть в Windows Server 2008 R2 працює на добре зарекомендував себе движку Extensible Storage Engine (ESE). Якщо вірити розрахункам масштабованості, даного рішення повинно вистачити навіть мереж з декількома мільйонами об'єктів, а вирости база, може до 16 терабайт. Серцем Active Directory є файл NTDS.DIT в якому, власне кажучи, вся інформація і зберігається. При додаванні другого і наступних контролерів домену відбувається створення копії даного файлу, і розміщення її на введеному в дію новому контролері. Тобто можна зробити чіткий висновок: кожен контролер домену зберігає свою версію файлу NTDS.DIT.
Важливо розуміти, що при відкритті оснащення для роботи з Active Directory, а це може бути Active Directory Користувачі і Комп'ютери або як варіант Active Directory Сайти та сервіси, ви завжди підключаєтеся до конкретного контролера домену та при бажанні можете вибрати з яким контролером працювати - це означає , що виробите з конкретною версією бази даних, яка в даний момент може відрізнятися від інших копій. Природно створюючи обліковий запис або змінюючи конфігурацію, зміни вносяться тільки в один файл NTDS.DIT, який знаходиться на контролері, куди підключена оснащення (або будь-який інший інструмент управління). Після внесення змін критично важливо оповістити інші контролери про зміни і нових даних і як можна швидше провести синхронізацію. У Active Directory цей процес синхронізації називається реплікацією і надалі я буду використовувати саме цей термін. Особливо важливо пам'ятати ці факти, коли ви займаєтеся вирішенням проблем з реплікацією Active Directory і вносите зміни в контекст конфігурації AD. Це відбувається теж на конкретному контролері і з конкретним файлом NTDS.DIT.
Фізично NTDS.DIT це просто один файл, але логічно він складається з декількох розділів (іноді їх називають контекстами іменування або контекстами реплікації), кожен з яких містить певну інформацію і реплицируется по-своєму.
Розділ «Schema» - зберігає в собі схему ActiveDirectory, яка описує, які об'єкти можуть бути створені, і що вони з себе представлятимуть. Змінюється найрідше, як правило, при переході контролерів на нову операційну систему або при установці в організації поштової системи Exchange. Процес зміни бази даних в контексті схеми найчастіше називають розширенням схеми і це не випадково, тому що скасувати ці зміни (наприклад, видалити створені в цьому контексті об'єкти) неможливо. Реплікація розділу здійснюється на всі контролери домену в лісі Active Directory. Єдиний розділ, чия реплікація не є мультімастерной. Реплікація розділу «Schema» завжди одностороння і виконується від контролера домену, який володіє роллю FSMO Господар Схеми, на все решту контролери домену. (Згодом залишилися контролери домену реплікують інформацію своїм репликационная партнерам, але джерелом поновлення в цьому ланцюжку реплікації завжди буде Господар схеми)
Мал. 1 Розділи бази Active Directory
Розділ «Configuration» - містить інформацію про конфігурацію Active Directory, зокрема описує, які і скільки доменів створено, як вони між собою пов'язані, скільки існує сайтів, які сервіси доступні в організації і просто системні настройки служби каталогів такі як квоти, політики LDAP- запитів, правила неточного пошуку, розпізнавання імен об'єктів і т.п .. Розділ реплицируется між усіма контролерами доменів в лісі і може бути змінений на будь-якому контролері домена. Зміни даного розділу пов'язані з конфігурацією і налаштуванням самої Active Directory.
Розділ «Domain» - або доменний. Усі облікові записи користувачів, групи безпеки, організаційні підрозділи, об'єкти комп'ютерів і принтерів створюються і зберігаються в даному розділі. Реплицируется розділ тільки між контролерами домену в тому домені до якого належить контролер. Виходить, що в організаціях, що мають кілька доменів, в кожному домені буде свій розділ «Domain».
Розділи «Application» - опціональні розділи. Зона реплікації залежить від настройки. Як правило, створюється два Application розділу, це ForestDNSZones і DomainDNSZones.
· ForestDNSZones - зберігає SRV і CNAME записи для Ліси AD і реплицируется на всі контролери домену в лісі, є DNS серверами.
· DomainDNSZones - містить DNS записи для зони домену. Реплицируется на всі контролери домену з встановленим на них DNS сервером.
Подивитися на кожен розділ каталогу і дані в ньому зберігаються можна через утиліти ADSI Edit AdExplorer і LDP.exe. Утиліту (AdExplorer) можна завантажити з сайту Microsoft, вона входить в комплект утиліт Sysinternals. А LDP.exe стає доступна після установки на контролер домену Windows Support Tools. Слід зазначити, що даний комплект не втратив своєї актуальності і після виходу Windows Server 2008.
Мал. 2 Вибір розділу для підключення в утиліті LDP.exe
Тепер важливо усвідомити таке, коли клієнт аутентифицирующей на контролері домену, і застосовуються групові політики, утворюється трафік (85 Кб на вхід станції в домен (з Default Domain Policy) і 75Кб на вхід користувача (теж з Default Domain Policy)). Більш того реплікація змін між контролерами доменів породжує свій реплікаційний трафік. Цим трафіком потрібно управляти, уявіть собі, що організація і природно ваш домен Active Directory розташовується в двох містах пов'язаних WAN каналом і одного разу все користувачі філії в Ростові-на-Дону почнуть звертатися до контролера, розташованого в центральному Московському офісі. А контролери домену почнуть реплицировать інформацію в будь-який час і за першим бажанням. Мінімум з чим Вам доведеться зіткнутися це висока утилізація WAN каналу і повільний вхід користувачів в домен.
Тому в Active Directory введено поняття Сайтів. Сайт це логічне об'єднання контролерів домену та клієнтів для управління службовим трафіком служби каталогів. Якщо ваш Ліс Active Directory не поширюється за межі одного сегмента локальної мережі, отже, ви працюєте з односайтовой структурою. Саме вона є дефолтной і саме з неї ми почнемо розмову.
При створенні Active Directory і піднятті (мається на увазі процедура dcpromo) першого контролера домену формується сайт за замовчуванням з ім'ям «Default-First-Site-Namе». Якщо не створювати додаткових сайтів і дотримуватися односайтовой структури, все нові контролери будуть потрапляти в даних сайт. Після появи другого і наступних контролерів повинні утворитися репликационная зв'язку (connection objects), які вказують на те який контролер і звідки повинен реплицировать зміни. Подивитися ці зв'язки можна через оснащення "Active Directory Сайти та Служби».
На Рис.3 відкрита оснащення «ActiveDirectoryСайти і Служби» і за наявною інформацією можна сказати, що в даному прикладі є єдиний сайт за замовчуванням, в якому знаходиться два контролера домену Server1 і Server2. А так же, що Server1 має партнера по реплікації Server2 і реплицирует з нього зміни. Без наявності даних зв'язків реплікації між контролерами працювати не буде.
Нерідкі випадки коли системні адміністратори, встановивши новий контролер домену, не знаходять у нього даних зв'язків і починають створювати їх руками. Це поширена помилка. За створення зв'язків, базуючись на певній логіці, відповідає служба KCC (Knowledge Consistency Checker). Створенню зв'язків самостійно може призвести до виникнення помилок і подальшої плутаниною. Для тих же, хто не хоче чекати, поки KCC впорається із завданням, існує спосіб її поквапити.
Мал. 3 Властивості репликационная зв'язку.
Для цього необхідно використовувати утиліту Repadmin з ключем kcc. Синтаксис буде виглядати наступним чином:
repadmin / kcc server1.itband.ru (Замість server1.itband.ru ви вкажете FQDN вашого сервера)
Якщо потрібно запустити генерацію зв'язків на всіх контролерах домену в сайті, то команда Repadmin набирає вигляду:
repadmin / kccsite: «Default-First-Site-Name» (Якщо ім'я сайту було змінено «Default-First-Site-Name» замінюється реальні ім'ям)
Можна так само запустити процес генерації топології на всіх контролерах лісу командою repadmin / kcc *. Більшість опцій команди repadmin підтримують ключ / async, який дає завдання контролера домену та при цьому не очікує його завершення.
Без адміністративного втручання служба KCC стартує на кожному контролері домену раз в 15 хвилин і в разі потреби додає або видаляє зайві Реплікаційний зв'язку (врахуйте, що зв'язку, створені вручну, не справляються KCC). Логіка створення зв'язків в рамках одного сайту здається досить простий, кожен контролер НЕ реплицируется з кожним, служба KCC завжди намагається створити кільце реплікації, причому в міру додавання нових контролерів кільце буде розширюватися. Розширення не безкінечна, при створенні зв'язків існує «правило трьох стрибків». Це означає, що між двома контролерами домену при реплікації не може бути більше трьох посередників.
Мал. 4 Принцип створення зв'язків реплікації службою KCC
Як тільки число контролерів досягне 8 штук, правило «трьох стрибків» призведе до того, що служба KCC виконає «хід конем» і додасть додаткові прямі зв'язки, тим самим скорочуючи відстань між двома будь-якими контролерами до допустимого значення «максимум в три стрибки». Дана ситуація добре проілюстрована на малюнку 4. Створення зв'язків між контролерами розташованими в різних сайтах виконується з урахуванням топології сайтів, сайт-лінків і мостів між сайт-лінками. Детальніше про побудову межсайтовой реплікації читайте в розділі «міжсайтовий реплікація». Слід зазначити, що кільце при побудові топології реплікації будуватися незалежно для кожного контексту реплікації (розділу Active Directory) далі ці кільця накладаються один на одного і з'ясовується, де можна замість декількох Реплікаційний зв'язків - обійтися однією.
Внутрісайтовая реплікація починається, коли в Active Directory відбувається зміна, це може бути зміна атрибута або створення облікового запису. Контролер домену, в базі якого відбулися зміни, очікує 15 секунд, а потім відправляє найближчого партнера реплікації повідомлення про те, що на ньому відбулося якесь оновлення. При наявності двох і більше партнерів по реплікації, наступні повідомлення відправляються кожному партнеру з 3-секундною затримкою (Вірно для рівня лісу Windows 2003 і вище, для Windows 2000 первинна затримка становить 300 секунд, а наступні 45 секунд). Після отримання повідомлення про зміну партнер реплікації перевіряє можливість реплікації і список оновлень і виконує процес реплікації з тим контролером, який надіслав повідомлення. Трьох секундна затримка запобігає надмірну завантаження через одночасних запитів оновлень від безлічі партнерів по реплікації. Періоди нотифікацій можна налаштувати командою repadmin / notifyopt.
Слід звернути особливу увагу читачів, що процес реплікації ЗАВЖДИ відбувається в режимі pull, тобто «Стягування» змін і нових об'єктів, але не в режимі push. Це пов'язано з тим, що тільки контролер господар файлу NTDS.DIT має право в ньому щось змінювати і відповідає за цілісність своєї БД. З цього так само слід, що ВСЕ лінки реплікації які, створюються в ручну або службою KCC мають односпрямовану природу, тобто логічно позначають вхідний потік репликационной інформації.
Деякі зміни реплицируются без 15-секундної затримки. Така реплікація, звана строкової (urgent replication). У події її викликають входять блокування облікових записів, зміна пароля облікового запису. В офіційних документах присутній плутанина. По суті це не реплікація зовсім і механізм передачі цих змін в корі відрізняється від процесу реплікації. Хоча в якості транспорту використовується теж протокол RPC. Така реплікація виконується не звичайним механізмом реплікації, а спеціальними викликами RPC. По суті це запити аналогічні зміни об'єктів через ADSI. Залежно від режиму роботи лісу список подій може змінюватися.
Якщо уважно придивитися до властивостей репликационной зв'язку, то можна знайти розклад реплікації, за замовчуванням воно встановлено на щогодинний запуск. Виникає питання: Навіщо ще одне розклад якщо є система повідомлень?
Мал. 5 Розклад реплікації
Даний розклад є основним і обов'язковим способом реплікації. Незважаючи на те, що система повідомлень, описана вище, в більшості випадків забезпечує синхронізацію до запуску цього розкладу, вона не гарантує успіх. Можлива ситуація коли контролер домену буде зайнятий online дефрагментацією бази, перерахунком зв'язків службою KCC і просто проігнорує необхідність обробити прийшли до нього повідомлення про зміни на партнерах по реплікації. У такій ситуації зміни будуть прореплікувалися протягом години.
При виникненні труднощів з реплікацією можна використовуючи утиліту replmon вручну запустити процес реплікації не чекаючи розкладу:
repadmin / replicate server2.itband.ru server1. itband.ru dc = itband, dc = ru
З ключем / replicate необхідно задати куди (server2.itband.ru) і з якого контролера (server1.itband.ru) повинні реплицироваться дані, а також який розділ каталогу потрібно реплицировать (dc = itband, dc = ru).
Запустити реплікацію всіх розділів Active Directory в рамках усього лісу (в рамках існуючої топології) досить легко, для це слід виконати: Repadmin / syncall / AeS. Врахуйте, що в великих мережах такий запуск реплікації може викликати серйозний потік трафіку, який піде не тільки по швидкісним каналам.
Алгоритм поширення змін
Тепер необхідно розібратися, як після отримання Реплікаційний повідомлення від партнера контролер домену вирішить: Є чи ні зміни необхідні для реплікації? Якщо є те, які об'єкти або їх окремі атрибути повинні бути прореплікувалися. Алгоритм виглядає наступним чином.
Будь-контролер домену веде якийсь лічильник званий «highestCommittedUSN», який збільшується на одиницю при будь-якому атомарному зміні бази Active Directory. При цьому у кожного контролера домену цей лічильник свій і між контролерами його значення не збігаються. Наприклад, в 9 ранку значення «highestCommittedUSN» у контролера DC1 дорівнювало 14879, а в 6 вечора 14896. Це означає, що за минулий час в базі цього контролера сталося 17 змін. Подивитися значення «highestCommittedUSN» можна за допомогою утиліти ldp просто підключившись до потрібного контролера домену. При підключенні виводитися стан динамічного системного об'єкта RootDSE, серед атрибутів якого як раз і є присутнім «highestCommittedUSN».
Мал. 6 Перегляд значення «highestCommittedUSN» на контролері домену.
Після проведеної реплікації кожен контролер домену кешируєт значення «highestCommittedUSN» своїх Реплікаційний партнерів. І коли після контролер домену DC1 отримає повідомлення від контролера DC2 в ньому буде інформація про поточний «highestCommittedUSN» DC2. Контролера DC1 залишиться тільки порівняти поточний «highestCommittedUSN» з тим, який він закешовану під час минулої реплікації. Якщо він виріс: значить в базі DC2 відбулися зміни і необхідно зробити реплікацію. Якщо залишився колишнім, то в ній немає необхідності.
Таблиця, в якій зберігається інформація про «highestCommittedUSN» Реплікаційний партнерів називається вектором поновлення або «up-to-date vector». Подивитися її можна за допомогою утиліти repadmin.
repadmin / showutdvec dc1 dc = lab, dc = itband, dc = ru
Default-First-Site-Name \ DC2 @ USN 16667 @ Time 2009-09-21 1:24:15
Default-First-Site-Name \ DC1 @ USN 20704 @ Time 2009-09-21 1:31:25
В даному прикладі результатом буде висновок значень «highestCommittedUSN» Реплікаційний партнерів DC1 (а також актуальний USN його самого), при цьому це будуть значення, про які DC1 знає, насправді вже вони могли вирости через внесення зміни в базу на тих контролерах. Слід пам'ятати, що «highestCommittedUSN» збільшується як після змін внесених в базу безпосередньо на контролері, так і після змін прореплікувалися з інших контролерів.
Мал. 7 Перегляд вектора оновлень на контролері DC1.
Є одне але, сам по собі «up-to-date vector» відповідає на питання «Чи були зміни?». Цього недостатньо, необхідно обчислити що змінилося. Давайте розглянемо цей механізм на прикладі.
У Нашій мережі находится два сінхронізованіх контролера домену (DC1і DC2). До змін «highestCommittedUSN» у DC1 дорівнює 20902, а у DC2 16940. На контролері DC1 створюється обліковій Запис користувача Федя Рашпін. Після створення облікового запису «highestCommittedUSN» на DC1 став показувати 20909. Це говорить про те, що було вироблено 7 змін. Нагадую, що вважаються атомарні зміни, тобто створення облікового запису можна розкласти на саме виробництво плюс зміна ряду атрибутів, які виконує оснащення Active Directory Users and Computers.
Якщо підключитися через LDP.exe до нашого об'єкту користувач, то можна побачити два атрибути uSNCreated і uSNChanged.
Мал. 8 Перегляд атрибутів uSNCreated і uSNChanged для облікового запису.
uSNCreated буде говорити, який «highestCommittedUSN» був в момент створення об'єкту на даному контролері, а uSNChanged в момент останньої зміни. Виходить, що перший показник (uSNCreated) буде залишатися незмінним, а другий в свою чергу (uSNChanged) у міру оновлень об'єкта буде рости. Важливо розуміти, що uSNCreated і uSNChanged на кожному контролері домену у об'єкта будуть свої.
Подивимося на користувача Федя через утиліту repadmin. Для отримання службової інформації, використовуваної при реплікації задіємо ключ / showmeta.
repadmin / showmeta "CN = Федя Рашпін, OU = testou, DC = lab, DC = itband, DC = ru"
При цьому нас цікавить інформація з кожного контролера. Але почнемо з DC1.
Мал. 9 Висновок метаданих про створеному користувача на DC1.
Яку ж інформацію нам дає repadmin (Рис. 9). Цей список не що інше, як об'єкт користувача, розкладений по атрибутам.
По кожному атрибуту можна побачити:
· Loc.USN це «highestCommittedUSN» контролера DC1 в момент внесення останніх змін.
· Originating DC говорить про те, на якому контролері були зроблені останні дії з цим атрибутом, тобто звідки пішло поширення.
· Org.Usn це «highestCommittedUSN» контролера автора змін в момент внесення останніх.
· Ver - версія атрибута, зростає на одиницю при кожному його зміні (локально або в результаті реплікації).
· Attribute - безпосередньо назва самого атрибута.
Поглянувши на цю таблицю можна зробити висновок, що користувач «Федя Рашпін» був створений (або змінений) на контролері домену DC1, при цьому побачити, що «highestCommittedUSN» DC1 в процесі створення облікового запису ріс від 20904 до 20909. (Org.USN)
Збіг колонок Loc.USN і Org.USN говорить про те, що запуск repadmin / showmeta проведений на контролері домену, який був автором змін. Якщо виконати те ж саме на другому контролері, результат буде дещо іншою.
Мал. 10 Висновок метаданих про створеному користувача на DC2.
На DC2 чітко проглядається, що автором всіх змін (крім одного) був DC1 і його «highestCommittedUSN» (Org.Usn) в момент зміни кожного атрибута. А також «highestCommittedUSN» в момент внесення оновлень в базу контролера DC2. (Loc.USN)
А ось тепер пора зробити невеликий висновок:
Коли контролер домену розсилає репликационная партнерам повідомлення про оновлення бази, він повідомляє свій поточний «highestCommittedUSN». Партнер, який отримав повідомлення про втрату чинності, порівнює цей «highestCommittedUSN» з тим, що він запам'ятав з минулого процедури реплікації. Якщо він виріс, значить необхідно запускати реплікацію. Наприклад: DC2 отримав від DC1 повідомлення і поточний «highestCommittedUSN» рівний 20912, він порівнює з відомим йому значенням 20850. Робить висновок про необхідність реплікації і запитує зміни, що відбулися в період зростання «highestCommittedUSN» з 20850 до 20912.
DC1 здійснює вибірку зі своєї бази. Для цього проглядається Loc.USN і ті атрибути, які змінювалися в заданому діапазоні «highestCommittedUSN» реплицируются на DC2.
рішення конфліктів
Не виключена ситуація коли один і той же атрибут буде змінюватися одночасно на двох і більше контролерах домену. Як бути в такій ситуації. Існує строгий механізм вирішення конфліктів.
Правило перше: Можна було помітити в метаданих реплікації параметр Ver. Як вже було сказано, він збільшується на одиницю кожного разу при зміні атрибута. Якщо відразу на двох контролерах відбувається зміна атрибута, в першу чергу буде проведено порівняння номера версії. Атрибут, що має більш високий номер версії, є пріоритетним. І саме його значення буде використовуватися.
Правило друге: Якщо номер версії збігається, враховується час зміни атрибута. Значення, встановлене за часом останнім виграє. У гіпотетичній ситуації, коли зміни атрибута на різних контролерів мають один номер версії, так і зроблені в один час переможе той контролер, який має більший номер GUID. Можливо кілька цікавих ситуацій. Один адміністратор вирішує видалити пусте організаційне підрозділ, інший же на сусідньому контролері в цей час створює обліковий запис. Виходить явний конфлікт інтересів.
У такій ситуації буде задіяний прихований контейнер LostAndFound, отримати доступ, до якого можна тільки переключивши оснащення «Active Directory - користувачі і комп'ютери» в розширений режим.
Мал. 11 Контейнер LostAndFound.
Новий створений користувач буде переміщений в даний контейнер, а організаційне підрозділ видалено. Згодом адміністратор перенесе обліковий запис в більш відповідне місце.
Інший вид розбіжностей може виникнути в разі одночасного створення об'єктів з однаковими іменами, це може бути підрозділ або обліковий запис користувача. У такій ситуації принцип досить простий, об'єкт, створений першим, перейменовується, точніше до його імені додається objectGUID. Якщо необхідність в цьому об'єкті згодом збережеться, ніщо не заважає адміністратору дати йому нове ім'я.
Мал. 12 Автоматичне вирішення конфлікту
Великою перевагою з точки зору реплікації є перехід на режим роботи домену Windows Server 2003 і більш пізні. У них змінилася процедура реплікації атрибутів типу «linked-valued» (приклад «Членство в групах»). При додаванні різних користувачів на різних контролерах в одну й ту ж саму групу результатом буде членство всхе доданих користувачів в складі цієї групи. У випадку з Windows 2000 склад групи при такому конфлікті визначався б за її членства на те контролері, на якому зміни в групі були б зроблені пізніше за часом.
На цьому хотілося б закінчити першу частину статті, в наступній частині ми поговоримо про побудову сайтів і особливості межсайтовой реплікації.
Ілля Рудь
Костянтин Леонтьєв
http://kleontiv.spaces.live.com/
Стаття опублікована в журналі "Системний адміністратор" від 01.2010
Виникає питання: Навіщо ще одне розклад якщо є система повідомлень?
<
