Отказоустойчивый DNS на основе браузера с использованием нескольких записей A

Недавно мое внимание привлекло то, что настройка нескольких записей A для имени хоста может использоваться не только для балансировки нагрузки циклического перебора, но и для автоматического переключения при сбое.

Поэтому я попытался проверить это:

  1. Я загрузил страницу с нашего домена
  2. Отметил, какой из наших серверов обслуживал страницу
  3. Выключил веб-сервер на этом хосте
  4. Перезагрузил страницу

И действительно, браузер автоматически пытался загрузить страницу с другого сервера. Это работало в Opera, Safari, IE и Firefox. Только Chrome не смог попробовать другой сервер.

Но, оставив этот сервер в автономном режиме на несколько минут и просмотрев журналы доступа, я обнаружил, что количество запросов к другим серверам значительно не увеличилось. При отключении 1 из 3 серверов я ожидал, что доступ к каждому из оставшихся 2 серверов увеличится примерно на 50%, но вместо этого я увидел только 7-10%. Это может означать только то, что переключение DNS в браузере не работает для большинства браузеров / посетителей, что прямо противоречит тому, что я только что протестировал.

У кого-нибудь есть идея, что происходит с поведением DNS при отказе браузера? Какова возможная причина, почему автоматический переход на другой ресурс работает для меня, но не для большинства наших посетителей?

редактировать: чтобы прояснить ситуацию, я абсолютно не изменил наши настройки DNS; здесь нет проблемы с TTL или распространением, все зависит от того, как клиент обрабатывает несколько записей A.

Источник

3 ответа

Хорошо, я начну с того, что DNS не является хорошей отказоустойчивой системой, вам нужен обратный прокси или балансировщик нагрузки. Есть несколько причин, почему опыт не совпадает. Прежде всего, в Chrome он использует ОС для получения информации DNS, так что она зависит от ОС для IP-адресов, поэтому ОС в этом случае может дать ей только один IP-адрес.

Насколько другие браузеры сильно зависят от того, как они работают с DNS, и от того, как он будет работать. Таким образом, сам браузер может решить не пытаться использовать другие IP-адреса или даже попробовать один и тот же несколько раз в зависимости от ответа DNS-сервера.

Это приводит нас к самому DNS-серверу, большинство не уважает ваши TTL-записи и сохраняет то, как долго это будет продолжаться, а это значит, что пользователи могут получить ваш старый IP-адрес довольно долго...

В-четвертых, пользовательский опыт: хотите ли вы, чтобы пользователи обновляли ваш сайт 3 или 4 раза? Есть ли у вас на сайте какие-либо сеансы или вход в систему, что произойдет, если браузер получит другой IP-адрес в середине сеанса. Если вам действительно нужны HA и время безотказной работы, вам действительно нужно подумать о том, чтобы сделать это правильно, если честно, иначе это приведет к большему разрыву, чем при использовании только одного сервера.

Источник

Для меня это очень важно, если вы не хотите платить за дорогие балансировщики нагрузки. Смотрите мой ответ здесь о том, как это обрабатывается браузерами: /questions/217925/yavlyaetsya-li-round-robin-dns-dostatochno-horoshim-dlya-balansirovki-nagruzki-s/217952#217952

Теперь, для вашего беспокойства, как вы контролировали accesses? Был ли это размер некоторых access_log? Были ли запросы в секунду на вашем веб-сервере?

Возможно, у вас есть какое-то решение для кэширования на веб-сервере, которое не попадет на ваш динамический сервер (PHP, Java...), если запрос уже находится в кеше. Чем больше серверов, тем больше запросов перед кэшированием (если они не разделяют кеш).

Прежде чем предположить, что это проблема DNS, добавьте реальный мониторинг: например, трекер аналитики в реальном времени или что-то в этом роде. Затем отключите один сервер и посмотрите, показывает ли текущий трекер уменьшение количества текущих пользователей на сайте.

В течение многих лет я использовал и до сих пор использую эту установку с настоящим удовольствием. Я только добавил еще несколько решений отработки отказа:

  • Round-Robin на 2 или 3 узла
  • каждый узел имеет:
    • Лак с директором / зондами для всех бэкэндов
    • lighttpd (Apache или nginx подойдут!) на другом порту с fastcgi
    • PHP-FPM пул

Если один PHP-FPM выйдет из строя, пробник Varnish выйдет из строя и удалит бэкэнд, пока пробник снова не будет исправен. Если сбой Varnish завершится, то Round-Robin+browser обработает изменение на другом узле.

Источник

Браузеры обычно довольно агрессивно пытаются использовать альтернативные записи, когда кто-то не отвечает.

Пара вещей:

  1. Ваша проблема с Chrome может быть связана с тем, как он кэширует DNS - он выполняет свое собственное кэширование и довольно агрессивен в этом отношении; мог ли он все еще иметь кешированную запись до того, как у вас появилось несколько записей A?
  2. Точно так же вы ждали хотя бы TTL зоны DNS после добавления дополнительных записей, чтобы проверить пользователей, приходящих извне?
  3. Кроме того, убедитесь, что нагрузка была равномерной между серверами. если бы на одном сервере было только 10% трафика, то на другом узле можно ожидать лишь небольшого увеличения, когда он умрет.

Помимо всего этого, циклический перебор DNS отлично подходит для географической избыточности и распределения нагрузки, но имейте в виду, что существуют и другие хорошие решения для локального переключения при сбое.

Источник
Другие вопросы по тегам