> его необходимость вообще малопонятна.Представь что у тебя есть 2 ToR-свитча в MLAG и 4 порта по 25G на сервере, ты воткнул это всё и настроил на коммутаторах LAG, раздаёшь LACP, и у тебя транк в котором VLAN-ы.
А еще у тебя настроен CoS на резервирование 50% буферов на 4-й очереди. И есть PFC c разносом это по приоритетам 802.1p и есть ETS, анонсирующий очереди коммутатора в DCBX и у тебя заведены в коммутатор соответствующие TLV или используются автоматические TLV (зависит от марки/модели свитчей). Ты получил свою lossless-очередь, и вот теперь ты её шейпишь сверху до 50G. А ну и серверов у тебя таких, например 4 штуки.
В этой ситуации в приоритете 4 у тебя есть VLAN пригодный для задач RoCE.
И вот на этих серверах у тебя сторадж поверх SMB в triple mirror. Диски и NVMe-кэш, ясен пень у тебя в серверах локально.
В этой ситуации у тебя сохраняется проблема единого логического линка LACP, потому что MLAG даст тебе балансировку при переходе траффика из ToR в Spine. Вот тут-то ты и утилизируешь свой мультиканал.
> типа vpn
Вообще, я бы не рекомендовал использовать RoCE, а применил бы RoCEv2 как раз из-за работы по UDP/IP.
У тебя тогда может быть даже не 1 LAG на 4 порта, а 2 по 2. В первом у тебя данные, а во втором сторадж. Причем в LAG для дранных приходит trunk, а LAG для стораджа может быть в access. И у тебя настроен мапинг DSCP в 802.1p, например CS6 -> 4. И ты классифицируешь траффик по DSCP с нетегированного порта (а сервак настроен это правильно помечать) и привязываешь это к PFC/ETS/DCBX.
Разница будет как раз в поведении во всяких VPN. Представь что у тебя есть второй ДЦ в котором всё то же самое и есть несколько L2VPN. И вот в первом случае ты гонишь тегированный трафик с PFC через L2VPN с использованием мостов на обоих сторонах. Тегированные VLAN-ы с lossless-траффиком попадают тегированными в мост. И вот в случае RoCEv2 у тебя... обычный IP траффик с DSCP пометкой в обычной VPN. Очереди на роутерах ты опять настраиваешь сам.
В этом случае задача не обязательно миграция данных. Это может быть единый кластер на двух локациях присутствует в виде зеркала для задач отказоустойчивости. То есть это еще одно зеркало "единого стораджа" не будет, задержки там тоже не так важны.
Ключевая разница в том, что у тебя может быть несколько VPN, но сеть сеть не применяет ECMP-роутинг. И вот тут опять тебе на выручку приходит мультиканал.
Для юзера, который ходит на шару в формате \\hostname это всё действительно малопонятно, но вот если у тебя есть Scale-Out кластер с этой шарой на которую ты бекапишь это всё, то мультиканал вновь обретает смысл.
> Переизобретатели tcp - они по другому не умеют.
Переизобретатели TCP изобрели iWARP и предлагают совать TCP over TCP для передачи файлов и блочных данных. Intel уже вроде отказался от своих велосипедов, а Chelsio не унимается. Я даже не буду рассказывать какой там монстр получился, сам почитай. Киллерфича в том, что мы хотим как Infiniband, но не будем настраивать CoS на коммутаторе, авось и так проканает. Ведь у нас TCP и гарантированная доставка. А потом, когда невменяемые задержки такого стораджа поверх iWARP шатают производительность всего что с ним работает предлагают... ты не поверишь... заплетать косы на коммутаторах да не как-нибудь, а именно через Data Center Bridging, то есть именно то что нужно было изначально для UDP-решений. С чем боролись на то и напоролись.
Одно радует, что великодушный Microsoft позаботился о бомжах^W дауншифтерах и теперь выпускает SMB over QUIC (iWARP от этого станет лучше) еще и с поддержкой Let's Encrypt. Я сейчас не шучу. Это новая версия SMB в Server 2022.
А вообще ты прав, эти технологии при неправильном использовании так фигурно могут положить (поставить на паузу) целый сегмент сети или сожрать траффик в VPN. Но тут проблема прямоты рук, точки роста рук и, немножечко, мозгов.
> Мда... как все же жаль, что мне не удалось сохранить третью версию сосамбы в живом виде :-(
Раз Microsoft столь великодушен к бомжам^W дауншифтерам, то может это всё запилят в форме модуля ядра, чтобы потом можно было это юзать мимо монструозной сосамбы 4...
