Журнал ИКС

Разделы сайта

• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Ближайшие события

Алексей НОВИЧКОВ

13 октября 2009

ЦОД: выбираем Ethernet-коммутаторы

Представление о том, каким сетевым оборудованием должен быть оснащен ЦОД, зависит от многих факторов: начиная с того, в какой отрасли и на каком уровне он решает задачи, и заканчивая тем, какие приложения в нем запущены. Что готов предложить рынок? «ИКС» спросил об этом поставщиков оборудования и системных интеграторов.

Поскольку для высокопроизводительной коммутации серверов и систем хранения сегодня используется большой спектр технологий и устройств (коммутаторы Ethernet, Fibre Channel, Infiniband, Myrinet и др.), мы решили сначала ограничиться рассмотрением узкого круга задач – организации коммуникации на уровне доступа сети ЦОДа с использованием технологии Ethernet, но при этом были вынуждены подняться несколько выше, рассмотрев архитектуру сети ЦОДа в целом.

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

Сеть ЦОДа: классическая архитектура и ее воплощения

Коммуникационная среда ЦОДа в силу повышенных требований к ее надежности и безопасности часто создается как отдельная сеть. Исторически масштабирование Ethernet-сетей производилось благодаря многоуровневой иерархической структуре. В классической современной архитектуре корпоративной ЛВС выделяют три уровня: доступа, агрегирования и ядра сети. Аналогичным образом строится и сеть ЦОДа (см., например, рисунок), т.е. в общем случае в ней также можно выделить уровень доступа (access tier, или у некоторых производителей – edge tier), просто в качестве терминальных узлов здесь выступают не настольные ПК или иные абонентские устройства, а серверы. В такой сети своя специфика имеется и у уровня агрегирования (иногда еще называемого distribution), и у уровня ядра. Скажем, на уровне агрегирования часто помимо средств безопасности и мониторинга располагаются еще и средства балансировки нагрузки.

Некоторые из опрошенных нами поставщиков считают, что для сети ЦОДа трехуровневая архитектура слишком сложна и избыточна. Это объяснимо, поскольку в России, которая находится на начальном этапе «цодостроительства», под ЦОДом часто подразумевают серверную комнату с парой стоек оборудования, и в таком случае действительно можно обойтись если не единственным модульным коммутатором, то уж точно сетью с двухуровневой архитектурой.

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

От ядра – к серверам

Уровень ядра сети ЦОДа обеспечивает коммутацию трафика от уровня агрегирования и связь ЦОДа с остальной корпоративной сетью. С организационной точки зрения именно за уровнем ядра сети ЦОДа в крупных организациях заканчивается зона ответственности структурного подразделения эксплуатации ЦОДа. Уровень агрегирования, комплектуемый обычно коммутаторами с большим числом портов 10 Gigabit Ethernet (10GE), в крупных сетях служит демпфером между ядром и уровнем доступа; коммутаторы в нем, как правило, устанавливаются парами, так, что коммутаторы уровня доступа подключаются сразу к двум коммутаторам уровня агрегирования.

Как уже отмечалось, в сети ЦОДа в качестве терминальных узлов уровня доступа выступают серверы. Современные серверы имеют как минимум два интерфейса Gigabit Ethernet. Кроме того, они могут оснащаться портами для связи с системой хранения данных (а часто еще и дополнительными интерфейсами для обеспечения доступа к системе резервного копирования) и портом управления по дополнительному каналу (out-of-band). Такое количество интерфейсов существенно усложняет коммутационную инфраструктуру нижнего уровня сети ЦОДа. Задача поставщиков активного сетевого оборудования – упростить ее, предоставив как можно более унифицированную коммуникационную среду.

На уровне доступа используются два метода размещения коммутаторов, в соответствии с которыми поставщики иногда классифицируют свои продукты. Это подключение серверов одного ряда стоек к од-ному коммутатору с большим числом гигабитных интерфейсов, устанавливаемому в конце этого ряда (End-of-row – EoR), и подключение серверов в каждой стойке к стоечному коммутатору высотой 1U–2U, устанавливаемому вверху стойки (Top-of-rack –ToR). Отдельная тема для разговора – обеспечение коммуникационной среды для блейд-серверов.

Компоновка стоек: ToR против EoR

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

В ToR-конфигурации используются коммутаторы с относительно небольшим числом портов. Для этого типа компоновки могут быть применены продукты большинства опрошенных нами производителей (см. табл. 1). Такой подход позволяет упростить кабельную систему (к стойке уровня агрегации достаточно протянуть кабели обычного или агрегированного uplink-канала). Недостатком, соответственно, является необходимость управлять большим числом коммутаторов. Однако специальные инженерные решения позволяют справиться с этой трудностью.

