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

Виртуализация ресурсов информационных систем является главным драйвером изменения требований к сетевым инфраструктурам и катализатором появления новых технологий в этой области. В частности, для многих «продвинутых» функций виртуализации необходимо, чтобы между конечными узлами была реализована связность на втором уровне (L2) модели OSI. Например, таково условие для осуществления «живой» миграции виртуальных машин (функция VMotion в системе VMware), поддержка которой очень важна для повышения отказоустойчивости и оптимизации загрузки. Обеспечить это для территориально удаленных узлов, которые обычно связаны через сеть IP (L3), — задача непростая.

Наличие связности L2 означает, что узлы должны находиться в одной подсети, или в одном широковещательном домене. В «довиртуальную» эру такие домены формировали узлы, находящиеся в одном физическом сегменте локальной сети. Взаимодействие внутри сегмента обеспечивали обычные коммутаторы L2, а передача трафика между сегментами осуществлялась с помощью маршрутизатора (L3). Впоследствии для формирования множества доменов L2 в рамках одной физической локальной сети стала использоваться технология виртуальных локальных сетей (VLAN).

Главный недостаток этой технологии заключается в жестком ограничении на число виртуальных локальных сетей. Для идентификации таких сетей в теге, определенном стандартом IEEE 802.1q, выделено всего 12 бит, так что максимально возможное число VLAN составляет 4096. Представьте, что вы строите коммерческий ЦОД для предоставления облачных сервисов по модели IaaS. Если у вас будет 200 клиентов, а каждый захочет иметь 20 отдельных (виртуальных) сетей, то вы с трудом, но впишетесь в ограничения VLAN. Но обычно серьезные проекты рассчитываются на большее число клиентов, да и ограничивать их по числу виртуальных локальных сетей тоже не хочется. Простая математика показывает, что технология VLAN принципиально не позволит поддержать, скажем, три сотни клиентов с такими же запросами по числу виртуальных локальных сетей.

Одна из основных причин появления новых технологий виртуализации сетей связана именно с необходимостью устранения ограничений, накладываемых «старой доброй» VLAN. Таких технологий насчитывается около десятка, но основное внимание отрасли сосредоточено на трех: VXLAN, NVGRE и STT. В первых двух для идентификации виртуальных сетей выделяется поле из 24 бит (Virtual Network ID, VNID), что позволяет определить 16 млн сетей. Технология STT «идет еще дальше», предоставляя для тега VNID 32 бит.

Увеличение числа виртуальных сетей — далеко не единственная задача, которую призваны решить обсуждаемые технологии. Не менее важно повышение гибкости сетевых инфраструктур, в том числе за счет упрощения процесса их настройки и переконфигурирования. Возьмем уже упоминавшийся выше пример с «переездом» виртуальных машин. Для их нормальной работы на новом месте необходимо, чтобы коммутаторы, к которым подключены соответствующие серверы, имели ту же конфигурацию и поддерживали те же правила обработки трафика виртуальных машин, что и коммутаторы на старом месте. Решение этой задачи вручную — особенно в большой сети — требует больших затрат, в том числе временных. Кроме того, для развертывания новых сервисов может понадобиться перенастройка всех коммутаторов в сети, что еще больше растянет процесс и добавит головную боль администраторам.

Построение с помощью VXLAN, NVGRE или STT виртуальных сетей поверх IP-сетей (L3) обеспечивает связность L2 вне зависимости от физического места расположения узлов. Их функционирование не зависит от настроек физической инфраструктуры, что позволяет быстро внедрять и изменять сервисы без необходимости перенастраивать физические коммутаторы. Все нужные настройки осуществляются на уровне виртуальной инфраструктуры и не привязаны к таким коммутаторам.

«СЛОЕНЫЙ ПИРОГ»

Общий принцип построения наложенных виртуальных сетей един для всех технологий (VXLAN, NVGRE и STT). В соответствии с административными или иными правилами виртуальные машины приписываются к тем или иным виртуальным сетям, для определения которых используются свои идентификаторы — VNID. Машины, входящие в одну виртуальную сеть, могут быть разбросаны по разным физическим узлам, в том числе территориально удаленным. Для функционирования таких сетей достаточно наличия между ними связи по IP (см. Рисунок 1).

Рисунок 1. Общие принципы разделения трафика при формировании наложенных виртуальных сетей.

