Комментарии 6
Почему мы не видим будущего за классическими FC-решениями? Дело в том, что они работают по принципу статического выделения кредитов, что требует настройки сетевой фабрики в соответствии с потребностями ваших приложений на ограниченный срез времени.
В последнее время FC шагнул вперёд к автономным сетям хранения данных, но продолжает нести в себе ограничения производительности. Сейчас мейнстрим — шестое поколение технологии, позволяющее добиться пропускной способности 32 Гбит/с, начинают внедряться и решения 64 Гбит/с. При этом с помощью Ethernet мы уже сегодня, используя таблицы приоритета, можем получить 100, 200 и даже 400 Гбит/с до сервера.
Прошу прощения, но в данном конкретном абзаце вы лукавите.
Поясняю:
1. Для одного порта 100/400Gbit/s не нужны, а если учесть что на стороне инициатора будет как минимум 2 порта, то 25/100 гигабайт в секунду ни один HBA/HCA не обеспечит. Всё упрётся в потолок скорости работы с ОЗУ на стороне сервера. И массив с одного контроллера, тоже не обеспечит такого потока.
2. Для SAN сетей измерение в виде пропускной способности, — маркетинговый ход, с попыткой низвести FC и вообще switched fabrics до уровня Ethernet. Сравнивать нужно IOPS и latency. Например, моя последняя сеть на ~1280 портов, построенная (не мной) на миксе 8G-FC и 16G-FC, обеспечивала более 20 миллионов IOPS, при этом не была нагружена до предела. Заменой 8G на 32G я озаботился, только из за EOS 8G оборудования. Также, ещё один пример, потребитель в одном ЦОД, используя массив(OceanStor) в другом ЦОД на дистанции 25km, имеет LUNs latency не превышающую 450usec, при этом 25км добавили 125мкс. Для БД это один из самых критичных параметров. И 400Гбит/с производительность не улучшат, т.к. всё равно, всё упрётся в латентность LUNs массива.
3. FC и switched fabrics в частности, гораздо проще в эксплуатации. Горизонтальное скаллирование за счёт добавления фабрик, может обеспечить практически любой throughput. Но на самом деле это не нужно. В рамках одного 32G коммутатора (Broadcom), можно обеспечить ISL 256Гбит/с. Два коммутатора (две фабрики) и это уже 500Гбит/с. Но в этих Гбит/с никакого смысла нет, т.к. см пункт 2.
4. У Huawei из за санкций проблемы с Broadcom, которая отказалась предоставить мне обновление FOS для OEM коммутаоров, купленных у Huawei. Может быть из за подобных случаев у ваших клиентов и позиции Broadcom, вы стремитесь перейти на открытые технологии? Не честнее было-бы об этом написать прямо?
ничего страшного, просите дальше:
1)немного голословно с вашей стороны. спец карты такие Mellanox CX и Huawei iNic для этих задач и создавались.
2)нет, нет, и нет. IOPS и Latency уже можно сравнивать не на уровне FC vs Ethernet, а на уровне FC и RoCEv2. Long Distance RoCEv2 также имеет свои задачи, но тут история про E2E Lantency не была раскрыта, т.к. писал про алгоритмы. Цифры так же интересные получаются. см рисунок:
3)У всех разные задачи, мы видим, что есть потребность у наших заказчиках. Именно в оптимизации. Масштабировать RoCEv2 намного проще, чем FC Fabric — задачи Merge/Enlarge не вызывают трудностей.
4)У вас устаревшая информация, мы продаем через наш канал OEM Brocade. По отказу в предоставлении прошивки — любопытно, конечно. Насколько я знаю — сейчас другая модель сервиса, здесь (по моему опыту)надо работать со своим менеджером плотнее, недопонимание — это вообще грустно.
1)немного голословно с вашей стороны. спец карты такие Mellanox CX и Huawei iNic для этих задач и создавались.
2)нет, нет, и нет. IOPS и Latency уже можно сравнивать не на уровне FC vs Ethernet, а на уровне FC и RoCEv2. Long Distance RoCEv2 также имеет свои задачи, но тут история про E2E Lantency не была раскрыта, т.к. писал про алгоритмы. Цифры так же интересные получаются. см рисунок:
3)У всех разные задачи, мы видим, что есть потребность у наших заказчиках. Именно в оптимизации. Масштабировать RoCEv2 намного проще, чем FC Fabric — задачи Merge/Enlarge не вызывают трудностей.
4)У вас устаревшая информация, мы продаем через наш канал OEM Brocade. По отказу в предоставлении прошивки — любопытно, конечно. Насколько я знаю — сейчас другая модель сервиса, здесь (по моему опыту)надо работать со своим менеджером плотнее, недопонимание — это вообще грустно.
немного голословно с вашей стороны. спец карты такие Mellanox CX и Huawei iNic для этих задач и создавались.
Создавались. Возможно я ошибаюсь, но вы цифр не приводите. HCA x16 PCI-E? Сколько GT/s обеспечивает PCI-E 3.0/4.0? A сколько обеспечивает ОЗУ? А ограничения накладываемые ОС?
Покажите результаты тестов массива, который на одном порту одного контроллера в состоянии throuput 100ГБ/с (не гигабит, а гигабайт) выдать, я просто не встречал таких. Буду признателен за информацию.
Приведённые вами картинки, с графиками, также маркетинг. PDF с полным disclosure тестов есть? Какие конфигурации фабрик и как сравнивались, на каком железе?
У вас устаревшая информация, мы продаем через наш канал OEM Brocade
Дело было летом. Brocade отказался поддерживать коммутаторы встроенные в ваш E9000, ссылаясь на санкции и заявление об отказе работы с Huawei. TAC Huawei, выслал прошивку FOS выложенную на диске yandex…
А ещё, как вы боретесь с задержками накладываемыми стэком TCP/IP в ОС? Как при этом получаются чудеса с вдвое лучшей латентностью?
The RoCE v2 protocol exists on top of either the UDP/IPv4 or the UDP/IPv6 protocol.[2] The UDP destination port number 4791 has been reserved for RoCE v2.[10] Since RoCEv2 packets are routable the RoCE v2 protocol is sometimes called Routable RoCE[11] or RRoCE.[3] Although in general the delivery order of UDP packets is not guaranteed, the RoCEv2 specification requires that packets with the same UDP source port and the same destination address must not be reordered.[3] In addition, RoCEv2 defines a congestion control mechanism that uses the IP ECN bits for marking and CNP[12] frames for the acknowledgment notification.[13] Software support for RoCE v2 is still emerging. Mellanox OFED 2.3 or later has RoCE v2 support and also Linux Kernel v4.5.[14]
по пунктам:
1)Подробные тесты мы выпускаем через Tolly, например. Там есть общая диспозиция по железу. Последний открытый тест — сравнение с Eth/IB. По FC, насколько мне известно — результаты еще не опубликованы.
Но общий формат оценить можно уже сейчас — reports.tolly.com/DocDetail.aspx?DocNumber=219119
2)Про задержки — это классический вопрос — здесь магия не в сети, а в приложении, которое отдает трафик напрямую в iNic. Здесь принцип RDMA является главенствующим, а не сеть. На уровне сети наша задача корректно отработать этот трафик.
Чуть больше по линкам:
e.huawei.com/en/material/networking/dcn/be80bbc977ac49afa73851e3d176dd6b
e.huawei.com/en/material/networking/dcswitch/a7d33936b84e4ffaa76474d607f2572f (тут 6 слайд)
1)Подробные тесты мы выпускаем через Tolly, например. Там есть общая диспозиция по железу. Последний открытый тест — сравнение с Eth/IB. По FC, насколько мне известно — результаты еще не опубликованы.
Но общий формат оценить можно уже сейчас — reports.tolly.com/DocDetail.aspx?DocNumber=219119
2)Про задержки — это классический вопрос — здесь магия не в сети, а в приложении, которое отдает трафик напрямую в iNic. Здесь принцип RDMA является главенствующим, а не сеть. На уровне сети наша задача корректно отработать этот трафик.
Чуть больше по линкам:
e.huawei.com/en/material/networking/dcn/be80bbc977ac49afa73851e3d176dd6b
e.huawei.com/en/material/networking/dcswitch/a7d33936b84e4ffaa76474d607f2572f (тут 6 слайд)
Спасибо. Интересно.
> здесь магия не в сети, а в приложении, которое отдает трафик напрямую в iNic. Здесь принцип RDMA является главенствующим, а не сеть.
Т.е. приложение должно уметь работать с IB verbs? Или в случае с СХД, этим занимается драйвер?
Если не сложно укажите, какие модели iNIC (не 10Gb), сейчас доступны к заказу?
И ещё вопрос. Нужно-ли строить отдельную сеть с RoCEv2 aware коммутаторами, или можно строить сеть хранения данных поверх существующей сети?
Т.е. учитывая что изначально заложена возможность маршрутизации трафика т.к используется IP стeк, должны-ли коммутаторы и маршрутизаторы знать о RoCEv2?
> здесь магия не в сети, а в приложении, которое отдает трафик напрямую в iNic. Здесь принцип RDMA является главенствующим, а не сеть.
Т.е. приложение должно уметь работать с IB verbs? Или в случае с СХД, этим занимается драйвер?
Если не сложно укажите, какие модели iNIC (не 10Gb), сейчас доступны к заказу?
И ещё вопрос. Нужно-ли строить отдельную сеть с RoCEv2 aware коммутаторами, или можно строить сеть хранения данных поверх существующей сети?
Т.е. учитывая что изначально заложена возможность маршрутизации трафика т.к используется IP стeк, должны-ли коммутаторы и маршрутизаторы знать о RoCEv2?
По IB vs RoCEv2 — они похожи верхним слоем, т.н. RDMA API (Verbs) — так корректнее.
И да, приложения должны уметь работать с RDMA.
Карты на СХД должны поддерживать RoCEv2, к примеру на Dorado v6 — уже есть такие.
Если их не было можно добавить.
Поддерживаются карты Mellanox CX-4/5/6.
С точки зрения приложений — уже поддерживается на срезе:
P.S. Для сравнения цифр, приведенных выше использовалась эта топология:
P.P.S. Коммутаторы должны знать о RoCEv2, но можно ( а иногда и нужно) совмещать в одной сети разный траффик. Маршрутизаторы работу с RoCEv2 не поддерживают сейчас.
P.P.P.S. Вот также карта паритета сервисов:
И да, приложения должны уметь работать с RDMA.
Карты на СХД должны поддерживать RoCEv2, к примеру на Dorado v6 — уже есть такие.
Если их не было можно добавить.
Поддерживаются карты Mellanox CX-4/5/6.
С точки зрения приложений — уже поддерживается на срезе:
P.S. Для сравнения цифр, приведенных выше использовалась эта топология:
P.P.S. Коммутаторы должны знать о RoCEv2, но можно ( а иногда и нужно) совмещать в одной сети разный траффик. Маршрутизаторы работу с RoCEv2 не поддерживают сейчас.
P.P.P.S. Вот также карта паритета сервисов:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Искусственный интеллект в сети ЦОД: опыт Huawei