Три задачи для сети ЦОД

До недавнего времени проектировщики сетей передачи данных ЦОД ориентировались на годами отработанную архитектуру сетевой инфраструктуры, состоящую из трех уровней:

• магистраль (ядро);
• распределение;
• доступ.

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

В ЦОД сетевая инфраструктура уровня доступа реализуется с использованием больших модульных коммутаторов, располагающихся в конце ряда стоек (принцип End of the Row, EoR) – возможна их установка и в середине ряда – и обслуживающих все серверы данного ряда, или компактных коммутаторов с фиксированной конфигурацией, устанавливаемых в каждую стойку (Top of the Rack, ToR). В последнем случае каждый коммутатор ToR (обычно высотой 1U) обеспечивает доступ к сети для серверов своей стойки и подключается восходящим каналом (uplink) к вышележащим агрегирующим устройствам.

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

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

ЗАДАЧА 1: УМЕНЬШЕНИЕ ЧИСЛА УРОВНЕЙ

Специалисты сразу заметят, что использовать коммутаторы в серверных шасси вовсе не обязательно: блейд-серверы можно подключить напрямую к внешним коммутаторам через соединительные панели (сквозные модули — pass-through module). При наличии четырех шасси высотой 10U по 16 «лезвий» в каждом и трех каналов Ethernet на сервер для подключения серверов в одной стойке требуется около двух сотен кабелей. Если в ряду восемь стоек, число кабелей, обеспечивающих подключение всех серверов к модульному коммутатору EoR, приближается к тысяче – и это далеко не предел. Поскольку в подавляющем большинстве случаев на уровне доступа применяются медножильные кабели, пучки, в которые они собираются, получаются огромными и по массе, и по диаметру, а для их прокладки понадобятся емкие кабельные трассы, занимающие дорогостоящее пространство ЦОД.

На выручку приходят производители кабельных систем, в арсенале которых имеются разработки, где под единой оболочкой объединены несколько обычных кабелей с групповыми разъемами MRJ21 (см. Рисунок 2). Использование таких групповых кабельных сборок вкупе с модульными коммутаторами EoR, обладающими высокой плотностью портов, позволяет реализовать весьма изящное решение по организации сети доступа в ЦОД. Групповые кабели, тянущиеся вдоль ряда стоек, могут быть терминированы на коммутационной панели (полностью пассивный элемент!), размещаемой в верхней части стойки, к которой серверы подключаются обычными шнурами RJ45. В качестве альтернативы можно использовать кабельные сборки типа «осьминог», показанные на Рисунке 2.

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

Другой способ уменьшения числа кабелей внутри одного ряда — использование коммутаторов ToR. Но большое число таких коммутаторов приводит к уже упомянутым проблемам (сложностям при обслуживании и управлении). Кроме того, подключение каждого коммутатора ToR к нескольким (для резервирования) агрегирующим устройствам значительно увеличивает число кабельных соединений. Поэтому ведущие производители сетевого оборудования предлагают объединять коммутаторы ToR в логически единый стек при помощи высокоскоростных каналов (такие решения называются по разному: горизонтальный стек, виртуальное шасси и т. д.). Главное здесь то, что в рамках одного ряда стоек все коммутаторы ToR функционируют (и управляются!) как одно устройство. В качестве стековых соединений могут использоваться не только стандартные каналы Ethernet на 10 Гбит/с, в том числе объединяемые в транки, но и нестандартные — например, коммутаторы Summit компании Extreme Networks можно связать посредством каналов с пропускной способностью до 512 Гбит/с. Чем выше пропускная способность стекового соединения, тем меньше его длина, но для соединения коммутаторов соседних стоек достаточно, чтобы поддерживаемая дальность передачи составляла всего несколько метров.

Реализация решения ToR компании Cisco несколько отличается от подходов большинства конкурентов, которые ориентированы на формирование разнесенных стеков. Особенности ее «виртуальной модульной системы» заключаются в следующем: родительский коммутатор (Nexus 5000) выполняет функции виртуального шасси, к которому в качестве виртуальных линейных модулей подключаются по 10-гигабитным каналам так называемые выносы (Nexus 2000), размещаемые в верхней части аппаратных стоек с серверами. При этом распределенная система Nexus, как и стек, функционирует как одно устройство. Согласно замечанию Александра Скороходова, системного инженер-консультанта Cisco, по сравнению с разнесенными стеками решение на базе Nexus позволяет сохранить четкую иерархию между центром (Nexus 5000) и «выносами» (Nexus 2000). Это дает ряд преимуществ, в частности, обеспечивает необходимые показатели по масштабируемости и производительности для управляющих протоколов и позволяет по отдельности выбирать модель «выноса» и «материнского» устройства.

При подключении серверов Алексей Голых, главный специалист отдела сетей передачи данных «Корпорации ЮНИ», рекомендует всегда обеспечивать отказоустойчивость, для чего в каждую стойку устанавливать по два коммутатора ToR и каждый сервер подключать к обоим. Если серверов в стойках немного, то пара коммутаторов может обслуживать сразу две стойки (см. Рисунок 3). Проблема «замыкания» стека — соединения первого и последнего коммутатора — легко решается путем организации плоского кольца, принципы формирования которого хорошо известны специалистам по SDH. В таком решении к ядру сети ЦОД могут подключаться как часть коммутаторов стека, так и все коммутаторы — в зависимости от требуемого уровня производительности и отказоустойчивости.

Итак, сегодня имеются эффективные решения, внедрение которых позволяет сократить число уровней физических коммутаторов (см. Рисунок 4). А можно ли убрать виртуальный? Ответ на этот вопрос приводит нас к Задаче 2.

ЗАДАЧА 2: ПОДДЕРЖКА ВИРТУАЛИЗАЦИИ

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

В качестве одного из вариантов обеспечения мобильности ВМ Александр Гуляев, руководитель отдела сетевых проектов компании «Инфосистемы Джет», называет включение серверов c виртуальными машинами в одну сеть VLAN. «Но при этом возможности мобильности ограничиваются этим сегментом, и в свете перспективы перехода к ’’облачным‘‘ вычислениям данное решение, безусловно, не является оптимальным», — отмечает он.

Работая над решением описанных проблем, специалисты Cisco и VMware предложили концепцию распределенного виртуального коммутатора с разделением функций управления и собственно коммутации трафика. Реализация этой концепции в продуктах VMware получила название vNetwork Distributed Switch с сосредоточением функций управления в системе VMware vCenter. Компания Cisco предлагает набор соответствующего функционала как VN Link. В основе технологии лежит понятие виртуального интерфейса Ethernet (vEth), к которому привязывается определенный набор сетевых параметров — профиль (VLAN, ACL, параметры безопасности, QoS и пр.). При переезде ВМ интерфейс vEth вместе со всеми своими атрибутами следует за ней.

На данный момент Cisco предлагает два подхода к реализации функционала VN Link. Первый сводится к использованию в серверах виртуального программного коммутатора Cisco Nexus 1000V с выносом «наружу» функций управления – их обеспечивает модуль виртуального супервизора (Virtual Supervisor Module, VSM) (см. Рисунок 5). (К слову, за данный вариант компания подверглась критике: конкуренты называют его серверо-ориентированным.) Второй подход предполагает полное «освобождение» гипервизора от функций коммутации и перенос их во внешний коммутатор. При этом на самом сервере требуется «виртуализатор интерфейса» – это дополнительное ПО в гипервизоре или специальный виртуализированный сетевой адаптер (предлагается в рамках системы Cisco UCS). На наш взгляд, последний вариант более перспективен, поскольку, помимо поддержки мобильности ВМ, решает обсуждавшуюся выше задачу сокращения числа уровней коммутаторов (ВК больше не нужен!).

Подход Cisco положен в основу разрабатываемого стандарта IEEE 802.1Qbh (Bridge Port Extension). Альтернативным предложением занимается рабочая группа IEEE 802.1Qbg (Edge Virtual Bridging). Редактирование проекта этого стандарта осуществляли представители HP и IBM, а в числе его соавторов – специалисты Brocade, Juniper и QLogic. «Краеугольным камнем» зарождающегося стандарта IEEE 802.1Qbg является технология виртуального агрегирования портов (Virtual Ethernet Port Aggregation, VEPA), а ее активный сторонник, компания Extreme Networks, в апреле 2010 года предложила свои решения для управления жизненным циклом ВМ и выноса функций ВК на внешний коммутатор.

До окончательной ратификации того или иного стандарта (IEEE 802.1Qbh или 802.1Qbg) еще далеко. Пока же в вопросах поддержки виртуализации сетевой инфраструктурой заказчикам придется полагаться на фирменные решения.

