Не понаслышке знаем, что промышленные компании сталкиваются со специфической задачей по разворачиванию инфраструктуры для цифрового двойника сложного технологического оборудования. Не на виртуалках, не в контейнерах, а на физических серверах с полным контролем над железом, памятью и вычислительными процессами.
Такие задачи часто включают:
CFD-расчеты (Computational Fluid Dynamics) для моделирования течений жидкостей и газов,
теплогидравлический анализ с учетом теплообмена и фазовых переходов,
мультфизическое моделирование — связанные задачи механики, электродинамики и акустики,
Real-time эмуляцию физических процессов для цифрового двойника.
В этой статье рассмотрим, как мы совместно с инженерами промышленности разбирались в архитектуре, с какими подводными камнями столкнулись и что в итоге получилось. Если вы планируете подобный проект — добро пожаловать под кат.
Почему Bare Metal
В мире, где все говорят об облаках и Kubernetes, выбор Bare Metal может показаться неочевидным. Но в HPC (высокопроизводительных вычислениях) для задач инженерного анализа это часто является наиболее предпочтительным выбором, когда существуют высокие требования к максимальной загрузке ЦП и масштабированию MPI, особенно для задач с высокой чувствительностью к задержке и локальностью NUMA. И вот почему:
Лицензирование. Коммерческие ПО, такие как Ansys, COMSOL или NX Nastran, часто связаны с физическим оборудованием. Виртуализация добавляе�� уровень неопределенности, с которым менеджеры лицензий работают некорректно.
Эффективность. Гипервизор потребляет около 2-4% ресурсов процессора. Для задач HPC, где каждый процент имеет решающее значение, это важно. Особенно когда речь идет о задачах с миллионами ячеек Mesh-сети, где решение может занять несколько дней.
Память. При моделировании CFD пропускная способность памяти и межпроцессорное взаимодействие по шине имеют решающее значение. Например, когда вы разделяете вычислительную сеть на миллионы ячеек и распределяете их по узлам кластера, каждая микросекунда задержки в MPI превращается в часы реального времени.
Архитектура для цифрового двойника
Мы взяли два сервера AMD и Intel с максимально схожей ценой и конфигурацией памяти и прогнали через них реальную рабочую нагрузку: расчет турбулентных течений в теплообменнике с мультфизическим coupling или, выражаясь более простым языком, — рассчитаем беспорядочно движущуюся жидкость (или газы), которая переносит тепло внутри теплообменника.
Это классический пример memory-bound (ограниченной пропускной способностью памяти) нагрузки. Поэтому и конфигурации выбирали не специфичные, а из наличия в продукте, где предсказуемо, победил AMD. Но давайте по порядку.
AMD против Intel в HPC задачах
Xeon Gold 6745P | AMD EPYC 9354 |
DDR5-6400, 8 каналов, ECC | DDR5-4800, 12 каналов, ECC |
3.1 ГГц (до 4.1 Turbo) | 3.25 ГГц (до 3.8 Turbo) |
336 МБ L3-кеш | 256 МБ L3-кеш |
PCIe 5.0 / 88 линий | PCIe 5.0 / 128 линий |
Хоть процессоры и сопоставимы по аппаратной многопоточности (32 ядра / 64 потока), Xeon имеет бОльшую максимальную тактовую частоту и значительно превосходит по размеру L3-кеша. Вот только это ли главное в задачах CAE (Computer-Aided Engineering)?
Например, решатели Ansys для нашей задачи (особенно CFD во Fluent и крупные расчеты в Mechanical) будут ограничены не скоростью вычислений процессора, а скоростью передачи данных из ОЗУ. Хотя бы потому, что итерационный решатель — это миллионы итераций, где каждое обновление переменных требует чтения/записи из RAM. Тут выясняется, что критически важным становится наличие 12 каналов DDR5 у EPYC.
Сюда же к важным аспектам для текущей задачи можно отнести плохую локальность данных из-за неструктурированной сетки (например, трубки, перегородки, ребра теплообменника) — низкая эффективность кеша CPU. Однако, для AMG и локальных операций кеш остается важным фактором.
Против Intel играет и 128 линий PCIe у Epyc, которые дают возможность подключить NVMe SSD (PCIe 5.0) для scratch-директории Fluent, тут солвер активно пишет checkpoint-файлы и временные данные.
И как вишенка на торте: начиная с Ansys 2022 R1, MAPDL автоматически использует AMD AOCL (BLIS library) при запуске на EPYC, что обеспечивает оптимальную производительность без ручной настройки.
Сеть
Те, кто следит за нашими докладами на GoCloud, знает, что все наши серверы оснащены MLAG 25GbE SFP сетью. Для CFD-кластеров это оптимальный выбор: достаточно для передачи результатов расчетов между нодами и инженерными станциями, но не требует дорогостоящей инфраструктуры 100GbE.
При размере 10-50 GB типичного результата расчета - сеть 25GbE позволяет передать данные внутри HPC-кластера за кратчайшее время, не создавая узкого места в вычислениях. Как альтернативу, мы также рассматривали InfiniBand-сеть, которая дала бы значительный буст к производительности вычислений, но по соображениям экономики проекта заказчик принял решение использовать Ethernet.
Особенности оптимизации
Прежде чем приступить, дополню, что в тестах и исследованиях мы использовали Rocky Linux 8.
NUMA-оптимизация
На двухсокетных EPYC критично правильное распределение памяти:
# Проверка загрузки ядер top -H -p $(pgrep -f fluent) # Проверяем NUMA (убедитесь, что видно 2 сокета) numactl --hardware # Запускаем Fluent с привязкой к NUMA узлам (для 2-сокетного узла = 64 ядра) fluent 3d -t64 -mpi=openmpi -pib.ofed -affinity=on -pinfiniband
В BIOS сервера найдите настройку NUMA Nodes per Socket (тут рекомендация 4 домена на сокет). Это группирует ядра и контроллеры памяти ближе друг к другу. При NPS1 (по умолчанию) память может быть «далекой» для половины ядер, что убьет производительность в CFD. Поэтому важно выставить NPS4 и желательно отключить SMT (ниже описано чуть подробнее).
Если все сделано правильно, после загрузки Linux выполните:
numactl --hardware
Если NPS4 и 2 сокета, вы должны увидеть ответ 8 available node slots.
Тюнинг памяти
DDR5-4800 теоретически дает около 460 GB/с на сокет, но на практике CFD-коды получают 60-70%. Есть шанс повысить этот предел до 80%:
Interleaving: выше, мы уже включили NUMA per socket. Для MPI-задач рекомендуется локальная привязка CPU и памяти к NUMA-домену. Глобальный interleaving может помочь в shared-memory сценариях, но снижает локальность для распределенных MPI-задач.
Huge pages: 2MB huge pages для MPI буферов. MPI-буферы и массивы переменных во Fluent занимают гигабайты — чем меньше промахов TLB, тем меньше простоев процессора.
# Проверка текущих настроек cat /proc/sys/vm/nr_hugepages cat /proc/meminfo | grep Huge # Установка 2MB huge pages (пример для 64 ГБ под MPI-буферы) echo 32768 > /proc/sys/vm/nr_hugepages # 32768 × 2MB = 64 ГБ # Для постоянного применения добавьте в /etc/sysctl.conf vm.nr_hugepages = 32768 # Проверка использования grep -i huge /proc/$(pgrep fluent)/smaps | head -20
Memory allocation: numactl --interleave=all для процессов, которым нужна вся память узла (тут эта команда принудительно чередует аллокацию памяти по всем NUMA-узлам на уровне ОС). Но важно, что если MPI-процессы закреплены по NUMA и каждый rank работает на локальном домене, то --interleave=all ухудшит локальность.
Проверка реальной пропускной способности:
# Установите mbw (memory bandwidth benchmark) sudo dnf install mbw # Запустите тест с привязкой к NUMA-узлу numactl --cpunodebind=0 --membind=0 mbw -n 10 4096 # Или используйте STREAM (или аналоги) для более точных измерений git clone https://github.com/jeffhammond/STREAM cd STREAM && make numactl --interleave=all ./stream
Итого: что настроить в BIOS для AMD
SMT | Disabled | SMT рекомендуется протестировать. В большинстве CFD-задач выигрыш минимален или отрицателен, но есть очень ощутимые исключения. |
NUMA Nodes per Socket (NPS) | NPS4 | Группирует ядра + контроллеры памяти, снижает латентность внутри домена. |
Memory Interleaving | Disabled | Вы используете программный интерливинг через |
Determinism Mode | Power | Позволяет SMU динамически повышать частоту. |
C2/C6 States | Disabled | Предотвращает переход ядер в глубокий сон во время итераций солвера. |
Вдобавок, что можно настроить на ОС и MPI:
# Отключите NUMA balancing в ядре (может мешать ручной привязке) echo 0 > /proc/sys/kernel/numa_balancing # Установите CPU governor на performance cpupower frequency-set -g performance # Для OpenMPI: оптимизация буферов export OMPI_MCA_btl_vader_single_copy_mechanism=none export OMPI_MCA_mpi_leave_pinned=1 # Закрепить страницы памяти для MPI # Для Intel MPI (если используете) export I_MPI_PIN_DOMAIN=omp:compact export I_MPI_ADJUST_ALLREDUCE=4 # Оптимизация коллективных операций # И уже мониторинг во время расчета # Проверка загрузки ядер и памяти в реальном времени htop -u fluent # дальше F2 - Columns - добавить PERCENT_MEM, M_RESIDENT # Мониторинг пропускной способности памяти (тут лучше perf) perf stat -a -e memory_bw_read,memory_bw_write -I 1000 sleep 30 # Проверка привязки процессов к NUMA numastat -m $(pgrep -f fluent | head -1)
Результаты и выводы
На кластере из 8 вычислительных узлов Bare Metal (AMD EPYC 9354, 2×32 ядра/узел, DDR5-4800) мы с инженерами заказчика получили неплохие результаты:
Fluent-тест на задачах заказчика сократили выполнение задачи на 37% по времени,
OpenFOAM масштабируемость (4 узла, 256 MPI) получили ~89% параллельной эффективности,
пропускная способность памяти (STREAM, на сокет) +16% к начальным показателям.
Одна из тестовых задач с рассчетом аэродинамики на 50 млн ячеек, турбулентность SST и сопряженный теплообмен показала почти двукратное ускорение. Равно как и равномерная загрузка всех 12 каналов памяти на сокет привело к устранению бутылочного горлышка при обмене граничными данными между доменами.
ROI проекта: заказчик значительно сократил время разработки нового оборудования, где количество физических прототипов удалось снизить с 12 до 4.
Что дальше
Сложно представить, но и это еще не предел. Эффективным шагом станет применение InfiniBand сетевой инфраструктуры. В задачах мультфизических эмуляций при масштабировании на 8 и более узлов именно латентность сети и пропускная способность при обмене граничными данными между MPI-процессами становятся основным ограничителем.
Если начать использовать InfiniBand в инфраструктуре заказчика, это значительно уменьшит задержки и колебания скорости отклика при передаче данных. В итоге, когда понадобится наращивать вычислительные мощности, система будет расширяться гораздо эффективнее.
