От Neutron к Sprut: о предпосылках разработки собственной SDN и полученных результатах

Любая облачная платформа рано или поздно перерастает изначальные решения. Наш случай с SDN Neutron — тому пример: при всех преимуществах, его архитектура стала барьером для развития. В результате, чтобы более полно реализовывать потенциал роста VK Cloud, нам потребовалось задуматься о смене стека.

Рассказываем о нашем опыте использования SDN Neutron, недостатках инструмента в контексте нашего проекта и разработке собственного решения.

Немного о SDN

SDN (Software Defined Network, программно-определяемая сеть) — инструмент управления overlay-сетями (виртуальная сеть поверх физической) и основа облачной инфраструктуры.

Использование SDN позволяет быстро изменять конфигурацию и мигрировать ресурсы внутри инфраструктуры, что является обязательным условием организации распределенной инфраструктуры на 1000 и более серверов.

В зависимости от задачи, SDN можно применять в разных сценариях, среди которых:

• организация сетевой связности внутри проекта;
• использование виртуальных маршрутизаторов, сетей и подсетей:
• организация доступа в интернет и подключение к проекту из внешних сетей;
• управление IP-адресами в проекте;
• настройка правил маршрутизации.

При этом SDN — основа любой облачной инфраструктуры, и неотъемлемый компонент любой облачной платформы, в том числе и VK Cloud.

Первый SDN и его специфика

Изначально облако VK Cloud разрабатывалось на базе OpenStack и частично использовало инструменты стека. Таким образом, в качестве первого SDN был выбран полностью интегрированный с платформой Openstack Neutron.

По умолчанию в SDN Neutron доступно много вариантов организации сети (vLan, Overlay, Flat) и большой пул сетевых сервисов, в том числе:

• виртуальные маршрутизаторы;
• балансировщики нагрузки;
• VPN;
• DNS;
• группы безопасности.

На уровне архитектуры Neutron сочетает несколько компонентов:

• Neutron API, который принимает входящие пользовательские запросы;
• плагин ML2, который реализует всю базовую логику работы Neutron;
• базы данных;
• RabbitMQ на слое transport;
• агенты, занимающиеся настройкой Data plane;

Data plane, в качестве которых могут быть OVS, NetNS, Daemons и другие.

Алгоритм работы Neutron довольно простой:

• Для создания виртуальной сети пользователь делает запрос в Neutron API.
• Neutron API передает запрос в плагин ML2.
• Плагин ML2 рассылает уведомления о создании сети всем агентам через RabbitMQ.
• После создания сети, агенты (например, Open vSwitch Agent) узнают о ней при создании порта на конкретном compute-узле. Только в этом случае агент на данном узле настраивает необходимые элементы Data Plane (бриджи, VLAN/VXLAN-теги и т.д.). Остальные агенты не выполняют действий, если порт не относится к их хосту.

Алгоритм отлаженный и до определенного момента Neutron нас устраивал. Но были у него и ограничения, которые по мере роста нагрузки стали для нас критическими.

• Агенты не хранят состояния (stateless) и нет обратной связи об их настройках. Это создает сложности, поскольку агент может пропустить часть событий из-за временного отключения, перегрузки или вся нода была отключена, на которой он расположен. Отчасти проблема решается с помощью механизма для полной синхронизации Full Sync. Но и здесь есть свои издержки: при большом количестве сущностей подобная синхронизация может занимать несколько часов.
• Data plane излишне усложнен. Ядром Data plane в Neutron является OVS, который отвечает за связь виртуальных машин и подключение сетевых функций: DHCP, DNS, Metadata Proxy и других. За настройку OVS отвечает OVS Agent. По сути, логика всей сети находится внутри OVS и OVS Agent. Это значительно усложняет мониторинг — в десятках тысяч правил легко потеряться.
• Event-based-общение через RabbitMQ. Агенты взаимодействуют с сервером через события. Однако в коде сервисов иногда возникают ошибки. Из-за этого агенты могут пропускать события, а RabbitMQ — терять их во время доставки из-за Race conditions. К тому же RabbitMQ в такой конфигурации становится «бутылочным горлышком»: если в нем случится сбой, весь SDN будет недоступен.
• Больше функциональности — больше событий. Neutron позволяет использовать много функций и настроек. Нюанс лишь в том, что их активация значительно повышает поток событий и, как результат, снижает производительность решения. Так, если в простой конфигурации Plane-сеть он может работать на тысяче гипервизоров, то при включении оверлейных сетей с механизмом распределенной маршрутизации с проблемами можно столкнуться уже после запуска сотни гипервизоров.

В результате мы приняли решение о необходимости смены SDN.

Варианты SDN и требования к инструменту

При поиске нового SDN мы исходили из того, что искомое решение должно удовлетворять некоторым критериям.

