Меня попросили восстановить нашу инфраструктуру балансировки нагрузки в центре обработки данных.
Первоначальный запрос был для балансировки нагрузки FTP-серверов. Я попытался сделать это, используя текущий балансировщик нагрузки ( Piranha / LVS), но не запустил его. Не только потому, что для этого программного обеспечения практически нет документации. Поскольку Piranhaэто считается устаревшим, я перешел к нему HAProxyпосле нескольких дней попыток, которые проделали работу за небольшую часть времени Piranha.
Итак, у меня есть балансировка нагрузки FTP (пассивный режим). Теперь меня попросили заменить весь балансировщик нагрузки Piranha в центре обработки данных. В текущей конфигурации Piranha у нас есть несколько веб-серверов, IIS-серверов .... aaa и DNS .
Нет, вот в чем дело:
HAProxyкажется, что это широко используемый LB, но он не способен справитьсяUDP load balancing . Это облом, так как мне нравится, как HAProxyработает. Поэтому я много гуглил и наткнулся на несколько вещей. Кажется, что большинство людей используют LVSв качестве LB для DNS (TCP / UDP). Некоторые используют dlbDNS, некоторые используют lbnamed, а некоторые используют netfilter / iptables.
Так как я хотел бы придерживаться HAProxyFTP, 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, помните, что ваша серверная инфраструктура столь же устойчива, как и самая «умная» конфигурация клиента. Поскольку ваша компания растет, это то, что вы никогда не можете контролировать. Не делайте предположений о дизайне, основываясь на однородной среде серверных ОС, так как в растущей компании ситуация редко остается прежней. Это определенно укусит кого-то, если вы не планируете это заранее.
источник
В эти дни вы можете использовать
dnsdistPowerDNSОт README
https://github.com/PowerDNS/pdns/tree/master/pdns/dnsdistdist
Они предоставляют репозитории для распространенных ОС: https://repo.powerdns.com/
источник