Как себя ведет большинство браузеров, если они получают несколько A-записей от DNS-сервера? Придерживайтесь одного IP-адреса, пока он доступен (и используйте другой только в том случае, если IP-адрес не работает)? Или они все время переключаются без причины?
Если большинство современных браузеров придерживаются одного IP, DNS-RR мне будет достаточно в качестве простого решения для аварийного переключения.
В каждом браузере есть собственный метод обработки циклического DNS. Сегодня я потратил некоторое время на изучение этой проблемы и буду продолжать обновлять свой ответ по мере того, как найду доказательства реализации, которые ограничат мои ответы браузерами, раскрывающими их поведение.
Гугл Хром
Google Chrome (используется v58) запросит все записи хоста для адреса (A, AAAA, CNAME) и поместит их в массив (список_адресов). Затем Chrome попытается открыть сокет на каждом IP-адресе в порядке от первого до последнего, Chrome не будет пытаться использовать самый быстрый или ближайший IP-адрес, он предполагает, что первый IP-адрес (указанный вашими восходящими DNS-преобразователями) является лучшим IP-адресом. В моих тестах bind и dns-серверы Windows предоставляют разный порядок IP-адресов для каждого поиска, что дает то, что кажется 50/50 разделением полосы пропускания для каждого IP-адреса. Эта функциональность представлена в chrome://net-internals/#events&q=type:SOCKET%20is:active
Curl (libcurl / 7.54.0)
Curl также имеет эту функцию переключения при отказе, но --connect-timeout намного длиннее, чем по умолчанию в chrome, chrome сразу же отключает, а Curl - нет. Если вы используете libcurl и хотите выжить в циклическом экземпляре DNS, когда один IP не работает (работает в Chrome, но не в коде), обязательно укажите это значение ниже.
DEFAULT_CONNECT_TIMEOUT: 0 заставил меня подумать, что с curl это невозможно.
* After 149990ms connect time, move on!
На обоих браузеры, IP не был липкий, они следовали TTL, указанному в DNS, и как только этот ttl истек (Chrome поддерживает это внутренне, curl запрашивает при каждом запросе), выбор ip выполняется каждый раз, как описано выше.
Что это значит? DNS-RR подходит для некоторых систем, но не предназначен для аварийного переключения. Вы должны ожидать, что все результаты поиска DNS (источник истины) действительны и доступны для обслуживания трафика. Есть много способов гарантировать доступность IP, например, виртуальные плавающие IP-адреса, уловки BGP / маршрутизации и т. Д. Используй их.
Все тесты, выполненные в среде только IPv4, будут возвращены с результатами двойного стека, как только инфраструктура будет доступна для тестирования.
Я предполагаю, что эти изменения являются побочным эффектом RFC IPv6-Fallback. Счастливые глазные яблоки
Обновить Полезное соображение, RR DNS может помочь только с балансировкой нагрузки, но не с ошибками приложений, если один из ваших узлов имеет 503, вы будете обслуживать 40-60%, если ваш трафик 503. Предполагается, что все перечисленные IP-адреса являются допустимыми рабочими конечными точками, если достижимый
См. Этот мой вопрос (и ответ): Как браузеры обрабатывают несколько IP-адресов.
Вкратце - циклический DNS вообще не улучшает доступность. Браузер выбирает один IP-адрес и придерживается его, даже если он не отвечает. (Проверено с помощью FF и хрома).
После истечения срока действия кеша DNS в браузере имя хоста снова разрешается, и процесс повторяется, независимо от того, был ли получен IP-адрес или нет.
Для базового HA вы можете использовать динамический DNS или различные подходы на основе IP.
РЕДАКТИРОВАТЬ: такое поведение будет иметь место, когда недоступный хост действует как «черная дыра». Если вместо этого хост активно отклоняет входящие соединения, браузер попробует один IP-адрес, получит отказ и сразу же использует другой IP-адрес, и, таким образом, он довольно хорошо переключится.
edit: Редактирование моего ответа с тех пор, как HiPerFreak обучил меня.
DNS-серверы вернут список всех A-записей, которые он имеет для данного имени хоста. На помощь приходит циклический перебор, так как он меняет порядок сортировки списка. Опубликованная ссылка - отличный пример того, как веб-браузеры будут использовать этот список.
Round Robinning может использоваться для очень примитивной формы балансировки нагрузки, но это очень плохая замена реальной балансировке нагрузки, поскольку, если один из хостов в циклической ротации выйдет из строя, DNS-сервер не будет мудрее и все равно поместите IP-адрес вышедшего из строя узла в список.
Они переключают IP-адреса, это не решение для аварийного переключения.
Браузеры позволяют ОС выполнять разрешение имен, и, например, Linux всегда рандомизирует IP-адреса, попробуйте host google.com несколько раз. IP-адреса будут расположены в случайном порядке.
DNS возвращает все IP-адреса в списке, но они меняют порядок в списке, и этот порядок не является случайным или изменяется при сбое 1, но они всегда возвращают IP-адреса в той же последовательности для целей балансировки нагрузки. Когда браузер получает список, я полагаю, он выбирает 1-е место в списке, если это не известно как неработающее.