Підбір живлення (PSU) для серверів — перестаньте гадати, почніть вимірювати

Чому підбір PSU — це проблема SRE, а не тільки закупівель

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

PSU — це місце, де ваша робоче навантаження стає фізикою. Сплески навантаження перетворюються на стрибки струму. Поведінка прошивки — в енергії вентиляторів. Нова мережна карта —
це кілька ватів, на які ви ніколи не заклали бюджет. І найобразливіше: коли з харчуванням щось йде не так, симптоми не завжди кричать «харчування».
Ви отримуєте нестабільні диски, несподівані перезавантаження, скиди NIC, пошкоджені датчики BMC або «випадкові» kernel panic. Проблеми з харчуванням маскуються під софтверні.

Ви прагнете трьох результатів:

• Жодних відмов, спричинених спрацьовуванням автоматів, перевантаженням PSU чи просадками напруги.
• Жодних втрат через надмірно великі PSU, що працюють у низькоефективному режимі.
• Швидкого відновлення, коли PSU виходить з ладу, падає живлення або PDU вас обдурює.

Якщо ваш метод підбору PSU — «підсумувати TDP і округлити вгору», ви керуєте продакшеном на надії. Надія — не джерело живлення.

Цікаві факти та трохи історії (щоб ви не повторювали старі помилки)

1. Ранні ПК-блоки живлення були орієнтовані на навантаження з тяжінням на 5V. Сучасні сервери в основному 12V-центровані, а DC-DC перетворення перемістилося на плату.
2. ATX12V (початок 2000-х) перекинув більше потужності на 12V для живлення CPU, змінивши значення «рейлів» та обмежень струму в реальних збірках.
3. 80 PLUS (сер. 2000-х) зробило ефективність маркетинговою і закупівельною позицією, але його тестові точки не покривають ваші спікоподібні навантаження.
4. Дата-центри змістилися від «один великий UPS» до розподілених UPS і розумних PDU, що спростило вимірювання — якщо ви справді ними користуєтесь.
5. Резервні PSU стали стандартом не тому, що вони модні, а тому, що гаряча заміна PSU краще, ніж вікно техпідтримки о 2-й ночі.
6. Сучасні CPU і GPU ввели агресивне підвищення частоти; миттєва потужність може перевищувати «TDP» у спосіб, який закупівельні презентації рідко згадують.
7. Криві вентиляторів змінили правила гри: вентилятори з високим статичним тиском можуть споживати значну потужність на повній швидкості, а оновлення прошивки можуть змінити поведінку вночі.
8. Щільність стояків зросла із появою віртуалізації і GPU; потужність і охолодження стали першими обмеженнями, а не лише місця в стійці.
9. Координація автоматів у будівлях еволюціонувала, але автомати все ще спрацьовують швидше за ваше оповіщення — особливо щодо пускового струму.

Здорова модель мислення: середнє, пікове і кепські секунди між ними

Помилки у підборі PSU виникають через використання одного числа, коли потрібно принаймні три:

• Середньостатистичне споживання в steady-state: що сервер споживає більшу частину часу.
• Тривалий пік: що він споживає під реальною роботою, не за синтетичною «TDP»-логікою.
• Транзієнт/пусковий струм: що він споживає під час завантаження, одночасного запуску дисків, розгону вентиляторів або стрибків GPU.

Додайте четверте, якщо використовуєте резервування:
режим з одним PSU — бо в конфігурації 1+1 вам все одно треба вижити на одному PSU без колапсу.

Що насправді означає «потужність PSU»

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

Цитата, яку варто мати на стіні

«Надія — не стратегія.» — Gen. Gordon R. Sullivan

Не SRE, але сенс болісно релевантний. У плануванні живлення «ймовірно, не піде в пік» — це надія, переодягнена в інженерію.

Жарт №1: PSU сервера — як парашут: якщо ви дізнаєтеся, що він замалий тільки коли він потрібен, у вас буде поганий день.

