Аббревиатуры SDN и NFV в последнее время звучат все чаще и звучат вместе. В тендерах операторы связи требуют от производителей обязательной поддержки SDN и NFV, т.к. уверены, что эти технологии оказывают положительное влияние на OPEX, CAPEX и TTM. Быстрый серфинг интернета показывает, что SDN — это Software-Defined Networking, а NFV — это Network Functions Virtualization. Обе технологии связаны с виртуализацией и с сетями, т.е. на первый взгляд складывается впечатление, что они очень похожие, если не одно и то же. Давайте разбираться, так ли это на самом деле! Проверка по Google Trend сначала подтверждает гипотезу: тренд запроса «SDN and NFV» начинается в 2013 году:
Но дальше оказывается, что тема Программно-определяемой сети начинает подниматься гораздо раньше — с 2008:
Начинаем разбираться.
SDN родился в недрах ЦОДов. Если в двух словах, то проблема с сетью была следующая.
Классический коммутатор маршрутизирует потоки трафика по правилам, которые необходимо конфигурировать в самом коммутаторе. Если коммутаторов 10-20, то их еще можно настроить вручную, а в ЦОДах с сотнями и тысячами коммутаторов задача превращалась в нерешаемую. Упрощенная схема, иллюстрирующая жизнь до SDN:
Т.е. чтобы поток данных маршрутизировался через 3 коммутатора, необходимо сконфигурировать каждый коммутатор в отдельности. Что же предлагает SDN? С современной точки зрения на архитектуру — ничего нового: разделение на слои и стандартизацию интерфейсов:
В нижнем слое «Инфраструктура» располагаются простые коммутаторы, которые умеют только маршрутизировать трафик. Таблицы для маршрутизации разливаются с центрального контроллера, расположенного в слое «Управление». Для этого используется стандартный протокол «OpenFlow». OpenFlow — стандарт, который с 2011 года развивает организация Open Networking Foundation (ONF). А первая версия стандарта появилась в 2008, становится понятно, откуда рост тренда «Программно-определяемые сети». На верхнем слое «Приложения» для управления, конфигурирования и мониторинга. API к нему не стандартизировано. Таким образом, конфигурирование коммутаторов производится централизованно, конфигурации разливаются автоматически — победа над OPEX и ТТМ. Коммутаторы стали дешевые и стандартные — экономим CAPEX. Для стандартных ЦОДов – большая победа, но для операторов связи счастье не наступило.
У операторов есть еще проблема – большое количество и разнообразие сетевых функций, примеры общеизвестных: NAT, firewall, DPI. Каждый производитель поставляет свои приложения на своем железе, и в результате у операторов скапливается зоопарк проприетарного железа, который опять же надо синхронно конфигурировать при введении новых коммерческих инициатив для абонентов. Т.е. это та же проблема с коммутаторами, но на более высоком уровне. Что же придумали операторы? Они объединились и под эгидой ETSI (Европейский Институт Телекоммуникационных Стандартов) выпустили стандарт ETSI NFV. Картинка из стандарта, иллюстрирующая проблему и решение:
Первая версия стандарта ETSI NFV вышла в 2012 (ага, вот откуда Google Trend растет). Посмотрим внимательнее на стандарт, упрощенная схема из документа «ETSI GS NFV-EVE 003», иллюстрирующая архитектуру:
Давайте разбираться. Справа — NFV MANO (Management and Orchestration ) — это только та часть, которую специфицирует ETSI. То, что слева — только рекомендации. В принципе эта часть может отличаться у разных производителей, но, как показывает практика, все вписывают свои решения в эту общую схему.
Сверху OSS/BSS стандартные системы операторов связи — биллинг, чарджинг, тарификация, CRM, самообслуживание абонентов и т.д. Они как были, так и остаются, и связаны с NFV только одним специфицированным интерфейсом (Os-Ma). Про функции интерфейсов подробнее я лучше расскажу в другой статье, сейчас же надо понять общую картину. Ниже расположены VNF (Virtualized Network Functions) — это как раз сетевые функции, которые теперь работают на стандартном оборудовании в виртуальной среде. EM (Element Management) — управление сетевыми элементами. EM обеспечивает для VNF функциональность FCAPS (fault, configuration, administration, performance, security). Не очень понятно, зачем вообще были введены в стандарт EM? Думаю, для того, чтобы не выносить эти функции в OSS/BSS, чтобы не пугать операторов необходимостью доработок в этом контуре. Управляют VNF — VNF Managers (VNFM).
Предполагается, что VNF Managers должны реализовываться производителями VNF, т.к. производители лучше всего знают, как управлять своими VNF.
Под слоем VNF расположена NFV Infrastructure (NFVI) — стандартное (COTS) оборудование со слоем гипервизора и виртуализации. Оборудованием и виртуализацией управляет VIM (Virtualized Infrastructure Manager). Производители систем виртуализации взялись как раз за нижний слой. Linux, OpenStack еще несколько десятков компаний организовали проект Open Platform for NFV (OPNFV). VMWare, разумеется, реализовала свою альтернативу vCloud NFV:
Управляет всем этим хозяйством главный элемент NFV — NFVO (NFV Orchestrator). Какие производители реализуют элементы NFV Orchestrator? На сегодняшний день также есть две альтернативы. ETSI объявил о запуске проекта – Open Source MANO (OSM) и компания Cloudify предлагает свою честную «pure-play cloud orchestration platform», которая работает как с OpenStack, так и с VMWare:
Ну все с NFV, вроде, разобрались, но наряду с преимуществами NFV на сегодняшний день видим и ряд проблем:
Таким образом, видим, что стандарту NFV есть куда расти! Подождите, а где тут SDN?
SDN обеспечивает для NFV виртуализацию сетевых интерфейсов и сетевую связность для VNF. Возьмем для примера элементы из OpenStack: виртуальный коммутатор «Open vSwitch» и SDN контроллер «Open Daylight». Поместим их в NFV, и теперь понятно, где тут SDN:
Может ли существовать SDN без NFV? Конечно, может — это мы видели в начале статьи. Может ли существовать NFV без SDN — ответ тот же, но при этом конфигурировать сетевые интерфейсы и связность нужно будет вручную, т.е. действительно наблюдаем синергию SDN и NFV. Стало понятно, что это никак не синонимы, а две большие разницы!
Таким образом, пока наблюдаем за развитием стандарта и с нетерпением ждем реальных success stories!
А при чем тут облака? Об этом в следующей статье «Облака как любовь».
Но дальше оказывается, что тема Программно-определяемой сети начинает подниматься гораздо раньше — с 2008:
Начинаем разбираться.
SDN — проблема и решение
SDN родился в недрах ЦОДов. Если в двух словах, то проблема с сетью была следующая.
Классический коммутатор маршрутизирует потоки трафика по правилам, которые необходимо конфигурировать в самом коммутаторе. Если коммутаторов 10-20, то их еще можно настроить вручную, а в ЦОДах с сотнями и тысячами коммутаторов задача превращалась в нерешаемую. Упрощенная схема, иллюстрирующая жизнь до SDN:
Т.е. чтобы поток данных маршрутизировался через 3 коммутатора, необходимо сконфигурировать каждый коммутатор в отдельности. Что же предлагает SDN? С современной точки зрения на архитектуру — ничего нового: разделение на слои и стандартизацию интерфейсов:
В нижнем слое «Инфраструктура» располагаются простые коммутаторы, которые умеют только маршрутизировать трафик. Таблицы для маршрутизации разливаются с центрального контроллера, расположенного в слое «Управление». Для этого используется стандартный протокол «OpenFlow». OpenFlow — стандарт, который с 2011 года развивает организация Open Networking Foundation (ONF). А первая версия стандарта появилась в 2008, становится понятно, откуда рост тренда «Программно-определяемые сети». На верхнем слое «Приложения» для управления, конфигурирования и мониторинга. API к нему не стандартизировано. Таким образом, конфигурирование коммутаторов производится централизованно, конфигурации разливаются автоматически — победа над OPEX и ТТМ. Коммутаторы стали дешевые и стандартные — экономим CAPEX. Для стандартных ЦОДов – большая победа, но для операторов связи счастье не наступило.
NFV — проблема и решение
У операторов есть еще проблема – большое количество и разнообразие сетевых функций, примеры общеизвестных: NAT, firewall, DPI. Каждый производитель поставляет свои приложения на своем железе, и в результате у операторов скапливается зоопарк проприетарного железа, который опять же надо синхронно конфигурировать при введении новых коммерческих инициатив для абонентов. Т.е. это та же проблема с коммутаторами, но на более высоком уровне. Что же придумали операторы? Они объединились и под эгидой ETSI (Европейский Институт Телекоммуникационных Стандартов) выпустили стандарт ETSI NFV. Картинка из стандарта, иллюстрирующая проблему и решение:
Первая версия стандарта ETSI NFV вышла в 2012 (ага, вот откуда Google Trend растет). Посмотрим внимательнее на стандарт, упрощенная схема из документа «ETSI GS NFV-EVE 003», иллюстрирующая архитектуру:
Давайте разбираться. Справа — NFV MANO (Management and Orchestration ) — это только та часть, которую специфицирует ETSI. То, что слева — только рекомендации. В принципе эта часть может отличаться у разных производителей, но, как показывает практика, все вписывают свои решения в эту общую схему.
Сверху OSS/BSS стандартные системы операторов связи — биллинг, чарджинг, тарификация, CRM, самообслуживание абонентов и т.д. Они как были, так и остаются, и связаны с NFV только одним специфицированным интерфейсом (Os-Ma). Про функции интерфейсов подробнее я лучше расскажу в другой статье, сейчас же надо понять общую картину. Ниже расположены VNF (Virtualized Network Functions) — это как раз сетевые функции, которые теперь работают на стандартном оборудовании в виртуальной среде. EM (Element Management) — управление сетевыми элементами. EM обеспечивает для VNF функциональность FCAPS (fault, configuration, administration, performance, security). Не очень понятно, зачем вообще были введены в стандарт EM? Думаю, для того, чтобы не выносить эти функции в OSS/BSS, чтобы не пугать операторов необходимостью доработок в этом контуре. Управляют VNF — VNF Managers (VNFM).
Предполагается, что VNF Managers должны реализовываться производителями VNF, т.к. производители лучше всего знают, как управлять своими VNF.
Под слоем VNF расположена NFV Infrastructure (NFVI) — стандартное (COTS) оборудование со слоем гипервизора и виртуализации. Оборудованием и виртуализацией управляет VIM (Virtualized Infrastructure Manager). Производители систем виртуализации взялись как раз за нижний слой. Linux, OpenStack еще несколько десятков компаний организовали проект Open Platform for NFV (OPNFV). VMWare, разумеется, реализовала свою альтернативу vCloud NFV:
Управляет всем этим хозяйством главный элемент NFV — NFVO (NFV Orchestrator). Какие производители реализуют элементы NFV Orchestrator? На сегодняшний день также есть две альтернативы. ETSI объявил о запуске проекта – Open Source MANO (OSM) и компания Cloudify предлагает свою честную «pure-play cloud orchestration platform», которая работает как с OpenStack, так и с VMWare:
Ну все с NFV, вроде, разобрались, но наряду с преимуществами NFV на сегодняшний день видим и ряд проблем:
- Только два производителя предлагают решение для VIM: OpenStack и VMWare
- Не получается на системе виртуализациии IT построить NFV. Cначала думали, что берем систему виртуализации IT, немного докручиваем, и получается NFV. Но задачи NFV слишком специфичны. Например, развертывание на bare metal серверах, необходимость распределенной структуры, большее число WAN линков и внешнего трафика
- Более высокие требования к оборудованию, к производительности, к задержке отклика
- Конфигурирование NVF не укладывается в шаблоны
- Нельзя избежать vendor-lock, даже используя OpenStack т.к. нужна техническая поддержка, а OpenStack каждый производитель точит под себя
Таким образом, видим, что стандарту NFV есть куда расти! Подождите, а где тут SDN?
SDN и NFV
SDN обеспечивает для NFV виртуализацию сетевых интерфейсов и сетевую связность для VNF. Возьмем для примера элементы из OpenStack: виртуальный коммутатор «Open vSwitch» и SDN контроллер «Open Daylight». Поместим их в NFV, и теперь понятно, где тут SDN:
Может ли существовать SDN без NFV? Конечно, может — это мы видели в начале статьи. Может ли существовать NFV без SDN — ответ тот же, но при этом конфигурировать сетевые интерфейсы и связность нужно будет вручную, т.е. действительно наблюдаем синергию SDN и NFV. Стало понятно, что это никак не синонимы, а две большие разницы!
Таким образом, пока наблюдаем за развитием стандарта и с нетерпением ждем реальных success stories!
Облака
А при чем тут облака? Об этом в следующей статье «Облака как любовь».
Немного ссылок
- Программно-определяемый ЦОД
- SDN и NFV: как это работает на сети оператора связи
- SDN и NFV много статей: sdnblog.ru
- SDN и NFV много статей на английском: www.sdxcentral.com
- NFV MANO: What's Wrong & How to Fix It
Следующие статьи
- Облака как любовь
- Интерфейсы и функциональные блоки NFV
- Производители и кейсы использования SDN и NFV
- Готовим NFV в домашних условиях
- BigData и NFV — есть ли связь?
Поделиться с друзьями
RGV
OpenContrail?
AlexeySushkov
ETSI в своих стандартах помещает OpenContrail в список SDN контроллеров (см. ETSI GS NFV-EVE 005), но никак не в VIM. Давайте разберемся почему.
OpenContrail – это OpenSource проект, который включает в себя SDN контроллер (Contrail Controler), виртуальный коммутатор (vRouter), аналитику, GUI для конфигурирования, API для интеграции с OpenStack и другими системами. Посмотрим на схему из их описания:
Отсюда видно, что экосистема OpenContrail, хотя и выходит за рамки простого SDN контроллера, но все-таки полностью помещается в NFVI в части SDN и отвечает за конфигурирование и управление виртуальными сетями. Тогда как VIM в NFV выполняет более широкий спектр задач и управляет не только сетью, но и вычислительными ресурсами, системами хранения данных и software образами (см. ETSI NFV-MAN001)