SDN и NFV: облачная виртуализация операторских сетей

Статья в №9 2015 г  журнала «Вестник Связи». (ссылка на оглавление журнала)

Технологии программно-конфигурируемых сетей SDN и виртуализации сетевых функций NFV имеют для отрасли связи такое же значение, как и переход от аналоговых АТС к цифровым станциям. Похожую параллель можно провести относительно перехода от парового двигателя к двигателю внутреннего сгорания, от луков, стрел и мечей к огнестрельному оружию, от конницы к танкам. Цели и задачи — одни и те же, средства реализации — разные.

В чем преимущества и выгоды от применения NFV для операторов? Можно указать лишь основные из них:

  • оперативность вывода новых услуг на рынок. NFV позволяет “конструировать” новые услуги программно в дата-центрах, там же их тестировать и быстро выводить на рынок;
  • сокращение капитальных затрат. Виртуализация сетевых элементов на стандартных серверах при массовом развертывании будет обходиться значительно дешевле, чем их реализация на выделенном оборудовании;
  • сокращение операционных затрат. Обслуживание стандартных серверов в дата-центрах производится обычным ИТ-персоналом, а не специализированными инженерами по аппаратным платформам операторских сетей, при меньшей численности требуемого персонала;
  • гибкость использования ресурсов. При небольшом трафике вызовов задействуется минимальное количество виртуальных машин на серверах, при росте трафика автоматически подключаются новые виртуальные машины для эмуляции функций сетевого оборудования. В случае аппаратной реализации ресурсы оборудования используются нерационально, поскольку они всегда рассчитываются на максимальный трафик в сети, а такие ситуации случаются лишь в часы максимальной нагрузки.

Разработка SDN началась в 2006 г. для кампусной сети Стэнфордского университета в Калифорнии, когда был создан протокол OpenFlow для централизованного управления процессами маршрутизации пакетов. Через несколько лет концепция приобрела популярность в Сети, а компания Google использовала SDN для централизованного управления сетью своих дата-центров в США, Азии и Европе. Затем технология SDN начинает активно применяться на сетях телекоммуникационных операторов. На этом этапе стала возможной виртуализация функций сетевых элементов NFV (Network Function Virtualization) телекоммуникационной сети, таких как элементы IMS (IP Multimedia Subsystem), включая ее отдельные компоненты, а также EPC (Evolved Packet Core), включая маршрутизаторы и коммутаторы, и др.

 Архитектура NFV

Picture1

Рис. 1 Архитектура NFV

Архитектура виртуализации сетевых функций (NFV), разработанная ETSI (документ GS NFV-0010 V0.1.7), показана на рис. 1.

Ее основной особенностью является возможность так называемой “оркестрации услуг”, т. е. выделение виртуальных ресурсов тем или иным услугам по запросу. При этом достигается наиболее оптимальное использование ресурсов оборудования: серверов, хранения и сети. Для этого в архитектуре NFV предусмотрен компонент администрирования и оркестрации MANO (Management and Orchestration), который является важнейшей частью концепции NFV. Рассмотрим работу системы MANO и ее отдельных элементов подробнее.

Блок виртуальной функции сети VNF (Virtual Network Function). Виртуальные сетевые функции VNF — основа архитектуры NFV. Это виртуализированные сетевые элементы. Например, это может быть маршрутизатор или базовая станция и пр. VNF может представлять также одну из подфункций сетевого элемента, например функцию пересылки пакетов в маршрутизаторе. Тогда несколько VNF будут соответствовать одному физическому сетевому элементу. Другие элементы телекоммуникационной сети, например IPS, GGSN, SGSN, RNC, SBC и пр., также могут быть реализованы программно в виде VNF.

Следует отметить, что разница между похожими аббревиатурами в том, что NFV — это технология, а VNF — это функция.

Система администрирования EMS (Element Management System). Управляет работой элементов VNF, отвечает за задание параметров, т. е. администрирование операций VNF, точно так же, как физические сетевые элементы управляются от системы управления сетью NMS (Network Management System). Например, это может быть управление при отказах, управление производительностью и другие функции системы управления сетью. Управление VNF от EMS осуществляется через закрытые интерфейсы (на рис. 2 они не показаны именно потому, что они закрытые). Одной VNF может соответствовать одна EMS, или одна EMS может управлять несколькими VNF. Кроме того, сама EMS также может представлять собой VNF, управляемую от другой EMS.

Менеджер VNFM (VNF Manager). Управляет работой одной или нескольких VNF. Например, он управляет жизненным циклом функций VNF, т. е. запускает, обслуживает и останавливает работу VNF. VNFM может выполнять те же функции, что и EMS, но через референсную точку, предложенную ETSI, в архитектуре NFV. Эта точка называется VeNf-Vnfm. Что такое “референсная точка” и чем она отличается от интерфейса — поясняется далее.

Инфраструктура NFVI (Network Function Virtualization Infrastructure). Среда (инфраструктура), в которой работают VNF. Она включает ресурсы физического оборудования, виртуальные ресурсы и уровень виртуализации, а именно:

  • аппаратные ресурсы (вычислительные, сетевые и ресурсы хранения) — это физическая часть инфраструктуры NFVI. Виртуальные ресурсы NFV запускаются на ее физических ресурсах. Любой стандартный коммутатор или физический сервер, или устройство хранения могут входить в эту категорию;
  • плоскость виртуализации отвечает за абстрагирование физических ресурсов в виде виртуальных ресурсов. На этом уровне находится специальная программная платформа “гипервизор”, которая производит отделение программных средств от аппаратных, т. е. дает возможность запускать программы независимо от выбранного оборудования, например, операционная система может работать на любом физическом сервере, который назначается для этой цели в данный момент;
  • виртуальные ресурсы (вычислительные, сетевые и ресурсы хранения) — это виртуальная часть инфраструктуры NFVI. Физические ресурсы абстрагируются в виртуальные ресурсы, которые используются для работы функций VNF.

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

  • Менеджер виртуализированной инфраструктуры VIM (Virtualized Infrastructure Manager). Система администрирования инфраструктуры NFVI, отвечающая за управление и администрирование ресурсов NFVI внутри одного домена инфраструктуры оператора, а также за сбор результатов измерений производительности и событий.
  • Оркестратор NFV (NFV Orchestrator). Генерирует, обслуживает и прекращает работу сетевых сервисов (функций) VNF через VNFM. Однако, его основным предназначением является создание комплексного сервиса из многих VNF. Также оркестратор отвечает за администрирование глобальных ресурсов NFVI. Например, он администрирует ресурсы вычислений, хранения и сети на нескольких менеджерах VIM на сети. Оркестратор не взаимодействует напрямую с VNF, только через VNFM и VIM. Например, имеется несколько функций VNF, из которых создана комплексная услуга — это может быть виртуальная базовая станция или виртуальный домен опорной сети ЕРС. На сети эти элементы могут быть представлены оборудованием либо от одного, либо от разных вендоров, для чего необходимо создать комплексную (end-to-end) услугу с использованием нескольких VNF, при этом требуется оркестратор услуг для коммуникации со всеми VNF и создания комплексной услуги.
  • Система поддержки операций и бизнеса OSS/BSS (Operation Support System/Business Support System). Это физическая система OSS/BSS оператора. OSS занимается управлением сетью, при отказах, конфигурацией и услугами. BSS отвечает за управление клиентами, продуктами, заказами и др.

В архитектуре NFV, имеющаяся BSS/OSS оператора может быть интегрирована с системой NFV MANO при помощи стандартных интерфейсов. Рассмотрим подсистему MANO более подробно, поскольку она является существенной частью архитектуры NFV.

MANO (Management & Orchestration)

При знакомстве с технологией MANO может возникнуть два вопроса.

В традиционных сетях связи существует только одна система управления NMS, которая может поддерживаться OSS. В сети NFV требуются еще несколько менеджеров: VIM Manager, VNF Manager и оркестратор. Есть также традиционная BSS. В итоге — пять разных административных систем. Не многовато ли?

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

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

Прежде всего, почему важно разбираться в модели MANO?

  • Во-первых, потому что MANO является основой архитектуры NFV и понимание работы MANO прояснит всю картину NFV.
  • Во-вторых, если вы оператор, то это поможет оценить решение NFV любого вендора, соотнося его с моделью ETSI. Если вы вендор и ожидаете RFP от оператора, то это поможет вам разобраться и понять, что нужно включать в техническое предложение.

MANO

Рис. 2. MANO.

В состав MANO входит три вида менеджеров: VIM, VNF (VNFM), NFV (NFVO) и группа репозиториев (рис. 2). В дополнение к четырем блокам внутри MANO есть также два блока вне ее: традиционная система управления сетевыми элементами EM (Element Management) и традиционные системы OSS/BSS оператора. Хотя они не входят в состав MANO непосредственно, они обмениваются с ней информацией.

VIM. Администрирует использование ресурсов в “одном домене” NFVI. Это могут быть либо физические ресурсы (серверы, хранилища, сетевые устройства), либо виртуальные ресурсы (виртуальные машины), а также программные ресурсы (гипервизоры). “Один домен” означает, что в архитектуре NFV могут быть несколько VIM, каждый из которых администрирует свой домен инфраструктуры NFVI.

Основные задачи VIM следующие:

  • управление жизненным циклом виртуальных ресурсов в домене NFVI, т. е. создание, поддержка и прекращение работы виртуальных машин на физических ресурсах в домене NFVI;
  • учет виртуальных машин, назначенных физических ресурсов для работы виртуальных машин;
  • управление FCAP (Fault, Configuration, Accounting, Performance) для программ и виртуальных ресурсов;
  • поддержка программируемых интерфейсов приложений для верхнего уровня, через которые физические и виртуальные ресурсы предоставляются другим системам управления.

VIM и NFVI являются основным фокусом разработок организации OPNFV. Ее целью является предоставление NFVI, VIM и открытых API для других NFV, которые вместе составляют общую архитектуру NFV.

VNFM. То, чем VIM является по отношению к NFVI, тем и VNFM является по отношению к функциям VNF, т. е. VNFM управляет функциями VNF как виртуальными сетевыми элементами, например, это может быть функция виртуального маршрутизатора Router VNF, виртуального коммутатора Switch VNF и т. д. В частности, VNFM занимается следующим:

  • определяет жизненный цикл VNF (создает, поддерживает и удаляет виртуальные сетевые элементы VNF);
  • отвечает за администрирование FCAP для VNF;
  • масштабирует функции VNF, что выражается в росте или снижении использования процессоров физического сервера, на котором “подняты” VNF, выделенных ресурсов хранения, а также коммутационной сети.

Одновременно может работать несколько менеджеров VNFM, управляющих различными VNF, или один VNFM может управлять несколькими VNF.

NFVO — оркестратор виртуализации сетевых функций (NFV Orchestrator). Как было отмечено выше, может быть несколько VIM, управляющих несколькими доменами NFVI. При этом возникают следующие вопросы:

  • кто управляет и координирует работу ресурсов, принадлежащих различным VIM, когда в одной “точке присутствия” РоР (Point of Presence) работают несколько VIM? Или когда один VIM работает в нескольких РоР? Точно так же может быть несколько VNFM, управляющих многими VNF;
  • кто управляет и координирует создание комплексных услуг с использованием нескольких VNF из разных доменов VNFM?

Для решения этих задач и создан оркестратор NFVO, который координирует, авторизует, занимает и высвобождает ресурсы NFVI в одной или многих РоР при помощи VIM напрямую или через восходящие интерфейсы API (оркестрация ресурсов).

Оркестрация услуг решает вопрос создания комплексных услуг из наборов VNF, когда они управляются от различных VNFM. Оркестратор услуг создает комплексную услугу из разных VNF путем координации соответствующих VNFM, поэтому нет необходимости в непосредственном взаимодействии с отдельными VNF. Например, это может быть создание услуги между виртуальной базовой станцией одного вендора и виртуальным узлом опорной сети EPC другого вендора. В процессе по мере необходимости могут запускаться новые VNFM. Производится управление топологией сетевых услуг, также называемых сетевыми графами VNF (VNF Forwarding Graphs). Образно можно представить NFVO в виде “клея”, который соединяет VNF друг с другом, создает комплексные услуги и осуществляет координацию ресурсов для таких “склеек”.

