После перехода с VMware NSX на open source 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 Облаке, чтобы решить эти задачи, повысить масштабируемость и отказоустойчивость, и какой ценой смогли этого достичь.