Ethernet или Fibre Channel? Можно ли построить центр обработки данных на основе единой сети NVMe over Fabrics, которая будет быстрее и дешевле классических решений? Можно ли обслуживать такую сеть одной командой вместо трех? Можно, если выбрать правильный протокол. Рассказываем, как это сделать.

Если посмотреть на типовой современный ЦОД, внутри мы увидим разнородный трафик TCP/IP, который перемещается как по физическим underlay-сетям, так и по логическим overlay. Как правило, в таком ЦОДе присутствуют три основные службы: HPC (high-performance computing), СХД и обыкновенная сервисная сеть. Каждая из них имеет определенную функциональность, свои требования и сопровождается отдельной командой.

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

Прежде всего, на ситуацию влияет появление новых и очень быстрых носителей информации. Выпуск аппаратных решений, как правило, вызывает к жизни множество протоколов и дизайнов. Так было с SSD, SCM (Storage Class Memory) и persistent memory. Они быстро обрастают протокольной «обвязкой»: PCIe, RDMA, NVMe и NVMe-oF. Соответственно, формируются и новые архитектуры — гиперконвергентные решения и компонентная десегрегация.

Применительно к сетевым технологиям локомотивом развития можно назвать протокол NVMe-oF (NVMe over Fabrics, NOF), позволяющий организовать дистанционный доступ к NVMe-устройствам с задержкой не более 10 мкс.

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

Каким требованиям должна отвечать такая сеть

В первую очередь здесь не обойтись без управления потоком на основе кредита (Credit-based Flow Control). Того самого, который обеспечивает нулевую потерю пакетов в сетевой фабрике. Кроме того, требуется поддержка клиентской части — операционных систем, приложений. Что касается минимальных задержек, на этом поле играют протоколы Fibre Channel, InfiniBand и Ethernet (RoCEv2). Также необходимо снять нагрузку с процессоров, что обычно делается на уровне сетевых интерфейсных карт. Наконец, на уровне архитектуры сети должна быть реализована концепция Multi-Pod, а также организована работа с системами Multi-host/Port/Path.

Среди всех способных обеспечить минимальные задержки протоколов Huawei делает ставку на Ethernet и RoCEv2 (RDMA over Converged Ethernet). Именно они позволяют объединить все составляющие сети ЦОД в одну. Уже сейчас мы видим, что многие из наших клиентов, заинтересованные в высокопроизводительных вычислениях, готовы к переходу на Ethernet, особенно после появления стандарта 400G.

Почему не Fibre Channel

Среди эксплуатантов Fibre Channel нет такого оптимизма. Там до сих пор можно найти много legacy-дизайнов на 8/16G, постепенно появляются проекты на базе 32G, в то время как начало коммерческой реализации 64G запланировано на первые месяцы следующего года. Попробуем сравнить обе сети.

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

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

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

Пойдем глубже. Итак, Ethernet показывает нам две стороны одной медали — высокую производительность и риск потери кадров. У Fibre Channel ситуация зеркальная: гарантированная сохранность данных и невысокая пропускная способность. В то же время Ethernet демонстрирует полную унификацию в управлении и развертывании сервисов, в том числе автоматизированном. Здесь есть SDN-контроллер, который строит как underlay-, так и overlay-сети. Добавим сюда системы телеметрии и анализа. А еще все прекрасно знают, как хорошо Ethernet масштабируется. Нам доступны дизайны и Multi-Pod, и Multi-DC.

Снова обратимся к преимуществам Fibre Channel. Это управление потоком на основе кредита, способность ресурсов быстро находить друг друга (plug'n'play), быстрые механизмы сходимости на уровне NVMe-фабрики. Если active/standby switchover в сетях Fibre Channel занимает менее одной секунды, то сети Ethernet на это потребуется от 8 до 15 секунд.

В Huawei очень хорошо понимают эти особенности, поэтому приложили серьезные усилия к тому, чтобы устранить свойственные Ethernet недостатки, сохранив при этом все его достоинства.

Новый Ethernet без потерь

Начнем с препятствующего потере кадров управления потоком. Да, существует множество стандартизированных методов сохранения данных в Ethernet, но они решают не все проблемы. Например, они не справляются, когда трафик с множества портов сходится в один порт (incast traffic). То же касается и блокирующих друг друга потоков. Не избавят эти методы и от ситуации, когда неправильно настроенная балансировка потоков приводит к перегрузкам.

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