Що вимірювати (і що специфікації вам не скажуть)

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

Вимірюйте на кількох рівнях

• Вхідна потужність на стіні / PDU: за що ви платите і що може спровокувати спрацьовування автомата.
• Вихід PSU (рідко безпосередньо видимий): що система споживає у термінах DC.
• Підказки на рівні компонентів: потужність пакета CPU, GPU, активність дисків, оберти вентиляторів та PWM.

Знайте обмеження, які важливі

• Гілковий ланцюг (рейтинг автомата; практика дерейтингу для безперервного навантаження відрізняється по регіонах і кодексу).
• Обмеження PDU і вилки (C13/C14 vs C19/C20, перетин кабелю, ліміти на вихід).
• Номінал PSU на вашу вхідну напругу (поширена пастка: 120V vs 208/230V — продуктивність і доступний запас різняться).
• Режим резервування (розподіл навантаження vs активний/резервний; і чи витримає платформа один PSU при повному навантаженні).

Не плутайте ці терміни

• TDP: точка теплового проєктування, а не контрактне обмеження потужності.
• PL1/PL2 (та еквіваленти вендорів): тривале проти boost-політики потужності; прошивка може їх змінити.
• Уявна потужність (VA) vs реальна потужність (W): UPS і PDU можуть показувати одне або інше; коефіцієнт потужності важливий, коли ви близькі до лімітів.

Практичні завдання вимірювання (команди, виходи, рішення)

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

Завдання 1: Прочитати миттєву потужність, що її повідомляє BMC (IPMI)

cr0x@server:~$ ipmitool sensor | egrep -i 'Power|Pwr Consumption|Watts'
Pwr Consumption   | 312        | Watts      | ok

Значення: BMC вважає, що система зараз споживає ~312W (часто — вхідну потужність, іноді обчислену).
Рішення: Якщо це сильно відрізняється від очікуваного, звірте джерело BMC з вимірюванням PDU перед тим, як довіряти йому для планування ємності.

Завдання 2: Витягнути історію потужності / min-max якщо платформа це експонує

cr0x@server:~$ ipmitool sdr elist | egrep -i 'Pwr|Power'
System Level      | 00h | ok  |  3.1 | Power Meter
System Level      | 01h | ok  |  3.2 | Power Max
System Level      | 02h | ok  |  3.3 | Power Min

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

Завдання 3: Виміряти обмеження потужності пакета CPU і струм (Intel RAPL через powercap)

cr0x@server:~$ sudo cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw
225000000

Значення: 225,000,000 µW = 225W довготривале обмеження пакета (PL1-подібне) для цього домену RAPL.
Рішення: Якщо ваш підбір PSU базувався на «CPU 165W», але прошивка дозволяє 225W тривало, оновіть бюджет або встановіть обмеження.

Завдання 4: Виміряти енергію RAPL для оцінки середнього споживання CPU за інтервал

cr0x@server:~$ E1=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); sleep 10; E2=$(cat /sys/class/powercap/intel-rapl:0/energy_uj); echo $(( (E2-E1)/10000000 ))
186

Значення: Приблизно 186W в середньому для того пакета за 10 секунд (енергія в µJ поділена на 10s).
Рішення: Ідентифікуйте навантаження з тривалим високим споживанням CPU — саме вони роблять «пік» не рідкісною подією.

