Исследование условий перехода на SDN-архитектуру сети провайдера «Орион» г. Снежное

Введение

Требование к современным сетям повышаются, и вместе с этим, с огромной скоростью развиваются различные способы решения таких задач как обеспечение высокого уровня масштабируемости с обеспечением требуемого качества обслуживания (Quality of Service, QoS). При этом стремятся к снижению стоимости сетевой инфраструктуры и издержек на её содержание.

Анализ текущего состояния проблемы

Главная проблема большинства сетей в том, что набор средств по обеспечению QoS изначально заложен производителями в сетевые устройства. Это, в свою очередь, не соответствует скорости внедрения услуг и новых приложений в существующие сети передачи данных. Существующие сетевые протоколы канального уровня, предназначенные для расширения возможностей сетевой инфраструктуры Fiber Channel, Infiniband, а также EthernetII, имеют ограниченные возможности по управлению трафиком и QoS. Усовершенствованные варианты протокола Ethernet – Converged Enhanced Ethernet и Cisco Data Center Ethernet включают расширения по управлению потоками на основе приоритетов, разделению пропускной способности, управлению перегрузками и логическим состоянием полос передачи данных, по обеспечению передачи без потерь, а также по одновременному использованию нескольких параллельных путей передачи данных между узлами. Основные недостатки данных решений – сложная децентрализованная схема управления потоками данных, основанная на множестве закрытых протоколов, значительная стоимость сетевого оборудования, сложность его расширения. Отдельно следует заметить, что данные решения используют реактивную схему управления потоками, когда решения по коммутации принимаются во время передачи потока.

Одним из решений является использование архитектуры программно-конфигурируемых сетей (Software-defined Networking, SDN). Централизация и открытость средств управления SDN позволяет гибко и эффективно адаптировать работу ЦОД под возникающие потребности бизнеса, что ускоряет внедрение инноваций и обеспечивает конкурентоспособность компаний. Наличие потребности компаний в создании эффективных распределенных вычислительных ЦОД, включающих сети хранения данных, на основе SDN, перспективный характер технологии SDN, а также отсутствие готовых решений в этой области являются существенными факторами, определяющими актуальность этого направления. Концепция программно конфигурируемых сетей (SDN) призвана изменить представления и существенно повлиять на подход к построению сетей связи. Комплексный подход к пересмотру основ построения сетей, конечно, начал привлекать внимание компаний поставщиков услуг именно потому, что они видят в ближайшей перспективе, а некоторые уже сталкиваются, с проблемами, которые существующими средствами решить, если и возможно, то очень сложно и не выгодно. Интернет провайдер, имея сегодня сеть, пока соответствующую его потребностям, сталкивается с проблемой значительного ежегодного роста объемов трафика. В таких условиях он вынужден постоянно увеличивать свои расходы, тогда как доходы, которые почти полностью зависят от среднего дохода на одного абонента, нельзя постоянно увеличивать в соответствии с существующими расходами, потому что во-первых, это может стать причиной оттока клиентов, для которых очень важным аспектом является стабильность цены за услуги; во-вторых, даже если цена будет расти высокими темпами, это неизбежно приведет к ситуации, когда ее повышение будет уже невозможным из-за неплатежеспособности населения, которое может выделять из своего семейного бюджета только какую-то незначительную часть средств на услуги интернет провайдера.

Для больших сетей провайдеров проблемой остается скорость восстановления сети после внедрения и настройки нового устройства. Например, при запуске нового устройства, например перенастройка списков доступа (Access Control List, ACL) на всех сетевых устройствах сети может занять немалый срок. Это происходит из-за распределенности управления. В результате администраторам приходится тратить массу времени на то, чтобы перенастроить правила обработки трафика на каждом сетевом устройстве. Аналогичные проблемы возникают, если необходимо перенастроить QoS- механизмы при внедрении нового приложения, например видеосвязи. Аналогичные проблемы появляются если необходимо изменить параметры защиты. Последнее может ослабить общую защищенность сети.

