Обзор NFV MANO платформ от open source community
Вступление
В прошлой моей статье мы с вами рассмотрели исторический контекст развития сетей передачи данных и предпосылки, которые привели к появлению и развитию концепций SDN и NFV. Экономический вывод для телеком-индустрии из статьи такой, что существует требование к повышению инвестиций в телеком-инфраструктуру и это связано с требованиями к большей пропускной способности каналов связи. Одновременно есть тенденция к сокращению средней выручки на абонента за счет развития конкуренции и демпинг со стороны крупных операторов в стремлении удержать долю рынка. Эти два сходящиеся графика — расходы на инвестиции и уменьшение доходов рано или поздно пересекутся, что приведет к банкротствам среди телеком-операторов и переделу рынка в сторону укрупнения.
Для нивелирования этой угрозы, крупные телеком-гиганты должны с одной стороны повышать отдачу от своих инвестиций, и с другой стороны создавать новые сервисы для повышения выручки с одного абонента. Обе задачи можно выполнить за счет виртуализации сетевых функций. Более плотное использование аппаратных ресурсов при виртуализации показало свой успех на рынке вычислительных мощностей — несколько виртуальных машин на одном физическом сервере утилизируют CPU, RAM и Storage гораздо эффективней. Запуск нескольких виртуальных сетевых функций на одном аппаратном сервере тоже снизит капитальные расходы на оборудование. Помимо этого, даст гибкость в управлении, позволяя быстрее производить обновление ПО, устранять баги и запускать новые сервисы в короткие сроки.
ETSI MANO
Для достижения этих целей требуется система управлением инфраструктурой виртуальных сетевых функций — NFVI (network function virtualization infrastructure). Эта система должна уметь в автоматизированном режиме запускать сетевые функции, отслеживать их состояние, масштабировать в случае увеличения нагрузки, перезапускать при аварийном поведении, терминировать в случае отсутствия необходимости. Все это легло в основу того, что назвали MANO — management and orchestration.
Крупные игроки телеком-индустрии, осознавая неизбежность движения в этом направлении, начали координировать свои усилия! Это невероятно в эпоху капитализма и закрытости бизнес-моделей, которые присутствовали в 20 веке, но видимо неизбежно в 21 веке, в котором темп изменений растет экспоненциально.
Началось все с того, что участники телеком-рынка стали создавать стандарты, по которым должны реализоваться программные компоненты этой индустрии. Под эгидой европейского института стандартизации в телеком-сфере ETSI была создана рабочая группа для создания целого списка стандартов, описывающих самые разные процессы этой идеи.
Представительство компаний-контрибьюторов, которые вносят свой вклад в создание стандартов, очень внушительное. Посмотрите на список участников стандарта ETSI MANO:
NEC, Tech Mahindra, Orange, Cisco, Amdocs, Wind River Systems, Alcatel-Lucent, HP, Oracle, Orange, Juniper, ZTE, Intel, Telecom Italia, Wipro, EnterpriseWeb, NSN, Huawei, ASSIA, Telefonica, China Unicom, AT&T, Verizon, Docomo, Deutsche Telekom, Sprint, Vodafone, 6Wind, BT, tech Mahindra, Sonus, Brocade, ETRI, Ooredoo, Fujitsu, Ericsson.
Тут и вендоры, и телеком-операторы. При таком солидном составе очевидно, что принятые стандарты будут имплементированы как в программных компонентах от вендоров, так и на сетях телеком-операторов. Стоит заметить, что работа над стандартами еще продолжается, так как при реализации заложенных подходов происходит уточнение функционала, формата данных, стыковочных интерфейсов, процессов и прочего. Каждая компания-контрибьютор имеет право (и активно им пользуется!) на внесение доработок в стандарт. Это помогает производителям ПО добавлять те функции, которые они знают как реализовать в исходном коде. И это помогает операторам, которые знают реальные бизнес-кейсы и как они должны быть решены с помощью разрабатываемого ПО.
В итоге была создана референсная архитектура компонентов MANO. Представим вам ее в красивой картинке от замечательных коллег из sdnblog:
Обзор всех компонентов данной архитектуры, как и обзор всего списка разрабатываемых стандартов это тема для отдельной статьи. Коллеги в параллельных потоках уже сделали несколько хороших обзоров данных компонентов (здесь и здесь).
Нас же, в рамках этого поста, интересует, какие инициативы дали свой результат в open source среде. Коммерческие проприетарные разработки вендоров, которые зарабатывают на продаже ПО и лицензий к ним, сложно оценить взглядом со стороны, не находясь внутри рынка. При этом опен-сорс проекты активно обсуждаются и их можно изучать, не будучи вендором.
Таких проектов в области ETSI MANO родилось достаточное количество:
• Open Source MANO
• Open-O
• SONATA
• OpenBaton
• ECOMP
• OpenStack Tacker
• Gohan
• OPNFV
Рассмотрим подробнее три из них.
Open Source MANO
Open Source MANO (OSM) разрабатывается рабочей группой под руководством самого ETSI. При этом лидирующую роль занимают представители операторов Telefonica, BT, Telenor и вендоров Intel, RITF.io, Ubuntu, VMWare. Полный список контрибьюторов можно посмотреть здесь.
Первый релиз OSM уже состоялся и доступен для скачивания. Доступный функционал представлен следующими компонентами:
Архитектура OSM уже сейчас позволяет производить дизайн сетевых сервисов, выполнять оркестрацию сетевых сервисов, управлять отдельными VNF и управлять ресурсами NFVI, выделяемых под VNF. Доступно подключение SDN-контроллеров для управления сетевым компонентом, необходимым для управления трафиком, который будет поступать в VNF.
Так как этот проект продвигается самим ETSI, то есть вероятность, что он будет одним из самых успешных.
Open-O
Данный проект является китайским ответом на тренд по созданию системы оркестрации сетевых функций. Список контрибьюторов говорит сам за себя: China Mobile, China Telecom, Huawei, ZTE, Hong Kong Telecom, Ericsson, Intel, Gigaspaces, Canonical, Infoblox, RedHat. И наличие в этом списке западных вендоров пускай вас не смущает — лидерами там являются именно китайские компании.
Первый релиз уже состоялся и доступен для скачивания. Функционал представлен следующими компонентами:
Архитектура позволяет создавать вокрфлоу сервиса с помощью стандарта TOSCA, управлять сетями с помощью SDN-оркестратора и сетевыми функциями с помощью NFV-оркестратора. Доступны коннекторы к сторонним SDN-контроллерам и системами управления NFVI через VIM.
Очевидно, что китайский рынок телеком-операторов будет ориентироваться на этот продукт и вряд ли мы увидим расцвет других инициатив на этом азиатском направлении. А с учетом того, что китайский рынок мобильной и фиксированной связи является самым большим в мире, то очевидно, что многие решения по управлению гигантскими потоками данных именно на этом рынке могут показать себя с лучшей стороны. Гигантские всплески трафика и работа с Большими Данными от большого количества подписчиков позволит протестировать инновационные подходы именно на этом рынке.
SONATA
Этот проект появился за счет европейского гранта на НИОКР в области сетей 5G под названием Horizon 2020 — инициатива, при которой к 2020 году должны появится сети 5G, которые позволят повысить скорость передачи данных для мобильных абонентов. При этом те сервисы, которые будут оказываться подписчикам должны иметь маленькую задержку и широкие возможности. Частью решения этой задачи является создание системы оркестрации сетей связи и сетевых функций. Проект SONATA должен был предоставить возможность дизайна сетевых функций и оперативное управление созданными сетевыми функциями.
В партнерах проекта указаны следующие компании: Atos, NEC, Thales, Telefonica, Nokia, BT и несколько европейских университетов. Сам проект имеет очень академическую направленность и глубокую проработку с точки зрения технологий. Нацеленность в приоритете на обкатку подходов нового технологического тренда, а не скорейшую коммерческую эксплуатацию.
Первый релиз уже доступен для скачивания, хотя по данным github«а видно, что в текущую первую версию продолжается контрибьюция кода и соответственно нельзя назвать этот релиз стабильным.
Функционал представлен следующими компонентами:
SONATA SDK позволяет производить дизайн сервисов и тестирование. SONATA Service Platform позволяет запускать созданные сервисы и управлять их жизненным циклом. Описание архитектуры доступно здесь (pdf).
Что делать телеком-операторам сейчас?
Что уже сейчас могут делать операторы связи, которые хотят подготовиться к следующему технологическому тренду? Крупные западные и азиатские телеком-операторы уже завершают стадии пилотирования и proof of concept и переходят на постепенное внедрение данных решений на продуктивный трафик. Новые участки сети оснащаются архитектурой виртуализированных сетевых функций. Новые сервисы проектируются с использованием agile-подхода и на основе распределенной инфраструктуры. В России операторы чаще всего ориентируются на решения, которые поставляют западные или азиатские вендоры, прошедшие обкатку на уже развернутых сетях. Возглавить этот тренд и начать внедрять инновации одними из первых на нашем рынке — это прерогатива крупных игроков, но те, кто первым воспользуется новой волной, получат максимум отдачи за счет раннего обучения персонала и поиска оптимального решения для своих нужд. Начать можно с пилотирования тех open source проектов, которые представлены в обзоре. После успешного опыта на открытых и бесплатных проектах, можно будет сделать выбор коммерческого проприетарного продукта, с учетом того, что зачастую телеком-операторы концентрируют свою экспертизу на операционных процессах, а разработку и поддержку решения оставляют за проверенным вендором. Кого выбрать из вендоров, каждый оператор решит сам, но такие отчеты как Magic Quadrant by Garnter часто являются тем вектором внимания, на который ориентируются многие потребители решений от вендоров. Недавний рейтинг от Gartner в области OSS систем показывает, кто поставляет самые продвинутые коммерческие системы в этой отрасли. Следует заметить, что под зонтиком OSS как раз и располагаются решения в области управления NFV-инфраструктурой и экосистемой VNF:
Видно, что в отчете Gartner помимо «железных» вендоров Nokia, Huawei, HPE, IBM и Ericsson так же присутствуют чисто софтварные компании — Netcracker, Amdocs, Oracle. При выборе своего вендора следует иметь в виду заинтересованность «железных» компаний в попутной продаже своих аппаратных устройств в комплексе с программными продуктами по управлению «железом». Софтварные компании лишены этого недостатка и чаще других являются мульти-вендорными по отношению к «железу».
При этом, можно выбрать на долгосрочнную перспективу и open source продукт, но нужно продумать на горизонте 3–5–7 лет, кто будет оказывать поддержку и писать патчи для багфикса.
Комментарии (2)
xcore78
23 декабря 2016 в 17:46 (комментарий был изменён)
0↑
↓
Привет, Василий!Спасибо, что несёте слово в массы.
Думаю, сетевикам было бы особенно интересно узнать о работающих проектах, поскольку одно дело решать задачи бизнеса в презентации и совсем другое — поставить себя в зависимость от технологии и оседлать её.
Например:
https://people.eecs.berkeley.edu/~sylvia/cs268–2014/papers/b4-sigcomm13.pdfСкептицизм и осведомлённость, увы, обратно пропорциональны.
p.s. уверен, вы уже читали про этих ребят. Можно только порадоваться за эксплуатирующих их решения инженеров.
wider
23 декабря 2016 в 18:22
0↑
↓
Привет, Алексей!Спасибо, что читаете и делитесь своими комментариями!
И уверен, что не сколько сетевикам, сколько людям от бизнеса интересней узнать о работающих проектах.
Ведь сетевик был бы рад поработать с любой инновацией, если в нее будут вложены деньги. И технарей как правило не нужно убеждать попробовать что-то новое. А вот тех, кто инвестирует свои средства в будущие проекты — они гораздо больше задумываются о том, где это уже взлетело и стоит ли туда вкладывать.Но тут можно попасть в интересную петлю. Если операторы долго будут ждать, пока кто-то другой у себя внедрит какую-то технологию и докажет рынку, что это работоспособно, то эти операторы могут просто изчезнуть с рынка, так как не успеют подготовиться к изменениями.
Простой пример с виртуализацией вычислительных ресурсов показал очевидную эффективность в повышенной утилизации железа и создания слоя абстракции между оборудованием и операционной системой.
Думаю крупные операторы осознают необходимость изменений, но им требуется решение, которое работает. Один из выводов статьи как раз в том, чтобы уже сейчас начать применять бесплатные решения в пилотах, чтобы персонал был готов к внедрению и использованию того решения, которое им предложат технологические вендоры.
Заменить «железный» файрвол на программный — это может быть первый шаг. Заменить «железный» BNG\BRAS на программный может быть вторым шагом. И так далее.
Про коллег из ЦПИКС не просто слышал, но и лично знаком с многими. Очень правильный вектор держат и желаю им успехов!
