Отказоустойчивый DNS на основе браузера с использованием нескольких записей A
Недавно мое внимание привлекло то, что настройка нескольких записей A для имени хоста может использоваться не только для балансировки нагрузки циклического перебора, но и для автоматического переключения при сбое.
Поэтому я попытался проверить это:
- Я загрузил страницу с нашего домена
- Отметил, какой из наших серверов обслуживал страницу
- Выключил веб-сервер на этом хосте
- Перезагрузил страницу
И действительно, браузер автоматически пытался загрузить страницу с другого сервера. Это работало в 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 обработает изменение на другом узле.
Браузеры обычно довольно агрессивно пытаются использовать альтернативные записи, когда кто-то не отвечает.
Пара вещей:
- Ваша проблема с Chrome может быть связана с тем, как он кэширует DNS - он выполняет свое собственное кэширование и довольно агрессивен в этом отношении; мог ли он все еще иметь кешированную запись до того, как у вас появилось несколько записей A?
- Точно так же вы ждали хотя бы TTL зоны DNS после добавления дополнительных записей, чтобы проверить пользователей, приходящих извне?
- Кроме того, убедитесь, что нагрузка была равномерной между серверами. если бы на одном сервере было только 10% трафика, то на другом узле можно ожидать лишь небольшого увеличения, когда он умрет.
Помимо всего этого, циклический перебор DNS отлично подходит для географической избыточности и распределения нагрузки, но имейте в виду, что существуют и другие хорошие решения для локального переключения при сбое.