Обзор открытых сетевых стандартов

Алекс Хентрон-Айвейн (Alex Henthorn-Iwane) | QualiSystems

В данном обзоре рассматриваются сетевые стандарты OpenDaylight, OpenSwitch, OpenStack и OpenFlow, разрабатываемые в рамках движения open source. Это масштабные сетевые проекты, нацеленные на создание программно-определяемых сетей (SDN).

В данной статье рассматриваются особенности некоторых отрытых сетевых стандартов и их влияние на развитие телекоммуникаций, стратегию развития информационных технологий и технологий построения сетей. Говоря на метауровне, важно отметить, что благодаря движению «open source», разработчики, занятые в сетевых проектах, всё больше внимания уделяют API-интерфейсам, DevOps-автоматизации и необходимости ухода от ручных способов проектирования и управления сетями в сторону автоматизированных. Вполне естественно, что в каждом рассматриваемом стандарте есть нечто своё, отличное от других. Начнём с OpenDaylight.

OpenDayLight: проект открытой подсистемы управления SDN

OpenDaylight – это проект конcорциума Linux (Linux Foundation), цель которого – развитие программно-конфигурируемых сетей (software-defined network, SDN) и виртуализации сетевых функций (Network Functions Virtualization, NFV). Он был запущен в 2013 году и очень быстро (менее чем за два года) стал крупнейшим проектом с открытым исходным кодом, в котором уже в начале 2014 года участвовало 266 разработчиков, написавших более одного миллиона строк программного кода.

Рис. 1. Открытая платформа SDN-сети и место в ней OpenDaylight

На что же конкретно направлен проект OpenDaylight? Самый понятный ответ – создание открытой подсистемы управления (control plane) SDN-сети, которая включает несколько уровней сетевого администрирования (рис. 1):

– Уровень подсистемы данных (data plane), которая состоит из физических и виртуальных устройств в сети, от которых данные через различные протоколы (OpenFlow и не только) поступают на более высокий уровень – уровень управления.

– Поверх уровня подсистемы данных находится платформа программного контроллера OpenDaylight, выше которого расположены API-интерфейсы с прикладным уровнем/уровнем оркестрации («северный мост»), а ниже («южный мост») – множество протоколов и API-интерфейсы к расположенному ниже оборудованию передачи данных.

– На вершине этого «пирога» находится уровень оркестрации (orchestration) и прикладной (application) уровень. Он может выглядеть, как, например, плагин для OpenStack Neutron.

OpenDaylight – это попытка выступить в роли контроллерной «швейцарии», которая обеспечит совместимость с любым типом коммутирующей аппаратуры через различные протоколы и интерфейсы, такие как OpenFlow, Path Computation Element Protocol (PCEP), NetConf и т.п. Контроллер OpenDaylight исполняется на своей собственной виртуальной Java-машине и поддерживает инициативу ODGi (the Open Service Gateway).

Вендоры и будущее OpenDaylight

Множество сетевых вендоров создали уже так много вариантов реализаций OpenDaylight, что его недоброжелатели уверены, что проект, несмотря на то, что выступает под флагом открытости, возможно, законсервирует позиции сетевых грандов. Основателями OpenDaylight стали компании Cisco и IBM, затем к сообществу присоединились Brocade, Juniper, Microsoft, Intel и другие. Весомая порция кода OpenDaylight приходится на крупных сетевых вендоров.

В частности, говоря о вкладе Cisco в OpenDaylight, часто рассматривается уникальный подход Cisco к SDN-сетям и тип контроллера, который следует использовать. Аналитик еженедельника «Мир сетей» (Network World) Джим Даффи (Jim Duffy) назвал детище Cisco – протокол OpFlex – «убийцей OpenFlow», что, возможно, несколько преувеличено, однако ясно, что в качестве будущего ядра OpenDaylight разработчики Cisco видят отнюдь не OpenFlow. Протокол OpFlex может стать ключевой частью релиза OpenDaylight Lithium (литий), который последует за OpenDaylight Helium (гелий). Однако Гуру Парулкар (Guru Parulkar), директор Open Networking Lab., считает, что такая особенность OpFlex, как «видимость» для приложений специфики устройств и связанные с этим ненужные сложности, может стать одной из причин создания для OpenDaylight альтернативного протокола.

