Citrix Distributed vSwitch controller. Концепция SDN

Статья опубликована в журнале «Системный Администратор»

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

Содержание

Немного про OpenFlow
Как это работает в OVS
Развертывание контроллера
Просмотр статистики
Qos и RSPAN
Описание потоков OpenFlow
Вывод
Ссылки

Немного про OpenFlow

Проект OpenFlow[2] стартовал в 2008 году в стенах Стэнфордcкого и Калифорнийского (Беркли) университетов в рамках зародившейся немногим ранее (2002 г.) концепции SDN (Software-defined networks) – программно-конфигурируемых сетей [1]. Основными идеями концепции являются простота, гибкость, унификация и дешевизна конечных решений. Архитектуру 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). К сожалению, Использование же сторонних, открытых реализаций контроллера [3], наиболее известные из которых NOX, FloodLight и Beacon, подразумевает программирование различных модулей и классов, описывающих желаемую функциональность.
По большому счету, OVS в составе XenServer и контроллер для него в исполнении Citrix — это наиболее полная и функциональная реализация концепции SDN.
Развертывание контроллера состоит из одного простого действия — импорта ВМ[4](в формате xva) на один из серверов XenServer. Для входа в локальную консоль ВМ используется логин admin и такой же пароль.
После успешного импорта и запуска ВМ необходимо сконфигурировать сетевой интерфейс управления. Чтобы задать статический ip-адрес используется следующая команда:

# set controller management-interface config static <IP-address> <netmask> <gateway-IP> [<dns-server-IP> <dns-server-IP2> <dns-search>]

Параметры, указанные в квадратных скобках, не обязательны.

Теерь когда сетевой интерфейс ВМ сконфигурирован можно заходить браузером в веб-консоль управления DVSC по адресу указанному в команде выше.
Используя те же учетные данные что при входе в локальную консоль, мы попадаем на страницу с общей информацией (Status). Здесь же, необходимо добавить пул ресурсов.
Пул ресурсов, в терминологии Citrix — это кластер серверов XenServer с одним или несколькими общими сетевыми хранилищами. При добавлении пула ресурсов в DVSC, указывается адрес или сетевое имя мастера пула и учетные данные для подключения.
Когда пул добавлен, коммутаторы на каждом из узлов XenServer автоматически переходят под управление контроллера DVSC. Это можно увидеть выполнив на любом из узлов XenServer следующую команду:

# ovs-vsctl show

987c42d0-eab0-43d9-a32b-4246973706c2
Bridge «xenbr0»
Controller «ssl:192.168.0.61:6633»
fail_mode: secure
…(вывод сокращен)

На текущий момент, DVSC от Citrix поддерживает не всю функциональность OVS. Точнее не все реализуется из веб-консоли. Например, создать GRE-туннель между несколькими ВМ на разных узлах возможно только из командной строки. Сейчас, в графическом режиме доступны просмотр сетевой статистики по различным фильтрам, ограничение пропускной способности, а также зеркалирование трафика. Но самое главная возможность, которая, пожалуй, позволяет реализовать любые фантазии — это удобное описание потоков OpenFlow по принципу, очень напоминающему создание правил межсетевого экрана. Впрочем, давайте обо всем по порядку.

Просмотр статистики

Вкладка Flow Statistics всецело посвящена просмотру статистики, отображение которой реализовано в виде графиков. Все параметры, доступные при выводе статистики, можно увидеть на рисунке №1. Хочется отметить, что за счет централизованного сбора статистики со всех коммутаторов, получается достаточно детализированная картина по движению трафика в виртуальной инфраструктуре. Из недостатков, пожалуй, отмечу лишь то, что данные по статистике доступны только в реальном времени. То есть максимальный период отображения — это один час, «история» отсутствует.
Рис. №1. Параметры отображения статистики

Qos и RSPAN

На вкладке Port Configuration, предоставляется возможность ограничить ширину канала конкретной ВМ или ее отдельного виртуального интерфейса. Так же можно настроить зеркалирование трафика по протоколу RSPAN отдельного интерфейса, ВМ или трафик всего пула в конкретный VLAN.

Описание потоков OpenFlow

Это пожалуй самая главная и интересная пункт из возможностей DVSC.
На вкладке Access Control можно гибко описывать различные правила фильтрации трафика. Как и в случае с QoS и RSPAN, здесь действует та же система иерархии правил. То есть, существуют глобальные правила (Global Policy) действие которых применимо ко всем виртуальным машинам на любых хостах во всех управляемых ресурсных пулах. Данные правила обычно общего характера. Например, тут по умолчанию описаны правила, разрешающие передачу трафика DNS и DHCP.
Ниже следуют правила налагаемые на конкретный пул ресурсов (Policy for pool). Здесь могут быть учтены особенности пула и заданны особые правила или переопределены глобальные.
Следующий уровень иерархии — это правила для конкретного физического интерфейса (Policy for Network). Данные правила применяются ко всем ВМ, работающим через указанный интерфейс. Ну и на самом низком уровне, они могут быть заданны для конкретной ВМ (Policy for VM) или для ее отдельного интерфейса.
Как выглядят составленные правила и параметры, из которых они состоят, можно увидеть на рисунке №2. А в каком виде они хранятся в OVSDB конкретного коммутатора можем посмотреть следующим образом:

# ovs-ofctl dump-flows xenbr0

NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=59.673s, table=0, n_packets=0, n_bytes=0, priority=40000,ip,in_port=1,nw_dst=224.0.0.0/24 actions=drop
cookie=0x0, duration=2275.395s, table=0, n_packets=0, n_bytes=0,
icmp actions=drop
cookie=0x0, duration=390.313s, table=0, n_packets=0, n_bytes=0, priority=65529,tcp,in_port=3,dl_src=1e:98:e9:bf:4d:67,nw_src=192.168.0.61,tp_dst=23 actions=drop

Утилита ovs-ofctl предназначена для управления OpenFlow-потоками OVS. С помощью нее можно описать любое правило.
Например, запретить ICMP на конкретном коммутаторе:

# sudo ovs-ofctl add-flow xenbr0 idle_timeout=0,icmp,action=drop

здесь idle_timeout=0 означает, что это правило постоянное. Если нужно временное правило, то можно указать количество секунд.
А вот более сложное правило, запрещающее весь трафик из конкретного порта в ip-подсеть:

# ovs-ofctl add-flow xenbr0 «in_port=1 ip idle_timeout=0 nw_dst=192.168.14.0/24 priority=40000 action=drop»

in_port=1, это номер порта источника в коммутаторе. Узнать какие интерфейсы включены в какие порты можно следующей командой:

# ovs-dpctl show xenbr0

system@xenbr0:
lookups: hit:0 missed:0 lost:0 flows: 0
port 0: xenbr0 (internal)
port 1: vnet1 (internal)

Примерно таким же образом работает и DVSC. Только при создании правил, особенно в случае глобальных, ovs-ofctl выполняется на нескольких узлах с различными параметрами. Но самая главная роль DVSC — отслеживать миграцию ВМ, изменение сетевой конфигурации и динамически переопределять OpenFlow потоки на коммутаторах.
Здесь, можно заметить, что OVS кроме коммутации трафика фактически выполняет и функции межсетевого экрана. Слияние этих двух ролей в одном решении, думаю можно объяснить тем, что контроль трафика в виртуальной среде, в частности между ВМ, невозможно осуществить средствами классических межсетевых экранов. По этому, функции фильтрации трафика, вполне логично возлагаются на виртуальные коммутаторы.
Рис. №2. Иерархия правил и их параметры

Вывод

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