Нейро сети для самых маленьких

Каждый раз, когда вы говорите нейросети «Спасибо», вы запускаете конвейер, в котором перемножаются сотни матриц с миллиардами элементов, и сжигаете электричества столько же, сколько светодиодная лампа за несколько секунд.

Это первая статья из небольшого цикла, посвящённого сетям для AI/ML-кластеров и HPC.

В этой серии мы коснёмся принципов работы и обучения моделей, параллелизации, технологий DMA и RDMA, сетевых топологий, InfiniBand и RoCE, а ещё пофилософствуем на тему общих и специальных решений.

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

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

Это видео создано из фотографии Клода Шеннона с помощью нейросети Алиса, основанной на Yandex GPT.

На него наложен звук, скрэмблированный с помощью программы, написанной нейросетью Claude от Antropic, названной так в честь Шеннона, практиковавшего машинное обучение ещё 70 лет назад.

Привет. Я Марат. Я сетевой инженер. Хуже того — я руководитель сетевых инженеров.

Код не пишу, на железки хожу только из любопытства.

Нейросетки использую повседневно, но под простые задачи: составить TL;DR, написать текст, вытащить данные из таблички, нарисовать картинку. Несколько раз для рабочих и домашних проектов пару функций с их помощью написал. Ну и кто sunno не баловался?

Но вот такой большой, настоящей, интересной задачки никак в поле зрения не было. А всех слушаешь — делают что-то полезное и крутое. На кухнях только и разговоров, что про вайб-кодинг. На хабре только и статьи, что про ML.

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

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

Важное условие — вайб-кодить. Не написав ни строчки кода, получить рабочую программу.

Привет. На связи linkmeup.

А что значит на связи? На какой связи? Когда мы стали так говорить? 

Или тот же Stay Tuned? Ну олды-то знают, а новое поколение?

Почему телефонную трубку чаще вешают, чем кладут?

Как вести дела с пацанами, которые уехали в Америку, но забыли изобрести не то что телеграф, а даже паровой двигатель?

Как отправить по почте ребёнка? 

Что делать, когда тебе 20, а ты ещё ничего не изобрёл?

Кем надо быть, чтобы в 19-м веке выбить лютую гору бабла из Англии на совершенно дикий проект - бросить через Атлантику 4000 км кабеля диаметром 2см на глубину 3-4 км. Пять раз. Выбить гору бабла. Четыре попытки провалить.

Итак, вы гиперскейлер, давайте отталкиваться от этого. Потому что если нет — собирайте хоть 3-tier на OSPF. А гиперскейлер вы в том случае, если у вас большая сеть на тысячи хостов, а лучше стоек. Вы уже попробовали топологию Клоза. Сначала вам очень нравилось. Она вся такая плотная, регулярная и масштабируемая — просто прелесть.

Как только кластер начал грозить вырасти за 2000 хостов, вы стали надстраивать ещё один уровень коммутации и докидывать в него всё новые и новые группы стоек. И продолжаете расти на десятки тысяч узлов. У вас отработанный дизайн, автоматизация ввода нового оборудования. Всё на потоке.

Но отчего‑то вы несчастливы. Вам плохо спится. Гложут сомнения и дурные мысли.
А всё дело в эпохе 400G! Вы долгие годы строили свою сеточку на 25+100, и всего всегда хватало. Раньше. А теперь надо на хосты соточку спустить. А значит и аплинки надо расширять, да вы и сами уже понимаете, что пора: ещё несколько лет — и эта сеть станет устаревшей. 200G, 400G, SerDes по 100 Гб/с на PSM4. Тут думать надо.

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

Вот есть у вас сотня коммутаторов или маршрутизаторов. Это много или мало?

Ну вроде как мало. А если надо на всех разом нового сотрудника добавить? А потом удалить уволившегося? А потом поротировать скомпрометированные пароли и ключи?

И тут приходит служба безопасности, которая, во-первых, хочет централизованно контролировать, у кого какие доступы, во-вторых, актуальны ли они на железках, в-третьих, ещё и смотреть, кто что когда запускал, да ещё и разрешать или запрещать это делать («Просто продолжай, не останавливайся» © СИБ).

Ну вот совсем уже и не мало. Чувствуете, чем это пахнет? Даааа, TACACS-ом.

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

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

Когда я был инженером, и когда у меня не было троих детей, я с горем пополам ещё удерживал в своей голове все дела и обещания.

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

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

