Структурування Active Directory - це ціла наука, занадто складна, щоб все її тонкощі можна було описати в одній статті. Проте, я хотів би поділитися з читачами деякими корисними рекомендаціями, які допоможуть зробити структуру AD більш ефективної, полегшать діагностику і управління.
1. Простота - запорука здоров'я
Перша порада - намагатися по можливості нічого не ускладнювати. Active Directory відрізняється великою гнучкістю, пропонує безліч типів об'єктів і компонентів, але не обов'язково все це використовувати тільки тому, що воно є. Спрощення структури Active Directory істотно підвищує ефективність роботи і полегшує діагностику при виникненні проблем.
2. подбати топологія сайту - це важливо
Хоча багато що може бути сказано на користь спрощення, при необхідності зовсім не забороняється використовувати і більш складні структури. У великих мережах практично завжди доводиться створювати кілька сайтів Active Directory. Топологія сайту повинна відображати топологію мережі. Ділянки мережі, на які припадає найбільше підключень, повинні вписуватися в рамки одного сайту. Зв'язки між сайтами повинні відображати з'єднання в рамках WAN - так, щоб на кожну фізичну приміщення, поєднане з WAN, припадав окремий сайт Active Directory.
3. Контролери домену не повинні бути багатофункціональними
Дуже часто в невеликих організаціях контролери домену виконують відразу кілька ролей (наприклад, файлового або поштового сервера) - з метою економії. Проте, в якості контролера домену бажано по можливості використовувати окремий сервер - фізичний або віртуальний. Присвоєння контролеру домену додаткових ролей негативно позначається на продуктивності сервера, послаблює безпеку і ускладнює процес резервного копіювання / відновлення системи.
4. серверів DNS потрібно як мінімум два
5. Не кладіть всі яйця в одну корзину (про віртуалізації)
В організаціях зазвичай використовується відразу кілька контролерів домену для того, щоб забезпечити відмовостійкість на випадок виходу з ладу одного з них. Однак найчастіше вся ця відмовостійкість зводиться нанівець за рахунок віртуалізації серверів. Багато компаній розміщують всі свої віртуальні контролери домену на одному хост-сервері, і якщо той виходить з ладу, контролери домену перестають працювати разом з ним. Так що віртуалізувати контролери домену можна і потрібно, але розміщувати їх слід на кількох хост-серверах.
6. Не можна нехтувати ролями FSMO (про резервне копіювання)
Мені якось довелося взяти участь у відновленні даних після виходу з ладу одного з контролерів домену в корпоративній мережі. На жаль, цей контролер виконував всі ролі FSMO, будучи єдиним сервером глобального каталогу і єдиним DNS-сервером в організації. Що ще гірше, резервної копії цього контролера домену не було. В результаті нам довелося заново формувати Active Directory з нуля. Такі ситуації, звичайно, відбуваються нечасто, але цей випадок чудово ілюструє важливість резервного копіювання контролерів домену.
7. Розвиток структури домену слід планувати наперед
У багатьох організаціях первісна архітектура Active Directory ретельно продумується, але в подальшому еволюціонує досить хаотично. Щоб цього уникнути, я раджу заздалегідь планувати структуру Active Directory з урахуванням майбутнього зростання. Передбачити, як саме Active Directory буде розвиватися, не завжди реально, але можна хоча б задати якісь критерії, якими слід керуватися при розширенні структури.
8. Сервери потрібно конфігурувати, знаючи, як ними будуть керувати
Планувати потрібно не тільки структуру Active Directory, а й порядок управління. Хто буде адмініструвати Active Directory? Чи буде це одна людина / група фахівців, або обов'язки по обслуговуванню будуть розподілені відповідно до кількості доменів / організаційних одиниць? З відповідями на такі питання варто визначитися, перш ніж приступати до створення контролерів домену.
9. Великомасштабні логістичні зміни небажані
Active Directory відрізняється великою гнучкістю і дозволяє вносити істотні зміни в свою структуру без простоїв і втрати даних. Проте, я б порекомендував по можливості уникати реструктурування Active Directory. Дуже часто це призводить до пошкодження деяких об'єктів AD, особливо при їх переміщенні між контролерами домену, що працюють під управлінням різних версій Windows Server.
10. На кожному сайті повинен бути хоча б один сервер глобального каталогу
Нарешті, ще одна порада: якщо Active Directory складається з декількох сайтів, бажано, щоб у кожного з них був власний сервер глобального каталогу. В іншому випадку клієнтам Active Directory доведеться завантажувати дані з глобального каталогу по мережі WAN.
Що ще ви порекомендували б враховувати при структуруванні Active Directory? Чи доводилося вам шкодувати про рішення, прийняті при первісному розгортанні AD?