Примечание. Это продолжение мой предыдущий вопрос по DNS Failover.
Цель: заставить веб-браузер клиента выбрать следующий доступный сервер, если он немедленно отключается.
Я где-то читал, что несколько записей A (хотя и не лучшее решение) - единственное решение «мгновенного переключения при отказе», возможное для приложений на базе HTTP / браузера.
Вот сценарий / пример:
У меня есть два сервера A и B, которые содержат точно такой же контент. IP-адрес сервера A - 1.1.1.1 и 1.1.1.2. IP-адрес сервера B - 2.2.2.1 и 2.2.2.2. У меня есть домен, зарегистрированный в Godaddy. Если я хочу использовать циклический перебор DNS, какой метод лучше?
Метод 1. Могу ли я установить записи своего сервера имен в Godaddy таким образом?
Метод 2: Или я сделаю Godaddy своим сервером имен и добавлю такие записи:
Мой вопрос: будет ли циклический перебор DNS работать с любым из этих двух методов? Если нет, то каков наилучший метод достижения цели?
Цель: заставить веб-браузер клиента выбирать следующий доступный сервер, если он немедленно отключается.
Обычно это делается путем введения третьего сервера, называемого балансировщиком нагрузки. Балансировщик нагрузки:
Сам балансировщик нагрузки можно сделать высокодоступным, используя 2 балансировщика нагрузки (LB), то есть всего как минимум 4 сервера (2 LB, 2 сервера веб-приложений). Однако многие небольшие магазины работают только с одним балансировщиком нагрузки, потому что это относительно более простые системы и часто очень надежны.
Метод 1. Могу ли я установить записи своего сервера имен в Godaddy таким образом? 1. ns1.serverA.com 2. ns2.serverA.com 3. ns1.serverB.com 4. ns2.serverB.com
Точно нет. Серверы имен используются только для разрешение IP-адресов веб-серверов. Сохраните серверы имен для домена по умолчанию вашего регистратора / хоста DNS (GoDaddy).
Метод 2: Или я могу сделать Godaddy своим сервером имен и добавить A Records следующим образом: 1. A @ 1.1.1.1 2. A @ 1.1.1.2 3. A @ 2.2.2.1 4. A @ 2.2.2.2
Когда DNS Round Robin (DNS RR) используется как часть высокопроизводительной настройки аварийного переключения / высокой доступности, тогда IP-адреса DNS RR указывает на высокодоступны. Другими словами, каждый IP-адрес - это виртуальный IP-адрес, обрабатываемый 2-мя устройствами. Как решение высокой доступности без высокодоступных IP-адресов серверов DNS RR не работает слишком хорошо. Основная проблема в том, что некоторые клиенты могут продолжать использовать "мертвый" IP-адрес, вы полагаетесь на то, что клиент делает «правильные вещи», а не все клиенты. Лучше использовать настоящий балансировщик нагрузки HTTP.
Тем не менее, многие небольшие веб-сайты используют DNS RR для только распределение нагрузки с хорошими результатами. Думаю, все дело в ваших ожиданиях.
В случае DNS RR наличие 2 IP-адресов на физический сервер ничего не дает, только дополнительную сложность. Поэтому просто используйте один IP-адрес для каждого сервера в своей нотации:
A @ 1.1.1.1
A @ 2.2.2.1
Я не думаю, что ваши предложения полностью реализуют то, что вы надеетесь сделать.
Подход A-record, который вы задокументировали, обеспечит все из этих IP-адресов, подходящих для получения вашего контента, поэтому веб-браузер пользователя может свободно использовать любой из них. Если действительно выбранный сервер не работает, тогда браузер пользователя может выберите попробовать другой IP-адрес, но его не будет рядом мгновенное.
Я также сомневаюсь в том, чтобы указывать несколько IP-адресов для одного сервера. Предположим, что сервер A не работает; если мой браузер пытается подключиться к 1.1.1.1, затем (после тайм-аута) пытается подключиться к 1.1.1.2 тогда я буду ждать доставки контента еще дольше.
Если вы действительно хотите надежного быстрого переключения между веб-серверами, вы, вероятно, захотите изучить что-то вроде HAProxy.
РЕДАКТИРОВАТЬ: В частности, вам понадобится пара компьютеров, на которых запущен HAProxy с «плавающим» IP-адресом, общим для них. Затем вы запускаете что-то вроде Сердцебиение на этих ящиках, так что если один из них выйдет из строя, другой обнаружит это и автоматически получит «плавающий» IP-адрес. Наконец, вы указываете своей одной A-записью плавающий IP-адрес (который всегда указывает на тот или иной экземпляр HAProxy).
Вы, вероятно, найдете Конфигурация сети при переполнении стека интересно / познавательно.
То, что вы описываете как method1, нарушает работу DNS и не обеспечивает переключения при отказе. Записи DNS также должны иметь авторитетный источник - не может быть двух конфликтующих авторитетных источников (но может быть несколько копий одной и той же conf).
Обычно вы выбираете подход «A record». Вы также можете контролировать TTL для записей A, которые некоторые регистраторы ICANN могут игнорировать в записях NS.
Round Robin DNS - это здорово, но будьте осторожны, некоторые браузеры (например, старые IE) могут слишком долго кэшировать записи, поэтому, если один из ваших веб-серверов выходит из строя и вы удаляете его IP-адрес из опубликованного DNS, вы все равно можете получить несколько посетителей, переходящих на этот IP-адрес. (все равно довольно небольшой процент, но достаточно, чтобы получить пару жалоб). Однако это очень хорошо для балансировки нагрузки.