Ситуация:
- У нас есть сайт DR, который нужно протестировать
На сайте DR имеется смесь хостов Linux и Windows. В случае аварии, если SERVER на рабочем сайте недоступен, SERVER_DR на DR включается и присоединяется к тому же домену Windows. Это делается таким образом на случай, если основной сайт недоступен, и мы не хотим удалять исходную запись для SERVER из AD.
Проблема, которую я пытаюсь решить, — это разрешение имени на сайте DR. Процессы и скрипты используют DNS-имя SERVER, поэтому на сайте DR запросы к SERVER должны транслироваться в SERVER_DR. У нас нет доступа, чтобы что-либо сделать на Windows DNS.
Моя идея заключается в использовании BIND для решения этой проблемы. Хосты в DR должны иметь возможность проходить аутентификацию в AD. Тот факт, что им не нужно получать доступ ни к чему другому за пределами сайта DR в домене Windows, должен упростить проблему.
Службы, к которым хостам DR необходим доступ, в основном это файлообменники и серверы SQL. Я считаю, что проблема может быть в серверах SQL, поскольку они используют SPN.
Это наводит на мысль об использовании BIND для зоны our.domain.com, удерживаемой BIND на сайте DR, однако я вижу возможную проблему, когда хостам Windows DR необходимо проходить аутентификацию в AD, поскольку им необходимо использовать неотмеченные записи, если я правильно помню. Мы не можем делегировать зоны из AD по причинам, которые я упомянул ранее.
Стоит ли решать эту проблему? Один из моих коллег предложил использовать файл hosts для каждого хоста Windows DR. Однако это выглядит довольно некрасиво, поскольку их не так много, и мое время на настройку BIND может быть потрачено впустую.
решение1
Файлы HOSTS не заставят аутентификацию AD работать должным образом. Для аутентификации AD нужны записи SRV RR, которые может предоставить только DNS-сервер (поскольку файл HOSTS — это всего лишь записи A RR).
Посмотрите здесь: мой предыдущий ответ об использовании BIND для поддержки AD:Использование BIND9 и DHCPD для поддержки домена Windows
У вас возникнут проблемы с корректной работой некоторого программного обеспечения, если имена компьютеров сервера Windows отличаются. Попытка просто "создать псевдоним" имени, не являющемуся DR, для сервера Windows с другим набором имен компьютеров сработает для некоторых протоколов, но другие потерпят неудачу (например, SPN в AD "привязаны" к именам компьютеров).
Мне не ясно, почему вы не можете использовать Windows DNS на сайте DR. Я думаю, что вы могли бы развернуть сервер Windows DNS и, в худшем случае, делегировать зону _msdcs.domain.com серверу Windows DNS в существующей инфраструктуре BIND.
Думаю, мне нужно будет немного больше понять, чего вы пытаетесь добиться и почему у вас есть ограничения, но в целом я бы постарался сделать среду DR максимально приближенной к производственной среде, чтобы вам пришлось выполнить минимальный объем работы при переносе операций в среду DR.
решение2
Не существует простого способа заставить хосты на сайте DR разрешать "SERVER" в IP-адрес SERVER_DR, сохраняя при этом работоспособность всех AD DNS. Вам нужно использовать псевдоним для всех ссылок на сервер.
Мой обычный подход — создать новый домен (например, mydomain.site), который не является целочисленным доменом AD. Это позволяет использовать отдельные и разные файлы зон для разных DNS-серверов. Затем измените все ссылки на ваши серверы на server.mydomain.site. Это позволяет вашим пользователям использовать одно имя сервера, которое разрешается в то, что подходит для сайта.
Примечание: для работы общего доступа к файлам Windows с псевдонимом CNAME необходимо добавить запись реестра для службы LanManServer. См.http://support.microsoft.com/kb/281308для подробностей. Это работает как на W2k8, так и на 2k и 2k3.
Я настоятельно рекомендую вам использовать Windows DNS для размещения домена .site. Если вы действительно не можете убедить своих системных администраторов помочь, вы можете использовать BIND и настроить серверы Windows DNS как fowarders. Тогда BIND разрешит домен .site, а Windows будет использоваться для всех остальных доменов, включая домен AD. Однако это усложняет обслуживание, поэтому я бы по возможности избегал этого.
Дж.Р.
PS по поводу "Примечание для общего доступа к файлам Windows для работы с псевдонимом CNAME"
Суть использования псевдонима в том, что вы можете просматривать общие ресурсы или подключать сетевые диски, используя имена UNC, например \myserver.mydomain.site\share, где имя "myserver.mydomain.site" разрешается в IP-адрес вашего целевого сервера и может разрешаться в различные IP-адреса на разных сайтах. По умолчанию служба LanManServer не разрешает просмотр, если имя сервера не совпадает с реальным именем сервера, и вы получите сообщение об ошибке, например, "В сети существует дубликат имени". Это делается для повышения безопасности. В статье базы знаний, которую я упомянул, описывается, как отключить проверку имен, чтобы работали имена UNC, подобные указанным выше.
На самом деле я использую этот трюк регулярно, потому что он позволяет легко перемещать общие файлы на разные серверы. Это не замена DFS, но может быть полезным трюком.