Оптимальне розміщення серверів глобального каталогу, windows it pro

Надіслати заявку на отримання матеріалів

У глобальних каталогах зберігаються всі об'єкти лісу, але тільки частина атрибутів цих об'єктів. GC містить часто запитувані атрибути, які називаються частковим набором атрибутів. Сервери GC роблять доступною інформацію про ці атрибути через протокол Lightweight Directory Access Protocol (LDAP) і використовують реплікацію для відправки часткових даних кожного домена на всі інші GC. Запити до GC володіють однією перевагою перед запитами до контролерів доменів (DC): контролери доменів зберігають інформацію тільки про власні доменах, в той час як GC містять інформацію про всі доменах лісу.

Зміна часткового набору атрибутів

Наступна процедура дозволяє визначати, які атрибути повинен включати GC. Для її здійснення потрібно оснащення Microsoft Management Console (MMC) Schema, яку необхідно попередньо зареєструвати. Для цього слід ввести в командному рядку

Після успішної реєстрації з'явиться відповідне повідомлення.

Існує ще одна вимога, яке належить виконати, перш ніж можна буде вносити зміни в схему: в реєстрі DC, що виконує роль Flexible Single-Master Operation (FSMO), слід створити новий параметр. Як завжди, потрібно дотримуватися обережності при внесенні змін до реєстру. Слід створити параметр Schema Update Allowed (типу REG_DWORD) зі значенням 1 в розділі HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters. Зміна вступає в дію негайно, без перезавантаження. Завершивши зміна схеми, цю можливість на DC потрібно відключити, змінивши значення параметра на 0.

Ніколи не слід змінювати налаштування за замовчуванням без вагомих на те підстав. Додавання ще одного атрибута в частковий набір атрибутів може помітно вплинути на реплікацію в мережі внаслідок так званої повної синхронізації вмісту GC. Реакцією кожного GC на додавання атрибута є виконання реплікації з повним оновленням міститься в ньому доступною тільки для читання інформації про інших доменах лісу. Чим більше доменів має ліс, тим значнішими будуть наслідки. Краще взагалі не вносити ніяких змін в частковий набір атрибутів у виробничому середовищі без настройки розкладу. Якщо ліс однодоменних, про наслідки повної синхронізації GC можна не турбуватися, оскільки GC не містять інформації про інших доменах і, отже, не виробляють реплікацію додаткової інформації. Не варто зайвий раз видаляти атрибути з GC - це може вплинути на ефективність системи.

Екран 1. Реплікація атрибутів на GC

включення GC

В оснащенні AD Sites and Services потрібно розкрити Sites. Вибравши вузол, слід відкрити його і вибрати DC. Далі потрібно натиснути правою кнопкою NTDS Settings, після чого на сторінці властивостей General буде відображатися параметр, який дозволяє включити (прапорець встановлено) і відключити (прапорець знято) використання даного контролера домену в якості GC. Просто установка прапорця в цьому осередку не означає, що GC став доступний і готовий до роботи, - ще повинна бути виконана реплікація. Системний журнал Directory Services буде містити запис з ID 1119, коли реплікація завершиться і GC буде готовий до роботи із запитами.

C:> repadmin / showreps domain_controller

де domain_controller - це ім'я DC, про який потрібно дізнатися, чи є він GC. Якщо контролер домену є GC, повідомлення, виведене після виконання команди, буде містити текст DSA Options: IS_GC.

Щоб отримати список всіх GC лісу, найпростіше використовувати інструмент Dsquery з папки% systemroot% system32. Щоб запустити Dsquery, потрібно ввести:

C:> dsquery server -forest -isgc

Поєднання Infrastructure Master з GC

C:> netdom query FSMO

