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

 

Операторы и сервис-провайдеры рассматривают внедрение SDN как способ трансформации своих сетей, надеясь, что это позволит им увеличить доходы за счет более оперативного и качественного предоставления сервисов конечным потребителям. От тестирования и пилотных проектов они переходят к внедрению новой технологии, несмотря на остающиеся технические сложности. Так, по данным IHS Markit, 75% крупнейших мировых провайдеров развернули или планировали развернуть программно определяемые сети в прошлом году и все без исключения собираются непременно это сделать.

Различий между телекоммуникационными и ИТ-приложениями становится все меньше. Это, в частности, означает, что они развиваются в соответствии с одними и теми же принципами, а подходы используются одинаковые: виртуализация и облака. Важная тенденция заключается в том, что операторы трансформируют свои узлы связи, превращая их в центры обработки данных. Так, AT&T увеличила число ЦОДов с 74 в 2015 году до 105 в 2016-м: они должны составлять единое интегрированное облако и служить основой для реализации стратегии компании по расширению применения виртуализации.

Как с наименьшими потерями внедрить SDN, какой стратегии придерживаться при внедрении NFV и каково место оператора в облачном мире — эти и другие вопросы рассматривались в докладах Вячеслава Васина (ЦПИКС), Максима Каминского (Brain4Net) и Александра Герасимова (J’son & Partners Consulting) на секции «Сетевая виртуализация. SDN. NFV» во время проведения российского сетевого форума RUS.NET 2016.

ДВА ПОДХОДА К РАЗВЕРТЫВАНИЮ SDN

В предыдущие два года SDN активно тестировалась по всему миру, но операторы настороженно относятся к окончательному переходу на эту технологию ввиду ее незрелости. Как показывает исследование IHS Markit, двумя основными препятствиями для развертывания SDN являются отсутствие ПО операторского класса и трудности совместного использования физических и виртуальных устройств в существующей сети.

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

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

Плюсы и минусы различных подходов к внедрению SDN в сети (зеленым цветом выделены преимущества, красным — недостатки)
Плюсы и минусы различных подходов к внедрению SDN в сети (зеленым цветом выделены преимущества, красным — недостатки)

 

Как было показано в ряде исследований, для того

чтобы взять под управление 80% сетевого трафика, достаточно заменить всего лишь 20% установленного оборудования.

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

Далее встает вопрос выбора коммутатора SDN. На рынке есть как программные решения, так и аппаратные, у каждого свои плюсы и минусы. У программного — максимальная функциональность; оно позволяет использовать любое количество таблиц и правил, но это не проходит бесследно для производительности. Аппаратное решение отличается производительностью, количеством и скоростью работы портов, но здесь есть свои подводные камни. «Накладывая на это решение контроллеры, — объясняет Вячеслав Васин, — вы сразу сталкиваетесь с необходимостью организовать обслуживание нескольких таблиц, но далеко не все представленное на рынке оборудование это умеет. Из опыта ЦПИКС могу сказать, что

на сегодняшний день более-менее адекватно реализуют подход SDN только программные решения и решения на базе сетевых процессоров».

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

Новое оборудование необходимо интегрировать с существующими системами OSS и BSS. Управление смешанной сетью гораздо сложнее, чем отдельно классической либо программно определяемой сетью. Особую трудность представляет диагностирование, поскольку какие-то устройства можно диагностировать классическим образом, например посредством traceroute, а какие-то — только с помощью системы централизованного управления: настоящий взрыв мозга для системного администратора. Последний должен уметь все — профессионально разбираться в устройстве и классической сети, и SDN, хорошо понимая, что где происходит.

