Современные DNS-решения для балансировки нагрузки
Я учусь распространять системы и сейчас изучаю тему балансировки нагрузки на DNS.
У меня есть несколько серверов Linux, и я хочу настроить следующую конфигурацию:
- один балансировщик нагрузки DNS, который разрешает IP-адрес менее загруженного сервера;
- несколько серверов приложений, которые обрабатывают запросы пользователей и отправляют собственную статистику нагрузки в балансировщик нагрузки DNS.
Некоторое время я гуглил и обнаружил, что lbname создается в соответствии с идеей dlbDNS и делает то, что мне нужно. Что меня смущает, так это то, что он на некоторое время застопорился (без обновлений с 2006 года), хотя есть замечания, что у него мало проблем. Также я не смог найти других решений. Поэтому я подумал, что, возможно, я прибегаю к ошибкам, или, возможно, такая функциональность включена в какое-то широко распространенное приложение, такое как bind.
Поэтому мой вопрос: актуален ли подход балансировки нагрузки на DNS в настоящее время и какие современные решения (приложения) можно использовать?
Заранее спасибо!
3 ответа
Большая часть распределения нагрузки на основе DNS применяется не столько к кластерам в пределах одного центра обработки данных, сколько чаще используется для указания пользователям географически близких экземпляров приложения.
Проблема с DNS заключается в том, что записи кэшируются, часто дольше, чем даже TTL, а это означает, что при обновлении конфигурации вашего кластера и DNS клиенты могут по-прежнему перенаправляться на неактивный / не отвечающий узел.
Это означает, что все меньшая часть ваших пользователей будет испытывать временные проблемы столько времени, сколько потребуется для очистки их кеша DNS.
Это может быть полностью приемлемым или нет. Это также зависит от того, является ли ваше приложение общедоступным или в корпоративной интрасети, и ваши клиенты, например, используют исключительно контроллеры домена Active Directory в качестве DNS-серверов.
Вторая возможная проблема с балансировкой нагрузки на DNS заключается в том, что многие пользователи могут использовать один кеширующий сервер имен, поэтому количество DNS-запросов, которые получает ваш сервер имен, потенциально не влияет на количество запросов, поступающих вам.
Так что нет, в вашем случае вам лучше использовать layer3, балансировку сетевой нагрузки или что-то вроде HAproxy, а не балансировку нагрузки DNS.
Лично я бы никогда не использовал DNS-балансировку нагрузки. Наиболее важной причиной является то, что слишком много неверно работающих распознавателей у интернет-провайдера и на компьютере клиента. Эти средства распознавания могут, например, игнорировать TTL, таким образом, кэшируя ответы DNS и потенциально возвращать неправильные ответы. Поскольку вы не можете должным образом влиять на эти вещи, я бы предпочел не зависеть от них, чтобы балансировка нагрузки работала должным образом.
Все установки балансировки нагрузки, которые я видел (F5, A10 и инструменты с открытым исходным кодом, такие как keepalived), выполняют балансировку нагрузки TCP-сессий (или UDP, ICMP).
"Балансировка нагрузки", хотя исторически не является "истинной" балансировкой, в наши дни балансировка нагрузки на основе DNS является необходимой и очень эффективной частью (первый уровень) решения большого объема и высокой доступности.
Уровень DNS способен разрешать имя DNS для клиента в зависимости от его географического местоположения (GeoIP), тем самым сокращая время отклика на несколько сотен мс.
это было невозможно даже несколько лет назад, когда DNS-балансировка нагрузки или балансировка бедного человека означала одну запись DNS-A с несколькими IP-адресами. эти IP-адреса даже не были балансировщиками нагрузки сами по себе (как вы видите сегодня, использующие CARP/VRRP/HSRP/ и т. д.), но они были настоящими конечными веб-серверами!!!! в этой модели любой сервер, который выходит из строя, приводит к тому, что часть трафика полностью скрывается.
Сегодняшнее использование сложных DNS, как своего собственного уровня HA, очень эффективно. Примером этого является aws route53, который использует не-rfc-совместимую запись "A/ALIAS", чтобы связать домены верхнего уровня с ELB для большой масштабируемости и времени безотказной работы. (нет, я не работаю для aws), однако, есть несколько других провайдеров, которые разрешат ваши dns к запросам клиентов, основываясь на ближайшем центре обработки данных клиентов, который может обслуживать запрос.