0: Ну, приветствую, коллеги. Да, я Борис, судя по всему, это все, кто как-то связан хоть немножко с сетями и кому там что-то, в общем, потенциально может быть интересно.

1: Вот. Ну хорошо, хорошо, что хоть столько людей набралось. Так, ну, про себя там пару слов, если с кем-то я не знаком. Ну, в сетях я очень давно начинал с рабо.

2: В системном интеграторе, потом в разных вендорах сетевого оборудования работал, потом перешёл в яндекс, в ног, там был сетевым архитектором. Вот сейчас сетевой архитектор в. Мвс клауда.

3: Участвую также, да, в работе атф, то есть та организация, где наши всякие стандарты, связанные с интернетом, разрабатываются там в нескольких рабочих группах, там соавтор рфси. Но это не буду повторять. В общем, есть

4: Там определённые профессиональные интересы, в 1 очередь трафик инжиниринг.

5: Ну и на этом, наверное, хватит про себя. Давайте дальше пойдём. Доклад у нас сегодня такой достаточно объёмный, будет очень непросто мне его уместить в заданное время. Не буду это все содержание повторять. То есть мы

6: Начнём как бы с проблематики, которая существует при использовании, значит, при развёртывании, а либо мл. Нагрузок в сетях цода.

7: Какие есть, коротенько упомянем существующие решения, какие у них ограничения, скажем так, значит, почему появилась вот как бы новая организация, да, вот этот ultra изернет консорциум, надо обязательно, как бы про это сказать, про

8: И дальше пойдём уже потихонечку. Значит, по архитектуре ультра изернета, как он соотносится как бы с обычным. Изернетовский, её небольшой опрос. Коллеги, поднимите, пожалуйста, руки. Те, кто слышал, что

9: Такое семиуровневая модель osi iso. Браво, браво. Вот вот мы будем, так сказать, по этим уровням идти и так смотреть. В общем, как это все соотносится.

10: Ну, поехали, и самая сложная часть будет в конце. Это заранее дисклеймер там.

11: Значит, ну, начнём, значит, я вот так попытался тоже, значит, ну, сделать какую-то вводную часть, подводку, как бы, к основной технологии сделал некую таблицу сам, по сравнению некоторых имеющихся лм, моделей, ну,

12: Естественно, на основе публичной информации, которая доступна, то есть можно увидеть список моделей, сколько там параметров? Миллиардов, да, как бы размеры градиентов и расчётные требования к сети.

13: В режиме обучения и в режиме инференса это такая как бы базовая подводка, чтоб от которой мы оттолкнёмся. Я попытался дальше это ещё более немножечко сузить, чтобы было более просто смотреть. То есть мы

14: Видим, что в процессе обучения, ну и мы это сейчас рассмотрим, почему у нас очень высокие требования к полосе пропускания, потому что нам надо прокачивать через сеть очень большие объёмы трафика, да, наши вот эти градиенты

15: В режиме инференса, чуть чуть поменьше требования, потому что модель уже обучена, естественно, меньше объёмы данных, но есть, соответственно, требования к детерминированной задержке, к надёжности, к вариации задержки. Методология, как бы моих расчётов ни

16: Описано, я не буду сейчас её повторять. Кто захочет, может посмотреть, может быть какой-то потом свой вариант предложить. И ключевой вопрос, да, когда, ну, естественно, у меня он тоже возник, собственно говоря, почему такие большие требования?

17: Полосе пропускания предъявляет именно там i мл. Нагрузки, ну и как бы ответ, к которому я пришёл, так сказать, что у нас много параметров, естественно да, для обучения моделей естественно 1.

18: 1 вычислитель, да, 1 ускоритель, он не в состоянии все эти параметры перемолоть, значит и обработать. Поэтому нам нужно какое-то их распределение, какая-то параллелизация. И поэтому пришла как бы индустрия, значит,

19: Piece к коллективным операциям, да, когда у нас множество разных там gpu или x пию, как мы их там не называем, работают над 1 задачей, соответственно, тут просто небольшой обзор я как бы тут как бы не ставлю.

20: Задачу. И собственно я не та, не тот человек, который должен про это там математику рассказывать, просто в контексте опять же сетей да, основные коллективные операции, которые влияют и как бы выкатывают дополнительные требования к сети all reduce.

21: Да, когда у нас мы локальные градиенты вычисляем на x пию, отправляем другим, получаем обратно да собираем Гавер.

22: Reduce катер операция когда нас мы части да распределяем между gpu бро отказ когда нам нужен так сказать какой-то параметр вес раскатить всем.

23: И если так, опять же, очень базово, так сказать, накидать типичный цикл обучения лм, да, то есть это прямой проход, обратный проход. И вот эти вот там редьюс, катер, градиентов операции в собирание.

24: Результата и обновление весов. И тут как бы естественно возникает задача, как это нам, так сказать, распределить между нашими тысячами джипию. Опять же, умные люди пришли к, надеюсь, видно, да, концепции

25: Параллелизма которых да, 3 основных параллелизм данных, значит, когда запускаем, да, на нескольких gpu модельку, потом каждая делает свою часть синхронизируем градиенты.

