Сервери в гарячих шафах: як «відсутність вентиляції» вбиває час безвідмовної роботи

Чому гарячі шафи вбивають безвідмовність (і чому це підступно)

«Немає вентиляції» рідко буває буквально. Більшість шаф має якийсь обмін повітрям: щілина під дверима, плитка стелі, що не зовсім на місці,
повернення повітря будівельної системи десь у будівлі. Проблема в тому, що шафи спроектовані для мітел, а не для кіловатів.
Ви не можете вштовхувати 2–8 кВт постійного тепла в малий об’єм і очікувати, що «загальнобудинкова кондиція» просто це поглине.

Схема відмови передбачувана:
тепло піднімається, повітря на вході стає теплішим, вентилятори розкручуються, пил рухається, статичний тиск зростає, починається рециркуляція,
CPU троттлиться, диски нагріваються, блоки живлення знижують потужність, і потім щось спрацьовує. Іноді відбувається чисте термічне вимкнення.
Частіше виникають таймаути, CRC-помилки, «флапи» лінків і пошкодження даних, що потім проявляються як «баги в додатку».

Інша причина, чому гарячі шафи підступні: люди вимірюють неправильну температуру. Вони дивляться на термостат у коридорі.
Або скеровують інфрачервоний термометр на двері шафи. Повітря, яке має значення, — це повітря на вході найгарячіших пристроїв,
під навантаженням, у найгіршу частину дня, коли двері закриті так, як вони зазвичай експлуатуються.

Ще одна неприємна правда: шафи заохочують «ще одну річ». Малий стійок стає смітником для NAS-боксів,
UPS, PoE-комутаторів, KVM і того старого 1U, який ніхто не хоче виводити з експлуатації. Термальний бюджет не оцінює ваш оптимізм.

Короткий жарт №1: Серверна шафа без вентиляції — це просто повільний мультивар з миготливими лампочками.

Вплив на безвідмовність нелінійний

Тепло не послаблює надійність поступово. Воно штовхає компоненти в режими, де показники помилок зростають стрибкоподібно.
Система може здаватися в основному нормальною — поки раптом ні. Ось чому термальні проблеми такі дорогі: вони створюють
«невідомі невідомі» і довгі інцидентні розслідування, бо кожна команда може знайти правдоподібного винуватця у своєму шарі.

Найнадійніший індикатор у продакшні — не абсолютна температура; це поєднання:
зростання обертів вентиляторів, збільшення кількості коригованих помилок, лічильники троттлінгу та зміна базової латентності.
Цей набір сигналів — підпис тепла.

Факти й історичний контекст: чому ми постійно повторюємо це

• Ранні “комп’ютерні кімнати” будувалися навколо охолодження першочергово. Мейнфрейми в 1960–70-х вимагали спеціалізованих HVAC-рішень; управління теплом було частиною архітектури, а не післядумом.
• ASHRAE розширила рекомендовані діапазони температур на вході з часом. Сучасне обладнання часто витримує тепліше повітря, але «витримує» не означає «працює з низьким рівнем помилок».
• Концепція гарячого/холодного коридору стала масовою в 1990-х. Це не мода; це реакція на зростання щільності теплового навантаження в стійках і проблеми рециркуляції.
• Контроль швидкості вентиляторів став розумнішим — і голоснішим. Сучасні сервери можуть агресивно підвищувати обороти вентиляторів, щоб вижити в поганому середовищі, що маскує корінь проблеми й збільшує споживання енергії та засмоктування пилу.
• Щільність потужності зросла швидше, ніж оновлення будівель. Багато «IT-шаф» проектувалися, коли нормою були сотні ват; сьогодні один 2U може це перевищувати.
• Корпоративні диски почали повідомляти температуру та телеметрію помилок роками тому. Атрибути S.M.A.R.T. — це найближче до зізнання від диска перед його відмовою.
• Мережеве обладнання проектують так, що воно працює гарячим. ASIC-комутатора та ступені PoE генерують суттєве тепло; у шафах вони втрачають лінки ще до повного виходу з ладу.
• Батареї UPS дуже чутливі до тепла. Термін служби свинцево-кислотних батарей сильно падає при підвищеній температурі, перетворюючи «захист живлення» на «непередбачену відмову в майбутньому».

Повторювана тема: індустрія вирішила цю проблему в дата-центрах десятиліття тому, а потім забула урок
в той момент, коли хтось назвав шафу «MDF» і поставив на неї замок.

Цитата, яку варто тримати на стіні, бо вона болісно підходить до термальних відмов:
«Надія — це не стратегія.» — Генерал Гордон Р. Салліван

Фізика, яка вам справді потрібна: тепло, повітряний потік і тиск

