Охлаждение сервера: airflow, троттлинг, диагностика

Если сервер стал шумнее, теряет производительность под длительной нагрузкой или ведёт себя нестабильно без явных аппаратных ошибок, в первую очередь нужно проверять не ПО на ошибки, а организацию airflow, температуру воздуха на входе в сервер и наличие подтверждённого thermal throttling. На практике правильная рекомендация почти всегда одна и та же: сначала убедиться, что система охлаждения в помещении работает, воздух проходит через сервер и стойку так, как это задумано производителем, затем сопоставить телеметрию BMC с поведением системы под нагрузкой, и только после этого делать выводы о замене компонентов, прошивках или нехватке мощности платформы.

Охлаждение сервера часто воспринимают как вспомогательную тему: пока нет аварийного отключения, значит всё в порядке. На деле проблемы с теплоотводом гораздо чаще проявляются не катастрофой, а постепенной деградацией. Вентиляторы начинают работать на повышенных оборотах, частоты под длительной нагрузкой становятся ниже ожидаемых, производительность плавает в зависимости от времени суток или места сервера в стойке, а после апгрейда накопителей или PCIe-карт система внезапно становится ещё более шумной и менее предсказуемой. Сервер при этом может не выдавать фатальных ошибок и оставаться полностью рабочим, но уже не работать в оптимальном режиме.

Это особенно важно в инфраструктуре, где ценится не только номинальная мощность железа, но и повторяемость результата. Для базы данных, виртуализации, CI/CD, аналитики, inference-нагрузок и любого длительного compute-задачника значение имеет не пиковая частота на коротком интервале, а способность системы держать расчётную производительность часами. Именно здесь охлаждение перестаёт быть вопросом «комфорта» или акустики и становится вопросом реальной вычислительной отдачи.

Почему airflow важнее, чем кажется

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

Из этого следует базовый, но часто игнорируемый вывод: airflow — это не только вопрос скорости вентиляторов. Можно поднять обороты, но если внутри нарушен маршрут движения воздуха, система будет бороться не с причиной, а с последствиями. Поток начнёт частично обходить горячие зоны, турбулизироваться, рециркулировать и терять эффективность. Именно поэтому сервер, который «по датчикам вроде не критичен», может уже работать с потерей thermal headroom.

На практике airflow ломают несколько типовых вещей:

• пустые юниты в стойке без заглушек;
• открытые или неправильно собранные отсеки в самом сервере;
• плотный кабель-менеджмент перед фронтальной частью;
• нестандартные PCIe-карты и адаптеры, меняющие сопротивление потоку;
• отсутствие штатных воздуховодов;
• пыль на фильтрах, решётках и радиаторах;
• слишком агрессивные “quiet”-профили;
• попытка эксплуатировать высокоплотную конфигурацию в шасси с минимальным запасом по охлаждению.

Особенно показателен случай с пустыми юнитами в стойке. На бытовом уровне это выглядит как мелочь: свободное место и свободное место. С инженерной точки зрения это часто прямой путь к рециркуляции горячего воздуха. Если пустые зоны не закрыты blanking panels, горячий выхлоп может возвращаться в холодную зону и снова попадать на вход серверов. В результате температура в помещении как будто нормальная, кондиционирование работает, но конкретный сервер или верхняя часть стойки получают уже подогретый воздух.

Температура помещения и inlet temperature — не одно и то же

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

Если в стойке нарушено разделение горячего и холодного воздуха, если фронт частично закрыт кабелями, если сервер стоит в верхней зоне с локальным hot spot или если поток охлаждённого воздуха до него просто доходит хуже, inlet temperature будет выше, чем ожидается по общему климату помещения. Отсюда и типичный эффект: формально серверная в пределах нормы, а конкретный узел троттлит, шумит и теряет стабильность.

Поэтому в температурной картине полезно различать сразу несколько уровней:

• температуру воздуха в помещении;
• температуру воздуха на входе в сервер;
• температуру конкретных компонентов;
• температуру выхлопа;
• разницу между входом и выходом при определённой нагрузке.

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

Что такое thermal throttling на практике

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

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

При этом не каждое снижение частоты — это именно thermal throttling. Есть ещё ограничения по питанию и энергополитике платформы. Поэтому правильная диагностика начинается с разделения thermal limit и power limit. Если частота снизилась, это ещё не доказательство перегрева. Но если падение частоты совпадает с ростом температурных событий, увеличением оборотов вентиляторов и подтверждается счётчиками throttling, картина становится гораздо яснее.

На уровне эксплуатации троттлинг обычно проявляется так:

• сервер заметно шумит под той нагрузкой, под которой раньше был тише;
• частоты на длительной задаче ниже ожидаемых;
• один и тот же бенчмарк даёт разные результаты утром и днём;
• после установки новой карты расширения система стала горячее и шумнее;
• верхние серверы в стойке ведут себя хуже нижних;
• короткие тесты выглядят нормально, а длительные — нет.

Почему сервер начинает греться и терять запас по охлаждению

У тепловых проблем почти никогда нет одной-единственной причины. Обычно это сочетание нескольких факторов.

На уровне сервера

Первый слой — сама конфигурация. Шасси может быть рассчитано на определённый диапазон TDP, количество накопителей, состав PCIe-устройств и определённую компоновку. Как только конфигурация становится плотнее, запас по охлаждению уменьшается. Иногда критическую роль играет не процессор, а менее очевидный элемент: высокопроизводительная сетевая карта, HBA, плотно установленный NVMe-набор, GPU, нештатный райзер или даже потерянная заглушка.

Сюда же относится всё, что нарушает заводскую аэродинамику: снятые воздуховоды, открытые крышки, замена штатных элементов на несовместимые, загрязнение, деградация вентиляторов и устаревшие thermal-профили в прошивке.

На уровне стойки

Даже хорошо собранный сервер может начать работать хуже в плохой стойке. Пустые места без заглушек, неаккуратные кабели, слабое разделение горячего и холодного потоков, плотная верхняя зона с несколькими горячими узлами подряд — всё это ухудшает условия на входе. Иногда сервер физически исправен, но установлен туда, где у него нет нормального thermal headroom.

На уровне помещения

Есть серверные, где всё выглядит «достаточно холодным», но охлаждение распределено неравномерно. В одной зоне всё в порядке, в другой появляются hot spots. На это влияют особенности подачи воздуха, перегрузка отдельных рядов, сезонность, фильтрация, пыль и даже то, как изменился тепловой профиль стойки после расширения инфраструктуры. Проблемы особенно заметны летом или в периоды максимальной загрузки.

На уровне настроек

Современные серверы управляют охлаждением не только механически, но и политиками. BMC, iDRAC, iLO и аналогичные контроллеры используют thermal profiles, fan offsets, режимы энергопотребления и защитные алгоритмы. Если профиль выбран слишком «тихий», если после добавления карты не пересматривались настройки, если политика вентиляции не соответствует новой конфигурации, система может либо постоянно раскручивать вентиляторы на максимум, либо наоборот, борясь за тишину, недостаточно активно отводить тепло до момента, когда троттлинг уже начнёт влиять на производительность.

Как отличить проблему охлаждения от других причин деградации

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

Если сервер шумит, но частоты не падают, это ещё не значит, что проблемы нет. Возможно, система пока удерживает температуру ценой оборотов, и запас ещё есть. Если частоты падают, но при этом нет признаков thermal events, нужно смотреть в сторону power limits и общей энергополитики. Если же сходятся сразу несколько признаков — рост RPM, ухудшение результатов под длительной нагрузкой, повышенный inlet, температурные события в BMC — вероятность тепловой проблемы очень высока.

Пошаговая диагностика без догадок

Хорошая диагностика идёт от простого к точному и не начинает с немедленной замены железа.

Сначала нужно зафиксировать сценарий проблемы. Когда она появляется: всегда или только в жаркое время суток? Под какой нагрузкой: короткой пиковой, равномерной длительной, storage-heavy, network-heavy? На одном сервере или на группе? Если деградация наблюдается на нескольких узлах в одной стойке, это уже сильный намёк на уровень стойки или помещения.

Далее нужно посмотреть телеметрию BMC. Важны не только абсолютные температуры, но и динамика: температура на входе, температура выхлопа, обороты вентиляторов, thermal warnings, событийный журнал, профиль охлаждения, история аппаратных изменений. Если после установки карты расширения сервер внезапно «взлетел» по шуму — это часто не баг, а реакция на изменившийся тепловой режим.

Следующий слой — операционная система и поведение под нагрузкой. Нужны реальные частоты в длительном тесте, а не короткий burst. Нужна проверка счётчиков thermal throttling, если платформа их предоставляет. Нужна корреляция между моментами падения частоты, ростом RPM и температурной телеметрией. Без этой связи слишком легко принять обычный нагрев за причину всех проблем.

После этого обязателен физический осмотр. Закрыты ли пустые юниты? На месте ли заглушки корзин и слотов? Нет ли кабелей, перекрывающих фронтальную часть? Чисты ли радиаторы и решётки? Не снят ли штатный shroud? Иногда проблема, которую пытаются решать настройками BIOS и BMC, оказывается банальным нарушением воздушного канала.

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

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

В современных серверах датчиков много, но практическую ценность имеют не все одинаково.

Главная методическая ошибка — смотреть только на CPU temperature. Это важный показатель, но сам по себе он почти ничего не говорит о причине. Высокая температура CPU может быть следствием плохого inlet, нарушенного airflow, агрессивной нагрузки, неудачной компоновки PCIe, недостаточного профиля вентиляторов или изначально плотной конфигурации. Поэтому изолированный датчик почти всегда вводит в заблуждение.

Что делать после того, как проблема подтверждена

Исправление нужно начинать не с самого дорогого шага, а с самого логичного.

Сначала восстанавливают правильный airflow: закрывают пустые U, возвращают заглушки, проверяют shroud, убирают препятствия на фронте и тыле, приводят в порядок кабели. Затем чистят сервер и стойку, проверяют вентиляторы и состояние радиаторов. После этого смотрят на профиль охлаждения и актуальность прошивок. Если проблема началась после апгрейда, нужно оценить, насколько новая конфигурация вообще соответствует тепловым возможностям шасси.

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

Что делать не стоит:

• ориентироваться на один датчик;
• открывать крышку сервера и считать, что так он «дышит лучше»;
• бездумно занижать шум профилями и offsets;
• игнорировать рост RPM, если сервис пока не деградирует;
• считать отсутствие аварий доказательством того, что охлаждение организовано правильно.

Когда воздушного охлаждения уже недостаточно

Есть сценарии, в которых проблема не сводится к наведению порядка. Если конфигурация стала слишком плотной по CPU, GPU, NVMe и PCIe, если стойка работает с выраженной неравномерностью, если thermal headroom минимален даже в нормальных условиях, а летом или под длительной нагрузкой система быстро уходит в шум и ограничения, значит пора думать не только о настройке, но и об архитектуре.

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

Правильно организованное охлаждение — это не «сервер, который не перегревается до ошибки», а сервер, который стабильно держит нужную производительность, не уходит в лишний шум и не живёт на грани теплового бюджета. Именно по этому критерию и стоит оценивать результат.

Если сравнивать всё в одном предложении, практический вывод такой: охлаждение сервера нужно диагностировать как систему, а не как набор отдельных температур. Воздух на входе, маршрут потока через шасси, реакция BMC, реальные частоты под длительной нагрузкой и физическое состояние стойки важнее, чем любой один «красивый» датчик в изоляции. Только такой подход позволяет отличить локальный перегрев от архитектурной проблемы и исправить причину, а не её симптомы.

Источники

• ASHRAE TC 9.9. — 2021 Equipment Thermal Guidelines for Data Processing Environments: Reference Card
• Cisco — Cisco UCS Site Preparation Guide
• The Linux Kernel Documentation — Intel thermal throttle events reporting
• Dell — PowerEdge: How to change the Server Thermal and Fan Settings
• DMTF — Redfish for Thermal Equipment