«Фабрики» — ЦОДам

Как показал прошедший в октябре 2012 года в Москве Ethernet-форум, главные слова в «лозунгах революционеров» — SDN и Fabric. Теме централизованно программируемых сетей SDN был посвящен предыдущий номер, теперь настал черед заняться «фабричными» делами.

Как отметил, выступая на форуме, Михаил Пергамент, консультант по центрам обработки данных компании Juniper Networks, на смену многие годы доминировавшей в ИТ архитектуре «клиент-сервер» приходит сервис-ориентированная архитектура. Если раньше большинство процессов серверной части выполнялись на одном физическом сервере, а потому при взаимодействии между ними сеть не задействовалась, то сейчас для повышения эффективности использования вычислительных ресурсов отдельные процессы распределяются по разным серверам, что существенно повышает нагрузку на сеть. В сервисориентированной архитектуре большинство данных остается внутри ЦОД и передается между его оборудованием (направление «запад – восток»), тогда как доля трафика между клиентами и серверами («север – юг») в общем объеме пересылаемых по сетям данных снижается (см. Рисунок 1).

Рисунок 1. В сервис-ориентированной архитектуре большинство данных остается внутри ЦОД и передается между его оборудованием (направление «запад – восток»), тогда как доля трафика между клиентом и сервером («север – юг») в общем объеме пересылаемых по сети данных снижается.

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

Один только факт «разворота на 90°» основного направления передачи трафика уже делает малоэффективными как традиционную иерархическую архитектуру сетей (доступ – агрегация – ядро), так и логические структуры наподобие «дерева», которые были оптимизированы для пересылки трафика от «корня» к «листьям» и обратно, то есть по вертикали «север – юг». К этому следует добавить рост интереса заказчиков к конвергенции сетей — к внедрению технологии FCoE, для которой требуется гарантированная передача трафика без потерь, а также к полноценной виртуализации сетевой инфраструктуры для поддержки уже виртуализированных серверов и перехода к облачной модели предоставления/получения ИТ-сервисов.

Именно новые решения, которые в англоязычной литературе получили наименование Fabric, по мнению большинства экспертов, позволят снять накопившиеся проблемы и сделать сети эффективной транспортной основой для виртуализированных ЦОД. По мнению Михаила Родионова, руководителя направления по работе с операторами связи в компании Extreme Networks, у отрасли уже сформировалось общее понимание того, каковы должны быть основные характеристики «фабрик»:

• поддержка всех линий связи в активном состоянии (без присущих протоколу STP блокировок);
• использование кратчайших путей пересылки;
• обеспечение низкой задержки и ее вариации;
• полная отказоустойчивость при отсутствии точек общесистемного отказа.

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

По мнению специалиста Extreme Networks, ключевым элементом фабрики должен стать контроллер, управляющий всеми ее элементами. По сути, речь идет о технологии централизованно программируемых сетей (SDN) и использовании протокола OpenFlow. Для поддержки же в активном состоянии всех имеющихся линий связи Extreme Networks предлагает использовать протокол Multi-Switch Link Aggregation Groups (MLAG). С его рассмотрения мы и начнем анализ возможных вариантов построения «фабрик».

ВАРИАНТ 1. MLAG

Это наиболее простая и хорошо проработанная технология для решения задачи одновременного использования нескольких путей передачи трафика (напомню, что протокол STP, дабы избежать зацикливания трафика, «замораживает» часть канальных ресурсов, оставляя активным только один путь между двумя узлами). Она основана на стандартной функции агрегации каналов (Link Aggregation Group, стандарт IEEE 802.1ad), которая позволяет несколько физических каналов объединять в один логический, повышая общую пропускную способность сети. MLAG дает возможность распределить эти логические каналы между двумя разными коммутаторами (см. Рисунок 2).

Рисунок 2. Пример «фабрики» от Extreme Networks.

