Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы программно-конфигурируемых сетей. Учебное пособие
.pdf
программистов по управлению распараллеливанием, выполняет большую часть
утомительного и сложного управления распределением рабочей нагрузки и
планирования рабочих потоков. Проект Maestro переносим и масштабируем,
поскольку разработан с использованием платформы Java и поддерживает
многопоточность.
в) Beacon – быстрый кроссплатформенный модульный, основанный на
Java, контроллер OpenFlow, который поддерживает и работу на основе событий
и на основе потоков [51].
Главные особенности:
1) устойчивость – Beacon был в разработке в течение полутора лет и
использовался в нескольких научно-исследовательских проектах, сетевых
классах и испытательном стенде. Beacon в настоящее время функционирует на
100 виртуальных и 20 физических коммутаторах в экспериментальном ЦОД и
работал в течение многих месяцев без сбоев.
2) кроссплатформенность – Beaconнаписан на Java и работает на многих
платформах от высококачественных многоядерных серверов Linux до
телефонов на Android.
3) динамичность – пакеты Beacon могут быть запущены / остановлены /
обновлены / установлены во время выполнения не прерывая другие
независимые пакеты.
г) Trema – платформа контроллера OpenFlow, которая включает все
необходимое для создания контроллеров OpenFlow на Ruby и/или C [52].
Платформа включает весь исходный код Trema, необходимый для
самостоятельной разработки контроллеров OpenFlow. Дерево исходных кодов
включает все основные библиотеки и функциональные модули, которые
работают интерфейсами коммутаторов OpenFlow. Также включено несколько
примеров контроллеров OpenFlow, разработанных с помощью Trema, а для
отладки имеется плагин для wireshark.
д) SNAC– контроллер OpenFlow, который использует веб-интерфейс
менеджера сетевой политики, чтобы управлять сетью [53]. Он включает гибкий
язык определения политики и удобный для пользователя интерфейс для
конфигурирования устройств и отслеживания событий. Он построен как
модуль NOX, однако требует определенную версию базового контроллера
NOX.
е) Helios– представляет собой расширяемый контроллер OpenFlow,
разработанный корпорацией NEC и рассчитанный на исследователей в области
ПКС. Он включает в себя специализированную программную оболочку,
позволяющую производить различные экспериментальные исследования.
ж) BigSwitch– контроллер OpenFlow с закрытым исходным кодом,
основанный на контроллере Beacon [54]. Контроллер BigSwitch использует
удобную в использовании консоль централизованного управления сетью, что
позволяет использовать контроллер в условиях развитой инфраструктуры
крупного предприятия.
61
Контроллер
Язык
разработки
Качество
документации
Открытость
исходного
кода
Многопоточность
NOX
C++/Python
Хорошее
Открытый
Поддерживается
Maestro
Java
Плохое
Открытый
Поддерживается
Beacon
Java
Хорошее
Открытый
Поддерживается
Trema
C/Ruby
Плохое
Открытый
Поддерживается
SNAC
C++/Python
Плохое
Закрытый
Нет поддержки
Helios
C
Хорошее
Закрытый
Нет поддержки
BigSwitch
Java
Хорошее
Закрытый
Нет поддержки
4.3 Проблема выбор сетевой операционной системы
Для выбора сетевой операционной системы необходимо сравнить
характеристики рассмотренных контроллеров OpenFlow. Выберем в качестве
критериев следующие характеристики: язык программирования для разработки
контроллера, наличие документации по использованию контроллера,
открытость исходного кода контроллера и возможность поддержки
многопоточности.
Значения критериев для семи рассмотренных контроллеров приведены в
таблице 4.1. Сравнительный анализ значения критериев показывает, что
наиболее удобными для исследования и использования сетевыми
операционными системами являются контроллеры NOX и Beacon, потому что
они имеют открытый исходный код и хорошо документированы.
Таблица 4.1 – Сравнение контроллеров OpenFlow
Закрытость исходного кода не позволяет вносить в контроллер какие-
либо изменения, что не соответствует поставленной задаче по дальнейшему
развитию сетевой операционной системы. В связи с этим контроллеры SNAC,
Helios и BigSwitch не могут быть использованы для дальнейшего развития.
Отсутствие хорошей документации по сетевой операционной системе не
позволяет эффективно расширять ее возможности, как следствие, контроллеры
Trema и Maestro, которые мало документированы, также необходимо
исключить из дальнейшего рассмотрения.
Для дальнейшего выбора сетевой операционной системы рассмотрим
результаты тестов производительности контроллеров Maestro, Beacon и NOX на
тестовом стенде, приведенные в работе [55]. Конфигурация включает в себя
два двухпроцессорных сервера (один для контроллера, другой для запуска
тестовых задач и перехвата пакетов) в следующей конфигурации:
процессоры Intel Xeon E5405, в каждом процессоре находится по 4
вычислительных ядра;
оперативная память– 4 гигабайта;
cетевые интерфейсы: 2 интерфейса со скоростью 1 гигабит/с;
операционная система: LinuxDebian Squeeze 32 бит;
62
версия интерпретатора Java: Sun Java 1.6.0_24.
Результаты сравнения контроллеров приведены на рисунке 4.3, взятом из
источника [55]. Обозначения: NOX – обычная версия контроллера NOX без
поддержки многопоточности, NOX_d – многопоточная и хорошо
оптимизированная версия контроллера NOX, maestro – контроллер maestro,
beacon – контроллер beacon.
Как видно из графика на рисунке 4.3 наибольшую пропускную
способность показал контроллер NOX.
На основании данных таблицы 4.1 и графика в соответствии с рисунком
4.3 имеет смысл использовать для исследования и расширения сетевую
операционную систему NOX в качестве контроллера OpenFlow, поскольку
контроллер NOX имеет открытый исходный код, написан на языке
программирования C++, хорошо документирован и показывает наиболее
высокую производительность в сравнении с другими контроллерами OpenFlow.
Рисунок 4.3 – Сравнение производительности контроллеров OpenFlow
Таким образом, в результате сравнительного анализа семи современных
сетевых операционных систем (контроллеров OpenFlow) для дальнейшего
исследования и расширения выбрана СОС NOX, демонстрирующая
значительные функциональные возможности, наивысшую производительность,
имеющая хорошую документацию, открытый исходный код.
63
При росте количества данных, обрабатываемых контроллером, возникает
значительное увеличение нагрузки на процессоры сервера. Распределение
нагрузки на несколько вычислительных ядер уже реализовано во всех
актуальных версиях контроллеров, однако этого может оказаться недостаточно
для большого количества одновременных запросов. Кроме того, при
реализации контроллеров не учитывается возможность существования
холодного резерва, и, как следствие, нет механизма репликации сведений о
существующих потоках и адресах.
Отсутствие репликации означает невозможность динамического
распределения нагрузки, переключения ресурсов на менее загруженные
контроллеры. При переключении вся информация теряется и, затем,
накапливается заново. Концепция кластерных служб, широко использующаяся
при создании масштабируемых приложений, подразумевает наличие единого
хранилища данных, системы локальных хранилищ, реплицирующихся с
главным хранилищем по требованию, системы диспетчеризации сообщений от
главной службы – распределителя нагрузки.
Рассмотрим хранилище данных более детально. Основное отличие
кластерного подхода – все данные хранятся в оперативной памяти, все действия
с данными выполняются в оперативной памяти. Управляющий узел сам
принимает решения о записи на жесткий диск изменений в БД. На всех узлах с
контроллерами запущены экземпляры сервера СУБД, настроенного на работу с
кластерным хранилищем. При этом сервер работает в режиме «ленивого»
чтения, то есть сохраняет на какое-либо время использованные данные на
стороне клиента.
Сетевое хранилище БД имеет автоматически-резервируемую структуру
хранения данных, серверы СУБД логически соединены с каждым узлом
кластерного хранилища данных. В случае отказа одного из узлов хранилища
выполнение транзакций продолжается на другом узле. Все узлы, используемые
для хранения данных, могут быть продублированы. В случае отказа одного из
узлов всегда есть еще один узел с теми же данными. Управляющий узел также
может быть продублирован. Отказ управляющего узла (даже если он один)
никак не влияет на работу остальных узлов такого кластера. В случае если
обнаружен отказ одного из узлов(недоступность его по сети, отказ жесткого
диска), он автоматически помечается как недоступный, и все остальные узлы
кластера оповещаются об этом.
Для обеспечения целостности данных используется непрерывное ведение
протокола всех выполненных транзакций и локальные контрольные точки. По
мере достижения определенного количества проведенных транзакций все
данные сохраняются на жесткий диск, и файл протокола очищается.
Распределитель нагрузки имеет холодный резерв, который активируется
компонентом наблюдения. При активации резервного распределителя нагрузки
мастер-служба СУБД на резервном узле подключается к СУБД и активирует
все соединения с узлами хранилищами БД. Все коммутаторы с поддержкой
OpenFlow имеют возможность настроить до трех адресов контроллера для
64
резервирования, первый адрес настраивается на интерфейс узла с основным
распределителем нагрузки, второй адрес должен быть настроен на интерфейс
узла с резервным распределителем нагрузки.
4.4 Расширение функциональных характеристик за счет
интеграции СОС с облачными сервисами
В настоящее время все облачные сервисы используют альтернативные
реализации виртуальной сети между экземплярами виртуальных машин внутри
группы. ДляVMwareVCloud, XenCloudPlatform – этоOpenVSwitch,
дляOpenStack – Quantum, дляRedHatEnterpriseLinux – LinuxBridge.
Архитектуры CiscoBlade, SunBlade проводят перенос коммутации в
физические управляемые коммутаторы вместо виртуальных. Наиболее
универсальным решением является использование OpenVSwitch как полностью
управляемого, независимого коммутатора с поддержкой OpenFlow.
OpenVSwitch имеет программные дополнения, добавляющие совместимость со
всеми популярными платформами для коммутации в облачных структурах.
Поддержка OpenFlow позволяет интегрировать любую промышленную
облачную систему с существующей программно-конфигурируемой сетью.
Рассмотрим самую распространенную платформу с открытым исходным
кодом для облачных систем OpenStack. Для создания виртуальных подсетей для
групп виртуальных машин используется программная система Quantum, в
которой кроме сетевых функций, реализованных на базе LinuxBridge, есть
функции, отвечающие за взаимодействие с контроллером OpenStack,
гипервизорами виртуальных машин, контроллерами вычислительных узлов
nova-compute, контроллерами узлов хранения данных glance и swift. Поэтому
полностью заменить систему Quantumна другую представляется
нецелесообразным. Однако существует решение для замены LinuxBridge на
OpenVSwitch, позволяющее расширить функционал и создать единую сеть под
единым управлением из физических и виртуальных коммутаторов. В
соответствии с рисунком 4.5 виртуальный коммутатор независим от остальных
компонентов.
65
Сервер
Quantum
СУБД
Сервер DHCP
Виртуальная
машина
Виртуальный
интерфейс
Виртуальный
коммутатор
Преобразователь
трафика
Linux Bridge
Физический
интерфейс
Клиент
Quantum
Локальная сеть
ЦОД
Контроллер
облачной
системы
OpenStack
Внешние сети
Вычислительный узел
Рисунок 4.5 – Структурная схема модулей, входящих в архитектуру Quantum
источника до приемника. В облачных системах могут существовать подсети
разных пользователей с одинаковыми адресами, поэтому передача трафика
между узлами без создания виртуального туннеля невозможна. Для этого
можно использовать преобразователь трафика LinuxBridge. При использовании
OpenFlow в виртуальном коммутаторе Quantum пропадает необходимость
выполнять какие либо преобразования трафика, за исключением случаев
коммутации с другим ЦОД при распределенной архитектуре. При этом
контроллер OpenFlow управляет трафиком непосредственно от источника до
приемника на всем протяжении пути, что позволит обеспечить требуемые
параметры качества обслуживания и производительности.
сетях возможности. В этом случае соответствующие сетевые службы
отделяются от физической сетевой инфраструктуры. Данный подход
реализуется с помощью управляемых коммутаторов, функциональность
которых позволяет поддерживать виртуальные локальные сети (Virtual Local
Area Network, VLAN). В области беспроводных локальных сетей тоже имеются
возможности для виртуализации типа Multi-SSID (несколько идентификаторов
беспроводной сети на одной точке доступа).
глобальную сеть, охватывать маршрутизаторы Интернет. Основное
преимущество виртуализации сетей заключается в возможности многократного
использования физической сетевой инфраструктуры. На основе физической
сети создается несколько логических сетей, которые используют общую
аппаратную инфраструктуру, но в остальном они почти полностью
изолированы.
Основная задача виртуального коммутатора – передать трафик от
4.5 Виртуализация сетей передачи данных
Виртуализированные сети открывают новые, недоступные в обычных
При виртуализации сетей виртуализация может распространяться и на
66
Виртуализация сетей реализуется с применением двух различных
методов. В случае VLAN и Multi-SSID виртуализации подвергается среда
передачи (канальный уровень), которая преобразуется в многократно
используемую среду. Беспроводная точка доступа с несколькими логическими
сетями создаетодновременноработающие изолированные зоны.Эти технологии
реализуются на канальном уровнемодели OSI. Такой вид виртуализации
ограничивается локальной сетью предприятия.
Взаимодействие на базе IP все чаще выходит за границы одной локальной
сети, и перемещается в глобальную сеть. В этих условиях виртуализации
VLAN и Multi-SSID оказывается недостаточно.
Следующий шаг в развитии виртуализации сетей — виртуализация на
третьем уровне, отделение данных от физической среды передачи данных:
создание IP сетей и маршрутизация пакетов данных между этими сетями IP.
При этом используется маршрутизатор, позволяющий создать множество
виртуальных маршрутизаторов. Каждый виртуальныймаршрутизатор может
настраиваться только для своей сети. Следующий уровень виртуализации
предполагаетодновременно реализовать разные приложения с собственными
настройками для маршрутизации и качества обслуживания.
Наибольшее распространение виртуализация сетей получила при
виртуализации ресурсов. Гипервизор может создать один или несколько
виртуальных сетевых адаптеров для каждой виртуальной машины. Эти
адаптеры будут видны в виртуальной машине как физические, но в
действительности они только предоставляют интерфейс к реально
существующему сетевому адаптеру. Гипервизор также позволяет динамически
создать виртуальную сеть с виртуальными коммутаторами, чтобы обеспечить
настраиваемую связь между конечными точками виртуальных машин.
Виртуальный коммутатор – это ключевой компонент, необходимый для
виртуализации сетевой инфраструктуры. Виртуальный коммутатор соединяет
виртуальные сетевые адаптеры с физическими сетевыми адаптерами,
установленными на сервере, и, что более важно, связывает одни виртуальные
сетевые адаптеры с другими для локального взаимодействия в рамках сервера.
Новый класс коммутаторов называется распределенным виртуальным
коммутатором (distributed virtual switch) и применяется для соединения
серверов таким способом, чтобы аппаратная архитектура стала прозрачной для
использующих её приложений. Виртуальный коммутатор на одном сервере
может прозрачно для пользователей подключиться к виртуальному
коммутатору на другом сервере.
Один из наиболее важных проектов в этой области – проект OpenVSwitch,
реализующий виртуальную коммутацию на базе протокола OpenFlow.
OpenVSwitch – это многоуровневый виртуальный коммутатор с открытым
исходным кодом. OpenVSwitch поддерживает наиболее популярные
гипервизоры, включая KVM, VirtualBox, Xen и XenServer. OpenvSwitch состоит
из службы-коммутатора и сопутствующего модуля ядра, который управляет
процессом поточной (flowbased) коммутации.
Другая технология используется в гипервизоре VMWareESXi – VXLAN
67
(Virtual eXtensible LAN), которая предоставляет расширенный механизм
создания виртуальных сетей VLAN в крупных ИТ-инфраструктурах,
объединяющих несколько ЦОД. VXLAN – это замена VLAN для создания
прозрачной мобильной сетевой среды для виртуальных машин, имеющих
возможность перемещаться между ЦОД. Стандартная концепция VLAN
позволяет использовать только до 4096 виртуальных сетей для логической
изоляции классов систем, что в крупных инфраструктурах иногда оказывается
недостаточно. Технология VXLAN – это способ создания новых логических
сетей в рамках уже существующих IP-сетей. В одной VXLAN-сети виртуальная
машина уникально идентифицируется двумя следующими параметрами:
а) VXLANNetworkIdentifier (VNI) – 24-битный идентификатор
виртуальной сети;
б) MAC-адрес машины.
Соответственно, в одной VXLAN-сети не может быть машин с
одинаковым MAC-адресом, но в разных VXLAN-сетях они могут существовать.
Реализована технология в программных коммутаторах vSwitch, работающих на
уровне ядра ОС, а также в распределенном коммутаторе VMware Distributed
Switch, который объединяет несколько коммутаторов vSwitch в целях
обеспечения централизованного управления сетевой инфраструктурой.
Виртуализация сети становится все более значимой и постоянно
развивается, как и другие формы виртуализации. Стоимость развертывания
экспериментальных топологий сетей, строгие требования изоляции трафика
предприятия, а также увеличивающиеся требования вычислительной мощности
для виртуальных серверов делают виртуализацию ключевым фактором, как в
секторе исследований, так и в индустрии (корпоративных сетях и центрах
обработки данных). Однако при виртуализации центров обработки данных
возникает проблема виртуализации и сетевых потоков для динамического
изменения конфигурации сети, которая может быть решена за счет
использования динамической настройки OpenFlow оборудования.
4.6 Управление сетевыми ресурсами и потоками данных в ПКС с
помощью сетевой операционной системы
Производительность СОС измеряется как количество обслуженных
запросов типа «PacketIn» в единицу времени. Кроме того, в каждой СОС
существует ограничение на максимальное число коммутаторов, подключенных
к одному экземпляру приложения. Схема тестирования производительности
зависит от режима измерений. Для тестирования применяется программа
«cbench» [54], которая эмулирует некоторое количество коммутаторов. При
тестировании полезной производительности после посылки каждого события
«PacketIn» виртуальный коммутатор ожидает ответа и после этого повторяет
запрос. При тестировании полной производительности коммутатор не ожидает
ответа, а сразу же посылает новое событие. Алгоритм работы показан нас
рисунке4.6.
68
Начало
Ввод
параметро
в
i=1
Exp_no=1
Установка
сессии с
контролле
ром
i<=N
i=i+1;
TimeBegin=Now
Параметры:
а) L – размер серии экспериментов;
б) M – время одного эксперимента;
в) N – количество эмулируемых коммутаторов;
г) T=1 – установить режим тестирования максимальной
производительносии, иначе режим полезной
произвоительности;
д) L=1 - эмулировать ответы ARP, иначе не эмулировать.
Установка
времени
начала
эксперимента
Установка номера
эксперимента
А
Послать и принять событие «PacketIn» может только виртуальный
коммутатор, эмулируемый программой cbench. Но все остальные действия
должен выполнять командный интерпретатор с соответствующим логики
измерения исполняемым кодом.
Рисунок 4.6 – Алгоритм тестирования производительности контроллера
69
Sw_no=1
Sw_no>N
Если номер коммутатора
превысил максимальное
значение
Посылка
PacketIn
коммутато
ром Sw_no
Буфер не заполнен
Прием
ответа
коммутатор
ом Sw_no
PktIn_cnt[Sw_no]=1
Количество принятых ответов
от контроллера
T==1
Ответ принят?
PktIn_cnt[Sw_no]+=1
Now-TimeBegin>M
Если время эксперимента
превысило заданное
значение
Нет
Да
Нет
Да
Да
Нет
Sw_no+=1
Now-TimeBegin>M
Если время эксперимента
превысило заданное значение
Да
Нет
Нет
Да
Exp_no>L
Если количество
экспериментов в серии
превысило заданное
значение
Exp_no+=1
Номер коммутатора
Следующий коммутатор
Счетчик ответов
от коммутатора
Sw_no
PktIn_cnt
Вывод вектора результатов
эксперимента
Конец
Нет
Да
А
Продолжение рисунка 4.6
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]