Включить циклический перебор dns
В настоящее время у меня работает сайт, трафик которого распределяется между 7 зеркальными серверами прямо сейчас (с использованием циклического перебора DNS). Но скоро потребуется больше зеркал, учитывая высокий объем трафика, который постоянно растет.
Существуют ли какие-либо практические или рекомендуемые ограничения на количество IP-адресов, связанных с данным доменным именем, при использовании циклического DNS?
Кроме того, какое решение вы бы порекомендовали, если количество зеркал велико (например, более 10 или 20 зеркал)?
Следует иметь в виду, что по умолчанию при поиске DNS используется UDP. Если ответ больше, чем может поместиться в одной дейтаграмме, возвращается столько, сколько подходит, и в заголовке устанавливается бит TC (усеченный).
Запрашивающая сторона может выбрать работу с тем, что было возвращено, или повторить запрос, используя TCP.
Кэширующие DNS-серверы не должны кэшировать усеченные ответы, так как они не знают, насколько полным является набор возвращаемых записей (в ответе не говорится «Я даю вам 12 из 28 записей»).
Таким образом, максимальное количество записей зависит от того, сколько вы можете вставить в дейтаграмму UDP. Помните, что ответ должен включать раздел полномочий, размер которого зависит от записи SOA для зоны.
Если вы используете записи CNAME, это также увеличит размер ответа, так как вы получите CNAME и запись A того объекта, на который указывает.
Лучше всего поиграть с различными номерами записей A, используя dig или "host -v", чтобы увидеть, когда запрос пересекает максимальный размер ответа UDP.
фактически кеширующим серверам разрешается кешировать ответы, если весь раздел получен. Если с разделом «ответ» все в порядке, но «дополнительный» раздел был усечен, было бы неплохо кэшировать этот ответ.
Не существует жесткого ограничения, но большинство сайтов не используют более 5 или 10 зеркал. Зеркальное отображение с помощью циклического перебора DNS наиболее полезно, если сайты географически разделены, так что в дополнение к распределению нагрузки существует избыточность.
По мере увеличения количества зеркал эффективность использования циклического перебора DNS при распределении нагрузки уменьшается, поскольку циклический перебор DNS не учитывает различные запросы, требующие большего количества ресурсов. Лучше использовать балансировку внешней нагрузки для распределения рабочей нагрузки по нагрузке на ЦП и доступности сервера, что также упростит обслуживание, поскольку сервер может быть немедленно отключен без изменения DNS, в результате чего клиенты пытаются получить доступ к отключенному серверу из кэшированных записей DNS. ,
Я опоздал на этот вопрос, но я подумал, что было бы неплохо упомянуть фактические пределы того, что вы можете сделать. Я не знаю теоретического предела, но некоторые интернет-провайдеры не будут принимать что-либо после 36. На самом деле, если вы включите больше, это не только не будет включать дополнительные серверы, они будут полностью игнорировать вас. У меня были проблемы с Verizon и Comcast, но я уверен, что другие пострадали.
Тем не менее, если у вас достаточно трафика для гарантии 36 зеркал, пожалуйста, не используйте циклический DNS.
Если у вас много серверов, возможно, лучший ответ - это сделать Akamai и использовать anycast DNS-серверы и циклический перебор. Другими словами, DNS-серверы для зоны распределены по сети, все с одинаковыми IP-адресами, и точки маршрутизации клиентов находятся на ближайших серверах по сети. Каждый сервер отвечает в циклическом порядке за подмножество полного списка возможных серверов.
Мы делаем что-то очень похожее, но мы используем аппаратные балансировщики нагрузки (кстати, Cisco ACE), единственным ограничением является размер подсети (если таковой).
В этой статье описываются некоторые основные методы балансировки трафика клиента ко всем точкам подключения в HPC Cache Azure.
Каждый HPC Cache имеет по крайней мере три разных IP-адреса, а кэши с большими значениями пропускной способности могут иметь до 12. Важно использовать все IP-адреса, чтобы получить все преимущества Azure HPC Cache.
Существуют различные варианты балансировки нагрузки, доступные для подключения клиента.
- Вручную выберите другой IP-адрес подключения для каждого клиента.
- Включение смены IP-адресов в скрипты подключения клиента
- Настройка системы DNS для автоматической маршрутизации клиентских запросов между всеми доступными адресами (dns с циклическим перебором)
Правильная система балансировки нагрузки зависит от сложности рабочего процесса, количества IP-адресов в кэше и большого количества других факторов. Если вам нужна помощь в выборе оптимального подхода, обратитесь к помощнику по Azure.
Дополнительная информация
Функция заказа netmask используется для возврата адресов для запросов типа A DNS для приоритета локальных ресурсов для клиента. Например, если эти условия верны, результаты запроса на имя возвращаются клиенту на основе близости ip-адресов.
- У вас есть восемь записей типа A для того же имени DNS.
- Каждый из восьми записей типа A имеет отдельный адрес.
В начальном выпуске Microsoft Windows 2000 Server эта близость вычисляется на основе исходного класса адреса, назначенного клиенту. Если клиенту назначен адрес родного класса A, то ответы, отосланные клиенту, будут приоритизированы записями, которые соответствуют членству в сети класса клиента A. Это также относится к родным адресам класса B и родному классу C.
Функция кругового робина используется для рандомизации результатов аналогичного типа запроса, чтобы обеспечить базовую функциональность балансировки нагрузки. В более ранних примерах восемь записей типа А с одинаковым именем и разными IP-адресами приводят к тому, что для каждого запроса в верхней части будет приоритизирован другой ответ. Так как новый IP-адрес приоритизирован в верхней части каждого запроса, клиенты не будут повторно маршрутизироваться на один и тот же сервер.
Начальный выпуск Windows 2000 Server не может одновременно использовать функцию заказа netmask и функцию кругового робина. Если включена функция заказа netmask, ответы всегда предоставляются клиентам в том же порядке. В Windows Server 2003 это поведение изменилось, чтобы разрешить использование как функции заказа netmask на основе подсетей, так и функции кругового робина. Использование функции заказа netmask и функции кругового робина обеспечивает осведомленность о близости и балансировку нагрузки.
Во многих текущих сетевых средах часто бывает необычно иметь маску подсети, которая является родным для фактического адреса. Поэтому нетмаск-заказ, основанный на родном классе IP-адреса, ненадежен при прогнозировании локальности сети. Windows Сервер 2003 расположен вблизи класса C независимо от типа родного адреса.
Вы можете использовать команду Dnscmd /Config /LocalNetPriorityNetMask 0x000000FF Dnscmd.exe для восстановления параметров Windows Server 2003 в параметры по умолчанию.
Хотя параметр по умолчанию в Windows Server 2003 является базой близости к классу C, этот параметр можно изменить. Можно определить, какая часть маски является относительной для заказа netmask в зависимости от среды. При выпуске коммутатора /LocalNetPriorityNetMask можно указать те биты, которые важны для операции заказа netmask. Вы можете использовать Dnscmd /Config /LocalNetPriorityNetMask 0x0000FFFF команду, чтобы использовать класс B (или 16 бит) для заказа netmask.
В следующей таблице перечислены другие параметры заказа netmask:
Netmask | LocalPriorityNet |
---|---|
255.255.255.0 | 0x000000ff |
255.255.0.0 | 0x0000ffff |
255.0.0.0 | 0x00ffffff |
Если для хоста используется только 6 битов, маска — 255.255.255.192. В ciDR-нотации, бесклассовом маршрутизации междоменов, это будет маска /26. Вы можете использовать команду для настройки подсети Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F Dnscmd.exe класса C.
Значительные биты устанавливают, какая часть адреса — это место хозяйского адреса. Поскольку двоичный эквивалент 0x3 равно 11, а двоичный эквивалент 0xF — 1111, в качестве части хост-адреса устанавливаются 6 битов. Если требуется 7 битов (255.255.255.128 или /25), значение будет 0x0000007F, так как двоичный эквивалент 0x7F 0111 1111. Если требуется всего 5 битов (255.255.255.224 или /27), значение будет 0x0000001F, так как двоичный эквивалент 0x1F равен 0001 1111.
Команда настраивает Windows Server 2003 для использования кругового и сетевого заказа на основе класса Dnscmd /Config /LocalNetPriorityNetMask 0xFFFFFFFF ip-адресов клиента.
Для успешного выполнения этой процедуры необходимо войти в систему на сервере или в домене в группу администраторов домена или в группу пользователей DnsAdmins.
Для использования балансировки нагрузки DNS необходимо выполнить указанные ниже действия.
Переопределение полного доменного имени пула внутренних веб-служб.
Если вы решите переопределить внутренние веб-службы с помощью самоопределенного полного доменного имени, каждое полное доменное имя должно быть уникальным из любого другого пула переднего плана, режиссера или директора пула.
Создайте DNS A Records hosts, чтобы разрешить полное доменное имя пула с IP-адресами всех серверов в пуле.
Включение случайного выбора IP-адреса или для DNS-сервера Windows Server включите циклическое управление.
По умолчанию будет включена функция "циклический перебор".
Проверка работы DNS Round robin
В Windows Server опция Enable round robin включена по умолчанию. Достаточно в консоли DNS Manager открыть свойства DNS сервера и посмотреть вкладку Advanced.
Что такое DNS Round robin и как он работает-01
Что такое DNS Round robin и как он работает-02
Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
Анализ кэша DNS на стороне клиента дает следующий результат:
C:\>ipconfig /displaydns
Windows IP Configuration
Теперь становится понятно, почему мы “пингуем” один и тот же хост 20.0.0.1. Сервер DNS возвращает клиенту все записи из зоны с указанием времени кэширования, равным по умолчанию 1 часу (или 3600 секундам). Поэтому до истечения времени кэширования (TTL – Time To Live) клиент больше не направляет к серверу DNS никаких новых запросов.
Возможные варианты:
постоянный сброс кэша на стороне клиента (плохой вариант);
установка времени кэширования, равное нулю, в свойствах зоны (плохой вариант, поскольку влияет на всю зону);
установка индивидуального времени кэширования на отдельных записях (хороший вариант).
Для настройки индивидуального времени кэширования в консоли DNS Manager требуется сначала включить режим View –> Advanced. Затем последовательно открываем свойства записей (в нашем примере это три записи www) и ставим время кэширования, равное нулю.
Что такое DNS Round robin и как он работает-03
Ping statistics for 40.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Файл зоны на сервере DNS при этом будет выглядеть так:
;
; Database file gorbunov.pro.dns for gorbunov.pro zone.
; Zone version: 7
;
www 0 A 20.0.0.1
0 A 30.0.0.1
0 A 40.0.0.1
Добавления нуля в записи типа A можно сделать и вручную непосредственно в файле зоны.
Технология DNS Round robin часто применяется для динамической балансировки нагрузки между зеркальными хостами. Она значительно проще в реализации, чем вариант настройки для тех же целей кластера NLB. При настройке DNS Round robin на серверах Windows не забывайте, что настройки по умолчанию для сервера DNS не позволяют в полной мере реализовать балансировку запросов и требуется ручная конфигурация сервера.
Чтобы переопределить полное доменное имя внутренней веб-службы
Запустить построитель топологии: нажмите кнопку Пуск, выберите пункт все программы, а затем — Microsoft Lync Server 2013 и нажмите кнопку Построитель топологии Lync Server.
В дереве консоли разверните узел Пулы переднего плана Enterprise Edition.
Щелкните пул правой кнопкой мыши, выберите команду изменить свойства, а затем — веб-службы.
В разделе внутренние веб-службы установите флажок Переопределение полного доменного имени .
Введите полное доменное имя пула, которое разрешается в физические IP-адреса серверов в пуле.
Под внешними веб-службами введите полное доменное имя внешнего пула, которое разрешается в виртуальные IP-адреса пула, и нажмите кнопку ОК.
В дереве консоли щелкните Lync Server 2013, а затем в области действия выберите пункт топология публикации.
Использование балансировки нагрузки с использованием скриптов
Существует несколько способов программной смены подключений клиента между доступными IP-адресами. Ниже приведены два примера.
Назначение IP-адресов вручную
Настройка распределения циклического перебора для точек подключения кэша
Система DNS с циклическим перебором (RRDNS) автоматически направляет клиентские запросы между несколькими адресами.
Чтобы настроить эту систему, необходимо настроить файл конфигурации DNS-сервера таким образом, чтобы при получении запросов на подключение к основному адресу домена HPC Cache он назначает трафик между всеми точками подключения системы HPC Cache. Клиенты подключают HPC Cache, используя его доменное имя в качестве аргумента сервера, и направляются к следующему IP-адресу подключения автоматически.
Для настройки RRNDS необходимо выполнить два основных действия:
Измените файл DNS-сервера named.conf , чтобы задать циклический порядок запросов к HPC Cache. Если задан этот параметр, сервер циклически перебирает все доступные значения IP-адресов. Добавьте инструкцию следующим образом:
Настройте записи А и PTR для каждого доступного IP-адреса, как показано в приведенном ниже примере.
Эти команды создают запись A для каждого адреса подключения HPC Cache, а также настраивают записи указателя для поддержки обратных проверок DNS соответствующим образом.
На приведенной ниже схеме показана базовая структура этой конфигурации.
После настройки системы RRDNS попросите клиентские компьютеры использовать его для разрешения адреса HPC Cache в командах подключения.
В этой статье описывается функция заказа netmask и функция кругового робина и совместное использование этих функций.
Применяется к: Window Server 2003
Исходный номер КБ: 842197
Включение циклического переобслуживанием для Windows Server
Разверните узел DNS, щелкните правой кнопкой мыши DNS-сервер, который вы хотите настроить, и выберите пункт свойства.
На вкладке Дополнительно установите флажок включить циклический перебор и включите расстановку по сети, а затем нажмите кнопку ОК.
Теория
Статья описывает одну из технологий балансировки нагрузки, которая может быть реализована средствами DNS. Для перевода имени хоста в IP-адрес клиент DNS направляет серверу DNS рекурсивный запрос (т.е. запрос, на который сервер DNS возвращает клиенту либо ответ с IP адресом, либо ответ с ошибкой).
В подавляющем большинстве случаев в зонах DNS содержится только один IP адрес, соответствующий тому или иному имени хоста. А какой IP адрес будет возвращать клиенту сервер DNS, если зона содержит несколько записей типа A для одного и того же имени? Ответ простой: сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д.
Поскольку адрес 20.0.0.1 идет первым в списке, клиент всегда будет пытаться связаться именно с сайтом по адресу 20.0.0.1. Получается, что сайты 30.0.0.1 и 40.0.0.1 используются только как пассивный резерв. До тех пор, пока "жив" сайт по адресу 20.0.0.1, сайты 30.0.0.1 и 40.0.0.1 не получат от клиента ни одного запроса.
Как сделать, чтобы запросы “доставались” всем хостам? Ответ простой: настроить на сервере DNS функцию Round robin.
На второй запрос от клиента или от другого сервера DNS будет возвращен ответ
В результате мы получаем динамическую балансировку запросов клиентов между несколькими хостами.
Практика
____________________________________________________________________________________
Создание записей DNS Host (A) для всех внутренних серверов пула
В диспетчере DNS выберите DNS-сервер для управления записями, чтобы развернуть его.
Щелкните правой кнопкой мыши домен DNS, в который нужно добавить записи, и выберите команду создать узел (A или AAAA).
В поле Имя введите имя записи узла (имя домена добавляется автоматически).
В поле IP-адрес введите IP-адрес отдельного сервера переднего плана, а затем выберите команду создать соответствующую запись указателя (PTR) или разрешите пользователям, прошедшим проверку подлинности, обновлять записи DNS с тем же именем владельца, если это применимо.
Продолжайте создавать записи для всех серверов-интерфейсов участников, которые будут принимать участие в балансировке нагрузки DNS.
Дополнительные сведения о создании записей DNS Hosting (A) можно найти в разделе Настройка записей узлов DNS для Lync Server 2013.
Сводка
В этой статье описывается функция заказа netmask и функция кругового робина в Windows Server 2003 системы доменных имен (DNS). Кроме того, в этой статье описывается совместное использование этих функций. Вы можете сделать это, чтобы рандомизировать результаты, возвращаемые с заказаного сервера netmask.
Функция кругового робина DNS позволяет DNS каждый раз возвращать IP-адреса имени в другом порядке.
Пример функции циклического перебора
В этом примере кода IP-адреса клиента используются в качестве случайного элемента для распределения клиентов по всем доступным IP-адресам HPC Cache.
Использование балансировки нагрузки DNS
В этом разделе описываются основы настройки системы DNS для распространения клиентских подключений ко всем точкам подключения в azure HPC Cache. Этот метод не учитывает объем трафика, создаваемый каждым клиентом, но гарантирует равномерное распределение клиентов по всем интерфейсам кэша, а не только одним или двумя.
В этом документе не содержатся инструкции по настройке DNS-сервера и управлению ими для клиентов в среде Azure.
DNS не требуется для подключения клиентов с помощью протокола NFS и IP-адресов. Dns требуется , если вы хотите использовать доменные имена вместо IP-адресов для доступа к аппаратным системам NAS или если рабочий процесс включает некоторые дополнительные параметры протокола.
Dns-система, используемая для распространения адресов клиентам, не должна обращаться к HPC Cache. В некоторых ситуациях может потребоваться использовать пользовательскую систему DNS для самого кэша, но настройка этой системы гораздо сложнее, чем настройка такой системы циклического перебора клиента. Если вы думаете об изменении DNS-сервера HPC Cache на пользовательскую систему, обратитесь к поддержка Azure.
Пример cksum скрипта команды Mount
В этом примере команда подключения использует хэш-функцию cksum и имя узла клиента для автоматического распределения клиентских подключений между всеми доступными IP-адресами в HPC Cache. Если все клиентские компьютеры имеют уникальные имена узлов, можно выполнить эту команду на каждом клиенте, чтобы убедиться, что используются все доступные точки подключения.
Чтобы использовать этот пример в рабочем процессе, настройте следующие термины:
X= В выражении используйте разделенный пробелом список всех адресов подключения кэша в отсортированном порядке.
(X=(10.0.0.) Выражение задает переменную X, так как этот набор адресов подключения: . Используйте базовый IP-адрес кэша и точные адреса, показанные на странице обзора кэша. Если адреса не являются последовательными, перечислите их все в числовом порядке.
В этом %3 случае используйте фактическое число IP-адресов подключения, которые имеет кэш (обычно 3, 6, 9 или 12).
Например, используйте %9 , если кэш предоставляет девять IP-адресов подключения клиента.
Для выражения $ используйте путь к целевому пространству имен хранилища, к которому будет обращаться клиент.
Можно использовать определенную переменную (NAMESPACE в примере) или передать литеральное значение.
В примере команды в конце этого раздела используется литеральное значение для пути /blob-target-1 к пространству имен.
Если вы хотите использовать пользовательский локальный путь на клиентских компьютерах, измените значение /mnt на нужный путь.
Ниже приведен пример заполненной команды подключения клиента:
Читайте также: