Введение

Виртуализация сетевых функций (NFV) и облачные сетевые функции (CNF) продолжают набирать популярность в отрасли телекоммуникаций. Виртуализация помогает сократить капитальные и операционные затраты, отделяя сетевые функции от инфраструктуры и обеспечивая гибкость и масштабируемость. Несмотря на широкое распространение этой технологии, организации по-прежнему сталкиваются с трудностями при ее реализации в повседневной работе.

Одна из главных сложностей — наладить процесс управления сетевыми функциями и их оркестровки. Телеком-компании должны создавать виртуализированные сетевые функции, при этом поддерживать высокое качество обслуживания и внедрять постоянно появляющиеся инновации. Технология 5G, скорее всего, продержится еще 5–8 лет, прежде чем уступить место 6G. Переход на сети нового поколения обходится дорого, и если средний доход на абонента не будет покрывать капитальные затраты, телеком-компании не смогут сохранить свои прибыли.

Чтобы сократить расходы и одновременно повысить безопасность и качество, компании обращают внимание на проекты с открытым исходным кодом, например Open Source MANO (OSM), Open Networking Foundation (ONF), Open Radio Access Network (O-RAN), OpenStack и т. д. С одной стороны, эти решения позволяют телеком-компаниям сокращать расходы и не зависеть от вендора, а с другой — им недостает поддержки и совместимости с другими решениями. Кроме того, эти технологии обычно предлагают только один компонент, в то время как компании предпочитают комплексные решения. Стек с открытым кодом от Canonical выделяется на фоне остальных решений, поскольку использует подход на основе моделей и значительно упрощает интеграцию между всеми компонентами.

Здесь будет описано, как создавать сетевые функции и интегрировать их в платформу MANO (управление и оркестровка сетевых функций), предложенную Европейским институтом телекоммуникационных стандартов (ETSI) для решения проблем совместимости и поддержки. У сетевых функций есть нефункциональные требования в производственной среде, связанные с мониторингом, логированием, масштабированием, апгрейдами и т. д. Мы рассмотрим, как удовлетворить эти требования с помощью основанного на моделях комплексного решения с открытым кодом, а не отдельных компонентов.

Сетевые функции

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

• Физические сетевые функции. PNF представляют собой оборудование (маршрутизатор, коммутатор, МСЭ и т. д.), тесно связанное с программным обеспечением.

PNF очень популярны. Это неплохой вариант, если клиент не возражает против зависимости от вендора и не хочет заниматься развертыванием сети.

• Виртуальные сетевые функции. VNF — это программная реализация сетевой функции или модуля, которая воспроизводит возможности PNF. VNF работают на виртуальных машинах (VM), которые можно запускать на обычном оборудовании, избегая зависимости от вендора.

VNF появились относительно недавно и пока не так широко распространены, как PNF. Это идеальный вариант для ситуаций, когда клиент хочет сам контролировать установку и развертывание или ему нужны возможности переноса и миграции.

• Облачные сетевые функции. CNF — это контейнеризированные PNF или VNF в облаке. Они работают на микросервисах, которые взаимодействуют друг с другом, образуя сеть. Микросервисы работают на контейнерах Docker, которые управляются с помощью Kubernetes (k8s), и используют принципы CI/CD в облачной архитектуре. CNF и KNF (сетевые функции на базе Kubernetes) одинаково используются в домене NFV, поскольку оба типа основаны на облачных концепциях.

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

В этом документе рассматриваются виртуализированные и контейнеризированные сетевые функции.

Внедрение сетевых функций с помощью Open Source MANO (OSM)

ETSI OSM — это проект сообщества ETSI, который предоставляет стек MANO с открытым исходным кодом, соответствующий информационным моделям и требованиям ETSI к NFV производственного класса¹. Этот стек ускоряет миграцию на NFV благодаря внедрению сетевых функций, а затем обеспечивает автоматизированную оркестровку сетевых функций с помощью day-2 операций.

Шаблоны проектирования и свойства

Для достижения желаемой производительности необходимо спроектировать сетевые функции таким образом, чтобы они были совместимы с облаком и обеспечивали устойчивость. Ниже приводится список основных элементов для настройки сетевых функций до оркестровки, как описано в стандарте NFV-SWA 001.