Extreme Networks — далеко не единственный производитель, который использует MLAG в своих решениях, но детали реализации этой технологии, а часто и названия, у каждой компании свои. Например, подобная технология в решениях Avaya называется Split Multi-Link Trunking (SMLT), а в коммутаторах Cisco Nexus 5000 и 7000 — Virtual PortChannel (vPC). Возможности поддержки нескольких путей реализованы также в коммутаторах компании Arista Networks, которая, как и Extreme Networks, использует термин MLAG.

Несовместимость различных реализаций делает невозможным использование в паре (кластере) коммутаторов разных производителей. Но для внешних устройств процесс работы MLAG прозрачен: подключенный коммутатор доступа (или сервер) «не знает», что он соединен с двумя разными системами, поэтому, например, устройство Cisco вполне можно подключить к группе MLAG коммутаторов Extreme или Arista.

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

ВАРИАНТ 2. ВИРТУАЛЬНЫЕ ШАССИ

Вопрос единого управления группой коммутаторов чрезвычайно актуален в сложных сетях, и именно потребность в его решении во многом подстегивает интерес к SDN. Такое управление уже достаточно давно реализовано для разработок, которые можно объединить общим понятием «виртуальное шасси». Речь идет об объединении нескольких физических коммутаторов в логически единое устройство с общей системой управления.

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

«Виртуальные шасси» предлагают многие производители. Одни из самых известных решений — это Virtual Switching System (VSS) компании Cisco и Intelligent Resilient Framework (IRF) компании HP (получено ею в результате покупки 3Com). Согласно заявлениям этих производителей, при использовании 10-гигабитных линий связи коммутаторы в рамках одного «виртуального шасси» могут быть разнесены не только по разным стойкам одного ЦОД, но и на расстояния в десятки километров, что позволяет построить единую сеть для территориально распределенного ЦОД.

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

Следует заметить, что большинство виртуальных шасси предоставляют все преимущества поддержки множественных путей передачи для внешних устройств. Другими словами, такие шасси могут предлагать вовне те же каналы MLAG, но при этом внутри (между компонентами) использовать различные фирменные технологии. Поэтому варианты 1 и 2 тесно связаны между собой.

ВАРИАНТ 3. РАСПРЕДЕЛЕННЫЙ КОММУТАТОР

У компании Juniper Networks также имеется решение «виртуальное шасси» (для коммутаторов Juniper EX), но она решила пойти дальше и разработала принципиально иное решение Qfabric. Как рассказывает Михаил Пергамент, при разработке QFabric было поставлено несколько ключевых задач.

Одна из них — обеспечить высокий уровень масштабирования (от сотен до тысяч 10-гигабитных портов) при неизменности ключевых характеристик. Другими словами, при увеличении числа портов в «фабрике» ни задержка, ни уровень переподписки не должны возрастать. (Замечу, что при традиционных методах расширения сети эти задачи решить чрезвычайно сложно, поскольку подключение каждого нового коммутатора увеличивает число транзитных узлов, а потому — и задержку.) Кроме того, вся подсистема коммутации с точки зрения управления должна была выглядеть как одно устройство и обеспечивать передачу любого трафика (L2, L3, FCoE, iSCSI, NAS и пр.).

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

По сути, QFabric — это распределенный коммутатор, в котором вместо пассивной шины, обычно соединяющей линейные карты и платы матрицы коммутации, используются оптические каналы, связывающие устройства QF/Node (выполняют функции линейных карт) и QF/Interconnect (применяются вместо традиционных матриц коммутации). Таким образом устранено ограничение, накладываемое размером физического шасси, при сохранении большинства преимуществ единого устройства. Управление фабрикой QFabric реализовано «в стиле» SDN, то есть с помощью внешнего контроллера, который в решении Juniper называется QF/Director. Служебный трафик передается по выделенной сети управления (out-of-band) (см. Рисунок 3). Точнее, таких сетей две, как и устройств QF/Director — для резервирования.

Рисунок 3. Пример «фабрики» от Juniper Networks (решение Qfabric).

Устройства QF/Interconnect тоже всегда устанавливаются парами или даже четверками. Развертывание «фабрики» от Juniper можно начинать с установки в качестве устройств QF/Interconnect двух небольших продуктов QFX3600-I, к которым каналами 40G подключается до 16 узлов QF/Node (всего 384 порта 10G). По мере расширения ЦОД можно добавить еще два устройства QFX3600-I, тогда число поддерживаемых портов увеличивается в два раза — до 768. «Фабрика», в которой функционал QF/Interconnect реализуется с помощью устройств QFX3600-I, имеет суффикс M (Micro).

Следующая стадия масштабирования — замена QFX3600-I на более мощное оборудование межсоединения: модульные устройства QFX3008 с восемью слотами вмещают до 128 портов 40G (QSFP+). При использовании четырех таких устройств общая емкость фабрики превышает 6000 портов 10G. Заметим, что при модернизации устройства QFX3600-I выбрасывать не надо: их можно использовать в качестве QF/Node, для чего, правда, каждый порт 40G потребуется конвертировать в четыре порта 10G с помощью специального разветвителя. Пока максимальное расстояние между устройствами QF/Node и QF/ Interconnect составляет 100 и 150 м при использовании оптики ОМ3 и ОМ4 соответственно.

Интересно отметить, что внутри QFabric используются протоколы IS-IS и BGP, которые относятся к уровню L3. Например, когда новый узел QF/Node подключается к сети, именно протокол IS-IS служит для его автоматического обнаружения, после чего QF/Director автоматически генерирует конфигурационные параметры (IP-адрес и пр.) и направляет их новому узлу. Протокол BGP нужен для распределения динамической информации, например новых МАС-адресов.

Другой пример «растягивания» коммутатора — решение Cisco Fabric Extender (FEX). Его основу составляют «материнские» коммутаторы (серий Cisco Nexus 5000, Nexus 7000 или UCS Fabric Interconnect), к которым подключаются выносы FEX, выполняющие функции удаленной линейной платы. В качестве выносов могут использоваться коммутаторы Nexus 2000, сетевые модули UCS 2100 Fabric Extender для блейд-серверов Cisco UCS, а также решение Cisco Nexus B22 Fabric Extender для блейдсерверов HP. Уникальная особенность этой «фабрики» состоит в том, что она может охватывать интерфейсы сервера (с помощью Cisco Adapter FEX) и даже виртуальные машины (технология VM-FEX). Это означает проникновение сети «внутрь» сервера, при этом в единой плоскости коммутации могут находиться не только порты коммутаторов, но и серверные адаптеры и виртуальные машины.

Хотя FEX и использует достандартную реализацию IEEE 802.1BR, пока это закрытое решение, а значит, его выбор означает, что ваша сеть будет привязана к одному вендору. Собственно говоря, другие рассмотренные выше решения также нельзя назвать стандартными. Есть ли вообще шанс построить «фабрику» на основе стандартов? Такую надежду дают технологии Transparent Interconnection of Lots of Links (TRILL) и Shortest Path Bridging (SPB), к рассмотрению которых мы и переходим.

ВАРИАНТ 4. TRILL

Технология TRILL определена в серии документов организации IETF (RFC 5556, 6325, 6327, 6349), но некоторые механизмы находятся только в стадии рассмотрения. Часто ее называют маршрутизацией на уровне L2. Как известно, классическая маршрутизация выполняется на основании информации уровня L3, при этом решение о выборе маршрута осуществляется по результатам вычисления кратчайшего пути. TRILL реализует похожую логику, но только не для IP-, а для МАС-адресов. Не удивительно, что «на языке» TRILL поддерживающие эту технологию коммутаторы называются маршрутизирующими мостами, или RBridge.

