Комментарии 6
Нашу доработку мы уже залили в апстрим и сейчас договариваемся с опенсорс‑сообществом о внедрении.
Тем временем мейнтейнер выкинул эти доработки и сделал совершенно другое решение.
Привет 🙂
После оригинального PR-а - https://github.com/osrg/gobgp/pull/2869 владелец репозитория действительно решил сделать альтернативное решение, которое лечит OOM'ы. Однако там осталась ещё часть с тем, что fsm будет залочен и это может привести к разрыву bgp-пиринга.
У нас в планах прийти в upstream со второй итерацией, помержив фикс с текущим мастером.
По облачным решениям вроде и народу много работает и зарплаты высокие, а скорости все равно деградируют каждый год. Сервера на горы и озера меняют?
Константин, спасибо за рассказ.
Можете подробнее рассказать про устройство side-by-side обновления ядерной части vrouter? Как загружается новая версия примерно понятно, как прогревантся - тоже. А как в нее переключается реальный датапас, порты виртуалок? Нужно ли для этого как-то отключать tap-интерфейсы и перецеплять их к новому ядерному модулю?
Мы приносим на хост новую версию модуля и новый vrouter-agent в контейнере, далее дожидаемся пока не установится сессия с cpl и скачается конфиг. Потом производим переключение портов по одному с механикой двухэтапного включения:
Новый vrouter получает сигнал, что скоро в него подключат новый порт
Новый vrouter прогревает весь конфигурационный и маршрутный кэш для этого порта
Выключаем порт из старого vrouter, это также снимает анонс со старым nexthop
Включаем порт в новый vrouter на боевую, это проращивает анонс с новым nexthop
То есть да, переходный период все еще есть, но в целом он укладывается в субсекундное время и в любой момент можно откатиться обратно на старую версию
Что мы изменили в сети, чтобы сделать её устойчивее