Недавно я обратил внимание на то, что настройку нескольких записей A для имени хоста можно использовать не только для циклической балансировки нагрузки, но и для автоматического переключения при отказе.
Итак, я попробовал проверить это:
И действительно, браузер автоматически пытался загрузить страницу с другого сервера. Это работало в Opera, Safari, IE и Firefox. Только Chrome не смог попробовать другой сервер.
Но оставив этот сервер в автономном режиме на несколько минут и просмотрев журналы доступа, я обнаружил, что количество запросов к другим серверам существенно не увеличилось. Когда 1 из 3 серверов отключен, я ожидал, что доступ к каждому из оставшихся 2 серверов увеличится примерно на 50%, но вместо этого я увидел только 7-10%. Это может означать только то, что отказоустойчивый DNS в браузере не работает для большинства браузеров / посетителей, что прямо противоречит тому, что я только что протестировал.
Кто-нибудь знает, что происходит с отказоустойчивым поведением браузеров DNS? Какая возможная причина может быть, почему автоматическое переключение при отказе работает для меня, но не для большинства наших посетителей?
изменить: Чтобы пояснить, я сделал абсолютно без изменений в наши настройки DNS; здесь нет проблемы TTL или распространения, все дело в том, как клиент обрабатывает несколько записей A.
Хорошо, я собираюсь начать с того, что DNS никоим образом не является хорошей системой аварийного переключения, вам нужен обратный прокси-сервер или балансировщик нагрузки. Есть несколько причин, почему опыт не такой. Прежде всего, в Chrome он использует ОС для получения информации DNS, так что IP-адреса зависят от ОС, поэтому ОС в этом случае может дать ей только один IP.
Что касается других браузеров, это сильно зависит от того, как они делают DNS, как это будет работать. Таким образом, сам браузер может решить не пробовать другие IP-адреса или даже попробовать один и тот же несколько раз в зависимости от ответа DNS-сервера.
Это подводит нас к самому DNS-серверу, большинство из которых не уважают ваши записи TTL и сохраняют их так долго, как кажется, что означает, что пользователи могут получить ваш старый IP-адрес довольно долго ...
В-четвертых, пользовательский интерфейс. Вы хотите, чтобы пользователям приходилось обновляться 3 или 4 раза, чтобы получить ваш сайт? Есть ли на вашем сайте какие-либо сеансы или логины, что произойдет, если браузер получит другой IP-адрес в середине сеанса. Если вам действительно нужна высокая доступность и время безотказной работы, вам действительно нужно подумать о том, чтобы сделать это правильно, честно говоря, иначе это приведет к большему разбору, чем использование только одного сервера.
Для меня это отличное решение, если вы не хотите платить за дорогие балансировщики нагрузки. См. Мой ответ о том, как с этим справляется браузеры: https://serverfault.com/a/868535/114520
Теперь, к вашему сведению, как вы отслеживали accesses? Был ли он размером с какой-то access_log? Было ли это количество запросов в секунду на вашем веб-сервере?
Возможно, у вас есть какое-то решение для кеширования на веб-сервере, которое не попадет на ваш динамический сервер (PHP, Java ...), если запрос уже находится в кеше. Чем больше серверов, тем больше запросов перед кешированием (если они не используют общий кеш).
Прежде чем предположить, что это проблема с DNS, добавьте реальный мониторинг: например, трекер аналитики в реальном времени или что-то в этом роде. Затем выключите один сервер и посмотрите, показывает ли лайв-трекер уменьшение количества текущих пользователей на сайте.
Я много лет использую и использую эту установку с удовольствием. Я только добавил еще несколько решений для аварийного переключения:
Если один PHP-FPM выйдет из строя, зонд Varnish откажет и удалит бэкэнд, пока зонд снова не станет исправным. Если Varnish не работает, браузер Round-Robin + обработает изменение для другого узла.
Браузеры обычно довольно агрессивно пытаются использовать альтернативные записи, когда одна из них не отвечает.
Пара вещей:
Помимо всего прочего, циклический перебор DNS отлично подходит для географической избыточности и балансировки нагрузки, но имейте в виду, что есть и другие хорошие решения для локального аварийного переключения.