Среди других потенциальных проблем реализации SDN Вячеслав Васин выделяет различия в реализации протокола OpenFlow разными вендорами и разработчиками. «Мы неоднократно сталкивались с ситуациями, когда одни и те же постулаты, на наш взгляд однозначные, по-разному интерпретируются разными производителями оборудования, — отмечает он. — Кроме того, поддержка обязательной функциональности в протоколе OpenFlow не гарантирует получения идеального для вашей сети решения. Например, операторам необходимы групповые таблицы FastFailover, но они опциональны с точки зрения OpenFlow. Приходится просить вендоров вносить необходимые дополнения».

Все эти проблемные моменты следует учитывать при выборе контроллера. «Контроллер, созданный в нашем центре с нуля, мы вынуждены подстраивать для работы с конкретным оборудованием», — рассказывает Вячеслав Васин. На аппаратных коммутаторах достаточно слабая плоскость управления (control plane).

В момент старта устройства требуется закачивать тысячи или десятки тысяч правил, однако процессор control plane способен обработать только определенное количество правил за единицу времени,

поэтому контроллер должен к этому подстраиваться: запускает порцию и ждет ответа, новая порция — снова ожидание...

Таким образом, ограничиваться одним лишь ознакомлением со спецификацией не стоит — обязательно нужно проводить лабораторное тестирование и реализовывать пилотные проекты, чтобы четко понимать, насколько имеющееся решение соответствует потребностям компании. Сейчас, по мнению Вячеслав Васина, наиболее благоприятный момент для того, чтобы обратиться к разработчикам SDN-решений: при отсутствии большого наплыва покупателей они, скорее всего, сделают ту технологию, которая нужна заказчику. «Вы можете оптимально выбрать свою архитектуру. Сейчас уже есть полнофункциональное решение от российских разработчиков — это программные и аппаратные коммутаторы на нашем ПО и контроллер с набором приложений», — заключает он.

ТЕЛЕКОММУНИКАЦИОННОЕ ОБЛАКО

Как указывается в отчете HIS Market, несмотря на все препятствия для реализации SDN, 70% опрошенных операторов собираются предлагать услуги программно определяемых территориально распределенных сетей (Software-Defined Wide Area Network, SD-WAN) и внедрять соответствующие технологии виртуализации сетевых функций (Network Function Virtualization, NFV). В качестве основного проводника для доставки этих решений заказчикам они рассматривают управляемые сервисы на базе виртуализированного оборудования CPE (virtual Customer Premises Equipment, vCPE).

Максим Каминский, технический директор Brain4Net, отметил в своем выступлении, что

vCPE — самый популярный бизнес-кейс у операторов во всем мире. Однако в России он востребован в меньшей степени, так как управляемые сервисы не пользуются у нас большим спросом.

Речь идет о том, что клиент не покупает оборудование для организации связи, а получает его в аренду в рамках единой услуги от провайдера. На рынке B2C примером может служить предложение услуги доступа в Интернет вместе с предоставлением маршрутизатора в аренду. В сегменте B2B можно арендовать самое разное оборудование (межсетевые экраны, ускорители трафика и т. д.) в рамках общей услуги от провайдера.

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

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

Можно виртуализировать самые разные сетевые функции: маршрутизацию, WAN-оптимизацию, балансировку нагрузки, функции обеспечения безопасности (брандмауэры, DPI, IDP/IPS) и т. д. «Если посмотреть «под капот» любой системе IPS, мы обнаружим там обычный компьютер x86, собранный в специфичном форм-факторе, названный appliance и с ценником, раз в десять превышающим стоимость данной железки», — говорит Максим Каминский.

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

Магистральное направление развития для провайдеров телекоммуникационных услуг, по мнению Максима Каминского, — построение телекоммуникационного облака (telco cloud), когда традиционные точки присутствия (Point of Presence, POP) —

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

В англоязычной прессе эта тенденция получила название «переоборудование узла связи в ЦОД» (Central Office Re-architected as a Datacenter, CORD). Узлы связи и так наполовину заполнены серверами, потому что последние нужны для осуществления собственной деятельности провайдера: биллинга, протоколирования событий, сбора статистики и т. д.

