Приносим извинения, если об этом спрашивали раньше, но я, кажется, не могу найти в нем много информации.
Мы собираемся использовать HAProxy для балансировки нагрузки нашего кластера MariaDB Galera. Все статьи / руководства, которые я видел по этому поводу, используют Keepalived (или что-то подобное) для активной / пассивной настройки HAProxy.
Есть ли веская причина, по которой у вас не должно быть активной / активной настройки?
Каждый узел HAProxy может иметь фиксированный IP-адрес, и оба имеют плавающий IP-адрес. В нормальных условиях запросы распределяются между двумя узлами HAProxy, если один из них выходит из строя, другой принимает плавающий IP-адрес и обрабатывает запросы с обоих IP-адресов. Когда другой возвращается, он снова берет свой плавающий IP-адрес и часть нагрузки.
Буду признателен за ваше мнение по этому поводу.
Люк
Важные соображения, чтобы не иметь активную / активную настройку с двумя виртуальными IP-адресами для одного и того же ресурса:
Обновление на 2020 год: keepalived давно устарел, потому что не работает в виртуальных облаках (AWS).
Давным-давно в офисе был интернет-маршрутизатор (Cisco). Маршрутизатор обеспечивал доступ в Интернет ко всем машинам, и это было хорошо.
... потом умер роутер и у всех сломался интернет, и это отстой.
Оказывается, чтобы иметь избыточность, нужны две штуки. Поэтому Cisco начала предлагать пары маршрутизаторов, работающих в тандеме.
Это делается с помощью протокола, называемого HSRP, VRRP или Карп. HSRP - это оригинальный протокол, созданный cisco для решения проблемы. Он был стандартизирован в VRRP потом https://tools.ietf.org/html/rfc3768 (1998 год), который внедрен большинством сетевых устройств и поставщиков. Люди из BSD заново изобрели свои собственные протоколы Карп чтобы сделать то же самое, они не смогли принять VRRP из-за опасений по поводу лицензирования или патентов.
Keepalived (и uCARP) - это программное обеспечение, реализующее VRRP (и CARP). Его можно настроить на двух обычных серверах Linux для переключения между ними.
Как работает VRRP? Для начала ему нужен плавающий IP-адрес, скажем 192.168.1.254, только один маршрутизатор владеет IP-адресом в любой момент времени. Устройства в сети просто отправляют трафик на этот (плавающий) IP-адрес и достигают активного маршрутизатора, они не знают, что он плавающий, и им все равно. Оба маршрутизатора постоянно общаются друг с другом, и если один из них умирает, другой маршрутизатор берет на себя IP и начинает обработку трафика.
На этом этапе необходимо знать сетевые уровни 2 и 3 OSI (MAC и IP). Сетевые устройства взаимодействуют с MAC и IP адреса, адреса разрешаются с помощью ARP.
Концепция захвата плавающего IP-адреса включает в себя ряд махинаций в сетевом стеке (все аббревиатуры, приведенные выше), это не совсем спроектированное или ожидаемое поведение.
В физической сети несколько компьютеров, физически подключенных к одному коммутатору Ethernet, обычно работает.
На виртуальной машине это обычно не работает. Виртуальная сеть должна обрабатывать сетевой трафик (уровни MAC и IP), обычно она блокирует волшебные пакеты или изолирует виртуальный хост, предотвращая работу VRRP.
Об основных виртуальных облаках (AWS, Google и др.). Это точно не работает, и это сделано специально. Представьте, что экземпляр AWS может взять на себя IP - весь трафик - от другого экземпляра Linux, возможно, от другого клиента. Какого черта?!
Облачные провайдеры предоставляют решения для балансировки нагрузки, см. AWS ELB и Google Cloud load balancers. Они имеют встроенную избыточность для решения этой проблемы, поэтому вам не нужно об этом думать. Keepalived просто устарел.
Следующий аспект - это CDN (CloudFlare, Akamai). В настоящее время все общедоступные веб-сайты работают через сеть CDN, которая обеспечивает кеширование, фильтрацию и защиту от DDoS-атак. CDN может обеспечивать балансировку нагрузки между несколькими вышестоящими серверами. Просто настройте все отдельные серверы, и трафик разделится.
Последний, но тем не менее важный. keepalived позволяет иметь только один активный сервер из многих, это тратит ресурсы, мягко говоря. На самом деле это катастрофическая проблема в реальном мире, потому что вещи должны масштабироваться, а они не могут масштабироваться по дизайну. Решения аварийного переключения, используемые сегодня в облаках и CDN, предназначены для распределения трафика между несколькими активными пунктами назначения. Достичь этого намного сложнее, и это делается кумулятивно на разных уровнях (см. DNS, Anycast, OSPF, BGP). Keepalived больше не является частью общей картины.