Программно определяемые сети (Software Defined Networks): настоящее и будущее

Как сказал однажды известный писатель, «…когда-то и электрическую лампочку считали чудом, а за обычные очки на носу могли запросто cжечь на костре…». Человечество во многом инертно и консервативно в своих взглядах. Люди не сразу воспринимает новое, как известно, первые два производителя молний для одежды разорились. И привычные сейчас вещи иногда проходят несколько витков по спирали прежде, чем превращаются в обычную для нас часть быта. То же самое можно сказать и про технологии.

Поговорим про модную сегодня тему, про так называемые, программно определяемые сети (Software Defined Networks, SDN), которая, как мне кажется, уже прошла все предварительные стадии и готова в ближайшем будущем превратиться в настоящий main stream развития сетей. Начну с нескольких тезисов в качестве короткой вводной:

1. «Все новости – это, обычно, хорошо известные вещи, только каждый раз происходящие с новыми людьми»: сама идея централизации интеллекта сети не новая и сети отчасти уже проходили по этому пути. Можно вспомнить, как был устроен в своем детстве Инет, как работали первые gateway-to-gateway протоколы, что были (да и сейчас, наверняка, где-то еще есть) в сетях хабы, которые работали через мосты, фактически аккумулирующие интеллект, вспомнить также про системы Configuration Automation & Provisioning. Примеров много. Но — концепция SDN уникальна тем, что основная ее идея не просто централизовать интеллект сети на выделенном устройстве – контроллере, а управлять напрямую плоскостью передачи данных (data plane) из единого, общего для всей сети, центра на базе специальных протоколов. Фактически, это означает вынос контрольной плоскости (control plane) всей сети на централизованную, внешнюю аппаратную базу, а не обычное разделение contol/data plane по процессам, ASIC-ам или печатным платам внутри одного устройства, с удаленным управлением через стандартные интерфейсы, типа CLI/SNMP.
2. «Первое, что делает любой диктатор – упрощает все понятия»: и в этом плане идеология SDN, с точки зрения сетевых устройств, вполне «диктаторская». «Думают» за коммутаторы и решают какие пакеты куда передавать SDN-контроллеры. Коммутатору отводится роль простого исполнителя. Решением сложных сетевых задач (типа защиты от петель или обеспечения безопасности) занимаются специализированные приложения в централизованной контрольной плоскости на контроллерах.
3. «Все слабые люди склонны думать, что было бы здорово, если бы ими никто не управлял; при этом, они не отдают себе отчета, что сами они не могут управлять ни собой, ни другими..»: идеология SDN позволяет упростить сами сетевые устройства до предела (фактически, до поддержки протокола управления для связи с контроллером и базовых функций коммутации), сделать их слабыми, а значит и дешевыми. Это, в конечном итоге, может кардинально снизить OPEX, который не дает спокойно спать всем держателям IT бюджетов.
4. «Чтобы распустить флаг, нужно пойти против ветра»: компания HP была пионером в разработке SDN технологий и одной из первых вышла на рынок с работающим решением (про него чуть ниже). Когда никакого OpenFlow еще не было и сетевая индустрия держала в фокусе другие технологии, HP уже участвовал в разработке предшественника OpenFlow (Ethane, в 2007 году), а затем стал одним из активных участников OpenFlow Network Foundation (ONF) и в, 2011 году, InCENTRE (Центр по тестированию OpenFlow).

Подытожим: SDN – это идеология построения сетей, в которой весь интеллект сети вынесен на отдельную аппаратную/программную базу, а все управление трафиком происходит на основе специальных протоколов (например, OpenFlow), которые оперируют понятием «поток» (flow) и могут совершать различные действия с ним (разрешить, запретить, перенаправить, переписать поля в пакетах и т.д.). Фактически, на контроллере определяется политика управления сетью на основе заданных правил, а также работы специализированных приложений (например, эмулирующих работу STP или протоколов маршрутизации). Затем конечный результат передается на коммутаторы по протоколу OpenFlow в виде flow-таблиц, содержащих информацию о том, куда, как и какой трафик передавать. С одной стороны, такой подход дает большую гибкость в управлении сетью, с другой — существенно упрощает администрирование (и, отчасти, архитектуру) сети.
Отдельная тема – это построение системы сетевой безопасности на базе OpenFlow. Контроллер фактически централизует эту функцию тоже (в виде специализированного приложения) и, потенциально, забирает на себя весь интеллект firewall-ов, IPS-ов и других традиционных систем сетевой защиты.

HP одним из первых выпустил коммерческий продукт, поддерживающий протокол OpenFlow. При этом, коммутаторы НР, поддерживающие OpenFlow, гибридные, т.е. поддерживают работу одновременно в двух режимах – OpenFlow плюс традиционная коммутация. Рассмотрим простой пример, где есть три коммутатора HP серии 3800, объединенные в кольцо. Вот так:

В качестве контроллеров собраны несколько вариантов – Floodlight, SNAC и NOX. В этом примере на коммутаторах настроены два контроллера – SNAC и Floodlight, вот так:

openflow
   enable
   controller-id 1 ip 192.168.2.10 controller-interface oobm
   controller-id 2 ip 192.168.2.11 controller-interface oobm

В OpenFlow настроены два instance-а, каждый из которых связан с отдельным контроллером, который управляет трафиком в отдельном VLAN-е. В этом примере контроллер SNAC настроен на управление трафиком в VLAN 3, контроллер Floodlight настроен на управление трафиком в VLAN 4, вот так:

instance "snac"
      member vlan 3
      controller-id 1
      limit software-rate 10000
      connection-interruption-mode fail-standalone
      max-backoff-interval 10
      enable
      exit
   instance "floodlight"
      member vlan 4
      controller-id 2
      limit software-rate 10000
      connection-interruption-mode fail-standalone
      enable
      exit
   hardware-statistics refresh-rate 10

В управляемые через OpenFlow VLAN-ы заведены определенные порты, вот так:

vlan 3
   name "SNAC"
   untagged 1/3,1/13
   tagged 1/1,1/23-1/24
   no ip address
   exit
vlan 4
   name "FLOODLIGHT"
   untagged 1/4,1/14
   tagged 1/1,1/23-1/24
   no ip address
   exit

И, собственно, на этом настройка OpenFlow на коммутаторах закончена. Дальше мы видим, что контроллер определил коммутаторы и можем их зарегистрировать, вот так это выглядит в вэб-интерфейсе SNAC-а:

Затем, как только появляется реальный трафик на портах, управляемых через OpenFlow, контроллер увидит источники, с которых идет трафик:

И, на основе сделанных настроек, отдаст в коммутатор информацию о потоках трафика, которые коммутатор должен обрабатывать. Отданные на коммутатор потоки (flow)в CLI коммутатора можно посмотреть вот так:

Дальше, к трафику можно применять разнообразные правила. Вот так, например, в контроллере SNAC выглядит закладка, где можно применять политики доступа по разным параметрам (src/dst MAC, src/dst IP, TCP порты, и т.д):

Можно посмотреть топологию сети, в Floodlight она выглядит вот так:

Можно посмотреть разную статистику по потокам, историю происходивших событий (кто регистрировался в сети и т.д.), в SNAC эта закладка выглядит так: