Подключение двух узлов DGX Spark: QSFP, SSH, RoCE и Cluster Assistant

Один DGX Spark — производительный сервер для одноузлового инференса. Соединение двух устройств через ConnectX-7 позволяет запускать модели и агентные нагрузки, которым недостаточно одного когерентного пула памяти объёмом 128 ГБ либо нужен тензорно-параллельный инференс на нескольких узлах.

Статья следует официальной архитектуре кластеризации NVIDIA и руководству connect-two-sparks. Перед подключением оборудования обязательно сверяйтесь с актуальной документацией.

Основные источники (начинайте здесь):

• Сеть ConnectX-7 / кластеризация (Руководство пользователя DGX Spark)
• Руководство connect-two-sparks
• NVIDIA Sync (Кластерный ассистент)
• Контекст продукта: DGX Spark · что такое Spark · реальность инференса

Переконфигурация сети может изолировать узел или нарушить доступ к управлению. Работайте через известный рабочий путь SSH по интерфейсу управления 10 Гбит/с перед изменением netplan ConnectX-7. Используйте одобренные кабели QSFP; не пытайтесь вставить неправильно ориентированный разъём в порт — NVIDIA документирует, что принудительное подключение может повредить порт.

Что вы создаёте

Общий порядок действий:

1. Физически соедините два устройства кабелем QSFP, подключив его к портам ConnectX-7 (канал класса 200 Гбит/с; кабель должен поддерживать скорость не менее 200 Гбит/с).
2. Назначьте IP-адреса интерфейсам Linux Ethernet, которые появляются для этого порта (каждый порт QSFP соответствует двум логическим интерфейсам).
3. Используйте одно и то же имя пользователя на обеих системах.
4. Настройте беспарольный SSH между узлами.
5. Запускайте распределённые рабочие нагрузки по высокоскоростному каналу (трафик NCCL / RoCE для сценариев многоузлового инференса или обучения).

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

Предварительные требования

Согласно официальному руководству:

Необязательно, но полезно: присутствие второго человека для контроля сессий SSH управления и письменная фиксация вывода ip addr / ibdev2netdev до внесения изменений.

Путь A: NVIDIA Sync Cluster Assistant

Если вы хотите избежать ручной настройки netplan, NVIDIA предлагает NVIDIA Sync Cluster Assistant как пошаговый способ настройки:

• Автоматическое обнаружение и создание сети для поддерживаемых топологий.
• Применяет настройки ConnectX-7, проверяет производительность канала связи и настраивает SSH между узлами.
• Поддерживает подключение до трёх Sparks напрямую кабелями, а также до четырёх при использовании коммутатора (согласно документации NVIDIA Sync / кластеризации).

Установите Sync на свой ноутбук, добавьте Sparks, затем используйте Cluster Assistant вместо ручного редактирования YAML — если ваша топология поддерживается. Для правил физической коммутации, ориентации портов слева/справа и общих сведений об именах интерфейсов по-прежнему читайте ConnectX-7 Networking. Cluster Assistant устраняет необходимость набора текста; он не отменяет необходимости наличия правильных кабелей и плана отката.

Путь B: Ручное руководство (connect-two-sparks)

1. Одно и то же имя пользователя

whoami

Если имена отличаются, создайте пользователя с одинаковым именем на обеих системах (в примере руководства используется nvidia), предоставьте ему права sudo и продолжайте работу от его имени. Сценарии распределённого запуска и скрипты настройки SSH-ключей предполагают совпадение имён пользователей.

2. Физическое подключение QSFP

• Подключите один кабель QSFP между двумя узлами Spark.
• При следовании инструкциям, ориентированным на NCCL, предпочтительно использовать одинаковое физическое положение порта на каждом устройстве (в рекомендациях NVIDIA указано, что согласованность портов помогает избежать проблем при тестировании).
• Ориентируйте язычок для вытягивания вверх; вставляйте кабель полностью без приложения чрезмерного усилия.
• Подтвердите состояние канала с помощью ibdev2netdev — соответствующие интерфейсы должны отображать статус Up.

Каждый физический порт QSFP отображается в Linux как два интерфейса Ethernet (и соответствующие устройства RoCE). В руководстве NVIDIA для одного физического порта приведены, например, имена enp1s0f1np1 и enP2p1s0f1np1. На ваших устройствах имена могут отличаться — ориентируйтесь на вывод ibdev2netdev именно вашей пары.

Порты QSFP на Spark в документации NVIDIA по кластеризации настроены как Ethernet. Используйте кабели, которые NVIDIA указывает как подходящие для скорости ≥200 Гбит/с. Более быстрые кабели не повышают предел порта 200 Гбит/с.

3. Настройка IP

Руководство предлагает:

• Вариант 1 — netplan (/etc/netplan/40-cx7.yaml): сохраняется после перезагрузки; chmod 600; sudo netplan apply.
• Вариант 2 — ip addr add: быстрее для проверки; IP-адреса не сохраняются после перезагрузки.

Пример схемы адресации из руководства (скорректируйте имена интерфейсов в соответствии с интерфейсами, имеющими статус Up):

Оба приведённых выше адреса относятся к двум логическим интерфейсам одного и того же подключённого порта, поэтому соединение одним кабелем уже использует две подсети. Согласно руководству NVIDIA, полная пропускная способность достигается уже одним кабелем QSFP, а собственное руководство NVIDIA по измерению производительности двух Spark измеряет пропускную способность RoCE через один кабель и суммирует два канала этого порта примерно до 190 Гбит/с — предела порта в 200 Гбит/с. Единственное, что руководство говорит о втором кабеле, — это требование к настройке: если подключены два кабеля, для полной пропускной способности адреса IP нужно назначить всем четырём интерфейсам. NVIDIA не документирует второй кабель между теми же двумя системами как прирост пропускной способности, поэтому планируйте второй кабель как топологию: третий узел или сеть с коммутатором, а не как дополнительную полосу для той же пары.

