А можно какую-либо ссылку на описание внедрения с pros and cons bgp/ospf в связке с haproxy? Просто слабо представляю себе для чего это делается.

Ну там было про то что божественная ExaBGP умеет проверки сервисов с помощью скриптов и если проверка не прошла, то перестает анонсировать заданный префикс. А чтоб такое сделать с OSPF Типа придется FRR\Bird держать и внешние скрипты. Как-то так что ли.

Именно оно ! 👍

А можно какую-либо ссылку на описание внедрения с pros and cons bgp/ospf в связке с haproxy? Просто слабо представляю себе для чего это делается.

В общем, суть в чем, если у тебя несколько балансировщиков нагрузки, то keepalived (по сути VRRP) будет держать виртуальный адрес активным только на одном балансировщике одновременно. Соответсно, при падении виртуальный адрес переедет на другой сервер. Тут вижу такие проблемы: - VRRP довольно такой себе протокол, с ним бывают проблемы из-за мультикастов, например. - Балансировщиков несколько, а в каждый момент времени работает только один - Виртуальный адрес эт дополнительная путаница. Потому что держать на каждом хосте надо два адреса - адрес из той ж сети что vip и сам виртуальный адрес. - Требует L2 связность между участвующими в VRRP группе серверами С динамической маршрутизацией завязанной на доступность севиса получается так: Сервис на хосте активен - значит анонсируем /32 Префикс. Пропал - протокол маршрутизации шлет обновление и оно быстро расходится, этот хост исключается из доступных. Если маршруты все с одинаковой метрикой, то будет работать ECMP, там где есть его поддержка. То есть, трафик худо-бедно будет раскидываться между серверами. А если сюда прикрутить Traffic Engineering, то получится и возможность управлять и тем как именно трафик идет к целевому серверу и пропускной способностью зарезервированной для разных TE туннелей. Как-то так вижу) Не знаю, делает ли кто-то такое и надо ли оно. Но возможность эту вижу.

api сервисы через haproxy + keepalived, но хочется перейти на несколько активных haproxy + BGP или OSPF. OSPF тут ругали, но, между тем, с ним можно навернуть еще и Traffic Engineering.

В общем, суть в чем, если у тебя несколько балансировщиков нагрузки, то keepalived (по сути VRRP) будет держать виртуальный адрес активным только на одном балансировщике одновременно. Соответсно, при падении виртуальный адрес переедет на другой сервер. Тут вижу такие проблемы: - VRRP довольно такой себе протокол, с ним бывают проблемы из-за мультикастов, например. - Балансировщиков несколько, а в каждый момент времени работает только один - Виртуальный адрес эт дополнительная путаница. Потому что держать на каждом хосте надо два адреса - адрес из той ж сети что vip и сам виртуальный адрес. - Требует L2 связность между участвующими в VRRP группе серверами С динамической маршрутизацией завязанной на доступность севиса получается так: Сервис на хосте активен - значит анонсируем /32 Префикс. Пропал - протокол маршрутизации шлет обновление и оно быстро расходится, этот хост исключается из доступных. Если маршруты все с одинаковой метрикой, то будет работать ECMP, там где есть его поддержка. То есть, трафик худо-бедно будет раскидываться между серверами. А если сюда прикрутить Traffic Engineering, то получится и возможность управлять и тем как именно трафик идет к целевому серверу и пропускной способностью зарезервированной для разных TE туннелей. Как-то так вижу) Не знаю, делает ли кто-то такое и надо ли оно. Но возможность эту вижу.

А сколько нод в контрол кластере?

Сколько душа просит. Все сервисы сами по себе stateless же (уж хз как по-русски). Кластер БД держать стоит в нечетном количестве экземпляров, то есть, 1-3-5-7.

С bfd нормально работает , но нужно ВСЕ переводить на l3 чтобы быдо счастье

А если drbd по старинке, то можно и на двух нодах сойтись

Ну я в нем не шарю. Вот у нас два сервера c drbd, как им решать кто из них гланый если связь между ними нарушится?

Ну неужели у всех по 3 ноды на control ?

А как определить какой сервер бд является основным, не рекомендуется же писать сразу на нескольких серверах? Какой нибудь mysql proxy или можно задать политику - данный сервис пускать на единственный живой сервер, остальные использовать при падении?

По три ноды не надо. Речь о базе данных. Для неё кворум нужен. А остальные сервисы - это WSGI.

Ок, даже для базы. Нужно 2 ноды + кворумная VM без диска?

Для базы надо три базы)

Я понимаю Как это на 2х хостах сделать ?

А чо с ним?

Как его на 2 ноды разнести Ну там вроде обычный mirror

а кто ругал OSPF ? BGP лучше тем что оно уже есть в нейтроне) не нужно кастылить

Подскажите что лучше использовать Neutron DVR или Neutron L3 HA

нет

лучше не использовать ни то, ни другое

dvr усложняет архитектуру и увеличивает расход белых адресов, HA в L3 агенте есть и так правда переключение пара минут вместо секунды

dvr усложняет архитектуру и увеличивает расход белых адресов, HA в L3 агенте есть и так правда переключение пара минут вместо секунды

А ничего что весь трафик через туннели идёт к нетворкам, которые ещё и отказоустойчивость уменьшают

если у вас деплой в 5 нод - dvr лучше чем +2 нетворк ноды если у вас деплой в 50+ нод - нетворк ноды сильно облегчают жизнь

а с dvr, подскажите, оно весь трафик локально гоняет ? или флоатинги через нетноды идут ?

External сеть начинается прямо на физическом интерфейсе гипервизора, получается что внешний трафик идет прямо на гипервизор, минуя лишние прослойки. Тенантный трафик по vxlan

А если в вашей схеме LBaaS включить, получится вообще красота - там же как обычно рандомом все ? )