По поводу разнесения нод на отдельных узлах — это было желание клиента. Сервис клиента в разных ДЦ, серверы также объединены по tinc, поэтому суть настройки не меняется.
Да, наверное, принципиальное преимущество в том, что зачастую роутер на Linux не только роутер. Он, как минимум, еще и DNS-сервер. То есть, выбирая решение на Linux, выбирают, в первую очередь, мультисервисность. Cisco, Juniper и т.д, конечно, тоже легко справляются с задачей, поставленной в статье.
Классно! Хорошие идеи часто рождаются одновременно у нескольких человек, и это прекрасно. Выкладывайте на GitHub, оформится как конечное решение в итоге.
Нужен всего один скрипт, в котором обрабатывается переключение с case по параметрам, как-то так:
case $1 in
operator1)
#тут пишем правила при переключении на оператора 1
;;
operator2)
#тут пишем правила для оператора 2
;;
*)
#тут выводим сообщение об ошибке или отправляем в мониторинг
esac
Скрипт нужно просто положить в /etc/netgwm/post-replace.d и он будет запускаться при каждой смене провайдера. В качестве параметров скрипту передаются:
$1 — new gateway identifier
$2 — new gateway IP or NaN
$3 — new gateway device or NaN
$4 — old gateway identifier or NaN
$5 — old gateway IP or NaN
$6 — old gateway device or NaN
По поводу Windows: при смене шлюза выполните conntrack -F на роутере. Если проблема в контраках, их сброс ее решит. Если же проблема в таймаутах на win-машине, то нет.
Коммутаторы в данной схеме позволяют включить не 2, а 3, 4 или 15 провайдеров и управлять ими с помощью netgwm. Если вопрос был про безопасность, то, конечно, Managment vlan не смотрит наружу.
По поводу локалки: мы используем схему коммутации, когда хосты из LAN коммутируются поровну в первый и второй коммутаторы и при выходе коммутатора из строя часть LAN оказывается без связи. Перекоммутацию выполняет администратор на месте руками.
conntrackd пробовали. Для себя увидели только один плюс — возможность репликации контраков между серверами, в наших текущих задачах обрыв соединений при переключении между роутерами не критичен.
В разных проектах разные роутеры, и количество ядер разное. Спасибо за совет по smp_affinity. По поводу физических карт: мы используем карты, поддерживающие несколько очередей.
Специально не замеряли производительность серверов. Единожды только уперлись в производительность роутера с процессором Atom, при этом на нем еще в userspace крутился VPN.
По поводу разнесения нод на отдельных узлах — это было желание клиента. Сервис клиента в разных ДЦ, серверы также объединены по tinc, поэтому суть настройки не меняется.
Обещанная статья по NetGWM https://habrahabr.ru/company/flant/blog/335030/
$1 — new gateway identifier
$2 — new gateway IP or NaN
$3 — new gateway device or NaN
$4 — old gateway identifier or NaN
$5 — old gateway IP or NaN
$6 — old gateway device or NaN
По поводу Windows: при смене шлюза выполните conntrack -F на роутере. Если проблема в контраках, их сброс ее решит. Если же проблема в таймаутах на win-машине, то нет.
По поводу локалки: мы используем схему коммутации, когда хосты из LAN коммутируются поровну в первый и второй коммутаторы и при выходе коммутатора из строя часть LAN оказывается без связи. Перекоммутацию выполняет администратор на месте руками.
В разных проектах разные роутеры, и количество ядер разное. Спасибо за совет по smp_affinity. По поводу физических карт: мы используем карты, поддерживающие несколько очередей.