Сеть и виртуализация. Часть I

Проанализировав в двух предыдущих номерах «Журнала сетевых решений/LAN» концепции централизованно программируемых сетей SDN и коммутирующих «фабрик», переходим к третьей составляющей «революции» в области сетевых инфраструктур, источником которой стала потребность в поддержке виртуализации ИТ-ресурсов. В этом номере мы поговорим о различных способах коммутации трафика виртуальных машин, а в следующем — об организации наложенных виртуальных сетей. Помимо рассмотрения соответствующих технологий, обсудим их связь с SDN и «фабриками».

С внедрением технологий виртуализации и появлением виртуальных машин возникла очевидная потребность в коммутации трафика между ними. С этой целью были разработаны виртуальные коммутаторы, такие как VMware vSwitch или Cisco Nexus 1000V — в англоязычной литературе их обычно называют Virtual Embedded (или Ethernet) Bridge (VEB). По своему функционалу они соответствуют обычным коммутаторам Ethernet, только выполнены программно на уровне гипервизора. Трафик между виртуальными машинами в рамках «своего» сервера коммутируется локально, не выходя за его пределы (см. Рисунок 1). А прочий трафик (с внешними МАС-адресами) — направляется во внешнюю сеть.

Рисунок 1. Коммутация трафика виртуальных машин внутри сервера (VEB) и вынос этого процесса во внешний коммутатор (VEPA).

Виртуальные коммутаторы могут быть модульными, как, например, уже упомянутый Cisco Nexus 1000V. Он состоит из двух основных компонент: модуль Virtual Ethernet Module (VEM) функционирует на базе гипервизора и отвечает за коммутацию трафика виртуальных машин, а модуль управления Virtual Supervisor Module (VSM) может быть установлен на внешнем сервере. Один коммутатор Nexus 1000V способен поддерживать множество модулей VEM на физических серверах. А для управления всем этим хозяйством (решения задач конфигурирования, мониторинга, диагностики и пр.) достаточно одного модуля VSM. По сути, все как в обычном модульном устройстве: VEM — это аналог линейной карты, а VSM — платы управления.

У виртуальных коммутаторов VEB есть свои преимущества: локальная коммутация трафика внутри сервера не приводит к какой-либо дополнительной нагрузке на сеть, к тому же для реализации такой коммутации не требуется внешнее оборудование. Данное решение отличается невысокой стоимостью и обеспечивает малое значение задержки. Но у него есть и серьезные минусы: к виртуальным коммутаторам далеко не всегда применимы традиционные приемы конфигурирования и управления, а курсирующий через них трафик невозможно отследить обычными средствами мониторинга. Такие коммутаторы часто находятся в ведении специалистов, отвечающих за серверы, тогда как за все остальные (аппаратные) коммутаторы отвечают сетевые администраторы, что создает проблемы для целостного управления всей сетью. Кроме того, поддержка работы виртуальных коммутаторов означает дополнительную загрузку процессоров сервера.

Другой подход к коммутации трафика виртуальных машин состоит в выносе этого процесса во внешние коммутаторы. Для его реализации были разработаны несколько технологий, две основные описаны в документах IEEE 802.1Qbg (Edge Virtual Bridging) и 802.1BR (Bridge Port Extension), которые на данный момент находятся в финальной стадии утверждения. Разработка первой из указанных технологий, в основу которой положен механизм Virtual Ethernet Port Aggregator (VEPA), была инициирована компанией HP. Технология 802.1BR родилась в Cisco Systems. Изначально ее стандартизацией занималась группа 802.1Qbh, но потом было решено выделить эту технологию в отдельный стандарт 802.1BR, дабы дистанцировать ее от стандартов серии 802.1Q, «отвечающих» за тегирование трафика Ethernet.

ТЕХНОЛОГИЯ VEPA: ВОЗМОЖНЫ ВАРИАНТЫ

Базовый вариант технологии VEPA (Standard Mode) прост в реализации. При небольшой модернизации гипервизора весь трафик будет направляться наружу вне зависимости от MAC-адреса назначения. А от внешнего коммутатора требуется направлять обратно (немыслимая операция для традиционного моста/коммутатора Ethernet!) кадры с МАС-адресом назначения, принадлежащим виртуальной машине, которая находится на том же физическом сервере, что и отправитель. Реализация этой функции обеспечивается простым обновлением микропрограммного кода коммутатора. При этом весь трафик — даже если его отправитель и получатель находятся на одном сервере — будет проходить через внешний коммутатор (см. Рисунок 1).

Этот вариант позволяет использовать отработанные годами методики и инструменты для мониторинга трафика и управления им. Он также дает возможность задействовать весь развитый функционал современных коммутаторов для обработки трафика — например, применять к нему заданные политики обеспечения безопасности, правила гарантированного качества обслуживания (QoS) и пр. Но трафик приходится «гонять порожняком» через сеть, даже если исходная и конечная точки его маршрута находятся на одном сервере. Это повышает временную задержку и увеличивает требования к пропускной способности каналов связи. С одной стороны, вычислительные ресурсы сервера освобождаются от задач по мониторингу трафика и его обработке, но с другой — серверу приходится дважды пропускать трафик через гипервизор.

Наряду с базовым вариантом в документах IEEE 802.1Qbg описан и другой вариант — многоканальный (Multichannel VEPA), который предоставляет ряд дополнительных возможностей. В этом случае один физический канал Ethernet делится на несколько виртуальных каналов, или туннелей. Они обеспечивают независимое подключение к сети различных объектов внутри сервера: это может быть виртуальный коммутатор VEB, VEPA или непосредственно виртуальная машина. Для формирования туннелей используется хорошо известный механизм Q-in-Q (стандарт IEEE 802.1ad), который предусматривает добавление к кадру сервисного тега (S-Tag). При этом сохраняется тег, определяющий принадлежность кадра к той или иной сети VLAN (802.1q). Для реализации многоканального режима VEPA, очевидно, необходимо, чтобы внешний коммутатор поддерживал механизм Q-in-Q.

Благодаря многоканальному режиму, архитекторы сетей получают большую гибкость для выбора оптимального механизма. Скажем, для снижения задержки при взаимодействии между виртуальными машинами, находящимися на одном сервере, можно использовать виртуальный коммутатор VEB, а для повышения уровня управляемости — режим VEPA. И все в рамках одного физического соединения (см. Рисунок 2).

Рисунок 2. Многоканальный режим работы VEPA.

802.1BR И ВЫНОСЫ ПОРТОВ

Предложенная Cisco технология VN-Tag, которая положена в основу стандарта IEEE 802.1BR, предполагает вынос (extender) портов коммутатора. Они (выносы) могут быть реализованы на базе отдельных сетевых элементов (например, устройств Nexus 2000 или сетевых модулей для блейд-серверов Cisco UCS), в сетевых адаптерах серверов и даже на уровне подключений виртуальных машин (технология VM-FEX).

Это означает проникновение сети «внутрь» сервера и включение в единую плоскость коммутации не только портов коммутаторов, но также серверных адаптеров и виртуальных машин. Управление коммутаторами вместе с выносами осуществляется как одним устройством, а добавление выносов, по сути, аналогично установке линейных карт в обычный модульный коммутатор.

Технология VN-Tag предусматривает добавление в кадры тега с одноименным названием. Главными компонентами этого тега являются поля с идентификаторами виртуальных интерфейсов (VIF) отправителя и получателя. Такие интерфейсы могут идентифицировать разные объекты, например виртуальные сетевые адаптеры (vNIC) виртуальных машин. На одном физическом порту может быть сформировано несколько виртуальных интерфейсов. Они становятся частью распределенного коммутатора, а потому трафик между такими интерфейсами (значит, и между виртуальными машинами) пойдет через его основной блок.