• Планирование инфраструктуры. Необходимо выбрать оптимальную инфраструктуру для сетевой функции. Это может быть bare metal, кластеры Kubernetes и виртуальные машины.

• Выбор моделей данных. Для сетевых функций необходимо составить стандартизированное описание, чтобы они поддерживали разные виртуальные инфраструктуры. Чтобы обеспечить совместимость компонентов NFV, центры стандартизации предоставляют разные модели данных.

• Оценка сетевых функций. Сетевые функции необходимо тестировать с учетом определенных критериев вычислительной сети и ресурсов хранения в инфраструктуре. Они должны обеспечивать одинаковые КПЭ в разных условиях.

• Внутренняя структура сетевых функций. Чтобы эффективно использовать микросервисы, нужно разделить функционал по разным виртуальным машинам и контейнерам в соответствии с требованиями сетевой функции.

• Создание инстансов сетевых функций. Выберите метод создания инстансов для сценариев отработки отказа. Для некоторых сетевых функций подходит использование параллельных инстансов, для других — непараллельных.

• Управление операциями. Сюда входит мониторинг, логирование, масштабирование, аудит, апгрейды, безопасность и т. д. Чтобы достичь высокой производительности, эти day-2 операции необходимо автоматизировать, поскольку управление ими вручную потребует слишком много ресурсов.

Этапы внедрения

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

• Создание дескрипторов сетевых функций в качестве шаблонов для инициализации и завершения, масштабирования, обновления или апгрейда.

• Создание пакетов для сетевых сервисов, то есть шаблонов для образов и конфигураций виртуализированной инфраструктуры, с помощью Enhanced Platform Awareness в OSM.

• Настройка day-1 и day-2 операций и действий в соответствии с требуемыми сервисами.

• Валидация и загрузка в каталог сервисов OSM.

Все этапы внедрения сетевых функций можно выполнить с помощью OSM, создав пакет сетевой функции с указанием конфигураций для day-0 (создание инстанса), day-1 (инициализация сервиса) и day-2 (операции в среде выполнения)⁷. Конфигурации day-1 и day-2 описаны в скриптах, которые называются чармы (charm). Они позволяют выполнять операции (см. день 1) в соответствии с функциональными требованиями. Эти чармы затем интегрируются в дескрипторы OSM.

Ниже приводится подробное описание каждого этапа.

Day 0

Конфигурация day-0 дня охватывает создание инстанса сетевых сервисов, или набора сетевых функций, а также настройку начальных параметров инфраструктуры, которые понадобятся позже в процессе внедрения.

• Создайте начальный пакет по стандарту ETSI SOL0063 и укажите базовые параметры, чтобы создать инстанс сетевого сервиса.

• Создав дескриптор сетевой функции (NFD) и дескриптор сетевого сервиса (NSD) в пакетах, определите параметры точек подключения, через которые будут взаимодействовать компоненты сетевой функции.

• Интегрируйте в дескрипторы скрипты cloud-init для основных конфигураций, необходимых для создания сетевого сервиса, например требования к загрузке ОС, настройка имени хоста, добавление ключей SSH, настройка сетевых устройств и пользователей.

• OSM поддерживает возможности Enhanced Platform Awareness (EPA) в дескрипторах, поэтому здесь можно включить Hugepages, CPU pinning, SR-IOV и другие возможности ускорения в сетевых функциях.

Day 1

Компонент OSM VCA (конфигурация и абстракция VNF) отвечает за day-1 и day-2 операции и работает на базе Juju⁸. Juju управляет чармами — кодом операций в дескрипторах сетевых функций. Это набор скриптов для развертывания и эксплуатации другого программного обеспечения. В нашем случае это сетевая функция.

OSM поддерживает два типа чармов — нативные и прокси-чармы. Выбор зависит от характера сетевой функции (см. рисунок ниже). Если вы используете фиксированный образ для сетевой функции, которую нельзя изменить, прокси-чарм необходимо разместить не в сетевой функции, а в другом LXD (менеджер контейнеров Linux) или облаке K8s. Если это нативный чарм, его можно изменить и нужно развернуть в той же рабочей нагрузке или сетевой функции.

Day-1 конфигурации запускают сервис и обеспечивают ожидаемый функционал сетевых функций. Этапы процесса:

• Создайте чарм (прокси или нативный) как оператор сетевой функции.

• Определите в чармах примитивы/действия, которые необходимо выполнить сразу после создания инстанса сервиса, т. е. начальную конфигурацию чарма и аутентификацию при использовании прокси-чармов.

• Интегрируйте настроенный чарм в дескрипторы OSM.

Day 2

За day-2 операции отвечает Juju, а для включения примитивов используется тот же механизм, что и для процесса day-1 конфигурации. Различаться будет характер примитивов, поскольку действия day-2 сосредоточены на операциях в среде выполнения⁴ и конфигурации, необходимой после создания инстансов сетевого сервиса, в том числе:

• Переконфигурация после запуска сервиса.

• Мониторинг определенных метрик инфраструктуры.

• Масштабирование на основе мониторинга.

• Операции для полной автоматизации.

Итак, сетевая функция внедрена и управляется через OSM. Сложность в том, что недостаточно автоматизировать внедрение сетевой функции и наладить ее работу. Существуют нефункциональные требования, связанные с мониторингом, логированием и аудитом, выполнение которых также можно упростить с помощью связей Juju⁹, как описано в следующих разделах.

Нефункциональные требования сетевых функций

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

Как решение для моделирования приложений Juju предоставляет инструменты с открытым кодом на основе моделей, которые можно легко интегрировать с сетевыми функциями с помощью связей. Если сетевая функция использует чарм, ее можно интегрировать в другие инструменты мониторинга с открытым кодом, связав ее с чармами этих инструментов.

Логирование, мониторинг и алерты (LMA)

Итак, сетевая функция внедрена в OSM и управляется оператором. Для непрерывного мониторинга и логирования требуется создать открытую инфраструктуру LMA на основе моделей. С ее помощью можно повторно использовать одни и те же модели, чтобы не менять конфигурацию всего стека LMA при обновлении сетевой функции. Это можно сделать с помощью связей Juju. Связи — это каналы коммуникаций между чармами, которые предоставляют абстракции для взаимодействия приложений.

Еще одно преимущество связей Juju — возможность повторного использования и бесшовная интеграция новых компонентов. Если масштаб сетевой функции увеличивается и нужно добавить больше инстансов, можно использовать тот же стек LMA без повторной конфигурации для новых юнитов в модели Juju.

Масштабирование

Масштабирование — это увеличение или уменьшения объема ресурсов в зависимости от требований пользователя или приложения. Juju поддерживает горизонтальное масштабирование с увеличением числа виртуальных машин или контейнеров в определенной сетевой функции. Это позволяет менять масштаб внедренных сетевых функций с помощью одной команды.

Следующий механизм создаст три дополнительных юниты, чтобы удовлетворить спрос сетевой функции.

Безопасность

Несмотря на признанные преимущества сетевых функций, включая сокращение операционных затрат и повышение эффективности сети, приоритетом остается безопасность.

В любом решении ее можно обеспечить на нескольких уровнях. Безопасность операционной системы можно легко реализовать, если развернуть сетевую функцию в ОС с регулярными обновлениями безопасности, например Ubuntu. Поддержка Extended Security Maintenance (ESM) для релизов Ubuntu LTS обеспечивает патчи для серьезных и критических CVE.

Для безопасности на уровне приложения можно, например, использовать в качестве чармов системы с открытым исходным кодом для обнаружения вторжений, такие как Snort, Zeek и Suricata, и интегрировать их с сетевой функцией. Развертывание и интеграция осуществляются так же, как описано выше для стека LMA.

Сценарий применения: оркестровка системы тестирования 5G с помощью Charmed OSM

Телеком-компании активно переходят с платформ bare metal на нативные облачные сети 5G. Чтобы обеспечить эффективность виртуализации сетевых функций в 5G, необходимо виртуализировать или контейнеризировать сетевые функции таким образом, чтобы их можно было изменять, контролировать, отслеживать и оптимизировать без лишних усилий.

