Регистрация Войти
Рейтинг:0
avatar Server

Создание записи DNS A для 3 контроллеров домена

флаг pl
Malata

Я установил новый домен в нашей сети, состоящий из 2 контроллеров домена, dc1, dc2. Я вижу записи A для двух контроллеров. Но мне нужно выполнить балансировку нагрузки, чтобы я мог ссылаться на 2 контроллера домена в одной записи.

Я создал две записи A с одинаковым именем для разных IP-адресов, dc.domain.com. Это стандартная процедура?

115
0 + 0
joeqwerty avatar
флаг cv
joeqwerty
**Но мне нужно выполнить балансировку нагрузки, чтобы я мог сослаться на 2 контроллера домена в одной записи**. Можете ли вы рассказать нам, почему вы хотите/должны выполнять «балансировку нагрузки» и что вы подразумеваете под этим утверждением?
0
Ответить
флаг pl
Malata
Спасибо. У меня есть приложение с примерно 10 000 пользователей, которое аутентифицируется в Active Directory.
0
Ответить
Рейтинг:2
Nikita Kipriyanov avatar Server
флаг za
Nikita Kipriyanov

Активный каталог уже есть форма балансировки нагрузки DNS. Вы просто смотрите не туда.

А запись просто говорит, какой контроллер имеет какой IP-адрес. Куда направляются клиенты для каждой доменной службы (LDAP, Kerberos, Global Catalog LDAP и т. д.), настраивается с помощью СРВ записи. И если вы не сделали ничего необычного, у вас будет СРВ записи в вашем домене уже указывают на каждый контроллер домена для каждой службы.

Вот типичная структура зоны DNS домена Active Directory:

пример.com.                              3600 В SOA dc1.example.com. admin.example.com 66593 900 600 86400 3600
пример.com. 3600 В NS dc1.example.com.
пример.com. 3600 В NS dc2.example.com.
пример.com. 600 В А 192.168.3.1
пример.com. 600 В А 192.168.4.1
_gc._tcp.example.com. 600 IN SRV 0 100 3268 dc2.example.com.
_gc._tcp.example.com. 600 IN SRV 0 100 3268 dc1.example.com.
_kerberos._tcp.example.com. 600 IN SRV 0 100 88 dc2.example.com.
_kerberos._tcp.example.com. 600 IN SRV 0 100 88 dc1.example.com.
_kpasswd._tcp.example.com. 600 IN SRV 0 100 464 dc2.example.com.
_kpasswd._tcp.example.com. 600 IN SRV 0 100 464 dc1.example.com.
_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc2.example.com.
_ldap._tcp.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_kerberos._udp.example.com. 600 IN SRV 0 100 88 dc2.example.com.
_kerberos._udp.example.com. 600 IN SRV 0 100 88 dc1.example.com.
_kpasswd._udp.example.com. 600 IN SRV 0 100 464 dc2.example.com.
_kpasswd._udp.example.com. 600 IN SRV 0 100 464 dc1.example.com.
DomainDnsZones.example.com. 600 В А 192.168.3.1
DomainDnsZones.example.com. 600 В А 192.168.4.1
_ldap._tcp.DomainDnsZones.example.com. 600 IN SRV 0 100 389 dc2.example.com.
_ldap._tcp.DomainDnsZones.example.com. 600 IN SRV 0 100 389 dc1.example.com.
ForestDnsZones.example.com. 600 В А 192.168.3.1
ForestDnsZones.example.com. 600 В А 192.168.4.1
_ldap._tcp.ForestDnsZones.example.com.    600 IN SRV 0 100 389 dc2.example.com.
_ldap._tcp.ForestDnsZones.example.com. 600 IN SRV 0 100 389 dc1.example.com.
dc1.example.com. 3600 В А 192.168.3.1
dc2.example.com. 3600 В А 192.168.4.1
_msdcs.example.com. 3600 В NS dc1.example.com.
_gc._tcp.Default-First-Site-Name._sites.example.com. 600 IN SRV 0 100 3268 dc1.example.com.
_kerberos._tcp.Первое-имя-сайта-по-умолчанию._sites.example.com. 600 IN SRV 0 100 88 dc1.example.com.
_ldap._tcp.Первое-имя-сайта-по-умолчанию._sites.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_gc._tcp.alter-site._sites.example.com. 600 IN SRV 0 100 3268 dc2.example.com.
_kerberos._tcp.alter-site._sites.example.com. 600 IN SRV 0 100 88 dc2.example.com.
_ldap._tcp.alter-site._sites.example.com. 600 IN SRV 0 100 389 dc2.example.com.
_ldap._tcp.alter-site._sites.DomainDnsZones.example.com. 600 IN SRV 0 100 389 dc2.example.com.
_ldap._tcp.alter-site._sites.ForestDnsZones.example.com. 600 IN SRV 0 100 389 dc2.example.com.

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

Вы можете изменить распределение нагрузки между контроллерами, изменив те СРВ записи. Видишь "100"? Эти веса. Если поставить 67 для одного ДЦ и 33 для другого, то первый получит 2/3 запросов, а второй 1/3. "0" перед каждым СРВ запись приоритеты; если у вас есть доступные серверы с более высоким приоритетом, более низкий приоритет вообще не будет запрашиваться. Пожалуйста, найдите СРВ запись описания для деталей; в инете полно объяснений, в том числе и на этом сайте.

Есть несколько записей, которые «несимметричны». Например, СОА запись содержит определенное имя DNS-сервера. Но в данном случае они используются редко, и это не является узким местом.

Также важное замечание о SYSVOL. Когда клиенты входят в систему, после проверки паролей (что включает Керберос service), они запрашивают у домена групповые политики и делают это с помощью домен имя, а не конкретное имя контроллера домена, например: \example.com\SYSVOL (а не, например, \dc1.example.com\SYSVOL). Вы можете видеть, что вершина домена имеет несколько А записей, по одной на каждый контроллер домена (4-я и 5-я строки примера). Клиент будет использовать случайно выбранные А запись для подключения, поэтому каждый контроллер домена будет иметь примерно одинаковую долю.

0 + 0
Рейтинг:0
avatar Server
флаг cn
Greg Askew

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

Примечание: это нет высокая доступность и не должна считаться таковой.

0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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