Сетевой стек Linux не прост даже на первый взгляд: приложение — в юзерспейсе, а всё, что после сокета, — в ядре операционки. И там тысяча реализаций TCP. Любое взаимодействие с сетью — системный вызов с переключением контекста в ядре.

Чтобы лишний раз не дёргать ядро прерываниями, придумали DMA — Direct Memory Access. И это дало жизнь классу софта с режимом работы kernel bypass: например при DPDK (Intel Data Plane Development Kit). Потом был BPF. А за ним — eBPF. 

Но даже помимо хаков работы с ядром есть такие штуки, как sk_buff, в которой хранятся метаданные всех миллионов протоколов. Есть NAPI (New API), которая призвана уменьшить число прерываний. Есть 100500 вариантов разных tables.

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

Привет. Я Марат Сибгатулин — сетевик в Яндексе, работаю в команде Yandex Infrastructure. И сегодня я расскажу вам одну поучительную историю.

Жили были два сервера. Да и не сервера вовсе, а виртуальные машины. Жили не тужили, добро наживали, скриптами разными обрастали. Три года они трудились на славу облака да во имя автоматизации. Пока не наступили чёрные дни для RAID-массива на гипервизоре.

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

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

Это вторая статья - техническо-практический разбор протоколов и интерфейсов автоматизации сети.

Если хочется исторической справки, я отсылаю читателя к статье-спутнику, в которой мы двигаемся от начала времён в будущее человечества. Какую роль сыграли в нашем настоящем IETF, ISO, олдовые и современные вендоры и даже просто люди.
В этой же мы раскрываем дерево XML, пробуем на вкус капабилити NETCONF, шлём первые RPC и наконец уже расставим в правильном порядке буквы YANG, OpenConfig, gNMI.

Практическую пользу вам принесут только обе прочитанные статьи. Вторая без первой будет непонятна. Первая без второй - беллетристика.

Это первая статья - историческая ретроспектива технологий и интерфейсов автоматизации сети. Если хочется более практического разбора, я отсылаю читателя к статье-спутнику!!!, в которой мы собираем лабу, дёргаем апишки, настраиваем коробки. В этой же разбираемся, как мы оказались в том месте, где мы находимся, и куда ведёт нас этот путь. Практическую пользу вам принесут только обе прочитанные статьи. Вторая без первой будет непонятна. Первая без второй - беллетристика.

В предыдущих сериях АДСМ мы выработали фреймворк автоматизации, разобрались с тем, зачем появилась виртуализация и как она работает. В последней части мы выбрали и обосновали дизайн сети, роли устройств, производителей, определились с LLD (адресацией, маршрутизацией, номерами Автономных Систем).

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

Нет, есть, конечно, и сегодня компании, которые ведут учёт выделенных IP-адресов в таблице Excel. Но это не наш путь.

Даже для самой маленькой конторки размеров в пару филиалов наличие централизованной системы управления IP-пространством не повредит.

Необходимость системы инвентаризации очевидна без лишних слов.

Все выпуски АДСМ:

<a href="https://habr.com/ru/post/453516/">0. АДСМ. Часть Нулевая. Планирование</a>
<a href="https://habr.com/ru/post/458622/">1. АДСМ. Часть Первая (которая после нулевой). Виртуализация сети</a>
<a href="https://habr.com/ru/post/475614/">2. АДСМ. Часть Вторая. Дизайн сети</a>
<a href="https://habr.com/ru/post/485618/">3. АДСМ. Часть Третья. IPAM/DCIM-система</a>

Этот выпуск я посвящу неотъемлемым системам в сетевой автоматизации — системе управления адресным пространством и инвентарной системе.

Мы выберем и установим её, разберёмся с архитектурой, схемой БД, интерфейсами взаимодействия и наполним её. А в следующих частях начнём писать несложные скрипты, автоматизирующие повторяющиеся операции, такие как добавление новых стоек.

Кроме того, я уже опубликовал отдельную статью о RESTful API, в которой сделал короткий обзор его принципов и работы, это нам понадобится.

• 0. АДСМ. Часть Нулевая. Планирование
• 1. АДСМ. Часть первая (которая после нулевой). Виртуализация сети
• 2. АДСМ. Часть Вторая. Дизайн сети

• Одна версия дизайна везде.
• Два вендора, образующих две плоскости сети.
• Один ДЦ похож на другой как две капли воды.

Содержание

• Введение и краткая история виртуализации
• Типы виртуальных ресурсов — compute, storage, network
• Виртуальная коммутация
• Инструменты виртуализации — libvirt, virsh и прочее
• Заключение