Что лучше для вывода из эксплуатации контроллера домена, который также является DNS-сервером?

Существует два подхода к выводу из эксплуатации контроллеров домена Active Directory, которые активно используются в качестве DNS-серверов.

Добавьте IP-адрес исходящего DC в новый DC и убедитесь, что DNS прослушивает этот адрес.
Снимите старый контроллер домена, оставьте на нем роль DNS и настройте глобальный сервер пересылки DNS на новый сервер.

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

Есть ли здесь четкая лучшая практика?

windows domain-name-system active-directory

— MDMarra
источник

Или, в-третьих, изменить какие-либо / все ссылки на старый DNS-сервер в сети?

— gravyface

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

Obviously, both are stopgaps until all servers and devices have been configured to use the primary IP address of a new server, but sometimes that transition period can be relatively long depending on the size of the environment.

правильно?

— MDMarra

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

— gravyface

Конечно, это лучший вариант, но когда я говорю «очень большая» среда, я имею в виду глобально распределенную инфраструктуру с более чем 300 DC и множеством различных ИТ-команд, управляющих различными компонентами инфраструктуры. Иногда, это действительно не возможно гарантировать , что вы получили все устройства в первом колебании во время обновления.

— MDMarra

@gravyface Вы не ошибаетесь, но в больших и географически разрозненных средах с децентрализованным управлением различными компонентами не всегда возможно согласовать план игры, привести всех в соответствие и стремиться к общей цели. Иногда вам просто нужно принять решение, чтобы двигаться вперед и найти решение или обходной путь, чтобы гарантировать, что он будет иметь как можно меньше последствий для других

— Матиас Р. Джессен,

Ответы:

Я не решаюсь ответить, потому что я думаю, что это скорее вопрос «обсуждения», чем вопрос строго «вопросов и ответов» ... но это субботнее ленивое субботнее утро, так что я все равно буду.

Есть ли здесь четкая лучшая практика?

Нет. (Черт, может быть, это был простой ответ всем ...)

Microsoft предоставляет очень простое и легко ~~доступное для~~ Google руководство по Bingable о том, как демонтировать контроллеры домена и выполнять миграцию AD и DNS, но я не буду связываться с ними ссылками и не буду делать вид, что они отвечают на ваш конкретный вопрос, потому что Microsoft явно не может документировать каждый конкретный случай для каждой среды организации.

Таким образом, системные администраторы / инженеры, такие как мы, должны восполнить пробелы своим собственным опытом и знаниями, когда Microsoft не написала специальный сценарий только для нас, и это то, что делает нас ценными.

Я могу привести вам пример того, что мы сделали для решения этой же проблемы, поскольку я также работаю в глобальных средах с десятками или более контроллерами домена, разрозненные леса AD, сожительствующие в одних и тех же сетях, устройства не-Windows также потребляющие Службы DNS из одних и тех же контроллеров домена и т. Д. Переезд в новые центры обработки данных и выход из старых, необходимость перехода на новое оборудование или новые версии ОС, а также простая старая деловая политика - все это возможные причины, по которым нам нужно было бы списать контроллеры домена, которые потенциально все еще использовались. И когда у вас есть несколько разнородных организаций, в настоящее время использующих эти серверы DC / DNS, обычно это изнурительный, затяжной процесс перенастройки каждого клиента (многие из которых могут не находиться под вашим контролем) перед выводом из эксплуатации контроллера домена с участием менеджеров проектов,

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

Чтобы решить эту проблему, мы создали VIP для каждого центра обработки данных и объединили все контроллеры домена в этом центре данных за этим VIP. (Этот VIP предназначен для службы DNS только по понятным причинам, я не говорю о балансировке нагрузки Kerberos и LDAP.) Таким образом, клиенты могут быть настроены на использование этого VIP для своего преобразователя DNS, и мы можем свободно добавлять и удалять контроллеры доменов, стоящие за этим VIP, когда угодно и как угодно.

Но вы не перед проблемой ... поэтому, учитывая варианты, которые вы предоставили:

Добавьте IP-адрес исходящего DC в новый DC и убедитесь, что DNS прослушивает этот адрес.

Снимите старый контроллер домена, оставьте на нем роль DNS и настройте глобальный сервер пересылки DNS на новый сервер.

Я бы выбрал вариант № 1, потому что ваша цель - как можно быстрее вывести из эксплуатации старый сервер, а вариант № 2 не поможет вам избавиться от старого сервера. С опцией # 2 существование сервера все еще необходимо. Я также не согласился бы с предложением Матиаса Р. Джессена о зонах-заглушках, потому что вам все равно придется оставить старый сервер на месте и в работе, что не способствует достижению вашей конечной цели.

С вариантом № 1, каким бы уродливым он ни был, вы можете удалить старый сервер, заявить о снижении затрат для своей компании, не платить за аренду другого центра обработки данных за месяц и получить награду за то, что вы такой хороший сотрудник.

Изменить: Думая о нашем чате немного больше, я думаю, что я, возможно, спроецировал свои собственные требования на вас, потому что у меня есть требования «тянуть-подключить-как-то» как можно скорее к некоторым вещам прямо сейчас, так что это было свежо в моей памяти. Похоже, у вас нет необходимости в немедленном отключении сервера как можно скорее.

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

— Райан Райс
источник

Я думаю , что это подпадает под good subjectiveв Доброй субъективны, Bad Субъективная пост , который определил «обсуждение вопросов» правила. По крайней мере, я на это надеюсь.

— MDMarra

@MDMarra Я согласен. +1 за наводящий на размышления и интересный вопрос. :)

— Райан Райс

Кроме того, просто для записи, я обычно делаю противоположное вашему предложению: D

— MDMarra

Дорога в ад Active Directory вымощена временными повязками. Назначение IP-адреса отключенного или подлежащего удалению DNS-сервера вашему новому DC и DNS-серверу является временной перевязкой.

Как отметил @gravyface в комментариях, в идеальном сценарии вы изменили бы все области DHCP и статические конфигурации, чтобы обновить предпочтение DNS клиента новым IP-адресом вместо старого, прежде чем полностью отключить старый DC.

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

В дополнение к тому, что старый сервер перенаправляет запросы даже после его демонтажа, я бы рекомендовал включить ведение журнала отладки для входящих запросов на DNS-сервере - это немного облегчает оценку не только того, что клиенты все еще указывают на старый DNS-сервер, но и выявление указанных клиентов.

При этом, я думаю, вы пропустили очевидный третий вариант: зоны-заглушки !

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

— Матиас Р. Ессен
источник