Теория и практика Open vSwitch. Часть 2. Протокол OpenFlow::Журнал СА 11.2013
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1826
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1887
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1446
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1066
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1636
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Теория и практика Open vSwitch. Часть 2. Протокол OpenFlow

Архив номеров / 2013 / Выпуск №11 (132) / Теория и практика Open vSwitch. Часть 2. Протокол OpenFlow

Рубрика: Администрирование /  Сети

Александр Руденко АЛЕКСАНДР РУДЕНКО, администратор информационной безопасности в ЗАО «Молдавская ГРЭС», a.rudikk@gmail.com

Теория и практика Open vSwitch
Часть 2. Протокол OpenFlow

Рассмотрим возможности OpenFlow-контроллера для Open vSwitch, а также поговорим о проблемах развития концепции SDN

В первой части статьи, посвященной Open vSwitch (OVS) [1], были рассмотрены основные возможности программного коммутатора, а также некоторые особенности его настройки и функционирования. Так как данная тематика достаточно обширна, была освещена лишь работа с «отдельно стоящим» коммутатором. Но сегодня, когда виртуальные инфраструктуры могут насчитывать десятки и сотни узлов, а соответственно и коммутаторов, необходим механизм, позволяющий гибко управлять множеством хостов и учитывать динамичность виртуальной среды, избавляющий от ручной настройки каждого узла. Таким средством является протокол OpenFlow, о котором и пойдет речь в данной статье.

Немного про OpenFlow

Проект OpenFlow [2] стартовал в 2008 году в стенах Стэнфордcкого и Калифорнийского (Беркли) университетов в рамках зародившейся немногим ранее (2002-й) концепции SDN (Software-defined networks) – программно-конфигурируемых сетей [3]. Основные идеи концепции – простота, гибкость, унификация и дешевизна конечных решений. Архитектуру SDN можно представить как множество достаточно простых программных и аппаратных коммутаторов, подключенных к единому мощному интеллектуальному контроллеру, реализованному в виде обычного сервера со специальным ПО. В данной схеме коммутаторы должны уметь лишь быстро переадресовывать трафик и больше ничего.

Вся интеллектуальная логика и высокоуровневая маршрутизация ложатся на плечи контроллера. За счет переноса интеллекта на центральный узел коммутаторы разгружаются и могут более эффективно использовать вычислительные мощности для выполнения низкоуровневых операций с трафиком. Также централизованное управление позволяет мониторить состояние всей сети и управлять множеством ее параметров из одной точки. Но самой главной идеей данной архитектуры является возможность программно управлять трафиком в такой сети. Иными словами, контроллер – это не просто ПО, способное отправлять определенный набор команд на подчиненные коммутаторы. Это своего рода фреймворк и API, позволяющие управлять потоками трафика из различных (зависит от контроллера) языков программирования. Это дает возможность строить сети любой топологии, непохожие друг на друга, и описывать различное поведение коммутаторов для тех или иных случаев.

Причем же тут OpenFlow? OpenFlow – это стандартизированный открытый протокол (распространенные версии – 1.1, 1.3), по которому происходит взаимодействие контроллера с подчиненными коммутаторами. Контроллер OpenFlow вносит изменения в таблицы потоков коммутаторов, на основании которых принимается решение о передаче принятого пакета на конкретный порт коммутатора.

К сожалению, концепция SDN развивается не так, как предполагалось. Хотя программно реализованных контроллеров достаточно на любой вкус, оборудования с поддержкой OpenFlow не так много, как хотелось бы. Например, продукты, выпускаемые Cisco Systems и Juniper Networks, проприетарны и несовместимы с прочими производителями. Поэтому, наверное, единственная область, в которой SDN развиты наиболее хорошо, – это виртуализация, и Open vSwitch – хороший тому пример. Он полностью соответствует SDN и использует открытую реализацию OpenFlow.

Как это работает в OVS

Архитектура OVS достаточно проста и прозрачна. Основными компонентами являются модуль ядра, OVSDB-база данных с конфигурацией (в формате json) и служба, отслеживающая и применяющая все вносимые в БД изменения. В случае с множеством узлов каждый из коммутаторов является отдельной сущностью, никак не связанной с другими такими же. Для централизованного управления несколькими коммутаторами в OVS реализована поддержка протокола OpenFlow, посредством которого контроллер вносит изменения в таблицы потоков коммутатора, тем самым управляя движением трафика.

Развертывание контроллера

Нормально реализованного контроллера для управления несколькими экземплярами OVS, готового к использованию без какого-либо программирования, пока не существует.

Для иллюстрации работы распределенного коммутатора на базе OVS будут использоваться несколько серверов XenServer 6.2 и реализация OpenFlow-контроллера от Citrix – Distributed Virtual Switch Controller (DVSC). Здесь надо сказать, что текущие свободные версии Open vSwitch, кроме непосредственно коммутатора, включают в себя и реализацию примитивного OpenFlow-контроллера. К сожалению, его возможности крайне ограничены. С его помощью можно управлять группой удаленных OVS, но их функциональность будет как у коммутаторов второго уровня (L2). К сожалению, использование же сторонних, открытых реализаций контроллера [4], наиболее известные из которых NOX, FloodLight и Beacon, подразумевает программирование различных модулей и классов, описывающих желаемую функциональность.

По большому счету OVS в составе XenServer и контроллер для него в исполнении Citrix – это наиболее полная и функциональная реализация концепции SDN.

Развертывание контроллера состоит из одного простого действия – импорта ВМ [5] (в формате xva) на один из серверов XenServer. Для входа в локальную консоль ВМ используется логин admin и такой же пароль.

Статью целиком читайте в журнале «Системный администратор», №11 за 2013 г. на страницах 26-28.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru