ENSURING QUALITY OF SERVICE IN PROGRAM CONFIGURED NETWORKS

Full Text

Введение Основа реализации качества обслуживания (Quality of Service, QoS) базируется на контроле входа и выхода пакета из устройства. Какая единица данных при этом используется - поток или пакет, - не имеет значения, основа реализации QoS сводится к определению приоритетов конкретных пакетов. Контроль над прохождением пакетов через сеть доступен только в пределах центра обработки данных (ЦОД), за пределами «Инфокоммуникационные технологии» Том 10, № 4, 2012 Бахарева Н.Ф., Коннов А.Л., Тарасов В.Н., Ушаков Ю.А 31 ЦОД вся ответственность ложится на провайдеров телекоммуникационных услуг [1]. Кроме того, сама система QoS предназначена для решения связанных с сетью вопросов, таких как перегрузка каналов и потеря пакетов, которые в конечном итоге приводят к снижению производительности приложений. Перегрузка каналов и потери пакетов могут произойти по ряду причин, например, превышение максимальной пропускной способности, высокий коэффициент загрузки (это делает их не способными к эффективной обработке входящих пакетов [1-2]), а также при неправильной конфигурации сетевых устройств. Некоторые типы QoS, например, ограничение полосы пропускания, могут помочь в решении проблемных ситуаций. Управление полосой пропускания может уменьшить проблемы, связанные с ограниченной пропускной способностью каналов связи, но только каналов между ЦОД и Internet. Если пропускная способность ограничена на другом конце канала («последняя миля» провайдера), этот метод не улучшит производительность, так как контроллер протокола OpenFlow не будет иметь сведений об этих ограничениях. OpenFlow контроллер будет применять правила вслепую по отношению к трафику за пределами центра обработки данных. Вне контекста приложений QoS редко дает заметное улучшение в производительности с точки зрения конечного пользователя. Контекст является необходимым для применения правильных методов и политик в нужное время, чтобы обеспечить оптимальную производительность для пользователей конкретного приложения. Особенности реализации QoS в OpenFlow коммутаторах Большинство коммутаторов и маршрутизаторов сегодня поставляются с некоторой встроенной поддержкой QoS. Некоторые продукты поддерживают только тип DiffServ (RFC-2474 и RFC-2475, небольшое количество очередей и политик), другие поддерживают тысячи очередей и большое количество политик. На практике при реализации QoS в сетях с коммутацией потоков сам поток отображается на класс трафика QoS, то есть поток получает идентификатор уже имеющегося класса. В настоящее время существует два основных типа QoS услуг - ограничение скорости на входе и гарантирование минимальной пропускной способности на выходе. Первая, как правило, делается на основе измерений скорости входного порта или потока, после превышения определенной скорости пакеты отбрасываются в соответствии с некоторым алгоритмом [4]. Ограничение минимальной гарантированной полосы пропускания означает, что каждому потоку будет доступна определенная часть от имеющейся пропускной способности. По умолчанию 8 очередей на физическом порту имеют следующие минимально гарантированные полосы пропускания от целого канала: - queue 1 (low priority): 2%; - queue 2 (low priority): 3%; - queue 3 (normal priority): 30%; - queue 4 (normal priority): 10%; - queue 5 (medium priority): 10%; - queue 6 (medium priority): 10%; - queue 7 (high priority): 15%; - queue 8 (high priority): 20%. Спецификация OpenFlow 1.0.0 предусматривает поддержку ограниченного функционала в области QoS. На каждый порт можно подключить одну или несколько очередей. Каждый поток ассоциируется с конкретной очередью. Обработка в очереди происходит в соответствии с настройкой конкретной очереди. По умолчанию все очереди имеют настройку на предоставление минимальной гарантированной пропускной способности, другие типы очередей не поддерживаются текущей версией OpenFlow [3]. Для обеспечения QoS в свойствах конкретного потока существует поле IP ToS, в нем содержится 6-битный DSCP идентификатор, Input VLAN Priority для приоритезации одного VLAN над другим. Для обработки потока существуют следующие действия: - OFPAT_SET_VLAN_PCP устанавливает приоритет VLAN 802.1q; - OFPAT_SET_NW_TOS устанавливает новое значение DSCP потоку; - OFPAT_SET_QUEUE устанавливает новый идентификатор очереди для данного потока, другими словами, ассоциирует конкретный поток с очередью вне зависимости от DSCP и VLAN Priority. Для настройки самих очередей QoS необходимы особые команды, не относящиеся к OpenFlow. Очереди настраиваются средствами операционной системы коммутатора - через специальные команды или посредством внешних утилит. OpenFlow-контроллер может только запросить информацию об очередях на конкретном порту: количество очередей, их тип, количество пакетов в очереди. Также можно запросить статистику по всем очередям коммутатора: переданные пакеты, переданные байты, количество переполнений «Инфокоммуникационные технологии» Том 10, № 4, 2012 32 Бахарева Н.Ф., Коннов А.Л., Тарасов В.Н., Ушаков Ю.А очереди. Каждая очередь имеет определенный размер в байтах и тип - простая FIFO очередь или с ограничением по гарантированной полосе пропускания. Для второго типа очереди настраивается гарантированная полоса пропускания в процентах (единица измерения равна 0,1%) от максимально доступной полосы пропускания порта коммутатора. Таким образом, существуют два шага для работы с QoS в OpenFlow - настройка очередей на коммутаторах с привязкой к портам или без нее и связывание конкретных потоков. Альтернативные методы реализации QoS в сетях OpenFlow Существует альтернативный метод обеспечения QoS - перенаправить обработку пакетов конкретного потока на операционную систему коммутатора, и тот обработает их классическими методами. Это возможно только на коммутаторах c одновременной поддержкой OpenFlow обработки пакетов и обычной обработки пакетов. Однако базовая концепция QoS предполагает, что все пакеты всегда идут по одному направлению в течение довольно длительного времени, если топология сети статична, а путь между двумя точками детерминирован. Сети OpenFlow не позволяют применять сложные механизмы QoS именно из-за недетерминированности топологии и путей следования пакетов. К тому же очень часто при глубокой интеграции виртуализирован-ных ресурсов в ЦОД требования к обеспечению требуемых показателей работы сети кардинально меняются в процессе работы для разных виртуальных сетей. В связи с описанными ограничениями реализации QoS предлагается использовать первый подход к реализации - настройку очередей на коммутаторах и сопоставление битов QoS и конкретных потоков на контроллере. Затем всю обработку QoS наиболее рационально перенести на операционную систему коммутатора в соответствии с битами QoS, что позволит максимально использовать все преимущества дополнительных возможностей очередей коммутаторов. Реализация обработки QoS Для корректной настройки параметров QoS необходима точная информация о потоках трафика в сети. В протокол OpenFlow встроена возможность анализа проходящего трафика средствами измерений. Все измерения записываются в таблицу измерений, которая состоит из записей измерений, определяющих измерения для каждого потока. Измерения для каждого потока позволяют OpenFlow реализовывать различные простые операции QoS, такие как ограничение скорости, и могут быть объединены с очередями каждого порта для реализации сложных структур QoS [3-4], таких как DiffServ, или для последующего анализа. Контроллер может уведомить коммутатор о различных типах обработки очередей: - удаление (отбрасывание) пакета. Этот тип обработки может быть использован для определения диапазона ограничения скорости; - изменение DSCP. Этот тип позволяет уменьшать приоритет DSCP в IP-заголовке пакета. Используется для определения простого ограничителя DiffServ. Для управления произвольным коммутатором OpenFlow любого производителя существует linux-утилита dpctl, позволяющая добавлять, удалять, просматривать данные о потоках, очередях, счетчиках. Для реализации QoS на уровне OpenFlow (программном уровне) необходимо создать очередь и настроить ее параметры. Так как очередь в OpenFlow может быть только с политикой WFQ, т.е. с нижней границей скорости потока, команда для настройки очереди для 3 приоритета на 2 порту коммутатора IP=10.1.1.1 для минимальной гарантированной скорости 1000 Кбит/с будет выглядеть следующим образом: Mpctl mod-queue tcp:10.1.1.1:6633 3 2 1000. Для классификации конкретного потока можно использовать как уже ранее присвоенный ToS/ DSCP, так и присвоить эти параметры непосредственно OpenFlow препроцессором или просто перенаправить в нужную очередь (локальная классификация). Правило для приоритезации (ассоциации с очередью №3) пакета от 10.0.0.2 к 10.0.0.3 выглядит следующим образом: ffdpctl add-flow tcp:10.1.1.1:6633 "ip ; nw_dst=10.0.0.3, nw_src=10.0.0.2; action=mod_ylan_pcp:3, output:23", где mod_vlan_pcp задает приоритет пакета (номер очереди) при обработке. При необходимости изменить ToS можно использовать параметр mod_ nw_tos:<tos>; output задает номер исходящего порта (коммутация). Минимальная гарантированная скорость на порту задается при дополнительной настройке физической очереди. Просто перенаправить пакет в физическую очередь №3 порта 23 коммутатора можно командой: «Инфокоммуникационные технологии» Том 10, № 4, 2012 Бахарева Н.Ф., Коннов А.Л., Тарасов В.Н., Ушаков Ю.А 33 Mpctl add-flow tcp.10.1.1.1:6633 "ip ; nw_dst=10.0.0.3,nw_src=10.0.0.2 ; action=enqueue:23:3, output:23", где enqueue - номер очереди конкретного порта. Параметр enqueue поддерживается не всеми коммутаторами. Для создания ограничения сверху конкретного потока используется следующая запись другой утилиты, входящей в состав продукта Open vSwitch: # ovs-ofctl add-limiter tcp.10.1.1.1:975; 123 drop 512 kbps, где 123 - номер ограничителя; drop - реакция на превышение лимита; 512 kbps - размер виртуального канала. После создания ограничителя необходимо связать конкретный трафик с ним: #ovs-ofctl add-flow tcp.10.1.1.1:975; "priority=32769, idle_timeout=0, ip; nw_dst=10.0.0.3,nw_src=10.0.0.2; action=rate limit: 123, output:23 ", где ratejimit - номер ограничителя. Как видно из приведенных примеров, настройка QoS для большой сети с множеством потоков и динамической топологией является сложной и нетривиальной задачей, к тому же ограниченной ручным созданием и настройкой очередей. Глобальная централизованная настройка QoS В больших сетях не имеется возможности для контроллера управлять выделением ресурсов каждому потоку трафика и применять QoS на конкретный поток данных. Коммутаторы имеют ограничение на количество записей в таблице OpenFlow, поэтому целесообразно использовать группировку (агрегацию) нескольких потоков в единую логическую группу и управление выделением ресурсов на эту группу. Большинство QoS политик классификации работают именно по этому принципу. В OpenFlow существует понятия «aggregative VLAN» и «aggregative flow», которые позволяют применять правила агрегации на уровне коммутатора и контроллера, не теряя при этом данные отдельного потока. Контроллер должен постоянно проводить мониторинг всей сети с целью обеспечения глобального управления ресурсами. Например, все коммутаторы могут пересылать LLDP, DHCP, ARP пакеты на контроллер, который всегда будет иметь у себя полную актуальную топологию сети со всеми связями и конечными устройствами. При необходимости контроллер может рассчитать места внедрения или удаления политик QoS, заново рассчитывать оптимальные маршруты с учетом применения QoS и требований приложений. Кроме того, предлагается регулярно делать дамп таблиц OpenFlow с коммутаторов и проводить их анализ для выявления несоответствий. Дополнительно во многих коммутаторах предоставляется возможность запроса QoS конфигурации. Для обеспечения функции глобального управления производительностью и качеством обслуживания сети необходима единая модель, в которой будет учитываться топология, полоса пропускания и настройки QoS для каждого потока. Модель расчета производительности Предлагаемая модель применения политик QoS основывается на базовых возможностях коммутаторов в области качества обслуживания, таких как - ограничитель скорости и статические очереди с приоритетами. Ограничитель скорости в OpenFlow коммутаторах реализован с некоторыми отличиями от RSCP в обычных коммутаторах. Введем обозначения: f0 - поток данных; rf0 - требуемая пропускная способность; df0 - допустимая задержка. Для обеспечения потоку f0 требуемой скорости rf0 необходимо вычислить остаточную пропускную способность arf как разность максимально доступной пропускной способности C и суммы текущих (пиковых) скоростей остальных потоков sum fi (С - SUM rfi). Затем проводится сравнение, не превышает ли rf0 остаточной полосы пропускания arf. Данное ограничение вставляется на коммутатор, куда впервые попадает искомый поток данных. Делается это с той целью, чтобы ограничить влияние потока на сеть. Однако при глобальном управлении сетью минимизация задержек на протяжении всей сети представляет собой проблему. В большинстве OpenFlow коммутаторов на каждый физический порт приходится 8 очередей. Очередь с номером 8 - самая низкоприоритетная. Предположим, что на одну из очередей (q8) порта 8 ассоциированы 6 потоков f - f с произвольными приоритетами (у f - f приоритет q = 6, у f4 - f6 - q = 4). Добавляется еще один поток f0, который ассоциируется с очередью q5 с приоритетом 5. Задержка потока f0 - df0 - зависит, во-первых, от того, насколько быстро прибывают пакеты в очередях с такими же или более высоки «Инфокоммуникационные технологии» Том 10, № 4, 2012 34 Бахарева Н.Ф., Коннов А.Л., Тарасов В.Н., Ушаков Ю.А ми приоритетами; во-вторых, насколько быстро канал сможет отправить пакеты. Затребованная пропускная R способность порта определяется как сумма всех пропускных способностей rf , I = q...8. Простая задача определения df0 определяется как зависимость f (q5, R58,C8), где q - приоритет очереди ассоциированной с потоком f (q = 5), R - сумма пиковых пропускных способностей rf5...rf8 для всех очередей с приоритетом 5 и выше. Модель расчета задержек Каждый коммутатор на пути следования пакета добавляет свой вклад в задержку. Более приоритетные потоки прибавляют задержки менее приоритетным потокам прибавляют задержку потокамиУ1-/3). При добавленииf потокам f -f задержка еще больше увеличивается. На следующем по пути коммутаторе контроллер может не найти место в очереди для потока f если другой похожий поток с тем же или более высоким приоритетом на том же физическом порту уже подходит к верхнему пределу максимальной задержки. Контроллер должен учитывать взаимодействие потоков, проходящих по одному пути, и будущее взаимодействие потоков на следующих по пути коммутаторах для решения задачи ассоциации потока с очередью. Оптимальное распределение потоков по очередям и назначение им приоритетов является сложной вычислительной задачей. Расчет этих параметров в соответствии с требованиями по задержкам потока f не должно нарушать требования к остальным потокам. Кроме того, необходимо уменьшать время установки новых потоков в таблицу коммутатора. Данная технология получила название SSF(shortest span first) и предназначена для максимизации обеспечения требований по производительности новых потоков при минимизации количества отклоненных потоков. По всему пути следования потока f0 на каждом исходящем порту ассоциируется очередь. Путь следования и очереди выбираются по минимальной вероятности потери потока. Очередь (1..8) назначается в соответствии с выбранным приоритетом на конкретном порту. Если приоритет будет установлен в максимум, поток будет иметь наименьшую задержку, но наибольшее влияние на остальные потоки и наоборот. На каждом порту необходимо вычислить наивысший возможный приоритет для потока f при котором еще возможно минимальное влияние на остальные потоки, и минимально воз можный приоритет, при котором в текущей ситуации возможно выполнить требования по производительности потокаf Диапазон приоритетов назовем /ow/0..h//0. Для каждого значения приоритета можно вычислить значение задержки в текущих условиях для текущих уровней загрузок портов и потоков. Затем проводится серия расчетов для решения задачи минимизации sum df{q,Rq:%, С)-> min, q-> min для каждого порта следования потока каждого коммутатора и диапазона q = qlow...qhi. Особенностью является обратно пропорциональная нелинейная зависимость задержки df от приоритета q. Sw1 port 1: Df[q=3..4]=10.80MC Sw2 poit 8: Df[q=5..H=17..15MC Sw3 port 5: Df(Q=5..6)=8..3MC Рис. 1. Расчет задержек на маршруте После расчета вариантов прямого потока трафика необходимо рассчитать еще и обратный поток трафика (ответ). Особенностью такого подхода является возможность динамической ассоциации приоритета потока на порт коммутатора в условиях постоянно меняющегося трафика. Выводы В настоящее время идет активное развитие программно-конфигурируемых сетей, и они постепенно приближаются к уровню промышленного внедрения. Развитие технологий, которые физически не могут быть реализованы в традиционной архитектуре, позволит показать существенные преимущества таких сетей в крупных нагруженных сетях. Вопрос обеспечения требуемого качества и производительности сети стоит во главе большинства работ в области традиционных сетей, и варианты реализации глобально-обеспеченной QoS в про-граммно-конфигурируемых сетях очень актуален. Развитие математического обеспечения для задач оптимизации распределения потоков и приоритетов, использование математического моделирования для сокращения времени вычислений оптимальных решений представляет собой актуальное направление для дальнейших исследований. Работа поддержана Федеральной целевой программой «Исследования и разработки по приоритетным направлениям развития научно-технологического комплек «Инфокоммуникационные технологии» Том 10, № 4, 2012

About the authors

N. F Bahareva

A. L Konnov

Email: andrey_konnov@mail.ru

V. N Tarasov

Email: vt@ist.psati.ru

Yu. A Ushakov

Email: andrey_konnov@mail.ru

References

Supplementary files