Технологию VN-Tag можно использовать как для выноса портов (по сути, для формирования распределенной коммутационной фабрики, в состав которой включаются виртуальные машины), так и для вывода трафика виртуальных машин в сеть. Важный плюс этой технологии — возможность конфигурировать каждый индивидуальный виртуальный интерфейс так, как будто это обычный физический порт. Главный недостаток — необходимость введения дополнительных полей в кадр Ethernet, что может потребовать аппаратной модернизации продуктов.

В ДЕЛО ВСТУПАЮТ АДАПТЕРЫ

В качестве примера реализации технологии VN-Tag рассмотрим так называемые виртуальные интерфейсные карты (Virtual Interface Card, VIC) компании Cisco.

Рисунок 3. Пример реализации технологии VN-Tag с использованием виртуальных интерфейсных карт (Virtual Interface Card, VIC) компании Cisco.

Рисунок 4. Различные режимы взаимодействия между виртуальными интерфейсами vNIC и виртуальными машинами при использовании виртуальных интерфейсных карт (Virtual Interface Card, VIC) компании Cisco.

Пусть вас не смущает название: на самом деле это вполне реальный сетевой адаптер с портами 10 GbE и поддержкой технологии FCoE, но специально подготовленный к работе в виртуализированных средах. На его базе могут быть сформированы до 256 виртуальных интерфейсов vNIC, которые, согласно концепции выносов, становятся логическим продолжением внешнего коммутатора Ethernet. В результате каждой виртуальной машине выделяется виртуальный порт на физическом коммутаторе (см. Рисунок 3), который берет на себя заботу не только о коммутации трафика, но и о соблюдении установленных правил безопасности, качества обслуживания и пр.

Поддержка продуктами VIC технологии VMware VMDirectPath позволяет существенно повысить производительность и снизить задержку сетевого взаимодействия виртуальных машин. Она делает возможным прямое взаимодействие между виртуальными интерфейсами vNIC и виртуальными машинами в обход гипервизора (см. Рисунок 4). При необходимости можно использовать механизм VMware VMotion, например, для динамического распределения нагрузки.

Рисунок 5. Различные варианты коммутации трафика виртуальных машин при использовании адаптера Brocade Fabric Adapter (FA) 1860.

Сетевые адаптеры нового поколения, оптимизированные для работы в виртуализированных средах, могут не только направлять трафик виртуальных машин во внешнюю сеть, но и самостоятельно его коммутировать. Примером такого продукта служит адаптер Brocade Fabric Adapter (FA) 1860, который содержит один или два физических порта: 10 Гбит/с (Ethernet, FCoE) или 16 Гбит/с (Fibre Channel). При использовании этого адаптера возможны три варианта коммутации трафика виртуальных машин (см. Рисунок 5). Первые два — это уже рассмотренные нами локальная коммутация силами виртуального коммутатора (адаптер FA 1860 в данном случае вообще не задействуется) и вынос коммутации во внешнюю сеть с применением технологии VEPA. Третий вариант в Brocade называют аппаратным виртуальным коммутатором (Hardware Based VEB).

При использовании этого варианта весь трафик от виртуальных машин направляется на локальный сетевой адаптер для коммутации: если трафик предназначен для виртуальной машины, находящейся на том же сервере, он направляется обратно гипервизору, если нет — уходит в сеть. Данный вариант коммутации использует стандартный формат кадра Ethernet. К преимуществам технологии Hardware Based VEB специалисты Brocade относят низкую загрузку процессора сервера, а также возможность (правда, лишь частичную) для настройки политик безопасности и использования механизма качества обслуживания (QoS), к недостаткам — ограничения по управлению трафиком.

Рисунок 6. Технология виртуализации PCI-устройств Single-Root I/O Virtualization (SR-IOV).

Второй и третий варианты в решении Brocade основаны на использовании технологии виртуализации PCI-устройств Single-Root I/O Virtualization (SR-IOV), разработанной группой специалистов PCI Special Interest Group. Эта технология вводит понятие «виртуальной функции» — Virtual Function (VF) и позволяет разделять сетевое устройство PCI на несколько виртуальных экземпляров, которые будут работать непосредственно с виртуальными машинами (см. Рисунок 6). Например, при использовании метода разделения ресурсов SR-IOV в рамках одного физического адаптера FA 1860 может быть создано 255 виртуальных экземпляров. К сожалению, как отмечают специалисты Brocade, технология SR-IOV имеет свои ограничения: в текущей спецификации предусматривается только передача входящего/ исходящего трафика виртуальных машин, а локальная коммутация осуществляется программным коммутатором гипервизора. Кроме того, виртуальный экземпляр адаптера VF не может вести себя как полноценный физический PCI-адаптер и поэтому требуется дополнительная инсталляция драйверов для гипервизора операционной системы VMware ESX и Microsoft HyperV, а также для BIOS серверов. Такая поддержка только планируется производителями этих операционных систем, что затрудняет применение методов Hardware Based VEB и VEPA.

Компания Brocade предлагает и свою фирменную технологию логического разделения ресурсов адаптера FA 1860 (пропускной способности порта и внутренней шины PCI) — vFLink, причем она не требует дополнительной установки драйверов для операционной системы VMware ESX и Microsoft Hyper-V. В режиме работы CNA на одном порту 10 GbE можно организовать до 8 независимых логических сетевых адаптеров и до 16 при использовании двух портов — в любой комбинации vNIC и vHBA. Общая пропускная способность (10 Гбит/с для портов Ethernet и 16 Гбит/с для портов Fibre Channel) может быть распределена между виртуальными адаптерами с шагом 100 Мбит/с.

ВИРТУАЛЬНЫЕ И (ИЛИ) ФИЗИЧЕСКИЕ

Многие эксперты считают наиболее перспективными технологии наподобие VEPA, когда сетевое взаимодействие между виртуальными машинами выводится в физическую сеть. Однако ряд причин, в том числе уже упомянутая задержка с выходом необходимых для механизма SR-IOV драйверов для популярных гипервизоров, осложняют реализацию этих технологий. Собственно, с точки зрения разработчиков сред виртуализации вполне логично выглядит отсутствие у них большого энтузиазма по созданию инструментов, которые позволят вывести из-под их контроля такой важный процесс, как взаимодействие виртуальных машин.

В этой связи показательна позиция Cisco. Продвигая технологию 802.1BR с целью обеспечить «проникновение» сети вглубь сервера, она не менее активно развивает и свой виртуальный коммутатор Nexus 1000V, который выполняет локальную коммутацию трафика виртуальных машин внутри сервера. Правда, при этом функции управления этим процессом — модуль Virtual Supervisor Module (VSM) — выносятся вовне. Это вам ничего не напоминает? Конечно, это не что иное, как реализация идей SDN: обработка трафика отделяется от управления этим процессом (подробнее см. статью «SDN: кому и зачем это надо?» в декабрьском номере «Журнала сетевых решений/LAN» за 2012 год). В полном соответствии с этим принципом построено и решение по виртуализации сети компании Nicira, причем оно ориентировано на использование программных коммутаторов (Open vSwitch). Именно ради этого решения, а не каких-то агентов OpenFlow, на мой взгляд, эта компания и была приобретена VMware.

И программные (виртуальные), и физические коммутаторы станут играть важную роль в процессе построения сетей нового поколения, где требуется обеспечить эффективную поддержку виртуальных машин. Причем преимущество получат те продукты, которые позволят включить сетевые объекты обоих типов в единую коммутационную среду. И совсем будет замечательно, если эта среда окажется построена по принципам «фабрики», то есть с минимумом иерархических уровней (в идеале — связь по принципу «каждый с каждым»), поддержкой всех линий связи в активном состоянии с обеспечением низкой задержки и отсутствием точек общесистемного отказа.

Александр Барсков — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: ab@lanmag.ru.