Sdn nfv что это
Взаимодействие SDN и NFV, обзор рекомендаций
Краткое описание идеи SDN и NFV
Идея, лежащая в основе концепции SDN (Software Defined network) предполагает отделение уровня управления сетевыми устройствами от уровня передачи данных. Под управлением в данной формулировке понимаются все действия связанные с выработкой правил передачи и обработки потоков информации, а также функции по конфигурированию и контролю состояния устройств уровня передачи данных. На уровень передачи данных возлагается только исполнение правил. При этом очень важным концептуальным моментом является возможность внешнего программирования уровня управления. Разработкой открытых стандартов SDN занимается организация ONF (Open Networking Fondation).
Концепция NFV (Network Function Virtualization) базируется на идее отделения функций сетевых устройств от аппаратного обеспечения, на котором эти функции реализуются. Такое разделение реализуется за счёт создания производительной и достаточно единообразной, централизованно управляемой виртуальной среды.
История взаимоотношений двух идей
Поскольку концепция NFV была впервые опубликована в рамках SDN форума, разработчики не могли обойти вопрос взаимодействия этих двух технологий. Вопрос о взаимодействии между SDN и NFV был включён в первый документ описывающий общие черты NFV. Описание идеи взаимодействия SDN и NFV занимало в первом документе чуть больше страницы. Авторы концепции NFV в лице ETSI (European Telecommunications Standards Institute) заявили о своей готовности к совместной работе с разработчиками SDN технологий и признали, что две технологии независимы и в тоже время способны дополнить друг друга. С точки зрения ETSI цель SDN была обозначена как создание сети пригодной для быстрого внедрения новых сервисов, а для NFV авторы документа определили целью сокращение капитальных и операционных затрат владельцев сетевой инфраструктуры.
Состояние на конец 2015 года
За три года прошедших с момента первой публикации концепции NVF идея взаимодействия SDN и NFV была существенно разработана и детализирована. В октябре ONF опубликовал документ со статусом техническая рекомендация (TR-518) и коротким названием «Взаимоотношения SDN и NFV», в декабре того же года ETSI опубликовал рекомендации по использованию SDN в архитектуре NFV.
Документ, разработанный ONF, содержит очень краткое описание концепции взаимодействия SDN и NFV в рамках архитектуры SDN. Предполагается два варианта взаимодействия SDN и NFV с возможностью сосуществования обоих вариантов в пределах одной системы. В первом случае NFV выступает для SDN в качестве заказчика и для взаимодействия использует API во втором случае NFV роль ресурса управляемого SDN контроллером и очевидно для взаимодействия используется OpenFlow. Из содержания документа можно заключить, что ONF пока уделяет незначительное внимание вопросам развития взаимодействия между технологиями SDN и NFV, что оставляет широкое поле для инициативы партнёров.
Документ, опубликованный ETSI, более детально проработан. В документе боле 120 страниц текста, из которых немногим менее половины посвящены описанию концепции взаимодействия. Вполне естественно, концепция рассматривает SDN с точки зрения NVF архитектуры. Детально рассмотрены все возможные варианты реализации элементов SDN с наложением их на архитектурные блоки NFV и интерфейсы между ними. Значительная часть концептуального раздела посвящена дизайну SDN в рамках архитектурного подхода NVF и возможным сценариям использования. На основе рассмотренных вариантов реализации выработаны 30 функциональных рекомендаций по дальнейшей проработке вопросов взаимодействия элементов SDN в рамках архитектуры NFV. Рекомендации касаются вопросов обеспечения безопасности, интерфейсов взаимодействия, способов реализации SDN контроллера и управления SDN контроллером со стороны элементов управления NVF архитектуры.
Более половины документа составляют материалы, которые обозначены авторами как информационные. В этот раздел попали описания 14-и стендов развёрнутых для подтверждения концепции использования SDN в NFV, четыре практических случая совместного использования технологий и сравнение шести SDN контроллеров с открытым программным кодом.
Заключение
На основе информации представленной в документе ETSI можно сделать заключение, что разработчики стандарта NFV серьёзно рассчитывают на получение определённых преимуществ от развития SDN в рамках в рамках архитектуры NFV и претендуют на лидирующую роль в этом процессе.
SDN, NFV, DPDK, ONP, OPNFV и так далее
Программно-управляемые сети (SDN) и виртуализация сетевых функций (NFV) постепенно выходят из лабораторий разработки и занимают свое место в рабочей среде: это более дешевые, более быстрые и более гибкие альтернативы традиционному сетевому оборудованию.
В свое время виртуализация преобразовала возможности развертывания ОС и приложений. Аналогичным образом NFV на уровне 4 и выше (уровень управления) и SDN на уровнях 2 и 3 (управление движением пакетом) преобразуют возможности управления сетевым трафиком с использованием уже существующего оборудования и операционных систем, как проприетарных, так и с открытым исходным кодом. В этой области платформа OPNFV, включая Intel Open Network Platform (ONP) Server (эталонная архитектура), поможет быстро приступить к проектированию и тестированию сети. Используйте инструкции для первоначальной настройки с помощью стандартных существующих серверных платформ с процессорами от Intel Atom до Intel Xeon.
Средства управления сетью и инфраструктурой виртуализации определяют информационную модель, набор интерфейсов API и протоколы управления, такие как OpenFlow (протокол обмена данными между уровнем управления и уровнем переадресации), разработанные для ОС OpenStack.
OpenStack (Juno-Mitaka) обеспечивает платформу для создания виртуальных машин (ВМ) и управления ими. Виртуальные машины — это базовые операционные системы для всех виртуальных функций. Каждая виртуальная машина может обладать несколькими виртуальными сетевыми интерфейсами.
OpenStack Neutron — это сетевой компонент абстрагирования сетевых конфигураций Linux с помощью общего API, действующего в качестве оболочки для сетевых функций (Open vSwitch, VLANs, iptables/netfilter и пр.).
OpenDaylight (Helium, Lithium, Beryllium) предоставляет код и архитектуру для виртуализации сетевых контроллеров (уровень управления настройкой, мониторингом и управлением)
Open vSwitch (OVS) 2.5.0 — это многоуровневый виртуальный сетевой коммутатор рабочего уровня. (OVS может быть узлом, подключенным к контроллеру OpenDaylight)
Data Plane Development Kit (DPDK) v16.04 — это набор библиотек уровня данных и драйверов сетевых адаптеров, образующих платформу программирования для быстрой обработки сетевых пакетов на процессорах общего назначения.
Примечание. Mitaka содержит OVS 2.5 с ускорением за счет DPDK 2.2
Intel Open Network Platform (ONP) Server — это эталонная платформа со сценариями и другими ресурсами для быстрой настройки тестовой сети. Эта платформа основана на решении OPNFV, которое представляет собой эталонный аппаратно-программный комплекс для развития NFV.
Технологии Intel для повышения производительности
Корпорация Intel (включая Wind River) вносит значительный вклад в разработку DPDK и Linux. Недавно разработчики Intel объединили Intel DPDK vSwitch с основной ветвью Open vSwitch, поэтому в Neutron можно использовать алгоритмы ускоренной обработки пакетов Intel, избегая проприетарных подключаемых модулей. Логика коммутации построена на основе библиотеки Intel DPDK, за счет чего существенно повышается производительность обработки пакетов. При этом функции коммутации могут быть интегрированы как в основной вычислительный сетевой узел OpenStack, так и в гостевые узлы.
В пакете Intel DPDK также содержатся примеры переадресации на уровне 3, балансировки нагрузки и таймеров; все эти примеры помогают ускорить разработку. Доступ к ресурсам предоставляется как к набору виртуальных функций: ресурсы доступны для множества виртуальных машин и позволяют ускорить обмен данными между виртуальными машинами.
Кроме того, Intel разрабатывает прототипы решений Open NFV (OPNFV) на платформе OpenDaylight, чтобы задействовать возможности повышения производительности сети.
Технология ускорения Intel QuickAssist предоставляет возможность ускорения различных алгоритмов (шифрование, сжатие, разгрузка) с поддержкой до 14 раздельных виртуальных сред. Технология Intel QuickAssist поддерживается процессорами Intel EP80579 (интегрированный процессор), Intel Xeon серий E5-2600 и E5-2400, Intel Core, Intel Pentium и Intel Celeron с наборами микросхем серии Intel 89xx.
Intel также предоставляет Intel Open Network Platform Server. Эталонная архитектура Intel ONP Server включает оборудование, оптимизированное для полного набора последних версий ПО с открытым исходным кодом в виде проверенного шаблона для быстрой разработки. Эталонная архитектура включает спецификации, отчеты о тестировании, сценарии оптимизации и поддержку сетевых интерфейсов Intel Ethernet от 1 до 40 Гбит/с (FTXL710-AM2 4x10GbE).
Какие приложения SDN/NFV доступны?
Перечень партнеров по разработке решений приведен здесь.
Где найти дополнительные сведения?
Intel поддерживает несколько сайтов, включая следующие.
Эволюция сети к SDN & NFV
Почему идет смена технологических концепций в среде сетей передачи данных, какие у этого причины и как изменится жизнь сервис-провайдеров через реализацию современных трендов?
Исторический экскурс
Развитие технологий сетей передачи с 1969 года (ARPANET) было направлено на то, чтобы каждый аппаратный компонент был независим от других компонентов. Протоколы взаимодействия работали по принципу обмена контрольной информацией, которая использовалась алгоритмами для анализа топологии и построении моделей взаимодействия между устройствами.
Есть версия, что такой подход был специально спроектирован для повышения шанса выживания сетей передачи данных в условиях военного конфликта, при котором часть устройств либо линий связи может выйти из строя, и оставшимся компонентам сети необходимо будет самостоятельно принять решение о том, какая топология осталась целостной и работоспособной. То есть децентрализация работы сети была заложена как цель.
Все разработанные протоколы динамической маршрутизации (RIP, OSPF, IGRP, BGP) и протокол ветвящегося дерева (STP) были построены на этом принципе – устройства как равноправные обмениваются имеющейся информацией о своих соединения с соседями и самоорганизуются в общую топологию, которая работает как единая сеть.
Достигнув актуальной на тот момент цели — автономности, со временем, когда нагрузка на сеть выросла, стало очевидно, как неэффективно используются текущие соединения. Работа сети на втором уровне OSI стала приводить к отключению избыточных соединений, тем самым снижая общую утилизацию сети передачи данных. Работа сети на третьем уровне OSI стала приводить к асимметричной маршрутизации, что могло вызвать непоследовательную доставку пакетов, что приводило к росту занятого объема буфера на принимающих устройствах.
Другой проблемой стал тот факт, что сетевые функции (Firewall, Load Balancing, Mirroring), которые реализовывались в определенном физическом месте сети передачи данных могли находится далеко в топологии от того места, где трафик генерировался. Так как трафик должен был быть доставлен до аппаратного устройства и только там быть, например, отфильтрованным, то это приводило к большей утилизации и снижению эффективности, чем если бы трафик был отфильтрован в месте генерации трафика.
С тех пор прошло немало времени и хоть угроза военных конфликтов осталась, технологическими лидерами было принято решение, что теперь цель централизации отвечает современным потребностям. Такой подход привел к необходимости пересмотра модели работы сети передачи данных в сторону разделения функций управления и функций передачи данных. Было принято решение все функции управления сконцентрировать в единой точке — контроллере, который собирал бы информацию с устройств передачи трафика и принимал решение о том, как этим трафиком управлять.
Централизация позволяет повысить эффективность загруженности всех соединений и утилизировать по максимуму ресурсы аппаратных устройств. Разработанный протокол Openflow решал задачу управления плоскостью передачи трафика, программируя коммутаторы действиями, которые должны быть совершены с трафиком. При этом модель принятия решения о том каким образом должен быть передан трафик внутри контроллера плоскости управления могла быть реализована совершенно по другим математическим моделям, чем те, на которых основаны известные протоколы динамической маршрутизации. Разница в том, что современные протоколы маршрутизации исходят из принципа обмена информацией между точками о топологии. Но если вся топология хранится в одном месте, то нет необходимости в алгоритмах обмена информацией. Есть лишь необходимость использовать информацию о топологии для того, чтобы направить трафик из точки А в точку Б. При централизованном подходе решения о передаче трафика могут быть не универсальны. То есть нет необходимости в передачи всего трафика между двумя точками по одному и тому же пути. Одна часть трафика может идти по одному пути, а другая использовать альтернативный путь в той же самой топологии. Такой подход повышает эффективность за счет максимальной утилизации имеющейся сетевой инфраструктуры.
Другое преимущество в том, что, обладая информацией о том, какие политики должны быть применены к различным типам трафика в различных точках входа трафика в сеть, есть возможность применить сетевую функцию непосредственно в этой точке сети. Если представить, что сотни сетевых функций можно отделить от аппаратной платформы и реализовать в виде программы, в которую в качестве входных данных поступает управляющая информация (какие политики необходимо применить к трафику) и задать входящий и исходящий интерфейс для трафика, то тогда эту сетевую функцию можно запускать на стандартных операционных системах на x86-серверах. Запуская эти программы в точках генерации либо обмена трафиком, центральный контроллер может программировать коммутаторы для передачи необходимого типа трафика внутрь сетевой функции. Трафик, после обработки сетевой функцией, возвращается в плоскость передачи данных и передается до конечного получателя.
Одним из аргументов принятия такой модели является снижение стоимости сети передачи данных по причине того, что конкретные сетевые функции, реализованные на специализированной аппаратной платформе, предлагаются по более высокой цене, чем реализация тех же функций на универсальной вычислительной платформе. Производительность специализированных платформ всегда была выше и это имело значение в эпоху не очень производительных универсальных процессоров, но современные тренды нивелировали это различие и теперь даже на общих CPU, за счет увеличивающегося быстродействия, стало возможно выполнение указанных сетевых функций при необходимой производительности.
Еще одним преимуществом стало то, что при наличии возможности выполнить сетевую функцию в любом месте сети передачи данных отпала необходимость в гигантской производительности в одном устройстве, ведь можно распределить требуемую производительность по всем точкам генерации или обмена трафиком. Данный факт позволяет очень быстро масштабировать производительность сетевой функции при резком увеличении объема трафика. Такое регулярно наблюдается во время значимых событий в жизни всего человечества, например, чемпионат по футболу, проведение Олимпиады или трансляция свадьбы английского принца. В такие моменты люди записывают видео и делают фотографии, заливают всё в «облако» и обмениваются ссылками. Всё это приводит к взрывному росту объемов трафика, которые нужно уметь перенаправить в нужные точки.
Сетевые функции сжатия трафика в режиме реального времени (Real-Time Compression, WAN Optimization), перенаправления запросов на ближайшие точки (CDN), балансировки нагрузки между фермой серверов (Load Balancing) требуется развернуть в автоматическом режиме и в нужном масштабе и предоставить к определенному виду трафика. Определить данный тип трафика, запустить виртуальные машины с требуемой функцией и перенаправить в них трафик помогают системы MANO с функциями auto-provisioning, auto-scaling, автоматической настройкой перенаправления трафика.
Оркестраторы (management and operation) данного процесса должны обладать целым набором способностей:
1) Управлять физической инфраструктурой: сетями передачи, хранилищами данных, серверами;
2) Используя платформы виртуализации создавать на основе физической инфраструктуры необходимые инстансы: виртуальные машины, виртуальные LUN, виртуальные сети;
3) Принимать телеметрию от текущих сетевых устройств для проведения анализа и принятия решения о предоставлении дополнительных сетевых функций;
4) Запустить из шаблонов требуемые сетевые функции и загрузить в них конфигурацию, соответствующую требуемой задаче;
5) Анализировать состояние запущенных сетевых функций для принятия оперативных решений в случае отказов, аварий либо перегрузок;
6) Ликвидировать запущенные сетевые функции в случае, когда необходимости в их работе больше нет и делать это на основе автоматических данным из телеметрии либо по запросу администратора;
7) Передать в бизнес ИТ-системы информацию об используемых ресурсах для проведения расчетов биллинга.
Реализация данного функционала позволит резко ускорит время предоставления услуг от сервисных операторов к клиентам и потребителям. Сокращение времени выхода услуги на рынок повысит монетизацию инфраструктуры и приведет к дополнительной прибыли. Пользовательский опыт от более плавного и быстрого потребления контента улучшит эмоциональное восприятие потребителями сервиса, что, в конечном итоге, повысит привлекательность операторов связи как клиентоориентированных провайдеров.
Enterprise CPE virtualization
Изменение работы провайдеров с предоставления обычных каналов связи («трубы») к созданию набора услуг с добавленной стоимостью позволит продолжать предоставлять высокорентабельный сервис, и в долгосрочной перспективе не приведет к снижению выручки за счет повышения конкуренции на рынке инфраструктурных провайдеров.
Еще одной возможностью для повышения прибыли для сервис-провайдеров является модель перехода к умным оконечным точкам (CPE). Переход от цифровых модемов к управляемым роутерам позволяет достичь нескольких целей. В данный момент для подключения удаленного филиала заказчика услуг сервис-провайдера требуется устройство подключающее локальную сеть филиала к сети оператора в нужную выделенную сеть, организованную либо посредством технологии MPLS либо в случае legacy провайдеров посредством технологии ATM. В таком случае необходимость совершать различные операции с трафиком заказчика (предоставлять дополнительные сетевые функции) приводила к необходимости доставлять этот трафик от клиента до ядра сети оператора, в котором располагаются устройства, реализующие такую сетевую функцию, и уже на ядре сети обрабатывать трафик по заданным политикам. Это приводило к повышенной утилизации «последней мили» и магистрали оператора тем трафиком, который можно было бы обработать ближе к источнику генерации. С другой стороны устройства оконечных точек являлись всего лишь либо аналогово-цифровыми преобразователями либо достаточно простыми IP-устройствами, без возможности проактивного мониторинга или удаленной настройки.
Замена таких устройств на CPE нового поколения позволит решить несколько задач. Дистанционное управление новыми CPE позволит производить zero-touch provisioning с помощью двухфакторного метода, используя активирующие URL. Таким образом, можно будет напрямую с завода-производителя отправлять устройства конечным клиентам, и уже на месте активировать их с нужной конфигурацией, в том числе неквалифицированным персоналом. Помимо этого, реализация на CPE с помощью слоя виртуализации контейнеров или виртуальных машин с нетребовательными к аппаратной платформе сетевыми функциями, позволяющими непосредственно на оконечной точке предоставлять услуги с добавленной стоимостью, даст возможностью клиентам в магазине приложений активировать для своей точки подключения тот функционал, который им требуется: антивирусная защита, фильтрация спама, родительский контроль и так далее. Оператор, взимая дополнительную плату за эти функции, получит широкую возможность наращивать выручку за счет быстрого и бесшовного внедрения новых SDN-приложений.
Для корпоративных заказчиков оперативное развертывание новых офисов в точках присутствия Интернета станет реальностью – не потребуется перенастраивать множество IPSec VPN туннелей на новую адресацию, в том случае если CPE будет автоматически строить наложенные туннели посредством технологий VXLAN или MPLSoGRE между множеством CPE и центральным центром обработки данных. Централизованное управление удаленными офисами позволит оперативно менять программное обеспечение на CPE и централизованно хранить конфигурационные данные. Средства информационной безопасности можно будет активировать из единой консоли управления сразу для всей организации. Администратор информационной безопасности по достоинству оценит отсутствие возможности сотрудников в филиале иметь доступ к консоли роутера, потому как политики могут быть настроены только на SDN-контроллере либо оркестраторе.
Выводы
Используя упомянутые тренды – переход на централизованный control plane, замена специализированных устройств с сетевыми функциями на x86-сервера с программными NF, создание системы управления виртуальными ресурсами с передачей управляющих сигналов в различные компоненты системы OSS\BSS, а также автоматизация и виртуализация устройств оконечных подключений приведет к повышению скорости вывода услуг на рынок, создаст экосистему для предоставления сервисов с высокой добавленной стоимостью и повысит привлекательность провайдера для конечных клиентов.
Обработка трафика в облаке. Кому нужна виртуализация сетевых функций (NFV)?
Сегодня хочу рассказать о концепции, которая в ближайшие несколько лет в корне изменит дизайны сетей связи и телекомуникационных услуг — о виртуализации сетевых функций, Network Functions Virtualization.
В отличие от повсеместно распространённой виртуализации приложений, сетевые функции перенести в облако гораздо сложнее, а некоторые из них вообще невозможно. Я расскажу о задачах и принципах NFV, об истории этой инициативы и её нынешнем статусе, об ограничениях и недостатках этого подхода, поделюсь своими мыслями о том, какие задачи с её помощью решаемы, а какие — принципиально нет.
От виртуализации приложений к виртуализации сетевых функций
Если мы необходимое нам приложение отвяжем от оборудования и заставим работать в изолированном программном контейнере вместо «железа», мы сможем назвать это приложение виртуализированным. Идеи виртуализации сопровождают IT-индустрию c момента появления первых ЭВМ — с 60ых годов прошлого века инженеры решали задачи разделения одного большого мэйнфрэйма на несколько изолированных проектов. В «нулевых» человечество вновь столкнулось с похожей задачей — на этот раз понадобилось эффективно разделять серверные ресурсы между множеством их потребителей-клиентов. Помимо самой возможности «нарезать» аппаратный ресурс, виртуализация несёт колоссальные выгоды.
Сосуществование нескольких приложений на общем железе выгоднее, чем работа их на выделенных серверах — виртуализированному решению для такой же производительности требуется меньше серверов; такое решение более компактно, расходует меньше электроэнергии, требует меньше сетевых портов и соединений. Новые способы доставки приложений в виде шаблона виртуальной машины позволяют покупателю отказаться от навязываемого ранее аппаратного сервера, но при этом получать все преимущества «коробочного» решения. Возможности современных гипервизоров и систем управления привнесли много нового в плане масштабирования, отказоустойчивости, различных оптимизаций. Виртуализация переформатировала ИТ-рынок: сформировалось понятие «облачных» сервисов различных моделей — SaaS, IaaS, PaaS. Однако, закономерности программно-прикладной сферы не в полной мере применимы к сфере сетевой.
Проблема, которую должна решить NFV-виртуализация
Современные телекоммуникационные сети содержат большое количество фирменного оборудования, как правило, очень специализированного, заточенного под конкретную операцию: одно устройство обеспечивает NAT, другое ограничивает скорость доступа и считает трафик, третье осуществляет родительский контроль и фильтрацию содержимого, еще одно отвечает за функции фаервола. Для сложившегося разделения функций между сетевой аппаратурой есть несколько причин: во-первых, каждый сетевой вендор, так уж сложилось, специализируется на нескольких функциях, в которых данная конкретная компания имеет свои наработки и ноу-хау. Другая вероятная причина сводится к очень специфической начинке таких устройств, имеющей мало общего с серверами общего назначения. Поэтому, оператор-эксплуатант таких решений поневоле вынужден любой ценой поддерживать сложившееся «разнообразие». Запуск новой услуги требует установки нового комплекта оборудования, поддерживающего необходимую функцию. Это, в свою очередь, требует выделения дополнительных площадей, дополнительного электропитания, логистики «железа», его монтажа и пусконаладки.
Сейчас очевидно, что сеть из физических «коробок», каждая из которых выполняет лишь одну-единственную функцию, это не самая оптимальная модель для развития. Помимо высоких капитальных и операционных затрат, такой дизайн очень инертен, не позволяет оператору наращивать портфель предоставляемых услуг так быстро, как того требуют акционеры. Сеть должна быть намного более гибкой и динамичной, способствовать внедрению любого нового сервиса, его быстрой активации по запросу абонента и освобождению занятых ресурсов при деактивации услуги.
Примеры сетевых функций. Какие возможно виртуализировать, а какие не очень
Функции, которые выполняют сетевые устройства, значительно различаются своими характеристиками и возможностями по их виртуализации. Некоторые целесообразно перенести в облако, а другие — категорически нельзя отделять от сетевой аппаратуры. Передача данных так или иначе связана с перемещением сетевых пакетов из одной географической точки в другую, и в каждой из этих точек, на каждом узле связи, должно, как минимум, присутствовать реальное сетевое устройство с нужным количеством сетевых портов — коммутатор или маршрутизатор.
Пересылка — forwarding/routing/switching — это самая примитивная операция над сетевым пакетом, которую выполняет сетевое устройство. По сути — копирование с одного порта на другой, иногда с заменой определённых полей фрэйма или пакета. Данная операция на большинстве платформ выполняется специальным комплексом, «заточенным» под быстрый поиск соответствия в специальной, троичной памяти TCAM и замену нужных полей пакета «на лету». Специализированный ASIC, используемый в маршрутизаторах и коммутаторах (его ещё называют Network Processor / Network Processing Unit) для таких примитивных задач более приспособлен — работает быстрее, расходует меньше энергии, примитивен, компакетен и дёшев.
Для сравнения, реализация такого же функционала программными средствами на general purpose CPU, с обращением к внешним данным через сложный стэк ввода-вывода (через ядро и драйвер), резко уменьшила бы производительность, да и в формате сервера невозможно было бы обеспечить нужную плотность портов.
Слайд Cisco о преимуществах NP, и о влиянии фич на производительность forwarding’а
Пересылку данных вместе со всей низкоуровневой логикой, которая обрабатывает каждый пакет, условно выделяют в плоскость передачи данных, Data Plane. Почти вся сигнализация — протоколы обнаружения соседства, протоколы маршрутизации и управления трафиком, различные механизмы балансировки, предотвращения петель, телеметрии, управления сервисами и полосой пропускания, авторизации, аутентификации и аккаунтинга — все они относятся к плоскости управления — Control Plane. Чем интенсивнее Control Plane и чем «тоньше» Data Plane — тем более целесообразно виртуализировать эту сетевую функцию, перенести её с сетевого железа на сервер. И наоборот, чем «толще» Data Plane и чем примитивнее Control Plane — тем функция сложнее в виртуализации, и лучше её оставить внутри сетевого устройства.
CE (Customer Edge) маршрутизаторы имеют очень широкий функционал Data Plane — от простого роутинга до поддержки специальных методов маршрутизации PBR/ABF, от примитивных ACL до сложного Zone-Based фаерволлинга, такие роутеры подерживают различные стандарты энкапсуляции и туннелирования (GRE/IPIP/MPLS/OTV), трансляцию сетевых адресов (NAT,PAT), сложные QoS-политики (policing, shaping, marking, scheduling). Функционал Control Plane тоже очень широк — от примитивных ARP/ND до сложнейших фич типа MPLS Traffic Engineering. Подобный Branch-маршрутизатор, с нагрузкой несколько десятков или сотен мегабит в секунду может быть прекрасно виртуализирован — на промышленном сервере можно разместить десяток-другой таких элементов.
ниша для применения виртуального CE-маршрутизатора Cisco CSR1000v относительно аппаратных платформ
P/PE маршрутизаторы, имеющие похожий функционал, предназначены для установки сети оператора, и их data-plane обрабатывает колоссальное количество трафика: от сотен гигабит до десятков терабит в секунду. При этом они должны иметь максимальную плотность портов. Стоит ли говорить, что сервер традиционной архитектуры не рассчитан на такие объемы данных, которыми оперируют маршрутизаторы провайдерского класса. Их DataPlane слишком «толст» и не интересен для виртуализации. По аналогии с операторскими роутерами, почти невозможна виртуализация высокопроизводительных коммутаторов, широко использующихся в ЦОДах.
16x40GE-портовый модуль простенького коммутатора. Под большим радиатором скрыт NPU Broadcom Trident II, обеспечивающий 640 честных Gbps.
Единственное, что иногда может или должно быть виртуальным применительно а таким великанам — лишь плоскость управления, полностью или частично. Data Plane в этом случае полностью остаётся на устройстве, а сама пересылка пакетов выполняется по таблицам, запрограммированным внешней системой. Такой системой может являться не только традиционный контроллер SDN в узком понимании (работающий по OpenFlow стандарту) — это может быть любой оркестратор, медиатор, драйвер сетевого элемента с поддержкой любого доступного интерфейса (CLI, NetConf, SNMP).
Под эту же категорию подпадает такой традиционный элемент, как скажем, BGP Route-Reflector, «разливающий» по сети таблицы маршрутизации BGP. Такие элементы хорошо подходят для виртуализации, но на сети оператора их считанные единицы. NFV-концепция касается скорее динамических, абонентских, массовых, а не инфраструктурных сервисов.
Забегая вперёд скажу, что вынесенный Control Plane и такое понятие как SDN соотносятся с NFV в несколько другом ключе — скорее как элемент сетевой инфраструктуры для самого NFV, а не как функция.
виртуализованный BGP Route-Reflector Juniper на стандартном сервере
CPE (Customer Premises Equipment или Residential Gateway) — та самая коробочка, устанавливаемая в квартире абонента, куда приходит кабель от оператора. Она раздает интернет на все устройства в квартире и является центральной точкой его домашней сети: на ней работает DHCP-сервер, кэширующий DNS-сервер, клиент протокола, по которому «общается» с провайдером: PPPoE/L2TP/PPTP/DHCP/802.1x. Из dataplane-фич определяющими также являются NAT и Firewall. От коробочки с портом для включения операторского кабеля в любом случае никуда не деться, и требования к устройству остаются прежними: маленький, симпатичный, беспроблемный, дешевый девайс. Эти чаяния давно уловили производители электроники, и на нашем рынке доступны такие устройства на любой вкус и кошелек. Надо отдать должное вендорам наиболее распространенных чипсетов таких «мыльниц»: их вычислительная способность может быть очень высокой, а такие ресурсоемкие функции как NAT и коммутация могут быть реализованы аппаратно.
Такие устройства на данный момент не отвечают требованиям операторов скорее из-за недостатка функционала: провайдер зачастую не может оценить их состояние и загрузку, они часто являются узким местом для предоставления услуги; оператор не видит локальную сеть абонента и не управляет настройками CPE, что затрудняет диагностику; отсутствие необходимых фич на этом элементе затрудняет запуск новых услуг; обновление ПО этих устройств, как правило, проводится несвоевременно, что привносит дополнительные риски. Я уверен, что в ближайшее время нас ждет переосмысление модели таких услуг, как родительский контроль, интернет-кинозал, управление умным домом, бэкап и репликация, хранение и просмотр видезаписей с домашних камер видеонаблюдения, сервисов наподобие «рабочего стола школьника» и т.д., и значительную роль в этом сыграет CPE, виртуализованные в домене оператора. Наличие индивидуального абонентского vCPE-контейнера, через который проходит абонентский трафик, вероятно, изменит принцип учёта потребления услуг: объектом тарификации, наконец, сможет стать не только трафик, а вычислительный или дисковые ресурс. «Коробочка с антенной» в такой услуге останется на своём месте в абонентской квартире, но будет иметь самый минимальный набор функций.
слайд Alcatel-Lucent наглядно иллюстрирует перенос сетевых функций с CPE-устройства в облако
BNG/BRAS — так называются роутеры-шлюзы, через которые абоненты оператора выходят в Интернет. Именно эти маршрутизаторы выполняют «дозирование» и учёт потребляемых услуг в соответствии с тарифным планом по каждому из пользователей. На эти устройства приходится колоссальная вычислительная нагрузка — каждого абонента необходимо авторизовать в AAA-системе по протоколу RADIUS, получить уникальные правила и атрибуты по каждой из сессий чтобы создать для каждого свой, уникальный сервис со своими классами и ограничениями, правилами учета и адресации, политиками QoS и ACL. Этот элемент отвечает за назначение адресов, поддерживает работу сигнализации ARP/ND/PPP/LCP/DHCP с десятками и сотнями тысяч абонентских устройств. По каждой сессии BNG должен понимать сколько трафика попало в тот или иной класс, сколько времени длилась сессия, кому перекрыть доступ в Интернет, кого «завернуть» на портал, а кому увеличить скорость. Нужно ли говорить, что эти железяки должны обладать очень производительным Control Plane? BNG имеет сетевые процессоры еще более сложные, чем на P или PE платформах! Помимо пересылки пакетов эта умная железка вытворяет с ними более интересные «упражнения»: каждая абонентская сессия программируется в сетевой процессор, по каждой может вестись по несколько счётчиков, у каждой могут быть свои правила, свои классификаторы, свои скорости доступа.
Такая «пакетная магия» невозможна без дополнительных аппаратных средств: сотен тысяч счетчиков и огромных объемов специальных типов памяти: TCAM’а для классификаторов и списков доступа, пакетной памяти для организации очередей. Некоторые технологии абонентского доступа используют туннелирование (L2TP/PPPoE), и тогда на BNG возлагается ещё и энкапсуляция-декапсуляция данных, а чем больше операций выполняется над сетевым пакетом, тем больше преимуществ имеет ASIC перед x86. Впрочем, виртуализованный BNG может быть интересен при суммарных объёмах трафика не более нескольких единиц Gbps, с очень динамичными сервисами и большим количеством сессий и bringup/teardown событий. Хороший пример — WiFi на транспорте: с малым объемом трафика, высокой динамикой, с наличием дополнительных сервисов вроде баннерной рекламы, которые можно разместить на том же кластере серверов, где развернут vBNG.
NAT — трансляция сетевых адресов — в связи с возникшим дефицитом публичных адресов, находящихся в распоряжении операторов связи, эта фича стала в последние годы востребована не только в Enterprise и SMB, но и в SP-сегменте. NAT-функционал относится к одной и самых ресурсоёмких Data Plane функций и требует значительных вычислительных ресурсов. Сложность её связана с огромным количеством одновременно отслеживаемых соединений. Открытие лишь одной этой страницы (со всеми объектами и картинками) создала, использовала и закрыла сотни трансляций на NAT устройстве. Конечно же, в том случае, если ваш оператор использует NAT. Клиенты пиринговых файлообменных сетей генерируют многие тысячи трансляций на один мегабит полосы.
Развитие упрощённых режимов NAT (так называемых Carrier-Grade режимов) позволило добиться увеличения производительности, однако выполнение NAT на сетевых процессорах сегодня скорее исключение, чем правило. Большой объём трафика, который должен обслуживать комплекс NAT сегодня реализуется на высокопроизводительных серверах, устанавливаемых в слот одного из центральных маршрутизаторов на сети. Данный подход позволяет избежать внешних сетевых соединений — комплекс подключается напрямую на backplane роутера и выглядит для маршрутизатора как еще один линейный модуль.
Мультисервисный маршрутизатор Huawei ME-60 c установленным SFU-модулем, на котором может быть запущен Carrier-Grade NAT
Еще одна яркая характеристика NAT — толщина — его возможно разделить на более мелкие части путём дробления пула адресов, но это сделает его менее эффективным. Чем он централизованнее — тем лучше используется доступный адресный ресурс. Из-за толщины, больших объемов трафика и большой вычислительной нагрузки NAT является интересным кейсом для концепции распределённого NFV (dNFV), когда сетевые функции логически централизованы (имеем единый пул адресов и ресурсов и единую точка управления), но при этом территориально распределены по узлам и находятся топологически близко к узлам транзита обслуживаемого трафика.
Security: Функционал сетевой безопасности по своим свойствам близок к NAT — также характеризуется огромным количеством и динамикой состояний (Stateful FW, NGFW, IDS, IPS, Антивирус, Антиспам), большим потреблением памяти и ресурсов CPU, что делает его интересным для виртуализации. В отличие от NAT, этот сервис нельзя назвать толстым. Его можно делить вплоть до соотношения 1 абонент на 1 контейнер, поэтому данная услуга считается одним из самых явных use-case для NFV.
DPI — глубокая инспекция пакетов — функция, позволяющая оператору связи ограничивать или определять уровень сервиса (квоту, скорость) для определённого типа приложения или содержимого. Одним из примеров может служить такая распространённая услуга «родительский контроль», при активации которой организуется прохождение абонентского трафика через фильтр на основании класса посещаемого ресурса. Data Plane этого сервиса обычно реализуется программными средствами, а интересная оператору производительность может начинаться с достаточно малых величин — это тоже один из ярких юз-кейсов.
MMSC/IMS — IP Multimedia Subsystem — «пограничный» элемент для предоставления голосовых сервисов, трансляции телевидения, стриминга видео для таких приложений, как домашний кинотеатр или видеонаблюдение, различных мультимедийных меню и сервиса обмена мгновенными сообщениями. Отлично дополняет портфолио операторских услуг.
Инфраструктурные элементы мобильных сетей GSM/UMTS/LTE/WiFi: беспроводные контроллеры, EPC, IMS, CSN, SMSC, PCC, GWc, GWu, PGW, SGW, HSS, PCRF — эти функции имеют высокие требования по вычислительным ресурсам, а по объёму передаваемых данных — скорее умеренные. Лишь некоторые из них имеют ряд особенностей, связанные с обеспечением необходимых параметров QoS.
Для полноты картины упомяну такие приложения, как DHCP, DNS, HTTP-серверы (с широчайшим выбором доступных WEB-приложений), HTTP Proxy (включая различные оптимизаторы, ускорители и URL-фильтры), SIP Proxy и т.д. Их можно относить к сетевым функциям, можно спорить и относить их к Application-уровню модели OSI, но, в любом случае, они востребованы и легко виртуализируемы, и также могут служить составными «кирпичиками» услуг нового поколения.
Развитие и текущий статус стандарта NFV
Итак, с самими функциями более-менее ясно. Осталось понять каким образом их возможно комбинировать друг с другом, как обеспечивать изоляцию сетевых соединений между этими виртуальными элементами, безопасность, масштабируемость и отказоустойчивость, как сделать систему прозрачной и управляемой, в конце концов, какое выбрать оборудование — вычислительное и сетевое — и как его настроить. Ради ответов на эти вопросы семь крупнейших зарубежных провайдеров (AT&T, BT, Deutsche Telekom, Orange, Telecom Italia, Telefonica и Verizon) решили объединить свои усилия в исследованиях и в 2013 г. создали рабочую группу под эгидой Европейского института по стандартизации в области электросвязи ETSI. Позже к их экспериментам присоединились десятки производителей сетевого оборудования и ПО, и на данный момент в NFV ISG входит несколько сотен участников.
На сетях участников-операторов были организованы несколько тестовых зон и распределены темы исследований и наиболее интересные вопросы для изучения. Практические наработки фиксируются, обобщаются и публикуются для последующего комментирования и исправления и по результатам работы формулируются новые вопросы. Ещё год назад технология NFV была мало наполнена конкретикой, но с каждой новой публикацией мозаика будущего стандарта выглядит всё полнее.
Примечательно, что успешный опыт «пилотирования» зачастую перенимается и тиражируется «как есть», и даже несмотря на «проприетарность» и пока ещё отсутствие полноценного открытого стандарта, ряд вендоров, желающих занять эту востребованную нишу, уже предоставляет не только сами виртуальные элементы, но и целостные решения NFV, разного масштаба, разной степени готовности и полноты, по-разному реализованные.
В 2014 году к вендорско-провайдерским инициативам присоединилось OpenSource сообщество Linux Foundation, чем был дан старт проекту платформы с открытым исходным кодом — OPNFV, который должен расширить интерес индустрии к использованию общедоступных и открытых продуктов в этой нише. Например, для сети подошёл бы OpenvSwitch и OpenDaylight, для слоя виртуализации — OpenStack, в качестве хранилища — Ceph, в роли гипервизора — KVM, хостовая и гостевая ОС — Linux. Сегодня доступен первый релиз этого продукта, Arno. Активности по стандартизации NFV также замечены в таких отраслевых организациях, как, например, MEF или TM Forum.
Архитектура и компоненты NFV
В соответствии со спецификациями ETSI, NFV домен состоит из трёх условных компонентов:
1. Virtualized Network Functions (VNF) — те самые сетевые функции, о которых шла речь выше. Как правило, под VNF-элементом подразумевается виртуальная машина или набор виртуальных машин, и их совокупность определяет верхнюю плоскость решения. Т.к. VNF-элементу предстоит быть динамически настроенным, предусмотрен еще один суб-блок в его составе или находящийся над ним — Element Management System (EMS).
2. NFV Infrastructure (NFVI) — физические ресурсы, их компоненты и настройки: сетевые устройства, хранилища, серверы и дополняющие их виртуальные ресурсы: гипервизоры, система виртуализации, виртуальные коммутаторы. Они, находясь на нижнем уровне, формирует нижнюю плоскость «пирога».
3. NFV Management and Orchestration (MANO) — «обвязка», управляющая жизненным циклом виртуальных элементов и нижележащей инфраструктурой — обозначается вертикальным прямоугольником, имеющим связи с обеими плоскостями решения через компоненты (Managers), отвечающие за управление конкретной плоскостью. Над менеджерами расположен оркестратор, роль которого заключается в разделении команд на два домена, в которых требуется произвести изменения.
Над всеми тремя основными элементами расположены традиционные операторские Operations/Business support systems (OSS/BSS): системы мониторинга, управления, биллинга, провиженинга услуг, порталы самообслуживания, в которые NFV интегрируется либо как единый элемент (через MANO), либо интерфейсами NFVI- и VNF-плоскостей по отдельности.