Любые проблемы с наличием активного/активного HAProxy устанавливают с Keepalived

Если у Вас есть convienent окно поблизости, аппаратный ключ GPS может предоставить информацию времени в дополнение к местоположению.

6
задан 18 March 2014 в 12:09
2 ответа

Важные соображения, чтобы не иметь активную / активную настройку с двумя виртуальными IP-адресами для одного и того же ресурса,

  • как распределять запросы по двум виртуальным IP-адресам
  • как вы иметь дело с липкими сеансами, сходством, постоянством и т. д., т.е. что происходит, когда последующие запросы начинаются с виртуального IP1, а затем переходят на виртуальный IP2, и нужны ли они вам для работы с тем же внутренним сервером.
  • что происходит, когда виртуальные IP-адреса переключаются на другой хост?
3
ответ дан 3 December 2019 в 00:38

Обновление от 2020 г.: keepalived уже давно устарело, поскольку не работает в виртуальных облаках (AWS).

Немного истории

Давным-давно в офисе стоял интернет-маршрутизатор (Cisco). Маршрутизатор обеспечивал доступ в Интернет для всех машин, и это было хорошо.

...потом роутер умер и интернет у всех сломался и это отстой.

Оказывается, чтобы иметь избыточность, нужно два чего угодно. Поэтому Cisco начала предлагать пары маршрутизаторов, которые работают в тандеме.

Это делается с помощью протокола под названием HSRP, VRRP или CARP. HSRP — это оригинальный протокол, созданный Cisco для решения этой проблемы. Он был стандартизирован в VRRP позже https://tools.ietf.org/html/rfc3768 (1998 год), который был реализован большинством сетевых устройств и поставщиков. Люди из BSD заново изобрели свои собственные протоколы CARP, чтобы делать то же самое, они не могли принять VRRP из-за опасений по поводу лицензирования или патентов.

Keepalived (и uCARP) — это программное обеспечение, реализующее VRRP (и CARP). Его можно настроить на двух обычных серверах Linux, чтобы обеспечить переключение между ними.

Расцвет AWS и закат VRRP

Как работает 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, возможно, от другого клиента. Какого черта?!

Облачные решения и решения CDN

Поставщики облачных услуг предоставляют решения для балансировки нагрузки, см. балансировщики нагрузки AWS ELB и Google Cloud. Они поставляются со встроенной избыточностью для решения этой проблемы, поэтому вам не нужно об этом думать. keepalived просто устарел.

Следующий аспект — CDN (CloudFlare, Akamai). В настоящее время все общедоступные веб-сайты работают за CDN, который обеспечивает кэширование, фильтрацию и защиту от DDoS. CDN может обеспечить балансировку нагрузки между несколькими вышестоящими серверами.Просто настройте все отдельные серверы, и трафик будет разделен.

И последнее, но не менее важное. keepalived позволяет иметь только один активный сервер из многих, мягко говоря, он тратит ресурсы впустую. На самом деле это катастрофическая проблема в реальном мире, потому что вещи должны масштабироваться, а масштабирование невозможно по замыслу. Используемые сегодня решения для аварийного переключения, которые можно найти в облаках и CDN, предназначены для распределения трафика между несколькими активными пунктами назначения. Этого намного сложнее достичь, и он выполняется кумулятивно на разных уровнях (см. DNS, Anycast, OSPF, BGP). keepalived больше не является частью общей картины.

-1
ответ дан 26 April 2020 в 23:35

Теги

Похожие вопросы