Упростить и виртуализировать

Трудно вспомнить другой период времени, столь насыщенный подобными заявлениями. Итак:

• 19 апреля Extreme Networks представила новую архитектуру Direct Attach для ЦОД;
• 17 мая Juniper Networks анонсировала модель трансформации архитектуры ЦОД «3-2-1»;
• 2 июня Force10 объявила о выпуске «первого коммутатора для динамических виртуализированных ЦОД»;
• 9 июня Brocade познакомила ИТ-общественность с архитектурой Brocade One;
• 14 июня Enterasys сообщила о разработке «вендоро-агностической» стратегии ЦОД.

Активное обсуждение последних тенденций в области сетевой инфраструктуры ЦОД происходит не только за океаном. На состоявшемся 1–2 июня в Москве форуме «Мир ЦОД» российские специалисты с большим интересом выслушали сотрудников компаний Cisco и Extreme Networks, представивших во всех подробностях свои новые подходы. Насколько нам известно, Cisco первой выработала «рецепты» решения ключевых инфраструктурных задач ЦОД (подробнее см. статью автора в майском номере журнала) и потому не вошла в число ньюсмейкеров весны – лета 2010 года.

«3-2-1»

Пожалуй, название стратегии Juniper весьма точно определяет наметившуюся в отрасли тенденцию к упрощению структуры сетей ЦОД путем сокращения числа уровней с трех (ядро, агрегация, доступ) до двух, а в перспективе и к переходу к одноуровневой (плоской) сети. На первом этапе специалисты этой компании предлагают отказаться от уровня агрегации, наличие которого значительно усложняет сети ЦОД. По их данным, это позволит на 99% (!) уменьшить число взаимодействий между коммутаторами, а также на 77% сократить задержку трафика — по сравнению с традиционными трехуровневыми сетями.

Один из вариантов решения этой задачи — использование технологии «виртуального шасси» (Virtual Chassis), с помощью которой до 10 коммутаторов Juniper EX4200 можно объединить в логически единое сетевое устройство, поддерживающее до 480 портов. Планируется, что в начале 2011 года данная технология будет реализована и в EX4500 — 10-гигабитном решении, которое было представлено компанией одновременно со стратегией «3-2-1». Обещано, что новинка будет также поддерживать технологию FCoE и необходимые для нее алгоритмы работы Ethernet без потерь кадров — Lossless Ethernet, или Converged Enhanced Ethernet (CEE).

В ближайшем будущем Juniper намерена представить решения для одноуровневой сети (проект Stratus), где коммутаторы будут взаимодействовать по принципу «каждый с каждым». В такой сети задержка трафика минимальна. Следует отметить, что в поддержку инициативы «3-2-1» выступили такие партнеры компании Juniper, как IBM и Dell.

Brocade в рамках своей новой архитектуры Brocade One анонсировала технологию Virtual Cluster Switching (VCS), которая «нацелена на преодоление известных проблем традиционной технологии Ethernet и построение инфраструктур виртуализированных ЦОД». По утверждению представителей компании, объединенные в инфраструктуру VCS коммутаторы выглядят для серверов и остальной части сети как логически единый коммутатор. Для поддержки множества путей передачи трафика VCS использует находящийся в стадии принятия стандарт Transparent Interconnection of Lots of Links (TRILL), который, в отличие от протоколов STP, позволяет поддерживать в активном состоянии все сетевые маршруты. При этом добавление, удаление или выход из строя каналов связи не приводят к остановке всего трафика, а маршрутизация в обход отказавшего участка не требует перестройки всей логической структуры сети. Управление коммутаторами, объединенными с использованием технологии VCS, осуществляется как единым логическим шасси. При использовании VCS отдельный уровень агрегации не требуется, поскольку все свойственные этому уровню функции выполняются в инфраструктуре VCS. Появление продуктов на базе VCS, которые также будут поддерживать технологии Lossless Ethernet (в Brocade используют термин Data Center Bridging, DCB), намечено на начало 2011 года.

Сократить число уровней в архитектуре сети рекомендуют и другие производители. Это можно делать как за счет исключения уровня доступа и подключения серверов непосредственно к агрегирующим коммутаторам, устанавливаемым в конце ряда стоек (End of Row, EoR), так и за счет исключения уровня агрегации и подключения коммутаторов доступа прямо к ядру сети. В последнем случае функции агрегации реализуются с помощью различных технологий, обеспечивающих объединение коммутаторов, установленных в верхней части стоек (Top of Rack, ToR), в горизонтальный стек или в виртуальное шасси (см. Рисунок 1). Этот вариант приобретает все большую популярность, поскольку, помимо всего прочего, позволяет существенно упростить кабельную инфраструктуру (сократить длину кабелей).

Те или иные варианты построения горизонтальных стеков из коммутаторов ToR сегодня предлагают многие поставщики: Enterasys, Extreme Networks, Force 10 и др. Для объединения коммутаторов могут использоваться как стандартные каналы (гигабитные или 10 Гбит/с), так и специальные стековые кабели. В последнем случае скорости внутристековых соединений могут быть очень велики — например, коммутаторы Summit компании Extreme Networks можно связать каналами на 512 Гбит/с.

Сетевое подразделение компании HP сейчас располагает мощной технологией Intelligent Resilient Framework (IRF), которая изначально была разработана 3Com и позволяет осуществлять горизонтальную интеграцию коммутаторов уровня доступа (IRF может применяться и на уровне агрегации, и в ядре сети). Суть также заключается в объединении нескольких физических коммутаторов в логически единую отказоустойчивую матрицу коммутации. В такую матрицу может быть собрано до 9 устройств, а пропускная способность соединяющих их каналов доходить до 120 Гбит/с (12×10GE). Хотя HP и не делала в последнее время громких заявлений по поводу стратегии упрощения архитектуры сети ЦОД, технология IRF позволяет эффективно решать эту задачу.

Безусловно, упрощению сетевой архитектуры способствуют вынос функций программных коммутаторов из сервера и перенос их на обычные аппаратные коммутаторы. Но об этом мы поговорим ниже.

КОГДА ВМ «МНОЖАТСЯ» И «ПЕРЕЕЗЖАЮТ»

Внедрение технологий виртуализации привело к тому, что к сетевой инфраструктуре стало предъявляться множество новых требований, связанных с обеспечением безопасности, масштабируемости, управляемости, да и просто с обычной коммутацией трафика. Взять, например, масштабируемость. Трафик определенного приложения обычно приписывается к «своей» виртуальной локальной сети (VLAN). С увеличением числа виртуальных машин (ВМ) и частоты их миграции в сети необходимо поддерживать больше сетей VLAN и связанных с ними таблиц (в которых указываются параметры безопасности, качества обслуживания и т. д.).

При переезде ВМ с одного сервера на другой необходимо сохранить ее принадлежность данной VLAN, а оба сервера должны находиться в рамках одного домена, связь в котором осуществляется на втором уровне (Layer 2). Если ВМ перемещается между территориально удаленными ЦОД, значит связь на втором уровне надо обеспечить и в данном случае, что оказывается совсем не просто, поскольку в глобальной сети трафик обычно маршрутизируется (операция на третьем уровне, Layer 3).

Еще одна проблема, возникающая вследствие виртуализации, — увеличение нагрузки на подсистему ввода/вывода серверов при увеличении числа ВМ (и приложений), работающих на одном физическом сервере. Поэтому со всей остротой встает вопрос о консолидации нескольких виртуальных адаптеров (NIC) на одном физическом, имеющем высокоскоростной порт 10 Гбит/с.

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

Для преодоления ограничений встроенных программных коммутаторов предлагается немало способов. Один из них — использование технологии Virtual Ethernet Port Aggregator (VEPA), о поддержке которой заявили компании Brocade, Enterasys, Extreme Networks, HP, Juniper Networks и др. (см. Рисунок 2).

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

Как отмечают сторонники VEPA, внедрение этой технологии не потребует замены существующей инфраструктуры, а сведется лишь к обновлению програм-много кода коммутаторов (см. Таблицу 1). Вынос процедур коммутации за пределы сервера позволит повысить их производительность и число поддерживаемых ВМ. Поскольку VEPA продвигается как открытый стандарт (IEEE 802.1Qbg), она независима от специфики используемых серверов и гипервизоров, что повышает свободу маневра заказчиков.

Возможность миграции на технологию VEPA (после принятия соответствующего стандарта) предусмотрена в архитектуре «прямого подключения» (Direct Attach) компании Extreme Networks. Как подчеркивает производитель, эта архитектура позволяет подключать ВМ напрямую к сети, без необходимости коммутации на уровне серверного ПО, что облегчает управление, мониторинг и поиск неисправностей. Функция «прямого подключения» появится, как ожидается, в III квартале 2010 года, она будет реализована с помощью лицензируемого модуля операционной системы коммутаторов. Предполагается, что стоимость лицензии составит около 1000 долларов за один коммутатор.

Разработанная Brocade технология Virtual Access Layer (VAL) виртуализирует подсистему ввода/вывода сервера и физические соединения на уровне доступа к сети (см. Рисунок 3). При этом виртуальное соединение VALink может быть ассоциировано с виртуальным адаптером (NIC или HBA), созданным на физическом адаптере CNA. Такое соединение, между адаптером CNA и ближайшим коммутатором, логически изолировано и привязано к конкретной виртуальной машине (или некоторому классу ВМ). При этом можно продолжить использование программного коммутатора на базе гипервизора (через такой коммутатор проходят соединения от ВМ1 и ВМ2, см. Рисунок 3), а можно функции ввода/вывода реализовать напрямую между ВМ и виртуальным адаптером (ВМ3 на Рисунке 3). При переезде ВМ на другой физический сервер ее ассоциация с VALink сохраняется, что позволяет поддерживать приписанные к ней настройки сетевых параметров и безопасности.

Что касается коммутации трафика между ВМ, то эксперты Brocade полагают, что место ее выполнения зависит от специфики задачи (см. Рисунок 4). Так, в крупной сети со сложными правилами контроля доступа и QoS определенные преимущества дает «возложение обязанности» по коммутации трафика на внешние коммутаторы с поддержкой VEPA. Коммутация на уровне адаптера (с функциями Virtual Ethernet Bridging, VEB) снижает задержку при передаче трафика (поскольку он не покидает сервер), что важно для достижения высокой производительности вычислений. Наконец, в небольших виртуализированных средах может оказаться вполне достаточно функционала программных коммутаторов, встроенных в гипервизоры. В планах Brocade — поддержка технологий VEB и VEPA.

УПРАВЛЕНИЕ И АВТОМАТИЗАЦИЯ

Управление коммуникациями между ВМ (включая обеспечение безопасности, качества обслуживания и пр.) — сложная комплексная задача, требующая взаимодействия между сетевым оборудованием (его средствами управления) и ПО виртуализации. Скажем, если при переезде ВМ на другой физический сервер сетевая инфраструктура не способна обеспечить требуемое этой машиной качество обслуживания трафика, то ПО управления должно предотвратить такое перемещение. Очевидно, что реализация подобного функционала требует сотрудничества между производителем коммутатора и ПО виртуализации.

В III квартале Extreme Networks планирует вывести на рынок програм-мные модули ExtremeXOS Network Virtualization (XNV), предназначенные для управления «жизненным циклом» виртуальных машин. Это решение позволит применять сетевые настройки (списки доступа, QoS и т. д.) к ВМ, используя профили виртуальных портов (Virtual Port Profiles, VPP). XNV обеспечит автоматическое отслеживание ВМ и применение профилей VPP при перемещении машины в сети ЦОД. Кроме того, это решение реализует функции инвентаризации, сохранения истории и получения данных о текущем местонахождении ВМ. Согласно информации, предоставленной компанией Extreme, XNV будет способна работать с гипервизорами основных поставщиков: VMware, Microsoft и Citrix.

Компания Juniper объявила о программной системе Virtual Control для автоматизации управления виртуальными серверами, которая тоже будет доступна в III квартале 2010 года. Она сможет управлять распределенными виртуальными коммутаторами VMware (vNetwork Distributed Switch) как собственными коммутационными платформами Juniper. Это достигается путем взаимодействия через API с сервером vCenter, в котором сосредоточены функции управления распределенных коммутаторов VMware.

В будущих релизах будет обеспечена интеграция с другими гипервизорами, такими как Xen (Citrix), Power VM (IBM), Hyper-V (Microsoft).

Свой подход к поддержке миграции ВМ компания Enterasys характеризует как «вендоро-агностический», то есть поддерживающий продукты разных поставщиков. Он основан на возможностях коммутаторов Enterasys автоматически применять индивидуальные профили к самым разным объектам, с которыми имеет дело коммутационная матрица; к их числу относятся и сеансы связи ВМ. Идентифицировав ВМ по МАС-адресу, коммутатор автоматически применит заданный для нее профиль. Для разработки инструмента, позволяющего получать информацию о ВМ в автоматическом режиме, компания сотрудничает с VMware, которая уже передала ей необходимый API.

Представляя свой новый коммутатор S60, представители компании Force 10 заявили, что он полностью готов к автоматизации процедур развертывания и управления сложными виртуализированными центрами обработки данных. Подробности решения нам неизвестны. Незадолго до анонса S60 производитель продемонстрировал, как другой коммутатор, C150, автоматически получает информацию об изменениях виртуализированной среды от сервера VMware vSphere. Можно предположить, что, наряду с большинством поставщиков оборудования сетевой инфраструктуры ЦОД, Force10 начнет автоматизацию с поддержки решений VMware.

Brocade тоже тесно сотрудничает с поставщиками решений для виртуализации серверных ресурсов. Однако, как подчеркивается в «программном документе» компании, описывающем технологию VAL, для работы в сети, где используются различные гипервизоры (а таких сетей со временем будет все больше и больше), требуется стандартный подход к получению профилей портов для ВМ. Поэтому большие надежды компания возлагает на разрабатываемый сейчас в IEEE стандартAutomated Migration of Port Profile (AMPP), который, как следует из его названия, позволит автоматизировать миграцию профилей портов.

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

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