WEBVTT

1
00:00:00.480 --> 00:00:01.997
С возвращением.

2
00:00:01.997 --> 00:00:05.159
На этом уроке мы расскажем об интеллектуальной

3
00:00:05.159 --> 00:00:08.770
истории программно-определяемых сетей, которая охватывает более 20 лет.

4
00:00:10.030 --> 00:00:14.470
Несмотря на то, что волнение о программно-определяемых сетях выросло за последние несколько

5
00:00:14.470 --> 00:00:17.810
лет, многие идеи эволюционировали за последние 20 лет.

6
00:00:19.050 --> 00:00:21.974
Действительно, термин «программно-определяемая сеть» был

7
00:00:21.974 --> 00:00:24.014
придуман в 2009 году, но многие

8
00:00:24.014 --> 00:00:28.883
идеи имеют корни в более ранних технологиях, начиная с телефонной сети.

9
00:00:28.883 --> 00:00:31.435
Подробнее о материале, описанном

10
00:00:31.435 --> 00:00:34.050
в этом уроке, вы можете прочитать в статье, которая приведена ниже.

11
00:00:34.050 --> 00:00:34.550
Мы

12
00:00:36.270 --> 00:00:37.660
можем думать об интеллектуальной истории

13
00:00:37.660 --> 00:00:41.150
программных сетей, определяемых в три этапа.

14
00:00:41.150 --> 00:00:45.220
Активные сети, которые ввели понятие программируемых сетей.

15
00:00:45.220 --> 00:00:47.456
Управление и разделение плоскости данных, которые предлагали

16
00:00:47.456 --> 00:00:49.740
открытые интерфейсы между плоскостями управления и данными.

17
00:00:49.740 --> 00:00:54.570
И OpenFlow API и сетевые операционные системы, которые являются первым экземпляром

18
00:00:54.570 --> 00:00:57.606
широко распространенного внедрения, открытого интерфейса между

19
00:00:57.606 --> 00:01:01.060
плоскостью управления и программируемыми маршрутизаторами и коммутаторами.

20
00:01:01.060 --> 00:01:04.879
Для каждого из этих этапов мы поговорим об интеллектуальном вкладе

21
00:01:04.879 --> 00:01:06.247
этого этапа, а также о различных

22
00:01:06.247 --> 00:01:09.170
мифах и заблуждениях, связанных с этой технологией.

23
00:01:12.120 --> 00:01:14.220
Активные сети появились в то время, когда Интернет

24
00:01:14.220 --> 00:01:17.010
стал видеть гораздо более разнообразные приложения и все более широкое использование.

25
00:01:18.440 --> 00:01:20.816
Исследователи хотели развернуть новые идеи, и активная

26
00:01:20.816 --> 00:01:23.900
сеть была первой попыткой сделать сети программируемыми.

27
00:01:24.900 --> 00:01:27.586
Это было вызвано сокращением

28
00:01:27.586 --> 00:01:31.459
расходов на вычисления, а также большим интересом со стороны финансирующих учреждений.

29
00:01:31.459 --> 00:01:34.309
С другой стороны, сетевые операторы были разочарованы

30
00:01:34.309 --> 00:01:37.380
трудностями, связанными с внедрением новых технологий в сети.

31
00:01:39.700 --> 00:01:43.921
Интеллектуальный вклад активных сетей включал понятие

32
00:01:43.921 --> 00:01:48.142
программируемых функций в сети, виртуализацию сети,

33
00:01:48.142 --> 00:01:51.626
возможность иметь пакет demulitiplex в программные программы,

34
00:01:51.626 --> 00:01:55.000
которые сидели на маршрутизаторах и коммутаторах в сети.

35
00:01:56.700 --> 00:01:59.800
И хотя это так и не было реализовано, активные сети действительно

36
00:01:59.800 --> 00:02:03.750
предлагают видение единой архитектуры для оркестрации middlebox.

37
00:02:03.750 --> 00:02:06.450
Мы видим, что это приносит плоды в

38
00:02:06.450 --> 00:02:10.772
таких технологиях, как NFV, или виртуализация сетевых функций.

39
00:02:10.772 --> 00:02:13.130
Существует много мифов вокруг активных сетей, а также.

40
00:02:14.600 --> 00:02:18.160
Один из них заключается в том, что многие люди думали, что активные сети подразумевают, что

41
00:02:18.160 --> 00:02:21.310
конечный пользователь всегда будет писать программы, которые идут в пакеты.

42
00:02:22.550 --> 00:02:25.028
На самом деле, большинство исследователей, работающих в этой области,

43
00:02:25.028 --> 00:02:28.140
признают, что эта модель программирования будет довольно редкой.

44
00:02:28.140 --> 00:02:30.154
Еще один миф об активной сети, состоял в том,

45
00:02:30.154 --> 00:02:32.344
что многие думали, что пакеты должны нести Java-код.

46
00:02:32.344 --> 00:02:34.488
На самом деле, активная сеть имела

47
00:02:34.488 --> 00:02:37.503
альтернативную программируемую модель маршрутизатора и коммутатора,

48
00:02:37.503 --> 00:02:42.229
которая выглядит не слишком отличной от многих архитектур SDN, описанных сегодня.

49
00:02:43.310 --> 00:02:46.217
Технологии, которые исследовали разделение

50
00:02:46.217 --> 00:02:49.440
плоскости управления и данных в сети, приняли смещение в сторону прагматизма.

51
00:02:49.440 --> 00:02:53.094
Попытка обеспечить программируемость, но ее решение в контексте

52
00:02:53.094 --> 00:02:54.660
гораздо более узких

53
00:02:54.660 --> 00:02:57.850
проблем управления сетью, таких как проектирование трафика.

54
00:02:57.850 --> 00:03:00.070
Рабочие группы МФТ, такие как Forces,

55
00:03:00.070 --> 00:03:04.180
разработали открытые интерфейсы между плоскостями управления и данными.

56
00:03:04.180 --> 00:03:08.212
И другие исследователи также разработали технологии для логически

57
00:03:08.212 --> 00:03:12.111
централизованного управления, такие как платформа управления маршрутизацией.

58
00:03:12.111 --> 00:03:13.947
С другой стороны, многие сетевые операторы

59
00:03:13.947 --> 00:03:16.450
столкнулись с насущными проблемами управления сетью, которые необходимо решить.

60
00:03:17.640 --> 00:03:20.490
Многие из первоначальных архитектур, предлагавших управление и

61
00:03:20.490 --> 00:03:24.410
разделение плоскости данных, решали очень специфическую проблему управления сетью.

62
00:03:27.070 --> 00:03:30.682
Управление и разделение плоскости данных предлагают два важных интеллектуальных вклада.

63
00:03:30.682 --> 00:03:33.118
Первым было понятие логически централизованного

64
00:03:33.118 --> 00:03:36.121
управления с использованием открытого интерфейса для маршрутизаторов и коммутаторов.

65
00:03:36.121 --> 00:03:41.461
Второй — технологии и алгоритмы для достижения распределенного

66
00:03:41.461 --> 00:03:46.853
управления состояниями в распределенном наборе сетевых контроллеров.

67
00:03:46.853 --> 00:03:48.842
Было

68
00:03:48.842 --> 00:03:50.502
также несколько мифов вокруг управления и разделения плоскости данных.

69
00:03:50.502 --> 00:03:53.267
Но, пожалуй, самым важным мифом было

70
00:03:53.267 --> 00:03:58.174
то, что логически централизованное управление каким-то образом нарушает обмен судьбой.

71
00:03:58.174 --> 00:04:02.186
Фактически, многие традиционные решения распределенной маршрутизации, такие как

72
00:04:02.186 --> 00:04:06.620
зоны OSPF и отражатели маршрутов BGP, уже нарушили эти принципы.

73
00:04:07.750 --> 00:04:11.776
И несколько парадоксально, введение дальнейшего разделения данных

74
00:04:11.776 --> 00:04:15.670
и управляющих плоскостей позволило исследователям задуматься о распределенном

75
00:04:15.670 --> 00:04:18.574
управлении состоянием гораздо более чистыми способами, чем они

76
00:04:18.574 --> 00:04:22.540
могли бы сделать в контексте существующих протоколов и технологий маршрутизации.

77
00:04:23.750 --> 00:04:27.670
OpenFlow использовал гораздо более общий подход, предоставляя больше функций,

78
00:04:27.670 --> 00:04:29.550
чем предыдущие контроллеры маршрутов, и

79
00:04:29.550 --> 00:04:32.050
основываясь на существующей аппаратной поддержке коммутаторов.

80
00:04:33.070 --> 00:04:36.570
Опираясь на поддержку существующего оборудования коммутатора

81
00:04:36.570 --> 00:04:41.400
, несколько ограничила гибкость, но обеспечила огромный выигрыш в немедленном развертывании.

82
00:04:41.400 --> 00:04:44.160
В некотором смысле OpenFlow был подтолкнут идеальный

83
00:04:44.160 --> 00:04:48.860
шторм между операторами сети, которые столкнулись с реальными проблемами управления сетью.

84
00:04:50.240 --> 00:04:52.340
Поставщики, многие из которых стремились

85
00:04:52.340 --> 00:04:56.190
отстранить действующих поставщиков, дизайнеры наборов микросхем, которые начали

86
00:04:56.190 --> 00:04:59.340
открывать свои API, и исследователи, которые

87
00:04:59.340 --> 00:05:01.750
искали новые способы внедрения инноваций в сети.

88
00:05:03.890 --> 00:05:07.840
OpenFlow изначально был принят в кампусах, а затем в центрах обработки данных.

89
00:05:09.190 --> 00:05:11.098
Теперь мы видим гораздо больше развертываний

90
00:05:11.098 --> 00:05:13.340
OpenFlow в различных сетях.

91
00:05:15.140 --> 00:05:18.720
Сам OpenFlow предложил несколько интеллектуальных вкладов.

92
00:05:18.720 --> 00:05:20.962
Одним из них было обобщение сетевых устройств и

93
00:05:20.962 --> 00:05:23.930
функций, которые управляют плоскостью данных и поддержкой.

94
00:05:23.930 --> 00:05:26.750
Вторым, который пришел в сочетании с OpenFlow,

95
00:05:26.750 --> 00:05:29.954
было видение сетевой операционной системы с тремя уровнями.

96
00:05:29.954 --> 00:05:34.362
Плоскость данных с открытым API, слой для управления состоянием и третий

97
00:05:34.362 --> 00:05:37.250
слой логики управления, которые повлияли на

98
00:05:37.250 --> 00:05:40.660
плоскость данных в зависимости от состояния сети.

99
00:05:40.660 --> 00:05:42.420
Эти сетевые операционные системы также

100
00:05:42.420 --> 00:05:44.880
разработали новые методы управления распределенными состояниями.

101
00:05:46.470 --> 00:05:49.088
Существует также несколько мифов вокруг OpenFlow.

102
00:05:49.088 --> 00:05:52.880
Один из них заключается в том, что многие думали, что первый пакет

103
00:05:52.880 --> 00:05:54.900
каждого потока данных должен идти к контроллеру.

104
00:05:54.900 --> 00:05:58.260
И на самом деле, OpenFlow не делает предположений о детализации

105
00:05:58.260 --> 00:06:01.580
правил или о том, обрабатывает ли контроллер любой трафик вообще.

106
00:06:03.470 --> 00:06:06.930
Второй миф заключается в том, что контроллер должен быть физически централизован.

107
00:06:06.930 --> 00:06:09.540
Фактически, большинство реальных развертываний имеют распределенные контроллеры.

108
00:06:09.540 --> 00:06:14.030
Последний миф заключается в том, что SDN и OpenFlow эквивалентны.

109
00:06:14.030 --> 00:06:16.460
На самом деле, OpenFlow - это всего лишь один экземпляр SDN.

110
00:06:18.990 --> 00:06:22.470
Наше интеллектуальное путешествие дало несколько уроков, но, пожалуй

111
00:06:22.470 --> 00:06:25.710
, самым важным является сбалансированность видения и прагматизма.

112
00:06:27.020 --> 00:06:32.333
OpenFlow, в некотором смысле, взлетел отчасти потому, что он нашел сладкое пятно, между

113
00:06:32.333 --> 00:06:34.951
видением программируемой сети и

114
00:06:34.951 --> 00:06:39.042
прагматизмом, обеспечиваемым поддержкой существующего оборудования.

115
00:06:39.042 --> 00:06:42.584
Эта напряженность сохраняется по мере того, как мы стремимся распространить понятия

116
00:06:42.584 --> 00:06:46.870
SDN и сетевой контроль на другие части сети.

117
00:06:46.870 --> 00:06:51.190
В том числе стремление распространить сетевое управление на серверы сырьевых товаров,

118
00:06:51.190 --> 00:06:55.830
а также тенденции к тому, чтобы сделать плоскости данных все более программируемыми. По мере

119
00:06:57.050 --> 00:07:00.480
того, как мы распространяем понятия SDN на эти другие части сети,

120
00:07:00.480 --> 00:07:04.590
важно учитывать баланс между видением и прагматизмом.