Как виртуализировать сеть: часть третья, построение наложенных виртуальных сетей
Наши предыдущие статьи в цикле о виртуализации сетей, преимущественно концентрировались на теоретических аспектах этого метода объединения сетевых ресурсов, а также инструментах аппаратной виртуализации. В этой же публикации мы обратимся к практическим аспектам виртуализации, рассмотрев преимущества и недостатки двух основных подходов к построению наложенных виртуальных сетей.
Помимо расширения возможностей удаленного доступа важнейшей причиной виртуализации сети для небольшой или средней организации является сетевая автоматизация, повышающая отказоустойчивость. Как правило речь здесь идет о 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.