Для вычисления наилучшего пути до пункта назначения коммутаторы RBridge используют протокол IS-IS, основанный на известном алгоритме Shortest Path First (SPF). Коммутатор, находящийся на входе в облако TRILL, с помощью IS-IS сразу определяет 16-разрядный идентификатор коммутатора на выходе. Каждый последующий коммутатор (транзитный узел) в облаке пересылает трафик на основе этого идентификатора, благодаря чему внутри облака не требуется поддерживать таблицу внешних МАС-адресов. Узлы оперируют очень небольшим объемом адресной информации, что упрощает их задачу, в частности, по распределению трафика по множеству путей. В технологии TRILL вводится такой важный параметр, как «время жизни» — Time To Live (TTL): при прохождении кадром каждого узла в сети TRILL значение этого параметра уменьшается. Этот механизм отсутствует в классической технологии Ethernet, что во многом и является причиной зацикливания трафика — без поля TTL кадр Ethernet может бесконечно долго «путешествовать» по сети, если не достигнет адресата.

В настоящее время несколько производителей при описании своих решений упоминают о технологии TRILL. В частности, Cisco называет свою технологию FabricPath, поддерживаемую устройствами серий Nexus 5000 и 7000, совместимой с TRILL. Однако независимые эксперты отмечают ряд отступлений от стандарта — в частности, другой формат кадра, который используется для передачи трафика между коммутаторами. Но поскольку Cisco активно участвует в продолжающейся стандартизации TRILL, высока вероятность, что фирменные функции со временем станут частью стандартов. Собственно, такое уже многократно происходило при формировании стандартов на другие сетевые технологии.

На Рисунке 4 показана расширенная фабрика, в которой применяется комбинация технологий Cisco FabricPath и FEX. Sxxx — это номера (идентификаторы) коммутаторов, используемые для доставки кадра внутри сети FabricPath. Так, в кадр, отправленный узлом с MAC-адресом A узлу с MACадресом C, на входе в сеть FabricPath добавляется заголовок, где в качестве номера исходящего коммутатора указывается S300, и дальнейшая передача до выхода из сети FabricPath будет осуществляться на основании этого номера.

Рисунок 4. Пример комбинации технологий Cisco FabricPath и FEX в единой расширенной фабрике.

Показанные на схеме S100 и S300 — это так называемые эмулированные коммутаторы (или домены vPC+), то есть пара коммутаторов, подключение к которым осуществляется по технологии Multi-Chassis PortChannel. Каждый из коммутаторов в паре имеет также свой собственный идентификатор FabricPath (скажем, S101 и S102, S301 и S302), а эмулированный коммутатор с точки зрения логической топологии FabricPath (как она видна в IS-IS) выглядит как находящийся «за ними»: S100 достижим через S101 и S102, а S300 — через S301 и S302. Тем самым устройства, подключенные к правой по схеме паре через каналы vPC+ (непосредственно или, как на схеме, через FEX), оказываются достижимы с «равной стоимостью» через S301 и S302, что обеспечивает распределение нагрузки между всеми оптимальными каналами.

На схеме также указаны два варианта подключения выносов FEX — сквозное (Straight-Through) и EvPC. Поскольку вынос FEX — это «продолжение» головного устройства, наиболее простой вариант — подключение FEX только к одному «материнскому» коммутатору. В этом случае вся настройка и коммутация осуществляется на одном коммутаторе, а для резервирования на случай его отказа от серверов организуются каналы vPC до выносов FEX, подключенных к разным коммутаторам в паре vPC. Такой вариант исторически называется Straight-Through.

Альтернативный, более сложный вариант — подключение FEX сразу к двум головным коммутаторам. В этом случае коммутация происходит сразу на обоих за счет организации подключений vPC от FEX до пары коммутаторов, а согласование настроек для портов FEX осуществляется, например, посредством автоматической синхронизации конфигураций. В такой схеме могут использоваться подключения vPC и до серверов, что позволяет говорить о двухуровневом vPC — от коммутаторов до FEX и от FEX до серверов. Данная схема получила название Enhanced VPC (EvPC).

