NFV для корпоративных сервисов

Программное конфигурирование сетей (Software-Defined Networking, SDN) и виртуализация сетевых функций (Network Functions Virtualization, NFV) входят в число наиболее обсуждаемых тем современной сетевой отрасли. В NFV виртуализация применяется к функциональности сетей. Согласно концепции виртуализации сетевых функций, проприетарное сетевое оборудование и специализированные сетевые устройства заменяются на программное обеспечение, которое выполняется на серверах общего назначения — коммерческих стандартных платформах.

Модель развертывания NFV может быть централизованной, когда серверы размещаются в ЦОД оператора, или распределенной (Distributed NFV, D-NFV), при которой виртуализация сетевых функций осуществляется в любом месте сети — в точках присутствия оператора и даже на стороне пользователя, в клиентском сетевом оборудовании. Последняя концепция, помимо того что может оказаться более эффективной и экономически оправданной, снижает риски перехода операторов на новую модель. Она активно продвигается, в частности, компанией RAD (см. интервью с Юрием Гиттиком в июльском номере «Журнала сетевых решений/LAN» за 2014 год).

RAD Data Communications — один из пионеров в D-NFV — большинство своих разработок осуществляет в партнерстве с ведущими мировыми операторами связи. На всемирном конгрессе «Network Virtualization & SDN World 2014» решение RAD для D-NFV было отмечено как инновация года в области NFV. В нем используется оборудование ETX — сетевое интерфейсное устройство второго/третьего уровня, оснащенное модулем D-NFV и интегрированным сервером x86 для виртуализации сервисов на площадке клиента. Компания, активно участвующая в деятельности соответствующих отраслевых органов стандартизации NFV, не так давно открыла новый центр разработки и исследований с фокусом на NFV и SDN.

В конце октября в Москве состоялся ежегодный международный «Ethernet-форум – 2014», организованный издательством «Открытые системы» и «Журналом сетевых решений/LAN». На одном из семинаров Юрий Гиттик, руководитель отдела стратегического развития и инноваций компании RAD, отвечающий за новые продуктовые направления, включая облачные вычисления, SDN и NFV, представил точку зрения компании на значение виртуализации сетевых функций для корпоративных сервисов.

ИЗ ИСТОРИИ NFV

Еще в 2004 году BT предложила идею сетевой инфраструктуры 21 Century Network с целью снижения операционных затрат, ускоренного внедрения новых сервисов и предоставления пользователям более гибких возможностей. Она предполагала объединение ядра сети и сети доступа в рамках единой сетевой платформы, но без виртуализации данная концепция не получила успешного продвижения.

По словам Юрия Гиттика, сегодня быстрое развитие NFV определяется несколькими факторами: стремительным ростом популярности виртуализации в ИТ, потребностью распространить идеи виртуализации на область сетевых функций и возможностью реализации последних за счет совершенствования элементной базы и инструментальных средств. Наконец, для реализации NFV доступна инфраструктура облачных вычислений и ЦОД.

По существу, NFV — это попытка операторов избавиться от жесткой привязки к конкретному производителю сетевого оборудования, поскольку они не хотят зависеть от одного поставщика. В традиционных сетях на каждой площадке устанавливается фрагментированное специализированное оборудование. Необходимость в дорогостоящей разработке новых аппаратных решений затрудняет выход на данный рынок новых игроков, препятствует инновациям и конкуренции. NFV предполагает применение стандартных серверов и коммутаторов, виртуальных устройств независимых поставщиков и программных инструментов управления/оркестрации (см. Рисунок 1). Таким образом, на этот раз инициаторами стандартизации выступают не вендоры, а операторы.

Рисунок 1. В NFV используется общая инфраструктура виртуализации и достигается высокая степень гранулярности сетевых функций. Последние реализуются на уровне ВМ, а не физических сетевых устройств со специальным программным обеспечением.

По сути, едва появившись, новая концепция NFV уже оказывает заметное влияние на стратегию крупных операторов, что свидетельствует об острой необходимости в ней. Менее чем за год вышло пять спецификаций NFV, и сейчас готовится новое издание (см. Таблицу 1). В выпущенном в середине октября документе «NFV White Paper 3.0» суммируется содержимое подготавливаемых документов NFV Industry Specification Group (ISG), рассказывается о перспективах стандартизации NFV, подчеркивается важность развития систем управления сетями в соответствии с динамикой и гибкостью NFV, создания учебных курсов и проведения исследований (http://portal/etsi/org/NFV/NFV_White_Parer3.pdf).

Таблица 1. Из истории NFV.

Проект документа «NFV ISG Second Release» (его окончательный вариант должен быть опубликован в январе 2015 года) включает в себя описание общей сетевой архитектуры («Architectural Framework Rev 2»), инфраструктуры (обзор использования вычислительного, сетевого доменов и домена гипервизора с примерами), интерфейсов и уровней абстрагирования, метрик качества сервиса, переносимости и тиражируемости, управления и оркестрации. Кроме того, в нем рассматриваются вопросы производительности и надежности, безопасности и защиты, а также архитектура виртуальных сетевых функций (http://docbox.etsi.org./ISG/NFV/Open/).

В ЧЕМ ВЫГОДА?

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

Кроме того, NFV обеспечивает быстрое масштабирование сервисов, возможность использования ПО для получения прибыли, применение недорогих стандартных серверов вместо сетевого оборудования, повышение операционной эффективности, оптимизацию сети в реальном времени, экономию электроэнергии за счет консолидации нагрузки (см. Рисунок 2). Новые сетевые функции (Virtual Network Function, VNF) могут разрабатывать небольшие компании, а это способствует инновациям.

Рисунок 2. Основные факторы, стимулирующие развертывание NFV (по данным отчета Infonetics Researсh «SDN and SDN Service Provider Survey», март 2014 года).

NFV помогает сократить операционные расходы, но сама по себе не упрощает операции — это достигается лишь в сочетании с автоматизацией и SDN (см. статью автора «SDN и другие» в июньском номере «Журнала сетевых решений/LAN» за 2014 год). Тем не менее ее основное достоинство — не экономия затрат, а гибкость. В NFV функциональность сети реализуется с помощью стандартных технологий ЦОД и переносится на уровень ПО, что позволяет избавиться от инерции аппаратных процедур. Кроме того, упрощается реализация отказоустойчивых схем и ускоряется внедрение инноваций в сетях и сервисах.

По сути, NFV — это методология, новый подход, причем не только технологический, но и организационный. Он предполагает не просто замену существующего сетевого оборудования на стандартные серверы, а обращение к гораздо более сложным процедурам и процессам. Чтобы решиться на внедрение данной методологии, оператор должен по-новому выстроить свою деятельность, да и сам переход от ее лабораторного тестирования к реальному использованию и получению прибыли от внедрения остается нетривиальной задачей, подчеркивает Юрий Гиттик. При миграции переход от существующей сетевой инфраструктуры к NFV может представлять значительные трудности, как и изменения в системах управления, OSS/BSS.

Между тем для традиционных операторов внедрение NFV — вопрос выживания. Большое количество узкоспециализированного и дорогого в обслуживании оборудования мешает им быстро внедрять и монетизировать инновационные услуги с приемлемыми капитальными и эксплуатационными расходами, затрудняя конкуренцию с провайдерами услуг (см. статью Александра Бриткина «NFV и пример ее применения для оператора связи» в октябрьском номере «Журнала сетевых решений/LAN» за 2014 год). Реализация NFV могла бы предотвратить перетекание доходов к новым сервис-провайдерам, развертывающим свои услуги «поверх» операторской инфраструктуры. Последние заинтересованы в сотрудничестве с традиционными операторами, поскольку публичный Интернет не гарантирует того качества сервиса, которое необходимо для предоставления некоторых видов услуг корпоративного уровня.

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

УПРАВЛЕНИЕ И ОРКЕСТРАЦИЯ

Модель архитектуры NFV пока только обсуждается. Отраслевая организация OPNFV (http://www.opnfv.org) намерена взаимодействовать с Европейским институтом телекоммуникационных стандартов (European Telecommunications Standards Institute, ETSI) и использовать элементы Open Source (см. Рисунок 3). Изначально области интереса OPNFV охватывали аппаратные платформы (вычислительные ресурсы, СХД и сетевое оборудование), слой виртуализации, виртуальные вычисления, сети и ресурсы хранения данных, а также средства управления виртуализированной инфраструктурой. Однако более важное значение могут иметь оркестрация и управление более высокого уровня (Management and Orchestration, MANO). Многие операторы не торопятся с внедрением NFV именно потому, что ряд вопросов, связанных с MANO, все еще остаются открытыми.

Рисунок 3. Отраслевая организация OPNFV будет заниматься интеграцией, тестированием и валидацией компонентов Open Source для создания платформы NFV операторского класса.

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

Классическая сетевая модель предусматривает три «плоскости»: данные, контроль и управление. «Вся идея SDN состоит в том, чтобы изменить пропорции между двумя последними — плоскостями управления более низкого и высокого уровня. Все больше функций будут переходить на уровень контроля и становиться программируемыми и автоматизируемыми, — рассказывает Юрий Гиттик. — Цель — не в конфигурировании или программировании сетей, а в программировании сервисов с привлечением автоматизации».

При этом существуют два основных подхода. Согласно первому, протоколы плоскости контроля заменяются на API в центральном контроллере SDN, а механизмы форвардинга в плоскости данных сводятся к простым операциям в коммутаторе SDN. Это предполагает замену существующего оборудования. При втором подходе SDN дополняет существующие технологии: для оптимизации производительности вводятся дополнительные операции управления, а для создания новых сервисов используются программные средства, в результате существующая сеть становится более программируемой. Большинство операторов и вендоров оборудования поддерживают первый подход, а второй применяется в исследовательских организациях.

РАСПРЕДЕЛЕННАЯ МОДЕЛЬ И vCPE

Чаще всего функции NFV размещаются централизованно — в ЦОД или на сетевых узлах (в точках присутствия оператора — POP), что, согласно документу «NFV Whitepaper», вовсе не обязательно. Распределенная модель (Distributed NFV, D-NFV) позволяет размещать их в любом месте, контролируемом сервис-провайдером. В том числе и на площадке клиента — в сетевых устройствах, служащих точкой демаркации сети оператора и пользователя услуг.

В традиционной модели развертывание новых сервисов нередко требует установки дополнительного оборудования у клиента (Customer Premises Equipment, CPE), а это — «головная боль» для оператора. Виртуализация сетевых функций предполагает перенос функциональности в точку присутствия (Point of Presence, POP) или в ЦОД оператора. Специфические устройства разных вендоров с их функциями (оптимизация WAN, межсетевое экранирование и др.) заменяются на устройства CPE следующего поколения — vCPE, работающие во взаимодействии с виртуализированными функциями в сети. vCPE объединяет две сущности — клиентское устройство и функциональность в сети оператора (см. Рисунок 4).

Рисунок 4. vCPE — это физическое оборудование и виртуальные устройства на площадке клиента и в ЦОД провайдера или в облаке. Причем у провайдера может отсутствовать физическая часть, а у клиента — виртуальная.

Индивидуальные устройства CPE заменяются на «виртуальное» сетевое решение, используемое несколькими клиентами (multi-tenant), причем для реализации vCPE необязательно даже внедрять виртуализацию (именно такими были первые версии) — виртуальность в данном случае означает разделение ресурсов между несколькими клиентами.

В современном понимании NVF виртуализация означает перенос функций в сеть. NFV значительно упрощает реализацию клиентского оборудования. На площадке клиента остаются лишь некоторые функции, «не переносимые» в сеть провайдера, — например, шифрование трафика, оптимизация WAN, контроль QoS. Кроме того, сетевые функции разделяются на две большие категории: функции, отвечающие за работу сети, в частности мониторинг производительности, и дополнительные сервисы (Value-Added Services, VAS), такие как VolP, FW, маршрутизация у клиента и пр. Последние нередко имеет смысл реализовать на стороне клиента. При распределении функций между CPE и оборудованием в точке присутствия или в ЦОД операторам приходится учитывать требования регуляторов и экономические соображения. Иначе говоря, функции VNF размещаются там, где это наиболее выгодно и оптимально.

Основные драйверы внедрения vCPE — перспектива ускоренного развертывания новых сервисов, реализация новых возможностей без замены оборудования у клиента, вытекающее из этого сокращение капитальных и операционных затрат, более простое управление CPE и объединение в одном устройстве сразу нескольких функций. А SDN должна позволить гибко объединять несколько элементарных функций в группы.

Рисунок 5. Архитектура vCPE в спецификации ETSI NFV ISG: виртуальное устройство vCPE реализует набор функций с помощью виртуальных машин, а физическое устройство pCPE с поддержкой SDN находится на площадке клиента. Возможны разные варианты размещения vCPE.

vCPE — развивающийся подход, предусматривающий разные варианты реализации. Между тем до сих пор нет единого определения vCPE, а ETSI и Broadband Forum продолжают работу над соответствующими стандартами (см. Рисунок 5). Возможны три модели: простое физическое оборудование CPE у клиента (pCPE) и централизованная виртуальная часть у провайдера (vCPE); распределение функций между CPE и ЦОД провайдера; перенос к клиенту и физической, и виртуальной составляющей (pvCPE) (см. Рисунки 6 и 7). CPE может быть реализовано по модульному принципу с выбором требуемой функциональности или как единое интегрированное устройство с заданной функциональностью. pCPE и vCPE могут быть слабо или тесно связанными — например, взаимодействовать по некоему протоколу управления. Это открывает разные возможности для «программируемости» и автоматизации.

Рисунок 6. Варианты виртуализации и размещения vCPE.

Рисунок 7. Для размещения функций vCPE тоже предусмотрены три разных варианта.

Если некоторые сетевые функции имеет смысл виртуализировать на площадке клиента, то логично установить там стандартный сервер и запустить на нем соответствующие виртуальные машины (ВМ). Однако, поскольку через такой сервер будет проходить весь трафик, он должен быть достаточно мощным. Для этой цели RAD разработала программно-аппаратное решение. Ряд функций (Forwarding, Traffic Shaping и др.) есть смысл вывести на аппаратный уровень, поскольку их программная реализация оказывается дороже или ведет к снижению энергоэффективности. На программный уровень (ВМ) можно вынести функции маршрутизации, диагностики и тестирования, а в виде приложений реализовать межсетевое экранирование, шифрование, оптимизацию WAN, IP-телефонию. Архитектурный подход vCPE позволяет легко модернизировать клиентские системы. Программная функциональность VNF может наращиваться с помощью приложений из магазина D-NFV App Store, разрабатываемых разными вендорами.

Архитектура сетевого интерфейсного устройства в модели D-NFV может включать в себя оборудование NTU (как часть сетевой инфраструктуры), гипервизор KVM и приложения в ВМ, такие как межсетевой экран (см. Рисунок 8), причем ВМ могут обрабатывать лишь часть трафика, например отдельные VLAN. Управление такой системой осуществляется из сети провайдера — оркестрация охватывает не только функциональность клиентского оборудования, но и конфигурирование сети. VNF в ВМ могут быть постоянно работающими или запускаться в случае необходимости — при наступлении определенных событий или для тестирования и выявления проблем в сети. Такой вариант называется децентрализованным (Centerless D-NFV), но часть функций VNF может быть перенесена в сетевые узлы или в ЦОД провайдера.

Рисунок 8. Функции VNF могут развертываться на стороне клиента в виртуализированном устройстве CPE.

Ключевые преимущества D-NFV — гибкое развертывание сервисов и контролируемые расходы. Опытная эксплуатация дает оператору возможность опробовать новый подход и проанализировать его пригодность. NFV и SDN достаточно трудно обосновать экономически, поэтому развертывание NFV на площадке клиента позволяет начать с «низкого старта», внедрить новые решения с минимальными начальными инвестициями и отказаться от них в случае неудачи без особого ущерба. Наконец, в этом случае не требуется замена OSS/BSS.

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

Сергей Орлов — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: sorlov@lanmag.ru.