Проверьте с помощью ip addr show <iface> на обоих узлах перед отладкой SSH.

4. Безпарольный SSH

Автоматический: запустите с одного узла скрипт discover-sparks из руководства, чтобы обнаружить соседние узлы и распространить ключи (может потребоваться однократный ввод пароля).

Ручное руководство: ssh-copy-id ваш открытый ключ на IP-адреса ConnectX-7 обоих узлов, используя общий пользовательский аккаунт.

Проверьте:

ssh <node1-cx7-ip> hostname
ssh <node2-cx7-ip> hostname

5. Распределённые рабочие нагрузки и RoCE

Беспарольный SSH и доступность на уровне L3 являются фундаментом. Рецепты многоузлового инференса и обучения затем опираются на канал ConnectX-7 / RoCE для коллективных коммуникаций (NCCL и аналогичных). Не ожидайте, что Wi-Fi 7 или порт RJ-45 10 Гбит/с смогут обеспечить эту инфраструктуру.

Следующие шаги после настройки подключения обычно описаны в других руководствах (многоузловое развертывание vLLM, тесты NCCL, специфичные рецепты моделей). Проверьте корректность коллективных коммуникаций с помощью документированных NVIDIA проверок NCCL и кластеризации для вашей версии программного обеспечения, прежде чем списывать проблемы на сервер модели.

Нюанс в именовании интерфейсов (прочтите перед вводом YAML)

Руководство NVIDIA по кластеризации объясняет, почему компоновка ConnectX-7 в Spark сбивает с толку людей, привыкших к схеме «один NIC = один eth0»:

• Каждый порт QSFP имеет два пути PCIe в SoC.
• Поэтому Linux отображает два сетевых интерфейса на каждый физический порт, а также соответствующие устройства RoCE.
• Примеры из руководств (enp1s0f1np1, enP2p1s0f1np1, …) являются иллюстративными. Всегда выполняйте сопоставление от ibdev2netdev на вашей паре после установки кабеля.

Если netplan ссылается на интерфейсы Down, а пара Up игнорируется, вы будете часами гоняться за призраками «плохого кабеля». Распечатайте таблицу соответствия из документации по кластеризации рядом с терминалом для первого запуска.

Примечания по безопасности для подсети CX7

Относитесь к каналу ConnectX-7 как к доверенной внутренней сети, а не как к гостевой сети Wi-Fi:

• Не объединяйте его небрежно с корпоративным VLAN для пользователей.
• Ограничьте, какие процессы привязывают порты RPC / NCCL / инференса к этим IP-адресам.
• Помните, что беспарольный SSH между узлами обеспечивает мощное средство латерального перемещения в случае компрометации одной из машин — соответственно защищайте физический доступ и учётные записи ОС.
• Для администрирования и ручных SSH-подключений используйте задокументированный интерфейс управления, чтобы ошибка в настройке CX7 не привела к полной потере доступа.

Риски, проверка и откат

Проектирование отката (адаптируйте руководство NVIDIA к хосту):

• Перед редактированием определите, существует ли уже /etc/netplan/40-cx7.yaml и конфигурирует ли какой-либо другой файл netplan те же интерфейсы. Создайте резервные копии соответствующих файлов и запишите хэши, владельца и права доступа.
• Не удаляйте вслепую существующий файл. Восстановите точные файлы до изменений, запустите sudo netplan generate, проверьте сгенерированный результат, затем примените изменения через известный рабочий путь управления.
• Для временных адресов удалите только явные адреса, добавленные в рамках этого изменения, и проверьте результирующие маршруты и состояние канала.
• Сохраняйте доступ к консоли или независимому управлению до тех пор, пока оба узла не пройдут проверки SSH и маршрутизации после отката.

Откат сбрасывает сетевую конфигурацию кластера. Планируйте его как окно изменений, если кто-либо зависит от многоузловой конечной точки. Подтвердите работоспособность SSH управления перед удалением конфигураций.

Таблица быстрого устранения неполадок

Основано на симптомах из руководства NVIDIA:

Пока не делайте этого

• Не запускайте производственную модель с тензорным параллелизмом, пока проверки SSH и канала не пройдут успешно.
• Не смешивайте ad-hoc IP-адреса с забытыми файлами netplan при перезагрузках.
• Не открывайте подсеть CX7 для ненадёжных сетей.
• Не принудительно подключайте коннекторы QSFP и не используйте случайные кабели DAC без проверки заметок о скорости/совместимости в руководстве пользователя.

Минимальный тест принятия

Прежде чем направлять агентов на многоузловую конечную точку:

1. Оба узла доступны по ping в подсети CX7.
2. Бессекурный SSH в обоих направлениях от имени общего пользователя.
3. Задокументированная проверка NCCL или канала из руководства выполнена успешно.
4. В списке узлов рецепта обслуживания используются адреса CX7, а не IP-адреса Wi-Fi.
5. Точные шаги резервного копирования и восстановления протестированы в окне обслуживания без потери пути управления.

Два устройства Spark, соединённые по утверждённой схеме QSFP, образуют конфигурацию, описанную NVIDIA. Команды настройки и отката в этой статье следуют документации производителя; они не являются подтверждённым результатом для вашего оборудования, кабельной инфраструктуры и версий программного обеспечения. Любую новую настройку межузловой сети проводите как контролируемое сетевое изменение, собирайте собственные доказательства приёмки и оценивайте реальные ограничения инференса только после успешной проверки сети.