Дмитрий Змеев, директор по продуктам и маркетингу, и Вадим Миркушин, руководитель направления виртуализации сетевых сервисов (NFV) Brain4Net рассказали о том, как устроен технологический процесс портирования новых виртуальных функций на B4N Service Platform, какие продукты уже поддерживаются и какие требования должны быть соблюдены для быстрой интеграции партнерских VNF.

Какие функции виртуализируют сервис-провайдеры?

Разнообразие доступных виртуальных сетевых функций (VNF) на NFV-платформе – залог успешной реализации множества бизнес-кейсов оператора – от виртуализации инфраструктурных функций, например, для предоставления широкополосного доступа в Интернет (BRAS/BNG, DPI, CG-NAT), до клиентских сервисов в составе vCPE (vRouter, vFirewall, vIDS/IPS и др.). NFV-платформа как таковая – без широкого набора поддерживаемых виртуальных функций, представляет малый интерес. Так же, как и виртуализация отдельного аппаратного решения не даст серьезных преимуществ для оператора. В настоящее время мы видим наибольший интерес, как со стороны операторов, так и сервис-провайдеров, к виртуализации следующих групп сетевых функций:

  1. Всё, что связано с сервисами безопасности – Firewall / NG-Firewall, IDS/IPS, VNF-шлюзы (особый интерес к решениям с поддержкой «ГОСТ-шифрования»). Можно отметить определенный интерес к функциям антивируса и родительского контроля;
  2. Маршрутизаторы, BRAS/BNG, CG-NAT, DPI – виртуализация инфраструктуры IP/Service Edge;
  3. Виртуализация функционала клиентских устройств и централизованное управление ими, частичный перенос функций в облако оператора (концепция vCPE);
  4. Виртуализация функций ядра мобильной опорной сети– vEPC, vIMS и др.

Первые три группы сервисов позволяют оператору реализовать бóльшую часть существующих на данный момент use-кейсов NFV в области фиксированной связи, последняя – нацелена на постепенную модернизацию инфраструктуры мобильной сети и переходу к стандартам IMT2020 (сети 5G). Также стоит отметить еще несколько интересных операторам категорий – виртуализированные решения в области унифицированных коммуникаций (vPBX, vSBC, Video Conferencing и др.) и управления WAN-сетью корпоративных клиентов (решения SD-WAN).

Стратегия Brain4Net в части поддержки виртуальных функций от партнеров нацелена на предложение релевантных решений для всех вышеописанных групп. В первую очередь мы нацелены на поддержку коммерческих продуктов в области маршрутизации (vRouter, vBNG) и комплексных виртуализированных решений для обеспечения безопасности. На сегодняшний день B4N Service Platform уже поддерживает коммерческие продукты от Juniper и Fortinet, а также несколько продуктов с открытым исходным кодом – Pfsense, OpenWRT и VyOS.

В этой статье мы хотим поделиться опытом разработки и реализации процесса поэтапного портирования новых виртуальных сетевых функций (VNF) на платформу B4N Service Platform. В данном случае, «портирование» – обеспечение возможности запуска конкретной VNF на платформе и обеспечение управления её жизненным циклом (добавление, удаление, масштабирование, восстановление, обновление и др.). Целью процесса является возможность предоставить Заказчику широкий выбор поддерживаемых продуктов, которые он сможет быстро запустить на платформе и за несколько кликов создать комплексные инфраструктуры из этих виртуальных функций (см. статью «Сервисы на расстоянии клика»).

Процесс портирования

После решения всех организационных вопросов (заключение партнерства, получение дистрибутивов и др.) Brain4Net совместно с поставщиком VNF выполняют ряд задач, чтобы обеспечить полную поддержку виртуальной функции. Эти задачи можно условно разбить на следующие этапы:

ЭТАП 1. Проверка функциональных возможностей VNF

