IT-оборудование
С пробегом и новое
Доставка по всей России
Время работы:
с 9:00 до 18:00
по Мск
0
0 Р
Акции

Как виртуализировать сеть: часть третья, построение наложенных виртуальных сетей

29 Октября 2019
Как виртуализировать сеть: часть третья, построение наложенных виртуальных сетей

Наши предыдущие статьи в цикле о виртуализации сетей, преимущественно концентрировались на теоретических аспектах этого метода объединения сетевых ресурсов, а также инструментах аппаратной виртуализации. В этой же публикации мы обратимся к практическим аспектам виртуализации, рассмотрев преимущества и недостатки двух основных подходов к построению наложенных виртуальных сетей.

Помимо расширения возможностей удаленного доступа важнейшей причиной виртуализации сети для небольшой или средней организации является сетевая автоматизация, повышающая отказоустойчивость. Как правило речь здесь идет о SDN (Software Defined Network) – подходе к управлению сетью, при котором изменения на сети выполняются не человеком, а программой. Обычно означает вынесение Control Plane за пределы конечных сетевых устройств на контроллер. Практика показывает, что сетевая часть IT-инфраструктуры компании является самой инертной и развивается медленнее всего, т.к. является базисом, на который опирается работа большинства сервисов. Соответственно в ней сложно производить изменения т.к. часто вывод из эксплуатации одного узла может сказаться на работе многих приложений и повлиять на большое число клиентов.

Чтобы снизить эти риски, все больше системных администраторов обращается к практике использования наложенных виртуальных сетей – overlay-сетей. Overlay-сетью обычно называют виртуальную сеть туннелей, которая надстраивается на физической сетью (underlay – коммутаторы, маршрутизаторы, кабели), и которая позволяет виртуальным машинам одного клиента взаимодействовать, при этом обеспечивая изоляцию от других клиентов. Данные клиента инкапсулируются в какие-либо туннелирующие заголовки для передачи через общую сеть. В качестве примеров таких сетей можно назвать GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE и т.д. Их привлекательность заключается в следующем.

  • Во-первых, настраивать нужно только конечные, а не транзитные узлы – это существенно ускоряет процесс подключения новых сервисов, а в некоторых случаях позволяет вообще не трогать сетевую инфраструктуру организации.
  • Во-вторых – что особенно актуально для небольших фирм – это позволяет экономить на оборудовании, т.к. снижаются объемы информации, хранимой в таблицах. Это происходит благодаря тому, что транзитным узлам не нужно ничего знать о маршрутах наложенной сети – адресации на хостах.

Рассмотрим основные подходы к построению оверлейных сетей в организации, сетевая инфраструктура которой опирается на несколько однотипных стоек с одинаковым серверным оборудованием, на котором запускаются виртуальные машины, контейнеры, реализующие сервисы и т.д. При таких исходных данных overlay-сеть обычно настраивается и поддерживается через центральный контроллер. С него конфигурация, Control Plane и Data Plane доставляются на устройства, которые занимаются маршрутизацией и инкапсуляцией клиентского трафика. Здесь можно выделить два принципиально отличающихся подхода к организации overlay-сети: overlay с ToR'a и overlay с хоста.

Overlay с ToR (Top of the Rack switch). Overlay может начинаться на коммутаторе доступа (ToR), стоящем в стойке, к которому подключены все физические машины, как это происходит, например, в случае VXLAN-фабрики. Это проверенный временем на сетях ISP механизм, который поддерживают практически все вендоры сетевого оборудования. Однако следует помнить, что в этом случае ToR-коммутатор должен уметь разделять различные сервисы, а сетевой администратор должен в известной степени сотрудничать с администраторами виртуальных машин и вносить изменения (пусть и автоматически) в конфигурацию устройств.

Overlay с хоста. Второй подход – запуск overlay и терминирование туннелей на конечных хостах, позволяющий физической underlay-сети оставаться максимально простой и статичной, что позволит минимизировать расходы на оборудование и снизить риски падения всей сети. При этом хост сам производит все необходимые инкапсуляции. Для этого неизбежно потребуется запускать специальное приложение на хостах.

Если сравнивать оба подхода, у обоих можно найти свои плюсы и минусы. Однако, по ряду причин, overlay с хоста в целом является более популярным. Во-первых, с ним проще запустить клиент на linux-машине, в то время как на коммутаторе ToR, скорее всего, придётся пока обращаться к проприетарным SDN-решениям, что делает бессмысленной идею мультивендорности, ключевую для виртуализации сетей. Во-вторых, ToR-коммутатор в этом случае можно оставить максимально простым, как с точки зрения Control Plane, так и Data Plane. Это обусловлено тем, что не нужно будет хранить ARP всех подключенных клиентов, коммутатору будет достаточно знать IP-адрес физической машины, что сильно уменьшит объемы таблиц коммутации/маршрутизации.

В следующей – заключительной – части цикла публикаций о виртуализации сетей мы опишем построение overlay-сети с хоста на примере опенсорсной SDN-платформы OpenContrail, известной также как Tungsten Fabric.

 
Поделитесь статьей в соцсетях   
 
Вам также может быть интересно
Как правильно спланировать аварийное восстановление: корректировка по потребности бизнеса
19 Сентября 2019
Читать
Как выбрать источник бесперебойного питания?
27 Июня 2019
Читать
Какими бесплатными утилитами облегчить работу сисадмина
15 Августа 2019
Читать

Comments System WIDGET PACK
Получите сервер
на тест-драйв
Оцените сочетание производительности и цены серверов от ittelo.ru
Соберем любую конфигурацию под ваши задачи и отправим вам на тестирование без предоплаты
После заявки:
  • Консультация
  • Бесплатная доставка
  • Тест-драйв у вас
  • Оплата
  • Гарантия 12 месяцев
Хотите проконсультироваться? С радостью ответим на ваши вопросы 8 800 551 80 12 или info@ittelo.ru
Товар добавлен в список сравнения
Перейти в сравнение
Продолжить просмотр