Совет относительно Active Directory разрабатывает для многосетевых серверов

В первую очередь, когда мы предоставляем услугу нашим клиентам, мы должны подвергнуть сомнению, каковы их требования. Включение клиенту понять, что их уровень сложности является ненужным.

• Каков был # клиентов?
• Это - весь внутренний трафик?
• Каков функциональный уровень доменов?
• Является TLS protcol быть используемым?

Используя метод K.I.S.S - создал бы два VLAN "SVR" и "CLT", разрешающий SSL/TLS и прекращение дело....

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

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

Существует несколько определенных аспектов, которые нужно рассмотреть.

1. Сервисная репликация домена Active Directory
2. Процесс Локатора DC Клиентов/Рядовых серверов
3. Определение имен и трафик для неAD сервисов DS

Один и два имеют много общего - в целом мы в прихоти Microsoft на этом и должны работать в границах AD процессов DS Microsoft.

Номер три у нас есть определенная комната для работы с. Мы можем выбрать маркировки, используемые для доступа к сервисам (файлы, экземпляры базы данных, и т.д.).

Вот то, что я предлагаю:

Создайте свои Контроллеры домена (DC)

• Вероятно, по крайней мере два.
• Каждый DC будет иметь два NIC, один в каждой сети/AD IP сайт DS - вызов их CLT и srv на данный момент.
• Только настройте один NIC в каждом DC прямо сейчас в srv сети.

Настройте AD Сайты и Сервисы правильно

• сайт srv и подсеть
• сайт CLT и подсеть
• снимите флажок, "Соединяют все ссылки сайта мостом" от Сайтов->, Транспорты Межсайта-> Щелкают правой кнопкой по "IP"
• удалите DEFAULTIPSITELINK, если он существует (или если Вы переименовали его), таким образом, нет никаких настроенных ссылок сайта. Обратите внимание, что это - неизвестное для меня - KCC, вероятно, выведет ошибки в журнал событий Службы каталогов, говоря, что эти два сайта (srv и CLT) не соединены в переменных интервалах. Однако репликация все еще продолжится между двумя DC, поскольку они могут связаться друг с другом использующим IP в том же сайте.

Настройте дополнительную зону в AD DS Интегрированный DNS

• Если Ваш домен AD DS является acme.local, создайте вторую Основную AD Интегрированную Зону с динамическими обновлениями, включенными названными clt.acme.local.

Настройте второй NIC на своем DC

• Они NIC будет NIC в сети/сайте CLT.
• Установите их IP
• Вот волшебная часть - Свойства Адаптера-> Свойства IPv4-> Усовершенствована-> Вкладка DNS-> Набор суффикс DNS для этого соединения с clt.acme.local-> контрольный регистр это соединение...-> Использование Проверки суффикс DNS этого соединения...-> хорошо полностью через.
• ipconfig/registerdns
• Это зарегистрирует IP NIC CLT в clt.acme.local зоне - обеспечение метода для нас для управления, какой IP/сеть используется позже.

Настройте рядовой сервер NIC

• Рядовой сервер NIC в сайте CLT должен иметь их суффикс DNS и набор флажков соответственно также как вышеупомянутый.
• Эти настройки могут использоваться с помехами и DHCP, не имеет значения.

Настройте DNS [тупик] поведение сопоставителя в сайтах

• DC-> Настраивает DC srv NIC для использования себя и другого DC srv IP NIC. Пустой DNS NIC CLT DC отпуска (статический IP необходим хотя). (DC сервер DNS все еще послушает на всем IP по умолчанию).
• Рядовые серверы-> Настраивают рядовой сервер srv NIC для использования DC srv IP сайта. Оставьте рядовой сервер CLT NIC DNS пустой (статический IP может использоваться).
• Клиенты/Рабочие станции-> Настраивают DNS (или через DHCP или статичный) для использования CLT DC IP NIC.

Настройте отображения/ресурсы соответственно

• То, когда серверы будут говорить друг с другом убедиться использовать .acme.local->, решит к srv сети IP.
• То, когда клиенты будут говорить с серверами убедиться использовать .clt.acme.local->, решит к сети IP CLT.

