Сетевые инфраструктуры ЦОД: текущее состояние и пути развития

Отрасль ЦОД стремительно развивается, а быстрый рост объемов передаваемых данных и масштабное внедрение технологий виртуализации вызывает потребность не только в постоянном повышении скорости каналов связи и производительности сетевого оборудования, но и в кардинальном пересмотре архитектур построения сетей ЦОД. С целью определить текущее состояние таких сетей, выявить основные возникающие в них проблемы и узнать о планах по их устранению «Журнал сетевых решений/ LAN» опросил специалистов, занимающихся развитием сетевых инфраструктур ЦОД в компаниях различных отраслей экономики. Полностью ответили на все поставленные нами вопросы представители 40 компаний, эти ответы и легли в основу статьи.

ОПРЕДЕЛИМСЯ С РАЗМЕРАМИ

Почти половина (46%) компаний, принявших участие в опросе, эксплуатируют центры обработки данных, в которых установлено более 10 стоек с оборудованием. В ЦОД еще 43,6% компаний — от трех до 10 стоек. И только у 1/10 опрошенных ИТ-хозяйство занимает менее трех стоек (см. Рисунок 1). Такие объекты, наверное, точнее называть серверными комнатами, хотя большой размер — далеко не главный отличительный признак ЦОД. Современные технологии виртуализации позволяют на базе одной стойки развернуть сотни виртуальных машин, чего вполне достаточно, чтобы «закрыть» ИТ-потребности даже средней по российским меркам компании. Поэтому по числу виртуальных машин (и, соответственно, по объему решаемых задач) комплекс из нескольких стоек с высокой степенью виртуализации вполне может превосходить ЦОД из десятка стоек с низкой плотностью вычислительных ресурсов.

Рисунок 1. Размер ЦОД (или серверов комнаты).

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

СКОРОСТЬ И ЕЕ ДЕФИЦИТ

На сегодняшний день на уровне доступа (для подключения серверов) в большинстве ЦОД используются каналы 1 Гбит/с (см. Рисунок 2), а на магистрали гигабитные каналы применяются практически наравне с 10-гигабитными (см. Рисунок 3). Хотя на рынке уже некоторое время доступны коммутаторы для ЦОД с интерфейсами 40 и 100G, эти технологии пока не получили сколько-нибудь заметного распространения. Решения 40G вообще не были упомянуты ни одним из респондентов.

Рисунок 2. Каналы на уровне доступа в сети ЦОД.

Рисунок 3. Магистральные каналы в сети ЦОД.

Проблемы с недостаточной скоростью каналов испытывают примерно треть ЦОД (см. Рисунок 4), соответственно, расширение этих каналов является одним из ключевых шагов по модернизации этих объектов. При этом чуть большее внимание планируется уделить развитию каналов доступа (см. Рисунок 5). Интерес к переходу на 10-гигабитные каналы для подключения серверов обусловлен не только общим ростом объемов трафика, но и все более широким внедрением технологий виртуализации. При увеличении числа виртуальных машин на одном физическом сервере повышается и нагрузка на его внешнюю систему ввода/ вывода, а значит, требуются более скоростные сетевые интерфейсы.

Рисунок 4. Проблемы в сети ЦОД.

Рисунок 5. Направление развития сетей ЦОД.

Каналы 10G в первую очередь будут активно применяться для межкоммутаторных соединений. Дальнейшее повышение пропускной способности магистральных каналов возможно за счет объединения нескольких физических линий 10G в единый логический тракт. По мере снижения стоимости оборудования 100G, его также начнут активно использовать на магистрали, поскольку при 10-гигабитных каналах на уровне доступа в ядре сети логично задействовать решения 100 Гбит/с.

КОНВЕРГЕНЦИЯ НЕИЗБЕЖНА?

Главная проблема для ИТ-специалистов связана с необходимостью поддержки сразу нескольких сетевых инфраструктур и технологий (см. Рисунок 4). Речь идет о параллельном существовании и развитии сетей Ethernet (ЛВС) и Fibre Channel (SAN). Как показал опрос, 67% компаний используют технологию Fibre Channel для подключения устройств хранения и формирования сети SAN.

Примерно четверть опрошенных в качестве ближайшего шага по развитию сети ЦОД назвали осуществление конвергенции сетей ЛВС и SAN на базе технологий FCoE и Data Centre Bridging (см. Рисунок 5). Чтобы стать универсальным транспортом и использоваться для передачи трафика FC (FСoE), технология Ethernet должна гарантировать доставку блоков FC/SCSI без потерь (lossless), поскольку этому типу трафика «противопоказаны» даже минимальные потери, возникающие в случае перегрузки в классических сетях Ethernet. Необходимые для этого механизмы уже стандартизованы рабочей группой IEEE 802.1 Data Centre Bridging (DCB), набор спецификаций которой составляет основу конвергентных решений Ethernet для ЦОД.

10% респондентов указали, что уже используют технологию FCoE. Хотя специально это мы не уточняли, но, скорее всего, соответствующие решения применяются на уровне доступа, то есть для подключения серверов к коммутаторам доступа с помощью конвергентных адаптеров (CNA). Это избавляет от необходимости для подключения серверов задействовать сразу две сетевые технологии: и традиционный трафик локальной сети, и трафик систем хранения данных (FCoE) передаются по одному каналу Ethernet. Преимущества очевидны: снижение числа кабелей, экономия технологического пространства в стойках, сокращение потребления электричества, уменьшение потребности в охлаждающих мощностях.

