Назад | Перейти на главную страницу

Когда добавлять контроллер домена в удаленном месте?

В месте, где есть 1 соединение T1 с задержкой пинга ~ 40-50 мс до ближайшего контроллера домена, о том, сколько обычных пользователей потребуется, прежде чем вы порекомендуете разместить там контроллер домена со средой Windows 2003.

T1 используется для Интернета, и их файловый сервер и сервер электронной почты не будут находиться с ними в этом месте. Есть также VOIP, проходящий через этот T1.

Когда я читал сообщение OPs, на этом удаленном сайте есть только 1 строка данных. Если да, то ответ на мой вопрос ниже, скорее всего, отрицательный ...

По моему (ограниченному) опыту, это вопрос не производительности, а времени безотказной работы.

Сколько работы могли бы выполнить эти удаленные пользователи, если T1 не работает, и какова ожидаемая и наихудшая надежность этого T1? Может ли удаленный контроллер домена обеспечивать аутентификацию и DHCP / DNS для пользователей, чтобы «значимо большой» набор приложений будет по-прежнему доступен, даже если T1 не работает?

Если сайт не работает, как только T1 выходит из строя, то есть удаленные пользователи не могут действительно выполнять какую-либо значимую работу без этого канала передачи данных, тогда удаленный DC не имеет смысла, ИМХО. То же самое происходит, если на сайте много значимой работы, но для этой работы не требуются какие-либо ИТ-системы. Но если DC может позволить использовать другие ИТ-системы, тогда это ценно.

Если вы настраиваете удаленный DC, подумайте о Контроллеры домена только для чтения Windows 2008, и рассмотрите возможность перемещения других служб ближе к пользователям для повышения производительности.

Если в этом месте нет других серверов, как вы указываете (файловый сервер и сервер электронной почты для них удалены), то я бы вообще не стал размещать там DC. Зачем беспокоиться о его обслуживании (даже если это минимальное обслуживание) или о его питании / охлаждении и т. На самом деле нет никакого смысла аутентифицировать их локально, если они не обращаются к каким-либо ресурсам сервера (это включает службы печати, о которых вы не упомянули, поэтому я предполагаю, что они подключаются через TCP / IP или имеют локально подключенные принтеры) .

Вы также спросили, «сколько обычных пользователей потребуется, прежде чем вы ...»:

На мой взгляд, как только вы получите более 10 пользователей или около того, я бы порекомендовал объединить некоторые роли и разместить в этом месте DC, который также действует как их локальный файл / сервер печати. Раньше у них было клеймо о том, что DC работает с файловыми службами / службами печати, но я думаю, что это прекрасно работает для 10-30 пользователей.

Я бы вообще не стал возиться с контроллером домена, если бы у вас не было достаточно значительного количества пользователей, а также ИТ-персонала на месте. Аутентификация домена может быть достаточно эффективной для каналов WAN, а остальное сделает кэшированная аутентификация XP.

Единственная серьезная проблема была бы, если бы у вас был локальный сервер Exchange, и вы не работали в режиме кэширования; В таких обстоятельствах поиск в GAL может быть довольно убийственным.

Я рекомендую развернуть AD, когда вам нужно пройти аутентификацию для использования локальных служб. Например. доступ пользователей к компьютерам друг друга, наличие у них локального сервера и т. д.

Количество пользователей значения не имеет. Можете ли вы рассчитывать на то, что достаточная пропускная способность всегда доступна, когда это необходимо для трафика AD? Достаточно ли надежное соединение для ваших нужд? Судя по вашему описанию, я подозреваю, что да, но только вы можете знать наверняка. В любом случае, если бы это была моя сеть, у них был бы собственный DC (и файловый сервер и т. Д.). Я стал жертвой того, что кто-то выше по дереву решил, что моему местоположению не нужен DC. В долгосрочной перспективе это просто обойдется дороже, если снизится производительность.

Мы управляем сотней удаленных офисов в этом диапазоне без DC. Трафик аутентификации слишком мал, чтобы оправдать (общую) стоимость машины. Я обнаружил, что подход «в хвосте» работает в долгосрочной перспективе; пользователи сначала будут жаловаться на медленный просмотр / почту (не время C + A + D), затем давление на полосу пропускания, затем трафик AD будет ехать в хвосте этого, и нет необходимости в DC. Удаленные контроллеры домена болезненны = стоимость поддержки и могут быть небезопасными.