Comments 14
И сразу же первый вопрос: а что будет, если по какой-то причине упадёт haproxy на одной из площадок?
Анонс ведь не снимется и трафик части пользователей будет улетать "в никуда".
Самое простое, можете воспользоваться подобным решением:
cat << EOF > /usr/local/bin/bird-haproxy-check.sh
#!/bin/bash
if ! systemctl is-active --quiet haproxy; then
birdc disable bgp
else
birdc enable bgp
fi
EOF
cat << EOF > /etc/systemd/system/bird-haproxy-check.service
[Unit]
Description=Monitor HAProxy
[Service]
ExecStart=/usr/local/bin/bird-haproxy-check.sh
EOF
cat << EOF > /etc/systemd/system/bird-haproxy-check.timer
[Unit]
Description=Run
[Timer]
OnBootSec=1min
OnUnitActiveSec=1min
[Install]
WantedBy=timers.target
EOF
systemctl daemon-reload
systemctl enable bird-haproxy-check.timer
systemctl start bird-haproxy-check.timerЛибо настроить как-то через алерты. Мне может быть везет, но я еще не разу не видел падение службы haproxy (тьфу-тьфу-тьфу))
Причин падения может быть масса, включая приход доброго OOM.
Но вообще уже лучше, теперь схема стала более отказоустойчивой.
Закину тогда ещё 2 вопроса:
Арбитр оставлен за скобками, но это очень важно в вашей схеме. Как реализуется его связь с управляемыми хостами? Какие-то выделенные радио-линки (пусть даже GSM модемы)? Если арбитр подключен через те же каналы и упадёт один из каналов, то он не сможет ничего сделать.
Судя по схеме, у вас подключение active-active? То есть трафик одновременно обрабатывается обоими приложениями и на схеме есть БД. Она работает в режиме синхронной репликации с двумя мастерами? Что с ней будет при потере связанности между ЦОД'ами, но при сохранении работоспособности каждого из ЦОД'ов и при наличии живых клиентов в каждом из ЦОД'ов?
Оба узла app идут вместе с +bd доступны для подключения. Отдельная база данных не предусмотрена (так было сделано). Арбитр необходим, когда возвращается нода, чтобы указать, кто из них является главным.
Трафик клиентов попадает одновременно на оба узла, так?
Клиент рядом с DC1 попадёт на балансер 1, там мастер app1.
Клиент рядом с DC2 попадёт на балансер 2, там масте app2.
Если приложение statefull, то могут быть разные нюансы - как разрешаете конфликты? Два юзера отредактировали одну таблицу - вот уже конфликт, который нужно разрешать. Или базы как-то синкаются между собой внутри?
Зачем весь этот огород.... Vxlan + keepalived, который может еще и делать проверку состояния необходимых сервисов
Не совсем ясно, как Вы хотите 1 и тот же vip адрес раздать на 2 разные l3 сети, с балансировкой, масштабируемостью применяя vxlan + keepalived. Расскажите нам, пожалуйста, поподробнее.
VXLan же ;))))
Делаем общий L2 домен для хостов и вуаля.
Решение спорное с технической точки зрения, но и исходное решение не учитывает важных нюансов (или учитывает, но они остались за скобками) и надёжность с vXLan будет не сказать, чтобы ниже.
нет нет, Вы меня не услышали, я ничего не имею против vxlan и особенными головными болями с ним(усложнение конфигурации, борьба с мту, и тд тд тд),когда у тебя левая часть схемы неуправляемая.. Если я не прав, дайте, пожалуйста, почитать, как это сделать. Нам интересно.
Где здесь балансировка с keepalived, вот суть вопроса. =)
ожно добавить через нет план и ненадо городить службы вот пример для настройки
network:
renderer: networkd
version: 2
dummy-devices:
dm0:
addresses:
- 172.19.12.1/32
BGP-anycast