В ближайшие годы доля конвергентного Ethernet на рынке SAN будет неизбежно увеличиваться. Тем не менее вероятность того, что доля решений Fibre Channel резко снизится, очень мала. В соответствующие инфраструктуры инвестированы большие средства, поэтому вряд ли компании решатся заменить всю инфраструктуру SAN.

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

ВРЕМЯ МЕНЯТЬ КОММУТАТОРЫ

Третьим по числу упоминаний источником проблем, возникающих в сетевых инфраструктурах ЦОД, стала недостаточная производительность коммутаторов. Ее, равно как и дефицит пропускной способности каналов, указали примерно треть респондентов (см. Рисунок 4). При этом почти 44% намерены в ближайшее время поменять коммутаторы на более производительные и функциональные.

В настоящее время на рынке сетевого оборудования для ЦОД, равно как и на рынке сетевого оборудования в целом, доминирует Cisco Systems. Об использовании продуктов этой компании сообщили 92,3% респондентов. На втором месте с солидной долей в 38,5% находится компания HP, которая в нашем опросе, дабы никто не забыл о приобретении ею 3Com, фигурировала как HP/3Com. Третье место досталось Brocade (20,5%), которая также была указана «в связке» с купленными активами Foundry Networks. Далее расположились компании Juniper Networks, Allied Telesis, Huawei, AlcatelLucent и Extreme Networks (указаны в порядке убывания доли).

Интересно сравнить приведенные выше данные с теми, которые получены путем анализа ответа на вопрос «Сетевое оборудование каких фирм вы планируете применять при создании/модернизации сети ЦОД?». Cisco продолжает доминировать, но ее доля уже уменьшается до 84,6%. Наиболее существенное снижение — примерно вдвое — может ожидать компанию HP: покупка ее оборудования в планах только у 17,9% респондентов. Меньше новых заказов (в процентном отношении) будет и у Allied Telesis, Huawei и Alcatel-Lucent. А вот Brocade, Juniper Networks и Extreme Networks могут не беспокоиться: внимание к их оборудованию только растет.

Следует также отметить, что заказчики намерены избавляться от «зоопарка» сетевого оборудования. Если в настоящее время примерно 25% участников нашего исследования используют оборудование трех и более производителей, то в будущем доля любителей подобной мультивендорности снизится примерно втрое — большинство заказчиков планируют сотрудничать только с одним или двумя вендорами. Одной из причин сокращения числа поставщиков являются проблемы, связанные с использованием фирменных протоколов, приводящих к несовместимости оборудования разных вендоров. На наличие таких проблем указали 15% респондентов.

КАК НЕ ПОПАСТЬ В ПЕТЛЮ

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

Набор алгоритмов, которые позволяют освободить гипервизоры от задач по коммутации трафика ВМ, передав их внешним коммутаторам, получил название Edge Virtual Bridging (EVB). В основу соответствующего стандарта, над которым трудится рабочая группа IEEE 802.1Qbg, положена технология Virtual Ethernet Port Aggregator (VEPA). Процесс стандартизации уже практически завершен (принят Draft 2.2), и примерно 10% наших респондентов планируют воспользоваться преимуществами решений с поддержкой EVB, задействовав их для переноса функций коммутации трафика ВМ с виртуальных коммутаторов на внешние устройства.

Еще одна проблема, с которой сталкиваются специалисты, ответственные за сетевые инфраструктуры ЦОД, связана с медленным восстановлением работы сетей после аварий, что во многом обусловлено особенностями классического протокола STP. Этот протокол отвечает за переключение на резервные маршруты, но делает это очень медленно — его время сходимости составляет от 30 до 60 с. Для снижения этого времени был разработан и стандартизирован институтом IEEE (802.1w) протокол STP с ускоренной сходимостью (Rapid STP, RSTP) — на кольцах средних размеров (порядка 20 коммутаторов) он обеспечивает сходимость за 2–3 с. Но и это время равно недопустимо велико для поддержки критически важных приложений в ЦОД. Протокол STP и его модификации не только медлительны, они еще и «замораживают» часть сетевых ресурсов, чтобы не допустить формирования петель и зацикливания в них трафика.

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

Следующим шагом стала разработка технологий, позволяющих на втором уровне (L2) поддерживать в активном состоянии все сетевые каналы, которые могут быть «собраны» в произвольную топологию. Их часто называют технологиями «маршрутизации на втором уровне». Речь идет о разработанной организацией IETF технологии Transparent Interconnection of Lots of Links (TRILL) и технологии Shortest Path Bridging (SPB), стандарт на которую (IEEE 802.1aq) был принят весной 2012 года. Планы по переходу с STP на эти технологии имеются примерно у 13% опрошенных нами респондентов.

Среди предложенных нами шагов по модернизации сети ЦОД наименее популярным оказался переход от классической трехуровневой архитектуры к плоским топологиям типа Fabriс — такой переход запланировали всего 7,7% респондентов.

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

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

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