ToR-компоновка: «виртуальное шасси», или Общая шина на уровне доступа

Ряд поставщиков предлагает решения, которые совмещают преимущества EoR- и ToR-компоновок путем объединения коммутаторов, монтируемых вверху стойки, в некий виртуальный модульный коммутатор с помощью мощной стекирующей шины. С точки зрения системы управления такой стек действительно представляется единым коммутатором, что упрощает администрирование множества отдельных устройств.

Например, у компании Juniper такое решение получило название «виртуальное шасси» (Virtual Chassis, VC). Оно работает только на коммутаторах серии EX4200. Несколько этих коммутаторов (до 10) объединяются стекирующей шиной с кольцевой топологией через два 64-гигабитных VC-порта с результирующей пропускной способностью 128 Гбит/с (допускается также подключение коммутаторов в VC-стек с помощью агрегируемых Ethernet-каналов с пропускной способностью до 40 Гбит/с). Управление виртуальным шасси производится с резервированием по принципу выделения master/backup-коммутаторов.

Метод стекирования для консолидации коммутаторов на уровне доступа при помощи специальной мощной шины используют и другие производители, например компания Nortel в технологии Switch Cluster, позволяющей объединять в кольцо до 8 устройств ERS5600 60-гигабитной шиной (максимальная пропускная в способность в кольце – 120 Гбит/с).

Несмотря на то что у Cisco есть своя технология StackWise для стекирования стоечных коммутаторов, сегодня в нише ToR-размещения компания делает ставку на коммутаторы серии Nexus с технологией так называемых выносных модулей (fabric extenders) с применением топологии «звезда». Идея этого подхода заключается в том, что виртуальный модульный коммутатор образуется за счет подключения к центральному коммутатору (также резервируемому) Nexus 5000 нескольких выносных модулей Nexus 2000, фактически Ethernet-коммутаторов высотой 1U, по обычному или агрегированному соединению из четырех 10GE-каналов. По данным компании, такой «почти неблокируемый виртуальный коммутатор» с 12 выносными модулями может иметь до 576 интерфейсов Gigabit Ethernet.

Справедливости ради надо сказать, что и остальные компании, представившие свои стоечные коммутаторы для компоновки ToR, позволяют строить из них стеки (преимущественно с помощью 10GE-каналов, часто агрегируемых). Но при этом неблокируемая коммутируемая емкость таких стеков значительно ниже, чем у перечисленных выше виртуальных модульных коммутаторов.

В самом деле для ЦОДа?

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

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

Высокая производительность и плотность портов. Коммутаторы на уровне доступа должны иметь как минимум гигабитные интерфейсы для связи с серверами и 10GE-интерфейсы для uplink-соединений. В силу упомянутого выше большого числа интерфейсов в современных серверах к коммутаторам для ЦОДов предъявляются требования высокой плотности портов. Но физический максимум конструктивной плотности портов фактически уже достигнут – это порядка 48–52 портов на стандартное стоечное устройство высотой 1U (см. фотографии). Поэтому, говоря о плотности, производители часто подразумевают некую удельную пропускную способность на один порт, а она тем выше, чем больше у коммутатора 10GE-интерфейсов. Сегодня компоновку с большим числом таких портов обеспечивают в основном модульные коммутаторы, но некоторые производители предоставляют уже и 1U–2U- стоечные модели 10-гигабитных коммутаторов, например, Cisco – коммутатор Nexus 5000 (до 52 10GE-портов), Juniper – 1U-коммутатор EX2500 (24 10GE-порта), HP – 1U-коммутатор ProCurve 6600-24XG (24 10GE-порта). Такие устройства могут быть использованы при ToR-размещении коммутаторов в стойках с высокопроизводительными серверами, оснащенными 10GE-интерфейсами.

Экономичность. Можно сказать, что на фоне мощности, потребляемой серверами, энергопотребление обслуживающего их коммутирующего оборудования не слишком значительно. Но для ЦОДа важна не только экономия самой электроэнергии, но и стоимость инфраструктуры бесперебойного питания, поэтому здесь каждый ватт на учете. Исследуя данный вопрос, мы обнаружили, что поставщики, относительно недавно вышедшие на рынок Ethernet-коммутаторов, более щепетильно относятся к энергопотреблению своего оборудования. Например, потребляемая мощность 24-портового гигабитного L3+ коммутатора XGS-4728F фирмы ZyXEL по каталогу составляет 63 Вт, а у аналогичной модели коммутатора H3C S5500-28C-SI фирмы 3Com и вовсе 58 Вт, что существенно ниже энергопотребления в холостом режиме соответствующих моделей других известных производителей, которые специально подчеркивают сертификацию своего оборудования с точки зрения экономичности. Впрочем, экономичность коммутируемой сети ЦОДа целесообразно считать по комплексному решению, с учетом потребления старших моделей Ethernet-коммутаторов и их конкретной компоновки.

