Как правило, поставщикам услуг требуется примерно 6 месяцев на развертывание текущей услуги и около 18 месяцев на создание и развертывание новой услуги. Именно это мы называем недостатком оперативности. Низкая оперативность объясняется необходимостью выполнения в рамках этой задачи большого количества шагов. Еще больше усугубляет ситуацию аппаратная архитектура услуг.

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

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

Неужели более эффективного подхода не существует? Такой подход есть — это виртуализация сетевых услуг. Именно ей суждено доминировать на рынке завтрашнего дня.

With Distributed NFV, service providers can now compete on more than simply the lowest price for a given network service, because the agility gap is essentially eliminated, thus enabling a powerful new differentiator – Time-To-Market (TTM).

Виртуализация сетевых функций (NFV) спешит на помощь

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

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

Где разместить VNF физически?

Итак, сетевые услуги перешли от отдельных аппаратных устройств к приложениям VNF, работающим на серверах. Где лучше разместить эти серверы? VNF могут работать на любых серверах. Имеет ли значение их физическое расположение? Да, имеет. Обсудим это подробнее.

Существует три стандартные модели развертывания VNF: распределенная, централизованная и гибридная (см. схему ниже). Распределенная модель предусматривает размещение VNF на границе сети (как правило, на территории клиента). Централизованная модель предусматривает размещение VNF в одной точке, например в ЦОД. Такой подход позволяет добиться значительной экономии ресурсов Webscale. Гибридная модель представляет собой комбинацию двух первых моделей: здесь некоторые VNF размещаются на границе сети, другие — размещаются централизованно.

Распределенная NFV (D-NFV) предлагает целый ряд преимуществ

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

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

Отказоустойчивость: некоторые сетевые функции, такие как IP-PBX, должны быть доступны даже в случае сбоя подключения к глобальной сети. Если эту сетевую функцию разместить в удаленном ЦОД, в случае сбоя сетевого соединения предприятие не сможет выполнять не только местные телефонные звонки, но и звонки внутри офиса!

Производительность: некоторые сетевые функции работают эффективнее на границе сети — например, комплексное управление качеством обслуживания (QoS) и гарантированное разграничение по соглашениям об уровне обслуживания (SLA).

Экономические показатели: хотя некоторые VNF можно перенести в централизованное хранилище с помощью избыточных соединений WAN, это влечет за собой дополнительные расходы, которые могут свести на нет преимущества размещения сетевых функций в ЦОД Webscale.

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

Как видите, некоторые VNF лучше размещать на границе сети. Зачастую это означает размещение на территории заказчика на сервере, управляет и владеет которым поставщик услуг или само предприятие. Поставщики услуг могут развернуть устройство Ethernet-доступа (EAD), оснащенное инфраструктурой виртуализации сетевых функций (NFVI), например отмеченное наградами новое решение  3906mvi Service Virtualization Switch, включающее необходимое серверное оборудование x86 и базовое ПО для размещения VNF.

Это даст поставщикам услуг возможность развертывать бизнес-услуги Ethernet, сертифицированные по стандарту MEF CE2.0, в течение одного дня и предлагать дополнительные сетевые услуги на той же платформе для загрузки, обновления, масштабирования и управления размещенными сетевыми услугами. Например, поставщик услуг может установить оснащенное сервером EAD, запустить бизнес-услугу Ethernet, а затем — быстро и безопасно загрузить виртуальный маршрутизатор, брандмауэр и блок шифрования.

Internal Ciena estimates put the market size for D-NFV services to be upwards of US$60 billion when network services such as managed IP/VPN, managed security, WAN optimization, SD-WAN, and SIP trunking are combined into an addressable market.

Что поставщики услуг думают о D-NFV?

Согласно результатам четвертого ежегодного глобального опроса поставщиков услуг SDN/NFV, проведенного Майклом Ховардом (консультант по операторским сетям и старший директор IHS Markit по исследованиям), поставщики услуг считают, что размещение VNF на границе сети сулит ряд важных преимуществ. Как показано ниже, почти 90% респондентов считают, что наибольшую выгоду NFV может принести в рамках vE-CPE (виртуальное предприятие — оборудование на территории клиента) для бизнеса — то есть, на базе рассмотренной нами выше схемы распределенной NFV (D-NFV). Такой результат вполне понятен, если учесть все приведенные выше причины размещения некоторых VNF на границе сети.

