Как быстро определить тепловые ограничения сервера / forpes.ru

Главная
Как быстро определить тепловые ограничения сервера

Как быстро определить тепловые ограничения сервера +17

18.12.2025 12:11

abelanovsky 0 7100 Источник

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

Меня зовут Анатолий Белановский, я старший инженер по методикам тестирования. В прошлом занимался спинтроникой, работал над разработкой STTMRAM, ReRAM, а также в области сверхпроводниковых кубитов. В статье расскажу о методике, которая позволит быстро определить тепловые ограничения процессоров, модулей памяти, накопителей, сетевых контроллеров и элементов питания. Инженеры могут использовать ее при аудите существующей инфраструктуры, оптимизации компоновки и нагрузок, приемочных испытаниях и ускоренного прототипирования систем охлаждения.

Эту статью я написал в соавторстве с инженерами-конструкторами YADRO Ильей Ермоленко и Александром Воробьевым. Спасибо коллегам за моделирование и консультации по серверному оборудованию и BBU.

Оценка рисков перегрева

Чтобы управлять рисками, которые возникают из-за перегрева компонентов в экстремальных режимах, нужно понимать «узкие места» и ограничения платформы. Это требует сложного и трудоемкого анализа. К нему относится CFD-моделирование (Computational Fluid Dynamics), физические испытания в термокамерах или размещение массива дополнительных датчиков. Такие подходы очень точны, но дорогостоящи, а еще требуют времени и специальных компетенций. Все это мешает использовать их для оперативной диагностики в реальной эксплуатации или при массовой оценке парка оборудования.

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

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

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

Для примера возьмем одну из типовых конфигураций сервера: диски SAS/NVME в передней корзине, процессор (CPU), системный вентилятор (SYS_FAN), модули памяти (DIMM), блоки питания (PSU), графический процессор (GPU). Влияние компонентов друг на друга я указал в таблице:

Итак, наша задача — определить тепловые ограничения сервера.

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

Для оптимизации процесса я построю тепловую модель. Она опишет взаимное влияние компонентов системы и позволит прогнозировать их температуру при разных режимах работы.

Что показало ручное тестирование

Чтобы определить тепловые ограничения серверного оборудования, в первую очередь я изучил результаты ручного тестирования: в них последовательно изменялись количество дисков, объем RAM и TDP процессоров. Для оценки термоустойчивости каждый набор конфигураций тестировался в диапазоне заданных температур окружающей среды. Выяснилось, что первый компонент, который выдает предупреждение о перегреве, — это блок питания.

В таблицах выше — результаты ручного тестирования для двух конфигураций: с общим объемом памяти 8 ТБ при температуре окружающей среды 27 °C и 1 ТБ при 35 °C соответственно. Мы видим, что блок питания выдает предупреждение о превышении температурного порога (50 °C) при одинаковых значениях тепловыделения (TDP) и количестве дисков в обеих конфигурациях. Это наблюдение позволяет предположить, что конфигурации взаимосвязаны.

На рисунке ниже — 3D-модель сервера. Блок питания (PSU1) расположен напротив процессора (CPU1) и принимает на себя основную массу горячего воздуха:

Слева — 3D-модель части сервера и результаты компьютерного моделирования. На иллюстрации по центру — распределение скорости потока воздуха. Справа — распределение температуры внутри сервера

А здесь показана зависимость температуры на блоке питания от TDP CPU1 для различных объемов модулей памяти. Видно, что у зависимости линейный характер:

Как объясняется эта зависимость? Мы имеем дело с конвекционным нагревом, а именно с вынужденной конвекцией. Поведение системы можно описать законом охлаждения (или нагрева) Ньютона. Дифференциальное уравнение:

$cm\frac{\displaystyle \text{d}T_{\displaystyle obj\text{}}}{\displaystyle \text{d}t}+P=hA(T_{obj}-T_{env})$

$c, m, T_{obj}$ — теплоемкость, масса и температура объекта

— мощность тепловыделения объекта

$h \sim v_{\text{air}}^{n}$ — коэффициент теплопереноса, степенная функция от скорости воздуха, зависит от геометрии системы

— площадь

$T_{env}$ — температура окружения

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

Можно сделать замену переменных ? = 1/(FAN Duty Cycle) и получить линейную зависимость температуры от скорости вращения вентиляторов

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

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

Первый график показывает мощность процессоров, второй и третий — как в зависимости от нее нагревается блок питания

Планирование эксперимента

Теперь обсудим, что из себя представляет метод планирования эксперимента (Design of Experiment, DOE).

У нас есть некий процесс. На вход подаются факторы, у нас они делятся на три типа:

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

На выходе получаем отклик системы.

Конечная цель — понять:

как входные параметры влияют на выходные;
как получить желаемые выходные параметры, в нашем случае это температура на компоненте.

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

Можно показать математически, что в случае линейной модели достаточно взять две крайние точки для планирования эксперимента (график слева) и не рассматривать промежуточные значения (график справа). Такой двухуровневый дизайн снижает дисперсию и максимизирует детерминант матрицы информации (D-optimality). Подробнее об оптимальных дизайнах эксперимента можно почитать тут.

Программа запуска испытаний

В тестовой среде для автоматических испытаний продуктов YADRO имплементировали утилиту optithermo на основе планирования эксперимента. Программа выполняет такие действия:

На вход система получает JSON-файл с набором крайних значений параметров и другую информация о DUT.
Из полной комбинаторики значений параметров случайным образом выбирается только то количество параметров, которое указано в JSON-файле.
Программа автоматически устанавливает значение параметров для каждого компонента. Тут дам немного деталей: чтобы сохранить внутреннюю аэродинамику сервера в пустых слотах, мы используем DIMM-заглушки. Для оптимизации экспериментов, о которой я расскажу ниже, мы не вынимаем неиспользуемые модули, а отключаем их в BIOS. В этом нам помогает отдельная автоматизация, но это тема уже для другой статьи.
Запускаются стресс-утилиты: ptu, fio, gpu-burn.
Данные выгружаются в InfluxDB для дальнейшей обработки.

В итоге длительность эксперимента занимает не месяцы, а 24 часа, это 48 прогонов. Постпроцессинг без учета выгрузки из базы данных занимает меньше минуты.

Как использовать температурную модель

Зависимость у нас везде линейная, поэтому модель тоже получается в виде системы линейных уравнений:

$R_{0}=\varepsilon_{0}+\alpha_{00}F_{0}+\alpha_{01}F_{1}+...+\alpha_{0m}F_{m}$ $R_{1}=\varepsilon_{1}+\alpha_{10}F_{0}+\alpha_{01}F_{1}+...+\alpha_{1m}F_{m}$ $R_{n}=\varepsilon_{n}+\alpha_{n0}F_{0}+\alpha_{n1}F_{1}+...+\alpha_{nm}F_{m}$

$R_{i}$ — отклик, температура компонента

$F_{j}$ — значения факторов: мощность, скорость вращения вентиляторов

$\alpha_{ij}$ $\varepsilon_{i}$ — неизвестные коэффициенты, которые можно получить из регрессии

Результаты, они же матрица коэффициентов, получились такими:

*Видно, что при температуре коэффициент равен единице, и это соответствует реальности*

Важно, что на PSU1 коэффициент выше, чем на PSU0. Это говорит о том, что CPU1 влияет на PSU1 сильнее. Еще мы видим, что диски модуля RAM тоже нагревают систему где-то до 2 °C:

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

Ошибка предсказания при этом не превышает 1,5 %. По сути это не более 1 °C.

Какие получились результаты

Благодаря проведенной работе я могу предсказать, какая температура должна быть в ЦОД, чтобы сервер при полной нагрузке не перегревался. Теперь соберем такую таблицу:

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

Решив систему уравнений, я понимаю, какая минимальная температура может быть у нас в ЦОД. Например, если бы у нас нагружался только CPU0, мы могли бы спокойно работать при температуре до 48 °C. С видеокартами результат не такой оптимистичный: при максимальной нагрузке мы можем работать только до 8 °C. Это пример того, как можно использовать модель.

Как искать оптимальные значения температуры для всех факторов

Модель представляет собой систему уравнений, которая решается относительно неизвестных факторов при фиксированных значениях максимальной температуры на компоненте. Дальше покажу, как найти оптимальные значения таких факторов, как, например, TDP или количество дисков в корзине.

Можно использовать метод наименьших квадратов:

$\underset{x\epsilon\mathbb{R}}{\displaystyle\text{minimize}}\left| Ax-b \right|^{2}$

Вот что получилось у меня:

Метод не всегда работает корректно. Некоторые значения нереалистичные — например, количество дисков получилось отрицательным. Чтобы его скорректировать, нужно зафиксировать некоторые из факторов. Я использовал TDP на разных компонентах и получил максимальное значение температуры в ЦОД:

Теперь результат реалистичный: на полной нагрузке платформа не может работать при температуре выше 24 °C.

Если видеокарты выключены

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

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

Давайте сравним ошибки:

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

С базовой станцией тоже работает

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

Модуль делится на контрольной модуль (control board) и вычислительный модуль (BaseBand). Первый управляет всей BBU, кроме набора активных компонентов. Главное, что здесь нагревается, это процессор и DC-DC-блок.

Вычислительный модуль состоит из двух процессоров и RFSoC, которые занимаются обработкой СВЧ-сигнала:

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

Дизайн эксперимента:

CPUs — 60 Вт и 110 Вт.
RFSoC — 10 Вт и 43 Вт.
Итого: 2²⁰ комбинаций.
Для предсказания температуры в самой горячей точке достаточно до 50 прогонов.

Матрица коэффициентов для самого горячего модуля будет такой:

Косвенные коэффициенты меньше собственного теплового параметра, но в сумме они дают прибавку к температуре примерно 10 °C. Получается, что с этой моделью я предсказал предельный TDP для процессоров и дальнейшее улучшение тепловых свойств радиатора.

С методикой, которую я описал в статье, можно определить тепловые состояния сервера и понять, как его компоненты влияют друг на друга. Построенная модель позволяет предсказать максимальную рабочую температуру в ЦОД, а в случае, когда температуру окружающей среды нельзя опустить ниже заданного уровня, определить оптимальные значения мощностей компонентов. Все это сокращает время испытаний с месяцев до суток.

На этом у меня все. Если будут вопросы по теме, оставляйте комментарии, — постараюсь ответить.