Для поддержки таких виртуальных сетей на каждом сервере должен присутствовать особый функциональный элемент — в англоязычной литературе его обычно называют Virtual End Point (VEP), — который обеспечивает упаковку и распаковку трафика. Как правило, этим занимается виртуальный (программный) коммутатор. Функционал VEP может быть реализован и на физическом коммутаторе (справа внизу на Рисунке 1), что позволяет включать в виртуальные сети физические устройства, подключенные к такому коммутатору. В зависимости от выбранной технологии упаковки и настроек, узлы, которые не содержат элементов с данным VNID, будут игнорировать пакеты с этим идентификатором или такой трафик вообще не будет доходить до них.

ЧТО ЗА «НАЧИНКА»

Подробный разбор организации наложенных виртуальных сетей начнем с VXLAN — технологии, которая благодаря активному маркетингу Cisco и VMware известна, пожалуй, лучше других. Итак, VXLAN предназначена для формирования больших изолированных сетей L2 в виртуализированных средах с множеством групп пользователей (multi-tenant). Основными сторонниками этой технологии считаются компании Cisco, VMware, Arista Networks, Broadcom, Citrix и Red Hat — по крайней мере, представители этих компаний являются авторами документа, где определяются основные механизмы VXLAN (он разработан в рамках рабочей группы Network Virtualization Overlays (NVO3) организации IETF). На момент написания статьи (март 2013 года) этот документ имел статус «экспериментальный» — Experimental.

Алгоритм VXLAN предусматривает, что весь кадр Ethernet (за исключением проверочной последовательности Frame Check Sequence, FCS) упаковывается в пакет UDP — см. Рисунок 2. Процедура инкапсуляции осуществляется в конечной точке туннеля — VXLAN Tunnel Endpoint (VTEP). Этот функциональный элемент, который может быть реализован как на виртуальном, так и на физическом коммутаторе, имеет два логических интерфейса: downlink и uplink.

Рисунок 2. Инкапсуляция VXLAN.

Чтобы разобраться в его работе, давайте предположим, что на вход этого элемента (то есть на интерфейс downlink) поступает кадр Ethernet, который следует на MAC-адрес 55:55:0С (здесь и далее для упрощения указаны сокращенные адреса) и принадлежит VLAN 111. Для начала выясняется, по какой сети VXLAN должен быть направлен кадр с указанным VLAN (см. Таблицу 1, а). Затем определяется IP-адрес точки на другом конце туннеля, по которому пойдет этот трафик (см. Таблицу 1, б). Этот адрес, вместе с другой необходимой информацией, вносится в добавляемые заголовки, после чего блок данных передается через интерфейс uplink.

Таблица 1. Примеры соответствия между VLAN и VXLAN (а), а также определение IP-адреса удаленной точки VTEP по МАС-адресу назначения (б).

Далее трафик пересылается через сеть IP в соответствии со стандартными процедурами маршрутизации. При этом начальная точка определяется по IP-адресу узла VTEP на одном конце туннеля, а конечная — по IP-адресу узла VTEP на другом конце туннеля (см. Рисунок 3). Там пакет распаковывается, внешняя (то есть используемая при передаче по туннелю VXLAN) адресная информация из него изымается, и мы получаем тот самый кадр Ethernet, который поступил на интерфейс downlink в исходной точке туннеля. Таким образом обеспечивается прозрачная передача трафика L2 через сеть L3 с изоляцией потоков данных каждой виртуальной сети VXLAN.

Рисунок 3. Пример передачи трафика по туннелю VXLAN.

Как быть, если исходный узел VTEP «не знает» того МАС-адреса, который указан в качестве адресата в поступившем кадре? В классических сетях Ethernet подобная задача решается просто и изящно: такой кадр направляется во все порты коммутатора (кроме того порта, откуда он поступил), ответный же кадр приходит только от узла-получателя, МАСадрес которого и заносится в таблицу. В технологии VXLAN применен очень похожий алгоритм, только кадр с адресом, отсутствующим в таблице узла VTEP в начальной точке туннеля, пересылается по всем адресам из многоадресной группы IP. (В идеале — для сокращения объема трафика — эта многоадресная группа должна быть ограничена только узлами VTEP, к которым подключены объекты данной сети VXLAN.) Тот узел VTEP, к которому подключена виртуальная машина с требуемым МАС-адресом, распаковывает пакет и направляет его по назначению, остальные узлы VTEP просто игнорируют прибывшие не по адресу пакеты (предварительно, если это необходимо, занеся в таблицы соответствие адресов МАС – VTEP). Получив ответный пакет, узел VTEP «узнает», по какому IP-адресу находится объект с ранее «незнакомым» ему МАС-адресом.

