RESEARCH PERFORMANCE PARAMETERS OF VIRTUAL SWITCHES WITH OPENFLOW SUPPORT

Full Text

Введение В современных IT-инфраструктурных про- ектах чаще всего применяются системы, осно- ванные на виртуализации и контейнеризации приложений и сетевых функций (NFV, Network Function Virtualization). Как в виртуализации, так и в NFV используются виртуальные коммутаторы для соединения с реальными сетевыми картами и между виртуальными машинами. Большая часть проектов по реализации NFV основывается на классических системах облачной виртуализации, например, VMware (vCloud NFV) и OpenStack (OPNFV, OSM), которые используют, соответ- ственно, виртуальные коммутаторы vSwitch (так- же vDS) и Open vSwitch (OVS). Поскольку OVS является открытой реализацией коммутатора с поддержкой OpenFow, его используют как один из основных коммутаторов такие платформы, как OpenStack, OpenNebula, OpenShift, в том числе в режиме OpenFlow с проактивными правилами OpenNebula и с контроллером OpenStack. Изучение работы Open vSwitch в разных ва- риантах при различной нагрузке может раскрыть источники проблем, которые могут возникать в таких средах при превышении допустимых по- казателей сети. В статье описан метод получения таких параметров производительности коммута- тора, как задержка обработки пакета (фрейма), максимальная пропускная способность. Метод позволяет оценить влияние конфигурации и ре- жимов OpenFlow на производительность. Обзор методов оценки состояния качественных показателей сети Для оценки текущего состояния качественных показателей сети часто используются методы ее упреждающей диагностики [1]. Трафик может быть проанализирован как программными, так и аппаратными методами. Получение данных может производиться на обычном ПК, использу- емом в качестве аппаратного зонда, или на сете- вом устройстве с использованием таких протоко- лов, как, например, NetFlow, SFlow или RMON. При этом полученная информация интерпрети- руется посредством специального программного обеспечения. Для анализа трафика также могут быть ис- пользованы встроенные средства маршрутиза- торов и операционных систем. Примерами та- ких средств могут выступать IpFilter, NetFlow, IPfw [2]. Для детального анализа сохраненного трафика используются так называемые стековые анализаторы. Один из наиболее распространен- ных продуктов для мониторинга от компании Fluke Networks - интегрированный сетевой ана- лизатор OptiView Network Analyzer [3]. OptiView Network Analyzer обеспечивает обзор всей корпо- ративной сети и помогает управлять изменения- ми инфраструктуры, решать проблемы произво- дительности сети и защищать ее от внутренних угроз. Данное портативное устройство включает функции обследования сети, анализа трафика и инфраструктуры, захвата пакетов и поддержку WAN, WLAN и VoIP. При этом стоимость этого прибора очень высока. «Infokommunikacionnye tehnologii» 2020, Vol. 18, No. 4, pp. 411-417 Для анализа потоков высокоскоростных со- единений могут быть использованы аппаратные анализаторы. Они довольно хорошо справляются с анализом и позволяют производить диагности- ку 1-2 уровней OSI. Аппаратные анализаторы отличаются возможностью автономного исполь- зования в любом месте сети и стандартизирован- ным интерфейсом управления. Кроме того, рабо- та таких устройств не зависит от используемых технологий и программного обеспечения. Но ос- новным недостатком таких комплексов является очень высокая стоимость [4]. Один из способов определить показатели про- изводительности сети связан с использованием технологии NetFlow компании Cisco Systems [5]. Технология NetFlow позволяет собирать и полу- чать статистику по потокам данных, проходящих через оборудование Cisco. Проходящий через устройство пакет может быть проанализиро- ван посредством коллекторов сборщиков дан- ной информации, например, Reporter Analayzer от Fluke Networks или Observer от Network Instruments [6; 7]. На основе проведенного ана- лиза может быть получена точная информация о потоке. Другой способ получения информации о со- стоянии сети непосредственно от агентов сети, применяемый в некоторых программных ком- плексах, - использование протокола SNMP. Од- нако программы сетевого мониторинга на основе протокола SNMP отражают статистику ошибок в сети не всегда адекватно, т. к. встроенный в ак- тивное оборудование агент SNMP всегда наблю- дает за состоянием сети только из одной точки. Кроме того, многие устройства SNMP работают только на первом и втором уровнях OSI [8]. Так же, как и протоколы сбора статистики NetFlow и sFlow, протокол SNMP предоставляет возможность только сбора и транспортировки информации на коллектор, анализ же должен производиться други- ми приложениями. Для мониторинга и управления сетью по про- токолу SNMP существует огромный выбор закон- ченных решений. Однако задачи автоматическо- го управления сетью требуют наличия аппарата анализа и средств прогнозирования для системы принятия решений. Для анализа сетей существует целый ряд огра- ничений, в частности: применение произвольных внешних программ анализа и интерпретации результатов затруднено закрытым форматом передачи и хранения данных; отсутствие во всех системах единого открыто- го формата сведений о структуре сети; все системы являются коммерческими и не до- пускают внесения изменений в программный код для адаптации к решаемой задаче; затруднена адаптация всех систем во внешние комплексы анализа в реальном времени [9]. Для решения названных проблем в настоящей работе предлагается методика исследования вир- туального коммутатора, позволяющая изучить поведение устройства при различных его конфи- гурациях. Методика автоматизированного исследования параметров производительности виртуальных коммутаторов с поддержкой OpenFlow Для получения набора зависимостей времен- ных и нагрузочных характеристик от входных па- раметров трафика, настроек и текущей нагрузки виртуальных коммутаторов предложена методи- ка автоматизированного экспериментального ис- следования (см. рисунок 1). Схема экспериментального исследования сетевого устройства включает в себя сервер с виртуальной машиной, опциональные вспомога- тельные коммутаторы Linux Bridge, исследуемые программные коммутаторы Linux Bridge и OVS как на хостовой машине, так и в виртуальной ма- шине. Генерация трафика осуществляется ути- литой trafgen по заранее созданным шаблонам пакетов с рандомизацией MAC-адреса. Перед на- чалом исследования создается первоначальный план генерации трафика с заданными интенсив- ностями и параметрами базовой настройки ком- мутаторов. Алгоритм запускает для каждой стро- ки плана эксперимента генератор с требуемыми параметрами, создает и управляет количеством задействованных виртуальных интерфейсов, за- дает параметры виртуальных коммутаторов че- рез API. На основе фиксации параметров трафика и временных срезов состояния устройства (дамп параметров и нагрузки на процессор и память) создается набор слепков состояний, параметров устройства, генераторов трафика и соответствую- щие им выборки времени задержки из анализато- ра дампов трафика и потери пакетов для каждого прогона. В процессе снятия показаний задерж- ки обработки фрейма происходит динамическое формирование плана дальнейших исследований для корректировки интенсивности генерации при большом проценте потерянных пакетов. Постановка эксперимента Для исследования работы виртуального ком- мутатора в различных условиях необходимо точ- Рисунок 1. Схема экспериментального исследования сетевого устройства но измерить время обработки фрейма и изучить влияние загрузки процессора на производитель- ность, а также влияние конфигурации коммута- тора на выходные характеристики. Для экспери- мента были выбраны следующие конфигурации в соответствии с возможными путями трафика 1-11 на рисунке 1: Изучение работы соединения через Linux Bridge внутри виртуальной машины (путь 1) и на оборудовании (путь 4). Изучение работы соединения через мост Open vSwitch внутри виртуальной машины (путь 2) и на оборудовании (путь 5). Изучение работы соединения через мост Open vSwitch в режиме OpenFlow с различным количеством установленных правил как внутри виртуальной машины (путь 3), так и на хостовой машине (путь 6). Изучение работы соединения Bridge (путь 7), OVS (путь 8), OVS+OpenFlow (путь 9) на хосто- вой машине. Изучение работы соединения через внеш- ние сетевые карты (путь 11) и через Bridge и внешние сетевые карты (путь 10). Поскольку виртуальный коммутатор при пере- даче пакетов не имеет задержку на сериализацию, передачу в линию, передачу по кабелю, то за- держки в сетевой карте при использовании NFV могут составлять существенную долю от общей задержки при низких нагрузках. Для проведения экспериментального исследования был разрабо- тан и реализован алгоритм, запускающий серию Таблица. План исследований - интервал между паке- тами при генерации трафика Путь Конфигурация Место прогона Host KVM 1,7 Linux Bridge 1,10,50 1,10,50 2,8 OVS 1,10,50 1,10,50 3,9 OVS+OpenFlow 100 правил 1,10,50 10,50,100 3,9 OVS+OpenFlow 1000 правил 1,10,50 10,50,100 4,10 Linux Bridge для внешней сети 1,10,50 10,50,100 5 OVS для внешней сети 1,10,50 1,10,50 6 OVS+OpenFlow для внешней сети, 1, 100, 1000 правил 1,10,50 1,10,50 10,11 Прямое соединение 1,10,50 1,10,50 экспериментов по заданным заранее сетевым ин- терфейсам. При задании режима OVS+OpenFlow генерируется заданное количество правил со слу- чайными адресами и номерами портов. Для генерации необходима рандомизация MAC-адресов для снижения влияния кеша. Каж- дый прогон проходил для размера пакетов 64 байт с параметрами генерации пакетов, указанных в таблице. Эти параметры были получены путем предварительного прогона и поиска таких интен- сивностей генерации, при которых потеря паке- тов не превышает 1 % от общего их числа. Предварительный эксперимент показал, что производительность в различных конфигурациях отличается в несколько раз. Эксперимент Эксперимент проводился на сервере 2×Intel Xeon E5 6 ядер, 64Гб ОЗУ DDR3-ECC, 2×SAS SSD RAID0. Первая серия прогонов запускалась на хостовой ОС Ubuntu server 20.04. Вторая се- рия на виртуальной машине KVM с такой же кон- фигурацией операционной системы и сетевыми адаптерами e1000 и коммутацией OVS. Третья серия прогонов проходила на виртуальной маши- не VMware ESXi с аналогичной конфигурацией и сетевым коммутатором vSwitch. Для генерации трафика использовался trafgen с рандомизацией MAC-адреса получателя и от- правителя, а также с параметром интервала вре- мени между пакетами в мкс. Результат измерений на различных вариантах конфигурации показан на рисунке 2. Потери пакетов размера 64 байт при исполь- зовании OpenFlow в виртуальной среде показаны на рисунке 3. Рисунок 2. Измерение задержек на различных вариантах конфигурации Рисунок 3. Потери пакетов OVS+OpenFlow в KVM Рисунок 4. Задержки OVS+OpenFlow в KVM На аппаратном сервере потерь пакетов не на- блюдается при любых сочетаниях параметров генерации трафика, а также при размере пакета более 500 байт в KVM. Задержки в режимах, где начинаются потери пакетов, растут экспоненци- ально (см. рисунок 4). Анализ прогона трафика через две сетевые карты виртуальной машины через коммутатор виртуализации показал, что потери на сериали- зацию и эмуляцию отсылки пакета составляют порядка 200-300 мкс через коммутатор OVS и 120 мкс при использовании Linux Bridge. Но максимальная производительность Linux Bridge при коммутации виртуальной машины на пакетах 64 байт ниже почти в два раза, чем OVS. Потери пакетов при использовании Linux Bridge начинались при скорости генерации от 100000 пакетов/с по 64 байт, тогда как OVS не терял па- кеты и при скорости генерации 1000000 пакетов/с по 64 байт. Заключение В статье проведено исследование различных сочетаний видов подключения сетевых виртуаль- ных коммутаторов и режима OpenFlow. В ходе ис- следования получены результаты, показывающие режимы, в которых возможны как потери пакетов более 50 %, так и задержки более 100 мс. Иссле- дованы различные участки пути следования па- кета, установлено, что внутри виртуальных ма- шин оптимальнее не использовать Open vSwitch в режиме OpenFlow, а в системе виртуализации, наоборот, лучше использовать Open vSwitch, чем Linux Bridge. При превышении нагрузки более выявленных границ необходимо оптимизировать Open vSwitch и устанавливать модуль DPDK для низко латентной коммутации или изменять ба- лансировку нагрузки на такие узлы. Исследование выполнено при финансовой поддержке РФФИ (проекты № 20-57-53019 и 18- 07-01446 А) и гранта Президента РФ для государ- ственной поддержки ведущих научных школ Рос- сийской Федерации (проект № НШ-2502.2020.9).

About the authors

M. V Ushakova

Orenburg State University

Email: m.v.ushakova@mail.ru
Orenburg, Russian Federation

Y. A Ushakov

Orenburg State University

Email: unpk@mail.ru
Orenburg, Russian Federation

I. P Bolodurina

Orenburg State University

Email: prmat@mail.osu.ru
Orenburg, Russian Federation

V. N Tarasov

Povolzhskiy State University of Telecommunications and Informatics

Email: tarasov-vn@psuti.ru
Samara, Russian Federation

N. F Bakhareva

Povolzhskiy State University of Telecommunications and Informatics

Email: bahareva-nf@psuti.ru
Samara, Russian Federation

References

Supplementary files