• Поддержка существующего набора сетевых функций. Множество полезных для пользователей опций уже реализовано, и мы не хотели их терять. Соответственно, новое решение должно быть таким же функциональным.
• Сеть DC вида «L3 на стойку (ToR)». В наших дата-центрах сети организованы по принципу «L3 на стойку». Поэтому важно, чтобы новый SDN мог работать в подобной конфигурации.
• Масштабирование. Объем запросов к серверам и сервисам VK Cloud постоянно растет, поэтому нам важно иметь возможность быстрого и гибкого масштабирования.
• Бесшовная миграция с текущей SDN. Переезд на новую SDN не должен повлиять на работу пользователей и функциональность.
• Возможность и потенциал доработки. Было важно, чтобы инструмент можно было адаптировать к текущим задачам и дорабатывать по мере необходимости. Исходя из этого, у нас было три варианта:
• переработать существующую SDN Neutron;
• заменить существующую SDN, например, на Tungsten Fabric/Open Contrail, OVN;
• разработать собственную SDN.

При этом переработка SDN Neutron — слишком трудоемкая задача, поскольку у решения 250 тысяч строк кодовой базы, в которой надо основательно разобраться. К тому же доработка не гарантирует, что нам удастся избавиться от всех недостатков Neutron.

Вариант с переходом на существующие решения, например, на Tungsten Fabric, тоже имеет свои нюансы. Так, у большинства инструментов нет всей нужной функциональности «из коробки». Соответственно, уже на первых этапах нужны доработки. Это усложняет внедрение, эксплуатацию и поддержку.

Разработка своего SDN — очевидно, самый сложный вариант, который требует от команды экспертизы в Control plane и Data plane, а также знания всех нюансов работы сетей. Но есть и преимущества. Например, можно выстроить любую архитектуру и предусмотреть нужные механизмы миграции. Именно поэтому мы решили написать собственную SDN.

Собственная SDN Sprut

На разработку новой SDN, которую мы назвали Sprut, ушло меньше года. В результате мы получили собственный инструмент, для которого обеспечили полную совместимость с OpenStack Neutron API для упрощения миграции и сохранения имеющегося у нас функционала.

Одновременно с этим, на уровне архитектуры мы смогли уйти от всех недостатков, характерных SDN Neutron.

• Ушли от Event-based общения между компонентами SDN. Агенты теперь регулярно получают от сервера целевое состояние, к которому должны стремиться, и постоянно обновляют его. Это напоминает режим постоянного Full Sync, где агенты сравнивают текущее состояние Data plane с целевым и вносят необходимые изменения, чтобы привести систему в актуальное состояние.
• Убрали брокер сообщений RabbitMQ. HTTP REST API заменил RabbitMQ. Это решение оказалось более эффективным для работы с обширными массивами данных о целевых состояниях агентов. Оно также отличается простотой в разработке и мониторинге.
• Оптимизировали архитектуру DataPlane. Чтобы нивелировать имеющиеся сложности, мы разделили SDN на три сущности: NFV, SDN и APP. Теперь NFV (Network Function Virtualization) отвечает за предоставление сетевых сущностей, SDN — за их связь между собой, а APP — обеспечивает совместимость уровней по API. После внесения изменений в архитектуре появилось два независимых уровня, каждый со своими агентами, контроллерами, базами данных и API.

При выстраивании архитектуры с нуля мы также учли несколько важных аспектов.

• Реализована микросервисная архитектура. Каждый сервис отвечает за свою функциональность и может быть развернут независимо от других.
• Замкнутый контур управления позволяет системе автоматически подстраиваться для надежной работы облачной платформы.
• Архитектура готова к горизонтальному масштабированию инсталляции.
• Предусмотрены механизмы Self-healing сетевых NFV-сущностей сервисов клиентов.

Одновременно с этим, SDN Sprut получила и широкие функциональные возможности, среди которых:

• механизмы интеграции REST API и другие;
• Direct Connect для организации выделенных каналов с инфраструктурой;
• продвинутый маршрутизатор для построения отказоустойчивой схемы с поддержкой BGP;
• возможность изолирования клиентского трафика для PaaS-сервисов;
• возможность создания общих сетей для объединения нескольких проектов в облаке;
• механизмы самовосстановления сетевых компонентов;
• автомониторинг для проверки, валидации и оптимизации инфраструктуры;
• поддержка событийно-ориентированной архитектуры.

Полученные результаты и выводы

Сейчас для нас Sprut — основная SDN для всех новых проектов. И это обусловлено не только тем, что мы смогли устранить недостатки Neutron, но и тем, что при значительно меньшем объеме кодовой базы (15 тысяч строк в Sprut против 250 тысяч строк в Neutron), мы получили существенно улучшенную производительность в наиболее востребованных сценариях.

Но мы не останавливаемся на достигнутом и продолжаем непрерывно совершенствовать продукт, чтобы сделать его еще универсальнее и функциональнее.