Контролер домену Infrastructure Master сервером GC краще не призначати. Infrastructure Master підтримує посилання об'єктів власного домену на об'єкти в інших доменах. Типовий приклад - членство в групах. Група в домені A може містити членів домена B. Якщо один з членів групи в домені B перейменований, нова інформація (т. Е. Відмітна ім'я - DN) повинна бути якимось чином переправлена ​​на контролери доменів в домен B, щоб вони точно відображали інформацію про членство в групах. Infrastructure Master містить записи, звані фантомами (phantoms), в базі даних, що представляє об'єкти з інших доменів. Infrastructure Master періодично звертається до найближчого GC, щоб визначити, чи не відбулися якісь зміни в об'єктах, для яких він зберігає фантомні запису. Якщо Infrastructure Master виявляє зміни, він видаляє старий фантом і створює новий запис. Потім Infrastructure Master реплицирует оновлення на інші DC в домені. Не слід включати роль Infrastructure Master на сервері GC, тому що GC вже мають інформацію про об'єкти в інших доменах і, отже, такі контролери не створюватимуть необхідні фантомні запису. Іншими словами, Infrastructure Master не зможе виконувати свою роль.

Коли встановлюється перший DC в AD, система автоматично конфигурирует його як GC. Система також призначає першого DC лісу все п'ять ролей майстрів операцій. Здається, що це суперечить сформульованому вище правилом для GC і Infrastructure Master, але це правило має два важливих виключення. Якщо використовується тільки один домен, контролеру домену, виконуючому роль Infrastructure Master, немає необхідності оновлювати посилання на об'єкти в інших доменах, оскільки інших доменів просто не існує. Другий виняток проявляється в тому випадку, коли всі контролери доменів одного домену в багатодоменному лісі є також серверами GC. Вони зберігають найостаннішу інформацію і не потребують оновлення, що приходять з Infrastructure Master. У такій ситуації важливо, якою DC виконує роль Infrastructure Master.

GC як Domain Naming Master

Сервер, що виконує роль майстра іменування домену - Domain Naming Master - вносить зміни в простір доменних імен лісу, наприклад, при додаванні або видаленні домену. Коли створюється новий домен, Domain Naming Master повинен забезпечити єдиність імені, т. Е. Гарантувати, що жоден інший домен (або доменний об'єкт) не має такого ж імені. Він робить це, перевіряючи локальний (найбільш близький) сервер GC. Якщо GC не є локальним, зміна виконано не буде. Щоб уникнути подібного конфлікту, слід розташовувати сервер з роллю Schema Master поблизу від Domain Naming Master.

Екран 3. Вибір сервера GC

Кожному сайту - свій GC

Може бути, має сенс все DC конфігурувати як GC? Перевага цього підходу полягає в максимальній надмірності GC, а також в тому, що питання про призначення ролі Infrastructure Master вирішується дуже просто. Недоліком є ​​погіршення продуктивності і мережі, і DC внаслідок зрослого трафіку реплікації. Очевидно, що витрати продуктивності зростають зі зростанням числа доменів, DC і GC. Необхідно прагнути до того, щоб підтримувати баланс між досягненням високого рівня надмірності і скороченням витрат. У однодоменних середовищі слід конфігурувати всі DC як GC, оскільки це не спричинить за собою ніяких додаткових витрат.

Нотатки на полях

Хоча при розміщенні GC слід керуватися досить жорсткими правилами, в кінцевому підсумку можна проявити гнучкість при розгортанні серверів GC. Потрібно пам'ятати, що кожна середа AD унікальна і що рішення, яке працює в одній організації, може бути зовсім непридатне в інший.

Занадто велике завзяття при розгортанні GC має певні недоліки, такі як сплески навантажень на мережу і інтенсивна робота DC, але і скупість в цьому відношенні не принесе нічого хорошого. Бажано забезпечити невеликий надлишок GC і пам'ятати про те, що, навіть якщо ви помилитеся з кількістю GC, можна вільно включити або відключити роль GC на сервері по ходу справи.

Нарешті, останнє і найважливіше зауваження. Розміщення GC не є одноразовою акцією. У міру розширення лісу необхідно регулярно переглядати свої рішення про розміщення GC. Моніторинг контролерів доменів і інфраструктурних ресурсів мережі повинен допомогти в цьому ..

Тоні Мюррей-Сміт ([email protected]) - фахівець з службам каталогів і поштових систем, підтримує сайт ActiveDir.org. Має сертифікати MVP і MCSE

Поділіться матеріалом з колегами і друзями