Десять советов по созданию эффективной структуры Active Directory
Структурирование Active Directory — это целая наука, слишком сложная, чтобы все ее тонкости можно было описать в одной статье. Тем не менее, я хотел бы поделиться с читателями некоторыми полезными рекомендациями, которые помогут сделать структуру AD более эффективной, облегчат диагностику и управление.
1. Простота — залог здоровья
Первый совет — стараться по возможности ничего не усложнять. Active Directory отличается большой гибкостью, предлагает множество типов объектов и компонентов, но не обязательно все это использовать только потому, что оно есть. Упрощение структуры Active Directory существенно повышает эффективность работы и облегчает диагностику при возникновении проблем.
2. Подобающая топология сайта — это важно
Хотя многое может быть сказано в пользу упрощения, при необходимости совершенно не возбраняется использовать и более сложные структуры. В больших сетях практически всегда приходится создавать несколько сайтов Active Directory. Топология сайта должна отражать топологию сети. Участки сети, на которые приходится больше всего подключений, должны вписываться в рамки одного сайта. Связи между сайтами должны отражать соединения в рамках WAN — так, чтобы на каждое физическое помещение, соединенное с WAN, приходился отдельный сайт Active Directory.
3. Контроллеры домена не должны быть многофункциональными
Очень часто в небольших организациях контроллеры домена выполняют сразу несколько ролей (например, файлового или почтового сервера) — в целях экономии. Тем не менее, в качестве контроллера домена желательно по возможности использовать отдельный сервер — физический или виртуальный. Присвоение контроллеру домена дополнительных ролей отрицательно сказывается на производительности сервера, ослабляет безопасность и усложняет процесс резервного копирования/восстановления системы.
4. Серверов DNS нужно как минимум два
Другая статья расходов, на которой мелкие компании часто пытаются сэкономить, — это резервные DNS-серверы. Проблема в том, что Active Directory полностью зависит от служб DNS. Поэтому если единственный DNS-сервер в организации выйдет из строя, Active Directory тоже работать не будет.
5. Не кладите все яйца в одну корзину (о виртуализации)
В организациях обычно используется сразу несколько контроллеров домена для того, чтобы обеспечить отказоустойчивость на случай выхода из строя одного из них. Однако зачастую вся эта отказоустойчивость сводится на нет за счет виртуализации серверов. Многие компании размещают все свои виртуальные контроллеры домена на одном хост-сервере, и если тот выходит из строя, контроллеры домена перестают работать вместе с ним. Так что виртуализировать контроллеры домена можно и нужно, но размещать их следует на нескольких хост-серверах.
6. Нельзя пренебрегать ролями FSMO (о резервном копировании)
Хотя Windows 2000 и все последующие версии Windows Server поддерживают модель с несколькими мастер-доменами, некоторые контроллеры домена все равно оказываются важнее других. В частности, контроллеры, выполняющие роли FSMO (Flexible Single Master Operations, FSMO), имеют критическое значение для нормального функционирования Active Directory. Хотя AD может какое-то время продолжать работу даже в случае отказа контроллера домена, выполняющего роли FSMO, в конечном счете это может нанести корпоративной сети серьезный урон.
Некоторые IT-специалисты утверждают, что вовсе не обязательно осуществлять резервное копирование всех контроллеров домена в сети, поскольку данные Active Directory на них дублируются. В каком-то смысле это действительно так, но резервные копии серверов, выполняющих роли 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?