Теплове навантаження: шафа — це акумулятор, який ви заряджаєте

Сервери перетворюють майже всю електричну потужність у тепло. Якщо ваш стійок споживає 3 кВт, ви додаєте приблизно 3 кВт тепла постійно.
У невеликій кімнаті з поганим обміном повітря температура підвищується, доки тепло, що виходить, не зрівняється з теплом, що входить. Проблема — з “виходом”.

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

Напрямок повітряного потоку: front-to-back працює тільки якщо переднє повітря залишається холодним

Майже всі сучасні стійкові сервери розраховані на фронтально-задній потік повітря. Такий дизайн передбачає:

• Холодне повітря доступне на фронтальних входах.
• Гарячий викид може вийти ззаду без повернення до входів.
• Статичний тиск не настільки великий, щоб вентилятори не могли протидіяти.

Шафа порушує всі три припущення з ентузіазмом. Люди ставлять стійки боком, закривають задню частину коробками або притискають стійку до стіни.
Потім закривають двері «заради безпеки». Вітаємо, ви збудували камеру рециркуляції.

Тиск і опір: чому «просто додати вентилятор» часто не допомагає

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

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

Точка роси й конденсат: відмова, якої ви не чекаєте

Теплові проблеми іноді супроводжуються невдалими «ремонтами»: «Давайте підведемо холодніше повітря.» Якщо це повітря нижче точки роси,
може осідати волога на металевих поверхнях. Це менше розповсюджено в типовому офісі, але трапляється при неправильному використанні переносних кондиціонерів
або коли підмішують зовнішнє повітря без контролю вологості.

Що ламається першим: реальні режими відмов по компонентах

CPU і пам’ять: троттлінг, потім повторні спроби, потім колапс

CPU захищають себе термальним троттлінгом. Звучить безпечно, поки ви не усвідомите, що це робить з навантаженнями, чутливими до латентності:
система залишається «ввімкненою», але стає непередбачувано повільною. Якщо у вас служби зберігання, троттлінг може спричинити каскадні ефекти:
накопичення write-back, довгі черги IO і таймаути, що виглядають як мережеві проблеми.

Контролери пам’яті й DIMM також можуть частіше давати помилки при високих температурах. Багато систем виправляють помилки прозоро (ECC),
що може зробити термальну проблему схожою на «випадковий шум продуктивності», поки лічильники ECC не підскочать або DIMM не буде відключено.

Зберігання: тепло перетворює «нормально» на «чому RAID перебудовується?»

Диски не люблять тепло. Це не забобон; це фізика та допуски. При вищих температурах:
мастила поводяться інакше, теплове розширення змінює зазори, а електроніка працює ближче до меж. Ви бачите більше повторних зчитувань, більше таймаутів
і іноді зростання UDMA CRC-помилок через маргінальне кабелювання, яке стає чутливим у міру нагріву.

SSD додають ще одну тонкість: контролери можуть сильно тротлитися при нагріванні корпуса. Це створює сплески латентності, що жорстоко впливають
на бази даних і віртуалізаційні платформи. Диски не вмирають миттєво; вони просто змушують ваше «швидке сховище»
поводитися так, ніби розмірковує про сенс свого існування.

Мережеве обладнання: флапи лінків і дивакуватість PoE

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

• Флапи лінків (порти стрибають) через термальний стрес або внутрішні захисти.
• Втрачені пакети, коли буфери й ASICи працюють нестабільно під тепловим навантаженням.
• Зміни у бюджеті PoE, через що камери та AP перезавантажуються.

Блоки живлення і UPS: дерейтинг і деградація батарей

Блоки живлення сертифіковані для роботи в певних термічних умовах. У гарячих шафах PSU працюють гарячіше, вентилятори крутяться інтенсивніше,
і старіння компонентів прискорюється. Коли PSU виходить з ладу в парі з резервуванням, це рідко «лише один PSU». Це попередження,
що обидва блоки «запікалися».

UPS-батареї — тихі постраждалі. Підвищена температура навколишнього середовища різко скорочує термін життя батареї, що означає, що наступний стрибок живлення
з перетвориться на відмову, оскільки UPS вже не може утримувати навантаження. Ви цього не дізнаєтесь, поки не протестуєте,
а більшість цього не робить.

Фактори людського чинника: двері — це конфігурація

У граничній шафі «двері відчинені» — це конфігурація. Люди залишають їх відкритими вдень, закривають вночі
заради безпеки, й ви отримуєте нічні термальні події, що виглядають як проблеми з плановими завданнями.
Ставте стан дверей як частину системи.

Короткий жарт №2: Єдина річ, що масштабується швидше за вашу обчислювальну потужність — це кількість картонних коробок, що блокують витяжку стійки.

Швидкий плейбук діагностики

Це порядок дій «припиніть сперечатися і знайдіть вузьке місце». Мета — не ідеальні вимірювання.
Мета — визначити, чи йдеться про тепловий інцидент і який шар отримує перший удар.

Перше: підтвердьте тепловий стрес, а не просто поганий день

1. Шукайте розкрут вентиляторів і термальні логи на найгарячих хостах. Поведінка вентиляторів — це канарка.
2. Перевірте частоту CPU і індикатори троттлінгу. Якщо такти зафіксовані низько під навантаженням, ви не працюєте в режимі «продуктивність», а в режимі «виживання».
3. Перевірте температури дисків і лічильники помилок. Помилки зберігання під час нагріву можуть імітувати будь-що інше.

Друге: ідентифікуйте режим відмови повітряного потоку

1. Виміряйте різницю між входом і викидом (навіть грубими датчиками). Високий вхід означає, що кімната гаряча; великий дельта означає, що потік повітря є, але приміщення може бути обмежене.
2. Перевірте на рециркуляцію: гарячий викид затягується назад у входи через погане ущільнення або заблокований вихід.
3. Перевірте статичний тиск / перешкоди: забиті фільтри, заблоковані отвори, «завіси» з кабелів.

Третє: кількісно оцініть ризик і виберіть найменш погане пом’якшення

1. Зменшіть навантаження (перенесіть завдання, обмежте CPU, призупиніть перебудови), якщо треба зупинити кровотечу.
2. Відновіть шлях повітря (тимчасово відкрийте двері, приберіть перешкоди, правильно переставте портативні вентилятори).
3. Сплануйте реальне виправлення: виділене охолодження, вентиляція, ізоляція потоків, моніторинг і дисципліна операцій.

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

Практичні завдання з командами: доведіть факт, а не відчуття

Нижче наведені практичні кроки, які можна виконати під час інциденту або як частину рутинної валідації. Кожен містить команду,
приклад виводу, що це означає та яке рішення прийняти.

Завдання 1: Перевірити датчики температури CPU (Linux)

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: 92.0°C  (high = 100.0°C, crit = 105.0°C)
Core 0:       90.0°C  (high = 100.0°C, crit = 105.0°C)
Core 1:       91.0°C  (high = 100.0°C, crit = 105.0°C)

Що це означає: Ви близькі до «high» і недалеко від порогів троттлінгу/автовимкнення.

Рішення: Негайно зменшіть навантаження й перевірте повітряний потік. Не запускайте технічні роботи, що підвищують IO/CPU (бекупи, scrub, rebuild).

Завдання 2: Підтвердити троттлінг CPU / зниження частоти

cr0x@server:~$ lscpu | egrep 'Model name|CPU MHz'
Model name:                           Intel(R) Xeon(R) CPU
CPU MHz:                              1198.734

Що це означає: Під навантаженням багато серверів повинні працювати значно вище ~1.2 GHz. Це вказує на термальний троттлінг або обмеження по потужності.

Рішення: Корелюйте з температурою й політикою потужності. Якщо це термальна проблема — усувайте охолодження; якщо обмеження потужності — перевірте BIOS/iDRAC-політики.

Завдання 3: Перевірити логи ядра на термальні події

cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i 'thermal|thrott|overheat|temperature' | tail -n 20
Feb 02 10:41:12 server kernel: CPU0: Core temperature above threshold, cpu clock throttled
Feb 02 10:41:12 server kernel: CPU0: Package temperature above threshold, cpu clock throttled
Feb 02 10:52:40 server kernel: mce: [Hardware Error]: Machine check events logged

Що це означає: ОС повідомляє про термальний троттлінг і, можливо, апаратні помилки через тепло.

Рішення: Припиніть шукати баги в додатку. Ви у відношенні апарат/середовище. Спочатку пом’якшіть тепловий вплив.

Завдання 4: Спостерігати швидкості вентиляторів (IPMI)

cr0x@server:~$ sudo ipmitool sdr type fan
FAN1             | 16800 RPM        | ok
FAN2             | 17200 RPM        | ok
FAN3             | 16950 RPM        | ok

Що це означає: Вентилятори майже на максимумі. Обладнання бореться з навколишнім середовищем.

Рішення: Якщо вентилятори максимальні, а температури все ще високі — подача/повернення повітря недостатні. Потрібні рішення на рівні кімнати, а не «ще вентилятор».

Завдання 5: Перевірити датчики PSU та інлет (IPMI)

cr0x@server:~$ sudo ipmitool sensor | egrep -i 'inlet|ambient|psu'
Inlet Temp       | 36 degrees C     | ok
Ambient Temp     | 38 degrees C     | ok
PSU1 Temp        | 63 degrees C     | ok
PSU2 Temp        | 65 degrees C     | ok

Що це означає: Вхідне повітря вже тепле. Температури PSU підвищені.

Рішення: Розглядайте температуру інлету як основний KPI. Якщо інлет >30–32°C протягом тривалого часу — плануйте ремедіацію, а не героїчні заходи.

Завдання 6: Перевірити температуру NVMe SSD і прапори троттлінгу

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep -i 'temperature|warning|critical'
temperature                             : 79 C
warning_temp_time                       : 124
critical_comp_time                      : 0

Що це означає: Диск провів час вище попереджувальної температури. Ймовірно відбувався троттлінг.

Рішення: Перенесіть інтенсивні записні навантаження з хоста, поки не виправите охолодження. Розгляньте радіатори/напрямні потоку для дисків, якщо це підтримує вендор.

Завдання 7: Перевірити температури SATA/SAS-дисків і історію помилок

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'temperature|reallocated|pending|crc'
194 Temperature_Celsius     0x0022   060   045   000    Old_age   Always       -       40
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       12

Що це означає: 40°C прийнятно для багатьох дисків, але CRC-помилки вказують на проблеми фізичного шару (кабелі/бекплейн), які можуть погіршуватися при теплі/вібрації.

Рішення: Перевірте/перепід’єднайте кабелі й бекплейн під час вікна технічного обслуговування. Якщо температури регулярно перевищують середину 40°C, спочатку виправляйте повітряний потік.

Завдання 8: Спостерігати латентність IO і черги (iostat)

cr0x@server:~$ iostat -xz 1 5
avg-cpu:  %user %system %iowait  %idle
          18.2    6.1    22.7   52.3

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              12.0   180.0   512.0  8192.0  48.2   3.1   98.7

Що це означає: Високий await при практично 100% завантаженні вказує, що сховище насичене або бореться. Під час нагріву троттлінг SSD/HDD може це спричиняти.

Рішення: Відкладіть важкі IO-операції (scrub, rebuild, резервні копії) і перевірте температури/троттлінг дисків. Якщо джерело — тепло, вирішуйте питання охолодження.

Завдання 9: Перевірити стан пулу ZFS і лічильники помилок (якщо застосовно)

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.
action: Replace the device or clear the errors if the device is otherwise healthy.
  scan: scrub repaired 0B in 02:13:44 with 0 errors on Sun Feb  2 07:00:11 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sda     ONLINE       0     0     2
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        /tank/vmstore/vm-104-disk-0

Що це означає: Помилки контрольних сум можуть бути спричинені диском, кабелюванням або контролером. Тепло може довести маргінальні компоненти до відмови.

Рішення: Розглядайте як ризик для даних. Стабілізуйте температуру, потім замініть/перевірте підозрілий пристрій і перевірте кабелі/бекплейн. Не «очищайте і моліться».

Завдання 10: Перевірити помилки NIC і стабільність лінків (ethtool)

cr0x@server:~$ sudo ethtool -S eno1 | egrep -i 'err|drop|crc' | head
rx_crc_errors: 41
rx_errors: 41
rx_dropped: 0
tx_errors: 0

Що це означає: CRC-помилки вказують на проблеми фізичного шару: кабелі, оптика, трансівери або перегріте обладнання.

Рішення: Перевірте також помилки на боці комутатора. Якщо помилки зростають, коли шафа найгарячіша, підозрюйте термальний стрес на NIC/комутаторі/оптиці.

Завдання 11: Перевірити логи комутатора на термальні тривоги (приклад NOS на Linux)

cr0x@server:~$ ssh admin@switch01 'show logging | include -i temp'
%PLATFORM-1-TEMP_WARNING: Temperature warning detected on sensor 2
%PLATFORM-2-FAN_SPEED: Fan speed increased to 95%

Що це означає: Комутатор явно попереджає про температуру і компенсує це підвищенням обертів вентиляторів.

Рішення: Пріоритезуйте охолодження. Комутатори часто «падають м’яко» (drop/flap) перед повним виходом з ладу, що робить інциденти хаотичними.

Завдання 12: Перевірити статус UPS і внутрішню температуру (приклад NUT)

cr0x@server:~$ upsc ups@localhost | egrep -i 'ups.temperature|battery.charge|battery.runtime|ups.load'
battery.charge: 97
battery.runtime: 820
ups.load: 41
ups.temperature: 39.2

Що це означає: Внутрішня температура UPS підвищена. Це податок на життя батареї, який ви платите щодня.

Рішення: Якщо температура UPS регулярно висока — перемістіть його у холодніше місце або покращіть вентиляцію. Заплануйте тест батареї та скоротіть інтервали заміни.

Завдання 13: Перевірити температуру в кімнаті з зовнішнього сенсора (приклад Prometheus node_exporter)

cr0x@server:~$ curl -s localhost:9100/metrics | egrep 'node_hwmon_temp_celsius' | head
node_hwmon_temp_celsius{chip="platform_coretemp_0",sensor="temp1"} 92
node_hwmon_temp_celsius{chip="platform_coretemp_0",sensor="temp2"} 90

Що це означає: Ви можете експортувати й ставити тривоги на термальні метрики. Якщо ви не ставите тривоги — ви свідомо обираєте сюрпризи.

Рішення: Додайте пороги тривог і сповіщення за швидкістю зміни (швидке підвищення температури часто дієвіше за абсолютні числа).

Завдання 14: Виміряти споживання потужності на хості (грубо, але корисно)

cr0x@server:~$ sudo ipmitool dcmi power reading
Instantaneous power reading:                   412 Watts
Minimum during sampling period:                385 Watts
Maximum during sampling period:                498 Watts
Average power reading over sample period:      431 Watts

Що це означає: Вати, що входять, — це вати тепла, що виходять. Сумуйте це по хостах, щоб оцінити теплове навантаження шафи.

Рішення: Якщо ви не знаєте свої ватти, ви не знаєте свої вимоги до охолодження. Використовуйте це число, щоб обґрунтувати витрати на вентиляцію/охолодження реальними цифрами.

Завдання 15: Підтвердити, що «відчинені двері» змінюють систему (контрольований експеримент)

cr0x@server:~$ for i in {1..5}; do date; sensors | egrep 'Package id 0'; sleep 60; done
Mon Feb  2 11:00:00 UTC 2026
Package id 0: 90.0°C  (high = 100.0°C, crit = 105.0°C)
Mon Feb  2 11:01:00 UTC 2026
Package id 0: 88.0°C  (high = 100.0°C, crit = 105.0°C)
Mon Feb  2 11:02:00 UTC 2026
Package id 0: 86.0°C  (high = 100.0°C, crit = 105.0°C)

Що це означає: Якщо відкриття дверей швидко знижує температуру, шафа має недостатню вентиляцію/повернення повітря.

Рішення: Розглядайте відкриття дверей як тимчасове екстрене пом’якшення. Побудуйте постійний шлях подачі/повернення, щоб безпека не конфліктувала з безвідмовністю.

Три корпоративні міні-історії з термальних фронтів

Міні-історія №1: Інцидент, спричинений хибним припущенням

Середня компанія переїхала до офісу й зробила те, що роблять багато: залишила «ядро» на місці, бо план міграції відкладено.
Новий простір мав чисту, замикальну мережеву шафу з глянцевим стійком і зчитувачем бейджів. Усім здавалося, що це відповідально.
Відповідальність — сильна естетика.

Хибне припущення було просте: система HVAC будівлі впорається. У шафі був приплив повітря, але не було повернення,
під порогом двері щільний. Перший тиждень здавалося нормально. Потім прийшов перший теплий день, і шафа стала пасткою для тепла.
Першим симптомом не були термальні тривоги — їх не було. Це був кластер зберігання, що почав таймаутити.

Ops ганялися за прошивкою зберігання, потім за кабелюванням, потім за гіпервізором. Потім команда додатків сміливо запропонувала підвищити таймаути,
що еквівалентно в IT — увімкнути радіо, щоб не чути шум двигуна. Тим часом вентилятори кричали, а латентність SSD зростала.

Зрештою хтось помітив закономірність: інциденти збиралися після 14:00. Будівля була орієнтована на захід; післяобіднє сонце нагрівало зовнішню стіну;
температура шафи підіймалась; і вузли зберігання троттлилися. Вирішення не було екзотичним: зробили правильний шлях повернення і постійний моніторинг,
плюс правило, що ніхто не закриває двері шафи в пікове навантаження, поки не встановлять вентиляцію.

Урок не був «HVAC важливий». Урок: не приймайте «здається прохолодно» як валідацію.
Якщо ви не можете виміряти температуру на вході і поведінку вентиляторів — ви гадатимете, а гадання коштують дорого.

Міні-історія №2: Оптимізація, що відкотилася

Інша організація мала шафу, що працювала гарячо, але «в межах специфікації». Хтось запропонував енергооптимізацію: підняти режими термостату,
зменшити швидкість вентиляторів у переносному кондиціонері в кімнаті й покластися на серверні вентилятори. На папері це зменшило шум і заощадило енергію.
На практиці це змістило, де платиться податок теплом.

