CC BY
42
порталов [Текст] / С.А. Лазарев, А.В. Демидов // Информационные системы и технологии. - Орел: Госуниверситет-УНПК, 2012. - № 4 (72). - С. 103-110.
5. Фролов А.И. Управление процессами информационного обмена в распределенной информационной среде в условиях перегрузки [Текст] / И.С. Константинов, А.В. Коськин, А.И. Фролов // Известия Тульского государственного университета. Серия «Технологическая системотехника». Выпуск 8. Труды участников V Международной электронной научно-технической конференции «Технологическая системотехника - 2006». - Тула: Изд-во ТулГУ 2006. - С. 51-60.
6. Константинов И.С. Создание распределенной телекоммуникационной сети учебно-научно-производственного комплекса ОрелГТУ / С.И. Афонин, А.В. Коськин, И.С. Константинов, С.А. Лазарев // Образовательная среда сегодня и завтра: Материалы II Всероссийской научно-практической конференции. - М.: Рособразование, 2005. - С. 293-294.
7. Коськин А.В. Технологическая среда для комплексного сопровождения процессов информатизации организационно-технических систем.: Монография / Под ред. И.С. Константинова. - М.: Машиностроение-1, 2006. -240 с.
8. Еременко В.Т. Математическое моделирование процессов информационного обмена в распределенных управляющих системах: монография / Под общ. ред. И.С. Константинова. - М.: Машиностроение-1, 2004. - 224 с.
БАЛАНСИРОВКА НАГРУЗКИ НА КОНТРОЛЛЕРЫ ПРОГРАММНО-КОНФИГУРИРУЕМОЙ СЕТИ
© Ушакова М.В.*
Оренбургский государственный университет, г. Оренбург
Программно-конфигурируемые сети сейчас начинают завоевывать популярность в центрах обработки данных, в узловых точках передачи Интернет трафика. Поэтому вопрос производительности таких сетей на сегодняшний день остается открытым, отчасти из-за относительной новизны таких решений. В статье описаны методы масштабирования контроллеров таких сетей, не зависящие от конкретного производителя оборудования.
Ключевые слова: программно-конфигурируемые сети, распределенные вычисления.
Программно-конфигурируемые сети используют в основе отделение системы управления коммутатором от самого коммутатора. Существующие
* Ассистент кафедры Администрирования информационных систем.
решения по реализации уровня управления имеют ограниченную масштабируемость из за централизованности. Все существующее контроллеры для протокола OpenFlow, за исключением коммерческого Onix с закрытым исходным кодом, не предоставляют никаких средств для создания нескольких экземпляров контроллера кроме создания нескольких потоков [1].
Кроме того, отсутствие возможности простыми методами резервировать контроллеры снижает надежность сети. Производительность контроллера строго зависит от производительности сервера, на котором он размещен, и от реализации механизмов обработки данных в программном коде.
Сама по себе реализация большинства контроллеров предлагает интерфейс программирования приложений (Application programming interface, API) для работы с физическим, канальным и сетевыми уровнями передаваемых данных. Однако большинство приложений не нуждаются в точном знании основ работы контроллера или ПКС, это нарушает принцип модели OSI, где уровень приложения не обязан знать, как реализован сетевой или канальный уровень. Нарушается принцип универсальности уровней.
Большинство контроллеров имеют в составе механизмы для взаимодействия с внешними приложениями, такие как Web-json интерфейс или RPC. Однако реализация таких взаимодействий сильно зависит от контроллера и может разниться от версии к версии. Управление контроллером из веб-приложений пока представляет собой единичные прототипы, реализованные для конкретных контроллеров и не интегрируемые в существующие приложения [2].
Во-первых, предлагается добавить новый слой API, реализующий абстрактные примитивы сетевых объектов, таких как распределенные сетевые хранилища, группы пользователей, группы приложений. Во-вторых предлагается разделить уровни управления сетевым и канальным слоем от уровня управление физической инфраструктурой. Это позволит приложениям, работающим непосредственно с устройствами не влиять на более высокоуровневые приложения
В третьих предлагается использовать произвольное количество предна-строенных контроллеров с приложением, обеспечивающим синхронизацию экземпляров контроллера и доступ к хранилищу сведений о сети. Создаваемый API позволит сетевым приложениям взаимодействовать не с контроллерами, а с интерфейсом хранилища информации, из которого контроллеры будут брать сведения для прокладки маршрутов, настройки параметров потоков и прочих функциональных особенностях сети.
Создание произвольного числа экземпляров контроллера позволит повысить масштабируемость в нужной в данный момент степени. Однако для повышения отказоустойчивости в соответствии с принятой в большинстве промышленных решений кластеризацией, необходимо организация распределенной точки входа в сервис. В данном случае, распределенная точка вхо-
да может подразумевать различные адреса контроллеров, что не поддерживается текущей версией протокола OpenFlow. Поэтому предлагается искусственно создать такую точку входа с автоматическим динамическим распределением подключенных коммутаторов по экземплярам контроллера. Это полностью согласуется с концепцией реализации сети как услуги в облачной инфраструктуре.
В единственном реализованном распределенном контроллере Onix используется распределенная база данных для хранения всей необходимой информации. В этой базе данных хранится полный граф всей сети, представляющий из себя топологию физического уровня и записи о состоянии и параметрах узлов сети. Для каждого экземпляра контроллера создается экземпляр базы данных. Все изменения одного экземпляра реплицируются на остальные экземпляры базы данных. Все приложения работают только с этой базой данных и не взаимодействуют с контроллером напрямую. В процессе репликации в таком случае могут возникать конфликты из-за отсутствия возможности разграничения прав доступа на ресурсы, существует теоретическая возможность блокировки ресурсов каким-либо приложением.
Такой подход поход на работу протокола OSPF, где все маршрутизаторы обмениваются между собой информацией о топологии сети, но каждый маршрутизатор сам рассчитывает все параметры маршрутов. Однако, отсутствие взаимодействия разных контроллеров с целью оптимизации процессов управления сетью снижает эффективность и точность расчетов и может допустить возникновение петель маршрутизации и рассогласования базы данных.
Предлагаемый подход обязывает контроллеры взаимодействовать с единой отказоустойчивой СУБД посредством транзакций. Наличие единой базы данных снимает вопрос несогласованности экземпляров базы данных, при использовании кеширования обеспечивает сравнимое быстродействие с вариантом локальных баз данных, обеспечивает простое взаимодействие приложений с единой точкой управления.
Контроллер Onix использует принцип кластеринга для создания виртуальной единой точки входа в контроллер. Предполагается наличие единственной мастер-машины, которая перенаправляет запрос к нужному элементу кластера, однако отсутствует парадигма единого пространства данных, как при создании кластеров веб-серверов или кластеров баз данных.
Схема работы распределенного контроллера показана на рис. 1. Использование стандартного протокола балансировки сетевых пакетов GLBP позволяет проводить балансировку по коммутаторам в автоматическом режиме.
Основная трудность реализации такой схемы состоит в высокой задержке при выполнении транзакций с СУБД. Локальные переменные на чтение показывают производительность выше на несколько порядков. Для решения этой проблемы предлагается использовать локальное кеширование данных
на основе дублирования используемых данных. В создаваемых компонентах должен использоваться объектно-ориентированный подход для доступа к СУБД, при котором каждая необходимая для общего пользования переменная в объекте будет ассоциирована с объектом в БД (полями, строками или запросами таблиц). При этом каждое поле БД при обращении помещается в оперативную память и хранится какое-то время. Удаление неиспользуемых данных должно происходить не по методике вытеснения, а по таймеру, что должно привести к экономии операций ввода-вывода. Для языков C++ и Python данный подход к хранению данных в СУБД реализуется дополнительными библиотеками и не вызывает сложностей в реализации. При этом каждый контроллер имеет доступ к информации обо всех потоках, узлах в сети из единой СУБД в любой момент времени, и может подменить любой другой вышедший из строя контроллер.
Узел 1 с СУБД и контроллером Узел 2 с СУБД и контроллером
Рис. 1. Схема работы котроллера сети с распределенным хранилищем
Предлагаемое решение использует единую базу данных и, соответственно, единое пространство данных. За распределение нагрузки от единой точки входа по экземплярам контроллера может отвечать промышленная система распределения нагрузки (например Cisco Content Services Switch, nginx) или любые другие программные и аппаратные реализации балансировщиков нагрузки. Такая универсализация достигается за счет отказа от использования кластеринга на базе механизмов операционных систем. Рас-
пределение нагрузки происходит по принципу обратного прокси-сервера. В этом случае мастер-машина может иметь горячий или холодный резерв, реализованный средствами протоколов типа GLBP, HRSP и подобных.
Список литературы:
1. Koponen T., Casado, M., Gude N., Stribling J. Onix: A Distributed Control Platform for Large-scale Production Networks [Электронный ресурс]. - Режим доступа: http://static.usenix.org/events/osdi10/tech/iull_papers/Koponen.pdf.
2. Ушаков Ю.А. Канальная коммутация в программно-конфигурируемых сетях [Текст] / Ю.А. Ушаков, В.Н. Тарасов, А.Л. Коннов // Новые информационные технологии и системы: труды Х международной научно-технической конференции (г. Пенза). - Пенза: Изд-во ПГУ, 2012. - С. 104-109.