26: Из моделей, которые, да, там тоже как минимум на 2 делятся тензоры и конвейерный параллелизм, и гибридный, когда мы, так сказать, совмещаем вот эти 2 варианта, тут вот иллюстрация, опять же, да, не будем тратить время на

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

28: Сети, опять же, да, 1, параллелизм данных. Больше всего параметров передаются, поэтому самые большие требования к полосе пропускания. И как бы сложность ещё в том, что там чем больше модель, как бы, чем

29: Больше параметров, то есть у нас линейная зависимость и, соответственно, также возрастают требования к полосе пропускания.

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

31: Что мне было тоже интересно, как сетевику, когда я стал как бы смотреть вот в эту механику, и, ну, какие-то у меня тоже начались, так сказать, аналогии в голове возникать, что при вот этих вот коллективных операциях, да, у нас

32: Ключевая роль как бы ложится на вот эти вот библиотеки коллективных операций, там, nvidia или каких-то других, так сказать, вендоров. В общем, неважно, какие и они у нас становятся таким ключевым интеллектуальным звеном, да, в

33: В процессе, на которых начинают запускаться определённые алгоритмы. Вот, типа там, ринг или 3, да, по объединению, да, вот этих gpu, так сказать, в нужную топологию, в зависимости от каких-то требований, значит, этой модели и у

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

35: Граф, да, так сказать маршрутизаторов Линков здесь у нас как бы ну вот у меня почему-то такая аналогия может у меня уже профессиональная деформация, что, ну вот как бы gpu он тоже становится вот таким вот, как бы точнее нисил становится таким вот, как бы логи.

36: Условным маршрутизатором, да, который вот эти вот как бы цепочки джипию просчитывает и соответствующие топологии как бы выстраивает и определяет.

37: Что было ещё интересно лично мне с чем вот я хотел поделиться, что как бы изначально, когда вообще вот там высокопроизводительные вычисления, так сказать, методологические определяли вот этих коллективных операциях.

38: Было достаточно много в процессе, как бы, когда мы стали двигаться не просто как бы эйчписи, а к amel мы стали как-то оптимизировать это количество. Вот специально мне очень понравилась эта картинка, она может быть тут много всяког

39: Но видно, что уменьшилось количество коллективных операций, уменьшилось количество поддерживаемых топологий. То есть мы как-то старались упростить, да, видимо, за счёт этого повысить эффективность. При этом, соответственно, какие ещё тенденции, что у нас

40: Естественно, там не только nvidia, есть ещё какие-то коллективные библиотеки, и, естественно, как бы с точки зрения аппаратного обеспечения у нас тоже как бы произошло некоторое расширение. Сейчас мы

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

42: Коллективных библиотек, которые, так сказать, ну бы формируют условно свой контрол плейн, свою плоскость управления. И основная проблема в чем, что, во первых, вот эти вот коллективные операции, особенно многоточечные, как бы они хороши с

43: С точки зрения как бы, логики работы этой библиотеки, но с точки зрения сети, вот как бы того, что мы сейчас имеем, там, tcp udp квика наших обычных транспортных протоколов, они на многоточечные коммуникации вообще не заточены, да, у нас там точка, точка, да, как бы.

44: Поэтому, как бы, получается такое, так сказать, некий, ну вот есть такой английский термин шипс, н the night, то есть, как бы вот параллельно существующие, как бы независящие друг от друга плоскости, семантику, никто этих коллективных сообщений, у нас сетевые устройства.

45: Ничего не понимаешь, что за там редьюс, там скатер, что это, это что то где-то во вне, да, это где-то, так сказать, мы ничего про это не знаем, и мы не можем наш, нашу сеть как бы подстраивать под требования этих коллективных операций, ну,

46: Опять же, да, вот получается независимые плоскости, что там, какая блокирующая операция, какая неблокирующая, опять же, тоже с точки зрения сети, мы про это ничего не знаем, ничего не понимаем и оно как-то во вне должно само там обрабатываться и опять

47: Топология да, про что мы говорили вот эти коллективные операции топологии с gpu логические вот в моделях, которые используют архитектуру там микшеров эксперт да, есть даже такой логический компонент маршрутизатор у меня.

48: Тоже сначала была такая как бы идея, что, так сказать, как-то подтащить под это наш традиционный сетевой маршрутизатор, но нет, это часть как бы нейронки, да, то есть это, это ни разу, так сказать, не то, что мы под маршрутизатором понимаем в сетях опять же.

49: Как бы он на своём уровне как-то, так сказать, может учитывать топологию в сети. Мы про, так сказать, то, что он учитывает, не знаем. То есть у нас полностью разделённые плоскости. То есть сеть это как бы вроде очень важный механизм, который должен перекачать этот трафик.

50: Обеспечить полосу, задержку, там, вариацию задержки но при этом она как бы такая, так сказать, как кукла, которую надо дёргать, да, вот она, так сказать, дай мне полосы на тебе полосу там но вот это вот совместить невозможно и дальше

51: Пробуем, так сказать, подвести, почему, как бы, как ultra изернет на эту проблематику отвечает ещё важный момент. Вот, товарищи, там ссылочка есть. В статье провели исследование, какие флоу, какие потоки есть в обычной сети и вот в сети