Таким образом, у любого провайдера в течение пяти лет так или иначе появится большая инфраструктура распределенных ЦОДов. Логично будет использовать их для виртуализации сервисов, перенеся сами сетевые функции из оборудования в виртуальные машины, и таким образом обеспечить лучшие показатели по масштабированию и резервированию этих функций, экономике и, самое главное, управляемости. При этом Максим Каминский отмечает следующий нюанс: «Услуга оператора все-таки является услугой связи. Иначе говоря, одна или несколько ВМ, запущенных для обслуживания потока трафика от какого-то клиента, составляют лишь часть большой цепочки услуги. Поэтому очень важна не только возможность реализации управления виртуализацией, но и склеивание транспортных услуг с виртуальными функциями, а в дальнейшем — и с доступом к облакам либо к Интернету». Для этого необходима прозрачная интеграция ЦОДа и WAN (см. рис. 1).

Рис. 1. Организация сервиса широкополосного доступа средствами SDN и NFV
Рис. 1. Организация сервиса широкополосного доступа средствами SDN и NFV

 

Конкуренцию операторам на их традиционном поле могут составить провайдеры облачных услуг XaaS. Виртуализацию сетевых функций они пока применяют очень мало, хотя, на взгляд Максима Каминского, могли бы оказывать клиенту целый ряд новых услуг по предоставлению в аренду самих функций. Если провайдер предлагает виртуальные выделенные серверы (Virtual Dedicated Server, VDS), то, по сути, предоставляется виртуализированный колокейшн для заказчика из сегмента B2B. Зачастую, переместив в КЦОД сначала часть рабочей нагрузки, клиент потом переводит туда всю свою инфраструктуру. Соответственно, ему требуются сетевые устройства для организации выхода в Интернет и защиты своей инфраструктуры от внешних угроз, в частности межсетевые экраны. Они могут быть реализованы и предоставлены провайдером XaaS в виде виртуальных сетевых функций.

КУДА ОПЕРАТОРУ ПОДАТЬСЯ?

Операторы связи активно ищут свое место в быстро меняющемся мире. Однако, долго примеряясь и раскачиваясь, они могут лишиться и своей исконной монополии на «трубу», то есть на магистральные сети. Собственно говоря, напомнил в своем выступлении Александр Герасимов, директор департамента ИТ и облачных сервисов в J’son & Partners Consulting, такая угроза вполне реальна. Как отмечает Джон Хэмбо (аналитик TeleGeography) в интервью Bloomberg, компании Amazon, Facebook, Google и Microsoft имеют столь большую потребность в пропускной способности, что им имеет смысл прокладывать собственные трансокеанские кабели, а не арендовать их у других операторов.

Недавно Google и Facebook выступили инвесторами в проекте Pacific Light Cable Networks (PLCN), предусматривающем прокладку линии между Лос-Анджелесом и Гонконгом протяженностью 12 800 км с рекордной на сегодняшний день пропускной способностью 120 Тбит/с. И это уже шестой подводный кабель, на который у Google есть право собственности. В результате если в 2009 году транстихоокеанские сети операторов по своей емкости намного превосходили «частные сети» таких провайдеров, как Google, Amazon и др., то уже в 2014 году по этому показателю они почти сравнялись. Иначе говоря, облачные провайдеры буквально за пять лет с нуля построили свои глобальные сети (см. рис. 2).

Рис. 2. Облачные провайдеры буквально за пять лет с нуля построили свои глобальные сети
Рис. 2. Облачные провайдеры буквально за пять лет с нуля построили свои глобальные сети

 

Зачем им это надо? «То, что они строят, не является сетями связи в привычном понимании», — объясняет Александр Герасимов. Традиционная сеть связи представляет собой трубу, куда поступает пользовательский трафик. Внутри же глобальной сети, связывающей, скажем, ЦОДы Google, пользовательский трафик практически отсутствует. Все, что циркулирует в такой сети, — это служебный трафик: данные, генерируемые в ходе миграции виртуальных машин, резервного копирования и т. д. И этот трафик полностью контролируется провайдером — он не зависит от нагрузки, которую создают абоненты. Именно поэтому в таких сетях применение технологий SDN/NFV дает максимальный результат, если говорить об экономическом эффекте:

уровень утилизации сети составляет около 95%, тогда как у операторов магистральные сети загружены на 10–15%.

Таким образом, происходит формирование новых центров концентрации трафика, которых несколько лет назад либо не было вообще, либо они не играли заметной роли. Это сети программно определяемых ЦОДов облачных провайдеров, где, вообще говоря, концентрируются уже приложения. В результате, заключает Александр Герасимов, глобальные облачные провайдеры вытесняют операторов на региональный уровень — роль операторов сводится к предоставлению отдельных фрагментов сетей для «доставки» ОТТ-приложений конечным пользователям. Впрочем, в мире до сих пор нет ни одного значимого примера успешного партнерства между телеком-оператором и ОТТ-провайдером.

Какие возможности есть у оператора для развития бизнеса? Александр Герасимов рассматривает три варианта: провайдер прикладных сервисов; провайдер виртуальной сетевой инфраструктуры на локальном и региональном уровне, предоставляемой «по требованию» с динамически управляемым QoS; специализированная организация по строительству и эксплуатации физической инфраструктуры сетей (пассивной, активной). Первый и третий варианты не сулят операторам ничего хорошего.

Ситуация, когда провайдеры IP-телефонии начинают предлагать сервисы виртуальных АТС, является классическим примером трансформации в провайдера прикладных услуг. Проблема в том, что объем этого рынка на два порядка меньше рынка классических телекоммуникационных услуг. Оператор должен смириться с тем, что в России его обороты будут исчисляться не сотнями миллиардов рублей, как сейчас, а единицами миллиардов. Не лучше и другая крайность — оператор как создатель инфраструктуры (базовых станций и т. д.). Это исключительно строительный бизнес, где достаточно своих подрядчиков.

Второй вариант, по мнению Александра Герасимова, вполне жизнеспособен. Идея следующая. Такие характеристики облачного сервиса, как доступность, безопасность, задержка сигнала и т. д., сегодня измеримы только внутри SDN-сети ЦОДа. Как только сервис выходит за границу этой сети, QoS исчезает. Соответственно, провайдер сервиса заинтересован в распространении QoS до конечного пользователя, чтобы предоставить определенные гарантии — в первую очередь обеспечить доступность. Сделать это на существующих сетях затруднительно.

«Для оператора связи, который фактически вытеснен на уровень доступа, перспективы состоят в том, чтобы реализовать свою сеть в соответствии с принципами SDN/NFV и состыковать ее с программно определяемыми сетями ЦОДов глобальных провайдеров, —

объясняет Александр Герасимов. — Тогда можно реализовать экономически эффективную модель разделения доходов, при которой оператор будет выступать брокером облачных сервисов, внося свою «добавочную стоимость» в виде управляемого QoS до устройства абонента».

Проблема в том, что операторы катастрофически отстают от облачных провайдеров в развитии сетей связи в соответствии с принципами SDN/NFV, идеология которых ориентирована на совершенно иные задачи, не свойственные традиционным сетям связи. Однако, пока еще есть шанс вскочить в уходящий поезд, операторам необходимо трансформировать свои сети, обеспечив поддержку SDN/NFV. В качестве примера можно назвать AT&T, которая к концу 2016 года намеревалась виртуализовать 75% своей инфраструктуры. Рынок оценил стратегию AT&T — капитализация компании начала расти. «На данный момент AT&T — единственный оператор связи, чья капитализация существенно растет. Другого такого примера нет», — утверждает Александр Герасимов.

ВЫХОД ОДИН

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

Дмитрий Ганьжа, главный редактор «Журнала сетевых решений/LAN»

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF