Компьютерные сети. 6-е изд.

5.6. Программно-конфигурируемые сети

Процесс управления трафиком всегда был очень непростым: он требует от операторов сетей настройки параметров конфигурации протоколов маршрутизации, которые затем производят перерасчет путей. Трафик идет по новым маршрутам, что ведет к перераспределению нагрузки. К сожалению, механизмы управления трафиком носят косвенный характер: изменение конфигурации протоколов меняет маршрутизацию и в отдельных сетях, и между ними. При этом протоколы часто ведут себя непредсказуемо. Эти проблемы во многом решаются с помощью программно-конфигурируемых сетей (Software-Defined Networking, SDN), которые мы обсудим далее.

5.6.1. Общие сведения

По сути, компьютерные сети всегда были «программно-конфигурируемыми», поскольку в маршрутизаторах используется конфигурируемое программное обеспечение, извлекающее информацию из пакетов и принимающее решения об их передаче. В то же время та часть ПО, которая запускает алгоритмы маршрутизации и реализует остальную логику передачи пакетов, всегда была вертикально интегрированной в сетевое оборудование. Купив маршрутизатор Cisco или Juniper, оператор сети был вынужден работать с программными технологиями, которые внедрил поставщик оборудования. Например, изменить какие-либо параметры протокола OSPF или BGP было просто невозможно. Главной причиной разработки SDN стало понимание, что плоскость управления (control plane) (логика выбора маршрутов и принятия решений о передаче) работает на программном уровне и может выполняться абсолютно независимо от плоскости данных (data plane) (аппаратных технологий, которые непосредственно извлекают информацию из пакетов и решают, что с ними делать). Эти плоскости показаны на илл. 5.43.

Если структурно разделить плоскость управления и плоскость данных, то логично предположить, что плоскость управления совсем необязательно запускать на сетевом оборудовании. На самом деле одна из популярных спецификаций SDN подразумевает наличие логически централизованной программы, зачастую написанной на языке высокого уровня (например, Python, Java, Golang, C). Эта программа принимает логические решения о пересылке и уведомляет о них все участвующие устройства. В качестве канала связи между высокоуровневой программой и нижележащим аппаратным обеспечением можно использовать любой механизм, поддерживаемый сетевым устройством. Один из первых SDN-контроллеров использовал в качестве плоскости управления протокол BGP (Фимстер и др.; Feamster et al., 2003). Позднее появились технологии OpenFlow, NETCONF и YANG, которые предложили более гибкие способы передачи информации плоскости управления сетевым устройствам. В некотором смысле технология SDN стала реинкарнацией давно известной архитектурной концепции централизованного управления, появлению которой способствовало наличие уже устоявшихся вспомогательных технологий (свободно распространяемых API для чипсетов, программного управления распределенными системами).

Илл. 5.43. Разделение плоскости управления и плоскости данных в программно-конфигурируемых сетях

Хотя технология SDN активно развивается в течение многих лет, основной принцип разделения плоскости данных и плоскости управления остается неизменным. Вы можете подробно ознакомиться с историей появления этой набирающей популярность технологии в работе Фимстера и др. (Feamster et al., 2013). Далее мы рассмотрим несколько основных направлений развития SDN. Это контроль переадресации и маршрутизации (технологии плоскости управления); программируемое оборудование и настраиваемая переадресация (технологии, делающие плоскость данных более программируемой); и программируемая сетевая телеметрия (приложение для сетевого администрирования, которое соединяет эти два компонента и играет ключевую роль для SDN).

5.6.2. Плоскость управления в SDN: логически централизованное программное управление

Одна из главных технических идей в основе SDN — наличие плоскости управления, работающей независимо от маршрутизаторов, часто в виде единственной логически централизованной программы. В некотором смысле технология SDN существовала всегда: поскольку маршрутизаторы можно настраивать, крупные сети часто автоматически генерировали их конфигурации на основе централизованной базы данных, обеспечивали контроль версий и выполняли их на маршрутизаторах с помощью скриптов. Такой способ настройки можно назвать SDN, но с технической точки зрения он дает операторам очень ограниченные возможности контроля передачи трафика по сети. Чаще всего управляющая программа SDN (контроллер) в большей степени отвечает за логику управления. К примеру, она вместо маршрутизаторов вычисляет пути и затем просто обновляет таблицы переадресации.

Первые исследования в области SDN были направлены на то, чтобы упростить для сетевых операторов задачу по регулированию трафика. Вместо настройки конфигурации сети предлагалось напрямую контролировать, какой путь выбирает каждый маршрутизатор. Первые реализации технологии SDN должны были работать в рамках существующих интернет-протоколов маршрутизации для непосредственного управления выбором путей. Одним из таких решений стала платформа управления маршрутизацией (Routing Control Platform, RCP) (Фимстер и др.; Feamster et al., 2003), впоследствии развернутая в магистральных сетях для балансировки нагрузки и защиты от DoS-атак. Позднее появился ряд других систем, в частности Ethane (Касадо и др.; Casado et al., 2007), обеспечивающая централизованный программный контроль аутентификации хостов в сети. Однако для ее реализации требовались нестандартные коммутаторы, что не способствовало ее распространению.

Когда преимущества технологии SDN для сетевого администрирования стали очевидны, к ней начали проявлять интерес операторы сетей и поставщики оборудования. Кроме того, была обнаружена удобная «лазейка» для еще более успешного контроля коммутаторов. Во многих из них использовался чипсет Broadcom с интерфейсом, позволяющим производить прямую запись в память коммутатора. Группа исследователей провела совместную работу с поставщиками коммутаторов, чтобы сделать этот интерфейс доступным для ПО. В результате был создан протокол OpenFlow (Маккиоун и др.; McKeown et al., 2008). Его поддержку обеспечили многие поставщики, которые пытались конкурировать с доминирующим игроком на этом рынке, компанией Cisco. Изначально OpenFlow поддерживал очень простой интерфейс: данные записывались в ассоциативную память в виде обычной таблицы сопоставления действий (match-action table). Эта таблица позволяла коммутатору идентифицировать пакеты по одному или нескольким полям заголовка (например, по полю MAC-адреса, IP-адреса и т.д.) и выполнить какое-либо действие, включая переадресацию пакета на определенный порт, его удаление или отправку в находящийся вне маршрута программный контроллер.

Было создано несколько версий протокола OpenFlow. Версия OpenFlow 1.0 пре­дусматривала наличие одной таблицы сопоставления действий. С помощью этой таблицы можно было найти точные совпадения с указанной комбинацией полей заголовка пакета (полей MAC-адреса, IP-адреса и т.д.) или произвести поиск по шаблону (например, по префиксу IP-адреса или MAC-адреса). В последующих версиях (наиболее заметная из них — OpenFlow 1.3) была добавлена поддержка более сложных операций, включая работу с цепочками таблиц, но лишь немногие поставщики реализовали эти возможности. Применять логические операции «И» и «ИЛИ» к таким сопоставлениям оказалось непросто, особенно для программистов. Это привело к появлению ряда технологий, которые упрощали задачу выражения более сложных комбинаций условий (Фостер и др.; Foster et al., 2011). Также они позволяли учитывать время и другие показатели при принятии решения о переадресации (Ким и др.; Kim et al., 2015). В итоге некоторые из этих технологий получили весьма ограниченное распространение: OpenFlow стал использоваться в крупных центрах обработки данных, где сетевые операторы обладали полным контролем над сетью. В глобальных и корпоративных сетях они использовались еще реже, поскольку в таблице переадресации можно было выбрать лишь очень ограниченный набор действий. Кроме того, многие поставщики коммутаторов так и не предоставили полную реализацию последних версий данного протокола. Это затрудняло практическое внедрение решений, использующих эти возможности. Однако в конечном счете протокол OpenFlow оставил после себя в качестве наследия пару важных идей: контроль над сетью с помощью одной централизованной программы, координирующей сетевые устройства и элементы пересылки, и выражение этого контроля с помощью одного высокоуровневого языка программирования (например, Python или Java).

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

Наряду с этим программный контроль на уровне ПО, изначально рассчитанный в основном на транзитные сети и сети центров обработки данных, постепенно находит применение и в мобильных сетях. Например, проект переоборудования узла связи в дата-центр (Central Office Re-Architected as a Datacenter, CORD) направлен на разработку сети 5G на основе стандартных аппаратных средств и программных компонентов с открытым исходным кодом (Петерсон и др.; Peterson et al., 2019).

5.6.3. Плоскость данных в SDN: программируемое оборудование

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

Для этой архитектуры используется общее название — протоколонезависимая архитектура коммутатора (protocol-independent switch architecture). Она предполагает наличие фиксированного набора конвейеров обработки. Каждый из них обладает памятью для таблиц сопоставления действий и определенным объемом регистровой памяти, а также поддерживает ряд простых операций, например добавление (Босхарт и др.; Bosshart et al., 2013). Соответствующая модель переадресации называется реконфигурируемыми таблицами сопоставления (Reconfigurable Match Tables, RMT); ее конвейерная архитектура была вдохновлена RISC-архитектурами. Каждая ступень конвейера обработки может считывать информацию из заголовков пакетов, модифицировать значения заголовка с помощью простых арифметических операций и записывать эти значения обратно в пакеты (илл. 5.44). Архитектура чипа содержит программируемый парсер, набор ступеней сопоставления в определенном состоянии. Они выполняют арифметические вычисления над пакетами и принимают простейшие решения по их передаче или удалению. Другой компонент чипа, депарсер, записывает полученные значения обратно в пакеты. Каждая ступень чтения/модификации может менять как собственное состояние, так и любые метаданные пакетов (например, информацию о том, какую глубину очереди видит отдельный пакет).

Илл. 5.44. Реконфигурируемый конвейер сопоставления действий для обеспечения программируемой плоскости данных

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

