You are here: Home / Users / Sasha Shkrebets / SDN / 2024 / Бакалавриат / Dr. Nick Feamster - Software Defined Networking (Coursera) / Неделя 1 (Week 1) / Виртуализация сетей (субтитры)

Виртуализация сетей (субтитры)

by Sasha Shkrebets last modified Feb 06, 2023 10:31 PM

Plain Text icon network_virtualization.vtt.txt — Plain Text, 27 kB (28500 bytes)

File contents

WEBVTT

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

2
00:00:01.890 --> 00:00:05.890
Мы продолжаем обсуждение истории программно-определяемых сетей.

3
00:00:05.890 --> 00:00:08.610
Сегодня мы поговорим о виртуализации сети.

4
00:00:09.870 --> 00:00:13.251
Сначала мы расскажем о том, что такое виртуализация сети

5
00:00:13.251 --> 00:00:15.804
и для чего она полезна, и проследим

6
00:00:15.804 --> 00:00:18.288
ее историю до 1990-х годов, а

7
00:00:18.288 --> 00:00:22.710
также изучим некоторые разработки в области виртуализации сети.

8
00:00:22.710 --> 00:00:24.982
За последние десять лет в виде

9
00:00:24.982 --> 00:00:28.745
поддержки сетевых экспериментов, а также различных

10
00:00:28.745 --> 00:00:32.224
концепций, таких как разделение поставщиков услуг от

11
00:00:32.224 --> 00:00:37.830
поставщиков инфраструктуры, которые мы видели в некоторых более ранних сетевых архитектурах.

12
00:00:37.830 --> 00:00:39.711
Мы также будем смотреть вперед и говорить о

13
00:00:39.711 --> 00:00:43.080
том, как виртуализация сети связана с программно определяемыми сетями.

14
00:00:44.170 --> 00:00:47.068
Итак, чтобы напомнить вам, где мы находимся, мы находимся в третьем

15
00:00:47.068 --> 00:00:52.600
из трех уроков, где мы обсуждаем эволюцию вспомогательных технологий.

16
00:00:52.600 --> 00:00:56.530
Мы только что закончили обсуждение истории программируемости сети,

17
00:00:56.530 --> 00:01:00.100
а также рассказали об истории управления центральной сетью.

18
00:01:00.100 --> 00:01:03.169
На этом уроке мы расскажем об истории виртуализации сети.

19
00:01:04.390 --> 00:01:06.900
Итак, в первую очередь, что такое сетевая виртуализация?

20
00:01:06.900 --> 00:01:11.530
Проще говоря, виртуализация сети представляет собой представление одной или нескольких

21
00:01:11.530 --> 00:01:16.150
логических топологий сети поверх той же базовой физической инфраструктуры.

22
00:01:16.150 --> 00:01:21.690
Кроме того, существует множество различных экземпляров виртуализации сети.

23
00:01:21.690 --> 00:01:26.360
Некоторые из них, которые предшествовали даже 1990-х годов, такие как виртуальные локальные сети.

24
00:01:27.650 --> 00:01:31.118
То, что мы собираемся говорить в этом уроке, однако,

25
00:01:31.118 --> 00:01:33.906
различные технологии и сетевые тесты, которые

26
00:01:33.906 --> 00:01:36.830
используют и развивают виртуализацию сети с тех пор,

27
00:01:36.830 --> 00:01:40.706
что по существу привели к некоторым из более зрелых

28
00:01:40.706 --> 00:01:45.570
технологий виртуальной сети, которые мы видим в виде компаний и коммерческая продукция сегодня.

29
00:01:47.050 --> 00:01:50.800
Итак, в первую очередь, каковы преимущества виртуализации сети.

30
00:01:50.800 --> 00:01:52.320
Один из них делится.

31
00:01:52.320 --> 00:01:57.504
Таким образом, с помощью виртуализации сети можно создавать экземпляры нескольких логических

32
00:01:57.504 --> 00:02:00.420
маршрутизаторов поверх одного физического узла или

33
00:02:00.420 --> 00:02:04.875
одной платформы, и в более общем плане можно создавать экземпляры нескольких

34
00:02:04.875 --> 00:02:10.850
виртуальных сетей поверх той же физической сетевой инфраструктуры.

35
00:02:10.850 --> 00:02:15.071
Это совместное использование, конечно, требует возможности обеспечить изоляцию ресурсов

36
00:02:15.071 --> 00:02:19.260
с точки зрения процессора, памяти, пропускной способности, таблиц пересылки и так далее.

37
00:02:20.540 --> 00:02:22.652
Таким образом, помимо совместного использования,

38
00:02:22.652 --> 00:02:26.990
виртуализация сети предлагает перспективу настройки.

39
00:02:26.990 --> 00:02:30.970
Пользователи виртуальной сети могут получить

40
00:02:30.970 --> 00:02:34.900
представление о своей собственной логической сети и логической

41
00:02:34.900 --> 00:02:38.480
топологии сети, отдельно от других логических сетей, которые

42
00:02:38.480 --> 00:02:42.160
могут работать на той же базовой физической инфраструктуре.

43
00:02:42.160 --> 00:02:45.074
А возможность видеть независимую

44
00:02:45.074 --> 00:02:48.740
логическую сеть также позволяет запускать

45
00:02:48.740 --> 00:02:52.970
настраиваемое программное обеспечение маршрутизации и пересылки самостоятельно,

46
00:02:52.970 --> 00:02:57.020
на этом конкретном фрагменте виртуальной сети.

47
00:02:59.500 --> 00:03:03.660
Итак, давайте просто посмотрим, как это может выглядеть с точки зрения нескольких снимков.

48
00:03:03.660 --> 00:03:07.455
Итак, предположим,

49
00:03:07.455 --> 00:03:12.840
что у нас есть фиксированная физическая инфраструктура, а также фиксированная физическая инфраструктура, маршрутизаторы, каналы и т.д.

50
00:03:12.840 --> 00:03:16.930
У нас может быть несколько сторон, которые хотят использовать эту фиксированную физическую инфраструктуру.

51
00:03:16.930 --> 00:03:19.870
Значит, у нас может быть красная вечеринка и синяя вечеринка.

52
00:03:19.870 --> 00:03:23.140
Каждому из которых может потребоваться доступ

53
00:03:23.140 --> 00:03:28.110
к различным базовым физическим сетевым ресурсам.

54
00:03:28.110 --> 00:03:33.090
Каждая из этих сторон может также захотеть создать различные

55
00:03:33.090 --> 00:03:39.130
произвольные виртуальные топологии поверх этой базовой физической инфраструктуры.

56
00:03:39.130 --> 00:03:41.977
Итак, идея заключается в том, что каждая из этих сторон,

57
00:03:41.977 --> 00:03:45.262
которые хотят использовать инфраструктуру, имеет возможность

58
00:03:45.262 --> 00:03:49.058
создавать собственное представление или собственную виртуальную топологию,

59
00:03:49.058 --> 00:03:53.630
собственную логическую топологию, расположенную на вершине этой физической инфраструктуры.

60
00:03:53.630 --> 00:03:55.360
И идея заключается в том, что каждый из них

61
00:03:55.360 --> 00:03:58.380
сможет работать самостоятельно, не вмешиваясь друг в друга.

62
00:03:59.690 --> 00:04:01.148
Итак, в остальной части этого урока мы

63
00:04:01.148 --> 00:04:04.770
рассмотрим три разных примера виртуальных сетей.

64
00:04:04.770 --> 00:04:07.400
Одним из них является архитектура буря, Switchlets,

65
00:04:07.400 --> 00:04:10.010
которая восходит к концу 1990-х годов.

66
00:04:10.010 --> 00:04:12.420
И некоторые из идей, которые появились из Switchlets

67
00:04:12.420 --> 00:04:16.660
, - это разделение структуры управления от самих базовых коммутаторов.

68
00:04:16.660 --> 00:04:22.790
А также возможность или возможность виртуализации базового

69
00:04:22.790 --> 00:04:28.759
оборудования коммутатора для обеспечения внешнего вида нескольких виртуальных коммутаторов.

70
00:04:31.590 --> 00:04:36.489
Вторая технология виртуальной сети, которую мы рассмотрим, это то, что называется

71
00:04:36.489 --> 00:04:39.258
виртуальной сетевой инфраструктурой или VINI, которая

72
00:04:39.258 --> 00:04:41.743
восходит к 2006 году, и мотивация

73
00:04:41.743 --> 00:04:43.447
здесь заключалась в том, чтобы предоставить виртуальную

74
00:04:43.447 --> 00:04:46.855
сетевую инфраструктуру, чтобы экспериментаторы могли проводить

75
00:04:46.855 --> 00:04:49.553
эксперименты со своими логическими сетей,

76
00:04:49.553 --> 00:04:52.660
совместно используемых в той же базовой физической топологии.

77
00:04:52.660 --> 00:04:57.277
Затем мы рассмотрим сетевую архитектуру под названием Cabo, которая использовала

78
00:04:57.277 --> 00:05:01.813
некоторое видение новых технологий виртуальной сети, чтобы

79
00:05:01.813 --> 00:05:07.807
понять, что виртуальные сети могут позволить поставщикам услуг работать

80
00:05:07.807 --> 00:05:10.075
независимо от поставщиков, которые делают

81
00:05:10.075 --> 00:05:14.470
базовую физическую сеть инфраструктуры.

82
00:05:15.900 --> 00:05:17.700
Итак, давайте сначала посмотрим на переключатели, которые

83
00:05:17.700 --> 00:05:21.000
вышли из чего-то, называемого архитектурой Буря.

84
00:05:21.000 --> 00:05:23.900
В этой конкретной архитектуре у нас

85
00:05:23.900 --> 00:05:28.560
есть один базовый коммутатор с его ресурсами.

86
00:05:28.560 --> 00:05:31.594
И тогда у нас есть открытый интерфейс управления коммутатором,

87
00:05:31.594 --> 00:05:35.750
а затем предоставляет эти ресурсы программному обеспечению, которое сидит выше.

88
00:05:36.810 --> 00:05:40.400
Действительно, этот интерфейс управления выглядит немного как открытый поток.

89
00:05:41.640 --> 00:05:44.977
Таким образом, идея или мотивация коммутаторов заключалась в том, чтобы

90
00:05:44.977 --> 00:05:49.670
позволить нескольким архитектурам управления работать в одной сети ATM.

91
00:05:51.420 --> 00:05:55.350
Открытый интерфейс управления разделил контроллер

92
00:05:55.350 --> 00:05:59.110
коммутатора и матрицу с помощью открытого протокола сигнализации.

93
00:06:00.290 --> 00:06:05.350
Делитель разбил ресурсы коммутатора, чтобы позволить

94
00:06:05.350 --> 00:06:09.679
нескольким контроллерам иметь собственное представление логического коммутатора.

95
00:06:10.710 --> 00:06:14.858
Действительно, это немного похоже на козырек потока, то, что мы изучим

96
00:06:14.858 --> 00:06:16.322
немного больше, когда мы говорим

97
00:06:16.322 --> 00:06:19.410
о современных архитектурах SDN, в частности об открытом потоке.

98
00:06:21.680 --> 00:06:25.740
Разделитель коммутатора, пространство портов раздела, пропускная способность и

99
00:06:25.740 --> 00:06:28.879
буферы, а также позволяют различным контроллерам управлять каждым коммутатором.

100
00:06:30.370 --> 00:06:33.294
В дополнение к сходству этой архитектуры

101
00:06:33.294 --> 00:06:36.218
с некоторыми более современными архитектурами SDN, также

102
00:06:36.218 --> 00:06:39.278
интересно отметить этот пункт в заключении

103
00:06:39.278 --> 00:06:43.640
документа, в котором представлена архитектура switchlet.

104
00:06:43.640 --> 00:06:46.052
В нем говорится, что, поскольку любой, кто может получить

105
00:06:46.052 --> 00:06:49.268
виртуальную сеть, будет эффективно сетевым оператором, мы надеемся

106
00:06:49.268 --> 00:06:51.747
увидеть увеличение креативности, которое может

107
00:06:51.747 --> 00:06:54.970
быть привлечено к решению проблемы управления сетью.

108
00:06:54.970 --> 00:07:00.066
Это интересно, потому что он по существу предсказывает, что

109
00:07:00.066 --> 00:07:05.162
произойдет дальше, а именно осознание того, что виртуальные сетевые

110
00:07:05.162 --> 00:07:10.258
инфраструктуры могут позволить исследователям сети преодолеть

111
00:07:10.258 --> 00:07:15.256
разрыв между маломасштабными экспериментами и симуляцией и реальными

112
00:07:15.256 --> 00:07:20.156
живыми развертываниями, и это было мотивацией за VINI или

113
00:07:20.156 --> 00:07:23.499
виртуальной сетевой инфраструктурой.

114
00:07:25.290 --> 00:07:27.670
Идея была в том, что, с одной стороны, мы проводили

115
00:07:27.670 --> 00:07:32.890
контролируемые, повторяемые лабораторные эксперименты, которые потенциально были не столь реалистичными.

116
00:07:32.890 --> 00:07:36.114
С другой стороны, у нас были живые развертывания, которые были очень

117
00:07:36.114 --> 00:07:38.098
реалистичными, могли масштабироваться, запускать реальный

118
00:07:38.098 --> 00:07:41.380
трафик, но не обязательно повторяться.

119
00:07:41.380 --> 00:07:43.870
Идея здесь заключалась в том, что мы могли бы использовать

120
00:07:43.870 --> 00:07:49.940
виртуализацию сети для преодоления разрыва между повторяемостью и реализмом.

121
00:07:50.950 --> 00:07:53.890
Таким образом, VINI запускает реальное программное обеспечение маршрутизации и предоставляет реальные,

122
00:07:53.890 --> 00:07:57.730
реалистичные сетевые условия для приложений, работающих на нем.

123
00:07:57.730 --> 00:07:59.920
Он дает экспериментатору контроль

124
00:07:59.920 --> 00:08:03.080
над различными сетевыми событиями, такими как сбои.

125
00:08:03.080 --> 00:08:05.240
Он может нести трафик от имени реальных пользователей.

126
00:08:05.240 --> 00:08:08.700
Он также может быть разделен между многими различными экспериментаторами.

127
00:08:10.770 --> 00:08:14.270
VINI также использовал разделение

128
00:08:14.270 --> 00:08:17.530
плоскости данных и управления для достижения некоторых из своих целей виртуализации сети.

129
00:08:18.530 --> 00:08:21.684
Его плоскость управления представляет собой

130
00:08:21.684 --> 00:08:26.000
программный маршрутизатор XORP, который использует различные протоколы маршрутизации,

131
00:08:26.000 --> 00:08:29.486
с целью позволить экспериментаторам запускать

132
00:08:29.486 --> 00:08:33.938
реальные протоколы маршрутизации поверх топологий виртуальной сети.

133
00:08:33.938 --> 00:08:39.966
Плоскость данных VINI обеспечивает появление этих

134
00:08:39.966 --> 00:08:45.610
топологий виртуальной сети экспериментаторам.

135
00:08:47.520 --> 00:08:53.100
Плоскость данных VINI реализована с помощью программного маршрутизатора Click,

136
00:08:53.100 --> 00:08:58.320
а интерфейсы, виртуальные интерфейсы были реализованы с использованием

137
00:08:58.320 --> 00:09:03.630
технологии под названием Tunneling, которая также используется во многих других виртуальных

138
00:09:03.630 --> 00:09:09.500
сетевых технологиях, для создания внешнего вида виртуальных связей.

139
00:09:09.500 --> 00:09:15.224
В VINI экспериментаторы могут также поставить фильтры перед этими

140
00:09:15.224 --> 00:09:21.379
туннелями, чтобы создать иллюзию или внешний вид сбоя связи.

141
00:09:22.480 --> 00:09:27.710
Эти фильтры, по сути, просто блокируют пакеты в отдельных туннелях.

142
00:09:27.710 --> 00:09:31.098
Учитывая технологии создания виртуальных сетей,

143
00:09:31.098 --> 00:09:35.025
исследователи затем начали изучать, как эта технология может

144
00:09:35.025 --> 00:09:37.720
быть использована для содействия внедрению

145
00:09:37.720 --> 00:09:41.670
новых услуг и ускорения темпов внедрения инноваций.

146
00:09:41.670 --> 00:09:43.722
Одна из этих архитектур называлась Cabo,

147
00:09:43.722 --> 00:09:46.790
или параллельные архитектуры лучше, чем одна.

148
00:09:46.790 --> 00:09:51.748
Эта архитектура дала представление о том, что поставщики инфраструктуры или

149
00:09:51.748 --> 00:09:56.854
те стороны, которые обслуживают маршрутизаторы, каналы, центры обработки данных и другую физическую

150
00:09:56.854 --> 00:10:00.036
инфраструктуру, могут работать независимо или

151
00:10:00.036 --> 00:10:02.478
отдельно от поставщиков услуг,

152
00:10:02.478 --> 00:10:06.520
предлагающих конечные услуги поверх этого инфраструктуры.

153
00:10:08.940 --> 00:10:11.772
Примеры такого разделения между инфраструктурой и

154
00:10:11.772 --> 00:10:15.580
поставщиками услуг в некотором смысле уже существуют.

155
00:10:15.580 --> 00:10:20.191
Двумя такими примерами являются матрица пакетов, которая позволяет нескольким

156
00:10:20.191 --> 00:10:24.990
поставщикам услуг Интернета совместно использовать одни и те же физические маршрутизаторы в точках обмена.

157
00:10:24.990 --> 00:10:28.256
И FON, коммерческий интернет-провайдер, который

158
00:10:28.256 --> 00:10:32.440
перепродает беспроводное подключение пользователей к Интернету своим клиентам.

159
00:10:33.590 --> 00:10:38.630
FON имеет интересный экономический рефакторинг, где пользователи в своих

160
00:10:38.630 --> 00:10:44.678
домах, которые покупают подключение вверх по течению от различных интернет-провайдеров,

161
00:10:44.678 --> 00:10:49.970
фактически являются инфраструктурными провайдерами, а FON является просто брокером

162
00:10:49.970 --> 00:10:55.100
этой интернет-услуги и эффективно выступает в качестве поставщика услуг.

163
00:10:56.970 --> 00:10:59.700
Итак, давайте просто подытожим то, что мы узнали в этом уроке.

164
00:10:59.700 --> 00:11:04.260
Мы узнали о виртуализации сети, в частности о том, что это такое.

165
00:11:04.260 --> 00:11:08.012
Виртуализация сети отделяет логическую сеть, которую

166
00:11:08.012 --> 00:11:11.161
видят пользователи или поставщики услуг, от

167
00:11:11.161 --> 00:11:14.913
подчеркивающей физической инфраструктуры и потенциально позволяет нескольким сторонам использовать одну и

168
00:11:14.913 --> 00:11:19.239
ту же физическую инфраструктуру для различных целей.

169
00:11:20.730 --> 00:11:24.590
Виртуализация сети имеет богатую историю, относящуюся

170
00:11:24.590 --> 00:11:28.910
к виртуальным коммутаторам или коммутаторам в 1990-х годах.

171
00:11:28.910 --> 00:11:33.200
Сетевые тестовые центры, такие как VINI, и эти архитектуры, которые

172
00:11:33.200 --> 00:11:37.809
предполагают использование виртуализации сети для предоставления различных типов услуг.

173
00:11:39.150 --> 00:11:44.360
Наследие виртуализации сети для SDN на самом деле довольно богато.

174
00:11:44.360 --> 00:11:49.470
Идея разделения поставщиков услуг от поставщиков инфраструктуры — это то

175
00:11:49.470 --> 00:11:53.330
, что мы видим сегодня в коммерческих сетях, определяемых программным обеспечением.

176
00:11:54.400 --> 00:11:59.460
Идея использования нескольких контроллеров для управления одним коммутатором

177
00:11:59.460 --> 00:12:04.612
и выставления нескольких логических коммутаторов поверх одного коммутатора на

178
00:12:04.612 --> 00:12:10.860
самом деле имеет корни в архитектуре коммутаторов.

179
00:12:10.860 --> 00:12:13.278
И идея о том, что одна физическая

180
00:12:13.278 --> 00:12:17.178
инфраструктура может, на самом деле, раскрыть несколько логических

181
00:12:17.178 --> 00:12:19.830
топологий сети, также имеет свои корни во

182
00:12:19.830 --> 00:12:23.420
многих исследованиях виртуализации сети.

183
00:12:23.420 --> 00:12:27.069
Таким образом, подытоживая, мы только что завершили три

184
00:12:27.069 --> 00:12:29.561
сокращения, которые изучают поддерживающие

185
00:12:29.561 --> 00:12:33.210
технологии для программно-определяемых сетей.

186
00:12:34.550 --> 00:12:39.380
Далее мы поговорим о различных типах стандартизации плоскости управления

187
00:12:39.380 --> 00:12:41.130
, которые происходили параллельно

188
00:12:41.130 --> 00:12:44.469
с эволюцией этих вспомогательных технологий.
Navigation