Comments 14
С добрым утром, концепцию vCPE похоронили в прошлом году (насколько я знаю — все вендоры).
На замену предложили SD-WAN.
Особо умные выпендрились и родили свое, uCPE от Juniper и CloudVPN от Cisco.
На замену предложили SD-WAN.
Особо умные выпендрились и родили свое, uCPE от Juniper и CloudVPN от Cisco.
Добрый день, ayurtaykin.
Насколько я вижу, эти термины располагаются по разную сторону одной концепции. vCPE — это оборудование с виртуализированными сетевыми фукнциями, а SD-WAN — подход, при котором эти vCPE удаленно управляются, обновляются и с помощью которых загружают на них дополнительные SDN-Application из «магазина приложений».
Так что скорей всего были не «похороны», а интеграция коробок в единую концепцию.
Насколько я вижу, эти термины располагаются по разную сторону одной концепции. vCPE — это оборудование с виртуализированными сетевыми фукнциями, а SD-WAN — подход, при котором эти vCPE удаленно управляются, обновляются и с помощью которых загружают на них дополнительные SDN-Application из «магазина приложений».
Так что скорей всего были не «похороны», а интеграция коробок в единую концепцию.
В сети провайдера SD-WAN может позиционироваться как технология обслуживающая ядро сети, прозрачная для пользовательских услуг, т.е. vCPE скорее дополняет SD-WAN чем конкурирует с ним. Что касается популярности vCPE — такие решения сейчас достаточно активно предлагаются на рынке основными поставщиками (Cisco, Huawei, Alcatel/Nokia, Ericsson, HP, etc). У HP есть неплохое обзорное исследование результатов различных PoC по состоянию на Q1 2016 где vCPE занимает не последнее место. Беглый поиск по другим поставщикам подтверждает тезу про актуальность концепции vCPE — достаточно много свежих отчетов о PoC в 2015 году. vCPE сценарии также тестировались на SDNFV Fest под эгидой ONF в Пекине этой весной.
Действительно интересная и слабо разработанная тема — стандартизация интерфейсов между SND/NFV решениями и традиционными OSS/BSS.
Действительно интересная и слабо разработанная тема — стандартизация интерфейсов между SND/NFV решениями и традиционными OSS/BSS.
Действительно, решениями vCPE сейчас как будто бы занимаются все ведущие сетевые вендоры. Лично я начал тестирование продуктов в данной категории с решения Nuage VNS еще пару лет назад. Но со временем обнаружил похожие продукты от Juniper, Cisco, Huawei, HP и других. На презентациях каждый из этих технологических лидеров заверял сервис-операторов, что хватит быть уже экономикой «трубы» и пора переходить на следующий уровень в over-the-top решениях, потому что если не они возглавят этот процесс, то за них это сделает кто-то другой и в таком случае инфраструктурные-провайдеры перейдут на уровень экономики поставщиков электричества. Очевидно, что сейчас идет нешуточная борьба между конкурентами за скорейшую реализацию всего необходимого функционала в этих решениях и вывода на рынок законченного и стабильного решения. На мой взгляд полноценно этим похвастаться не может пока ни один вендор.
И как правильно заметил Vramin, гораздо больший вызов лежит в плоскости управления всей этой software-defined инфраструктуры. Каким образом можно обеспечить отказоустойчивую, гео-распределенную, событие-ориентированную, управляемую приложениями систему Оркестрации и Управления (orchestration + MANO)? Для это требуется не только описать текущую физическую и виртуальную инфраструктуру в виде моделей на синтаксисе YANG, Ansible, OpenConfig, чтобы влиять на оперативное развертывание новых сервисов, но так же научится принимать от этих элементов управляющие сигналы для реагирования на события.
Видно, что коллеги из ETSI проделали гигантскую работу в этом направлении для того, чтобы создать абстрактные модели взаимодействия указанных компонентов, но теперь необходимо целой армии разработчиков и продакт-менеджеров воплотить эти абстракции в код.
И как правильно заметил Vramin, гораздо больший вызов лежит в плоскости управления всей этой software-defined инфраструктуры. Каким образом можно обеспечить отказоустойчивую, гео-распределенную, событие-ориентированную, управляемую приложениями систему Оркестрации и Управления (orchestration + MANO)? Для это требуется не только описать текущую физическую и виртуальную инфраструктуру в виде моделей на синтаксисе YANG, Ansible, OpenConfig, чтобы влиять на оперативное развертывание новых сервисов, но так же научится принимать от этих элементов управляющие сигналы для реагирования на события.
Видно, что коллеги из ETSI проделали гигантскую работу в этом направлении для того, чтобы создать абстрактные модели взаимодействия указанных компонентов, но теперь необходимо целой армии разработчиков и продакт-менеджеров воплотить эти абстракции в код.
Думаю, что повсеместное внедрение подобных технологий окончательно разрушит сетевой нейтралитет и мы получим все те «прелести», которые встречаются в сотовых сетях.
Трафик на одни IP будет платным, на другие — бесплатным. Появится роуминг и всякие опции. За TCP трафик будет цена как за холодную воду, за UDP — как за горячую.
Трафик на одни IP будет платным, на другие — бесплатным. Появится роуминг и всякие опции. За TCP трафик будет цена как за холодную воду, за UDP — как за горячую.
Тут вопрос не в том что похоронили vCPE и придумали uCPE или SDN-WAN. А в том, что никто не знает как применять и как использовать NFV в продакшн системах. Большая проблема в том, что софтварные решение сетевых компонентов не дают должной производительности, потому что general-purpose процессоры не справляются с задачами процессоров сетевых устройств.
Из личного опыта, чаще всего Telco вендоры пытаются определить как же правильно развернуть окружение, если конкретней — OpenStack, так что бы он работал эффективно для нужд NFV, некоторые смотрят в сторону Docker-based NFV решений и все, далее идет анализ телеметрии с каждой NFV путем пинга или перегонки траффика в рамках двух подсетей одного клауда.
Так же, не стоит забывать, что такое оркестрация NFV. Звучит все круто и ново, прям как Internet of Things, но (!!) это всего лишь конфигурация софта поверх виртуальных машин (и тут у вас сразу должны забегать глаза из-за обилия способов установки и конфигурации софта в современном IT).
Самым интересным тут является средство оркестрации NFV, который подразумевается в указанном выше MANO, а так же проектах Open-O или Linux OPNFV — TOSCA data modeling language.
Так вот, на данный момент есть только очень маленький сегмент коробочных решений, которые предоставляет возможность оркестрации NFV. Среди указанных проектов (MANO, Linux OPNFV, Open-O) нет ни одного проекта, у которого есть готовое решение, вообще. Но если откинуть NFV и подумать о виртуалках и конфигурации софта, то сразу на ум придет несколько решений, которые могут делать оркестрацию используя TOSCA в качестве языка описания моделей:
AIOrchestra это Py3.5 либа для построения микросервисов вокруг.
Имея возможность оркестрировать ресурсы облака остается вопрос упомянутый мною выше — как же наконфигурить OpenStack, так чтобы работал «круто для NFV».
Вот и весь NFV. Как говорится, стильно, модно, молодежно.
Из личного опыта, чаще всего Telco вендоры пытаются определить как же правильно развернуть окружение, если конкретней — OpenStack, так что бы он работал эффективно для нужд NFV, некоторые смотрят в сторону Docker-based NFV решений и все, далее идет анализ телеметрии с каждой NFV путем пинга или перегонки траффика в рамках двух подсетей одного клауда.
Так же, не стоит забывать, что такое оркестрация NFV. Звучит все круто и ново, прям как Internet of Things, но (!!) это всего лишь конфигурация софта поверх виртуальных машин (и тут у вас сразу должны забегать глаза из-за обилия способов установки и конфигурации софта в современном IT).
Самым интересным тут является средство оркестрации NFV, который подразумевается в указанном выше MANO, а так же проектах Open-O или Linux OPNFV — TOSCA data modeling language.
Так вот, на данный момент есть только очень маленький сегмент коробочных решений, которые предоставляет возможность оркестрации NFV. Среди указанных проектов (MANO, Linux OPNFV, Open-O) нет ни одного проекта, у которого есть готовое решение, вообще. Но если откинуть NFV и подумать о виртуалках и конфигурации софта, то сразу на ум придет несколько решений, которые могут делать оркестрацию используя TOSCA в качестве языка описания моделей:
AIOrchestra это Py3.5 либа для построения микросервисов вокруг.
Имея возможность оркестрировать ресурсы облака остается вопрос упомянутый мною выше — как же наконфигурить OpenStack, так чтобы работал «круто для NFV».
Вот и весь NFV. Как говорится, стильно, модно, молодежно.
Долгое время не понимал суть SDN и NFV.
Вроде и с сетями на «ты»… и с виртуализацией… и программировать вроде как получается. Но никак не понимал как эти абстрактные понятие (SDN/NFV) реализуются в реальном, приземленном, мире.
В один день решился, и попробовал все это дело в действии. Надеюсь что я не один такой и кому-то будет интересно читать далее: для сисадминов кто хорошо знаком с (старыми) сетевыми технологиями, но не в теме SDN+NFV. Смотрел я на openflow с SDN контроллером ONOS. А также на OPNFV.
Начнем с SDN.
1) упрощаем маршрутизаторы до безобразия. Они становятся совсем «тупыми». Единственное что они понимают, это команды типа: «все пакеты с dst ip 10.0.0.1 которые вошли через порт eth0, отправить в порт eth1 попутно изменив 'dst mac' на аа: аа: аа: аа: аа: аа». На этих же маршрутизаторах крутиться маленькая программа которая подключается по TCP к контролеру. Контроллер по этому соединению отправляет команды-правила на добавления/удаления/изменения. Получив новые правила, они «скомпилированны» в ASIC(Application-specific integrated circuit) и далее весь процессинг делаеться на уровне hardware.
Например, когда новый пакет получен, маршрутизатор ищет правило которое подходит в списке правил. Если находит, правило исполняется. Если нет, пакет можно отправить контролеру по TCP соединению. Он проанализирует пакет и (возможно) отправит новое правило на добавление.
2) контроллер это просто громадная программа. Например ONOS/Opendaylight написаны на ява. Его задача, воссоздать граф сети в памяти. Наверное многие уже писали алгоритмы для графов в универе. Вот и контроллер крутит всякие алгоритмы чтоб найти кратчайший/лучший путь в сеть. А потом поочередно добавит нужные правила во все маршрутизаторы по пути. Никакой магии :) Вся красота в том что можно добавить какие угодно алгоритмы самому и не надо ждать что CISCO добавит их в IOS.
Маршрутизаторы также собирают всякую статистику о сети. Например, о своих соседях-маршрутизаторах (используя протокол LLDP). А также, об загруженности соединений. Эти данные они отправляют контроллеру по тому-же TCP соединению. Именно эта информация позволяет воссоздать сеть в память контролера и понять что «интерфейс eth0 у switch2 загружен, надо бы какой-то трафик перевести в обход».
В случае NFV, все вроде еще проще:
Вместо того чтоб крутить DHCP/ DNS/ ..../Firewall/..../[new network function] в роутерах, используем магию (в смысле, виртуальную машину/контейнер): на одной запускаем DHCP сервер, на второй BIND, на третей настроим iptables… и так далее. А можно еще купить магическую программу от [крутой организации] и поставить в 4-ую вм. После этого, добавим по правилу через СДН чтоб трафик распределялся по правильным вм.
Как это сделать? В этом то и вся проблема, а SDN и NFV пока что взлетают, взлетают, да не взлетят. Плохо это? хорошо?: не мне решать.
Например, OPNFV это ОГРОМНЫЙ монстр. Первое что надо сделать для его установки, это поднять Openstack кластер. Потом, в этом кластере поднимется пара виртуальных машин в которые устанавливается SDN контроллер с «high availability», blackjackom и шл…
Напомним, SDN контроллер это еще один монстр на пару сотен тысяч линий кода (если не миллионов).
На данный момент я ужасно боюсь что «это» взлетит и мне придется администрировать его, честно боюсь
Я ведь только-только привык к DevOps, а тут DevOps в 5-ой степени
Вроде и с сетями на «ты»… и с виртуализацией… и программировать вроде как получается. Но никак не понимал как эти абстрактные понятие (SDN/NFV) реализуются в реальном, приземленном, мире.
В один день решился, и попробовал все это дело в действии. Надеюсь что я не один такой и кому-то будет интересно читать далее: для сисадминов кто хорошо знаком с (старыми) сетевыми технологиями, но не в теме SDN+NFV. Смотрел я на openflow с SDN контроллером ONOS. А также на OPNFV.
Начнем с SDN.
1) упрощаем маршрутизаторы до безобразия. Они становятся совсем «тупыми». Единственное что они понимают, это команды типа: «все пакеты с dst ip 10.0.0.1 которые вошли через порт eth0, отправить в порт eth1 попутно изменив 'dst mac' на аа: аа: аа: аа: аа: аа». На этих же маршрутизаторах крутиться маленькая программа которая подключается по TCP к контролеру. Контроллер по этому соединению отправляет команды-правила на добавления/удаления/изменения. Получив новые правила, они «скомпилированны» в ASIC(Application-specific integrated circuit) и далее весь процессинг делаеться на уровне hardware.
Например, когда новый пакет получен, маршрутизатор ищет правило которое подходит в списке правил. Если находит, правило исполняется. Если нет, пакет можно отправить контролеру по TCP соединению. Он проанализирует пакет и (возможно) отправит новое правило на добавление.
2) контроллер это просто громадная программа. Например ONOS/Opendaylight написаны на ява. Его задача, воссоздать граф сети в памяти. Наверное многие уже писали алгоритмы для графов в универе. Вот и контроллер крутит всякие алгоритмы чтоб найти кратчайший/лучший путь в сеть. А потом поочередно добавит нужные правила во все маршрутизаторы по пути. Никакой магии :) Вся красота в том что можно добавить какие угодно алгоритмы самому и не надо ждать что CISCO добавит их в IOS.
Маршрутизаторы также собирают всякую статистику о сети. Например, о своих соседях-маршрутизаторах (используя протокол LLDP). А также, об загруженности соединений. Эти данные они отправляют контроллеру по тому-же TCP соединению. Именно эта информация позволяет воссоздать сеть в память контролера и понять что «интерфейс eth0 у switch2 загружен, надо бы какой-то трафик перевести в обход».
В случае NFV, все вроде еще проще:
Вместо того чтоб крутить DHCP/ DNS/ ..../Firewall/..../[new network function] в роутерах, используем магию (в смысле, виртуальную машину/контейнер): на одной запускаем DHCP сервер, на второй BIND, на третей настроим iptables… и так далее. А можно еще купить магическую программу от [крутой организации] и поставить в 4-ую вм. После этого, добавим по правилу через СДН чтоб трафик распределялся по правильным вм.
Как это сделать? В этом то и вся проблема, а SDN и NFV пока что взлетают, взлетают, да не взлетят. Плохо это? хорошо?: не мне решать.
Например, OPNFV это ОГРОМНЫЙ монстр. Первое что надо сделать для его установки, это поднять Openstack кластер. Потом, в этом кластере поднимется пара виртуальных машин в которые устанавливается SDN контроллер с «high availability», blackjackom и шл…
Напомним, SDN контроллер это еще один монстр на пару сотен тысяч линий кода (если не миллионов).
На данный момент я ужасно боюсь что «это» взлетит и мне придется администрировать его, честно боюсь
Я ведь только-только привык к DevOps, а тут DevOps в 5-ой степени
Хорошая статья. Очень жду продолжения :)
Насколько я понимаю, сейчас на рынке «зоопарк». Каждый делает что-то своё, пытаясь занять удобную нишу. Данный хаос делает отсрочку идее «унифицированного магазина сетевых функций», потому как каждую новую VNF для такого магазина, потребуется допиливать под некий единый стандарт. Насколько я понял, конкретизированного стандарта еще нет, есть нечто верхнеуровневое от ETSI. Поэтому быстрого деплоя VNF в магазин с последующими активностями по service chaining мы еще долго не увидим :(.
Насколько я понимаю, сейчас на рынке «зоопарк». Каждый делает что-то своё, пытаясь занять удобную нишу. Данный хаос делает отсрочку идее «унифицированного магазина сетевых функций», потому как каждую новую VNF для такого магазина, потребуется допиливать под некий единый стандарт. Насколько я понял, конкретизированного стандарта еще нет, есть нечто верхнеуровневое от ETSI. Поэтому быстрого деплоя VNF в магазин с последующими активностями по service chaining мы еще долго не увидим :(.
Увы, да. Как я описал в своем комментарии — есть 3 организации, которые почти что игнорирует друг друга. А те, кто написал естандарт ETSI MANO игнорируются ввиду изначально неправильно политики унифицирования реализации стандарта (мол, всё, мы написали стандарт — повинуйтесь).
Не уверен, что технологические вендоры-лидеры будут игнорировать стандарт 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.
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.
А долго это один год или пять лет? :)
Мне видится, что сейчас такое время, когда в ближайшее время могут выстрелить сразу несколько вендоров со своими решениями по «магазину VNF приложений». Cisco аналог показывала где-то год назад в рамках функционала APIC-контроллера. NEC со своим SDN space призывает производителей VNF к сотрудничеству. HP недавно анонсировал открытие SDN app store.
Возможно прорыва стоит ожидать не сколько от сетевых вендоров, сколько от производителей OSS\BSS систем, в которые сейчас активно интегрируют MANO-компоненты.
Мне видится, что сейчас такое время, когда в ближайшее время могут выстрелить сразу несколько вендоров со своими решениями по «магазину VNF приложений». Cisco аналог показывала где-то год назад в рамках функционала APIC-контроллера. NEC со своим SDN space призывает производителей VNF к сотрудничеству. HP недавно анонсировал открытие SDN app store.
Возможно прорыва стоит ожидать не сколько от сетевых вендоров, сколько от производителей OSS\BSS систем, в которые сейчас активно интегрируют MANO-компоненты.
Вендоры обязательно пальнут (куда же им деваться), только в разные стороны.
Можно ли приложить линк на Cisco аналог VNF магазина (если это вдруг не NSO)? Признаться, не слышал о его существовании.
Согласен, что много работы ложиться на плечи участников процесса REL, ибо здесь мы имеем телекомовскую хотелку, завернутую в ИТ-шное решение. Но я не уверен, что их действия определят направление, так как не их экспертиза является основополагающий.
Можно ли приложить линк на Cisco аналог VNF магазина (если это вдруг не NSO)? Признаться, не слышал о его существовании.
Согласен, что много работы ложиться на плечи участников процесса REL, ибо здесь мы имеем телекомовскую хотелку, завернутую в ИТ-шное решение. Но я не уверен, что их действия определят направление, так как не их экспертиза является основополагающий.
На семинаре по Cisco ACI демонстрировали возможности контроллера APIC, в который можно загрузить Device Package — подготовленный образ ВМ от других вендоров для реализации конкретной сетевой функции, в которые по заданному API-интерфейсу передается конфигурация во время применения этого device package к сервисному графу для реализации network function.
Демонстрация показала как в автоматическом режиме можно сетевые функции применять к трафику. Настраивать в консоле каждую ВМ с сетевой функции не было необходимости.
Демонстрация показала как в автоматическом режиме можно сетевые функции применять к трафику. Настраивать в консоле каждую ВМ с сетевой функции не было необходимости.
Sign up to leave a comment.
Эволюция сети к SDN & NFV