Итак, некоторые VNF следует размещать на границе сети, но насколько же велик рынок услуг D-NFV? Это зависит от того, сколько VNF вы предложите в незанятом сегменте рынка распределенных услуг, ведь некоторые VNF можно разместить в любой точке сети. Согласно внутренним подсчетам Ciena, после выхода на рынок таких сетевых услуг, как управляемые IP/VPN, управляемые средства безопасности, оптимизация WAN, SD-WAN и SIP-транкинг, его объем составит примерно 60 млрд долларов США. Вот почему поставщики услуг уделяют так много внимания услугам NFV — это практично и экономически выгодно.

Уникальная природа D-NFV требует специализированного решения

При централизованном размещении всех VNF (например, в крупном ЦОД) соединения между различными VNF, регуляторами и серверами в одном здании и в одной физической локальной сети относительно самодостаточны. Тем не менее, при размещении VNF на границе сети необходимо использовать WAN, и, следовательно, решать проблемы, связанные с расстоянием, задержками, безопасностью и производительностью сети. В локальных сетях эти проблемы встречаются гораздо реже. Как видите, природа D-NFV имеет весьма уникальный характер. При широком развертывании виртуальных услуг на границе она требует специализированного решения.

 

 

Предприятия ожидают от виртуальных сетевых услуг как минимум не меньшей — по сравнению с аппаратными решениями — безопасности и производительности, поэтому проблемы WAN в рамках решения D-NFV так или иначе необходимо решить. Инструменты и программное обеспечение с открытым исходным кодом, первоначально разработанные для централизованного использования, использовать с D-NFV бывает непросто, они требуют определенной оптимизации. Новое ПО Ciena D-NFVI ориентировано именно на решение проблем, связанных с особенностями D-NFV.

Действующий образец D-NFV на базе решений разных производителей на выставке MEF16 в Балтиморе

Посетители MEF16 могут испытать на практике опытную модель «Регулирование услуг разных поставщиков на базе открытых API для обеспечения активации услуг, производительности, мониторинга и NFV». Выставочный образец решения демонстрирует регулирование управления производительностью с активацией услуг Ethernet операторского класса в WAN на базе решений разных производителей с поддержкой SDN и NFV. Эта опытная модель, реализованная силами CenturyLink в сотрудничестве с Ciena, нашим подразделением Blue Planet и RAD, представляет возглавляемую CenturyLink инициативу с поддержкой открытого исходного кода и решений разных поставщиков, направленную на разработку API и адаптеров ресурсов на платформе MEF LSO для автоматизации комплексной доставки оперативных гарантированных регулируемых услуг на базе NFV и Ethernet операторского класса.

На вручении наград MEF Excellence Awards в последний день выставки эта опытная версия, реализованная специалистами Ciena, CenturyLink и RAD, заняла третье место среди всех представленных на мероприятии экспериментальных решений.

Специалисты Ciena демонстрируют опытную модель на MEF16

Конкурентная борьба: не цены, а скорость выхода на рынок

Поставщики услуг ориентированы на открытые экосистемы. Такие экосистемы предоставляют широкий выбор, используют лучшие технологии и работают на базе более диверсифицированной и надежной цепи поставок. На одной из недавних выставок мой коллега точно подметил: «Игнорируя открытый подход, мы даем повод игнорировать себя». Думаю, он прав. Открытый подход получает все большее распространение, и, учитывая преимущества этой парадигмы, удивляться этому не приходится. Будучи потребителем, я всегда ценю наличие широкого выбора товаров, будь то хлебобулочные изделия или автомобили. Вполне логично, что того же ждут и поставщики услуг, не так ли? В Ciena мы уже несколько лет реализуем этот подход в нашей сетевой архитектуре OPn, он прослеживается во всех наших решениях, включая новое решение D-NFV, разработанное специально для использования с распределенной NFV.

Мы предлагаем виртуальные сетевые услуги на базе реального решения D-NFV. Хотите узнать больше? Свяжитесь с нами.