Компьютерные сети
SDN: программируемые сети
Google перешёл на SDN в 2012 году и увеличил утилизацию сети с 30% до 95%. Как управлять сетью из 100000 серверов без армии сетевых инженеров? Ответ - программировать её как софт.
- **Google B4** - WAN между датацентрами полностью на SDN. Централизованный traffic engineering позволяет использовать каналы на 90%+ (vs 30-40% в традиционных сетях).
- **Facebook** использует OpenR (собственный SDN) для управления backbone сетью. Изменения политик применяются за секунды, не часы.
- **Azure/AWS VPC** - виртуальные сети в облаке это SDN. Каждый tenant изолирован, firewall rules применяются программно на hypervisor'ах.
Предварительные знания
SDN Architecture
**Software-Defined Networking (SDN)** - архитектура, где управление сетью отделено от передачи данных. Вместо того чтобы настраивать каждый свитч отдельно через CLI, один центральный контроллер программирует всю сеть.
В традиционной сети каждое устройство само решает куда слать пакеты (распределённый control plane). В SDN контроллер видит всю сеть целиком и может принимать оптимальные решения глобально - как GPS-навигатор вместо расспросов прохожих на каждом перекрёстке.
**Три слоя SDN**: 1) **Application Layer** - сетевые приложения (firewall, load balancer, IDS). 2) **Control Layer** - SDN controller с глобальным видением сети. 3) **Infrastructure Layer** - свитчи и роутеры, выполняющие forwarding.
Преимущества SDN: программируемость (сеть как код), централизованное управление (один источник правды), быстрая адаптация (изменить поведение всей сети за секунды), vendor-agnostic (OpenFlow работает на разном железе).
В чём главное отличие SDN от традиционной сети?
OpenFlow Protocol
**OpenFlow** - протокол связи между SDN контроллером и свитчами. Это 'язык', на котором контроллер говорит свитчам что делать с пакетами. OpenFlow стал первым и самым распространённым southbound API в SDN.
Свитч хранит **Flow Table** - таблицу правил. Каждое правило: match (какие пакеты) + action (что делать) + priority + counters. Когда приходит пакет, свитч ищет matching правило и выполняет action.
**Reactive vs Proactive**: В reactive mode контроллер устанавливает правила по первому пакету (packet-in). В proactive mode правила заранее прописаны. Reactive гибче, proactive быстрее (нет задержки на первый пакет).
Что происходит когда пакет не матчит ни одно правило в flow table?
Control Plane
**Control Plane** - 'мозг' сети, который принимает решения о маршрутизации. В SDN это централизованный контроллер с глобальным view топологии. Он знает о всех свитчах, линках, хостах - и может вычислять оптимальные пути.
SDN контроллер предоставляет **Northbound API** для приложений (REST, gRPC) и **Southbound API** для свитчей (OpenFlow, P4, gNMI). Приложения запрашивают 'изолировать хост X', контроллер транслирует это в flow rules.
**Популярные SDN контроллеры**: ONOS (carrier-grade, Java), OpenDaylight (enterprise, Java), Ryu (research/learning, Python), Floodlight (datacenter, Java), POX (учебный, Python).
Что такое 'Intent' в контексте SDN контроллера?
Data Plane
**Data Plane** (Forwarding Plane) - уровень, который физически передаёт пакеты. В SDN это 'глупые' свитчи с flow tables. Они не думают - только выполняют match-action правила на wire speed (миллионы пакетов в секунду).
Для высокой производительности data plane использует специализированное железо: **ASIC** (Application-Specific IC), **TCAM** (Ternary CAM для быстрого match), **NPU** (Network Processing Unit). Программные свитчи (OVS) используют kernel bypass и DPDK.
**P4 (Programming Protocol-independent Packet Processors)** - язык для программирования data plane. В отличие от OpenFlow (фиксированный набор match fields), P4 позволяет определять собственные headers и processing pipeline. Это 'SDN 2.0'.
SDN делает сеть медленнее из-за централизованного контроллера
Data plane работает на wire speed - контроллер участвует только при установке правил, не для каждого пакета
После установки flow rule пакеты обрабатываются локально в свитче за наносекунды. Контроллер нужен только для первого пакета (reactive) или изменения политик. В steady state контроллер не в пути данных.
Почему TCAM используется для match в hardware свитчах?
Итоги
- **SDN** разделяет control plane (решения) и data plane (forwarding) - централизованное управление сетью
- **OpenFlow** - протокол между контроллером и свитчами. Flow table = match + action rules
- **Control Plane** - SDN контроллер с глобальным view. Northbound API для приложений, Southbound для свитчей
- **Data Plane** - 'глупые' свитчи с TCAM для wire-speed forwarding. OVS для виртуализации
- **Intent** - высокоуровневая абстракция: описываем 'что хотим', контроллер вычисляет flow rules
Связанные темы
SDN - фундамент современных сетей:
- Динамическая маршрутизация — SDN заменяет распределённые протоколы (OSPF, BGP) централизованным контроллером
- Network Automation — SDN контроллер - это programmable API. Ansible/Terraform могут управлять через него
Вопросы для размышления
- Что случится с сетью если SDN контроллер упадёт? Как обеспечить high availability?
- Почему SDN особенно популярен в datacenter'ах, но не в enterprise campus сетях?
- Как бы вы реализовали dynamic load balancing через SDN контроллер?