52: Центров обработки данных, где есть загрузки, то есть в обычной сети. У нас много мелких и средних потоков с такой, как бы, ну, условно скажем, небольшой полосой пропускания. В случае мл, у нас как бы инверсная картина у нас

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

54: Крайне остро встаёт проблема эффективной балансировки трафика, потому что у нас много вот этих так называемых элефант слоу, да, флоу с большой пропускной способностью. Если какой-то линк сейчас мы про это чуть дальше поговорим.

55: Почему это может произойти? Перегружаются, возникают потери, да, то есть какие какая-то часть фреймов пакетов теряется джипу в рамках или x pure коллективных операций должны проводить вот эту синхронизацию, да, если она не

56: Произошла, мы ждём, да, пока, так сказать, вот проблемный джипию, так сказать, реанимируется. Все ждут как бы простой приводит к потерям, да, в 1 очередь, в конце Концов, скажем так, к денежным потерям, да, потому что мы нашу

57: Инфраструктуру, так сказать, не используем эффективно. Поэтому в рамках эволюции вообще архитектур сетей, она, как мы стали подстраиваться под вот эти новые загрузки, ну вот там вот для меня справа

58: Для вас слева картинка традиционная, то, что мы называем кло, топология или close ещё по-русски, то есть, ну, кло, потому что, так сказать, французские, можно сказать, инженеры это придумали, та топология, которой 100 лет в обед, она с пятидесятых годов используется её

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

60: Концепт переиспользовали в архитектуре сетей цода уже очень давно, так сказать, все её используют у нас есть сервера с цпу, которые подключаются к нижнему уровню коммутаторов, их называют top рек или ещё leaf, лист коммутаторы.

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

62: Как только у нас появилась амл нагрузка, что, так сказать, у нас появились джипию, поэтому для, как бы, создания мощного узла мы стали делать отдельную джипию фабрику. То есть, ну, как правило, это, так сказать, вендоро, специфичное решение, там, как

63: Какой-нибудь инвелинг, прошу прощения, вот или что-то в таком духе.

64: И для того, чтобы, соответственно,

65: Gpu мы как бы коммутируем через свою выделенную фабрику, а сами наши сервера с gpu объединяем через вот эту эйчписи сеть, про которую мы поговорим чуть дальше инфинибенд и вот она и таким образом у нас получилось 3 сети.

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

67: Фабрики тоже, то есть фронте, бэк про проблемы инфини Бенда мы поговорим дальше или ограничения, скажем так, но основной как бы ограничитель это то, что, собственно говоря, инфинибенд мы можем строить только на

68: Оборудование 1 вендора не будем называть фамилии, но известно, что это nvidia, поэтому, естественно было желание, что как-то, так сказать, все-таки попытаться бэкэнд перевести на изернет на традиционную вот эту вот.

69: Архитектуру

70: Для этого, соответственно, значит, немножечко меняется конфигурация в сервисе gpu и cpu, но появляются как бы смарт Ники, более производительные адаптеры, но логика да, теперь, то есть backend.

71: Сеть как бы в идеале ушла от инфинибенд, перешла на изернет, осталась джипию фабрика, осталась фронт, сеть. То есть это вот те вот как бы эволюция архитектуры, которая произошла с появлением джипию.

72: Упс. Пардон, здесь такая суммарная резюмирующая таблица вот этих вот как бы произошедших изменений, что была 1 общая сеть, да, как я на картинке там показывал для всего, да, для в цоде она

73: Поделилась на scale up scale out вот этот фронт про что мы говорили бэкэнд сеть была многоуровневая кло архитектура в зависимости от требований масштабирования то есть про это

74: Кому интересно про вот эти вот как бы реальные топологии таких многоуровневых сетей на конференции яндекса некс коп. Дай Бог памяти. В 2019 году мой тогдашний коллега Дмитрий Афанасьев сделал как раз отличный доклад про вот эту архитектуру.

75: Сети яндекса. Там это все очень подробно описано. Здесь мы лимитируем количество уровней 2, чтобы уменьшить задержку. Помните, там требования достаточно жёсткие по задержке, опять же от вот этих вот коллективных операций, поэтому только 2 уровня

76: Мы не растём вверх, но для того, чтобы нам масштабируемость обеспечить, мы, во первых, делаем многоплоскостные сети. Если сюда быстро вернуться. То есть у нас не вот 1 такая вот как бы плоскость истории спайн, а будет нескольк.

77: Параллельных вот так вот как бы плоскостей. Если нам нужно, значит, увеличить масштаб. Есть вот это мультирег, подключение, когда каждый вот этот вот интеллектуальный сетевой адаптер, там свой Свич. В общем, мы пытаемся как бы распараллелить эту нагрузку.

78: Сервера.

79: Функционал коммутаторов, который нужен как бы в обычной облачной сети балансировка в 1 очередь типа про это поговорим.

80: Транспортные протоколы. И вот видно, масштабы цона. Я просто хотел, чтобы вы сравнили, да, то есть там десятки тысяч, сотни тысяч серверов тут уже у нас возникают за счёт того, что у нас увеличивается количество вот этих экспи ю джипию. То есть у нас уже миллионные масштаб.

81: И, естественно, растёт размер 1 потока.

82: Очень коротко про инфинибенд, опять же, не буду повторять. То есть это совершенно как бы параллельная, независимая технология, у неё свой физический уровень. Видно, здесь канальный, сетевой, транспортный, своя маршрутизация. То есть это как бы с эзернетом вообще никак.

83: Она, так сказать, просто как бы параллельная сущность. Изначально её придумали для как раз эйчписи, условно можно сказать, 25 лет тому назад разные топологии могут быть, маршрутизация решается, как бы она централизованная, там есть такой, как бы

84: Контроллер, вот, либо вендорский, либо опенсорсный, который как бы выбирает протокол маршрутизации, опять же, в зависимости от эйчписи, как бы задачи. И вот формирует эти таблицы, выбирает протокол маршрутизации, в общем, для коммутаторов, то есть

85: Вот этот интеллект он не распределённый, а в controller, nvidia, как я уже сказал, производит все, про инфини больше не буду говорить, опять же, вот здесь есть ссылочки, вот мой коллега Роман Глебов отличные доклады делал вот на nex копе он сегодня здесь будет.

86: Вечером выступать, всем рекомендую послушать.

87: Естественно, как я говорил, было стремление, что все-таки давайте от вот этой вот пропитанной инфинибенд, как бы все-таки что то попытаемся реализовать на изернет, поэтому придумали, как бы вот эту концепцию рдим, да, то есть прямой акцесс доступ к памяти через изернет, когда

88: Мы брали вот этот вот инфини, эндовский, как бы пелот сначала просто запихивали его в л 2 изернет фрейм, ну, как бы, который, типа, контейнером, так сказать, для передачи. Но как мы прекрасно знаем, да, у нас, значит, вот если мы используем фреймы, это 2

89: Уровень, он работает только в рамках 1 2 домена. Никакая маршрутизация невозможна сразу ограничения по масштабируемости и так далее. Поэтому от тройки версии 1 перешли к версии 2, когда мы для того, чтобы иметь возможность

90: Сегментировать, маршрутизировать добавили udp как прокси ip и опять изернет.

91: Какие у нас есть недостатки? Тоже очень коротко. Соответственно, ну, старая технология, концепция, да, не, то есть без фабрика, без потерь, значит, где есть вот этот приорити флоу, контрол меха.

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

93: Там как бы различные проблемы в сети такой концепции 1 из проблем это what had оффлайн блокинг, когда у нас несколько флоу проходят через один и тот же порт коммутатора, если 1 flo как бы, значит соответственно блокируется.

94: И мы блокируем в итоге весь порт целиком, и все остальные флоу, которые вроде, ну, как бы, были нормальные, да, мы их тоже, так сказать, останавливаем, возникают всякие вот эти синхронизации, там, tcp и так далее, и так далее. То есть и особенно все это.

95: Проявляется с Ростом масштаба. Поэтому вот резюме, что вот текущие архитектуры, они по своей природе не рассчитаны на вот этот масштаб, который есть у больших мл кластеров.

96: Почему родилась? И вот отсюда становится понятным, почему родилась новая технология. То есть, когда придумывали, значит, инфинибенд у нас был, соответственно, простые сетевые технологии, но была сложность с вычислительными ресурсами, да, то есть было время, процесс

97: Процессоров пентиум, условно говоря, вот, соответственно, какие-то сложные вычисления на них высокопроизводительные было не так-то просто организовать, поэтому пришли к тому, что контрол плейн должен быть проще сейчас за счёт опять же, вот этих

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

99: 100, там 200, 400, 800 гигабит скорости поэтому мы можем как бы перевести эту проблему, как бы усложнения на контрол плейн, да, на более умные протоколы, соответственно, как появил

100: Ультранет, то есть вызов понятен, да, то есть существующие архитектуры с этим масштабом не справляются и не могут справиться привязка к конкретному вендору. Поэтому, ну, значит, другие вендоры подумали, а что мы тут, как бы, так сказать, отдых

101: Да, есть большой рынок. Давайте мы как-то тоже попытаемся так сказать прийти к этому. Поэтому вот эти вот товарищи там amd broadcom и прочие значит hp собрались в 22 году что давайте все-таки какой то открытый стандарт придумаем.

102: Сначала хайперв назывался, потом в ультранет переименовали, то есть сформировали консорциум, то есть, да, объединение, так сказать, свободное участников, да, для решения вот какой-то 1 задачи были дискуссии, что давайте, может быть, рокки попробуем, там, как-то, что

103: Придумать и перестандарты овать, либо сделаем что-то с нуля решили делать с нуля новую архитектуру. И вот в начале 2023 года махнули шашкой, все-таки, так сказать, объявили, что будем делать новый масштабируемый транспорт

104: И, собственно, официально, так сказать, объявили в 23 году о этом консорциуме, как, из чего он состоит, да, как бы логически, ну, естественно, да, рабочие группы по разным направлениям, там, по софту, по транспорту, по каналам данных, по физике.

105: И так далее, в которых, да, так сказать, вырабатываются те или иные архитектурные решения.

106: Какие основные задачи? То есть реализовать масштабируемую архитектуру, про что я говорил дальше не буду вот это все перечитывать. И крайне важный момент, что нам нужна совместимость изернет. Мы не можем сделать ещё 1 инфинибенд, который будет вообще, так сказать, независим. У нас есть вот

107: Это база изернет и нам желательно по максимуму её переиспользовать. Поэтому с точки зрения ultra изернет, он, в принципе как бы ориентируется вот на ту же архитектуру, которую я раньше показывал. То есть вот есть капли, локальная сеть, цпу и вычислители.

108: Соединяет. Вот, и она вот с таким фиолете фиолетовый, да, наверное, цвет показано, есть. Соответственно, бэкэнд скаут сеть это вот та сеть, которая соединяет акселераторы, и мы на неё. Вот в 1 версии специфика

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

110: Не буду это все перечитывать. Явно слайд, конечно, получился перегруженным. То есть, что нам нужно? Нам нужно, чтобы у нас как бы ядро новой архитектуры поддерживало этот масштаб. Поговорим дальше, за счёт чего он реализуется? За счёт чего обеспечивается производитель?

111: Как безопасность и как вообще экосистема в результате выглядит.

112: И я уже немножко говорил, да, помните, когда были графики, как бы потоках в Цодов, значит, и говорил про важность балансировки, то есть как работает балансировка сейчас в наших как бы традиционных апи сетях, да, у нас есть несколько параллельных маршрутов до 1

113: И того же префикса иквел кост молтипа они в rip существуют да, в маршрутной таблице, потом фип как бы соответственно программируется дальше есть какие-то flow, сорс, дестинейшн.

114: Адресами, портами и транспортным протоколом включается хэш функция, которая вычисляет в зависимости от этих 5 параметров, какой интерфейс будет использоваться на выходе.

115: Если у нас нет энтропии, вот в этих параметрах у нас возникает так называемая поляризация, когда у нас хэш как бы начинает многие флоу пихать в один и тот же линк, то есть 1 линк получается забит, остальные не догружены.

116: Как ultra изернет, решил вот эту как бы проблему решать, которая очень остро вот в цодах, а давайте каждый источник, то есть каждый наш, условно ник интеллектуальный, да, будет вот эту энтропию от себя, так сказать, генерит.

117: То есть, давайте мы выберем какой-то вот параметр, ну, например, там destination, то есть udp порт, как интервью, и будем его менять таким образом. Соответственно, у нас каждый пакет отправляется по

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

119: Ultra изернет сразу решил давайте мы, так сказать, определим какие-то значит ориентиры, когда что использовать значит как поднастраивать в зависимости от конкретной, от конкретной нагрузки и сказали, что вот будет эйчписи

120: И профиль, который ориентирован на он самый максимальный по фичам и ориентирован на вот эйчписи задачи значит, на суперкомпьютерные задачи есть и для ai ml как бы сделали 2 отдельных профиля Бейс и full.

121: Значит, там у них уже поменьше функционала. Не буду это все перечислять. Суть в том, что у каждого из этих профилей при настройке, да, грубо говоря, либо в конфигурации там сетевой карты, либо, в, значит, некая система оркестрации должна это

122: Будет есть определённый приоритет. И вот эти наши конечные точки, то есть nicki, они там феппо называются фабрик, значит, эндпоинты, они вот эти параметры могут согласовывать. То есть, допустим, я поддерживаю эйчписи и айфу, а я поддерживаю

123: Full и Айбес, ну, значит, и айфу как бы общий. Мы, соответственно, договариваемся про его использование.

124: И переходим к самой архитектуре. Вот как-то, конечно, время очень быстро бежит. Соответственно, очень коротко с точки зрения физики, как бы использование изернета все остаётся по прежнему. То есть ultra изернет, не изменяет, он не придумывает, новый изернет все

125: Остаётся по прежнему, соответственно, цель обеспечить совместимость существующей, значит, инфраструктуры. Вот некоторые там предложения с точки зрения трансиверов, что там 100 гигабит на lane, там, чтобы сразу стартовать с 400 гигабитного, значит,

126: Интерфейса 200 гигабит, чтоб, например, на 800 перейти, соответственно, преимущество, да, поэтапное развёртывание без замены.

127: Наших коммутаторов. Так, опс куда-то я убежал. А с точки зрения канального уровня дейта линк он тоже остаётся, по сути, как бы как был в изернет, так есть. Но появляется вот то, что зелёненьким показано 2 опциональных протокола.

128: Работающий на канальном уровне кредит Бейс, флоу контрол и lynch левел ретрай они опциональны как бы если switch адаптер поддерживают, они будут работать, если нет ну значит, можно без них.

129: 3 уровень по большому счёту он тоже остаётся без изменений как мы использовали ip в 4 айпи в 6 мы также используем как использовали мы протоколы маршрутизации те или иные в soda там биджипи, например так e используем, ультра изернет.

130: В это не лезет, как бы вот оно как есть остаётся. Опять же, нам нужно как бы вот эту вот обеспечить совместимость.

131: Ну, есть некоторые, как бы, фишечки, значит, которые тут появляются, например, пакет тримминг. То есть, опять же, решение проблемы, значит, переполнения буферов. Если раньше у нас буфер переполнялся, мы сбрасывали пакет.

132: И получатель как-то по таймауту должен, а че то не то, да, так сказать, произошло. А давайте мы ускорим, потому что мы не можем больше ждать у нас. Помните, требования по задержке, нам надо это быстрей, поэтому пусть коммутатор при заполнении буфера данные отбросит.

133: Вот, а заголовок пошлёт получателю и скажет товарищ пакет не дошёл до тебя, запроси его перед повторную передачу. Вот эта идея.

134: Самые драматические изменения, которые ультра изернет, приносит. И вот это действительно там революционные, там, можно сказать, изменения это транспортный уровень. Все, прощайте, тисипи, ютипи и quik все, их больше нет, теперь появляются, значит, новый тран.

135: Транспорт с 4 подуровнями, семантический доставки пакетов, пакет деливери, управление перегрузками кондишн менеджмент и transport security и в результате как бы транспорт состоит из 4 транспорт.

136: Протокол как бы состоит, то есть мы опять же сделали вот эту вот как бы дезагрегацию, можно сказать, по функционалу на разные подуровни.

137: Это такая сложная картинка. Я, может быть, зря её просто скопипастил. Надо было самому здесь просто более подробно указаны. Значит, вот эти вот подуровни, и что они делают вот в этим зелёненьким? То есть роль семантики. Помните, я говорил, что проблема, что суще?

138: Существующие сети, вот эту семантику коллективных операций, они вообще не понимают, как бы, как там эти сообщения, какие они блокирующие. Это все как бы разные плоскости. Здесь сделана попытка на уровне транспорта нашу сеть сделать готовой для понимания

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

140: Вот эту вот как бы сетевую семантику делаем как бы адекватной нашей семантике, значит, наших коллективных операций с точки зрения адресации, да? Ну понятно, что это ip адресация, там вы 4 или вы 6, но нам нужно

141: Как-то её сделать масштабируем поэтому мы делаем тоже такой финт ушами значит, как говорится, делаем 4 ключа адрес фабрики айпи, адрес сетевой карты идентификатор джаба джоб айди идентификатор.

142: Процесса и индекс конкретного ресурса. То есть вот эти вот 4 ключевых параметра, они уникально идентифицируют как бы нашу задачу конкретную, которая где-то работает и нет больше вот как в инфинибенд необходимости выделять вот эти кьюэр.

143: Очереди.

144: Есть тут тоже сложная схема. Сейчас предлагаю в неё не вглядываться. То есть есть 2 как бы механизма адресации, которые сразу как бы должны из коробки работать. Относительная адресация и абсолютная. То есть в относительной адресации у нас мы что делаем, значит?

145: Вот этот джоб айди, он указывает на соответствующую вот эту вот таблицу процессов, то есть мы не указываем конкретный процесс, а смещение в таблице задаём. То есть нам не надо знать, сколько у нас процессов на всех узлах. Мы просто вот это смещение задали, то есть таким, так сказать, более

146: Lookup вот этот вот как бы ускорили и есть абсолютная адресация, когда мы все 4 параметра задаём и соответственно вот по всем 4 сразу лезем так сказать в нужную нам область.

147: Есть проблема ещё, соответственно, как нам эти сообщения, то есть мы же говорим про семантику, да, то есть есть разные форматы сообщений, соответственно, как их нам, так сказать, разбирать. Значит, то есть, есть, соответственно, тегированные сообщения, тогда мы анализируем, что за тег и

148: Соответственно, по разному это можем как-то дифференцировать обработку. Есть нетегированные, то есть какая-то общая очередь сообщений, принцип фифо, вот они нам как бы набросались на транспортном уровне, мы их фифо, так сказать, по очереди разгребаем, соответственно, сделали для идентифика.

149: Сообщения вот эти айтишники всякие инициаторы ключи и соответственно, мы помогаем, да, то есть мы опять семантику нашу сетевую подкручиваем под коллективные операции. То есть мы даём возможность вот нашим этим коллективным библиотекам сразу

150: Понимать даже как бы абстрагироваться то, что там дальше в сети, да, мы можем по вот этим message, id, так сказать, помогать им вот эти вот логические топологии, значит организовывать

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

152: Стратегии, что в таких ситуациях, так сказать, предпринимать есть для hpc. Есть вот этот механизм или протокол рандеву контрольный пакет запрашиваем, значит,

153: В ответ на который, да, уже, соответственно, идёт чтение прямое из памяти для иай профилей немножко другие механизмы, отложенная передача. То есть мы говорим, подожди, подожди, товарищ, че то ты не вовремя нам это сообщение прислал, как бы, да, я сейча.

154: Чуть чуть тут разгребусь, и ты мне его перешлёшь, как бы, вот. Либо, значит, мы можем в базовом профиле просто как бы переспросить в явном виде отправителя. То есть тоже такая очень, правда, сразу большая гибкость из коробки под разные

155: Задач. Проблема прямой записи в память. Да, и вот исключение вот этих дедлоков взаимоблокировок.

156: Ещё раз напоминаю, что у нас есть вот эти 4 идентификатора, которые вот уникально, да, так сказать, адресацию определяют, и она прямо есть в каждом пакете. И для того, чтобы нас не было этих

157: Блокировок, да, мы сразу как бы должны использовать разные трафик классы, чтобы вот эти вот данные банк, данные в 1 трафик классе передавались, управляющий трафик в другом, чтобы они друг другу не мешали, не блокировали друг друга, да, на 1 Порту, то есть, чтоб

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

