CC BY
17
УДК 519.687
И.П. Болодурина, профессор, доктор технических наук, заведующий кафедрой прикладной математики, ФГБОУ ВО «Оренбургский государственный университет» e-mail: prmat@mail.osu.ru
П.Н. Полежаев, преподаватель кафедры компьютерной безопасности и математического обеспечения информационных систем, ФГБОУ ВО «Оренбургский государственный университет» e-mail: newblackpit@mail.ru
Ю.А. Ушаков, кандидат технических наук, доцент кафедры геометрии и компьютерных наук, ФГБОУ ВО «Оренбургский государственный университет» e-mail: unpk@mail.ru
А.Е. Шухман, кандидат педагогических наук, заведующий кафедрой геометрии и компьютерных наук, ФГБОУ ВО «Оренбургский государственный университет» e-mail: shukhman@gmail.com
Л.В. Легашев, заведующий лабораторией кафедры геометрии и компьютерных наук, ФГБОУ ВО «Оренбургский государственный университет» e-mail: silentgir@gmail.com
ОБЛАЧНЫЕ ВИРТУАЛЬНЫЕ СЕТЕВЫЕ ЛАБОРАТОРИИ НА ОСНОВЕ IAAS
В статье описан подход к созданию облачных виртуальных лабораторий, предназначенных для изучения сетевых технологий, администрирования и операционных систем студентами в высших учебных заведениях и инженерами при проектировании сетевой инфраструктуры. В его основе лежит визуальное задание и настройка схемы сети через браузер с последующим ее сохранением в формате JSON и автоматическим развертыванием в ЦОД через API облачной системы OpenNebula. После развертывания для обеспечения сетевой связности компонентов виртуальной сети, расположенных на разных физических серверах, используется протокол OpenFlow, поддерживаемый программными коммутаторами Open vSwitch на каждом узле и аппаратными HP 3500 в физической сети. Для проведения экспериментальных исследований был использован ЦОД университета. При условии большой загрузки и большой задержки между клиентом и удаленным рабочим столом поток удаленного управления остается стабильным, что обеспечивает пригодность удаленной работы на серверах с графическим интерфейсом. Результаты эксперимента показали эффективность использования облачных систем в ИТ-образовании.
Ключевые слова: виртуальная сетевая лаборатория, ИТ-образование, инфраструктура в качестве сервиса, OpenFlow, маршрутизация.
На сегодняшний день ИТ-образование подразумевает доступ студентов к сетевой инфраструктуре для выполнения лабораторных работ. Виртуальные машины и соединяющие их сети используются для практического изучения серверных ОС, получения навыков администрирования компьютерных сетей. В сравнении с известными проектами, направленными на проведение экспериментов по исследованию и изучению сетей (GENI, VNET, VNRMS и так далее), которые рассматриваются в статье [8], мы предлагаем более простое решение для обучения, которое использует собственный облачный ЦОД.
Любая конфигурация виртуальной сети требует задания определённого набора узлов и топологии их соединений. В таких сетях используются управляемые маршрутизаторы и коммутаторы. Однако нестандартные топологии и компоненты, которые могут применяться в подобных конфигурациях, исключают использование стандартных физических схем. Также стандартные гипервизоры, такие как
MS Hyper-V, VMWare, Xen vSphere, KVM и облачные агрегаторы (OpenNebula, OpenStack), не дают никакой возможности по созданию и развертыванию топологии по требованию с использованием традиционных способов.
В настоящее время облачные услуги обеспечивают использование любого необходимого количества виртуальных машин, которые, как правило, подключаются к сети с помощью программного коммутатора Open vSwitch (OVS) с поддержкой протокола OpenFlow для организации программно-конфигурируемых сетей. Применение OpenFlow в облачной инфраструктуре позволяет создавать любые топологии, которые независимы от физических ограничений. При этом Open vSwitch интегрируется в топологию в виде коммутатора под управлением одного контроллера OpenFlow. Однако подобная возможность использования Open vSwitch совместно с OpenFlow в существующих сетевых проектах не применяется достаточно широко.
Система, описанная в данной статье, предназначена для автоматизированного создания и развертывания лабораторных и промышленных виртуальных сетей с любой топологией на базе OpenNebula и рассчитана на вышеупомянутое использование Open vSwitch.
1. Описание существующих проблем и способов их решения
Для реализации облачной виртуальной сетевой лаборатории нужно решить одну из проблем, которая заключается в необходимости автоматически создавать и развертывать виртуальную инфраструктуру. При этом необходим инструмент для визуального задания и редактирования схемы сети с учетом текущих возможностей и ограничений облачной инфраструктуры. Кроме того, необходимо преобразовывать схему в наборы командных сценариев для развертывания инфраструктуры по требованию на облачных серверах.
В некоторых статьях представлены автоматизированные методы создания топологий для виртуальных сетевых лабораторий. Проект UNetLab [3] предоставляет возможность задания виртуальных топологий, но лишь в рамках одной виртуальной машины. Авторы используют QEMU, Dynamips и Open vSwitch для эмуляции реальной топологии, SSH через Web-интерфейс для доступа к настройкам устройств. Подобный подход имеет проблемы с масштабированием, потому что ресурсы виртуальной машины ограничены, поэтому в рамках нашего проекта предоставляется возможность развертывания виртуальных узлов одной топологии на нескольких виртуальных машинах. Также в проекте применяется значительно упрощенный Web-интерфейс с целью обеспечить совместимость со старыми компьютерами.
Чтобы связать узлы виртуальной сети, расположенные на разных компьютерах физической сети, облачные системы обычно используют VLAN или VXLAN. Мы протестировали подход на основе GRE внутри гетерогенной топологии [6] для создания безграничного единого сетевого пространства без каких-либо аппаратных ограничений. Этот метод использует виртуальные подключения по GRE поверх любой физической топологии сети.
Методы управления сетевыми ресурсами и разработка эффективных алгоритмов маршрутизации и обеспечения QoS в программно-конфигурируемых сетях были подробно описаны в [4, 7]. В работе [5] представлена комплексная система управления виртуальными и физическими сетями с применением технологии программно-конфигурируемых сетей. Внутри подобных конвергентных сетей контроллер может принимать решения по маршрутизации потоков данных практически без задержки. В работе [10] авторы использовали OpenFlow для мониторинга IP и маршрутизации в режиме реального времени без привязки по МАС-адресам.
В работе [9] описывается метод контроля трафика протокола. Он работает вплоть до уровня L7 и реализует маршрутизацию на основе конкретных протоколов. Данный метод может использоваться при решении проблем балансировки нагрузки и гарантирования параметров QoS для потоков, данных в высоконагруженных облачных сетях за счет эффективной маршрутизации всех критически-важных протоколов.
Задача визуального отображения виртуальной сети, включая определенный набор компонентов, имеющих предварительно установленные ограничения, была рассмотрена в ряде исследований. Существуют различные решения для визуализации и работы с диаграммами и графиками, такие как Draw2D [2] и Cytoscape.js [1]. Самым простым для использования и интеграции является компонент Draw2D, который имеет открытый исходный код и поддерживается во всех браузерах. Для использования данного компонента схемы сети задаются в формате JSON.
Пример простой схемы сети с двумя компьютерами и маршрутизатором представлен на рисунке 1. Описание топологии сети в формате JSON для этого примера представлено на рисунке 2. Благодаря простому описанию схемы и удобному графическому представлению можно создавать гораздо более сложные схемы с большим числом взаимосвязанных компонентов.
PC
VLANrl _____________
Filter:none Fil1er:none I
ч --PC
( label l< I--^ '-
__Imn- \Kfii
Img: WinXP-1
NIC:1
Mem:512
Img: CiscoWXR NIC: 2 Mem: 123
Img: WinXP-1
NIC:1
Mem:512
Рисунок 1. Пример простой сети
"type": "draw2d.shape.basic.Rectangle",
//Rectangle PCI
"id": "354fa3b9-a834-Q221-2009-abc2d6bd852a", //ID
"userData": {IMG: WinXP-1, NIC:1, MEM: 512}, //Load parameters
"ports": [{ //Ports
"type": "draw2d.Port", //Type
"id" : "ebfl>35bb-5767-8155-c80+- 14bd48789dc21", //II)
"us erData" : {name: ethO, speed: 1 OOtx, vlan : 1}, //Settings
"name": "ethO", //Name
]}.{
"type" : "draw2d.shape.basic.Rectangle", //Rectangle PC2
"id": "354fa3b9-a834-0221-2009-abc2d6bd852a", //ID
"userData": {IMG:WinXP-1, NIC:1, MEM: 512}, // Load parameters
"ports": [{
"type": "draw2d.Port", //Type
"id" : "ebfl>35bb-5767-8155-c80+- 14bd48789dc22", //II)
"userData": {name :eth0, speed : 100tx,vlan: 1}, //Settings
"name": "ethO",
//Name
]},{
"type": "draw2d.Connection", //Link
"id": "69f7e40c-4586-0d7f-8817-c798f8c07969",
"userData": {Type:OVS, VLAN:1, Filter:none, Dupls ;x:yes}, //Link settings
"source": {
"node": "ebfb35bb-5767-8155-c804-14bd4S789dc21 "} Ji Source
"target": {
"node": "ebfb35bb-5767-8155-c804-14bd48789dc22"}}//Destination
Рисунок 2. Описание JSON топологии сети
Другой проблемой, связанной с разработкой облачных виртуальных сетевых лабораторий, является автоматическое создание скрипта для автоматического развертывания сети в соответствии со схемой ее топологии. Для решения этой задачи выбран XML-RPC, который поддерживается на большинстве платформ и используется для взаимодействия с OpenNebula. Эффективной реализацией XML-RPC для Python является модуль ОСА. Он применяется на серверной стороне для автоматизации процесса.
Скрипт для развертывания инфраструктуры использует метод one.template.instantiate() для создания виртуальных машин на основе имеющихся шаблонов. Информация о параметрах сетевых карт и их количестве передается в данный метод. Все виртуальные машины, порождаемые подобным образом, создаются в состоянии «Hold». Размер параметров памяти, настройки сетевых карт и ряд прочих характеристик может быть изменен после того, как виртуальная машина была создана.
Основную нагрузку на проектирование связей между объектами берет на себя модуль маршрутизации. По полученным сведениям о первоначальном размещении объектов по физическим серверам, а также исходя из предоставленной схемы связи, списков фильтрации и подсетей модуль создает правила OpenFlow для коммутаторов и OVS для обеспечения работы топологии. Правила задаются в виде: <IN_PORT = значение> <фильтры для заголовков> <перезапись заголовков> <целевой порт>.
При этом подобные правила устанавливаются проактивным образом (заранее, до появления потоков данных в сети). Каждый коммутатор OVS получает от контроллера OpenFlow свой набор правил для маршрутизации трафика (при этом также обеспечивается и его изоляция). При отсутствии высоких требований к пропускной способности сети контроллер OpenFlow может быть использован для обработки всех передаваемых по сети потоков данных. В этом случае на коммутаторах должно быть установлено правило следующего вида:
<IN_PORT = значение> <forward CONTROLLER^ которое отправляет все пакеты с заданного входящего порта на контроллер.
В качестве контроллера OpenFlow для реализации проекта был выбран Ryu SDN, который позволяет формировать таблицы правил на коммутаторах через REST-интерфейс контроллера. 2. Описание реализации Для реализации предлагаемого в рамках настоящего исследования подхода в небольшом ЦОД была развернута облачная система на базе OpenNebula (рисунок 3). Все серверы имеют две сетевые карты: одну для сервисной сети, а другую - для облачной. Последние подключаются к коммутатору OpenFlow и по умолчанию работают в обычном режиме переключения с динамическими VLAN.
OpenlUebula cDntloller
OpenFlow controller
IS]
Automatization sys :em
Рисунок 3. Схема облачной системы
Каждый сервер имеет виртуальный коммутатор Open vSwitch (ovs-br0) для подключения к виртуальным машинам (рисунок 4).
С точки зрения контроллера OpenFlow каждый прокладываемый маршрут представляет собой последовательность входных и выходных портов (рисунок 5). Для его расчета используется алгоритм Дейкстры на основе информации, которую контроллер получает через протокол LLDP.
Виртуальная сеть начинает работу после того, как виртуальные машины были развернуты, и были установлены все правила маршрутизации для реализации сетевых подключений согласно схеме топологии. Для получения доступа к виртуальным машинам и их консолям используется протокол VNC (по умолчанию для KVM) через браузер с расширением NoVNC.
Рисунок 4. JSON описание топологии сети
Рисунок 5. Маршрут, проложенный через сеть
Пользователь облачной виртуальной сетевой лаборатории при просмотре схемы сети в браузере может сделать двойной щелчок по виртуальной машине, что приведет к открытию окна с консолью для доступа к ней. Механизм доступа работает следующим образом - на порту 443 работает п^пх, который пересылает трафик NoVNC. Дальнейший доступ осуществляется с использованием уникальных токенов, получаемых из базы данных Ореп№Ьи1а, что позволяет зарегистрировать реальные 1Р-адреса и порты сервера в NoVNC. Каждый пользователь имеет доступ только через свои токены.
3. Экспериментальные исследования
Для экспериментального исследования был использован учебный ЦОД Оренбургского государственного университета. Вычислительный центр включает в себя четыре двухпроцессорных сервера и восемь однопроцессорных серверов с 32 Гб оперативной памяти на каждом из них. Сервисная и облачная сети реализуются коммутаторами НР3500, которые поддерживают протокол OpenFlow. Поверх
серверов развернута облачная система OpenNebula. Все серверы имеют мост Open vSwitch с поддержкой OpenFlow для связи виртуальных машин и сети. Для хранения используется распределенное хранилище Ceph на четырех серверах по два диска 1Тб с кешированием в SSD на еще четырех серверах. Также используется кеширование записи KVM в оперативную память для увеличения быстродействия. Все сети работают на скорости 1 Гбит/с, связь между коммутаторами на скорости 10 Гбит/с.
Первый эксперимент был проведен для оценки производительности хранилища с учетом различных конфигураций. Виртуальные машины запускались в автоматическом режиме, время запуска и задержка в работе хранилища замерялись одновременно. Запуск осуществлялся командой onevm resume, время запуска регистрировалось скриптом мониторинга, который использовал команду onevm list. На рисунке 6 показаны результаты эксперимента для количества одновременно запускаемых виртуальных машин от 1 до 50.
120 п / / 95
100 - о Я S 80 - / - 85 - 75
о / - 65
1 60 - tr> / - 55
1 40 -Я - 45 - 35
20 - — — - 25
0 1 1 1 1 1 1 1 - 15
о
5
я
6
О
е
о
9
1
40
50
5 10 15 20 30 Число виртуальных машин -Задержка запуска ---Латентность СерЬ
Рисунок 6. Измерение времени запуска с одновременным измерением латентности хранилища Ceph
Как видно на рисунке 6, латентность хранилища растет экспоненциально по мере увеличения количества виртуальных машин. Это связано с ростом задержки доступа к дискам хранилища. В экспериментальном облаке в хранилище имеется 8 дисков на 4 серверах, которые могут обеспечить теорети-
ческую скорость чтения до 800 Мбайт/с, а дополнительное SSD кеширование дает снижение латент-ности.
На рисунке 7 показана пропускная способность хранилища для операций чтения и записи в расчете на одного клиента.
f 90 -,
о Ш ю 70 -
О Щ.о 50 -
о ю a s щ 30 -
и О о 10 -
£ -10 -
HDD
OSD
Ceph -t 1 Ceph -t 16 Ceph -t 25
13Чтение □Запись Рисунок 7. Пропускная способность хранилища (один клиент)
Заметим, что пропускная способность хранилища в значительной степени зависит от способа доступа. Эксперимент учитывает только одного клиента с несколькими потоками.
С ростом количества клиентов скорость чтения будет расти пропорционально, однако скорость записи останется приблизительно такой же (рисунок 8).
50 п
ю 2
0
1 30
U
о В
и
^ Ю о
£
10 20 Клиенты
30
50
-Чтение---Запись
Рисунок 8. Пропускная способность хранилища в зависимости от количества клиентов
Это связано с распределенным способом чтения и журнальным способом записи. Также надо отметить, что данная система еще не настраивалась на максимальную производительность и не имеет жур-налирования на SSD дисках, что теоретически может увеличить производительность в несколько раз.
Для тестирования пригодности удаленной работы на серверах с графическим интерфейсом (например, Windows Server) требуется измерение скорости потока удаленного графического интерфейса. При скорости до 10 кадров в секунду работа с интерфейсом возможна в комфортных условиях. Также оказывает влияние задержка в канале, которая сильно
зависит от многих факторов, например от нагрузки на процессор и на маршрутизатор. При запуске множества виртуальных машин и одновременном доступе по протоколу VNC к 50 параллельным каналам VNC-KVM необходимо поддерживать стабильную скорость потока независимо от задержки. В системе был использован вариант VLN-HL (High Latency, с высокой задержкой), который подстраивается под задержку и дает стабильную скорость потока. На рисунке 9 показана зависимость скорости потока от задержки в линии (горизонтальная ось) и от периодичности обратной связи (разные графики).
19 п
17
15 -
13
11 -
9 -
—♦—VNC-HL 70 ms -e-VNC-HL 60 ms VNC-HL 50 ms VNC-HL 40 ms -H-VNC-HL 30 ms
ooooooooooooooo
^НГЯО'^-'ОЮС^ООСЛО'ЛООО
^н ^ч fs V") О
Задержка, мс ^
Рисунок 9. Зависимость скорости потока от задержки в линии
Реальная задержка между клиентами и конечной точкой потока не превышает 500 мс для локальной сети, поэтому скорость потока будет стабильной и работа с удаленной виртуальной машиной комфортной.
4. Выводы
Результаты эксперимента показали эффективность использования облачных систем при создании произвольных топологий с большим числом
узлов. Использование OpenFlow позволяет делать топологии первого и второго уровней независимыми от инфраструктуры ЦОД, от VLAN, от настроек маршрутизации. Даже небольшой облачный ЦОД (12 серверов с низким уровнем производительности) способен предоставить виртуальные классы для изучения операционных систем, сетевого администрирования, облачных сервисов и создания различных облачных сервисов и сетей на суммарно до 50 узлов, что хватает для одновременной работы до 10-15 человек. Даже при условии большой за-
грузки и, как следствие, большой задержки между клиентом и удаленным рабочим столом поток удаленного управления остается стабильным и предоставляет достаточные условия для комфортной работы.
В дальнейшем планируется продолжить исследования с использованием высокоскоростного хранилища на базе коммутаторов с 10 Гбит/с и SSD для кэширования, а также с расширением объема ресурсов ЦОД для увеличения одновременного использования несколькими университетами.
Литература
1. Библиотека для анализа и визуализации графиков Cytoscape.js [Электронный ресурс] - Режим доступа: http:// http://js.cytoscape.org/ - (дата обращения: 10.09.2016).
2. Библиотека для визуализации диаграмм и графиков Draw2D touch [Электронный ресурс] - Режим доступа: http://www.draw2d.org/draw2d - (дата обращения: 10.09.2016).
3. Платформа UNetLan [Электронный ресурс] - Режим доступа: http://www.unetlab.com/documentation/ -(дата обращения: 10.09.2016).
4. Полежаев, П., Ушаков, Ю., Поляк, Р., Миронов, А. Применение методов муравьиной колонии в разработке эффективных алгоритмов маршрутизации и обеспечения QoS для корпоративных программно-конфигурируемых сетей // Интеллект. Инновации. Инвестиции, 2014. - № 4. - С. 106-113.
5. Полежаев, П., Шухман, А., Коннов, А. Разработка образовательных ресурсных датацентров на базе программного-конфигурируемых сетей // Труды Международной конференции по науке и технологиям «Современные Сетевые Технологии (MoNeTec)», Москва, Россия, 2014. - С. 133-139.
6. Полежаев, П., Шухман, А., Ушаков, Ю. Система сетевого управления ресурсами для высокопроизводительных вычислений на основе SDN // Труды 14-й Международной конференции, NEW2AN 2014 и 7-й конференции ruSMART 2014, Санкт-Петербург, Россия. - Т. 8638. - С. 219-230.
7. Ушакова, М., Ушаков, Ю., Полежаев, П., Легашев, Л. Методы управления сетевыми ресурсами на основе программно-конфигурируемых сетей // Интеллект. Инновации. Инвестиции, 2013. - № 4. - С. 146-150.
8. Chowdhury, N.M.M.K.; Boutaba, R. Network visualization: state of the art and research challenge //IEEE Communications Magazine, 2009. - Vol. 47. - pp. 20-26.
9. Goija, P., Kurapati, R. Extending OpenvSwitch to L4-L7 service aware OpenFlow switch. // 2014 IEEE International Advance Computing Conference (IACC) - pp. 343-347.
10. Stabler, G., Rosen, A., Goasguen, S., Kuang-Ching, Wang Elastic IP and security groups implementation using OpenFlow. // VTDC '12 Proceedings of the 6th international workshop on Virtualization Technologies in Distributed Computing Date - pp. 53-60.
Исследование было выполнено при финансовой поддержке Министерства образования Оренбургской области (грант № 37 от 30.06.2016 г.) Правительства Оренбургской области и РФФИ (проекты 1647-560335 и 16-07-01004), Президента Российской Федерации в рамках стипендии для молодых ученых и аспирантов (СП-2179.2015.5).
