sdn nov-21-v1.1

Post on 01-Jul-2015

20.131 Views

Category:

Documents

2 Downloads

Preview:

Click to see full reader

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 должна быть гибкой и

допускать частичное внедрение

Даниил Гинсбург

Сетевой архитектор

dbg@yandex-team.ru

Backup slides

Почему надо пересмотреть data-plane

• Очень много разных механизмов

• Когда их надо сочетать, всѐ становится

сложно

• Многие из них тесно связаны с неуклюжими

абстракциями высших уровней и тянут их за

собой в железо

44

Какой он, идеальный data-plane?

• Простой (на самом деле простой!)

• Гибкий

• Поддерживает иерархичность от природы

• Не ставит препятствий для

масштабирования

• Не несет с собой предположений, о том как

он должен управляться

45

Называется он MPLS

А способ комбинирования –

indirect FEC resolution

top related