159: Под уровень доставки тут ключевой концепт как бы тоже сейчас уже нет времени лезть в глубины то, что у нас как бы нет уже больше никакого вот этого фривей хендшейка, как у нас в tcp, у нас сразу как бы с 1 пакета вот этот эфемерный контекст создаётся.

160: И погнали, как говорится. То есть нам не надо вот этих, так сказать, длинных там рукопожатий.

161: Есть тоже на транспортном уровне мы сразу задаём 4 типа различных режимов транспортных, то есть надёжный режим с неупорядоченной, значит, доставкой, надёжный, с упорядоченной, ненадёжный с неупорядоченной и для

162: И дом патентных операций ещё свой отдельный режим. То есть сразу решили как бы сначала заложить как бы максимально возможную гибкость для разных типов нагрузок. То есть вот этот рот, режим, который релейбл ордер деливери, это вот как раз то, что

163: Мы как бы для hpc задач аля инфинибенд как бы гарантированную доставку, значит, можем тоже эмулировать здесь.

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

165: И дальше пошли наши вот эти заголовки разных подуровней. Если мы используем транспортную безопасность, она будет, да, если не используем, не будет, ну и так далее. И вот количество Байтиков, которые, соответственно, там используются так, для справки просто есть.

166: Как я уже говорил, отдельный уровень управления перегрузками сис. Соответственно, он там есть отдельный логический, так сказать, элемент конешн, контрол, контекст, который разные вот эти вот наши координирует, так сказать,

167: Pdc для того чтобы управлять перегрузками, не допускать перегрузок есть разные алгоритмы, значит сетевой алгоритм вот нетворк сигнал Бейс алгоритм основывается на Сенах традиционных наших и.

168: Time и есть алгоритм на стороне, значит, получателя, да, ресивер на кредит, Бейс, контрол, то есть получатель, да, выдаёт кредиты.

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

170: Протокол управления перегрузками на стороне получателя и когда на стороне сети

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

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

173: Ключевой момент, то, что мы сразу, вот, то есть опять подумали изначально о безопасности есть, мы не думаем, что, а, а давайте, то есть мне нужна шифрация на канальном уровне. Ну тогда, наверное, какой-нибудь Максе надо использовать, если на сетевом, то, наверное, айписек, да, то есть тут как бы сразу вот как бы в архитекту

174: Изначально этот компонент запроектирован.

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

176: Retry 1 из опциональных компонентов, который, может быть, может не быть идея простая. Давайте как бы, да, у нас есть на транспорте, да, под уровень, который condena перегрузками управляет замечательно, пусть он будет, но если мы можем оптимизировать на канальном уровне,

177: Давайте делать это. Тут, тут тоже очень простая система. В преамбулу кодируются идентификаторы пакета в интернет фрейме. Считаем их на приёме, что-то пропало автоматом делаем гоу бэк эн, то есть повторную перед

178: Дачу там, значит, этих потерянных пакетов.

179: Транспортный уровень вообще про неё ничего не знает. То есть мы на канальном уровне, да, как бы оптимизируем вот эту вот историю с потерями, соответственно, экономим на времени.

180: Опять же, даже на канальном уровне есть. Там тоже был 2 компонент кредит, то есть своя кредитная система, флоу контроля тоже идея такая, что опять же, да, Свич выдаёт кредиты сетевой карте, и они, значит, идут вот эти вот

181: Частые апдейты, получатель. То есть мы отправили, возвращаем кредит, отправили, возвращаем кредит и таким образом, как бы мы тоже на канальном уровне понимаем, да, сколько отправлено там, опять же, для вот режима, да, надёжный, упорядоченной.

182: Доставки очень как бы просто без, ну как бы мы создаём фундамент без потерь как бы.

183: И резюме незаметно, так сказать, пробежали про мега сложным концепциям. Значит, что нам даёт ultra, изернет, уходим от концепции фабрики без потерь. Да, мы изначально понимаем, что потери есть. И, собственно, да, вот это увеличение

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

185: Миллионы узлов сразу, как бы, архитектура под это заточена. Транспорт, да, как connection, да, то есть у нас все больше вот опять никаких фривей, Шейков послали. Эфемерный контекст создался, как бы, транспортное соединение там заработало все эти

186: Идентификаторы, значит, назначились и пошла вот эта, так сказать, погнали наших городских пакет, спрей, адресация, говорили, да, 4 вот этих вот идентификатора разные, опять же, семантику подстроили под коллектив.

187: Операции безопасности, то есть, ну, как бы, просто, ну, вот много очень таких реально значимых улучшений и вишенка на торте совместимость изернет экосистемой. Нет больше привязки к 1 вендору, да, то есть, в принципе, как бы

188: Для развёртывания, да, нам нужны, как бы, естественно, сетевые карты, да, сетевые адаптеры, которые будут поддерживать ультра, изернет, потому что, как бы, большая часть интеллекта на них, а коммутаторы, в принципе, могут оставаться, ну, современные содовска, которые

189: Поддерживает тот же Есин. Значит, и мы можем с этим запуститься, а потом уже в процессе, там, так сказать, например, их апгрейдить для поддержки вот этих линк Лавер аддишен про дополнительных протоколов.