Переносний кондиціонер мав одну трубку, що викидала повітря назовні, створюючи негативний тиск.
Негативний тиск затягував тепле повітря з стельової пустоти й сусіднього коридору. Датчик кімнатної температури, встановлений біля дверей,
виглядав нормально. Інлет у верхній частині стійки — ні.

Інцидент почався як переривчасті втрати пакетів. Вина відскакувала між: фаєрволом, провайдером, прошивкою комутатора.
Старший інженер нарешті перевірив логи комутатора й побачив термальні попередження. Комутатор не знищувався випадково; він берег себе.
Тоді виміряли температуру на вході у верхній частині стійки і виявили значну різницю з «кімнатною» температурою.

Відкат оптимізації припинив проблеми, але постмортем виявив справжню цінність: вони оптимізували під метрику, яку було легше виміряти (кімнатна температура біля дверей),
а не ту, що важлива (інлет пристроїв). Переставили сенсори, додали оповіщення по RPM вентиляторів і замінили однотрубну систему на конфігурацію, що не створює депресії.

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

Міні-історія №3: Небанальна, але правильна практика, що врятувала день

Одна команда вела невеликий, але критичний on-prem стек: кілька хостів віртуалізації, сховище, стек комутаторів і UPS.
Не гламурно. Не велике. Але відповідало зарплаті та внутрішній аутентифікації, тож «маленьке» не означало «необов’язкове».

У них була рутина, що здавалася майже смішною стороннім: квартальна перевірка термального стану. Одного й того ж разу, за тією ж процедурою.
Двері закриті, типовий денний робочий набір, записати інлети зверху/посередині/знизу, перевірити базові оберти вентиляторів, валідовати температуру UPS
й переглянути дельти атрибутів SMART. Це займало менше години. Це давало нудні графіки. Нудні графіки — це подарунок.

Коли сталася зміна в балансуванні HVAC будівлі (проект фасіліті, що перенаправив повітря), їхня наступна квартальна перевірка зафіксувала
повільне підвищення інлет-температур і підвищений базовий RPM вентиляторів. Нічого не відмовило. Жодних юзер-скарг. Жодних тривог.
Просто дрейф.

Оскільки в них були базові вимірювання, вони змогли переконливо звернутися до фасіліті: «Інлет цієї шафи піднявся, і наші вентилятори на 20% швидші
при тому ж навантаженні». Фасіліті відрегулювали заслінки й відновили повернення повітря. Ніяких простоїв, жодної драми, жодних північних дзвінків.

Урок суто непривабливий: базові вимірювання перетворюють теплові проблеми з інцидентів на технічне обслуговування.
Саме так виглядає надійність у календарі.

Поширені помилки: симптом → корінь проблеми → виправлення

1) Випадкові перезавантаження в другій половині дня → термальне вимкнення або захист PSU → перевірити логи й покращити інлет-охолодження

Симптом: Хости перезавантажуються «випадково», часто в пікові години.
Корінь: CPU/пакет досягає критичної температури або PSU піддається термозахисту; іноді це логиться в BMC, іноді навіть не доходить до логів ОС.
Виправлення: Перевірте журнал подій BMC/IPMI і логи ядра; зменшіть навантаження; відновіть повітряний потік; додайте датчик інлет-температури й оповіщення; реалізуйте реальну вентиляцію/повернення.

2) Сплески латентності зберігання → троттлінг SSD/HDD → додати повітряний потік і припинити прогрів корпуса

Симптом: База даних застигла, VM IO wait стрибнув, але пропускна здатність здається «нормальною».
Корінь: Контролери SSD троттляться або HDD повторно читають при високій температурі; вентилятори корпусу вже на максимумі.
Виправлення: Підтвердіть через NVMe SMART логи і температури дисків; тимчасово призупиніть scrubs/rebuilds і міґруйте «гарячі» навантаження; виправте повітряний потік у кімнаті і закрийте пустоти в корпусі.

3) CRC-помилки на дисках або NIC → маргінальний фізичний шар погіршився через тепло → перепід’єднати/замінити, потім виправити шафу

Симптом: CRC-помилки на SATA або Ethernet; переривчасті таймаути.
Корінь: Поганий кабель/бекплейн/оптика, що стає нестабільною під впливом тепла і вібрації від максимальних вентиляторів.
Виправлення: Замініть підозрілі кабелі/оптику, огляньте бекплейн, забезпечте правильне механічне кріплення; потім знизьте температуру навколишнього середовища, щоб уникнути повторення.

4) Порти комутатора флаплять → термальна тривога комутатора → розблокуйте вентиляцію і відведите PoE-навантеження

