Тест кластера Thunderbolt 5: насколько быстрее сеть из нескольких Mac mini?

Когда хватает одной машины — и когда нужна кластеризация TB5

Первый облачный Mac многих команд уже закрывает ежедневные iOS-сборки: один M4, 16 ГБ RAM, полный Archive за три–четыре минуты. Узкое место чаще в параллелизме, а не в скорости одного ядра — у вас 6 целевых приложений, 3 расширения и 2 виджета, а CI-скрипты выстраиваются в очередь на одном runner; или граф Swift Package в monorepo огромен, чистая сборка занимает больше 15 минут, и каждому runner нужны десятки ГБ DerivedData и снимков исходников.

Очевидное решение — «поднять ещё облачных Mac, каждый со своей задачей». В теории это работает, но если машины общаются только через отдельные публичные порты 1 Gbps, синхронизация workspace на 40 ГБ может занять 6–8 минут — съедая выигрыш от параллельного запуска. Кластеризация Thunderbolt 5 решает задачу плоскости данных между машинами в одном стойке: PixVPS физически соединяет Mac mini на одном узле кабелями TB5 с заявленной пропускной способностью 80 Gbps, чтобы узлы фермы сборки синхронизировали артефакты и распределяли работу без насыщения публичного egress.

Сразу уточним: TB5 не добавляет ядра CPU в одну коробку и не «склеивает» три M4 в машину на 30 ядер. Он ускоряет передачу данных и оркестрацию при совместной работе машин. Если боль в том, что «одна машина компилирует слишком медленно», TB5 мало поможет; если боль в «медленном копировании кэшей между машинами» или «ночные batch-сборки не успевают» — TB5 как раз нужен.

Физический канал 80 Gbps против публичного 1 Gbps: что реально меняется

У каждого Mac mini PixVPS свой публичный IPv4 и порт 1 Gbps — достаточно для SSH, VNC и загрузки в TestFlight. Когда машина A отправляет папку DerivedData на 30 ГБ на машину B для инкрементальной сборки, маршрут через публичный интернет означает, что данные выходят из стойки и возвращаются обратно. Теоретический потолок ~125 МБ/с; на практике окно TCP и лимиты записи на диск удерживали нас на 108–112 МБ/с — около 4 минут 30 секунд на 30 ГБ.

Кластеризация TB5 создаёт выделенный путь данных внутри стойки. В «Сведения о системе» межсоединение отображается как мост Thunderbolt 5 (bridge0 или отдельный интерфейс en*), отдельно от публичного en0. Мы провели 60-секундные TCP-тесты iperf3 между узлами 1 и 2: среднее в одну сторону 58,4 Gbps (~7,3 ГБ/с), суммарно в обе стороны ~94 Gbps; rsync 30 ГБ файлов смешанного размера (структура как у DerivedData) занял 42 секунды — примерно в 6,4 раза быстрее публичного пути.

58 Gbps ниже заявленных 80 Gbps — нормально: накладные расходы протокола, программные прерывания CPU и устойчивая запись NVMe (~2,8 ГБ/с последовательно на диск) ограничивают реальный throughput. В нагрузках фермы сборки узкое место часто смещается с «сети» на «дисковый I/O» или «однопоточный линкер» — поэтому параллельные тесты Xcode ниже не дали линейного ускорения в 3 раза.

Чеклист после выдачи: что должно быть видно в macOS

На странице заказа отметьте «Кластеризация нескольких машин Thunderbolt 5» ($1,9/день, $9,5/месяц) и убедитесь, что каждый экземпляр на одном узле и в одной партии заказа имеет включённую опцию. PixVPS завершает физическое подключение в стойке; после входа по SSH проверьте межсоединение этими шагами.

1. 01
   Подтвердите наличие мостового интерфейса TB5

   На каждой машине выполните networksetup -listallhardwareports — должен быть Thunderbolt Bridge или выделенный порт TB. Запустите ifconfig, чтобы найти IP подсети межсоединения (часто 169.254.x.x или внутренний диапазон; используйте то, что назначает консоль).

2. 02
   Ping соседей и быстрый тест пропускной способности

   С узла A: ping -c 10 <TB IP узла B> — задержка должна быть < 1 мс. После brew install iperf3 запустите iperf3 -s на B и iperf3 -c <TB IP B> -t 30 на A; throughput должен достигать десятков Gbps.

3. 03
   Настройте SSH только через TB

   В ~/.ssh/config добавьте псевдонимы Host с Hostname на внутренние IP TB, чтобы крупные синхронизации не шли по публичным маршрутам. Пример: Host m4-node2 → Hostname 10.20.0.12 (IP из консоли в разделе «Информация о межсоединении кластера»).

4. 04
   Смонтируйте общие каталоги артефактов (опционально)

   Проще всего: запланированный rsync --delete для DerivedData; продвинутые варианты — NFS поверх TB или sshfs только для чтения. Мы использовали схему «первичный узел собирает + rsync пушит инкременты» — минимум скриптов.

Тест 1: ночная параллельная матрица Archive для нескольких приложений

Сценарий: у команды 4 независимых приложения, все Release Archive нужны за 30 минут. Последовательно на одной машине: 4 схемы выполняют xcodebuild archive одна за другой, ~3м48с чистой сборки каждая, итого 15м12с — без Export и загрузки.

Стратегия на трёх узлах: матрица GitHub Actions распределяет 4 схемы по 3 runner (2+1+1), каждый делает checkout и подпись независимо — без общего DerivedData. Wall-clock определяется самым медленным runner: 4м05с (одна схема потратила лишние 17 секунд на разрешение Swift Package). Примерно на 73 % меньше ожидания, чем при последовательном запуске.

В этом сценарии полоса TB5 почти не задействована — сборки не обмениваются крупными файлами; ценность в «одна партия заказа, одна стойка, низкая задержка планирования», а не в передаче данных. Если у вас 2 приложения и релиз раз в месяц, 3 машины + TB5 избыточны; при 5+ целях и ночных batch-сборках матричный параллелизм окупается.

Тест 2: инкрементальная синхронизация DerivedData в monorepo

Здесь как раз проявляется полоса TB5: после полной сборки на первичном узле синхронизируем 28 ГБ DerivedData на два вторичных узла, которые выполняют только инкрементальную компиляцию своих framework-целей.

Поток: узел 1 чистый archive (3м52с) → rsync -avz --progress -e ssh ~/Library/Developer/Xcode/DerivedData/MyMonorepo-* m4-node2:~/cache/ → узлы 2 и 3 параллельный инкрементальный archive для назначенных framework-целей.

TB5 экономит ~3м40с только на синхронизации; сквозное время почти на 5 минут быстрее последовательной сборки на одной машине. При большем DerivedData (50 ГБ+) или более частой синхронизации (каждый PR с push кэша) разрыв растёт. Поэтому мы рекомендуем TB5 командам, которые делят кэши сборки между кооперирующимися машинами.

Тест 3: пробный distcc и реальность

Мы попробовали distcc на трёх M4: первичный узел раздаёт предобработанные единицы компиляции, вторичные возвращают .o-файлы. Теория обещает ~3× ускорение; чистая сборка сократилась лишь с 3м52с до 2м34с (~1,5×) — далеко от линейного.

Причины просты: современная система сборки Xcode включает explicit modules для Swift и сильный параллелизм; один M4 уже насыщает 10 ядер. distcc добавляет удалённое планирование, синхронизацию заголовков и этапы линковки на первичном — съедая выигрыш. Единицы компиляции Swift также соблюдают порядок зависимостей модулей; в отличие от чистых C-проектов, свободно нарезать нельзя.

Вывод: для типичной iOS/Swift-работы «каждая машина выполняет независимые задачи» лучше, чем «distcc режет один xcodebuild». Ценность TB5 — быстро доставить исходники и кэш на каждый узел, а не форсировать одну сборку на несколько CPU. Если ваш стек — зрелый C/C++ с Makefiles, distcc ещё может помочь; на крупных SwiftUI-репозиториях не ждите 3×.

Подводные камни: подключено правильно, а всё равно медленно?

Во время тестов мы столкнулись с ситуациями, когда всё «выглядело кластеризованным», но работало как публичный интернет. Чеклист:

rsync использовал публичный IP. Если псевдонимы Host в SSH config всё ещё указывают на публичные адреса, синхронизация 30 ГБ возвращается к ~4 минутам. Запустите ssh -v m4-node2 и убедитесь, что целевой IP в подсети TB.

Диск стал узким местом. Три машины одновременно пишут на NVMe — устойчивая запись может упасть до ~1,5 ГБ/с; iperf3 всё ещё показывает высокую полосу, но rsync end-to-end замедляется. Разнесите синхронизации по времени или используйте инкрементальные каталоги (--link-dest).

Файрвол или Little Snitch заблокировали интерфейс TB. Некоторые средства безопасности по умолчанию блокируют трафик моста — временно разрешите Thunderbolt Bridge и повторите iperf3.

Узлы были не в одной партии заказа. Кластеризация TB5 применяется только к экземплярам на одном узле с включённой опцией в одной партии; пары из разных регионов (например, Сингапур + Токио) не могут быть связаны по TB — только публичный интернет, дополнение TB5 не нужно.

Когда кластеризация TB5 стоит своих денег

Вернёмся к заголовку: насколько быстрее сеть из нескольких Mac mini? По нашим трём тестам ответ зависит от формы workflow — чистый матричный параллелизм (отдельные приложения) может сократить wall-clock почти пропорционально числу машин; monorepo с общими кэшами выигрывают больше всего, когда TB5 сжимает синхронизацию с минут до секунд; distcc на Swift-проектах даёт скромный эффект.

Если один облачный Mac закрывает ежедневный CI, стандартного M4 ($21,1/день, 16 ГБ RAM, выделенный 1 Gbps) достаточно — без доплаты за TB5. Добавляйте TB5 ($1,9/день / $9,5/месяц), когда запускаете минимум 2 экземпляра на одном узле, ночные batch-сборки превышают 30 минут суммарно или узлы часто синхронизируют 10 ГБ+ DerivedData / кэшей SPM.

PixVPS предлагает то же оборудование и кластеризацию в пяти регионах — Сингапур, Япония (Токио), Корея (Сеул), Гонконг и Восток США — выдача за 1–5 минут на машину; партии кластера получают подключение TB в стойке. Отметьте кластеризацию TB5 на странице заказа, чтобы разместить машины в одном домене межсоединения; услугу можно добавить позже из консоли для существующих экземпляров (см. Центр помощи). Поддержка людьми 7×24, ответ на тикет в течение часа; топология кластера и внутренние IP — в разделе «Информация о межсоединении кластера».

Экономика фермы сборки проста: параллелизм × скорость одной машины − накладные расходы координации = реальный выигрыш. Кластеризация Thunderbolt 5 убирает самую крупную часть накладных — ожидание синхронизации больших файлов. Сначала разбейте работу на параллельные независимые задачи, затем используйте TB5 для ускорения распределения кэшей — это лучше, чем слепо добавлять машины.