Завдання 5: Перевірити споживання GPU і ліміти (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,power.draw,power.limit,clocks.sm --format=csv,noheader
NVIDIA A10, 126.54 W, 150.00 W, 1395 MHz

Значення: Реальне споживання GPU 126W з лімітом 150W.
Рішення: Для GPU-серверів підбір PSU без реальної телеметрії GPU — це показуха. Якщо кілька GPU можуть одночасно досягти ліміту, закладайте цей пік.

Завдання 6: Перевірити поточну частоту CPU і статус тротлінгу (швидка перевірка)

cr0x@server:~$ lscpu | egrep -i 'Model name|CPU max MHz|CPU MHz'
Model name:          Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU max MHz:         3200.0000
CPU MHz:             2001.102

Значення: Поточна частота не підвищена; під навантаженням вона може різко зрости і збільшити потужність.
Рішення: Якщо ви бачите постійно низьку частоту під навантаженням, можливо, у вас обмеження по живленню або термальне обмеження — обидва пов’язані з PSU і охолодженням.

Завдання 7: Перевірити журнали ядра на події, пов’язані з живленням

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'power|brown|thrott|vrm|PSU|over current|watchdog' | tail -n 20
kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 27: b200000000070005
kernel: EDAC MC0: CPU power throttling detected

Значення: Апаратура/прошивка повідомили про тротлінг або помилки, які можуть бути пов’язані з доставкою живлення (не завжди, але варто корелювати).
Рішення: Якщо це корелює зі сплесками або перезавантаженнями, припиніть шукати «випадкову нестабільність» і перевірте живлення, PSU і терміку.

Завдання 8: Перевірити статус PSU і режим резервування через IPMI (якщо підтримується)

cr0x@server:~$ ipmitool sdr type 'Power Supply'
PS1 Status       | ok
PS2 Status       | ok
PS1 Input Power  | 165 Watts
PS2 Input Power  | 162 Watts

Значення: Обидва PSU активні і приблизно рівномірно ділять навантаження.
Рішення: Якщо ви очікували режим 1+1 з одним активним і одним в резерві, можливо ви не в тому режимі резервування, який думаєте. Оновіть модель відмови.

Завдання 9: Виміряти потужність від стіни через метрований Rack PDU (приклад SNMP)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.7.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.7.1 = INTEGER: 356

Значення: OID вендора повертає потужність на розетці в ватах (приклад: 356W). Семантика MIB відрізняється; підтвердіть одиниці виміру один раз, а потім автоматизуйте.
Рішення: Використовуйте показники PDU як істину для планування ланцюгів і ризику автомату. Показники BMC — «приємні для перегляду», але не ваш фінансовий орієнтир.

Завдання 10: Перевірити струм на виході PDU, щоб виявити ризик близький до спрацьовування

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.6.3.1.5.1
SNMPv2-SMI::enterprises.318.1.1.26.6.3.1.5.1 = INTEGER: 28

Значення: Струм на розетці (приклад: 2.8A якщо пристрій використовує декаампера); знову ж таки, залежить від вендора.
Рішення: Переведіть у ампери, порівняйте з лімітами ланцюга та PDU. Якщо ви близько — не додавайте «ще один вузол».

Завдання 11: Корелювати навантаження з потужністю за допомогою контрольованого тесту навантаження (CPU)

cr0x@server:~$ sudo apt-get -y install stress-ng
...
cr0x@server:~$ stress-ng --cpu 32 --cpu-method matrixprod --timeout 60s --metrics-brief
stress-ng: info:  [8421] dispatching hogs: 32 cpu
stress-ng: metrc: [8421] cpu                60.00s  19184.12 bogo ops/s

Значення: Ви створили відтворюване навантаження на CPU. Паралельно знімайте показники PDU/BMC.
Рішення: Побудуйте для платформи «CPU-only пік» як базову величину. Потім робіть те саме з диском і мережею, щоб побачити комбіновані піки.

Завдання 12: Активність дисків і кількість приводів важливі — виміряйте це (нагрузка на сховище)

cr0x@server:~$ iostat -dx 2 3
Device            r/s     w/s   rMB/s   wMB/s avgrq-sz avgqu-sz await  svctm  %util
nvme0n1         820.0   110.0   128.0    24.0     358     2.10   2.1   0.6   55.0

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

Завдання 13: Перевірити події заряджання батареї/модуля кеш-контролера

cr0x@server:~$ sudo dmesg | egrep -i 'battery|cachevault|supercap|charging' | tail -n 20
megaraid_sas 0000:3b:00.0: CacheVault charging started

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

Завдання 14: Перевірити оберти вентиляторів і PWM — вентилятори не безкоштовні

cr0x@server:~$ sudo ipmitool sdr | egrep -i 'FAN|RPM' | head
FAN1            | 7800   | RPM  | ok
FAN2            | 8100   | RPM  | ok

Значення: Високі оберти означають вищу витрату енергії на вентилятори і часто вказують на термальне навантаження або зміну профілю прошивки.
Рішення: Якщо бачите тривало високі обороти, перевірте повітряний потік і температуру на впуску; ваш бюджет потужності і терміка PSU погіршуються.

Завдання 15: Перевірити вхідну напругу PSU (бо 120V vs 208V має значення)

cr0x@server:~$ ipmitool sensor | egrep -i 'Inlet|VIN|AC|Voltage' | head
PS1 Inlet Volt   | 208        | Volts     | ok
PS2 Inlet Volt   | 208        | Volts     | ok

Значення: PSU бачать 208V, що зазвичай покращує ефективність і зменшує струм при однаковій потужності.
Рішення: Якщо ви на 120V і збільшуєте щільність, подумайте про переведення на вищу напругу живлення там, де це можливо. Це часто найпростіший спосіб збільшити потужність.

Завдання 16: Швидкий і грубий спостережний тест пускового струму через лог піків PDU (якщо підтримується)

cr0x@server:~$ snmpget -v2c -c public pdu01 1.3.6.1.4.1.318.1.1.26.4.3.1.6.1
SNMPv2-SMI::enterprises.318.1.1.26.4.3.1.6.1 = INTEGER: 47

Значення: Лічильник «пік струму з моменту останнього скидання» (приклад). Точний OID залежить від вендора і моделі.
Рішення: Якщо піковий струм значно вищий за установившийся, рознесіть завантаження і уникайте синхронного підключення після відключень.

Резервні PSU: 1+1 не завжди означає 1+1

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

• Потужності на один PSU порівняно з піковими потребами системи.
• Поведінки розподілу навантаження (active/active або active/standby).
• Поводження при обмеженні потужності, коли один PSU відсутній (деякі системи автоматично тротлять; інші просто падають).
• Незалежності живлення (два PSU на одному PDU — це не резервування; це оптимізм із зайвими кроками).

Простими словами про N+1

Якщо у вас два 800W PSU у конфігурації 1+1, важливе питання:
Чи може сервер працювати на піку на одному 800W PSU?
Якщо реальний виміряний пік — 780W біля стіни і PSU при високій вхідній температурі дерейтується, ви не «в безпеці». Ви стоїте на тонкому технічному розрахунку.

Балансування навантаження не гарантоване

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

Пусковий струм (inrush): автоматові байдуже ваші таблиці

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

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

Жарт №2: Автомати як інженери on-call: вони багато чого терплять, але пам’ятають саме ту одну останню соломинку.

Як зменшити ризик inrush

• Рознесіть завантаження (PDU, зовнішня автоматизація або гачки оркестратора).
• Уникайте синхронного розгону вентиляторів шляхом оновлення прошивки у контрольованих хвилях, а не «всі разом у п’ятницю».
• Знайте поведінку HDD: параметри staggered spin-up на HBA збережуть ваш автомат і гордість.
• Вимірюйте піковий струм там, де можливо: деякі метровані PDU і UPS ведуть логи пікiв та inrush-подій.

Дереатинг: температура, висота над рівнем моря, пил і чому «1200W» інколи фантазія

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

Дереатинг проявляється як:

• Менший доступний вихід при вищій температурі на впуску.
• Збільшена потужність вентиляторів (що підвищує системне споживання і знижує ефективність).
• Раніше термозахистне вимкнення або захисне тротлінгування.

Температура — множник ризику

Сервер, що «в нормі» при 18°C на впуску, може стати крихким при 30°C на впуску, коли один PSU виходить з ладу, а залишений працює гарячіше і голосніше.
Саме в такий момент найгірше дізнатися, що ваша припущення про резервування базувалося на лабораторному буклеті.

Висота над рівнем моря — це реальна річ (так, правда)

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

Криві ефективності: вати, які ви не витягуєте, все одно коштують вам

Ефективність — це не константа. Це крива. Більшість PSU «щасливі» десь на 40–60% навантаження, залежно від конструкції. При дуже низькому навантаженні ефективність падає,
і ви втрачаєте потужність у вигляді тепла. При дуже високому навантаженні ефективність теж може падати, і терміка стає некрасивою.

За замовчуванням надмірне збільшення PSU здається «безпечним», але воно може вести до марнотратства у трьох напрямках:

• Capex: моделі PSU більшої потужності коштують дорожче.
• Opex: нижча ефективність на холостому ходу по всьому парку — неприємно для рахунку за електрику.
• Охолодження: втрачені вати перетворюються на тепло, яке ваш об’єкт має відвести.

Що робити замість сліпого oversizing

Виміряйте реальний пік і виберіть PSU так, щоб:

• Ваш середній режим знаходився в ефективній частині кривої.
• Ваш тривалий пік залишався нижче консервативного порогу (особливо в режимі N+1).
• Ваш inrush не спрацьовував гілкові автомати під час масових подій у флоті.

Це менш гламурно, ніж купувати найбільший доступний блок. Але саме так ви уникнете проведення вихідних у холодному коридорі з ліхтариком.

Три корпоративні міні-історії з краю «має бути нормально»

Міні-історія 1: Інцидент через неправильне припущення

Компанія розгорнула нову партію серверів з великим сховищем: багато дисків, подвійні контролери і «резервні» PSU. Закупівля підібрала PSU, підсумувавши TDP CPU, RAM і «трохи для дисків».
Вони також стандартизували 120V живлення в застарілій кімнаті, бо воно «вже було там».

У steady-state усе виглядало нормально. Графіки моніторингу були нудні, і розгортання оголосили успішним. Потім майже планове обслуговування електропостачання. Після відновлення живлення
весь ряд спробував завантажитися одночасно. Декілька автоматів спрацювали миттєво. Декілька стійок піднялися напівжитими: деякі сервери зациклилися на завантаженні, деякі втратили диски, а пару контролерів піднялися деградованими.

Постмортем був брудний, бо перша хвиля дебагу пішла в сторону софту: версії ядра, порядок завантаження, прошивка RAID. Видимим натяком було те, що відмови групувалися по стійках і PDU, а не по збірках ОС.
Хтось нарешті витягнув логи пікових струмів PDU і порівняв їх з рейтингом гілкового автомату.

Причина не в тому, що сервери «споживали забагато» в середньому. Причина в тому, що inrush і одночасний запуск дисків перевищили толерантність автомата при 120V, де струм вищий при тій самій потужності.
«Резервні PSU» не допомогли, бо резервування не заважає автомату спрацювати.

Виправлення було нудним: рознесення завантаження, увімкнення staggered spin-up на HBA та переведення найщільніших стійок на вищу напругу де було можливо. Також почали фіксувати пікову потужність на PDU під час приймальних тестів.
Наступний сеанс обслуговування пройшов без пригод — а це найкращий тип події.

Міні-історія 2: Оптимізація, що повернулася бумерангом

Інша організація серйозно взялася за енергоефективність і вирішила агресивно «підібрати» PSU. Вони помітили, що сервери в простое споживають близько 120–160W і вирішили, що менші PSU покращать ефективність на холостому ході.
Вони затвердили стандартну конфігурацію з низькопотужними PSU для нового обчислювального флоту.

Лабораторні тести виглядали добре. Ідл-ефективність трохи покращилася. Закупівля була в захваті через скорочення витрат. Флот розгорнули в продакшен, де навантаження було імпульсним — аналітика батчами та сплески API.
Під час сплесків поведінка CPU boost підштовхнула тривалу потужність вище, ніж очікували.

Все ще «у специфікації» для одного PSU — до тих пір, поки PSU не вийшов з ладу.

За 1+1 резервуванням один PSU повинен був нести повне навантаження. На папері це можливо. На практиці, при вищих температурах на впуску і більший запиленості, ніж в лабораторії, залишений PSU працював гарячіше.
Прошивка платформи відповіла тротлінгом продуктивності. Сервіс не впав, але затримки зросли з «добре» до «чому черга тане». SREs сприйняли це як регресію софту, бо нічого не впало. Просто стало повільно й непередбачувано.

Проблема не в самій ідеї підбору; проблема була в тому, що це робили на підставі тестів холостого ходу й ігнорували режим N+1 та дерейтинг середовища. Вирішили підняти PSU на крок, запровадити обмеження потужності для найбільш імпульсивних вузлів і припинити оцінювати успіх виключно по ефективності в idle.
Ефективність важлива. Передбачуваність важить більше.

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

Команда, що керувала змішаним флотом (GPU-коробки, ноди сховища, звичайні обчислювальні), мала скупу політику: кожна нова модель заліза мала пройти «характеризацію потужності» перед тим, як потрапити в продакшен.
Це означало вимірювання idle, 50-го процентиля навантаження, тривалого піку і пускового inrush — використовуючи той самий PDU, що й у продакшені.

Чеклист також вимагав тестування резервування: витягніть один PSU під навантаженням і підтвердіть, що вузол залишається стабільним, з записами потужності і терміки.
Це не було опційно. Це не було «коли буде час». Це було обов’язковим, як тести відновлення RAID.

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

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

План швидкої діагностики

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

Перше: підтвердіть, що саме відмовляє (вузол, стійка, ланцюг чи кімната)

• Чи відмови групуються по стійці/PDU або по моделі заліза?
• Чи події корелюють з бойовими завантаженнями, обслуговуванням або стрибками температури?
• Чи бачите ви спрацьовування автоматів або тривоги UPS?

Друге: довіряйте PDU/UPS для вхідної потужності, потім перехресно перевірте BMC

• Перевірте PDU на рівні розетки: вати/ампери і будь-які лічильники піків.
• Порівняйте з BMC-значеннями; великі несходження вказують на погані сенсори або різні точки вимірювання.
• Підтвердіть вхідну напругу. Низька напруга означає вищий струм при тій самій потужності і менший запас.

Третє: протестуйте поведінку резервування під навантаженням

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

Четверте: ізолюйте транзієнтні причини

• Пусковий струм і старт дисків: шукайте події автомата або піки PDU при відновленні живлення.
• Зміни прошивки/криві вентиляторів: корелюйте з останніми оновленнями.
• Сплески навантаження: корелюйте з телеметрією CPU/GPU і часом інцидентів.

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

1) Випадкові перезавантаження під навантаженням

Симптом: Хости перезавантажуються, коли стартують пакетні задачі або сплески використання GPU.
Корінь: Перевантаження PSU або проблеми транзієнтної реакції; інколи один PSU слабкий/старіє і колапсує на крок-навантаженнях.
Виправлення: Виміряйте на PDU під час навантаження. Протестуйте з одним PSU виключеним. Замініть підозрілий PSU. Якщо піки реальні — підвищуйте потужність PSU або обмежуйте потужність.

2) Спрацьовування автоматів після обслуговування або відновлення живлення

Симптом: Цілі стійки темні, автомати спрацьовують одразу при подачі живлення.
Корінь: Пусковий струм плюс синхронне завантаження; запуск дисків і розгін вентиляторів це посилює, особливо при 120V.
Виправлення: Рознесіть завантаження. Увімкніть staggered spin-up. Знизьте щільність на ланцюг або переведіть на вищу напругу.

3) «Резервний» PSU але один вихід спричиняє падіння продуктивності

Симптом: Без відмови, але затримки зростають і пропускна здатність падає, коли один PSU помирає.
Корінь: Режим з одним PSU викликає обмеження потужності або термальний стрес; залишений PSU працює гарячим і прошивка тротлить CPU/GPU.
Виправлення: Підберіть так, щоб один PSU міг витримати тривалий пік з запасом при найгіршій вхідній температурі. Тестуйте і документуйте продуктивність у режимі відмови.

4) PDU показує високі вати, BMC — низькі (або навпаки)

Симптом: Два «авторитетних» числа розходяться на 20–40%.
Корінь: Різні точки вимірювання (вхід проти обчисленого), дрейф калібрування сенсорів або баги прошивки BMC.
Виправлення: Довіряйте PDU/UPS як істині для виставлення рахунків і автомата. Використовуйте BMC для трендів. При потребі калібруйте разом з відомим метрологічним приладом.

5) Нова прошивка спричинила перевитрату бюджету потужності

Симптом: Після оновлення BIOS/BMC вартість стійки зросла або стрибнула потужність вентиляторів; з’явилися тривоги автомата або UPS.
Корінь: Оновлені криві вентиляторів, вищі ліміти boost-потужності або інші профілі за умовчанням.
Виправлення: Повторно характеризуйте споживання після змін прошивки. Фіксуйте профілі потужності. Rollout оновлень хвилями з моніторингом PDU.

6) «Ми підібрали по TDP» і тепер усе тісно

Симптом: Математика з табличок каже, що ви в безпеці; реальні виміри говорять протилежне.
Корінь: TDP — не обмеження; накладні витрати платформи, пам’ять, диски, NIC, вентилятори і поведінка boost не були враховані.
Виправлення: Побудуйте виміряну модель потужності для кожної платформи: idle, типовий, тривалий пік, inrush і режим N+1. Припиніть використовувати суму TDP як остаточну відповідь.

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

Покроково: як підібрати PSU для моделі сервера (без гадань)

1. Визначте джерело істини для вимірювань. Для планування ємності використовуйте метрований PDU/UPS (вхідні вати); BMC — для трендів і статусу резервування.
2. Зафіксуйте умови впуску. Занотуйте вхідну напругу та приблизну температуру на впуску під час тестів. Дані потужності без умов — плітки.
3. Виміряйте чотири точки потужності:
   • Idle (після завантаження, сервіси стабільні)
   • Типове навантаження (репрезентативний продакшен-мікс)
   • Тривалий пік (стрес-тест, що імітує реальні вузькі місця)
   • Пуск/inrush (холодний старт, не теплий ребут)
4. Протестуйте поведінку N+1. Під навантаженням відключіть один PSU і спостерігайте стабільність, тротлінг і поведінку вентиляторів. Зафіксуйте потужність і терміку.
5. Застосуйте маржу свідомо. Додайте запас для помилок вимірювання, змін середовища, старіння і «сюрпризної прошивки». Уникайте миттєвої реакції «подвоїмо».
6. Перевірте відповідність ланцюгу. Переведіть вати в ампери при вашій напрузі і переконайтеся, що ви не фліртуєте з лімітом гілки під піками і inrush.
7. Визначте розмір PSU і режим резервування. Оберіть модель PSU так, щоб режим з одним PSU залишався стабільним на тривалому піку з реальним запасом.
8. Документуйте профіль. Зберігайте виміряні значення і умови тестів у вашому runbook по залізу, щоб наступна людина не займалась археологією.
9. Операціоналізуйте моніторинг. Налаштуйте оповіщення при незвичному зростанні потужності, але також при втраті резерву і несподіваних змінах в поділі навантаження.
10. Повторно тестуйте після суттєвих змін. BIOS/BMC оновлення, нові NIC/HBA, зміни моделі GPU або зсуви в навантаженнях заслуговують повторного вимірювання.

Контрольний список: бюджету стояка, який ви зможете захистити на нараді

• На стійку: виміряний типовий і виміряний пік, а не просто сума шильдиків.
• На гілку: ампераж при фактичній напрузі з чіткими припущеннями про допустиму безперервну завантаженість.
• План по inrush: процедура рознесення завантаження задокументована і протестована.
• План резервування: PSU на різних вводах; PDU на різних upstream де можливо.
• Тести приймання: кожна нова модель заліза проходить прогін характеристик потужності перед розгортанням.

Контрольний список: версія «ми збираємося додавати GPU»

• Виміряйте ліміт потужності GPU на карту і підтвердьте загальну рамку потужності платформи.
• Підтвердіть обмеження PCIe auxiliary power і riser; не припускайте, що проводка шасі відповідає маркетингу GPU.
• Протестуйте сумарний CPU+GPU пік під реальними навантаженнями (не лише синтетичними).
• Перевірте поведінку резервування при відключенні одного PSU під GPU-навантаженням.
• Підтвердіть ланцюг і тип розетки PDU (C13 vs C19) та ліміти на розетку.

FAQ

1) Чи можу я підібрати PSU, підсумувавши TDP компонентів?

Використовуйте суму TDP лише як орієнтовний нижній межа. Реальні системи перевищують його через boost-поведінку, потужність вентиляторів, зарядні явища контролерів і транзієнти.
Вимірюйте на PDU.