Вернемся к сходимости NVMe-фабрики. В случае разрушения сети протокольная сходимость осуществляется по таймауту. Мы в Huawei не считаем это правильным. Мы научились встраиваться в сигнализацию NVMe между хостом и таргетом, а затем отдавать команду произвести активный switchover на другой канал. Это позволило добиться такого же односекундного переключения, как и в сетях Fibre Channel.

Теперь о plug'n'play. Раньше для каждого ресурса приходилось вручную настраивать хост, путь, порт, имя и пр. C появлением в наших СХД OceanStor поддержки технологии UltraPath+ мы предлагаем возможность автоматической регистрации ресурсов.

А что с производительностью? Для того, чтобы ответить на этот вопрос, мы провели серию синтетических тестов с использованием СХД OceanStor V6. Для сравнения использовались сети Ethernet 25G и Fibre Channel 32G. Прирост производительности на небольших фреймах составил порядка 100% в пользу Ethernet. С увеличением размера фреймов разрыв сокращался, но даже худший из результатов показал паритет пропускной способности. Конечно, гораздо интереснее было бы провести тестирование на реальных нагрузках. Как только наши заказчики обратятся за такой возможностью, мы с удовольствием откликнемся.

Несколько слов об алгоритмах iLossless

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

• Контроль телеметрии. Система в реальном времени собирает информацию об очередях, загрузке буферов и предсказывает их будущие состояния.

• Контроль TCP сессий. Система собирает информацию о потоках, формирует статистику, анализирует задержки и потери.

• Работа с подлежащим и вышестоящим слоями. Именно здесь, кстати, реализованы алгоритмы ускорения сетевой сходимости. Речь идет о некоем подобии Credit-based Flow Control, но лишь между «соседями».

• Возможность встраиваться в поток NVMe-команд. Коммутатор умеет представляться таргетом и передавать сигнальную информацию для NVMe-хоста.

Вся эта функциональность и позволяет Huawei уверенно конкурировать с решениями на базе Fibre Channel, предлагая свои СХД на базе классической сети Ethernet. Работа коммутатора строится на парсинге, копировании и изучении пакетов. Коммутатору доступны все заголовки, включая заголовок InfiniBand. Уже из него можно извлечь нужные подзаголовки, содержащие все основные характеристики потока. Эта информация отправляется в аналитический процессор, который собирает дополнительную информацию: запросы на соединение, ответы, порты, задержки, данные о потере пакетов и др. Данные собираются со всех коммутаторов и отправляются на уровень выше — в интеллектуальную аналитическую платформу iMaster NCE-FabricInsight. Она видит реальную топологию сети и текущую ситуацию в ней. Как только повышается задержка RoCE-трафика и возникает угроза потери данных, начинается переконфигурация.

Немного подробней о сборе статистики TCP-сессий. Есть три подхода. В принципе, они отражают эволюционное развитие архитектуры чипов.

Анализ TCP-сессий на основе ERSPAN

Здесь используется удаленное копирование заголовков пакетов TCP, подлежащих анализу, через протокол ERSPAN в коллектор iMaster NCE-FabricInsight для анализа сеанса TCP. CloudEngine зеркалирует пакеты TCP SYN, FIN и RST в коллектор iMaster NCE-FabricInsight. iMaster NCE-FabricInsight анализирует полученные заголовки для анализа процессов установки и завершения TCP-соединения между приложениями в сети, для получения пути пересылки, задержки пути, времени начала/окончания и количества байтов потоков TCP, а также аномальных сеансов TCP.

Внимательный читатель скажет: «Хорошо, с TCP-трафиком разобрались. А как же RoCE, который работает по UDP, или c VxLAN пакетами на уровне SPINE?» С ним мы тоже умеем полноценно работать.

Анализ TCP/UDP потоков на основе Edge Intelligence

Edge Intelligence (TAP) реализуется с помощью выделенного чипа на коммутаторе, цель которого – сбор и анализ потоков TCP/UPD, и экспорт результатов анализа в iMaster NCE-FabricInsight (TDA).

В отличие от анализа потока TCP, анализ потока UDP выполняется на основе детализации блоков. Edge Intelligence (TAP) при идентификации потока определяет порядковые номера UDP-пакетов. На основе этих номеров пакеты в потоке UDP группируются в несколько блоков. После получения согласованного потока UDP, TAP анализирует все пакеты UDP в первом блоке UDP и создает таблицу потоков на основе ключевых значений 5-tuple.

После получения таблицы потоков UDP, iMaster NCE-FabricInsight вычисляет информацию о потоке (включая количество пакетов, количество байтов и скорость) и качество пересылки (потеря пакетов и задержка) между каждыми двумя соседними устройствами на основе TTL.

Анализ TCP AnyFlow

При пересылке пакета, коммутатор CloudEngine с чипом Р5 анализирует пакет и создает аппаратную таблицу потоков на основе 5-tuple. По истечении определенного времени (flow table age timeout) коммутатор CloudEngine отправляет пакет с таблицей потоков в центральный процессор для анализа и предварительной обработки. Центральный процессор в первую очередь отправляет записи о аномальных потоках напрямую в iMaster NCE-FabricInsight для анализа и поиска неисправностей root-case. Затем центральный процессор сжимает все остальные записи потоков, генерирует таблицу статистических потоков и отправляет ее в iMaster NCE-FabricInsight для сбора статистики трафика и анализа тенденций. Дополнительно чип P5 коммутатора CloudEngine может обнаруживать аномалии при пересылке пакетов. При обнаружении аномалии (например, задержка в пересылке пакетов превышает пороговое значение или во время пересылки происходит потеря пакетов) чип отправляет аномальный пакет в центральный процессор для создания записи потока. Затем CPU создает таблицу потоков с аномальными пакетами и отправляет ее в iMaster NCE-FabricInsight для анализа перегрузки и потери пакетов при пересылке (см рисунок).

Ниже приведена сравнительная таблица по трем методам анализа

Какие устройства поддерживают TCP AnyFlow

В настоящее время TCP AnyFlow реализован в новейших моделях коммутаторов:

• CloudEngine 6866-48S8CQ-K

• CloudEngine 6866-48S8CQ-P

• CloudEngine 6868-48S8CQ-P

• CloudEngine 8851-32CQ8DQ-P

• CloudEngine 8851-32CQ8DQ-K

• CloudEngine 8868-32CQ8DQ-P

• CloudEngine 16804

• CloudEngine 16808

• CloudEngine 16816

Как начать использовать Ethernet NOF+

Ниже представлены модели коммутаторов, которые Huawei в настоящее время поставляет для нужд ЦОД. Устройства принадлежат к нескольким поколениям. Некоторые снабжены AI-чипами (Edge Intelligence), но все же не обладают всем спектром возможностей, которые демонстрируют новейшие коммутаторы на нашей собственной аппаратной базе. Если заказчик задумывается о переходе с Fibre Channel на Ethernet NOF+ с использованием наших СХД Dorado V6, то наилучшим выбором для него станут платформы, выделенные на схеме желтым цветом.

Модели CE6866, CE8851 также поддерживают технологию iLossless и хорошо подойдут для реализации BackEnd сети СХД на основе Ethernet NOF. CloudEngine 6866 является leaf-коммутатором с интерфейсом 25G в сторону клиента. CloudEngine 8851 — spine-коммутатор с интерфейсами 100G «вниз» и 400G «наверх». Мы называем этот дизайн 400G-Ready. Когда возникнут задачи построения сетей 400G, для них будет использовано как раз это оборудование, обладающее всем спектром возможностей, о которых рассказано выше.

Небольшой прикладной кейс

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

Мы полностью разработали дизайн и показали, как осуществить миграцию. После проведения PoC-тестов началась реализация проекта. Итоговый рост производительности сети составил 35–40% при значительном снижении совокупной стоимости владения инфраструктурой.

Здесь можно видеть конкретные результаты проекта. Как видите, совокупную производительность ЦОДа с учетом всех нагрузок удалось увеличить в десять раз, в том числе и за счет высвобождения ресурсов, прежде занятых обслуживанием сети.

Краткий вывод прост. Путь развития Fibre Channel довольно скоро приведет к тому, что даже самые мощные вычислительные ядра не смогут себя проявить из-за ограничения пропускной способности сети. Современный Ethernet в сочетании с решениями Huawei позволяет полностью решить эту проблему.