190: И резюме, то есть это ultra изернет, это не новый изернет, да, то есть вот я хочу, чтобы это все запомнили. То есть мы у нас уровня 1, 2, 3, как были, да, там есть какие-то, так сказать, новации, но они опциональные.

191: Ключевое различие это именно транспортный уровень. То есть осенью выдали, так сказать, в публику вот эту 1 версию спецификации. Она очень большая, очень подробная, её можно там найти на сайте этого альянса, прочитать для тех, кто интересуется.

192: И уже есть анонсы первых продуктов. То есть, если бы я сейчас, так сказать, был, работал бы в каком-то вендоре, я бы сказал, парни, а сейчас начинается самая важная часть презентации. Мы производим супер свечи, супер адаптеры, и мы лучше других, но у меня этого не будет, потому что я не работаю в вендорах. Вот, ну,

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

194: На наш портал мсовский со всякими артиклями статьями уже заговариваюсь да, вот видеороликами и так далее и QR-код на оценку доклада спасибо, Борис да, все, я немножко не уложился все здорово, все, спасибо большое, давайте.

195: Шустро. Пару вопросов нужно задать. Вот, молодой человек, я готов. Спасибо за доклад. У меня такой вопрос. Смотрите, если в сети одновременно будет работать исипи трафик рдма версии 2 и вот этот новый протокол ультра изернет, то, соответственно,

196: Для конешн контроль, для перегрузок. Вот этот новый алгоритм, энсиси эрсиси. Не будет ли он подавляться более вежливыми алгоритмами? Ну, смотрите, да, да, я понял. Вопрос. Спасибо. Очень правильный вопрос важный. Вот.

197: Да, архитектура, если почитать подробно вот эту там спецификацию, всякие, так сказать, документы, она предусматривает возможность вот этого поэтапного развёртывания, что мы, как бы, ну, грубо говоря, делим там на разные трафик классы, так сказать, чтобы это все, и, ну, тут

198: Нам важно, что, ну, в моём понимании, да, как бы, чтоб у нас как бы, не было пересечения. То есть, если мы вот этот, как бы, ultra изернет, как бы, на стороне клиента организовали, чтобы он, соответственно, с ультраизо транспортом работал, чтоб там не было параллельно, как б,

199: Tcp и ultra изернет, чтоб они так сказать не не сражались друг с другом понял, спасибо вам, да да, ну и соответственно немного пересекающийся вопрос с коллегой насчёт именно ultra изернета транспортного уровня то есть.

200: Его, в принципе, получается, как бы можно натянуть даже на существующую инфраструктуру, да, если очень хочется, то есть без, без всех 100 гигабит, 400 гигабит просто. Да, да, да. Гигабитный изернет. Взять, поиграться, как это говорится, есть, это такая-то, что я, типа, могу

201: Мега костёр с 1 спички, но Спичка должна быть специальная, то есть должна поддерживать сетевой адаптер, да, вот эти все, ну то есть библиотеку там, вот этот il fabrique. То есть, чтобы вот этот интеллект он поддерживался адаптером и вот этой вот библиотекой и драйвером тогда, да, да.

202: То есть, сеть, вот, ну, достаточно современные интернет коммутаторы для старта вполне подойдут. Я про это вот, у меня там было, то есть, у нас вот этот интеллект, он как бы ушёл на фабрик поинты на конечный. Угу. А с точки зрения сетевой карты, то есть, все в юзерспейсе все равно не органи.

203: То есть там какое-то фмв на сетевой карте тоже должно, скорее всего, да, скорее всего, тут надо, наверное, будет дождаться уже, как бы, вот, чтоб кто-нибудь такую сетевую карту купил, как бы потестил и посмотрел, как оно, но как бы

204: Вентор на букву б уже такую сетевую карту анонсировал. Как бы ясно. Спасибо большое. Да, вот последний вопрос. Мужчина тянет активно. Спасибо за интересный доклад. Вопрос возникает вот какой вот вообще достаточно большое количество

205: На, так сказать, конечно, в основном транспортном уровне, но при этом нет ощущения файнтюнинга необходимости, то есть, грубо говоря, очень придётся эти сети аккуратно тюнить.

206: Ну, согласен, что тут, да, надо как бы отдавать отчёт и понимать, какого типа нагрузка будет работать, да, в вашем цоде и какой профиль наиболее оптимален. То есть, да, мы можем всему эйчписи профиль назначать.

207: Мы увеличим вот эти накладные расходы на обработку семантики и так далее. Вот эти вот там надёжная доставка и прочее. То есть надо, да, надо вот понимать. То есть, если у нас все-таки там лмки, давайте использовать i профиль, да, если эйчписи

208: Pc то есть тут надо вот принимать этот дизайн, какая-то уже практика есть ну практики пока, насколько мне известно, публичной нет, есть просто рекомендации, что типа товарищи, вот значит смотрите на возможности профиля на вашу нагру.

209: И вот выбирайте, так сказать, то, что конкретно подходит вам.

210: Спасибо. И Борис, классные. Вот вопрос. Нужно выбрать 2 лучших из 3, к сожалению. Ох, черт, выбрал бы 3. Но, да, извините, к сожалению, да, к сожалению, надо сделать 1 вопрос у коллеги 1. Да, да, да, конеш. И вот у вас про профили все.

211: Все, все, Борис, спасибо большое.