Эксперты в подборе IT-оборудования
Компании, которые впервые сталкиваются с расчётными задачами, обычно ищут «мощный сервер». Логика понятная: расчёт идёт долго, значит нужно железо побыстрее. Но между «быстрым сервером» и системой для высокопроизводительных вычислений разница не количественная. Меняется вся конструкция: как узлы обмениваются данными, откуда они читают файлы, кто распределяет между ними задачи и сколько ядер разрешает использовать лицензия расчётного пакета.
HPC-серверы (High Performance Computing, высокопроизводительные вычисления) - отдельный класс оборудования. Ниже разберём, из чего они состоят, как выглядит такая система у обычной организации, а не у национального суперкомпьютерного центра, и на чём чаще всего сгорает бюджет.
Если коротко
HPC-системы - это специализированные комплексы для задач, которые обычный сервер либо не потянет по памяти, либо будет считать неприемлемо долго. Речь о моделировании течений и прочности, обработке геномных данных, квантово-химических расчётах, обучении моделей.
Отличие от обычной серверной инфраструктуры в том, что задача здесь одна, но она разрезана на куски и считается на многих узлах одновременно. Из этого следует всё остальное. Узлам нужно постоянно обмениваться промежуточными результатами, поэтому сеть здесь входит в состав вычислителя - через неё идёт сам расчёт. И всем узлам нужен одновременный доступ к одним и тем же файлам, поэтому обычная сетевая папка перестаёт справляться.
Обычный сервер на такой задаче - как велосипед на гонках Формулы 1. Вроде тоже транспорт, даже экологичнее, но сами понимаете.
| Характеристика | Обычный сервер | HPC-система |
|---|---|---|
| Вычислительные ядра | Десятки в одной машине | Сотни в кластере на 4-8 узлов, сотни тысяч в национальных центрах |
| Архитектура | Однородная | Часто смешанная: процессоры плюс GPU-ускорители |
| Память | От 64 ГБ до 1-2 ТБ | От 256 ГБ на узел; на больших расчётных сетках - несколько ТБ |
| Сеть между машинами | 1-10 Гбит/с, задержка не критична | От 25-100 Гбит/с до InfiniBand 400 Гбит/с, задержка критична |
| Хранилище | Локальные диски или СХД | Параллельная файловая система, доступная всем узлам сразу |
| Потребление стойки | 3-7 кВт | 10-15 кВт на воздушном охлаждении, выше - только с жидкостным контуром |
| Кто обслуживает | Системный администратор | Администратор плюс человек, понимающий расчётные пакеты |
Правая колонка описывает класс систем целиком, от небольшого кластера до машинного зала. Ваша конфигурация окажется где-то на этой шкале, и чаще всего ближе к левому краю, чем кажется на старте.
Публикации про высокопроизводительные вычисления обычно рассказывают про эксафлопсы и мегаватты. Для конструкторского бюро, лаборатории или отдела расчётов это не ориентир. Реальная система, с которой начинают, выглядит скромнее.
Типовая точка входа - от двух до восьми вычислительных узлов в одной стойке плюс управляющий узел и хранилище. Двухпроцессорный узел на 64-128 ядер под полной нагрузкой берёт 0,8-1,2 кВт. Четыре таких узла вместе с управляющим и хранилищем дают 4-6 кВт - верхняя половина того, что тянет обычная офисная серверная с нормальным кондиционером.
Совсем другая история с ускорителями. Расчётные и обучающие GPU потребляют 300-700 Вт каждый, и узел на четыре карты в одиночку выходит примерно на 3 кВт. Четыре таких узла - это уже около 12 кВт, вплотную к пределу воздушного охлаждения стойки. Поэтому ускорители выбирают с оглядкой на тепло: расчёт теплопритоков и схема воздушных потоков нужны до закупки, а не после.
Требования прозаичные, и касаются они чаще здания, чем железа:
Дизель-генератор, два независимых ввода и полный набор стандартов ЦОД - это разговор про другой масштаб. Небольшому кластеру нужны стабильное питание, честное охлаждение и понимание, сколько он потребляет на пике.
Скорость кластера определяется тем, как компоненты работают вместе.
Универсального выбора здесь нет. Расчёт на явных схемах хорошо ложится на GPU, а задача с большими разреженными матрицами и сильными связями между элементами может считаться на ускорителе медленнее, чем на процессорах. Прежде чем закладывать GPU в бюджет, проверьте, поддерживает ли его ваш расчётный пакет и на каких именно решателях.
Научные расчёты генерируют большие массивы данных, и читают их все узлы одновременно. Отсюда многоуровневая схема:
Смысл всей конструкции один: не дать узлам простаивать в ожидании данных. Купить сотни ядер и посадить их на одну сетевую шару - типовая и дорогая ошибка.
В кластере узлы обмениваются промежуточными результатами на каждом шаге расчёта. Здесь важна не столько пропускная способность, сколько задержка - счёт идёт на микросекунды.
Честный ориентир: кластеру на 4-8 узлов в большинстве случаев хватает 100-гигабитного Ethernet с RoCE, и это заметно дешевле и привычнее в обслуживании. InfiniBand начинает окупаться, когда узлов десятки, а задача плохо переносит задержки. Топологии вроде Fat Tree или Dragonfly - вопрос уже следующего масштаба, для одной стойки достаточно обычного неблокирующего коммутатора.
Единого правильного способа собрать HPC-систему нет. Выбор зависит от задач, бюджета и требований к росту.
Кластеры остаются самой распространённой архитектурой. Суть простая: несколько серверов (узлов) объединены быстрой сетью и работают как единое целое. Подробнее про сам принцип - в статье о том, что такое кластер серверов и зачем нужна кластеризация.
Типичный кластер состоит из вычислительных узлов, узла доступа и управления, узлов хранения, коммутационной сети и системы мониторинга. Растёт он добавлением узлов, причём узлы могут быть разными: часть с ускорителями, часть без.
Небольшой организации обычно хватает компактного кластера на 4-16 узлов в одной стойке. Такая система решает серьёзные расчётные задачи и не требует инфраструктуры уровня дата-центра.
Грид-вычисления используют географически распределённые ресурсы: виртуальный суперкомпьютер, собранный из кластеров разных организаций. Подход живёт в научных коллаборациях, где несколько институтов работают над общим проектом - например, в системе обработки данных Большого адронного коллайдера. Для коммерческой организации это редко применимо: чтобы войти в грид, нужно в него что-то отдать.
Аренда вычислений выглядит привлекательно: нет капитальных затрат, платишь за использованные часы, масштабируешься мгновенно. Оговорка в том, что предложения крупных зарубежных провайдеров российскому заказчику недоступны, и ориентироваться на них при планировании бессмысленно.
Реальных вариантов три:
Отдельно про требования к происхождению. Если вы госзаказчик или субъект КИИ, к системе применяются ограничения: программное обеспечение берут из реестра Минцифры (Astra Linux, РЕД ОС, «Альт»), оборудование - из реестра Минпромторга. Коммерческую компанию эти требования не касаются, и проверять их применимость нужно до выбора платформы, а не после.
Научные вычисления давно вышли за пределы академических институтов. Спектр применения шире.
Объёмы данных здесь колоссальные: эксперименты на Большом адронном коллайдере дают порядка 90 петабайт в год.
Здесь HPC сокращает цикл разработки: вместо десятков физических прототипов проводят тысячи виртуальных испытаний. Это же и самый частый сценарий у коммерческих заказчиков в России.
Требования тут свои: критична минимальная задержка, а не пиковая производительность. Разница в миллисекунды имеет цену.
Выбор конфигурации - компромисс между производительностью, стоимостью и требованиями задачи.
Сначала нужно понять характер расчётов:
Самый надёжный способ выбрать конфигурацию - профилирование того, что вы считаете сейчас. Один прогон реальной задачи с замерами покажет узкое место точнее, чем любые сравнения по спецификациям.
| Тип задач | Что закладывать в конфигурацию | Примеры применения |
|---|---|---|
| Вычислительная гидродинамика (CFD) | Высокочастотные процессоры, много каналов памяти, быстрая сеть между узлами | Аэродинамика, прогноз погоды |
| Обучение и инференс моделей | Узлы с GPU, локальные NVMe под датасеты | Компьютерное зрение, обработка текста |
| Молекулярная динамика | Сбалансированная система: сильные процессоры плюс ускорители | Разработка лекарств, материаловедение |
| Квантово-химические расчёты | Максимум оперативной памяти на узел, быстрые локальные диски | Квантовая химия |
| Обработка геномных данных | Много ядер и большой объём памяти (до нескольких ТБ) | Секвенирование ДНК, персонализированная медицина |
| Рендеринг и визуализация | GPU с большим объёмом видеопамяти, быстрое общее хранилище | Проектирование, визуализация результатов |
При выборе стоит проверить несколько вещей заранее: насколько просто добавить узлы, поддерживает ли система смешанные конфигурации, можно ли обновлять компоненты поэтапно и как устроено управление. Хорошо спроектированный кластер растёт вместе с задачами и не требует полной замены на каждом шаге.
Этот пункт стоит того, чтобы разобрать его отдельно, потому что именно на нём чаще всего теряют деньги. Коммерческие расчётные пакеты считают лицензию по вычислительным ядрам. Сколько у вас серверов, их не интересует. Купив сервер на 128 ядер, вы не получаете права считать на 128 ядрах.
Как это устроено на примере Ansys, где условия опубликованы. Решатель по умолчанию использует 4 ядра без дополнительных лицензий. Дальше ядра открываются пакетами HPC Pack, и шкала нелинейная:
| Пакетов HPC Pack | Доступно ядер решателю |
|---|---|
| Без пакета | 4 |
| 1 | 12 |
| 2 | 36 |
| 3 | 132 |
| 4 | 516 |
Из таблицы следует практический вывод. Организация с одним пакетом получает 12 ядер. Двухпроцессорный сервер на 128 ядер в этой ситуации простаивает больше чем на 90 %, и деньги, вложенные в ядра, не работают. Разумнее взять процессоры с меньшим числом ядер, но с более высокой частотой: на 12 разрешённых ядрах расчёт пойдёт быстрее.
Порядок действий, который экономит бюджет
Сначала выясните, сколько ядер разрешает ваша лицензия и как она считает GPU (у Ansys ускорители учитываются по потоковым мультипроцессорам, а не по ядрам). Потом подбирайте конфигурацию под это число. Обратный порядок приводит к серверу, половина которого не используется.
У открытых пакетов ограничения по ядрам нет: OpenFOAM, GROMACS, Quantum ESPRESSO считают на всём, что вы им дадите. Если расчётная задача решается открытым пакетом, экономика кластера меняется полностью - весь бюджет уходит в железо. У российских коммерческих CAE условия свои, и считаются они обычно по ядрам или расчётным модулям; точные цифры смотрите в договоре, а не в общих обзорах.
Железо - половина дела. Вторая половина в том, как задачи распределяются и чем считаются.
В высокопроизводительных вычислениях доминирует Linux - от специализированных сборок вроде Rocky Linux и SUSE HPC до российских дистрибутивов, если этого требует регламент.
Дальше идёт планировщик задач: он распределяет узлы между пользователями и ставит расчёты в очередь.
Планировщик - это то, что отличает кластер от нескольких серверов рядом. Без него пользователи будут договариваться о доступе в переписке и запускать расчёты поверх чужих.
Правильно собранный под вашу архитектуру пакет считает заметно быстрее, чем тот же пакет из репозитория. Это тот случай, когда несколько дней работы инженера дают больше, чем закупка ещё одного узла.
Прежде чем закладывать конфигурацию, проверьте документацию своего пакета: какие решатели умеют работать на GPU, как пакет масштабируется между узлами и на скольких ядрах перестаёт ускоряться. У многих задач предел масштабирования наступает гораздо раньше, чем кончается железо.
Основная работа с расчётной системой начинается после закупки.
Энергоэффективность в HPC сводится к простому вопросу: поместится ли система в вашу серверную. Плотные конфигурации с ускорителями упираются в предел воздушного охлаждения - обычная стойка на воздухе держит примерно 15-20 кВт (подробнее о том, до какой плотности стойки хватает воздуха, - в отдельном разборе). Дальше начинается разговор про жидкостное охлаждение процессоров и GPU, задние двери с теплообменником или разнесение узлов по нескольким стойкам. Последний вариант часто дешевле и почти всегда проще в обслуживании.
Как это решается, видно на конкретной сборке: мы собирали GPU-сервер в формате tower на двух RTX PRO 4000 Blackwell - в том числе потому, что напольный корпус решает вопрос охлаждения там, где стойки нет вообще.
Начинать стоит с профилирования. Оптимизация вслепую часто ускоряет то, что и так занимало проценты времени.
Кластер - общий ресурс, и качество его использования зависит от договорённостей внутри команды не меньше, чем от конфигурации.
Высокопроизводительные вычисления перестали быть экзотикой исследовательских центров. Но подходить к ним стоит с другого конца, чем к обычной серверной закупке.
Порядок, который работает: определить расчётный пакет и его требования, выяснить ограничения лицензии по ядрам, замерить реальную задачу на одном узле, посчитать питание и тепло для нужного числа узлов - и только потом собирать конфигурацию. При таком порядке кластер на четыре узла нередко закрывает задачи, под которые изначально закладывали в разы больший бюджет.
По теме: чем серверные видеокарты отличаются от игровых · конфигурация сервера для рендеринга · как рассчитать мощность стойки
Собираете систему под расчёты?
Конфигурация под HPC собирается от задачи: число ядер под лицензию расчётного пакета, память под размер сетки, ускорители там, где решатель умеет их использовать, и питание с охлаждением, которые всё это выдержат. Инженеры ITTELO подберут узлы под требования вашего расчётного пакета и объём задач, соберут и протестируют конфигурацию под нагрузкой перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
