Меня попросили восстановить нашу инфраструктуру балансировки нагрузки в центре обработки данных.
Первоначальный запрос заключался в балансировке нагрузки на FTP-серверы. Я пробовал сделать это, используя текущий балансировщик нагрузки (Piranha / LVS), но не запустил его. Не только потому, что для этого программного обеспечения практически нет документации. поскольку Piranha считается устаревшим, я перешел на HAProxy после нескольких дней попыток, которые сделали работу за долю времени, потраченного на Piranha.
Итак, у меня есть балансировка нагрузки FTP (пассивный режим). Теперь меня попросили полностью заменить балансировщик нагрузки Piranha в центре обработки данных. В текущей конфигурации Piranha у нас есть несколько веб-серверов, серверов IIS .... аааи DNS.
Нет, вот в чем дело:
HAProxy кажется широко используемым LB, но он не способен обрабатывать UDP load balancing. Это облом, так как мне нравится, как HAProxy работает. Так что я много погуглил и наткнулся на несколько вещей. Большинство людей используют LVS как LB для DNS (TCP / UDP). Некоторые используют dlbDNS, некоторые используют lbnamed, а некоторые используют netfilter / iptables.
Поскольку я хотел бы придерживаться HAProxy для серверов FTP, HTTP, IIS я запутался в использовании его рядом с LVS.
Требования:
2 экземпляра LB с аварийным переключением
2 DNS-сервера (уже существующие) с аварийным переключением
Несколько внутренних серверов (http, приложение и т. Д.)
Вопросы:
Это возможно? Нужна ли вообще балансировка нагрузки UDP на DNS-серверах? Есть ли какой-нибудь ресурс, который мог бы показать мне, как начать с этого? Или есть решение LB, способное не только обрабатывать TCP / HTTP, но и балансировку нагрузки UDP?
PS: Решение LB не должно быть аппаратным и иметь открытый исходный код / лицензию GPL / бесплатное.
Любая помощь или ссылка на соответствующие ресурсы приветствуются!
Не балансируйте нагрузку на свой DNS.
Это невероятно легкий протокол - вам потребуется огромный объем трафика, чтобы потребовалось более одного ящика (в этом случае вы все равно будете узким местом в своем балансировщике нагрузки), и в него встроена устойчивость, потому что вы можете использовать несколько записей NS. в вашей делегации (в случае отказа одного из серверов будут использоваться другие серверы).
Мне неудобны эти вопросы и ответы, потому что на самом деле еще не установлено, о каком DNS-сервере вы говорите. Когда дело доходит до отказоустойчивости рекурсивного DNS, существует несколько серьезных заблуждений, и важно, чтобы люди, заходящие через поисковые системы, не уходили от этого обсуждения с ложным чувством безопасности.
Авторитетный DNS: Для авторитетных DNS-серверов общие знания об отказоустойчивости DNS довольно точны. Пока у вас есть несколько авторитетных DNS-серверов, которые геоизбыточны, все в порядке. Основная причина добавления высокой доступности для отдельных IP-адресов - это хостинг много авторитетные зоны. Это позволяет вам увеличить количество серверов без необходимости изменять настройки регистратора для каждого размещенного домена.
Рекурсивный DNS: Всегда используйте какую-либо форму решения высокой доступности. (BGP, устройство и т. Д.) Здесь вы можете столкнуться с серьезными проблемами. Все библиотеки преобразователя не созданы равными: клиенты DNS Windows будут циклически перебирать исходный сервер, используемый между запросами, но большинство систем на основе Unix всегда будут циклически просматривать список последовательно. Что даже Меньше известно, что у этих библиотек Unix будет время ожидания на каждом поисковом домене комбинацию перед переходом к следующему серверу. Если у вас настроено несколько доменов поиска и первый сервер в порядке поиска преобразователя не работает, это может вызвать значительные задержки в разрешении DNS для каждого отдельного запроса: более чем достаточно, чтобы вызвать проблемы в ваших критических приложениях.
Когда дело доходит до рекурсивного DNS, помните, что инфраструктура вашего сервера настолько устойчива, насколько надежна самая безумная конфигурация клиента. По мере роста вашей компании это то, что вы никогда иметь контроль над. Не делайте никаких проектных предположений, основанных на однородной среде серверной ОС, поскольку в растущей компании все редко остается прежним. Это обязательно кого-то укусит, если вы не планируете это заранее.
В наши дни вы можете использовать dnsdist от PowerDNS
Из README
dnsdist - это балансировщик нагрузки, хорошо распознающий DNS, DoS и злоупотребления. Его цель в жизни - направлять трафик на лучший сервер, обеспечивая максимальную производительность легитимным пользователям, одновременно перенаправляя или блокируя незаконный трафик.
dnsdist является динамическим в том смысле, что его конфигурация может быть изменена во время выполнения, а его статистика может быть запрошена из консольного интерфейса.
https://github.com/PowerDNS/pdns/tree/master/pdns/dnsdistdist
Они предоставляют репозитории для распространенных ОС: https://repo.powerdns.com/