ЗАДАЧА 3: КОНВЕРГЕНЦИЯ

Все сказанное выше относится в основном к одной части сетевой инфраструктуры ЦОД – к вычислительной сети Ethernet. Но существует и другая – сеть устройств хранения данных (SAN) на базе технологии Fibre Channel (FC). Перевод всего сетевого оборудования ЦОД на единый транспорт (Ethernet) – это и есть конвергенция сетевой инфраструктуры.

Чтобы служить в качестве такого универсального транспорта и использоваться для передачи трафика FC (FСoE), технология Ethernet должна гарантировать доставку блоков FC/SCSI без потерь (lossless), поскольку данному типу трафика «противопоказаны» даже минимальные потери, возникающие в классических сетях Ethernet при перегрузке. Большинство необходимых для этого механизмов будут, как ожидается, стандартизованы в течение 2010 года рабочей группой IEEE 802.1 Data Centre Bridging (DCB), набор спецификаций которой составит технологическую основу будущих решений Ethernet для ЦОД. Для описания таких решений существует несколько терминов: например, сотрудники Cisco долгое время предпочитали термин Data Center Ethernet (DCE), а IBM и Brocade – Converged Enhanced Ethernet (CEE). В любом случае речь идет о модернизируемом варианте Ethernet, способном стать универсальным транспортом.

Как долго придется ждать «всеобщей» конвергенции? По мнению Нила Рикарда, вице-президента по исследованиям компании Gartner, несмотря на привлекательность концепции ее реализация пока нецелесообразна с экономической точки зрения. Он предупреждает, что построение сети DCB/FCoE не сводится лишь к внедрению технологии 10GbE, для этого требуется поддержка ряда новых стандартов и реализация ячеистой топологии на втором уровне (L2 mesh). К тому же, добавляет он, некоторые производители могут попытаться затянуть процесс стандартизации (чтобы привязать к себе заказчиков фирменными технологиями), а для нормальной производительности потребуются новые микросхемы (обновление аппаратной части коммутаторов и адаптеров). Эксперт Gartner не ожидает появления крупных проектов по построению конвергентной сети ЦОД ранее 2012 года. А по прогнозу 3Com, переход к конвергентным сетям DCB начнется лишь в 2015 году (см. Рисунок 6).

В качестве первого этапа большинство экспертов рекомендуют осуществлять конвергенцию на уровне стойки. В этом случае в самой стойке можно использовать конвергентные адаптеры (CNA) и технологию FCoE для подключения к коммутатору ToR, а восходящие подключения реализовать отдельно для Ethernet и FC (см. Рисунок 7). Нил Рикард не исключает возможности использования для подключений внутри стойки не только технологии Ethernet/FCoE, но и других вариантов, например Infiniband и PCIe.

Александр Скороходов (Cisco) указывает, что пока, даже в рамках решений одного производителя, реализации FCoE, которые охватывали бы несколько транзитных узлов (Multihop), фактически отсутствуют. Но при этом достигнутый уровень стандартизации дает возможность строить мультивендорные конвергентные решения для комбинаций «конвергентный адаптер — коммутатор» или «конвергентный адаптер — коммутатор — массив хранения». «Необходимо понимать, что FCoE — всего лишь способ транспорта FC, поэтому не решает проблем интероперабельности, присущих самой технологии FC на уровне служебных протоколов. Как легко предположить, все трудности, связанные с соединением коммутаторов FC разных производителей, вряд ли исчезнут и в мире FCoE», — отмечает он.

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

Стоит отметить, что в ЦОД полный переход на Ethernet возможен не только за счет DCB — нельзя забывать и о другой технологии передачи трафика SAN по Ethernet (точнее, по TCP/IP) – iSCSI. По мнению Дмитрия Дощаного, несмотря на менее совершенные технологические характеристики данного транспорта, низкая стоимость делает iSCSI отличным решением для слабо нагруженных и некритичных серверов, которым требуется блочный доступ. При этом модифицировать существующую инфраструктуру Ethernet/IP нет необходимости — программные инициаторы iSCSI, доступные для всех ОС, позволяют использовать обычные адаптеры Ethernet.

Так или иначе, развитие архитектур и решений для построения сетевых инфраструктур ЦОД обещает немало интересного. Бум на рынке ЦОД стал мощным катализатором развития рынка сетевого оборудования, и эта область становится ключевой ареной борьбы ведущих производителей.

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