CC BY
12
М. В. Ушакова, ассистент кафедры АИС, Оренбургский государственный университет e-mail: m.v.ushakova@mail.ru
УПРАВЛЕНИЕ СЕТЕВОЙ ИНФРАСТРУКТУРОЙ НА ОСНОВЕ ПРОГРАММНО-КОНФИГУРИРУЕМЫХ СЕТЕЙ
Исследования выполнены при поддержке Министерства образования и науки Российской Федерации в рамках проекта М 14.514.11.4048 ФЦП «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2013 годы» и РФФИ
(проекты №12-07-31089 и №12-07-31022)
На сегодняшний день все большее распространение получают беспроводные сети семейства стандартов IEEE 802.11. Но даже последние нововведения в стандарт не решают проблему гибкого управления сетевой инфраструктурой. В статье предложена концепция единообразного управления сетевой инфраструктурой вне зависимости от типа носителя на базе программно-конфигурируемых сетей.
Ключевые слова: программно-конфигурируемые сети, беспроводные сети.
Как известно, в основе работы любой компьютерной сети лежат две основные задачи: идентифицировать получателя данных и его местоположение и доставить данные от отправителя к получателю. Разграничение управления сетевым оборудованием от управления передачей данных за счет разработки специального программного обеспечения, которое может работать на обычном выделенном компьютере и которое находится под контролем и управлением администратора сети, является относительно новым способом повышения эффективности работы сетевой инфраструктуры.
Управлять сетью в целом, а не отдельными экземплярами сетевого оборудования намного выгоднее [5], чем разрабатывать множества протоколов взаимодействия при децентрализованном управлении. В основе программно-конфигурируемых сетей [2] лежит представление о компьютерной сети как сети, имеющей «плоскость данных», которая отвечает за пересылку пакетов на основе состояния в каждом коммутаторе и «плоскости управления», которая отвечает за вычисление, планирование и управление пересылкой.
Контроллер такой сети формирует данные о состоянии всех ресурсов сети и обеспечивает доступ к ним для приложений управления сетью. Эти приложения управляют разными аспектами функционирования сети, такими как построение топологии, принятие маршрутизирующих решений, балансировка нагрузки и т.п. Для реализации этой идеи был разработан открытый протокол OpenFlow для управления сетевым оборудованием, не ориентированный на продукты какого-либо отдельного поставщика.
1. Постановка задачи
Контроллер используется для управления таблицами потоков коммутаторов, на основании
которых принимается решение о передаче принятого пакета на конкретный порт коммутатора. При росте количества данных, обрабатываемых контроллером, возникает значительное увеличение нагрузки на процессоры сервера. Распределение нагрузки на несколько вычислительных ядер уже реализовано во всех актуальных версиях контроллеров, однако этого может оказаться недостаточно для большого количества одновременных запросов. Кроме того, при реализации контроллеров не учитывается возможность существования холодного резерва и, как следствие, нет механизма репликации сведений о существующих потоках и адресах.
Модули контроллера не должны хранить информацию о потоках только в локальных переменных. Основная проблема состоит в том, что большинство стандартных компонентов контроллера использует локальные переменные в классах для хранения таких данных, как список и смежность коммутаторов, список портов каждого коммутатора, ассоциативный список физических адресов [6]. Каждый компонент работает независимо от других или использует только свойства и методы базовых компонентов. Необходимо согласовать работу локальных переменных и глобального хранилища данных.
2. Методы решения проблемы распределенного контроллера
Схема работы распределенного контроллера показана на рисунке 1. Основная трудность реализации такой схемы состоит в высокой задержке при выполнении транзакций с СУБД. Локальные переменные на чтение показывают производительность выше на несколько порядков.
Для решения этой проблемы предлагается использовать локальное кеширование данных на основе дублирования используемых данных. В
создаваемых компонентах должен использоваться объектно-ориентированный подход для доступа к СУБД, при котором каждая необходимая для общего пользования переменная в объекте будет ассоциирована с объектом в БД (полями, строками или запросами таблиц). При этом каждое поле БД при обращении помещается в оперативную память и хранится какое-то время. Удаление неиспользуемых данных должно происходить не по методике вытеснения, а по таймеру, что должно привести к экономии операций ввода-вывода. Для языков C++ и Python данный подход к хранению данных в СУБД реализуется дополнительными библиотеками и не вызывает сложностей в реализации. При этом каждый контроллер имеет доступ к информации обо всех потоках, узлах в сети из единой СУБД в любой момент времени, и может подменить любой другой вышедший из строя контроллер.
3. Распределенная обработка в беспроводных сетях
Особенность беспроводных сетей в том, что, в отличие от проводных сетей передачи данных, для них существует ряд специфических проблем. По стандарту IEEE 802.11 клиенты выбирают точки доступа на основе собственного решения (от операционной системы или от драйвера сетевой карты). Стандарт не описывает механизм выбора точки доступа по мощности сигнала, и это существенно усложняет управление клиентами в стандартной инфраструктуре.
Уровень контроля доступа к среде передачи данных IEEE 802.11 MAC [3] определяет протокол для передачи кадров данных и взаимодействия станций друг с другом. Доступ к среде передачи
данных в 802.11 реализован посредством функции распределенной координации (DCF), которая использует множественный доступ с контролем несущей и предотвращением коллизий (CSMA/CA) для произвольного доступа к среде, где несколько устройств пытаются одновременно установить связь по сети.
Когда клиент собирается присоединиться к беспроводной сети, он сканирует пространство в поисках доступных сетей, путем отправки пробного кадра на все каналы. Точки доступа, которые получают этот кадр и готовы принять подключение клиента, отправляют ответ на этот кадр; таких точек доступа может быть несколько. Управление ответом на кадр сканирования позволяет управлять точкой доступа, к которой будет присоединен конкретный клиент.
На рисунке 2 показан алгоритм процесса автоматического переподключения клиентов, который инициируется со стороны точки доступа.
Для правильной генерации ACK кадров (которые создаются на аппаратном уровне) необходима дополнительная настройка драйвера сетевой карты. Контроллер сетевой карты будет посылать подтверждающие кадры только при совпадении MAC адреса принятого кадра, SSID и специальной маски. Кроме того, точка может послать сигнал отмены ассоциации, который вызовет попытку переподключения клиента и, следовательно, возможность подключения к другой точке доступа.
Как видно из алгоритма, программа, выполняющая переподключения, должна иметь сведения обо всех точках доступа и всех клиентах на точках доступа. Кроме того, для динамического
Узел 1 с СУБД и контроллером
Модули
управления
А
Локальное
хранилище,
файл
протокола
т
СУБД
Служба
репликации
а
Мастер-служба кластерной СУБД
Узел 2 с СУБД и контроллером
Модули
управления
А
Контроллер
Локальное
хранилище,
файл
протокола
т
СУБД
___ Служба
I репликации
Мастер-служба кластерной СУБД
Коммутатор с OpenFlow
Коммутатор с OpenFlow
Коммутатор с OpenFlow
Рис. 1. Схема работы котроллера сети с распределенным хранилищем
контроля трафика беспроводных клиентов необходимо коммутировать пакеты от всех клиентов на какой-либо коммутатор или маршрутизатор, который будет принимать решения о допуске или отклонении пакета, а также о дальнейшей маршрутизации. Это можно сделать настройками IP протокола в сервисе DHCP при использовании фильтрации MAC адреса получателя на точке доступа, либо просто использовать протокол OpenFlow для коммутации пакетов или перезаписи MAC адресов. На рисунке 3 показана структурная схема такого управления.
4. Реализация программного управления в беспроводной инфраструктуре
При реализации централизованной схемы управления в точке доступа, так же, как и в комму-
таторе OpenFlow, существует модуль управления, отвечающий за связь с контроллером OpenFlow. Приложение коммутации отвечает за передачу уже полученных пакетов так же, как и в коммутаторе, а приложение управления беспроводными клиентами осуществляет сбор статистики, посылку команд на настройку драйвера сетевой карты и задание правил коммутации. Как видно, такой подход требует модификации ПО точки доступа, что возможно только при использовании ПО с открытым исходным кодом. Большинство автономных точек доступа нижней и средней ценовой категории, а также практически все беспроводные маршрутизаторы в тех же категориях поддерживают ПО OpenWRT с открытым кодом, которое уже поддерживает протокол OpenFlow, имеет про-
Рис. 3. Схема управления точкой доступа контроллером программно-конфигурируемой сети
5000,0
4000,0
3000,0
2000,0
1000,0
4686,2
4030,2
3122,9
2716,9
1523,5
I
1340,7
3 контроллера
2 контроллера
1 контроллера
|___| Без СУБД MySQL C СУБД MySQL
Рис. 4. Сравнение производительности решений
граммный коммутатор и возможность создания своего ПО [4]. Модификация драйвера также возможна при изменении исходного кода.
5. Экспериментальные исследования
В качестве платформы экспериментальных исследований был выбран контроллер floodlight, для которого был заимствован модуль управления агентом OpenFlow беспроводных точек доступа. В качестве агента было создано ПО в связке с программным коммутатором OpenVSwitch (OVS). Тестирование производительности такого решения показано на рисунке 4. Как видно из графика, при увеличении количества контроллеров
растет общая производительность, в то же время использование единого хранилища снижает производительность до 15%, что приемлемо при большом количестве контроллеров.
В данный момент существует прототип подобной системы, реализованный в T-LabsBerlin [1]. В качестве основы для контроллера используется контроллер floodlight, реализованный на языке java, клиентом выступает модуль программного маршрутизатора clickmodularrouter. Этот прототип имеет весь необходимый функционал на серверной стороне, однако клиентский модуль может быть скомпилирован не для всех платформ и про-
шивок из-за жесткой привязки к платформе программного маршрутизатора. Управление непосредственно из модуля OpenFlow ОС OpenWRT на сегодняшний день не реализовано, хотя и возможно.
6. Выводы
Представленные методы и алгоритмы позволяют автоматизировать процесс управления уров-
нем доступа беспроводной сети ІЕЕЕ 802.11, а интеграция с сетевой операционной системой позволяет использовать протокол OpenFlow как альтернативу протоколам CAPWAP управления точками доступа, что делает возможной реализацию центрального управления беспроводной инфраструктурой на базе программного обеспечения с открытым исходным кодом.
Литература
1. Department of Telecommunication Systems Internet Network Architectures. BerlinOpenWirelessLab (BOWL) [Электронный ресурс]. - URL: http://www.inet.tu-berlin.de/menue/research/wireless/wireless/. -Дата обращения: 10.04.2012.
2. OpenFlow [Электронный ресурс] // Wikipedia. - URL: http://en.wikipedia.org/wiki/OpenFlow. -Дата обращения: 22.04.2013.
3. OpenFlow: Uninterrupted Streaming from Moving Golf-cart with OpenFlow Wireless [Электронный ресурс]. - URL: http://www.openflow.org/wp/uninterrupted-streaming-from-moving-golf-cart-with-openflow-wireless/. - Дата обращения: 01.04.2012.
4. Тарасов, В. Н. Программно-управляемая виртуализированная беспроводная точка доступа как средство бесшовного роуминга / В. Н. Тарасов, Ю. А. Ушаков, П. Н. Полежаев, А. Е. Шухман, А. Л. Коннов // Вестник Оренбургского государственного университета. - 2013. - № 5. - С. 150-155.
5. Тарасов, В. Н. Математическое моделирование облачного вычислительного центра обработки данных с использованием OpenFlow / В. Н. Тарасов, П. Н. Полежаев, А. Е. Шухман, А. Л. Коннов, Ю. А. Ушаков // Вестник Оренбургского государственного университета. - 2012. - № 9. - С. 150-155.
6. Ушаков, Ю. А. Канальная коммутация в программно-конфигурируемых сетях / Ю. А. Ушаков, В. Н. Тарасов, А. Л. Коннов // Новые информационные технологии и системы: труды Х международной научно-технической конференции (г. Пенза). - Пенза : Изд-во ПГУ, 2012. - С. 104-109.