2) Чи завжди купувати PSU з максимальною потужністю?

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

3) Який запас слід додати?

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

4) Кому довіряти більше: BMC чи PDU?

Для планування автомата і ємності: PDU/UPS вхідні вати. Для трендів по хосту і статусу резервування: BMC корисний. Якщо вони розходяться, розберіться, але бюджетуйте за PDU.

5) Чому споживання стрибає після оновлення BIOS/BMC?

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

6) Як резервні PSU впливають на ефективність?

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

7) Що таке VA vs W при підборі UPS і ланцюгів?

W — реальна потужність; VA — уявна потужність. UPS і PDU можуть вказувати одне або інше. Якщо коефіцієнт потужності далеко від 1.0, VA може бути значно вищим за W, і це може стати обмеженням для ємності UPS, навіть коли вати в нормі.

8) Як уникнути спрацьовування автоматів під час перезапусків флоту?

Рознесіть завантаження, увімкніть staggered spin-up дисків де можливо і уникайте «усі вузли одночасно вгору». Підтвердіть за допомогою логів піків PDU і проведіть контрольований тест.

9) Чи треба мені хвилюватися про ліміти рейлів PSU?

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

10) Який практичний спосіб обмежити потужність серверів, щоб не перевищувати ліміти?

Використовуйте інструменти вендора або профілі прошивки де можливо і перевіряйте через PDU. Для CPU обмеження на базі RAPL може допомогти, але підтвердіть поведінку під вашими навантаженнями — деякі навантаження міняють затримку заради ватів у неприємний спосіб.

Наступні кроки, які ви можете зробити цього тижня

• Виберіть одну модель сервера і створіть профіль потужності: idle, типове, тривалий пік, пуск/inrush і результати тесту N+1.
• Зробіть PDU джерелом істини для вхідної потужності і піків; підключіть SNMP-опитування до вашого пайплайна метрик.
• Проведіть контрольований тест резервування: під значним навантаженням витягніть PSU і стежте за тротлінгом, розгоном вентиляторів і стрибками потужності.
• Напишіть процедуру рознесення завантаження і відрепетируйте її. Після відключення не час виявляти, що ваші інструменти не вміють секвенувати.
• Оновіть вимоги до закупівель: вимагайте метровані PSU/BMC сенсори де можливо і просіть вендорів описати поведінку в режимі одного PSU.
• Повторно перевіряйте після оновлень прошивки. Підходьте до «незначних ревізій» як до нових моделей, поки не виміряєте їх.

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