После перехода с VMware NSX на opensource SDN OVN, о котором я рассказывал на HL++ 2024, мы смогли вздохнуть полной грудью, получив прирост в производительности, быстродействии сети и, наконец, начали "владеть" продуктом, избавившись от вендорской закрытости. OVN, как и его предшественник NSX предоставлял в облачной сети L2-изоляцию между подсетями, firewall на портах ВМ, DHCP и возможность подключения внешних инфраструктур клиентов через HW VTEP (L2 Gateway).

В то же время остальные сетевые сервисы — DNS, межсетевой firewall, VPNaaS и маршрутизация VPC и зонами доступности — продолжали функционировать в LXC-контейнерах на выделенных сетевых нодах с использованием стандартных Linux-инструментов. Такое решение было простым и понятным, но имело свои ограничения.

Поэтому мы видели улучшение облачных сетей уже на базе более продвинутых фич OVN, которые должны были решить оставшиеся проблемы:

- Сетевая нода с LXC и veth-интерфейсами становилась узким местом с точки зрения производительности, особенно при росте нагрузки одного VPC
- Использование conntrack для NAT добавляло нагрузки, что влияло на эффективность обработки внешнего трафика
- Несмотря на компактность LXC, сосредоточение всех сетевых функций VPC в одном контейнере снижало гибкость при построении распределённых архитектур

В докладе я расскажу, как мы выстроили новую архитектуру сетевых сервисов в К2 Облаке, чтобы решить эти задачи, повысить масштабируемость и отказоустойчивость, и какой ценой смогли этого достичь.