Что касается вендоров, то им, конечно, сложно соблюсти баланс между стремлениям к инновациям в линейках своих собственных продуктов и услуг и участием в сообществе open source. Проекты, подобные OpenDaylight, демонстрируют стремление к созданию открытого ПО для «оркестрации» (orchestration) различных SDN сетей. Но атмосфера «дикого запада», присущая территории open source, рождает риски превратить нынешних грандов сетевого рынка в де-факто его новых шерифов. Ясно, что на этом пути нужна «золотая середина».

«Вендоры в открытых сетевых проектах должны работать в симбиозе с другими членами сообщества, – пишет в блоге TechCrunch Марк Коэн (Mike Cohen). – Должны вносить свой вклад в интересах открытого сообщества и одновременно продолжать инновационную деятельность по созданию различных продуктов для удовлетворения потребностей своих клиентов. Часть своих инноваций вендоры должны отдавать и в открытое сообщество, что поможет продви- гать новые стандарты и будет способствовать росту соответствующего рынка».

Резюме

Проект OpenDaylight, инициированный CISCO и IBM в 2013 году и возглавляемый ныне консорциумом Linux Foundation, – это не только значимый открытый сетевой стандарт, но и одно из самых передовых движений в области ПО с открытым исходным кодом. Он определяет открытый контроллер с большим набором API-интерфейсов с различного типа сетевой инфраструктурой на нижнем уровне и интеграцией с верхним уровнем. Для быстрого развития этого проекта и его благополучного будущего как беспрецедентной попытки объединить SDN-сети и виртуализацию сетевых функций в рамках методологии DevOps важен формат, в котором работают вендоры, внося свой вклад в OpenDaylight и используя его наработки.

Open vSwitch: открытая виртуальная коммутация

Теперь рассмотрим Open vSwitch – инициативу создания виртуального коммутатора под лицензией Apache 2.0.

Виртуальная коммутация – концепция не новая. Пионером стала компания VMware, разработчик программного обеспечения для виртуализации серверов, которое позволило заменить физические коммутаторы на виртуальные. Смысл этой затеи в том, что программный стек сервера, в котором содержатся виртуальные машины (VMs), может запускать функции коммутации для связи с виртуальными или логическими портами Ethernet. Основное отличие виртуальных серверов, таких как Open vSwitch (OVS) и устаревших виртуальных мостов L2, таких как в Linuх, состоит в том, что они предназначены управлять высокодинамичными облачными средами, где состояние сети (как конфигурируемое, так и сформированное в реальном времени) может при необходимости передаваться между хостами с помощью виртуальных машин (инстансов) vSwitch.

В отличие от проприетарных решений виртуальных коммутаторов, таких как Nexus 1000V компании Cisco и vDS (vSphere Distributed Switch) компании VMware, Open vSwitch – это самая яркая их альтернатива с открытым исходным кодом и всё более значимый элемент других открытых сетевых проектов. Коммутатор OVS работает в гипервизорах Linux, таких как Xen и KVM, включён по умолчанию в Xen Cloud Platfrom и XenServer 6.0 и интегрируется в проект OpenStack, который будет рассмотрен в следующем разделе данного обзора. Модуль ядра datapath теперь тоже включается непосредственно в Linux.

Коммутатор OVS предназначен для обеспечения возможности сетевого управления через протокол OpenFlow и администрирования через протокол Open vSwitch Database. Он функционирует как программный коммутатор и дополнительно может выгружать обработку данных в коммутирующий чип сетевых адаптеров (NICs) или внешних аппаратных коммутаторов.

Вот лишь несколько его важных характеристик:

– поддержка протоколов туннелирования, таких как VXLAN и IPsec,

– совместимость с OpenFlow, включая многочисленные расширения для виртуализации,

– контроль соблюдения правил для каждого интерфейса виртуальной машины,

– использование протокола LACP (Link Aggregation Control Protocol) для агрегирования каналов,

– совместимость с IPv6.

Компоненты коммутатора Open vSwitch

В первую очередь Open vSwitch состоит из целого ряда компонентов служебного назначения (control plane), которые расположены в пространстве пользователя, плюс модуль ядра, который управляет передачей реальной информации (data plane).

–Ovs-vswitchd: это самый важный компонент, который запускает коммутатор. Он взаимодействует непосредственно с модулем ядра OVS через протокол netlink. Если выходящий пакет, управляемый ядром, не содержит записи кэша о пункте назначения этого пакета, ядро обращается к процессу Ovs-vswitchd, который ищет в базе данных ссылку на запись в таблице переходов, соответствующую данному пакету. Найденные команды адресации пакета передаются обратно в ядро и записываются в кэш. Компонент Ovs-vswitchd может взаимодействовать и с контроллерами Open Flow.

–Ovs-dbserver: этот сервер поддерживает функционал администрирования процесса Ovs-vswitchd, сохраняя все конфигурационные изменения, обычно используя схему базы данных (OVSDB) коммутатора OVS. Он предоставляет внешним клиентам, которые используются для конфигурирования коммутатора, протокол OVSDB на базе JSON-RPC.

В отличие от Cisco Nexus 1000V или решения от VMware, у OVS нет собственного контроллера SDN. Он предназначен для работы с контроллерами третьих фирм и с «облачными оркестраторами» (Cloud Orchestrators), поэтому могут использоваться контроллеры OpenDaylight или плагины OpenStack Neutron OpenFlow и OVSDB.

Open vSwitch и SDN

OVS способствует развитию SDN, поскольку обе технологии характеризуются открытостью и высокой производительностью.

«Open vSwitch – это самый популярный сетевой бэкэнд для развёртывания проектов OpenStack, широко принятый как де-факто стандарт реализации протокола OpenFlow, – объясняют участники проекта OVS Джастин Петит (Justin Pettit), Бен Плафф (Ben Pfaff) и Итан Джексон (Ethan Jackson) в интернет-блоге Network Heresy. – Для успешного будущего Open vSwitch необходима не только его высокая программируемость и универсальность, но и фантастическая скорость. Последние годы мы в своей работе сосредоточились именно на этом – создании максимально универсального и в тоже время максимально скоростного программного коммутатора».

За серию последних релизов эффективность OVS значительно улучшились.

Рис. 2. Жизнь нового информационного потока, проходящего
через элементы форвардинга в коммутаторе OVS. Первый пакет
(фиолетовый путь) терпит неудачу при сопоставлении с содер-
жимым кэша в модуле ядра и посылается а пространство пользова-
теля для дальнейшей обработки. Последующие пакеты полностью
обрабатываются в ядре (путь жёлтого цвета).

Например, в ядерном кэше появился механизм обработки «мегапотоков» данных – megaflow (на основе битовых «джокеров» в полях заголовков пакетов), благодаря которому ядро может посылать процессу ovs-vswitchd меньшее количество исключений (рис 2). Появились новые возможности классификатора пакетов в ovs-vswitchd, такие как «сортировка по приоритетам» (Priority Sorting), «поэтапный просмотр» (Staged Lookup) и «трекинг префиксов» Prefix Tracking, благодаря которым существенно уменьшилось количество поступающих в ядро «мегапотоков» трафика – с миллионов до тысяч. В версии OVS 2.0 процесс ovs-vswitchd стал многопотоковым и позволяет лучше разделять задачи реального времени и задачи администрирования.

Резюме

Open vSwitch – мощный проект сообщества open source по разработке виртуальных коммутаторов на базе ОС Linux. Это альтернатива решениям компаний Cisco и VMware, представляющая собой базовую инновационную платформу и признанный стандарт коммутатора с открытым исходным кодом для использования совместно с протоколом OpenFlow. Ключевые характеристики Open vSwitch – использование подсистемы управления (control plane) протокола OpenFlow, очень гибкий протокол OVSDB для задач администрирования (management plane), возможность выгружать задачи управления трафиком (data plane) в аппаратную часть, высокая производительность и постоянное развитие.

OpenStack

