Оценка показателей эффективности сегмента программно-конфигурируемых сетей

Классическая архитектура сети развивается по мере выявления проблем, решением которой становилось совершенствование и усложнение стека протоколов TCP/IP.

В новой архитектуре, называемой программно-конфигурируемых сетях (ПКС), рассматривается возможность дифференциации функции управления и передачи данных.

При продвижении кадров, коммутатор обращается к таблице коммутации (рис. 1).

Рисунок 1 - Передача данных в Ethernet коммутаторе

В обычном Ethernet коммутаторе сразу реализуются уровни управления, и передача данных. Микроконтроллер сам принимает решения о продвижении кадров. Управлять решениями микроконтроллера нельзя, только его настроить, указывая определенные права и приоритеты. Это накладывает заметные ограничения на функциональность Ethernet коммутаторов и всей сети в целом. В сети «каждый с каждым» требуется использование маршрутизатора (рис. 2).

Рисунок 2 - Схема Ethernet коммутатора и сети «каждый с каждым»

Протокол OpenFlow используется для менеджмента сетевых устройств, такие как коммутаторы и маршрутизаторы с центрального устройства – OpenFlow контроллера сети (может представлен на любой ЭВМ). Такой контроль заменяет работающую на сетевом устройстве программу, осуществляющую построение маршрута, создание карты коммутации и т. д. Контроллер, с установленой СОС. используется для управления таблицами потоков в коммутаторе, на основании которых принимается решение о передаче принятого пакета и затем всего потока на конкретный порт коммутатора.

В OpenFlow коммутаторе реализован только уровень передачи данных. Задача коммутатора в непосредственном принятии поступающих данных и обработке, извлечение их адресов. Если адрес назначения находится в таблице, то данные немедленной передаются коммутационной матрице. Если же информации в таблице нет коммутатор по специальному защищенному каналу передает запрос на центральный контроллер OpenFlow. И уже на основании полученной информации вносит изменения в таблицу потоков, после чего осуществляется обработка данных (рис. 3).

Рисунок 3 – Взаимодействие коммутатора OpenFlow с центральным контроллером сети

Центральный OpenFlow контроллер сети имеет точную информацию о топологии и о ее структуре. Это позволяет, не прибегая к IP-маршрутизации, улучшить качество передаваемых пакетов, а также создавать связи «каждый с каждым» на канальном уровне, (рис. 3). Появляется возможность «коммутировать» каналы передачи от источника до пункта назначения. Поэтому можно считать, что по сети проходят потоки данных, а не отдельные пакеты. Контроллер может взаимодействовать с программным обеспечением высокого уровня — платформами виртуализации ЦОД и др., а также объединять устройства под управлением СОС. Примером таких систем является NOX.

NOX это часть системы программно-конфигурируемых сетей. Это система для создания приложений управления сетью, которые позволяют управлять одним или несколькими коммутаторами. Система NOX работает на аппаратном обеспечении и предоставляет среду, которая может управлять сетями на гигабитных скоростях. NOX является первым и самым распространённым контроллером OpenFlow.

Более практически, NOX позволяет:

• •    NOX предлагает сложную функциональность сети (управление, прозрачность, контроль доступа и т.д.);

• •    Разработчики могут добавить свое собственное программное обеспечение управления;

• •    NOX представляет собой центральную программную модель для всей сети - одна программа может контролировать переадресацию на всех коммутаторах сети;

• •    NOX может быть расширен как в C++ или Python. Текущая версия содержит множество примеров приложений и встроенные библиотеки, которые обеспечивают полезные функции сети, такие как хост отслеживание и маршрутизация.

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

Нами ставилась задача измерения задержки обработки пакетов и потерь при отсутствии записи в таблице OpenFlow коммутатора и потерь пакетов в OpenFlow контроллере NOX. Запустим эксперимент в соответствии с разработанным механизмом по оценке показателей эффективности сегмента ПКС. Полученные результаты экспортируем, для дальнейшей обработки в Microsoft Excel.

Построим график функции по полученным данным (рис. 4). Период сессии составляет 1000 пакетов (длина пакета выставлена 1500 байта).

Рисунок 4 - Задержки пакетов. Горизонтальная ось показывает количество пакетов, вертикальная ось время в секундах

На графике видно, что с увеличением количества передаваемых пакетов растет задержка. Причем задержка наблюдается после передачи примерно 160-го пакета. Отметим, что размер пакетного буфера данного коммутатора составляет 36 MБ.

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

Из графика рисунке 5, видно, что потери растут с увеличением задержек, причем потери наблюдаются, также начиная примерно с 160-го пакета.

Рисунок 5 - Потери пакетов за сессию

Если эксперимент произвести не запуская контроллер, то потери и задержки наблюдаться не будут, согласно спецификации к коммутатору HP 3500, 1000 Мб/с время ожидания: < 3,4 мкс (размер пакета 1500 байта).

Выводы. При отсутствии записей в таблице OpenFlow коммутатора задержки и потери довольно большие (рис. 4 и 5). Если же заранее внести записи, то можно ожидать, что значения задержек и потерь уменьшатся. Это связано с обработкой пакетов на контроллере и созданием правил, по которым в дельнейшем будет “двигаться” пакет.

Согласно полученным результатам использование протокола OpenFlow на начальном этапе для малых сетей не целесообразно. По причинам, высокой стоимости оборудования и развертывания программно-конфигурируемой сети высока, а также вполне справляется со своими задачами традиционное сетевое оборудование.