На этом этапе инженеры Brain4Net проверяют технические возможности виртуальной функции, проводя комплексную программу исследований, идентичную для всех поставщиков VNF. В эту программу входят проверки по следующим основным направлениям:

  • Доступ на VNF. По существующему workflow, первой к VNF подключается сеть management. Для успешной конфигурации на VNF должен быть либо доступ по SSH через первый интерфейс, либо возможность полностью сконфигурировать его через Cloud-Init (datasource: OpenStack или config-drive). Возможна также интеграция с внешним API самого VNF. Первый интерфейс должен получать IP-адрес по DHCP. Если для организации начального доступа на VNF необходимы предварительные настройки, они выполняются заранее вручную внутри образа VNF.
  • Конфигурация. После получения доступа на VNF через SSH по выданному на первый интерфейс адресу, возможны различные способы автоматической конфигурации:  Ansible, Bash/Shell скрипты, Netconf, возможно скопировать скрипт на VNF по SCP и выполнить его любым доступным на VNF executor-ом. Поддерживается эмуляция интерактивной конфигурации с помощью Expect. Обязательно в момент конфигурации ставится публичный SSH-ключ на VNF и меняется пароль пользователя по-умолчанию на случайно сгенерированный.
  • Мониторинг. Мониторинг осуществляется средствами внешнего сервера Zabbix, который отправляет данные на платформу через API. От VNF требуется наличие SNMP, Zabbix-агента или хотя бы возможность его установить и автоматически сконфигурировать. Метрики ожидаются с первого management-интерфейса VNF. При использовании SNMP, сервис должен отдавать на него корректные Object Identifiers для параметров производительности (CPU load, network load и т.д.).
  • Масштабирование. Определяется модель масштабирования: будет ли использовано вертикальное или горизонтальное масштабирование, какие конфигурационные процессы должны быть запущены для корректного масштабирования.
  • Управление. Определение методов передачи управления пользователю через management-интерфейс(SSH/WEB).
  • Доступность. На этом этапе проверяется обеспечение доступности и отказоустойчивости функции – возможность восстановления из бэкапа, поддержка High Availability (HA) по умолчанию и другие характеристики.
  • Лицензирование. Рассмотрение возможных схем лицензирования, методы установки и активации лицензий или необходимость интеграции с сервером лицензирования вендора VNF. Желаемый сценарий – лицензия активируется автоматически в процессе развертывания VNF с использованием скриптов, плейбуков или API.

После того, как инженеры Brain4Net определили технические возможности виртуальной функции, приступают к её портированию на платформу.

ЭТАП 2. Составление VNF-дескриптора

VNF-дескриптор содержит в себе описание принципов работы виртуальной функции, описание её компонент (возможно, что функция состоит из нескольких виртуальных машин – VDU), возможностей масштабирования, мониторинга и множества других технических характеристик. Дескриптор позволяет максимально четко описать поведение виртуальной функции и обеспечить её корректный запуск и управление жизненным циклом.

В случае, если вендор виртуальной функции не предоставляет VNF-дескриптор, Brain4Net оказывает максимальную поддержку процесса подготовки дескриптора, а зачастую и вовсе полностью берет эту задачу на себя.

ЭТАП 3. Сборка образа VNF

После выполнения всех вышеописанных шагов, инженерами Brain4Net собирается готовый образ виртуальной функции (со всеми необходимыми установочными скриптами, файлами и дескриптором). После чего, образ загружается в VNF Catalog платформы.

ЭТАП 4. Тестирование портированной виртуальной функции

На финальном этапе проводятся всесторонние тесты загруженной виртуальной функции – корректность работы жизненного цикла VNF, её использование в комплексных сетевых сервисах с другими функциями и др.

Что в итоге?

Весь вышеописанный процесс преследует одну цель – максимально упростить конечному Заказчику пользование платформой и запуск новых функций. Наша цель – обеспечить развертывание новых VNF в несколько кликов, взяв на себя все сложные и муторные задачи по обеспечению корректности работы.

Ежедневная кропотливая работа инженеров и архитекторов Brain4Net позволяет компании постепенно строить полноценный “marketplace” из виртуальных сетевых функций вендоров-партнеров и обеспечить заказчику максимально простое и удобное средство получения как коммерческих решений, так и решений с открытым исходным кодом.

На момент написания статьи на B4N Service Platform уже поддерживается более десяти различных поставщиков VNF, включая Juniper, Fortinet, Palo Alto Networks, Arbor и др. В дополнение к коммерческим продуктам, Brain4Net старается предложить альтернативное решение на базе открытого исходного кода. Так, в текущий момент поддерживаются такие продукты, как OpenWRT, VyOS, pfSense.

В вопросах портирования новых продуктов на B4N Service Platform, Brain4Net движется с высокой скоростью, которая позволяет компании каждый квартал добавлять на платформу до шести новых продуктов.

Хотите получить больше информации о поддерживаемых продуктах? Не нашли среди вышеописанных поставщиков нужного Вам? Хотите увидеть демонстрацию работающих решений? Напишите нам на need@brain4net.com, мы всегда готовы рассмотреть вопрос о быстром обеспечении поддержки конкретного продукта и поделиться с Вами всей необходимой информацией.