Теперь рассмотрим проект OpenStack, который значительно крупнее рассмотренных выше стандартов с открытым исходным кодом OpenDaylight и Open vSwitch. Это программное обеспечение облачных вычислений, в котором используются логические абстракции, благодаря которым пользователи могут получать из их инфраструктуры всё, что угодно. Проект зародился в NASA и RackSpace.

OpenStack состоит из множества компонентов, которые охватывают такие задачи, как Compute (контроль вычислительных ресурсов), Block Storage (хранилище блоков),Object Storage (хранилище объектов), Telemetry (измерение и контроль), Networking (сетевой уровень) и работа с аппаратными средствами («железом»). Несмотря на то, что исторически OpenStack не рассматривался простым в использовании (особенно по сравнению с альтернативами в публичном облаке, такими как Amazon Web Services (AWS) или Microsoft Azure), за ним стоят выдающиеся разработчики и он обладает достаточной целостностью, чтобы его смогли масштабно (2500 узлов) внедрить такие фирмы, как Walmart, о чём было рассказано на саммите OpenStack в Ванкувере в 2014 году и весьма впечатлило слушателей (!).

Обзор OpenStack: как проект приобрёл популярность в облачной экосистеме

Сейчас проекту OpenStack около семи лет, и он развивается под эгидой консорциума OpenStack (OpenStack Foundation). В 2016 году в нём участвовало 649 организаций с различными уровнями участия и около 69 000 зарегистрированных членов из 181 стран. Высший уровень участия – Platinum – включает таких тяжеловесов, как ubuntu, HP, IBM, Intel, Red Hat, SUSE и соучредитель RackSpace.

Как видно из названия, OpenStack – это программное обеспечение с открытым исходным кодом. Его основной функционал легче всего понять как операционную систему для облачных вычислений. А если более конкретно, то пользователи могут получать доступ к вычислениям, хранилищам данных, сетевым ресурсам через web-интерфейс. Используя инструментальную панель OpenStack (компонент, названный Horizon), разработчики могут создавать виртуальные машины (VMs), конфигурировать сети и управлять дисковыми хранилищами данных (volumes) из одного места.

Один из специалистов компании Red Hat прекрасно охарактеризовал привлекательность OpenStack, указав на такие преимущества, как:

–сотрудничество в рамках идеологии open-source: размер комьюнити OpenStack даёт возможность широкого обмена знаниями;

–отсутствие замкнутости: пользователи OpenStack свободны от привязки к конкретному вендору или проприетарному решению,

–низкая стоимость и быстрота адаптации к новым условиям: в идеале OpenStack минимизирует препятствия к реализации эффективной автоматизации IT-инфраструктуры, так как он может работать на оборудовании массового выпуска и приспосабливаться к потребностям пользователей. На саммите OpenStack в докладе представителей американской компании- ритейлера Walmart было сказано, что при переходе на обобщённый аппаратный сервер с работающим OpenStack новые серверы обошлись в два раза дешевле и общая стоимость эксплуатации системы упала на 300% по сравнению с предыдущим образом действий.

В OpenStack есть, конечно, несколько недостатков. Традиционная головная боль – это установка, настройка и миграция. Чтобы избежать этих узких мест, организации могут выбирать простую опцию публичного облака, однако выбор правильной облачной инфраструктуры – не всегда вопрос только удобства (или цены, если речь идёт об этом).

В отчёте от аналитической компании «451 Research» общий годовой доход вендоров, так или иначе имеющий отношение к OpenStack, может достигнуть к 2018 году 3 млрд долларов, увеличив сложный годовой темп роста (CAGR) за период с 2014 по 2018 год на 40 %. Большая часть этого дохода достанется, вероятно, поставщикам услуг OpenStack, меньший кусок перепадёт дистрибуторам OpenStack, рынку инструментария разработчиков по методологии DevOps, рынку решений по администрированию облаков и рынку PaaS (платформа как услуга) на OpenStack (рис. 3). Есть вероятность, что продолжится консолидация в рамках комьюнити OpenStack (наподобие того, как Cisco приобрела Metacloud), поскольку большие вендоры хотят и откусить побольше.

Компоненты и архитектура OpenStack

OpenStack аккумулирует много новых API-интерфейсов и компонентов. Это результат стремительной разработки в течение нескольких лет. В список компонентов входят:

– Horizon: Dashboard (приборная панель),

Рис. 3. Общий годовой доход вендоров в сегменте OpenStack по годам с 2013 по 2018 гг.

– Nova: Compute (вычислительные услуги),

– Cinder: Block storage (блочные хранилища),

– Swift: Object storage (хранилища объектов, облачное файловое хранилище),

– Neutron: Networking (сетевой уровень связи с Compute),

– Keystone: Identity (идентификация),

– Ceilometer: Telemetry (измерение и контроль),

– Ironic: Bare metal provisioning (предоставление «железа», в отличие от виртуальных машин),

– Sahara: Elastic map reduce (масштабируемый стек обработки данных и интерфейсы администрирования),

– Heat: Orchestration (согласование работы облачных приложений),

– Glance: Images (работа с образами дисков и серверов),

– Zaqar: Multi-tenant cloud messaging

– Watcher (OpenS tack Inf ras t ructure Optimization) (оптимизация существующих виртуальных ресурсов).

Выше, в абзаце о том, как OpenStack может работать на базовом уровне, упоминался Horizon, компонент OpenStack, который играет роль «приборной панели» и представляет собой графический интерфейс администрирования.

Так как OpenStack имеет много компонентов, рабочий процесс может выглядеть, например, так:

– пользователь использует Horizon (компонент «приборная панель») для запроса виртуальной машины (VM) с запущенной в ней ОС SUSE Linux,

– компонент Keystone осуществляет аутентификацию этого запроса,

– далее запрос передаётся компоненту Nova, который создаёт начальную запись для создания VM,

– теперь Nova может послать запрос компоненту Glance на предоставление образа VM,

– посылается запрос компоненту Neutron, который отображает сетевой контроллер (NIC) каждой виртуальной машины на его сеть и присваивает IP-адреса,

– посылается запрос компоненту Cinder для получения данных из хранилища,

– запрос передаётся обратно в компонент Nova, который запускает загруженную виртуальную машину. OpenStack – это огромная и развивающаяся экосистема. Она сталкивается со значительной конкуренцией со стороны публичных облаков, а также, вероятно, более зрелых решений с открытым исходным кодом, таких как CloudStack, однако её имидж, брэнд и масштабность говорят о том, что она с большой вероятностью будет занимать важное место среди облачных технологий и в ближайшем будущем.

Резюме

OpenStack – открытая операционная система для облачных вычислений. Созданная NASA и RackSpace, она предоставляет логические абстракции для управления сетью и обеспечения согласованной работы всех её элементов. Она состоит из множества компо- нентов с различными функциями, такими как контроль вычислительных ресурсов (compute), хранение информации (storage) и аутентификация (identity). Сообщество OpenStack, в котором участвует множество уважаемых поставщиков услуг и оборудования, настолько велико, что проект OpenStack можно смело назвать одним из наиболее важных проектов с открытым исходным кодом во всём мире.

OpenFlow

В этом разделе рассмотрим некоторые открытые сетевые протоколы, которые стали использоваться, чтобы сети работали быстрее. Вероятно, самый заметный – это OpenFlow, который по-настоящему ускорил развитие SDN, так как в этой индустрии обратили внимание на идею, что коммутаторы могут быть программируемыми. Корни OpenFlow лежат в проекте 2006 года Ethane, его придумал студент Стэнфорда Мартин Касадо (Martin Casado). Сейчас OpenFlow курируется консорциумом Open Networking Foundation.

OpenFlow: протокол для управления трафиком и оркестрации SDN

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

В своей основе OpenFlow централизует управление коммутацией пакетов, приходя на смену используемому в большинстве сетей проприетарному ПО, которое контролирует,куда каждый коммутатор посылает пакеты. То есть вместо простого сопоставления адресов получателей пакетов с заданными в таблице предлагается использовать поле гибкого трафика – протокол OpenFlow предназначен стать внутри SDN стандартным коммуникационным интерфейсом между подсистемой управления (control plane) и подсистемой пересылки пакетов (forwarding plane). С помощью OpenFlow можно отделить друг от друга не только control plane и forwarding plane, но и физические и логические конфигурации.