Эффективный теплоотвод. Решение проблемы охлаждения в коммутирующем оборудовании для ЦОДа имеет определенные особенности. Дело в том, что нетипичная для серверных стоек боковая система вентиляции (side-to-side), реализованная в большинстве традиционных моделей пицца-подобных коммутаторов, приносит инженерам ЦОДов много хлопот из-за эффекта замкнутого горячего контура, когда горячие «выхлопы» одного устройства «заглатываются» для охлаждения другого. Учитывая этот факт, ряд производителей уже начал поставку «плоских» стоечных коммутаторов с продольной системой вентиляции (front-to-back). Это, например, модели серий AT-x900/908 фирмы Allied Telesis и уже упомянутые модели Cisco Nexus (все семейство), Juniper EX2500, HP ProCurve 6600. Причем две последние серии предусматривают реверсивную компоновку вентиляторов (в моделях HP обращение потока производится простой перестановкой блока вентиляторов). Таким образом, мощные стоечные коммутаторы все больше по своей компоновке напоминают серверы, которые они обслуживают.

Поддержка оптических интерфейсов. Поскольку медножильные кабели категории 6A, предназначенные специально для технологии 10GE, занимают значительный объем пространства (не только в сравнении с оптическими кабелями, но даже с кабелями категорий 5e и 6), использование их в ЦОДе усложняет задачу эффективного отвода тепла. Кроме того, они проигрывают оптике в рабочих расстояниях, а «медные» порты потребляют гораздо больше электроэнергии, чем оптические, поэтому критически важной становится поддержка коммутаторами оптических интерфейсов (т.е. наличие слотов XFP или SFP/SFP+).

Однако строгий читатель может заметить, что все это справедливо и для любых современных ЛВС. В то же время к сетям ЦОДов сегодня предъявляются определенные специфические требования, связанные, в частности, с применением технологии виртуализации серверов, что сильно отличает такие сети от обычных ЛВС. Эти требования тезисно сформулировал системный инженер-консультант Cisco Александр Скороходов:

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

Эффективная поддержка больших доменов коммутации 2-го уровня (коммутации Ethernet). Широкое использование миграции виртуальных машин усугубляет данное требование.

Все более высокая производительность и массовый переход на технологию 10-Gigabit Ethernet, поскольку консолидация вычислений приводит к росту нагрузки на сетевые интерфейсы серверов.

Консолидация ввода-вывода (переход на технологии объединенной сети). Использование виртуализации приводит к росту доли серверов, подключенных к сетям хранения данных, что делает особенно актуальной задачу консолидации ввода-вывода, т.е. отказа от отдельного подключения серверов к сетям Ethernet и Fibre Channel, а в перспективе, возможно, и от отдельных сетей передачи данных и хранения данных.

  

В результате своего небольшого исследования мы выяснили, что, если не считать некоторых концепций и сетевых архитектур (например, Data Center Infrastructure Solutions фирмы Juniper или аналогичных концепций HP и Nortel) и «точечных» моделей ком-мутаторов, поставщики в основном позиционируют свое Ethernet-оборудование как универсальное, которое может использоваться как в корпоративных и операторских транспортных сетях, так и в сетях ЦОДов.

Взяв на себя определенный риск, компания Cisco выпустила целую линию продуктов, позиционируемую как специализированное оборудование для ЦОДа. В нее входят коммутаторы серий Nexus 7000, 5000, 2000 и 1000V. Последний представляет собой виртуальный программный коммутатор, обслуживающий виртуальные же серверы в среде гипервизора VMware. (Можно сказать, что на наших глазах начинается этап перетаскивания очередного слоя оборудования в «зазеркалье» виртуализации.) Линия продуктов Nexus – не последняя инициатива Cisco в рамках ее концепции Data Center 3.0. Весной этого года компания вышла на рынок с новой линией продуктов Unified Computing System, поставляемой в формате блейд-шасси, и серверов для них, которые включают в себя полную сетевую инфраструктуру с конвергированной Ethernet-средой и использованием как минимум 10GE-интерфейсов. Тем самым рынку Ethernet-оборудования брошен вызов, и уже в ближайшее время можно ожидать, что на нем разгорится борьба в сфере специализированных комплексных сетевых решений для ЦОДов.

Заметили ошибку в тексте? Выделите её мышью и нажмите Ctrl+Enter. Спасибо!