Симптом: Телефони/AP перезавантажуються, uplink-и стрибають, spanning tree нестабільний.
Корінь: Перегрів ASIC або PoE-стадій; заблоковані вентиляційні отвори або нагромадження обладнання без зазору.
Виправлення: Перевірте логи/температури комутатора, очистіть шляхи airflow, зменшіть PoE-бюджет за потреби, додайте простір між стійками і забезпечте витяжку/повернення шафи.

5) «Температура в кімнаті нормальна», але сервери гарячі → розташування сенсорів брешуть → вимірюйте інлет у верхній частині стійки

Симптом: Термостат на стіні читає 22°C; сервери повідомляють 35–40°C інлет; вентилятори кричать.
Корінь: Стратифікація й рециркуляція; термостат встановлено не в тому місці, часто біля дверей або в зоні припливу.
Виправлення: Встановіть сенсори на входах пристроїв (верх/середина/низ). Тривожтеся про інлет, а не про коридорну температуру.

6) Переносний кондиціонер «допомагає», але вологість/тиск стають дивними → негативний тиск і погане повернення → виправте шлях повітря

Симптом: Температура шафи коливається, двері важко відкрити, пил збільшується, продуктивність все ще нестабільна.
Корінь: Однотрубний переносний кондиціонер викидає повітря назовні, створюючи негативний тиск і затягує тепле/пилове повітря з інших зон; немає контрольованого повернення.
Виправлення: Використовуйте належне охолодження з балансованим припливом/поверненням або виділену спліт-систему; закрийте шляхи рециркуляції; уникайте депресуризації шафи.

7) Батареї UPS виходять з ладу раніше часу → тепло шафи → перемістіть UPS або покращіть вентиляцію, потім тестуйте батареї

Симптом: Самотести UPS не проходять; час автономної роботи значно нижчий за очікування.
Корінь: Термін служби батареї скорочений через підвищену температуру навколишнього середовища.
Виправлення: Покращіть охолодження навколо UPS, тримайте його подалі від найгарячіших зон стійки, плануйте регулярні тести часу автономної роботи і проактивну заміну батарей.

Контрольні списки / покроковий план

Покроково: стабілізувати інцидент у гарячій шафі (сьогодні)

1. Підтвердити тепловий стрес: перевірте sensors, ipmitool sensor, оберти вентиляторів і термальні/троттл-логи.
2. Припинити погіршення: призупиніть scrubs/rebuilds, відкладіть резервні копії, перемістіть пакетні задачі й розгляньте тимчасове обмеження CPU.
3. Негайно відновити повітряний потік: прибрати перешкоди, забезпечити вихід заднього викиду і, як тимчасовий захід, відкрити двері, якщо це знижує інлет-температуру.
4. Захистити дані в першу чергу: якщо з’являються помилки зберігання — пріоритет цілісності; scrub/rebuild виконувати пізніше, коли температура стабільна.
5. Документувати стан дверей і зміни: якщо «двері відкриті» — зафіксуйте це як операційну залежність.
6. Встановити таймер для повторних перевірок: температуру й RPM вентиляторів кожні 5–10 хвилин, доки не стабілізується.

Покроково: виправити шафу (цього місяця)

1. Інвентаризувати джерела тепла: перелічіть обладнання й оцініть ватаж (зчитування BMC, PDU, UPS). Просумуйте. Це ваше теплове навантаження.
2. Змапити повітряний потік: передня/задня частини стійок, зазори, перфорація, бланкувальні панелі, кабельний менеджмент і шлях викиду.
3. Додати датчики інлету: верх/середина/низ стійки спереду; принаймні один датчик біля найгарячіших пристроїв.
4. Ставити тривоги по правильних сигналах: інлет-температура, RPM вентиляторів, час попередження NVMe, термальні тривоги комутаторів, внутрішня температура UPS.
5. Спроєктувати приплив і повернення: потрібні обидва. Приплив без повернення — це брехня з тиском; повернення без припливу — вакуум жалю.
6. Розділити гарячий викид: навіть базові принципи ізоляції потоків допомагають — уникати рециркуляції і закривайте очевидні шляхи обходу.
7. Зменшити опір: чистити фільтри, прибрати пінні/пилозахисні килимки, уникати «завіс» кабелів ззаду, тримати вентиляційні шляхи чистими.
8. Підтвердити тестуванням під навантаженням: симулюйте пікове навантаження і стежте за інлет-температурами та базовими RPM вентиляторів при закритих дверях.

Операційний контрольний список: щоб це не поверталося (постіно)

• Квартальне базування: інлет-температури, RPM вентиляторів, температури дисків, температура UPS і лічильники помилок.
• Контроль змін для фасіліті: балансування HVAC може вас зламати; вимагайте повідомлення й повторної валідації.
• Правило порядку: нічого не зберігати позаду стійок, ніякого картону, ніяких «тимчасових» куп кабелів, що блокують викид.
• Політика дверей: або шафа працює з закритими дверима, або вона не працює. Проєктуйте під закриті двері.
• Планування ємності включає охолодження: додавання хоста — це додавання тепла; розглядайте ватти як ресурс першого класу.

