Open Flow SDN – взгляд изнутри на одном примере.
Хочу поделиться опытом близкого знакомства с оборудованием OpenFlow для построения SDN сетей. Так как у каждого производителя, а может и у каждого потребителя, есть своё представление о SDN, а отношение к Open Flow тоже варьируется от скептически-презрительного до оптимистически-восторженного, то сразу пропущу всю лирику и перейду к описанию простейшего эксперимента.
Итак у нас есть SDN сеть, построенная на OpenFlow коммутаторах (OFS) и управляемая OpenFlow контроллером (OFC) (Рис.1).
Вся настройка коммутаторов заключается в их переключении в режим OFS и указанию IP адреса контроллера. Соединяем коммутаторы патчкордами в соответствие с нашими пожеланиями, подключаемся к контроллеру, проверяем доступность и связность коммутаторов, составляющих нашу сеть, и приступаем к решению задачи. В качестве задачи попробуем создать сетевую инфраструктуру, которая могла бы обеспечить живую миграцию виртуальных машин (VM).
Естественно я заранее подготовил пару серверов с развёрнутыми VM и ПК (WAN PC), с помощью которого будем проверять доступность VM во время процесса миграции. Кроме этого для обеспечения VM Live Migration мы должны обеспечить наличие vmkernel канала между ESXi машинами, развёрнутыми на разных серверах.
Так как используемый контроллер Open Flow поддерживает виртуализацию сетей (NFV), создаём 2 независимые сети (Рис.1):
— Виртуальная сеть (VTN1) для организации vmkernel канала между ESXi#1 и ESXi#2
— Виртуальная сеть (VTN2) для рабочих VM и WAN интерфейса
Заодно проверим возможность объединения различных VLAN в рамках одной VTN, поместив наши ESXi и VM в различные VLAN.
Рис.1 Конфигурация физической и логических сетей
В данном эксперименте намеренно не используется какое-либо ПО для синхронизации сетевой и ИТ подсистем, то есть наша SDN должна автономно реагировать на перемещение VM.
Контроллер позволяет создавать VTN либо в графическом интерфейсе, либо в специальной программной оболочке. Процесс создания VTN ближе к программированию, чем к сетевому администрированию. Например VTN1 описывается следующим программным кодом:
vtn VTN1 {
vbridge VBR1 {
vlan-map ofs-datapath-id 0000-0000-0000-0003 vlan-id 251
vlan-map vlan-id 251
interface VIF_VEX1 }
vexternal VEX1 {
ofs-map ofs-datapath-id 0000-0000-0000-0004 ofs-port GBE0/15 vlan-id 252
interface VIF }
vlink VLINK_VBR1_VEX1 {
vtn link vbridge VBR1 interface VIF_VEX1 vtnnode VEX1 interface VIF }
}
Для мониторинга непрерывности доступа к мигрируемой VM мы организуем ‘ping’ посылки с физического хоста, эмитирующего подключение со стороны WAN.
OFC поддерживает функцию визуализации, что позволяет нам увидеть не только физическую топологию и созданные нами логические сети, но и активные потоки трафика:
— ‘ping’, посылаемый на VM 10.10.10.86
— и ответ ‘ping’возвращаемый на WAN PC 192.168.11.11
Выбрав из списка один flow мы можем увидеть его маршрут в логической и физической сети. По каждому потоку нам доступна полная информация L1-L4.
С точки зрения данного эксперимента нам наиболее интересны MAC и IP адреса, а также VLAN тэг.
И так мы переходим в консоль VMware и запускаем миграцию.
Как видно из скриншотов VM Win1 мигрировала с ESX#2 на ESX#1, а наша SDN автоматически перестроила маршрутизацию трафика. На следующем рисунке мы видим обновленный экран визуализации.
Обратите внимание, что MAC и IP адреса не изменились, а VLAN тэг изменился с 254, на 253, который тоже разрешён для VTN2.
На данном эксперименте мы убедились, что хост (в данном случае VM) не меняя своего IP и MAC адреса может свободно перемещаться в рамках OpenFlow SDN сети в соответствии с правилами на соответствие логической сети (VTN), к которой он принадлежит. При этом SDN сеть обеспечивает оптимальную маршрутизацию трафика и соблюдение требуемых политик в физической сети, куда бы мы ни переместили наш хост.
На примере 'ping' посылок можно заметить кратковременную недоступность мигрируемого ресурса, которая на самом деле является не критичной для множества реальных приложений.
PS: Конечно это простейший эксперимент, не затрагивающий как функциональные возможности SDN, связанные с балансировкой, фильтрацией, редиректом трафика и управлением политикам; так и вопросы масштабируемости, интеграции с существующими IP сетями, обеспечением надёжности, безопасности и т.д. Но на мой взгляд этот пример наглядно демонстрирует, что сети OpenFlow являются наиболее простым и, возможно, самым совершенным инструментом в нашем динамичном мире.
В следующих статьях я надеюсь на примерах разобраться остальные вопросы и буду признателен, если в комментариях вы предложите сценарии для дальнейших экспериментов.
Для постановки эксперимента использовались:
OpenFlow контроллер: NEC PF6800
OpenFlow коммутаторы: NEC PF5240, PF5248
Документация: PFC configuration_guide_V5