Переход на централизованное управление сетью, реализованное в программно-конфигурируемых сетях позволить ослабить вышеперечисленные недостатки. Основным отличием SDN от сетей передачи данных является централизованное интеллектуальное управление и мониторинг сети, которые обеспечивает проверку, контроль и модификацию потоков передаваемых данных. Согласно концепции SDN, вся логика управления выносится в специализированные контроллеры, которые способны отслеживать работу всей сети (Рисунок 1).

Рисунок 1 – Компоненты SDN - архитектуры

Цель и задачи исследования

Целью работы является выработка рекомендаций по внедрению SDN-архитектуры в действующую сеть. Для достижения поставленной цели необходимо проанализировать возможность перехода к такой структуре.

В ходе исследования необходимо решить следующие задачи:
• проанализировать проблемы внедрения SDN-решений в сеть интернет провайдера;
• разработать рекомендации относительно эволюционного внедрения SDN-решений в транспортную сеть;
• разработать методику оценки параметров экономической эффективности использования SDN-решений интернет провайдером;
• предложить средства эффективного управления мультисервисного трафика транспортной SDN сети;
• разработать имитационную модель, которая позволяет оценить работоспособность и эффективность предложенных решений.

Анализ целесообразности внедрения SDN решений в сеть провайдера

Прoграммнo-кoнфигурируемая сеть (SDN от англ. Software-defined Networking, также программнo-oпределяемая сеть[1-5]) — сеть передачи данных, в котoрой уровень управления сетью реализуется прoграммно и прoстранственно разнесен с устройствoм передачи. Данная архитектура вoзникла, благoдаря неoбходимости разделения функций передачи трафикa и функций упрaвления. Это связaно, в первую очередь с «oграниченностью» функционaла алгoритмов управления трафикoм в существующих сетевых устрoйствах. Т.е. поставщики сетевого оборудования по сути дела предоставляют определенный набор таких функций. В добавлении к этому, процессы передачи трафика, а также процессы управления трафиком реализуются в едином устройстве (микросхеме). Т.о. обеспечивается пересылка пакетов с одного порта на другой на основе правил, определяемых программным обеспечением устройства (анализ пакетов, производит изменение содержащейся в них служебной информации и т. д.).

Концепция SDN позволяет конфигурировать сеть как единую систему, независящую от производителя оборудования. Что достигается путем создания унифицированного интерфейса между уровнем управления и урoвнем передачи данных. Элементами SDN-архитектуры являются: прилoжения SDN, SDN контрoллер, упрaвляющие агенты, функции котoрых заложены в OpenFlow коммутатoры, FlowVisor или интерфейс, oтвечающий за передачу упрaвляющей информации, компoненты упрaвления и администрирoвания.

Приложения SDN предоставляют конечным пользователям требуемые сервисы. Однако они содержат ряд требований к сетевой инфраструктуре.

Контроллер [6-10] является единой централизованной точкой управления. Он взаимодействует с уровнем приложений при помощи открытого интерфейса API, а также выполняет функции контроля за физическими устройствами. Использование контроллера как единой точки управления даёт возможность существенно упростить логику работы и затраты на оборудование архитектуры SDN, так как исчезает необходимость в поддержке и обработке набора протоколов управления на транспортном уровне.

OpenFlow коммутаторы [11-15] ответственны за взаимодействие сетевой инфраструктуры с уровнем управления. В них содержаться одна или несколько таблиц переадресации (flowtable), в которых находятся все данные о потоках передаваемой информации.

Рисунок 2 – Пример таблицы потоков OpenFlow

FlowVisor [16,17,27] обеспечивает распределение управляющей информации между потоками данных. Он определяет множества потоков, которые относятся к той или иной подсети. Также, в его функции входит обеспечение виртуализации потоков управляющих пакетов в отдельные срезы сети.

Компоненты управления и администрирования – это набор статических данных, включающих в себя внешние задачи: координацию политик и правил, принятых при проектировании модели архитектуры SDN, начальные настройки оборудования и правила распределения сетевых ресурсов.

Основой управления SDN является протокол OpenFlow, который отслеживает изменения на уровне передачи данных и заносит их в таблицу переадресации, а также модифицирует и пересылает управляющую информацию между контроллером и коммутаторами. Протокол OpenFlow контролирует обмен сообщениями об изменениях таблиц переадресации, поддерживая при этом стандартный набор параметров.

Принцип работы протокола OpenFlow (7 кадров, количество циклов не ограничено, 138 кб)

Выработка рекомендаций по модернизации сети

Контроллер представляет собой сервер, на котором установлено соответствующее программное обеспечение. Отношения между ним и коммутаторами с поддержкой OpenFlow очень похожи на отношения типа «клиент-сервер», где сервер (контроллер) выносит решение, а клиент (коммутатор) должен воплощать эти решения в жизнь. Поэтому, необходимо решить сколько контроллеров нужно для сети и они должны быть расположены. В общем случае сеть будет иметь вид звезды - то есть один контроллер, подключенный ко всем элементам сети. Однако есть возможность, в зависимости от количества узлов и их расположения, использовать несколько контроллеров, которые будут создавать несколько SDN доменов.

Одним из основных факторов как в расположении контроллера, так и в выборе их количества для крупного интернет провайдера, являются задержки ответов контроллера [18-20] на запросы элементов сети. Очень важно иметь быструю динамичную реакцию на события. Для решения этой проблемы, зная расположение узлов сети и расстояния между узлами, предлагается методика для определения местоположения контроллера.

Предположим, что имеется граф G (V, E), где V-количество узлов, Е-количество соединений. Обозначим d (r, s) - кратчайший путь от узла r принадлежащему V к s принадлежащему V, получим:

Где Lср (R) - средняя задержка при расположении контроллера в r принадлежащего V. Сравнив таким образом средние задержки для каждого возможного r, находим оптимальное расположение контроллера. Если полученное оптимальное значение средней задержки не удовлетворительное, или из-за очень большого количества элементов сети операционных возможностей сервера не хватает, логично было бы использовать несколько контроллеров, разбив перед этим нашу сеть G (V, E) на несколько G1 (V1, E1) .. Gn (Vn, En) по принципу топологической близости узлов сети, и применить к каждому подмножеству предложенную методику. Конечно, в таком случае контролеры должны быть связаны друг с другом. Их взаимодействие должно быть основано на том, что каждый контроллер должен осуществлять связь с соседними через специально выделенный канал связи. Это достигается путем установки приложения на контроллер, для которого взаимодействие контролер-контроллер превращается в разновидность контроллер - коммутатор.

Одним из недостатков централизации управления является меньшая отказоустойчивость сети [21-26]: при выходе из строя управляющего элемента или потере связи с ним «безмозглый» периферийный узел может стать совершенно бесполезным, в то время как при самоуправлении он легко адаптировался к изменившейся ситуации.

Чтобы повысить надежность сети, предлагается делать резервирование контроллеров. Для этого используем FlowVisor - специальный OpenFlow контроллер, который выступает в качестве прозрачного прокси между OpenFlow коммутаторами и несколькими OpenFlow контролерами. Он создает «срезы» сетевых ресурсов и делегирует контроль над каждым срезом различным контроллерам. Таким образом есть возможность иметь два контроллера, что физически присоединены к одним и тем же коммутаторам, но которые «видят» и контролируют лишь часть из них, а в случае отказа одного контроллера автоматически берут на себя контроль над всеми подключенными к себе коммутаторами. Это решает как проблему резервирования контроллеров, так и проблему простоя.

Понимая практическую сложность резкого перехода на новые решения, предлагается следующий алгоритм перехода к SDN, который состоит из трех этапов.

Имея установленный SDN - контроллер, прежде всего необходимо провести последовательную замену граничных маршрутизаторов. Одновременно их заменить нельзя потому, что они задействованы в работе сети и передачи трафика - это приведет к остановке работы всей сети. Таким образом, можно отсоединить один из маршрутизаторов и заменить его на OpenFlow коммутатор, подключенный к контроллеру. Есть также возможность поставить OpenFlow коммутатор в параллель к граничному маршрутизатору и перебросить соединение постепенно. Для сети все выглядит так, будто не произошло никаких изменений, потому что контроллер просто возьмет на себя те же функции контроля, которые были до этого у маршрутизатора. Полностью заменив граничные коммутаторы получим почти SDN сеть, потому что теперь контроллер может определять маршрут следования трафика. Но эта сеть не является полностью SDN сетью, поскольку она не динамично реагирует на процессы, которые в ней проходят - контроллер получает оперативную информацию только о тех соединениях, которые непосредственно подключены к SDN коммутатору.

Чтобы полностью перейти к SDN все элементы сети должны поддерживать OpenFlow и быть подключены к контроллеру. Предлагается методика нахождения основных узлов [28,29], замена которых даст наибольший эффект с точки зрения эффективности управления сетью. Идея заключается в том, чтобы каждый путь в сети проходил хотя бы через один транзитный SDN - коммутатор. Если на первом этапе граничный SDN коммутатор строил путь через всю сеть к другому граничному коммутатору, то теперь он будет строить путь только к ключевому SDN коммутатору. Это позволит логично упростить любой путь и иметь возможность более оперативно реагировать на изменения в сети. Далее приведена методика, которая заключается в нахождении транзитных узлов, которые надо заменять в первую очередь.

Обозначим l_ij - бинарную переменную, которая принимает значение 1, если в сети существует линк между узлами i и j, и x_ij^st - бинарную переменную, равную 1, если соединение между i и j лежит на пути p_n (s, t), где s и t - наши граничные маршрутизаторы. Переменная y_i принимает значение 1, если роутер i должен быть заменен, u_i^st= 1, если путь проходит через SDN-коммутатор. V-множество, в состав которого входят маршрутизаторы с облака. Математическая модель нахождения ключевых узлов состоит из уравнений:

Выражение (2) означает, что должны быть использованы только существующие пути. Выражение (3) - заполняется квадратная матрица a[n][n]. Уравнение (4) предъявляет требование к тому, что каждый путь от одного Edge -s к другому - t должен включать хотя бы один SDN-коммутатор. Уравнение (5) указывает на то, что элемент сети i был выбран для замены. Выражение (6) подсчитывает количество линков d, непосредственно присоединенные к маршрутизатору s. Таким образом, рассчитывается m - общее количество всех возможных путей от s к t. Далее в (7) формируется матрица k с количеством строк, равным числу путей, и количеством столбцов, равным количеству элементов сети. Формула (8) указывает на необходимость минимизировать количество маршрутизаторов, которые требуют изменения, обязательно учитывая условие (5).

Постепенно заменив все маршрутизаторы на SDN - коммутаторы, получаем полноценную SDN сеть.

Вывод

На данном этапе написания магистерской работы был сформирован ряд рекомендацій по внедрению SDN-архитектуры в функционирующую сеть интернет провайдера. В ходе дальнейшего исследования будет проведено моделирование новой SDN-структуры на примере интернет провайдера «Орион» г. Снежное и будет выполнена оценка экономической эффективности.

Предполагается, чтo пoсле завершающего этапа SDN-архитектурa будет обладать пoвышенной прoизвoдительностью (стaбильнaя рaбoтa обеспечивaется даже при 100-процентнoй загрузке каналов), вoзмoжнoстью перестрoйки физическoй сети без прерывaния oбслуживания в виртуaльных сетях, пoвышенной степенью безoпасности за счет полной изоляции виртуальных сетей другу от друга, увеличением надежности сети благодаря самовосстановлению и автоматическому перераспределению потоков трафика в соответствии с правилами.

Таким образом, переход к SDN-архитектуре позволит повысить качество как управления потоками трафика, так и сетью в целом. С другой стороны это решение позволить удешевить модернизацию существующей сети провайдера «Орион» г. Снежное, а, следовательно, улучшить качество услуг при их неизменной стоимости.

Список источников

1. SDN Architecture Overview [Электронный ресурс]. – Режим доступа: www.opennetworking.org.
2. Software defined networking [Электронный ресурс]. – Режим доступа: inau.ua.
3. Центры обработки данных. SDN: «третий элемент» для будущих дата-центров [Электронный ресурс]. – Режим доступа: www.sib.com.ua.
4. Introduction to Software Defined Networking (SDN)[Электронный ресурс]. – Режим доступа: www.cse.wustl.edu.
5. Open Networking:Dell’s Point of View on SDN [Электронный ресурс]. – Режим доступа: i.dell.com.
6. What's Software Defined Networking? [Электронный ресурс]. – Режим доступа: twiki.di.uniroma1.it.
7. SDN-NFV Reference Architecture [Электронный ресурс]. – Режим доступа: innovation.verizon.com.
8. Software Defined Networking (SDN) - Open Flow [Электронный ресурс]. – Режим доступа: www.ics.uci.edu.
9. Программируемый Интернет [Электронный ресурс]. – Режим доступа: www.ripn.net.
10. Software Defined Networking (SDN) and OpenStack [Электронный ресурс]. – Режим доступа: f5.com.
11. Oracle SDN Performance Acceleration with Software-Defined Networking [Электронный ресурс]. – Режим доступа: www.oracle.com.
12. SDN for Service Providers [Электронный ресурс]. – Режим доступа: www.cisco.com.
13. Software Defined Networking Concepts [Электронный ресурс]. – Режим доступа: homepages.inf.ed.ac.uk.
14. Software Defined Networking [Электронный ресурс]. – Режим доступа: www.comp.nus.edu.sg.
15. SDN Software Defined Networks [Электронный ресурс]. – Режим доступа: www.control.lth.se.
16. О.Ю. Евсеева, Е.Н. Ильяшенко, Е.Б. Ткачева Математическая модель и метод комплексного управления ресурсами транспортной программно-конфигурируемой сети // Электронное научное специализированное издание – журнал «Проблемы телекоммуникаций» №1(18) 2016 .
17. Красотин А.А., Алексеев И.В. Программно-конфигурируемые сети как этап эволюции сетевых технологий // Модель и анализ информ. систем. №4 2013.
18. Ю. Ю. Коляденко, Е. Э. Белоусова ПРОГРАММНО-КОНФИГУРИРУЕМЫЕ СЕТИ НА БАЗЕ ПРОТОКОЛА OPENFLOW И ИХ ХАРАКТЕРИСТИКИ // Scientific Journal «ScienceRise» №3/2(20)2016.
19. Н.Ф. Бахарева, Ю. А. Ушаков, М. В. Ушакова, А.Е. Шухман ОСНОВЫ ПРОГРАММНО-КОНФИГУРИРУЕМЫХ СЕТЕЙ // Учебное пособие.
20. Боклагов В.С., Лозинская В.Н. ИССЛЕДОВАНИЕ УСЛОВИЙ ПЕРЕХОДА НА SDN-АРХИТЕКТУРУ СЕТИ ПРОВАЙДЕРА «ОРИОН» Г. СНЕЖНОЕ // Автоматизация технологических объектов и процессов. Поиск молодых : сборник научных трудов ХVII научно-технической конференции аспирантов и студентов в г. Донецке 24-25 мая 2017 г. - Донецк : ДОННТУ, 2017. – 409 с..
21. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2013–2018: Cisco® February 5, 2014 [Електронний ресурс].
22. The Road to SDN: An Intellectual History of Programmable Networks: Nick Feamster, Jennifer Rexford, Ellen Zegura [Електронний ресурс].
23. OpenVirteX – A Network Hypervisor : Open Networking Lab [Електронний ресурс].
24. The Controller Placement Problem: Brandon Heller, Rob Sherwood, Nick McKeown [Електронний ресурс].
25. OpenFlow Switch Specication: Open Networking Foundation June 25, 2012 [Електронний ресурс].
26. DISCO: Distributed Multi-domain SDN Controllers: Kevin Phemius, Mathieu Bouet and Jeremie Leguay [Електронний ресурс].
27. FlowVisor: A Network Virtualization Layer: Deutsche Telekom Inc. R&D Lab, y Stanford University, _ Nicira Networks October 14, 2009 /Rob Sherwood, Glen Gibb, Kok-Kiong Yap [Електронний ресурс].
28. Analysis of CAPEX and OPEX Benefits of Wireless Access Virtualization: the 4th Workshop on E2Nets, Budapest, Hungary, June 9, 2013 / M.M.Rahman, Charles Despins. [Електронний ресурс].
29. Е.В. Дуравкин, Е.Б. Ткачева, Иссам Саад АРХИТЕКТУРА SDN. АНАЛИЗ ОСНОВНЫХ ПРОБЛЕМ НА ПУТИ РАЗВИТИЯ // Системи обробки інформації, 2015, випуск 3 (128).