Виртуальные сети, VLAN-ы, трафик север-юг/запад-восток, оверлей, L2 поверх L3 — и кто только придумал всю эту конструкцию? Думаю, такие мысли знакомы многим админам и инженерам. 

Всё становится проще с SDN (Software-Defined Networking). Меня зовут Михаил Фучко, я архитектор SDN в команде zVirt. В этом посте я расскажу, зачем и как мы в Orion soft разрабатывали и интегрировали SDN в нашу систему виртуализации.

Обсудим:

• Какие требования есть у компаний к SDN в продукте;

• Почему выбрали OVN/OVS;

• С какими проблемами столкнулись при интеграции с oVirt и какие решения нашли, чтобы их устранить.

SDN — механизм, а не политика

Мы в Orion soft уже шесть лет развиваем свое решение — систему виртуализации zVirt. Она опирается на Open Source проект oVirt на базе гипервизора KVM с использованием библиотеки libvirt. 

Наши заказчики долгое время работали с VMware NSX и привыкли к определенному уровню удобства и функциональности. Поэтому создание SDN-решения стало для нас необходимостью. При этом инфраструктура у каждого заказчика имеет свои особенности. Так что мы решили действовать по принципу «механизм, а не политика»: обеспечить многообразие возможностей, не навязывая конкретный сценарий применения. 

Второй принцип — масштабируемость. Чаще всего применение SDN становится актуально по достижении объемов инфраструктуры примерно в 10-16 хостов. Тем не менее сами возможности управления трафиком могут быть полезны и на 3-4 хостах. На маленьких инсталляциях некоторые преимущества SDN могут даже проявиться ярче. Например, возможность создавать внутренние виртуальные сетевые инфраструктуры под конкретную задачу обеспечит большую автономность для инженера виртуализации при проектировании среды. Поэтому SDN-решение должно одинаково хорошо работать на инсталляциях разного размера. 

Третий принцип — простота миграции. Когда люди покупают zVirt, им первую очередь нужна виртуализация, которая решает старые проблемы и не плодит новые. С этой точки зрения в продуктовом SDN важнее всего легкость внедрения и отладки. Это не то решение, которое «строят» несколько месяцев или лет. От продуктового SDN ждут возможности установки по нескольким кликам в веб-интерфейсе. 

Почему OVN/OVS

Как подступиться к реализации программно-определяемой сети в системе виртуализации? Внимательный читатель сразу скажет: «Ребята, вы же взяли за основу oVirt, там уже есть поддержка оверлейных сетей и интеграция с OVN/OVS». 

Действительно, oVirt подсказала нам направление работы: zVirt SDN построен на базе OVN (Open Virtual Network) и OVS (Open vSwitch). Для нас большую роль играет time-to-market, поэтому мы решили воспользоваться возможностью не  создавать все «с нуля».

Но были и другие не менее значимые аргументы в пользу OVN/OVS:

Надежность и развитие. OVN/OVS — проверенное решение. Его используют на многих OpenStack-инсталляциях, в том числе крупных. Есть международное комьюнити, которое регулярно дорабатывает решение и формирует задатки новых нужных фичей.

Архитектура. OVN—– самодостаточное решение. Его не нужно интегрировать с чем-либо, кроме портов виртуальных машин. Есть несколько точек ввода данных, а дальше OVN мало что нужно от окружения. С точки зрения продукта это плюс: меньше потенциально ломающихся частей, меньше потенциальных нестыковок в интеграции. 

Люди. В России тоже сформировалось OVN-комьюнити с опытом работы в инфраструктуре облака. Это дает возможность кооперироваться, быстрее получать ответы на насущные вопросы.

Что досталось в «наследство» от oVirt

Реализация SDN в oVirt имеет серьезные проблемы с надежностью и архитектурой: потеря ВМ присвоенного ей статического адреса при перезапуске, невозможность установить хост в кластер типа OVS, невозможность применить конфигурацию nmstate при определенном наборе сетей с VLAN. Эти проблемы долгое время сохранялись в коде oVirt, и нам нужно было их устранять. 

Архитектурное «наследство» тоже вызывало вопросы. Если изучить дизайн-документы oVirt, можно увидеть, как интегрировались многие компоненты SDN-решения. Например, поддержка групп безопасности: механизм реализовали, API взяли от OpenStack, и он работал. В качестве интерфейса предлагалось использовать Ansible-плейбуки от другого проекта, сохранение конфигурации никто не отрабатывал. Кажется, что разработчики выполняли части большого плана, но с очень скромным набором ресурсов. 

В oVirt были выполнены многие важные аспекты интеграции с OVN. Был введен отдельный тип кластеров, обеспечено подключение ВМ к OVS, oVirt может создавать и обновлять логические порты ВМ. Но получить из этого целостный продукт методом доработки существующих решений не удалось. Потому мы решили воспользоваться «наследством», насколько это возможно, но не следовать изначальным архитектурным принципам. Наш SDN разрабатывается как дополнительный сервис, а не проходит через материнский код Engine oVirt.

Как устроен SDN в zVirt

Анализируя реализацию SDN в oVirt, мы пришли к собственному пониманию решения с теми ограничениями, которые диктует выбранная нами стратегия разработки. В этой статье мы посмотрим на наш SDN с точки зрения общей структуры продукта. Более подробное погружение в технические компоненты решения — в следующих статьях. 

Мы используем фреймворк на базе OVN/OVS, но с некоторыми важными модификациями. Хотя мы опираемся на примитивы из этих технологий, мы существенно преобразовали их в соответствии с нашими нуждами. 

Все возможности нашего SDN доступны через публичный поддерживаемый API, который используется в том числе нашим пользовательским интерфейсом. Таким образом мы предлагаем полный паритет функциональности графического интерфейса и средств автоматизации. API поддерживает поиск, операции follow, пагинацию.

Еще одна особенность нашего SDN — отсутствие собственной базы данных. Мы работаем исключительно с параметрами OVN, что значительно упрощает процесс обновления. Но наш подход к управлению объектами отличается от стандартного. Некоторые объекты, которые в OVN являются однородными, мы разделяем и управляем ими по-разному, реализуя собственную логику. Итоговую желаемую картину сети хранит в себе Northbound-база, «северная» база данных. Специальный контроллер OVN обеспечивает чтение данных из «северной» базы и формирование «южной» — той, на связь с которой будут выходить контроллеры на хостах виртуализации. 

В основе работы хоста с поддержкой SDN лежит Open vSwitch как программируемый коммутатор. Он способен принимать трафик со всех ВМ, обрабатывать его согласно набору flow-правил и принимать решения о маршрутизации.  Его программированием на основе содержимого «южной» базы данных занимается специальная служба ovn-controller. Связь между хостами виртуализации реализуется с применением GENEVE-туннелей, которые настраиваются автоматически. 

Для интеграции SDN с zVirt мы разработали систему хуков. Это позволяет нам минимизировать изменения в основном коде zVirt, что упрощает процесс синхронизации с мейнлайном. Благодаря такому подходу подключение SDN оказывает минимальное влияние на существующую инфраструктуру. Миграция становится простой операцией — достаточно перезапустить ВМ, и после этого она уже окажется в среде SDN. 

При этом нам всё равно необходимо обеспечивать выход в физическую сеть предприятия. Для этого мы предлагаем различные способы публикации: 

• Стандартный вариант — L3-подключение, использование логических маршрутизаторов в качестве точек преобразования трафика. Пользователь выбирает VLAN для подключения, задаёт IP-адрес и получает продолжение сети в этом VLAN. Такой подход потребует либо применения NAT, либо настройки маршрутизации. 

• Механизм L2-бриджинга SDN с существующими VLAN. Он позволяет перенести нагрузки из существующего традиционного разбиения в SDN без реконфигурации сетевого стека ВМ, смены IP-адресов или маршрутов в сети. ВМ достаточно переподключить к другому профилю NIC и запустить заново. ВМ, подключенные к VLAN через L2-бриджинг,  будут работать точно так же, как и подключенные к тому же VLAN  через оригинальные механизмы. При этом функциональность SDN по контролю и зеркалированию трафика становится доступной без дополнительных трат на переезд. 

Кроме того, мы делаем SDN более лояльным к сетевой самодеятельности виртуальных машин. Например, в последнем релизе zVirt 4.2 мы одновременно решили две противоположные задачи: обеспечили механизм контроля MAC-адресов и IP-адресов на порту, а также предоставили возможность для большей свободы действий ВМ с точки зрения IP-адресов. zVirt SDN предназначен для решения насущных проблем в prod-среде, поэтому гибкость нужна, чтобы решение могло адаптироваться к различным сценариям. 

У SDN есть только путь

Мы продолжаем дорабатывать SDN-решение, и отдельный вызов для нас — разнообразие пользовательских сценариев. Нам приходится учитывать множество различных вариантов применения продукта: от крупного дата-центра до удаленного маленького филиала, где за всё отвечает один инженер. 

Еще один вызов — процесс миграции на SDN. Мы работаем над его упрощением, сокращаем количество шагов, чтобы сделать переход более гладким и понятным.

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

Сейчас самый интересный сценарий для большинства пользователей zVirt — применение L2-бриджинга. В следующей статье я подробно раскрою его техническую реализацию. А пока буду рад вопросам — про какие еще особенности разработки SDN в продукте хотелось бы узнать подробнее?