TATA Elxsi имеет огромный опыт в реализации крупных программ в сфере беспроводных технологий и 5G и активно развивает проект Open Source MANO. В сотрудничестве с Canonical, TATA развернула систему тестирования 5G в Charmed OSM, чтобы тестировать производительность платформы операторов Canonical Juju при настройке и мониторинге 5G CNF.

Charmed OSM — это апстрим-дистрибутив Open Source MANO, разрабатываемый и обслуживаемый Canonical, который упрощает развертывание и эксплуатацию с помощью чармов Juju. Charmed OSM позволяет провайдерам телеком-услуг легко развертывать апстрим Open Source MANO в высокодоступных масштабируемых кластерах производственного класса.

Обзор решения

С помощью контроллера Juju и Charmed OSM можно развертывать сетевые функции Kubernetes (KNF) для 5G в инфраструктуре MicroK8s. Все компоненты, то есть сеть радиодоступа (RAN) и 5G Core, основаны на платформе операторов на базе моделей, которые можно повторно использовать, обновлять и интегрировать в зависимости от текущих требований. Функциональные возможности платформы:

• Внедрение 5G Core, эмулятора 5G RAN и IMS с помощью Charmed OSM.

• Связывание сетевых сервисов 5G E2E (эмулятор RAN, Core, IMS).

• Конфигурация day-1 и day-2 использует универсальный менеджер VNF (контроллер Juju и чармы).

• Мониторинг KNF на основе чармов контроллера Juju и визуализация в Grafana.

Эти варианты применения проверены в рамках развертывания, куда входит подключение к PDN (сеть пакетной передачи данных), IP-соединения между абонентскими станциями и возможность вызовов по протоколу Voice SIP.

Информация о компонентах:

Экосистема с открытым исходным кодом для создания сетевых функций

Продукты с открытым исходным кодом позволяют снизить капитальные затраты при переходе на новые технологии, но телеком-компании и мобильные операторы ищут поставщика комплексного решения. Как мы уже говорили, сетевые функции связаны с нефункциональными требованиями, на основе которых операторы готовят их к развертыванию и оркестровке.

Canonical предлагает комплексное решение с использованием технологий с открытым исходным кодом для эффективного создания сетевых функций. Компания предоставляет все необходимые элементы: Ubuntu в качестве операционной системы, кластеризация LXD для абстрактного уровня виртуализации, Ceph для распределенного хранения, а также MicroK8s и микрооблака для предоставления рабочих нагрузок в контейнерах и виртуальных машинах. Charmed OSM отвечает за уровень управления развернутых приложений. Все эти компоненты поддерживают подход на основе моделей, в котором используется Juju и чармы. Их можно развертывать и повторно использовать в соответствии с требованиями сетевых функций.

Canonical предлагает не только управляемую инфраструктуру для внедрения сетевых функций, но и стек мониторинга для нефункциональных требований, например Prometheus для сбора метрик, Grafana — для их анализа, Graylog для лога аудитов и Filebeat для объединения логов из различных компонентов или баз данных. Наряду с разработкой инновационных и улучшенных инструментов с отрытым кодом Canonical также предоставляет операторы, которые упрощают развертывание и обслуживание имеющихся инструментов.

 Ссылки на ресурсы:

1. https://osm.etsi.org/images/OSM-Whitepaper-TechContent-ReleaseONE-FINAL.pdf

2. https://osm.etsi.org/images/OSM_VNF_Onboarding_Guidelines_June_2019.pdf

3. https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/006/02.07.01_60/gs_nfv-sol006v020701p.pdf

4. https://osm.etsi.org/docs/vnf-onboarding-guidelines/04-day2.html

5. https://osm.etsi.org/docs/vnf-onboarding-guidelines/02-day0.html

6. https://osm.etsi.org/docs/vnf-onboarding-guidelines/06-walkthrough.html

7. https://osm.etsi.org/docs/vnf-onboarding-guidelines/00-introduction.html

8. https://juju.is/docs/sdk

9. https://juju.is/docs/relations

Присоединяйтесь к Telegram каналу UBUNTU Community, чтобы быть в курсе последних новостей!