Рекомендации по проектированию Active Directory для небольших сетей

Определение небольшой сети

Слово «маленький» означает разные вещи для разных людей. Например, я считаю свою собственную сеть маленькой. Я веду шоу одного человека с примерно 20 компьютерами. С другой стороны, компания из списка Fortune 500 может считать дочернюю компанию с тысячей пользователей небольшой сетью. Для целей этой статьи я буду определять небольшую сеть как сеть с менее чем сотней пользователей.

Планирование домена

Одной из первых вещей, которые вам нужно будет спланировать для вашей небольшой сети, является структура домена. Сначала это, вероятно, звучит как излишество. В конце концов, большинство небольших сетей представляют собой один лес, один домен. Можно возразить, что необходимо планировать будущий рост, но один контроллер домена Windows Server 2003 может разместить в каталоге миллионы объектов. Даже если вы используете устаревший контроллер домена Windows NT 4.0, ограничение по-прежнему составляет около 40 000 пользователей. Так почему же так важно планировать структуру домена для такой маленькой сети?

Это связано с административным контролем. Более чем вероятно, что если в вашей сети меньше сотни пользователей, вы, вероятно, будете единственным администратором сети. Однако у географии есть способ это изменить. Например, представьте, что эти сто сотрудников разбросаны по трем разным офисам в трех разных частях страны. Вы все еще собираетесь самостоятельно управлять сетью для всех трех офисов или предпочитаете помощь?

Скажем в качестве аргумента, что вы решили, что вам нужна помощь в управлении сетями в удаленных офисах, потому что они так далеко. Теперь вопросы заключаются в том, какую помощь вы хотите получить и насколько вы доверяете удаленным администраторам?

Эти вопросы важны, потому что у вас есть несколько вариантов. Если вы просто хотите, чтобы удаленные администраторы могли сбрасывать пароли, разблокировать учетные записи пользователей и т. д., вам, вероятно, лучше всего создать организационное подразделение для каждого удаленного офиса, а затем поместить учетные записи пользователей из каждого офиса в соответствующую организационную единицу. Ед. изм. С другой стороны, если вы хотите полностью передать управление удаленными офисами удаленному администратору (вы сохраняете контроль над лесом), то вам, вероятно, лучше создать отдельный домен для каждого офиса.

Планирование ресурсов

В качестве аргумента предположим, что вы решили использовать один домен для своей сети. Независимо от того, есть ли на картинке какие-либо удаленные администраторы или нет, вам придется принять некоторые важные дизайнерские решения относительно ваших удаленных офисов. Эти решения связаны с тем, какие типы серверов (если таковые имеются) вы хотите разместить на удаленных объектах.

Решения такого типа всегда имеют большое значение, но они еще более важны в небольших компаниях, потому что вы должны сбалансировать стоимость серверов (и их влияние на ваш бюджет) с выгодой, которую они принесут.

Давайте представим, что у вашей компании очень ограниченный ИТ-бюджет (хм… может быть, мы не притворяемся в этом плане) и что вы решили вообще не размещать серверы в удаленных офисах. Ваша сеть может функционировать таким образом, но вы полностью зависите от скорости и надежности соединения WAN между удаленным офисом и главным офисом. Если канал WAN выйдет из строя, никто в удаленном офисе даже не сможет войти в систему.

Конечно, каналы WAN постоянно выходят из строя, и наличие целого офиса, полного людей, которые не могут войти в систему, пока проблема не будет устранена, вероятно, не очень хорошо для бизнеса. Итак, допустим, мы собираемся разместить контроллер домена в каждом удаленном офисе, чтобы люди могли входить в систему независимо от того, доступна ли ссылка WAN или нет. Но действительно ли это решает проблему? Не совсем. Во всяком случае, это создает некоторые другие проблемы.

