CC BY
18
М. В. Ушакова, ассистент кафедры АИС, Оренбургский государственный университет e-mail: m.v. [email protected]
Ю. А. Ушаков, кандидат технических наук, доцент кафедры системного анализа и управления, Оренбургский государственный университет e-mail: [email protected]
П. Н. Полежаев, преподаватель кафедры компьютерной безопасности и математического обеспечения информационных систем, Оренбургский государственный университет e-mail: [email protected]
Л. В. Легашев, аспирант кафедры геометрии и компьютерных наук, Оренбургский государственный университет e-mail: [email protected]
МЕТОДЫ УПРАВЛЕНИЯ СЕТЕВЫМИ РЕСУРСАМИ НА ОСНОВЕ ПРОГРАММНО-КОНФИГУРИРУЕМЫХ СЕТЕЙ
Исследования выполнены при поддержке Министерства образования и науки РФ в рамках федеральной целевой программы «Научные и научно-педагогические кадры инновационной России» на 2009-2013 годы» (соглашение№ 14.В37.21.1881 от 09.10.2012), РФФИ (проекты №13-01-97050 и №12-07-31022)
Программно-конфигурируемые сети уже заняли свою нишу в открытых центрах обработки данных, этим вопросом занялись крупнейшие игроки телекоммуникационного рынка, такие как Google, Cisco, IBM. Поэтому вопрос применимости таких сетей в других сегментах рынка на сегодняшний день остается открытым, отчасти из-за относительномалой распространенности таких решений. В статье описаны подходы крупнейших производителей для универсальных и виртуализированных сетей. Целью обзора является изучение нового сегмента оборудования и подходов для реализации программного управления сетями. Основная задача состоит в анализе существующих подходов крупнейших производителей и инновационных решений ведущих лабораторий в области сетевого оборудования для программно-конфигурируемых сетей. В результате была предложена универсальная спецификация требований по управлению сетевой инфраструктурой для подобных сетей для использования при проектировании и выборе технологий.
Ключевые слова: программно-конфигурируемые сети, распределенные вычисления.
Технология программно-конфигурируемых сетей (ПКС), предложенная исследователями Стэнфорда и Беркли в 2008 году [4], с 2011 г. на данный момент развивается консорциумом OpenNetworkmgFoundatюn, включающим несколько десятков ведущих производителей сетевого оборудования и программного обеспечения. В основе подхода ПКС лежит возможность динамически управлять пересылкой данных в сети с помощью открытого протокола OpenFlow. Все активные сетевые устройства объединяются под управлением сетевой операционной системы (СОС), которая обеспечивает приложениям доступ к управлению сетью. Исследованием подхода ПКС занимаются многие ученые, на-
пример, Г. Ванг, Т. Эйджен, А. Шейх, Н. Ма-кеон, Р. Бутнариу, Дж. Рексфорд, К. Ротенберг, К. Макапуна, Ф. Верди, М. Магалхаес, А. За-хемски, Б. Хеллер, Х. Шимониши.
1. Концепция управления на основе ПКС
Поскольку идея ПКС заключается в том, чтобы отделить уровень управления сетевым оборудованием от управления передачей данных, управление потоками данных в ПКС осуществляется централизованно с помощью специализированного программного контроллера с установленной сетевой операционной системой (СОС) и набором сетевых приложений, реализованных поверх ее, работающего под контролем администратора сети на отдельном
сервере. При этом возможна разработка сетевых приложений, использующих специальный высокоуровневый интерфейс для управления сетевой инфраструктурой [6].
Любая СОС при взаимодействии с сетевой инфраструктурой использует приложения, которые обрабатывают свою часть информации и формируют ответные пакеты. При управлении произвольной инфраструктурой с реальными и виртуальными коммутаторами, точками беспроводного доступа, возникает проблема унификации управления. При этом самой большой проблемой является попытка разработчиков перенести традиционные представления о сетях в плоскость виртуальных сетей и интерфейсов.
Контроллер ПКС не различает реальные и виртуальные интерфейсы, во множестве интерфейсов OpenFlow привязка клиента к интерфейсу выполняется по традиционным принципам CAM-таблицы соответствия MAC/IP адреса и интерфейса. Однако при работе с виртуальными коммутаторами типа OpenvSwitch или NECVirtualSwitch виртуальная машина или мобильный клиент, привязанные к интерфейсу, могут быть перемещены на другой сервер или точку доступа в любой момент времени и это может повлечь потерю связи. В программноуправляемом коммутаторе CiscoNexus 1000V, VMwaredvSwitch и подобных при взаимодействии с гипервизором происходит перемещение интерфейса вместе с виртуальной машиной, там нет привязки интерфейса к конкретному коммутатору, интерфейс является единицей коммутации.
2. Обзор технологий для управления ресурсами ПКС
При использовании OpenvSwitch в качестве основы для OpenFlow управления коммутацией, как это сделано в операционных системах коммутаторов HP, NEC, Nicra, Netgear, а также в гипервизорах Xen, KVM, QEMU и в разновидности виртуального коммутатора для VMwareESXi привязка интерфейса к виртуальной машине происходит на конкретном физи-
Приложения обработки пакетов
Поток событий Команды
Вход потока Fjowjn_ _
Приложения
Routing Engine
Арр Engine
Tenants
I Flow In (
J________________L
T
Выход потока Flow Out_
Topo Update
Настройки
Authenticator & Demultiplexer
I”
Topology Engine
Logical Topo Views
Raw Topo DB
События пакетов PACKET IN
Config &
Policy
DB
Monitor
I
I
T
События топологии 1 SWITCH_JOIN !
SWITCH LEAVS
— i
i
SWITCH_JOIN 7 SWITCH_LEAVE i STATS_REQ J STATS REP і
Flow
Installer
FLOW_MOD PACKET OUt
Установщик
записей
Physical DC Network
Сеть
Programmable Switches ПКС Коммутаторы
Рис. 2. Модульная система управления ЦОД на базе NOX
ческом сервере. На рисунке 1 показана общая схема работы всех подобных коммутаторов на примере NECVirtualSwitch [5].
Единицей управления коммутацией здесь остается коммутатор, который не перемещается и привязан к физическому серверу. При использовании туннелирования такие коммутаторы могут объединяться по VPN каналам, они могут управляться одним контроллером, но при этом это будет несколько автономных коммутаторов, не влияющих друг на друга в отличие от того же VMwaredvSwitch, где коммутатор один на все устройства.
Quantum
Big Switch Plugin
Quantum API <--------►
t>-
Моду
Big Virtual Switch
Модуль связи
REST Программный API интерфейс
m
Big Network Controller running BVS
1
H Y P E R V I S O R
.^i'i Virtual Switch
Рис. 3. Расположение модуля сопряжение с контроллером облачной системы
В работе Ripcord [2] рассматриваются принципы управления инфраструктурой в целом, для этого разработана концепция модульного управления (рис. 2).
Однако из нестандартных модулей следует выделить только модуль «Tenants», разграничивающий доступ для нескольких арендаторов и «Соnfig&PolicyDB», содержащий сведения о настройках для конкретной сети. В работе не описаны механизмы прямого взаимодействия контроллера и системы управления ЦОД или беспроводной сетью с целью обеспечения мобильности устройств.
Рассмотрим альтернативные подходы к обеспечению мобильности и, следовательно, к более гибкому управлению всей инфраструктурой. Компания BigSwitch, специализирующаяся на производстве программного обеспечения для коммутаторов, и разработчики контроллеров Floodlight, BigNetworkController предложили концепцию модуля для облачных систем OpenStack - TheBigSwitchQuantumPlugin [1] в соответствии с рисунком 3.
Такое размещение модуля позволяет перехватывать команды на перемещение, запуск и остановку виртуальных машин, и тем самым отслеживать перемещения в момент их начала. Схожие решение по размещению дополнительных модулей управления есть у CiscoNetworks (CiscoCloudlaaS), AristaNetworks [7] (AristaSof twareDefinedCloudNetworking, SDCN). Все эти решения позволяют взаимодействовать программному обеспечению и контроллеру сети, что является прямым способом управления инфраструктурой ПКС.
Самый комплексный подход к управлению инфраструктурой наблюдается в CiscoONE [3] (OpenNetworkEnviroment) концепции управле-
Ґ C, JAVA, Python V , REST, Программируемые интерфейсы У
onePKAPIPresentation (Уровень представления)
О о
onePKAPIInfrastructure (Уровень взаимодействия с инфраструктурой)
С N IOS I XE (Catalist, ISR, ASR1K v J Ґ N NXOS (Nexus Platforms) Ґ N IOS XR (ASR 9K, CRS) V У
Рис. 4. Платформа CiscoOnePK
Рис. 5. Схема обработки пакетов в CiscoONE
ния через платформу ОпеРК (OpenNetworkEnv iromentPlatfotmKit), как показано на рисунке 4.
Данная платформа реализует единообразное управление как ПКС оборудованием (OpenFlow, NXOS), так и стандартными СОС ^со (IOSXE/XR). При этом управление происходит через открытый языконезависимый интерфейс TCP-XML, что позволяет получить совместимость с произвольными контроллерами при написании внешних приложений. На рисунке 5 в каждом устройстве установлен специальный программный модуль ОпеРК, работающий по тем же принципам, что и OpenFlow.
3. Выводы
В результате можно сформулировать требования по управлению инфраструктурой в целом, компьютерными сетями и потоками данных:
а) система управления должна покрывать как физические, так и виртуальные и облачные сетевые устройства и среды;
б) система должна обеспечивать инструменты визуализации, диагностики и решения проблем;
в) система должна иметь инструменты взаимодействия с программным обеспечением потребителей сети передачи данных - гипервизорами, сервисами, протоколами;
г) система должна обладать интерфейсом внешнего управления и взаимодействия платформонезависимого вида;
д) система должна поддерживать резервирование в активном или пассивном режимах;
е) система должна поддерживать возможность разделения сети на сегменты под разным административным управлением;
ж) система должна поддерживать управление трафиком по шаблонам и расписаниям для оптимизации работы сети.
Отдельно можно специфицировать требования к коммутации и маршрутизации:
а) при использовании в ЦОД система должна запоминать каждый добавленный узел и по возможности сразу записывать маршрут во все требуемые коммутаторы;
б) система должна по возможности учитывать существующие потоки при маршрутизации новых потоков;
в) для агрегации маршрутов маршрутизацию желательно проводить на физические устройства виртуальных узлов;
г) по возможности необходимо использовать принципы канальной коммутации VPN или MPLS для сокращения количества возможных направлений распространения трафика.
Создание сервиса для управления всей инфраструктурой является сложной задачей, оптимальным вариантов видится создание модульной платформы, взаимодействие с которой может осуществляться по универсальным программным интерфейсам, что позволит действительно отвязать контроллер от приложений, осуществляющих управление сетью.
Литература
1. Big Virtual Switch and OpenStack [Электронный ресурс] // Web site BigSwitch: [сайт]. - URL: http://www.bigswitch.com/sites/default/files/sdn_resources/openstack_aag.pdf. - Дата обращения:
03.04.2013.
2. Brandon Heller. Ripcord: A Modular Platform for Data Center Networking / Brandon Heller, David Erickson, Nick McKeown [Электронный ресурс] // Conference SIGCOMM’10 site: [сайт]. -URL: http://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p457.pdf. - Дата обращения:
15.04.2013.
3. Martinussen, B. Introduction in SDN relevant to DC [Электронный ресурс] / B. Martinussen // Cisco Systems site: [сайт]. - URL: http://www.cisco.com/web/europe/ciscoconnect2013/pdf/DC_3_ SDN.pdf. - Дата обращения: 10.04.2013.
4. McKeown, N. OpenFlow: Enabling Innovation in Campus Networks / N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, J. Turner // ACM SIGCOMM Computer Communication Review. - New York, 2008. - Т. 38. - № 2. - С. 69-74.
5. ProgrammableFlowOpenFlow-based Network Fabric for Hyper-V [Электронный ресурс]// Nec site: [сайт]. - URL: http://www.nec.com/en/global/prod/pflow/images_documents/201302_PF1000_ datasheet.pdf. - Дата обращения: 01.04.2013.
6. Смелянский, Р. Л. Программно-конфигурируемые сети [Электронный ресурс] / Р Л. Смелянский //Сайт издательства «Окрытые системы». - 2012. -URL: http://www.osp.ru/os/ 2012/09/13032491. - Дата обращения: 04.04.2013.
7. Software Defined Cloud Networking // AristaNetworks: [сайт]. - URL: http://go.aristanetworks. com/l/12022/2012-03-08/qz2/12022/1411/SDCNWhitepaper.pdf. - Дата обращения: 08.04.2013.