О чем я говорю?

• AD репликация DS все еще произойдет, поскольку DC может разрешить друг друга и соединиться друг с другом. acme.local и _msdcs.acme.local зона будут только содержать DC srv, AD репликация DS IP NIC только произойдет в srv сети.
• Процесс локатора DC для рядовых серверов и рабочих станций будет функционировать - хотя там существуют возможность задержек в различных частях различных AD процессов DS, когда сайт неизвестен, если несколько, IP DC возвращается - их будут судить, сбой и движение, пока каждый не будет работать. Эффекты на DFS-N не были полностью оценены ни один - но будут все еще функционировать.
• Не AD сервисы DS будут функционировать прекрасные при использовании вышеупомянутого .acme.local и маркировок .clt.acme.local, как описано.

Я не полностью протестировал это, поскольку это довольно смехотворно. Однако точка этого (ничего себе, длинный) ответ должен начать оценивать, возможно ли - не, должно ли это быть сделано.

@Comments

@Massimo 1/2 не смущают несколько AD сайты DS в acme.local зоне и таким образом записи SRV, заполненные DC в тех сайтах в acme.local зоне с необходимостью в записях SRV в clt.acme.local зоне. Основной суффикс DNS клиента (и домен Windows, к которому к ним присоединяются) все еще будет acme.local. Клиент/рабочие станции только имеет единственный NIC, с основным суффиксом DNS, вероятно, полученным из DHCP, установил на acme.local.

clt.acme.local зоне не нужны записи SRV, поскольку она не будет использоваться в процессе локатора DC. Это только используется клиентами/рабочими станциями для соединения с неAD сервисами DS рядового сервера с помощью IP рядового сервера в сети CLT. AD DS связал процессы (локатор DC) не будет использовать clt.acme.local зону, но AD сайты DS (и подсети) в acme.local зоне.

@Massimo 3

Будут записи SRV и для CLT и для srv AD сайтов DS - просто, что они будут существовать в acme.local зоне - см. примечание выше. clt.acme.local зоне не нужен DC связанные записи SRV.

Клиенты смогут определить местоположение прекрасного DC. Клиент серверы DNS указывает на IP CLT DC.

Когда процесс локатора DC на клиенте начинается

• Если клиент будет знать его сайт, то вопросом о DNS будет _ldap. _ tcp. [сайт]. _sites.dc. _ msdcs.acme.local SRV. Это возвратит назад сайт определенный DC, которые имеют зарегистрированные записи SRV.
• Если клиент не будет знать его сайт, то вопросом о DNS будет _ldap. _ tcp.dc. _ msdcs.acme.local SRV. Это возвратит назад весь DC. Клиент попытается связать с LDAP DC, пока он не найдет тот, который отвечает. Когда клиент находит один, это выполняет поиск сайта для определения сайта клиента, и кэш сайт в реестре, таким образом, будущие экземпляры локатора DC происходят более быстрые.

@Massimo 4

Тьфу, хорошая выгода. Путем я вижу его существует два пути вокруг этой проблемы.

1. Меньшее влияние (по сравнению с 2 ниже) должно создать запись в файле hosts на клиентах/рабочих станциях для dc1.acme.local и dc2.acme.local, указывающего на IP NIC CLT DC.

или

2. Вручную создайте необходимые записи SRV в netlogon.dns файле на каждом DC. Это, вероятно, будет иметь некоторые последствия в сети сервера. Рядовые серверы могут время от времени общаться с DC в сети CLT, если это настроено.

В целом, ни один из него не симпатичен, но это - не обязательно конечная цель. Возможно, клиент просто тестирует Ваши технические прерывания. Булькание, которое это на их столе переговоров и говорит им "Здесь, это будет работать, но я заряжаю Вас 4x моя обычная норма, чтобы настроить и поддерживать его. Можно уменьшить его до 1.5x моя обычная норма-.5x заряд ЛАВАША путем выполнения [правильное решение]".

Как отмечено ранее, моя рекомендация состоит в том, чтобы убедить иначе или работать. Но это уверенный является забавное небольшое упражнение в смешном.:)