sdn nov-21-v1.1
DESCRIPTION
Научно-технический семинар 21 ноября, доклад Даниила ГинсбургаTRANSCRIPT
Даниил Гинсбург
Сетевой архитектор
SDN –революция или эволюция?
План выступления
Критиканство!
Пессимизм!
Скепсис!
Чуть-чуть конструктива
Может быть все и так хорошо в
сетевом мире?
А может быть не надо?
5
Что сейчас не так в сетевом мире
• Передача полезного трафика (data-plane)
устроена сложно
• Управление сетью (control-plane) устроено
сложно
• Ущербные и невыразительные абстракции
• Используется 5%* возможностей
оборудования, а оплачивается 100%
• Отсутствие программируемости – мы
заложники у вендоров
• Крайне затрудненная автоматизация
6
Надо что-то делать!
Давайте сделаем что-то …
… и назовем это SDN!
Scott Schenker
Not a revolutionary technology....
-....just a way of organizing network functionality
SDN - о чем это?
8
SDN – это магическая штука, которая
• Даст нам удобные абстракции– Простые!
– Понятные и естественные!
– Выразительные!
• Позволит пользователю реализовывать
функции сети самостоятельно
• Обеспечит независимость от вендора
• Даст возможность автоматизировать ВСЁ!
• Преобразит мир!
9
Как предлагается этого достичь
• Разделить прохождение трафика (data-
plane) и сигнализацию/управление (control-
plane)
• Сделать элементы data-plane крайне
простыми
• Централизовать control-plane
• Это все позволит быстро и просто
реализовывать удобные абстракции в
control-plane независимо от data-plane
10
Разделить control и data
• Разделить прохождение трафика (data-
plane) и сигнализацию/управление (control-
plane)
• Совсем-совсем разделить data-plane и
control-plane?
11
Разделить control и data
• Идея не нова – так устроен любой
современный роутер (плюс миллион
примеров из истории)
12
Разделить control и data
• Крайне усложняет модель отказов
13
Простой сетевой элемент
• Сделать элементы data-plane крайне
простыми (или сделать вид)
• Насколько просто должен выглядеть
сетевой элемент?
14
Сетевой элемент - идея
• Lookup
• Rewrite
• Forward
• …
• PROFIT!
15
Сетевой элемент - реальность
Крайне упрощенная схема сетевого элемента
16
Сетевой элемент – openflow
• OpenFlow 1.0 – multi-field lookup
• Крайне примитивная модель
• Комбинаторный взрыв
17
Комбинаторный взрыв
Задача: Пропускать трафик на N хостов на
одни и те же M TCP-портов, остальной
сбрасывать.
Решение OpenFlow 1.0: NxM записей
18
Сетевой элемент – openflow
• OpenFlow 1.1 – multiple tables
• Избавление от комбинаторного взрыва
• Сравнительно элегантная модель
• Плохо отображается на железо
• Дорогое удовольствие
19
Комбинаторный взрыв
Задача: Пропускать трафик на N хостов на
одни и те же M TCP-портов, остальной
сбрасывать.
Решение OpenFlow 1.1+: N записей в одной
таблице, M записей в другой
20
Сетевой элемент – openflow
• OpenFlow X.X – FAWG
• Вся сложность наружу
• Ну и где же абстракция для data-plane?
21 Если так пришлось сделать, значит уровень абстракции выбран неверно
22
Централизация и децентрализация
• Централизовать control-plane
• Насколько централизованным должен быть
control-plane?
23
Централизация и децентрализация
• Колебательный процесс между двумя
крайностями– «Развитие идѐт через постоянное отрицание противоположностей
друг другом, их взаимопревращение, вследствие чего в
поступательном движении происходит возврат назад, в новом
повторяются черты старого» - Ф. Энгельс
• Нормальное явление в индустрии
• Диктуется не только модой и маркетингом, а
еще и объективными факторами (иногда)
• Вывод: нужна гибкость
24
It is always possible to agglutinate multiple separate
problems into a single complex interdependent solution.
In most cases this is a bad idea.
RFC 1925
25
Централизация openflow-style
• Элемент крайне туп и не способен ни к
каким самостоятельным действиям
• Контроллер должен реагировать на все
события в сети
• Как это масштабировать? Новым витком
спирали централизация/децентрализация?
Делать SDN правильно!
Так делать-то чего?
27
SDN – это магическая штука, которая
• Даст нам удобные абстракции– Простые!
– Понятные и естественные!
– Выразительные!
• Позволит пользователю реализовывать
функции сети
• Обеспечит независимость от вендора
• Даст возможность автоматизировать ВСЁ!
• Это отличные свойства и их действительно
стоит хотеть!
28
Что же для этого надо сделать?
• Стандартизовать один механизм data-plane
• Выбрать правильную абстракцию элемента
• Обеспечить возможность реализовать
сетевые функции как централизованно, так
и децентрализовано
• Обеспечить возможность комбинирования
функций
29
Почему оба стиля управления важны
• Есть естественно централизованные
функции – например, высокоуровневые
политики
• Есть естественно децентрализованные
функции – например, перемашрутизация
при сбоях
• А есть функции, которые можно
реализовывать там, где это выгодно здесь и
сейчас – например, вычисление пути
30
Комбинирование
• Сеть может иметь доменную структуру –
например: DC и WAN, access и core, RAN
backhaul и т.д.
• В разных доменах функции могут
реализовываться по-разному
• Домены нужно «сшивать» и «накладывать»
• Поверх транспорта мы можем реализовать
«сервисы»
31 Домены сети могут управляться по-разному
32 Домены сети могут управляться по-разному
33 Необходимо строить наложенные домены
34 И поверх них можно создавать сервисы
35
Правильная абстракция элемента
• Должна действительно прятать сложность
сетевого элемента
• Должна позволять комбинирование стилей
управления
• Похоже, что правильную абстракцию(-ии)
предоставит i2rs от IETF – более высокий
уровень
Что надо развертывать завтра
Где мы сейчас
37
Зачем?
• На сегодня два с половиной самых
актуальных применения SDN:
• Сетевая виртуализация
• Сцепление сервисов
Компоненты решения
• Уровень транспорта и уровень
виртуализации
• Транспорт – IP/MPLS– Распределенная сигнализация
– С PCE (stateful PCE) или без – по потребности
• Виртуализация – Начинается от хоста
– MPLS-метка в качестве сервисного демультиплексора
– Гибридное управление наложенной сетью
• Централизация политик
Заключение
40
Заключение
• Идея хороша. SDN обещает нам много, и
обещанного стоит желать
• Первый блин комом: OpenFlow – по
большей части лабораторная игрушка
• SDN это не только OpenFlow
• Централизация – не самоцель
• «Традиционные» сети и SDN будут жить
вместе
• Архитектура SDN должна быть гибкой и
допускать частичное внедрение
Backup slides
Почему надо пересмотреть data-plane
• Очень много разных механизмов
• Когда их надо сочетать, всѐ становится
сложно
• Многие из них тесно связаны с неуклюжими
абстракциями высших уровней и тянут их за
собой в железо
44
Какой он, идеальный data-plane?
• Простой (на самом деле простой!)
• Гибкий
• Поддерживает иерархичность от природы
• Не ставит препятствий для
масштабирования
• Не несет с собой предположений, о том как
он должен управляться
45
Называется он MPLS
А способ комбинирования –
indirect FEC resolution