Как показала конференция SDN&NFV Russia 2016, операторы делают первые практические шаги к виртуализации инфраструктуры, активно тестируют решения на базе концепции NFV (Network Functions Virtualization) с дальнейшими планами по построению «телеком облака» (Telco Cloud). При этом, чем глубже они вникают в процесс, тем больше препятствий встречают на своем пути. Много где пишут на тему неготовности технологий к коммерческой эксплуатации, отсутствия стандартов, непонимания экономической эффективности, но мало кто поясняет, что конкретно имеется в виду? В этой статье постараюсь сформулировать десять основных причин, почему мы до сих пор не видим широкого распространения технологий NFV.

Статья отражает личное мнение автора, которое может не совпадать с мнением всей редакции SDNBLOG

Что такое NFV? По мнению вендоров, виртуализация сетевых функций должна кардинально изменить принципы построения операторских сетей. Концепция предлагает «перенести» элементы сети оператора со специализированных платформ на «стандартное» оборудование на базе архитектуры x86 (или может ARM выстрелит, кто знает?).

Gartner-hype-cycle-July2015
Источник: www.gartner.com

Каждый год Gartner публикует так называемый “Hype Cycle”. По данным отчета за 2015 год, концепция NFV уже прошла «пик завышенных ожиданий» и теперь стремится к «нижней точке разочарований» (см. рис.). Перебравшись с красивых слайдов презентаций в тестовые лаборатории, технология продемонстрировала как потенциальные преимущества, так и свою сырость. Несмотря на серьезный потенциал, существует ряд причин, почему мы до сих пор не видим широкого распространения NFV.

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

#1. Необходимость комплексных организационных изменений

TMForum_report_2015_when_will_nfv_cross_the_chasm
Источник: www.tmforum.org

Расширенное понимание концепции NFV заключается в изменении принципов предоставления сервисов и, как следствие, функционирования сети.  Реализовать подобные масштабные преобразования возможно только с помощью создания единого «центра компетенций», в который входят эксперты компании различных специальностей – ИТ-подразделения, R&D, маркетинг, продажи и пр. При этом необходима поддержка процесса со стороны высшего руководства. Это процесс небыстрый и требующий вовлеченности множества подразделений.

По данным отчета TM Forum (см. рис.), необходимость комплексной организационной трансформации — важнейший фактор, тормозящий адаптацию концепции NFV.

Инженеры разных подразделений (ИТ, сетевые инженеры, телеком) должны найти общий язык друг с другом, а в это пока слабо верится. Программисты должны будут научиться писать приложения под новую архитектуру, маркетинг – понять, какие сервисы могут быть наиболее привлекательны и подготовить рынок к таким услугам, а продавцы — научиться их продавать. Это всё конечно упрощенно, но суть должна быть понятна.

Зачем это нужно? Почему нельзя просто взять и виртуализировать пару сетевых сервисов и остановиться на этом? Можно, но ощутимого экономического эффекта от этого не будет. Виртуализация сетевых функций – это всего лишь один из множества шагов на пути трансформации Телеком-оператора (продавца каналов связи) в провайдера комплексных услуг, который потенциально может предоставить из своего облака практически любой сервис по запросу в автоматическом режиме. Когда речь идет о необходимости организационной трансформации, имеется в виду глобальная стратегия развития оператора, а не замена какой-то одной специализированной аппаратной платформы на стандартный сервер.

#2. Множество систем управления и наследие «legacy» платформ

ИТ-системы операторов строились десятилетиями. За это время появилось множество дублирующих друг друга систем – управления и мониторинга, средств информационной безопасности и др. Многие из них вообще относятся к разным поколениям сети. Объединение всех этих сущностей в нечто централизованное – долгий и поэтапный процесс, который иногда называют «выравниванием ИТ-ландшафта».

Зачем этим заниматься? Если оператор задается целью рано или поздно построить Telco Cloud, то одним таким облаком в масштабах страны он вряд ли обойдется. Потом возможно получится так, что интегрировать каждое отдельное облако с множеством кусочных ИТ-систем будет стоить таких денег, что об этом даже лучше не думать.

Второй вопрос связан с системами, которые стало модно обозначать приставкой «legacy» (в переводе с англ. «устаревшие»). Еще 2-3 года назад они были верхом технического прогресса, а тут вдруг в один момент устарели? Конечно нет, и наиболее вероятно эти системы не будут заменены «NFV-аналогами» до тех пор, пока не потеряют актуальность или не закончится жизненный цикл оборудования. Это не стоп-фактор для внедрения NFV, а скорее совет поставщикам: «не предлагать модернизировать то, что исправно работает и соответствует потребностям оператора».

#3. Нет понимания экономической эффективности технологий

Это, пожалуй, основной стоп-фактор, при обсуждении которого больше вопросов, чем ответов. Если бы все понимали, насколько экономически выгодна технология, неужели мы до сих пор бы не видели её в коммерческой эксплуатации? Насколько эта эффективность выражается в конкретных цифрах, относительно конкретного кейса применения? И есть ли на данный момент жизнеспособные кейсы?

Есть замечательная цитата на эту тему (к сожалению, не помню чья):

The best technology doesn’t win, the best business case does!

Пока непонятно, откуда взяться этому глубокому пониманию, если практически нет лучших мировых практик внедрения технологии? Оператор AT&T – главный пионер в области SDN и NFV, к концу 2015 года ставил планы по виртуализации лишь 5% своей инфраструктуры. Что же говорить об остальных?

Вопросов масса, но это не значит, что нужно ждать появления этих best practices. Никто, кроме самого оператора, не сможет качественно оценить затраты на «клаудификацию» собственной инфраструктуры и её дальнейшую поддержку. Виртуализация всего, что можно виртуализировать – не самоцель, а средство достижения цели. Заказчик должен четко осознавать, зачем ему нужна технология и каких конкретно финансовых показателей он сможет добиться с её помощью. Хотя всё вышесказанное и достаточно очевидно, сделать это гораздо сложнее, чем говорить об этом.

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

#4. Стратегии крупных вендоров

Эксперт одного из операторов связи сравнил поведение крупных вендоров с басней Крылова «Лебедь, щука и рак». К сожалению, так было, так есть и так будет. Вот лишь несколько основных факторов, тормозящих развитие практически любой новой технологии:

  • Защита существующей продуктовой линейки. Ни один крупный производитель сетевого оборудования не заинтересован в том, чтобы то, на чем он зарабатывал последние 20-30 лет (продажа «коробок»), вдруг перестало приносить ему доход. Субъективно, это один из важнейших факторов недостаточно быстрого развития NFV, а SDN — еще в большей степени;
  • Попытки монополизации рынка. Каждый крупный вендор стремится к тому, чтобы клиент купил у него всё, что тот может продать. В итоге заказчик получает «vendor lock-in», а это то, от чего он и хочет избавиться при переходе на архитектуру NFV;
  • Собственное видение развития технологий. Как грамотно заметил технический директор одного из российских разработчиков в области SDN/NFV, «выбирая одного из крупных поставщиков, вы покупаете не только конкретное решение, но и видение развития технологий этого вендора со всеми вытекающими последствиями».

Список можно продолжать и дальше, и у каждого обязательно найдется, что в него добавить (добро пожаловать в комментарии). Суть от этого не меняется: «…а воз и ныне там!»

#5. Поддержка мульти-вендорного и многоуровневого решения

Поддержка мульти-вендорного решения и так приносит немало головной боли. К сожалению, это устраняется только путем перехода на одного поставщика – единую точку входа для заказчика при обращении в тех. поддержку. Сложные взаимодействия поставщиков могут серьезно повлиять на SLA (Service Level Agreement) и привести к перекладыванию ответственности при расследовании инцидентов в мульти-вендорном решении. Очевидный, но тем не менее очень важный фактор, который нужно учитывать. Особенно если поставщик идет вместе с партнерской экосистемой.

Одно из возможных решений этой задачи – подписание многостороннего SLA производителями всех компонент в рамках виртуальной инфраструктуры, чтобы не возникла ситуация игры в «пинг-понг» между вендорами. Перекладывание ответственности – знакомая ситуация, из-за которой оператор несет серьезные финансовые и репутационные потери.

По поводу многоуровневого решения… Создание «телеком облака» и централизация управления всем парком систем добавляет новые уровни управления – оркестрация, координация выделения ресурсов, управление виртуальными функциями нескольких поставщиков – все те блоки, обозначенные в модели ETSI NFV MANO (см. следующий пункт). Цитируя эксперта одного из крупнейших российских операторов, «каждый из этих блоков соревнуется с другими за право принести максимальное количество проблем».

К этому можно добавить, что «создание единого Telco Cloud» с централизацией управления всем, что только можно в сети оператора, звучит утопично. Таких облаков скорее всего будет несколько, соответственно, количество задач увеличится пропорционально.

#6. Отсутствие стандартов NFV

Перейдем теперь более техническим моментам и поговорим о тех самых «блоках», о которых шла речь в предыдущем пункте.

ETSI NFV MANOНа данный момент, единственным ориентиром при построении платформ на базе NFV является референсная архитектура NFV Management and Orchestration (MANO), разработанная ETSI. Модель включает концептуальные блоки, при этом их реализация остается на откуп поставщикам решений. Интерфейсы взаимодействия между блоками пока не стандартизированы. Как следствие, множество различных толкований архитектуры MANO и подходов к реализации модели. Схему, подобную той, что на рисунке, можно увидеть в презентации практически любого вендора, с заполнением соответствующих блоков продуктами этого поставщика и партнерской экосистемы.

Многие участники рынка жалуются на медленную работу ETSI по разработке стандартов и недостающие блоки. Дабы «помочь» в решении этих вопросов, с каждым днем появляется всё больше сообществ, «работающих во благо open source» и желающих что-нибудь стандартизировать. Например, только в этом году появилось целых два новых проекта – OPEN Orchestrator (OPEN-O) и ETSI Open Source MANO (OSM). В будущем будет видно, насколько это в действительности поможет в формировании стандартов.

Кроме вышеперечисленных организаций, в процессе участвует основной стандартизирующий орган — IETF, консорциумы MEF и TMForum, а также сообщество OPNFV. Международный союз электросвязи (или ITU-T) как обычно опаздывает.

Теперь о России. В ближайшие 2-3 года российских стандартов в области NFV не предвидится. Регулирующие органы ожидают появления международных документов (в основном, от ITU-T), после чего нужно еще до двух лет, чтобы разработать локальные регуляторные и другие нормативные акты.

Появление международных стандартов ожидается приблизительно к 2018 году… В России процесс стандартизации в области SDN/NFV не начат. Его инициация произойдет после того как будут приняты основополагающие документы международных стандартизирующих организаций. Но, до этого времени может быть разработана некая отраслевая концепция по внедрению технологий SDN и NFV на сетях связи российских операторов.

Владимир Ефимушкин, заместитель генерального директора по научной работе, ЦНИИС (Центральный Научно-Исследовательский Институт Связи)

Важная и пока не решенная задача применения технологий SDN и NFV в России – адаптация требований СОРМ (система технических средств для обеспечения функций оперативно-розыскных мероприятий) под стандарты SDN и NFV. Например, требования регулятора запрещают перенос точки съема трафика, что ограничивает возможности миграции виртуальной функции в случае распределенной инфраструктуры. На эти вопросы пока тоже нет конкретных ответов, одни лишь разговоры (см. Грядущие проблемы СОРМ в SDN-сетях).

#7. Несовместимость решений

Несовместимость напрямую связана с отсутствием стандартов (хотя мы видим, что и при их наличии во многих других областях, проблема остается). Причем она возникает сразу на нескольких уровнях, начиная даже с самого, казалось бы, изученного – управления инфраструктурой и виртуальными ресурсами. Большинство вендоров используют OpenStack в качестве менеджера инфраструктуры (VIM, Virtualized Infrastructure Manager в модели MANO) для NFV-платформы. Причем это коммерческая реализация OpenStack. Множество индивидуальных доработок приводит к тому, что запустить виртуальную функцию (VNF) на сторонней платформе вызывает массу сложностей. Это в корне противоречит идеи NFV, которая предполагает некую абстракцию вычислительных ресурсов от виртуальных сетевых функций. В подтверждение этого тезиса, тестирование лаборатории EANTC совместимости NFV-решений.

Мы наблюдали массу проблем совместимости NFVI, несмотря на тот факт, что все NFV-платформы основаны на OpenStack.

Карстен Розенховель, директор EANTC.

Второй момент связан с виртуальными функциями, а точнее с т.н. Element-менеджером (EMS) для этих функций. Основная задача Element Manager транслировать специфичные для VNF параметры в понятные VNF-менеджеру. Говоря простым языком, предполагается, что все запущенные на платформе сетевые функции будут управляться через единый интерфейс оркестратора (VNF Orchestrator) без необходимости конфигурации напрямую с помощью CLI или WEB-интерфейса. Для того, чтобы это было возможно, необходимо чтобы поставщик виртуальной функции предоставил определенный API, понятный стороннему оркестратору. Бóльшая часть существующих сегодня VNF не имеют Element Manager или не поддерживают сторонний VNF Manager.

Еще один немаловажный фактор – отсутствие стандартных интерфейсов взаимодействия между блоками модели MANO. На схеме из предыдущего пункта можно увидеть подписи Ve-Vnfm, Vnfm-Vi, Or-Vnfm, Or-Vi и др. Они обозначают т.н. «референсные точки», и пока что эти интерфейсы никак не стандартизированы. Всё есть в виде драфтов, которые можно найти на сайте ETSI. Каждый вендор реализует интерфейсы по-своему со всеми вытекающими отсюда последствиями.

#8. Функциональная готовность коммерческих продуктов

Маркетинг – великая сила! На бумаге всё гладко: клиент получает массу преимуществ, при этом его затраты стремительно идут вниз. При углубленном изучении, оказывается не всё так замечательно. Операторы указывают на недостаточный уровень функциональной готовности коммерческих продуктов. Решения часто не соответствуют техническим требованиям для применения в сети оператора связи, при этом даже многое из указанного в презентациях, присутствует лишь в Roadmap вендоров вплоть до 2020 года.

Кроме очевидных недостатков, связанных со стандартизацией и совместимостью, нужно отметить ряд технических моментов, на который стоит обратить внимание:

  • Недостаточная для оператора производительность NFV-решений, о которой поговорим чуть подробнее;
  • Архитектурные особенности. Некоторые решения изначально проектировались для работы в корпоративных ЦОД. На пике бума технологий NFV, эти платформы были различным образом «подкорректированы», возможно, немного расширен функционал и добавлена приставка «Carrier Grade». И теперь они позиционируются для построения Telco Cloud. Напрашивается вопрос: за счет чего они вдруг стали платформами “carrier grade” класса?
  • Создание т.н. «цепочек сервисов» (Service Function Chaining, SFC), т.е. определенной последовательности из сетевых функций, через которые должен пройти трафик. Стандартов в этой области тоже пока нет. На данный момент существует несколько драфтов, основной – NSH (Network Service Header). Но, скорее всего в существующих решениях это будет какая-то проприетарная реализация;
  • При использовании OpenStack в качестве платформы для управления ресурсами (VIM в архитектуре MANO), получаем как все его преимущества, так и недостатки (см. 6 ограничений OpenStack. Построение NFV платформы в сети оператора). British Telecom уже предложил пути обхода этих недочетов, но это лишь часть ограничений;
  • Вопросы интеграции с OSS/BSS системами и безопасности в NFV-средах.

Список можно продолжать, но важно отметить, что эти вопросы не будут решены без активного участия операторов.

#9. Недостаточная производительность NFV-решений

Чуть более подробно расскажу лишь об одном из ключевых факторов – производительности. Под производительностью имеется в виду скорость обработки трафика в виртуальных сетевых средах и пропускная способность самих виртуальных функций. В первом случае, основные «узкие места» — сетевой стек Linux виртуальной машины и виртуальный коммутатор.

Эти задачи достаточно успешно решаются с помощью различных методов «обхода» гипервизора и kernel space в Linux. Наиболее популярные средства — Intel DPDK, SR-IOV, TCP offload и др. Они имеют определенные ограничения, но на сегодняшний день их использование должно стоять в графе «обязательные требования» при составлении ТЗ.

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

Кроме вышесказанного, есть еще один важный момент. Очевидно, что не все сетевые функции одинаковые! Например, сложная обработка пользовательского трафика (глубокий анализ трафика, шифрование и др.) на «стандартном сервере» без использования аппаратных средств – достаточно неблагодарное занятие.

 «Бонус»

В завершение списка всё-таки добавлю ещё один фактор, который, по мнению агентства CNews Analytics и моему личному, является одним из основополагающих в России.

#10. Недостаток информированности и внутренней экспертизы в России

Отчет Gartner, на который идет ссылка в начале статьи, в большей степени отражает ситуацию за рубежом. Рискну заявить, что в России концепция NFV еще даже не достигла «пика завышенных ожиданий». Если не брать крупнейших российских операторов, в большинстве своем российская Телеком-отрасль находится на стадии изучения технологии.

Конференция SDN&NFV Russia 2016 продемонстрировала серьезный прогресс, произошедший в области NFV за год, но количество участников (по подсчетам, в мероприятии приняли участие около 70 человек) явно указывает на только формирующийся интерес российской аудитории.

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

CNews_analytics_informirovannost_o_sdn_nfv
Источник: www.cnews.ru

В конце 2015 года, агентство CNews Analytics провело опрос о перспективах использования SDN и NFV в России. В интервью приняли участие ведущие российские операторы связи, сервис-провайдеры, вендоры и дистрибьюторы. По данным издания, 30% вендоров считают одной из причин медленной адаптации SDN и NFV в России – недостаточную информированность участников рынка об этих технологиях и четкого понимания своих потребностей.

Заключение

Любая новая технология должна пройти цикл зрелости, причем созреть должна не только сама концепция, но и рынок. И, субъективно, приведенные здесь причины отражают это высказывание. Пять первых пунктов связаны с участниками рынка, оставшиеся – с техническими ограничениями концепции.

Спасибо всем, кто смог дочитать до сюда. Статья написана не для того, чтобы отбить всяческое желание присматриваться к концепции NFV, а скорее наоборот – ускорить прохождение того самого «пика завышенных ожиданий» и взглянуть на вещи реально. Чем раньше мы почувствуем все подводные камни, тем быстрее сможем адаптировать технологию к применению в реальной сети.

Надеюсь, вы узнали что-то полезное и уже близки к «нижней точке разочарования», после которой, если верить Gartner, все вместе начнем взбираться на «холм просвещения» (Slope of Enlightenment).

И последняя просьба: если вам понравилась статья, поддержите проект, поделитесь ей в социальной сети. Для нас это будет стимулом продолжать бесплатно делать то, чем мы занимаемся.

Создатель проекта SDNBLOG, главный редактор. Последние 12 лет занимается всем, что связано с сетевыми технологиями, виртуализацией и облачными инфраструктурами. До 2014 года работал в ролях сетевого инженера и системного архитектора, сейчас сфокусирован на продакт-менеджменте и техническом маркетинге. Принимает непосредственное участие в создании коммерческих продуктов и решений на базе SDN и NFV. ИТ-энтузиаст и адепт инновационных технологий

1 КОММЕНТАРИЙ

  1. Спасибо, Дима. Очень интересная и исчерпывающая статья про сложности и подводные камни, которые могут возникнуть и, пожалуй, уже возникают в процессе внедрения технологии NFV. Концепция NFV новая и сложная, но вектор развития выбран правильный. И не стоит пугаться трудностей. Как гласит известная мудрость, дорогу осилит идущий.

ОСТАВЬТЕ КОММЕНТАРИЙ