В технологии NVGRE подобный механизм «самообучения» не предусмотрен, и это одно из основных ее отличий от VXLAN. Решение задачи получения необходимых адресов возлагается на специальный контрольный протокол, который пока не определен. Он должен обеспечивать установление соответствия между IP-адресами внешней сети (согласно терминологии разработчиков NVGRE, это адреса провайдера — АП), которые привязаны к физической сетевой инфраструктуре и служат для передачи трафика по туннелям NVGRE, и IP-адресами клиента (АК). Последние используются для обслуживания клиентских сетей, которые виртуализуются и лишаются привязки к фактическим адресам и топологии базовой физической сети.

Для упаковки клиентских пакетов в технологии NVGRE задействуется хорошо известная процедура Generic Routing Encapsulation (GRE), а для идентификации виртуальных сетей — 24-разрядное поле Tenant Network Identifier (TNI), которое иногда называют ключом GRE. Процедура передачи трафика показана на Рисунке 4. Виртуальные машины клиента отправляют пакеты данных в пространстве АК, они упаковываются в новый пакет, заголовок которого снабжается необходимыми IP-адресами отправителя и получателя типа АП в дополнение к идентификатору виртуальной подсети (ключ GRE). Этот ключ позволяет узлам идентифицировать клиентскую виртуальную машину для каждого отдельного пакета даже в случае возможного совпадения адресов. Как отмечается в документах Microsoft, совместное использование АП (несколькими виртуальными машинами) положительно сказывается на масштабируемости сети, поскольку число IP- и MAC-адресов, которые сетевая инфраструктура должна «запомнить», может быть существенно снижено.

Рисунок 4. Пример передачи трафика по туннелю NVGRE.

Компания Microsoft — одна из главных движущих сил технологии NVGRE. Кроме того, в разработке документации на NVGRE в рамках организации IETF принимали участие эксперты из компаний Arista Networks, Intel, Dell, Hewlett-Packard, Broadcom, Emulex. Обратите внимание, что пересечение с «лагерем сторонников» VXLAN небольшое: только две компании — Arista и Broadcom — активно участвовали в разработке обеих технологий. Документ на NVGRE пока имеет статус «информационный» — Informational.

Такой же статус и у документа IETF, описывающего технологию STT. Ее разработала одна компания — Nicira, которая была приобретена VMware. Основные отличие STT от рассмотренных выше технологий — это больший размер тега (32 бита) для идентификации виртуальных сетей, а также возможность разгрузки центральных процессоров за счет использования в сетевых адаптерах алгоритмов наподобие Large Segment Offload (LSO). При наличии такого механизма стек TCP/ IP может не «загружать себя» нарезанием пакетов данных необходимого размера, а «спускать» их вниз большими порциями в виде гигантских (jumbo) кадров. «Нарезкой» займется сам адаптер NIC (см. Рисунок 5).

Рисунок 5. Различные варианты упаковки блоков данных при использовании стека TCP/IP: а — традиционный вариант, б — использование механизма LSO, в — использование LSO и добавление заголовка STT.

Типовые адаптеры NIC «умеют» сегментировать стандартные кадры TCP/IP/MAC, но они не смогут выполнить эту операцию для блоков, к которым добавлены заголовки VXLAN или NVGRE. Поэтому данные технологии при их программной реализации существенно увеличивают нагрузку на процессор. Для решения проблем производительности желательна их аппаратная поддержка в коммутаторах и/ или сетевых адаптерах. Для VXLAN такая поддержка обещана уже в скором времени.

Разработчики STT изначально стремились сделать так, чтобы программная реализация не приводила к серьезному снижению производительности сервера. Поэтому заголовок STT реализован «в стиле» TCP, сетевой адаптер «думает», что перед ним обычный пакет TCP, и выполняет стандартную процедуру LSO (см. Рисунок 5, в).

НОВЫЙ СЛОЙ — НОВЫЕ ПРОБЛЕМЫ

Любая дополнительная «упаковка» блоков данных чревата повышением накладных расходов. Одна часть таких расходов связана с повышением нагрузки на процессор, и ее мы уже обсудили выше, выяснив, что и NVGRE, и VXLAN существенно повышают такую нагрузку. Другая часть расходов обусловлена увеличением размера передаваемых по сети кадров. Скорости современных сетей достаточно высоки, чтобы «не заметить» нескольких дополнительных байтов. Но в результате кадр приобретает нестандартный размер, а значит, надо использовать jumbo-кадры или выполнять дополнительное фрагментирование.

