DNS и стратегии отказоустойчивости для балансировщиков нагрузки
Я пытаюсь узнать, как создать высокодоступный служба балансировки нагрузки для серверов приложений, например HTTP-трафик и как они работают с DNS-серверами.
Рассмотрим следующую диаграмму. Я понимаю, что балансировщики нагрузки (например, HAProxy) могут быть настроены для назначения основного сервера и стратегии отката на вторичный (который становится новым первичным), если первичный сервер выходит из строя.
- Разве для этого не требуется, чтобы DNS-сервер знать из или избрать первичный сервер LB?
- Иногда это не DNS-серверы вне центра обработки данных (или вне прямого контроля) компании или организации, которые сами управляют балансировщиками нагрузки? Если да, то как они указывают на DNS-серверах, на какой LB-сервер попасть?
Вы определили проблему создания избыточных внутренних серверов для балансировщика нагрузки (или обратного прокси) только для того, чтобы обнаружить, что сам балансировщик нагрузки становится единственной точкой отказа.
Обычно это решается за счет того, что два или более блока балансировки нагрузки имеют общий IP-адрес, также известный как плавающий IP-адрес, тем самым создавая кластер балансировки нагрузки.
Запись DNS будет указывать только этот плавающий IP-адрес и позволит кластеру балансировки нагрузки определить, какой блок балансировки нагрузки получает какой входящий запрос. Поэтому DNS-серверы обычно не требуют знания основных и резервных членов в группе балансировщика нагрузки.
Существуют различные реализации, делающие возможными как активные / пассивные конструкции, в которых только один узел кластера доступен через плавающий IP-адрес в любой момент времени, так и активные / активные конструкции, в которых все блоки кластера доступны через плавающий IP-адрес одновременно.
Существует множество кластерных протоколов и приложений, см., Например, vrrp, hsrp, glbp. Зная терминологию, найти больше альтернатив - тривиальная задача.
haproxy можно развернуть несколькими способами для достижения кластерной функциональности, и решения легко найти, см., например, Вот, и Вот.
Есть и другие подходы. См. Например Балансировка нагрузки DNS с циклическим перебором и Маршрутизация геолокации DNS.
Да, это правда, что служба DNS может размещаться за пределами организации, в которой размещается балансировщик нагрузки. Обычно это влияет только на время выполнения изменений, но не на саму функциональность кластера балансировщика нагрузки (предостережение: специализированные решения).