Как инженеры определяют тепловые ограничения серверного оборудования

Чтобы управлять рисками, которые возникают из-за перегрева компонентов в экстремальных режимах, нужно понимать «узкие места» и ограничения платформы. Это требует сложного и трудоемкого анализа. К нему относится 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) и принимает на себя основную массу горячего воздуха:

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

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

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

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

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

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

Итак, у нас есть процесс — не важно, какой именно, от заварки чая до запуска ракеты в космос. На вход подаются факторы трех типов:

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

На выходе получаем отклик системы. Конечная цель — понять:

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

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

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

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

Программа выполняет такие действия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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