Репозитории. Существует четыре типа репозиториев:

  • каталог сетевых услуг, содержащий шаблон развертывания для сетевых услуг;
  • каталог VNF для всех используемых дескрипторов VNF, используемый менеджером VNFM в процессе запуска и управления жизненным циклом функции VNF;
  • список экземпляров NFV содержит все детали о примерах (экземплярах) сетевых услуг и соответствующих экземплярах VNF;
  • ресурсы инфраструктуры NFV, используемые для формирования услуг.

EMS. Система управления элементами формально не входит в MANO, но если она присутствует, то ей нужна координация с VNFM, поэтому важно знать о том, что она делает.

EMS отвечает за управление FCAPS для VNF, т. е. это управление при авариях, конфигурацией, аккаунтами, производительностью и безопасностью. Как отмечалось выше, VNFM также это делает. Однако в отличие от VNFM, EMS делает это через закрытые интерфейсы с VNF. Тем не менее, EMS должна обмениваться информацией с VNFM через открытый интерфейс или референтную точку. Также она может работать с виртуализированными элементами вместе с VNFM для выполнения функций, которые требуют обмена информацией о ресурсах NFVI, ассоциированных с VNF.

OSS/BSS. Это стандартная система оператора с набором систем и приложений, которые он использует для управления и поддержки бизнеса. NFV должна работать вместе с ней, а не автономно.

В принципе, можно управлять функциями VNF и инфраструктурой NFVI от OSS/BSS непосредственно расширением существующего функционала OSS/BSS, но это выливается в необходимость развертывания собственных (закрытых) реализаций вендора, что ведет к “вендорозависимости” оператора. По крайней мере, интерфейсы между EMS и VNF пока не определены в ETSI. Поскольку NFV представляет собой открытую платформу, то управление объектами NFV через открытые референсные точки (как в MANO) является более рациональным подходом.

Существующие OSS/BBS, однако, могут предоставить для NFV MANO дополнительные функции, если они не поддерживаются в конкретной реализации NFV MANO. Такое предоставление осуществляется через стандартные открытые интерфейсы между NFV MANO и существующими OSS/BSS.

Референсные точки. MANO имеет множество референсных точек, например, Or-Vi, NF-Vi, Or-Vnfm и др. Почему они называются именно “референсными точками”, а не интерфейсами?

Термин “интерфейс” подразумевает двусторонний обмен сигнальными сообщениями между точками, которые представляют собой законченные физические либо программные объекты. Референсная точка, в отличие от интерфейса, определяет взаимодействие между функциональными архитектурными блоками, которые сами состоят из законченных программно-аппаратных объектов. А поскольку в концепции MANO мы оперируем именно функциональными блоками, а не объектами, поэтому вместо слова “интерфейс” используется термин “референсная точка”.

Вот вкратце все, что нужно знать об NFV MANO для первоначального знакомства.

Что впереди

Вряд ли трансформация в сетях операторов через SDN и NFV будет легким и простым процессом. Переход на цифровые станции также занял в свое время годы и десятилетия. Многие помнят показатель “процента цифровизации” для операторских сетей, и даже сейчас нельзя сказать, что он везде составляет 100 %. Точно также и процент “энэфвизации” для операторских сетей будет вначале небольшим, но по мере амортизации выделенного сетевого оборудования, аппаратных платформ IMS/EPC, сетей агрегации и доступа будет происходить постепенный переход на “облачные” платформы SDN/NFV.

* * *

А эта картинка в журнале не опубликована… 🙂

cartoon-Apr-4

— В компании внедряется виртуализация, и старое сетевое оборудование больше не нужно. Поэтому его отдали в комнату для кофе, а мебель продали.

Об авторе Алексей Шалагинов

Независимый эксперт
Запись опубликована в рубрике Статьи, NFV, SDN с метками , , . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.