Позвольте мне описать мою ситуацию.
У меня в сети пять DC; смесь 2008 R2 и 2012. Одна из них недоступна в настоящее время, и для решения этой проблемы может потребоваться некоторое время. Остальные четыре DC подключены к сети и доступны со всех рабочих станций.
На некоторых рабочих станциях, когда я пытаюсь пропинговать свое доменное имя, время ожидания истекает. Когда я проверяю IP-адрес, на который он разрешил, это будет DC, который недоступен. Чтобы облегчить представление, позвольте мне назвать контроллеры домена и дать им IP-адреса.
DC1.xyz.com - 192.168.0.1
DC2.xyz.com - 192.168.1.1
DC3.xyz.com - 192.168.2.1
DC4.xyz.com - 192.168.3.1
DC5.xyz.com - 10.72.0.1
На большей части рабочей станции, когда я пингую xyz.com; он разрешается в 192.168.xx.xx и получает ответ. Но в некоторых случаях он разрешается до 10.72.0.1 и истекает время ожидания.
DC1, DC2, DC3 и DC4 находятся на одном сайте AD, а DC5 - на другом сайте, так как он находится в облаке. Насколько я понимаю, стоимость достижения DC1, DC2, DC3 и DC4 меньше; все рабочие станции должны разрешить свои IP-адреса, если они не недоступны.
У меня вопрос: почему рабочая станция разрешается в DC, который находится на другом сайте и для которого требуется более высокая стоимость? Как это повлияет на рабочую станцию?
Заранее спасибо. Буду очень признателен, если вы, ребята, поможете мне разобраться в этом.
Это ожидаемое поведение. Прямой поиск в DNS вернет ВСЕ контроллеры домена, для которых A-запись зарегистрирована в DNS. Любое клиентское приложение, использующее доменное имя Active Directory, должно учитывать этот сценарий и компенсировать недоступность контроллеров домена.
Стоимость сайта относится к процессу DC Locator, а не к поискам DNS.
Каждый из этих IP-адресов, которые вы указали, находится в разных подсетях. Предполагая, что каждый компьютер, с которого выполняется пинг, использует свой локальный маршрутизатор в качестве шлюза по умолчанию, это означает, что маршрутизатор, скорее всего, будет иметь запись DNS для xyz.com, установленную на статический IP-адрес того, какой DC находится в его подсети.
2 решения, одно долгосрочное и одно быстрое:
Долгосрочная перспектива - переместите все контроллеры домена за балансировщиком нагрузки и получите его с адресом xyz.com, который разрешается из каждой подсети. Таким образом, когда один DC выходит из строя, балансировщик нагрузки должен иметь возможность справиться с этим и использовать другие 3 DC.
Кратковременный - узнайте, какая подсеть направляется к неисправному DC. Получите доступ к шлюзу по умолчанию для этой подсети (вероятно, к маршрутизатору, к которому подключен ПК). Измените адрес, на который указывает xyz.com, на один из рабочих DC. Однако это увеличит нагрузку.
Это кажется хорошей отправной точкой. Определите, все ли ПК в одной подсети или на одном маршрутизаторе обращаются к неправильному DC. Если это так, скорее всего, проблема в таблице маршрутизации на шлюзе.