Во-первых, наличие локально доступного контроллера домена не гарантирует, что пользователи смогут войти в систему (если только мы не говорим о Windows NT). В среде Active Directory пользователи должны иметь возможность связаться с сервером глобального каталога, чтобы войти в систему. Единственным пользователем, который может войти в систему без доступа к серверу глобального каталога, является администратор домена. Хотя эту проблему легко исправить. Вы можете просто назначить контроллер домена каждого офиса сервером глобального каталога. Это позволит пользователям входить в сеть, когда канал WAN не работает; при условии, что пользователи могут взаимодействовать с контроллером домена.

Даже если контроллер домена доступен локально и назначен сервером глобального каталога, пользователи не смогут войти в систему, если они не могут взаимодействовать с контроллером домена. Есть несколько вещей, которые могут привести к этому. Одна из причин, по которой пользователи не могут взаимодействовать с контроллером домена, заключается в том, что их компьютерам не назначен IP-адрес. Подумайте об этом на минуту. Если единственный доступный DHCP-сервер находится в другом здании, а соединение с глобальной сетью выходит из строя, то никто в удаленном офисе не сможет арендовать IP-адрес. Поэтому, вероятно, неплохо иметь DHCP-сервер в удаленном офисе.

Другая причина, по которой контроллер домена может быть недоступен, заключается в том, что Active Directory полностью зависит от DNS. Если DNS-сервер находится в главном офисе, а соединение с глобальной сетью выходит из строя, клиенты в удаленном офисе могут быть не в состоянии разрешить имя локального контроллера домена.

Допустим, вы решили потратить немного денег и установить DNS-сервер, DHCP-сервер и контроллер домена в удаленных офисах. Есть еще пара вопросов, с которыми вам, возможно, придется столкнуться. Одной из проблем является чрезмерный трафик репликации. Каждый раз, когда Active Directory обновляется в любом из офисов (например, при добавлении учетной записи пользователя или изменении пароля), обновление распространяется по каналу WAN на другие контроллеры домена в других офисах. Если Active Directory часто обновляется, этот трафик репликации может сильно увеличить пропускную способность.

Решение здесь состоит в том, чтобы создать отдельный сайт Active Directory для каждого офиса. Трафик репликации Active Directory по-прежнему необходимо отправлять на контроллеры домена в удаленных офисах, но его можно запланировать и отправлять пакетами, а не постоянно перегружать канал WAN трафиком репликации.

Другая проблема, с которой вы можете столкнуться, — доступность данных. Если предположить, что в удаленных офисах есть контроллер домена, сервер глобального каталога, DHCP-сервер и DNS-сервер, то пользователи в этом офисе смогут войти в систему, даже если связь по глобальной сети прервется. Однако возможность входа в систему не имеет большого значения, если пользователи не могут получить доступ к своим данным.

Есть несколько способов обойти эту проблему. Надлежащий план действий будет зависеть от того, будут ли данные совместно использоваться различными офисами. Если нет необходимости обмениваться данными между офисами, то, вероятно, лучший способ действий — установить файловый сервер в каждом офисе и позволить пользователям сохранять свои данные непосредственно на этом сервере. Если данные должны быть разделены между офисами, то вам, вероятно, лучше настроить сервер DFS в каждом офисе. Таким образом, каждый офис содержит сервер с полной копией данных компании. Если канал WAN выходит из строя, пользователи по-прежнему могут получить доступ ко всему набору данных. Когда соединение WAN возвращается, любые изменения, внесенные в данные, синхронизируются с другими серверами DFS в других офисах.

Вывод

В этой статье я упомянул о многих вещах, которые должны присутствовать в удаленных офисах, чтобы пользователи могли продолжать работать даже в случае отказа канала WAN. Если бюджет является проблемой, вы, вероятно, можете обойтись, объединив все эти роли на одном сервере. Обычно считается лучшей практикой не использовать контроллер домена в качестве файлового сервера (из соображений безопасности и производительности). Вы должны делать то, что подходит для вашей отдельной компании. В ситуации, подобной той, что я описал выше, я бы рекомендовал разместить по два сервера в каждом удаленном офисе. Один сервер будет действовать как контроллер домена, глобальный каталог, DHCP и DNS-сервер. Другой будет действовать как файловый сервер (возможно, сервер DFS).