Как обеспечить контроль за трафиком между компонентами виртуализированного приложения с минимальными затратами по времени? Существует ли технология, которая позволяет передать трафик по цепочке через несколько сервисных компонент, например, межсетевой экран, пакетный фильтр и систему балансировки трафика, не внося изменений ни в настройку сети, ни в конфигурацию самих приложений? Под катом мы поговорим о технологии Cisco vPath, которая позволяет изящно создавать сервисные цепочки в средах виртуализации и не зависеть при этом от производителя гипервизора.
1. Формулировка задачи
Исходные данные:
- есть приложение, которое состоит из нескольких компонент, например, WEB, APP, DB;
- компоненты представляют собой виртуальные машины (VM) и находятся в пределах кластера из гипервизоров;
- все компоненты подключены к одному сетевому сегменту и используют один шлюз по умолчанию для общения со внешним миром.
Схема организации подключения к сети компонент приложения выглядит, как на Рис. 1.
Рис. 1 Логическая схема организации подключения приложения к сети
По умолчанию матрица взаимодействия между компонентами приложения и внешним миром выглядит так.
Рис. 2 Исходная матрица взаимодействия между компонентами приложения
Трафик, который передается между компонентами приложения, никак не контролируется – всем всё разрешено.
Постановка задачи в общем виде:
- не меняя конфигурации приложения предоставить возможность контролировать трафик между компонентами приложения;
- контроль предполагает возможность прозрачного встраивания сервисных элементов на пути передачи трафика между компонентами приложения;
- сервисный элемент может быть виртуальной машиной, которая выполняет пакетную фильтрацию, балансировку нагрузки, глубокую инспекцию на прикладном уровне, сжатие трафика, сетевой анализ трафика и т.д. и т.п.;
- ключевая часть задачи — сервисных элементов может быть несколько, а сложность встраивания не должна зависеть от их количества;
- должна иметься возможность выстраивать сервисные элементы в цепочки.
Пример реальной задачи № 1 – встраивание пакетного фильтра
Возможность контролировать трафик между приложениями дает сервисный элемент под названием пакетный фильтр, например Cisco VSG. Пакетный фильтр встраивается на пути передачи данных между виртуальными машинами. После встраивания фильтра матрица взаимодействия изменяется и выглядит следующим образом.
Рис. 3 Прозрачное встраивание пакетного фильтра
Примечание к Рис. 3: на рисунке изображены логические операции, которые выполняет пакетный фильтр. С этой задачей, в общем случае, может справится и одна виртуальная машина. Это примечание так же актуально для схем, которые приводятся ниже по тексту.
Что делает пакетный фильтр:
- разрешает входящий трафик от пользователей из сегмента outside только к WEB-компоненте приложения;
- трафик из сегмента outside к компонентам приложения APP и DB -запрещается;
- разрешается трафик между парами компонент WEB-APP и APP-DB по известным протоколам и портам;
- весь остальной трафик – запрещается.
Пример реальной задачи № 2 – создание сервисных цепочек
Исходя из опыта реальных проектов, зачастую владельцы приложений, сетевые администраторы и администраторы безопасности хотят от своей инфраструктуры большего, чем просто пакетная фильтрация. Постановка задачи близкая к той, с которой мы каждый день сталкиваемся в проектах, выглядит примерно так.
Рис. 4 Сервисные цепочки между компонентами приложения
Пользовательский трафик, предназначенный для WEB-компоненты приложения проходит через первую сервисную цепочку:
- сначала трафик должен попасть на балансировщик нагрузки, например Cisco Netscaler 1000V;
- затем пройти грубую очистку на пакетном фильтре;
- потом попасть на межсетевой экран для более тонкой очистки, например Cisco ASAv*;
- и только затем сбалансированный, очищенный и проинспектированный трафик должен быть передан на WEB-компоненту.
* Текущая версия ASAv 9.2(1) не имеет поддержки vPath. Ее реализация планируется в ближайшее время.
На пути трафика могут встречаться другие сервисные цепочки с другим набором и порядком сервисных компонент. В нашем примере вторая сервисная цепочка состоит из пакетного фильтра и межсетевого экрана.
2. Решение задачи традиционными методами
При создании сервисной цепочки традиционными методам проблема перенаправления трафика от одной сервисной компоненты к другой решается путем изменения топологии сети. Давайте посмотрим как можно решить только что расмотренную «Реальную задачу № 2». Между сервисными виртуальными машинами и приложением создается единственно возможный путь передачи данных см. Рис. 5.
Рис. 5 Создание сервисной цепочки путем изменения топологии
На физическом пути передачи трафика встраиваются сервисные компоненты. Любое логическое изменение в сервисной цепочке приводит к физическому изменению в топологии сети. Как видно из Рис. 5. вместо одного коммутатора и одного VLAN в исходной задаче мы имеем 2 логических коммутатора (inside/outside) и 9 VLAN. Вы можете самостоятельно вычислить во сколько раз возрастает сложность топологии при использовании традиционного топологического метода по сравнению с тем, что предлагает vPath. На месте VLAN могут быть VXLAN топологическая сложность от этого не уменьшается.
3. Главный вопрос статьи
Что же может предложить компания Cisco для облегчения процесса создания сервисных цепочек для приложений, которые виртуализированы? Как, не увеличивая сложность инфраструктуры, получить гибкий инструмент, не зависящий от гипервизора?
4. Главный ответ статьи
Компания Cisco предлагает использовать технологию vPath, которая обеспечивает изящное создание сервисных цепочек в виртуализированной среде. vPath является функцией распределенного виртуального коммутатора Cisco Nexus 1000V. Коммутатор Cisco Nexus1000V доступен сегодня для всех основных гипервизоров – Hyper-V, KVM*, vSphere. Давайте посмотрим на то, как архитектурно устроен vPath, как настраивается и как выглядит инкапсуляция.
* Первый релиз Nexus 1000V для KVM версии 5.2(1)SK1(2.2) не имеет поддержки vPath. Ее реализация планируется на последующие релизы.
5. Архитектура vPath
Для того, чтобы воспользоваться технологией vPath необходимы:
- виртуальный коммутатор Cisco Nexus 1000V;
- сервисная виртуальная машина, которая поддерживает vPath.
Давайте обратимся к исходной логической схеме организации сетевого подключения приложения, которая была представлена на Рис. 1. На Рис.6 отражены изменения, которые нужно внести при внедрения vPath.
Рис. 6 Основные архитектурные компоненты vPath
Что же поменялось?
- стандартный коммутатор, который «прилагается» к гипервизору, был заменен на коммутатор Nexus 1000V;
- виртуальные машины WEB, APP, DB мигрировали со стандартного коммутатора на Nexus 1000V;
- так же были добавлены сервисные виртуальные машины с поддержкой vPath, которые выполняют уже знакомые нам роли фильтрации, балансировки и межсетевого экранирования.
Можно добавить столько сервисных машин, сколько операций над трафиком необходимо выполнить, а можно обойтись одним пакетным фильтром, как мы уже видели в Примере реальной задачи № 1. В реальных сценариях наверняка будет происходить совмещение сервисных функций с целью уменьшения затрат и топологической сложности. Никаких дополнительных коммутаторов и новых VLAN/VXLAN не появилось. Топологически схема не поменялась.
Архитектура Nexus 1000V
Прежде, чем двигаться дальше и разобраться с тем, как устроен vPath давайте познакомимся с устройством коммутатора Nexus 1000V.
Рис. 7 Архитектура коммутатора Nexus 1000V
Nexus 1000V, как видно из Рис. 7, имеет две компоненты:
- модуль VEM (Virtual Ethernet Module) – программный код, который встраивается в гипервизор и обеспечивает коммутацию трафика;
- модуль VSM (Virtual Service Module) – компонента, которая обеспечивает централизованное управление и настройку VEM-модулей.
Nexus 1000V по своей архитектуре очень похож на физический модульный коммутатор, где VSM — играет роль супервизора (модуля управления), а VEM – исполняет роль линейной карты.
Все настройки интерфейса, который используется для подключения виртуальной машины к VEM модулю, хранятся в конструкции которая называется профиль порта – Port Profile.
Для демонстрации возможностей vPath воспользуемся Nexus 1000V, который развернут в нашей локальной лаборатории. Порты виртуальных машин в нашей лаборатории настроены следующим образом.
port-profile type vethernet V-CONT.WEB
switchport mode access
switchport access vlan 21
no shutdown
state enabled
port-profile type vethernet V-CONT.APP
switchport mode access
switchport access vlan 21
no shutdown
state enabled
port-profile type vethernet V-CONT.DB
switchport mode access
switchport access vlan 21
no shutdown
state enabled
Пока конфигурация всех портов идентична. Но поскольку для каждого из портов мы хотим реализовать свою сервисную цепочку, то мы настроили три разных профиля.
Основная идея vPath
Основная идея в том, чтобы создать механизм, который позволяет абстрагироваться от существующей топологии сети и пропустить трафик по нужным сервисным компонентам прозрачно и для сетевых устройств и для конечных виртуальных машин. Помните, что во всех наших исходных примерах виртуальные машины расположены в одном VLAN?
Как vPath это делает?
Модуль VEM ведет учет всех потоков данных, которые через него передаются. Эти данные собираются в таблице Flow Table. Поток идентифицируется по 6-ти сущностям: IP адрес источника, IP адрес получателя, порт источника, порт получателя, протокол, VLAN. Каждый раз когда в сети появляется новый поток, появляется новая запись в таблице потоков.
Рис. 8 Таблица потоков, передающихся через VEM модуль
Первый пакет каждого вновь детектированного потока отправляется на сервисное устройство. Таким образом VEM модуль «задает» сервисному устройству вопрос: можно ли мне его передавать дальше или нельзя? При пересылке пакета сервисному устройству к нему добавляется дополнительный заголовок с vPath инкапсуляцией.
Рис. 9 Логическая схема работы vPath
Сервисное устройство выполняет инспекцию пакета по правилам и политикам, которые были на нем настроены администратором безопасности, приложения или сети. Потом сервис возвращает VEM модулю исходный пакет так же с vPath инкапсуляцией, в которой содержится ответ – да, можно передавать пакет дальше, или — нет, этот пакет нужно отбросить, поскольку он, не удовлетворяет политике безопасности.
Модуль VEM получив пакет от сервисного устройства:
- записывает ответ в поле Action таблицы потоков;
- передает пакет в порт назначения без vPath-инкапсуляции, если в поле Action находилась команда Forward;
- продвигает пакет дальше по цепочке, используя vPath заголовок, если в поле Action находилась команда Redirect;
- отбрасывает пакет, если в поле Action находилась команда Drop.
Если природа сервиса не требует постоянной передачи данных через сервисный элемент, как например в случае пакетного фильтра Cisco VSG, то все последующие пакеты передаются минуя сервисный элемент, используя записанный в кеше ответ сервисного устройства.
Ниже приведен упрощенный алгоритм работы vPath для случая, когда между компонентами приложения нужно организовать пакетную фильтрацию.
Рис. 10 Алгоритм работы vPath для Cisco VSG
6. Настройка vPath
Теперь перейдем к практической настройке механизма vPath на нашем лабораторном стенде. У нас реализована следующая топология.
Рис. 11 Топология лабораторного стенда
Сначала регистрируем сервисные узлы, на которые будем перенаправлять трафик.
vservice node ASA-1 type asa
ip address 10.0.21.1
adjacency l2 vlan 21
fail-mode close
vservice node VSG-1 type vsg
ip address 10.0.21.254
adjacency l2 vlan 21
fail-mode close
Проверяем, что Nexus 1000V «видит» зарегистрированные модули и статус у них – Alive.
N1K# show vservice brief
--------------------------------------------------------------------------------
License Information
--------------------------------------------------------------------------------
Type In-Use-Lic-Count UnLicensed-Mod
asa 2
--------------------------------------------------------------------------------
Node Information
--------------------------------------------------------------------------------
ID Name Type IP-Address Mode State Module
1 VSG-1 vsg 10.0.21.254 v-21 Alive 4,
2 ASA-1 asa 10.0.21.1 v-21 Alive 4,
<часть вывода опущена>
Создаем сервисную цепочку из 2-х зарегистрированных ранее модулей.
vservice path WEB-CHAIN
node VSG-1 profile WEB_SP order 1
node ASA-1 profile TEST-EDGE-SP order 3
Проверяем, что Nexus 1000V «видит» сервисную цепочку.
N1K# show vservice brief
<часть вывода опущена>
--------------------------------------------------------------------------------
Path Information
--------------------------------------------------------------------------------
Name:WEB-CHAIN NumOfSvc:2 Mod:4,
Node Order Profile
VSG-1 1 WEB_SP
ASA-1 3 TEST-EDGE-SP
--------------------------------------------------------------------------------
<часть вывода опущена>
Подключаем сервисную цепочку, которая состоит из ASA и VSG к профилю, определяющему подключение виртуальной машины WEB к сети.
port-profile type vethernet V-CONT.WEB
org root/tenant-01
vservice path WEB-CHAIN
Проверяем, что Nexus 1000V «видит» настроенную цепочку.
N1K# show vservice brief
<часть вывода опущена>
--------------------------------------------------------------------------------
Port Information
--------------------------------------------------------------------------------
PortProfile:V-CONT.WEB
Org:root/tenant-01
Path:WEB-CHAIN
Node Profile(Id)
VSG-1(10.0.21.254) WEB_SP(9)
ASA-1(10.0.21.1) TEST-EDGE-SP(8)
Veth Mod VM-Name vNIC IP-Address
15 4 r1-web-v2 1 10.0.21.10
<часть вывода опущена>
Теперь сделаем так, чтобы трафик, который передается в сторону виртуальных машин APP и DB, передавался через пакетный фильтр.
port-profile type vethernet V-CONT.APP
org root/tenant-01
vservice node VSG-1 profile APP_SP
port-profile type vethernet V-CONT.DB
org root/tenant-01
vservice node VSG-1 profile DB_SP
В итоге, при помощи нескольких строк конфигурации в лаборатории была реализована следующая схема передачи трафика внутри VLAN=21. При этом мы не создавали новых вспомогательных коммутаторов или VLAN. На Рис. 12 изображена сервисная цепочка, которая получилась.
Рис. 12 Сервисная цепочка настроенная в примере
Как видно из представленной конфигурации она крайне проста по сравнению с теми изменениями, которые пришлось бы вносить, если бы потребовалось изменить топологию сети для вписывания в нее сервисных элементов. Еще раз подчеркнем — исходная топология не изменилась.
7. vPath инкапсуляция
vPath упаковывает исходные пакеты в свой заголовок следующим образом.
Рис. 13 vPath инкапсуляция
В случае, если сервисная виртуальная машина располагается в том же сегменте, то к исходному пакету добавляется транспортный L2 заголовок. Если сервисная машина располагается в другом сегменте, то добавляется транспортный L3 заголовок. Тело исходного кадра не меняется. Между транспортным заголовком и исходным пакетом находится vPath заголовок.
vPath заголовок состоит из 3-х обязательных компонент:
- базовый заголовок;
- сервисный заголовок;
- платформенный заголовок.
Рис. 14 vPath заголовок
Базовый заголовок:
- содержит версию протокола и идентификатор сервисной цепочки.
Нужно отметить, что сама сервисная цепочка в заголовок не включается. Там присутствует только ее уникальный идентификатор. Информация о цепочке хранится в специальной таблице Service Table, которая так же как и FlowTable есть на каждом VEM–модуле. Программирование этой таблицы происходит централизованно с VSM–модуля, когда владелец системы вносит изменения в конфигурацию.
Сервисный заголовок:
- реализует процедуру согласования используемой версии vPath;
- переносит информацию об идентификаторах профилей на сервисных устройствах;
- реализует процедуру Запрос/Ответ между VEM модулем и сервисным устройством.
Платформенный заголовок:
- переносит информацию специфичную для платформы, которая реализует vPath;
- содержит идентификатор порта источника;
- содержит идентификатор типа сегмента – VLAN, VXLAN;
- содержит идентификатор сегмента – номер VLAN, номер VXLAN.
Вот так выглядит пакет, который VEM модуль получил от виртуальной машины и перенаправляет на сервисный модуль. Последний должен принять решение – можно или нельзя этот пакет передавать по сервисной цепочке дальше. В сервисном заголовке мы видим, что выполняется функция REDIRECT. Сервисный модуль подключен к VEM модулю по L2.
Рис. 15 Пакет, который VEM передает на сервисный модуль
Следующий снимок экрана представляет собой пакет, который VEM модуль получил от сервисного модуля после инспекции пакета. Поле Service Context Header содержит идентификатор RESPONSE, а в поле ACTION установлено значение PERMIT, означающее, что этот пакет можно передавать дальше.
Рис. 16 Пакет, который VEM получает от сервисного модуля после инспекции
8. Выводы
В статье мы обсудили проблему создания сервисных цепочек в ЦОД. Большое количество владельцев виртуализированной инфраструктуру сталкивается с этой проблемой при развертывании приложений. Решение проблемы путем изменения топологии сети для вписывания сервисных устройств проводит к усложнению конфигурации сети. Мы же познакомились с легким способом решения этой проблемы при помощи разворачивания коммутатора Nexus 1000V и задействования технологии vPath, которая настраивается несколькими простыми командами.
Автор: khavankin