Современные чипсеты, такие как Barefoot Tofino, позволяют выполнять протоколонезависимую обработку нестандартных пакетов на входе и на выходе (илл. 5.45). Благодаря этому можно анализировать временные параметры очередей (например, время нахождения в очереди отдельных пакетов), а также производить нестандартную инкапсуляцию и декапсуляцию. Кроме того, можно применять метод активного управления очередью (к примеру, RED) к выходным очередям, используя метаданные, получаемые из входных очередей. В настоящее время исследуются способы использования этой архитектуры для управления трафиком и перегрузками, в частности, путем мелкоструктурной оценки параметров очередей (Чэнь и др.; Chen et al., 2019).

Такая степень программируемости оказалась наиболее полезной в сетях дата-центров. Благодаря своей архитектуре они способны извлечь выгоду из широких возможностей настройки. С другой стороны, данная модель обеспечивает общее повышение эффективности и расширение функциональности. Она позволяет включать в пакеты информацию о состоянии самой сети с помощью внутриполосной сетевой телеметрии (In-band Network Telemetry, INT) (например, величину задержки на каждом транзитном участке пути).

Илл. 5.45. Реконфигурируемые конвейеры сопоставления действий на этапах входа и выхода

На сегодняшний день существуют программируемые сетевые карты, комплект разработчика плоскости данных (Data Plane Development Kit, DPDK) от Intel и другие библиотеки, а также гибкие конвейеры обработки (например, чипсет Barefoot Tofino, программируемый на языке P4 (Босхарт и др.; Bosshart et al., 2014)). Благодаря этому операторы сетей разрабатывают нестандартные протоколы и производят расширенную обработку пакетов в самом коммутационном оборудовании. P4 — высокоуровневый язык для программирования протоколонезависимых обработчиков пакетов (например, RMT-чипов). Также были разработаны программируемые плоскости данных для виртуальных коммутаторов (точнее, это произошло задолго до появления программируемых аппаратных коммутаторов). Еще одним важным шагом в области программируемого управления коммутаторами стала разработка открытой программной реализации Open vSwitch (OVS), которая позволяет обрабатывать пакеты на нескольких уровнях и работает в виде модуля ядра Linux. OVS предлагает целый ряд возможностей, от VLAN до IPv6. Операторы сетей получили возможность настраивать переадресацию в дата-центрах, в частности, запуская OVS в качестве коммутатора в гипервизоре серверов.

5.6.4. Программируемая сетевая телеметрия

Одним из наиболее важных преимуществ технологии SDN является то, что она позволяет обеспечить программируемую оценку параметров сети. Многие годы сетевое оборудование предоставляло весьма ограниченные сведения о сетевом трафике. Это могла быть общая статистика потоков трафика с точки зрения сетевого коммутатора (например, по стандарту IPFIX). В то же время возможность перехвата каждого сетевого пакета ведет к большим издержкам, учитывая необходимый размер пропускной способности и памяти, а также объем обработки для последующего анализа этих данных. Для многих приложений нужно найти баланс между степенью детализации трассировки пакетов и масштабируемостью агрегатных данных IPFIX. Этот баланс необходим и для таких задач сетевого администрирования, как оценка производительности приложений, и для упоминавшихся ранее задач управления перегрузками.

Программируемое коммутационное оборудование, представленное в предыдущем разделе, обеспечивает более гибкий сбор телеметрии. Одна из тенденций, к примеру, заключается в предоставлении операторам сетей возможности запрашивать данные о сетевом трафике на высокоуровневом языке с использованием таких фреймворков, как MapReduce (Дин и Гемават; Dean and Ghemawat, 2008). Этот подход изначально рассчитан на обработку данных в крупных кластерах. Поэтому с его помощью можно запрашивать информацию о сетевом трафике (например, количество байтов или пакетов, отправленных на определенный адрес или порт в заданном временном интервале). К сожалению, программируемое коммутационное оборудование еще (пока) не настолько совершенно, чтобы поддерживать сложные запросы. Иногда их нужно разделять между потоковым процессором и сетевым коммутатором. Для этого существует несколько технологий (Гупта и др.; Gupta et al., 2019). Вопрос об эффективном способе отображения высокоуровневых абстракций и конструкций запросов на коммутационное аппаратное и программное оборудование более низкого уровня остается открытым.

Наконец, крупной проблемой в сфере программируемой сетевой телеметрии в ближайшие годы будет все большее распространение в интернете зашифрованного трафика. С одной стороны, это обеспечивает конфиденциальность, затрудняя несанкционированный доступ к пользовательским данным. Но с другой стороны, невозможность увидеть содержимое трафика усложняет задачу сетевого администрирования для операторов. К примеру, рассмотрим отслеживание качества видеопотоков. Если трафик не зашифрован, можно узнать битрейт и разрешение видео. В противном случае эти сведения приходится логически выводить на основе тех свойств сетевого трафика, которые доступны для непосредственного наблюдения (например, интервалы получения пакетов и объем трафика в байтах). В недавних исследованиях были представлены способы автоматического логического вывода высокоуровневых свойств трафика сетевых приложений на основе низкоуровневой статистики (Бронзино и др.; Bronzino et al., 2020). Рано или поздно операторам потребуются более эффективные модели, позволяющие логически оценить влияние перегрузки и других факторов на производительность приложений.