Если обычный коммутатор 2-го уровня (L2) самообучается, постепенно заполняя таблицы маршрутизации на основе анализа MAC-адресов и лавинной односторонней передачи пакетов, а для пересылки пакетов по назначению использует MAC-адреса получателей, то сеть, построенная вокруг OpenFlow, получает свои команды таблицы маршрутизации от контроллера OpenFlow (подобно OpenDaylight), работающего в сервере или виртуальной машине. Контроллер OpenFlow взаимодейстует с коммутаторами и маршрутизаторами через протокол OpenFlow, а с вышележащими («на севере») бизнес-приложениями – через API-интерфейсы.

Такое централизованное расположение контроллера позволяет ему оптимизировать управление сетевым трафиком: максимально использовать полосу пропускания, улучшить качество и класс предоставляемых услуг передачи данных (QoS) по всему маршруту и эффективно реагировать на динамику запросов со стороны приложений и сервисов (на основе бизнес-правил). OpenFlow – это идеальный компаньон для «оркестрации» облаков, поскольку благодаря своей более гибкой, программируемой природе он может стать основой для сетевых соединений, поддерживающих формируемые по определённым правилам инфраструктурные среды.

Система OpenFlow состоит из трёх ключевых компонентов:

– таблиц маршрутизации в совместимых c OpenFlow коммутаторах,

– описанного выше контроллера OpenFlow,

– протокола OpenFlow, по которому взаимодействуют контроллер и коммутаторы.

Запись в таблице маршрутизации, которая расположена в совместимом c OpenFlow коммутаторе, содержит поля пакетов для сопоставления, включая источник (или приёмник) Ethernet или IP-адреса, порты TCP/IP и т.п. Выполняемые действия, такие как отправление пакета в нужный порт, изменение значений заголовка или отбрасывание пакета, определяются правилами маршрутизации на основе этих полей.

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

Обмен сообщениями между контроллерами OpenFlow и коммутаторами OpenFlow может быть симметричным, асинхронным или от контроллера к коммутатору:

– симметричные сообщения – это приветственные (hello) сообщения между коммутатором и контроллером, а также эхо-сообщения для мониторинга задержек передачи от коммутатора к контроллеру;

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

– сообщение от контроллера к коммутатору – это, например, запрос контроллером информации от коммутатора, модификация таблиц маршрутизации или пересылка пакета после того, как была создана новая запись.

OpenFlow и комьюнити SDN

Openflow – это важная деталь в деятельности как движения SDN, так и более широкого комьюнити open source. OpenFlow обладает ключевой взаимосвязью с OpenDaylight и Open vSwitch (например, даёт возможность программно расширять Open vSwitch, что облегчает сетевую автоматизацию). Для SDN это самый важный протокол с открытым исходным кодом для абстрагирования передачи трафика и управления. В настоящее время в консорциум Open Networking входит много важных вендоров, таких как HP, Huawei и IBM, и он продолжает совершенствовать OpenFlow.

Однако это не единственная «игра» на данном поле. Компания Cisco продвигает в качестве элемента своей ориентированной на приложения сетевой инфраструктуры ACI (Application Centric Infrastructure) протокол OpFlex, роль которого в SDN значительно отличается и не требует специфического набора возможностей OpenFlow. Кроме того, предлагается совершенно другая парадигма программируемых сетей – оверлейные сети, например NSX от компании VMware.

Территория SDN, открытая протоколом OpenFlow несколько лет назад, по-прежнему высококонкурентна. По мере того как всё большее число организаций переходят на программно-определяемые центры обработки данных (ЦОД) и дополнительную виртуализацию, конкурентоспособность SDN растёт. И несмотря на заявление аналитической компании Gartner о том, что SDN-сети в полуцикле своего развития находятся в самой нижней точке, истинные приверженцы SDN продолжают упорно совершенствовать протоколы типа OpenFlow и его конкурентов и превращать их в реальные решения. И только время покажет, какая парадигма одержит верх.