Но вернемся к реализациям технологии TRILL. Она положена и в основу решения Virtual Cluster Switching — «фабрики» Ethernet, разработанной компанией Brocade (см. Рисунок 5). Правда, вместо протокола IS-IS в решении компании используется протокол Fabric Shortest Path First (FSPF), позаимствованный из мира Fibre Channel. Как указывают специалисты компании, протокол FSPF позволяет каждому коммутатору VCS одновременно «видеть» все входящие в «фабрику» устройства и выбирать маршруты с учетом состояния всей топологии. Коммутация трафика между двумя конечными устройствами в фабрике осуществляется в режиме балансировки нагрузки, при котором используются все возможные эквивалентные пути с одинаковыми минимальными весами между конечными коммутаторами. Физические каналы Ethernet, связывающие два смежных коммутатора в Ethernetфабрике, автоматически объединяются в одну логическую группу Brocade Fabric Trunk.

Рисунок 5. Пример «фабрики» от Brocade.

Осенью 2012 года Brocade представила VDX 8770 — первый модульный коммутатор в линейке устройств VDX, предназначенных для построения Ethernet-фабрик (до этого строителям таких «фабрик» были доступны только устройства с фиксированной конфигурацией). Представленный коммутатор существенно увеличивает масштабируемость и производительность Ethernet-фабрики, в которой может насчитываться более 8000 портов. Как сообщают в компании, решения VDX сейчас применяются в более чем 700 инсталляций по всему миру.

ВАРИАНТ 5. SHORTEST PATH BRIDGING

Технология SPB описана в принятом институтом IEEE в марте 2012 года стандарте 802.1aq. Во многих отношениях она является конкурентом TRILL. Интересна история вопроса: разработчики TRILL сначала предложили свою технологию для стандартизации в качестве замены STP институту IEEE, но, получив отказ, обратились к IETF. Тогда чиновники IEEE инициировали разработку SPB.

Для сбора сведений о топологии сети SPB, так же как и TRILL, используется протокол IS-IS. Однако реализуемые SPB механизмы передачи кадров отличаются от тех, что используются в TRILL. При входе в домен SPB к стандартному кадру Ethernet «приклеивается» дополнительный тег с идентификатором VLAN (VID), который «снимается» на выходе из домена. У SPB имеются две модификации: одна — SPBV — использует формат кадра 802.1ad (Q-in-Q), а другая — SPBM — 802.1ah (MAC-in-MAC). Второй вариант позволяет поддерживать значительно большее число узлов, что делает его подходящим для использования в больших сетях сервис-провайдеров.

О поддержке SPB заявили такие компании, как Alcatel-Lucent, Avaya и Huawei, причем они утверждают о проведении успешных тестов на совместимость. Как видим, лагери сторонников TRILL и SPB представляют собой практически непересекающиеся множества, однако есть и исключения. По крайней мере одна компания, HP, заявила о намерении поддерживать обе эти технологии.

К лидерам на рынке решений для сетевой инфраструктуры ЦОД относятся компании Cisco, HP, Extreme Networks, Brocade и Juniper. Во всяком случае именно так считают эксперты Info-Tech Research Group. Эту пятерку выделили и участники опроса, проведенного нашим журналом осенью 2012 года (подробнее см. статью «Сетевые инфраструктуры ЦОД: текущее состояние и пути развития» в сентябрьском номере «Журнала сетевых решений/LAN» за 2012 год). Эти компании пока предлагают собственные варианты для построения коммутационных полей нового поколения типа Fabric. Поэтому тем, кому «фабрики» действительно необходимы, придется довериться одному из названных вендоров либо ждать готовности решений на базе стандартов TRILL и SPB.

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