Поширені питання

1) Яка температура є «занадто високою» для серверної шафи?

Важлива величина — температура входу пристрою, а не термостат у коридорі. Багато середовищ прагнуть тримати інлет
у низьких-середніх 20°C для запасу. Тривалий інлет у 30°C+ — це зона, де починаються троттлінг і підвищений ризик помилок,
особливо у верхній частині стійок.

2) Чому проблеми проявляються як помилки дисків або мережі, а не як «перегрів»?

Тому що ОС бачить лише те, що повідомляє апарат, і багато компонентів «падають» м’яко спочатку: повтори, таймаути, CRC-помилки
і падіння продуктивності. Деякі платформи логують термальні події в BMC, але не передають їх в ОС. Також тепло підсилює маргінальні фізичні
проблеми (кабелі, оптика, конектори).

3) Чи можна вирішити це, просто залишивши двері відкритими?

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

4) Чи хороші переносні кондиціонери як рішення?

Іноді так, але їх легко встановити неправильно. Однотрубні блоки часто створюють негативний тиск, який затягує гаряче повітря і пил звідкиінде.
Якщо ви змушені використовувати переносне охолодження — переконайтеся, що шлях повітря збалансований і гарячий викид не рециркулює.

5) Чому верх стійки завжди гарячіший?

Стратифікація: гаряче повітря піднімається. Також багато шаф мають погане повернення повітря біля стелі, тому гаряче повітря накопичується вгорі.
Якщо верхні пристрої забирають це повітря — вони мають найгірші умови інлету, навіть коли «кімнатна» температура здається нормальною.

6) Який найшвидший спосіб довести, що тепло — винуватець?

Корелюйте три сигнали: зростання інлет/CPU температур, підвищення RPM вентиляторів і погіршення продуктивності/помилок. Потім зробіть контрольовану зміну
повітряного потоку (прибрати перешкоду або тимчасово відкрити двері) і спостерігайте, чи падають температури і стабілізуються помилки.

7) Чи викликає тепло корупцію даних?

Тепло може збільшити рівень помилок і таймаутів; корупцію зазвичай попереджають ECC, контрольні суми і механізми протоколів,
але ці захисти мають межі. Більший практичний ризик — це відмови під час rebuild/scrub, коли ваш запас надмірності вже зменшений.

8) Що пріоритетніше: більше охолодження чи кращий моніторинг?

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

9) Чому вентилятори на максимумі іноді погіршують ситуацію?

Максимальні вентилятори збільшують споживання енергії (ще більше тепла), збільшують вібрацію (маргінальні конектори й диски страждають),
і швидше засмоктують пил, що забиває фільтри й радіатори. Вони необхідні в аваріях, але свідчать про недостатність охолодження на рівні кімнати.

10) Як пояснити це нефаховим представникам фасіліті чи менеджменту?

Говоріть мовою ватів і ризику. «Цей стійок споживає приблизно X ват постійно; це тепло, яке потрібно видалити. Без шляху повернення
інлет-нагрівається і доступність падає.» Потім покажіть просту кореляцію: пікові температури проти інцидентів/RPM вентиляторів.

Висновок: наступні кроки, що покращують безвідмовність

Гарячі шафи не вибухають як у фільмі. Вони виходять з ладу як повільна фінансова теча: трохи більше латентності тут,
трохи більше повторів там, перебудова, що триває довше, ніж потрібно, і потім п’ятничний інцидент, що приходить із документами.
Виправлення не містить містики. Це повітря, вимірювання й дисципліна.

Зробіть це наступним, у порядку

1. Інструментуйте інлет-температуру у стійці (верх/середина/низ) і налаштуйте сповіщення.
2. Ставте тривоги на RPM вентиляторів і термальні події, щоб «гаряче» ставало причиною алерту до інциденту.
3. Кількісно визначте теплове навантаження в ватах за допомогою зчитувань BMC/PDU/UPS. Використайте число для рішень з фасіліті.
4. Виправте шляхи повітря: забезпечте приплив і повернення, блокування рециркуляції і вільний вихід викиду.
5. Оперціоналізуйте нудні перевірки: квартальні бази, тести батарей, дельти SMART і правило, що перебудови зберігання не виконуються під тепловим стресом.

Якщо ви експлуатуєте продакшн-системи в шафі, ви вже граєте на складному рівні. Принаймні зніміть з себе тепловий недолік.
Безвідмовність і так складна, не перетворюйте свою інфраструктуру на обігрівач з власною думкою.