Разработчики каждой из трех основных технологий организации туннелей по-разному подошли к решению этой проблемы. VXLAN ориентирована на использование в ЦОД, где поддержка jumbo-кадров — дело обычное, поэтому эта технология предполагает использование больших блоков данных. Системы NVGRE предусматривают применение механизмов определения максимально допустимого блока на пути передачи (Maximum Transmission Unit, MTU). Соответственно, там, где возможно, применяются jumbo-кадры, а там, где необходимо, — блоки стандартного размера. Наконец, STT полагается 58 Журнал сетевых решений/LAN http://www.lanmag.ru на сегментирование кадров адаптером NIC.

Другой блок проблем связан с тем, что исходный заголовок прячется «внутрь» пакета. Информацию из этого заголовка используют, например, балансировщики нагрузки, которые распределяют трафик по нескольким доступным путям передачи. «Не видя» этой информации, они не могут разделить трафик на потоки и осуществить балансировку. Для преодоления этой проблемы создатели VXLAN предусмотрели хэширование информации внутреннего заголовка и размещение его в поле, выделенном для указания протокольного порта UDP. В технологии STT и NVGRE подобный вариант не заложен. Разработчики NVGRE разве что рекомендуют использовать несколько IP-адресов для хоста, что позволяет разделить трафик на несколько потоков.

Информацию из основного заголовка используют и другие сетевые устройства, скажем межсетевые экраны. Согласно этой информации они выполняют необходимые операции по управлению трафиком и обеспечению политик безопасности. Если такой экран окажется на пути следования инкапсулированного трафика, администраторам придется изменить его настройки, чтобы он пропустил такой трафик.

При внедрении новых технологий виртуализации сети неизбежно встанет задача обеспечения взаимодействия с объектами, которые виртуализация не затрагивает. Это могут быть приложения СУБД, которые «не дружат» с виртуализацией и продолжают работать на обычных физических серверах, системы хранения или те же межсетевые экраны и балансировщики нагрузки. Кроме того, потребуется обеспечить взаимодействие виртуальных сетей, например VXLAN, с обычными сетями L3 через маршрутизаторы. В качестве интерфейса между VXLAN и объектами физических сетей можно использовать, в частности, продукт VMware vShield Edge. Производители встраивают подобный функционал и в традиционные сетевые устройства. Скажем, Brocade реализовала функции шлюза VXLAN в своих балансировщиках нагрузки ADX (см. Рисунок 6), а в самое ближайшее время такие функции появятся на ее коммутаторах VDX и маршрутизаторах MLX.

Рисунок 6. Схема взаимодействия виртуальных сетей VXLAN c объектами, подключенными к физической сети (в данном случае это сервер баз данных) через балансировщик нагрузки Brocade ADX.

ВМЕСТЕ ИЛИ ВРОЗЬ

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

Здесь примечательна позиция компании VMware, которая после покупки Nicira оказалась причастна к разработке сразу двух вариантов построения наложенных сетей — с использованием VXLAN и STT. Как отмечает Брюс Деви, один из создателей STT, для построения туннелей между гипервизорами, благодаря низкой нагрузке на процессор и ряду других преимуществ, эта технология может стать оптимальной. Однако для организации туннелей между гипервизорами и сетевыми устройствами, возможно, лучше подойдет VXLAN, поскольку она поддерживается большим числом производителей. Он предлагает рассматривать названные технологии как некие виртуальные кабели, обеспечивающие связность в виртуализированной среде (см. Рисунок 7).

Рисунок 7. Наложенные туннели можно представить как кабели для соединения объектов в виртуализированной среде. При этом в одной сети можно использовать разные туннели, например STT и VXLAN.

Подводя итог вышесказанному, еще раз подчеркну, что ни одна из рассмотренных технологий не является стандартизованной, а для производительной работы VXLAN и NVGRE желательна их аппаратная поддержка в сетевых адаптерах и/или коммутаторах. Эти обстоятельства могут сдерживать их внедрение. Вместе с тем задачи, которые требуют такого внедрения, уже настолько назрели (например, предоставление услуг IaaS), что компании готовы рискнуть, выступая в качестве пионеров реализации наложенных виртуальных сетей нового поколения. В этом случае важно понимать возможности и ограничения конкретной технологии, а также перспективы ее развития.

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