Налаштування NUT у homelab закриває просту задачу: коли зникає живлення, сервери не мають падати хаотично. UPS тримає навантаження кілька хвилин, а NUT стежить за станом батареї, роздає події по мережі й запускає коректне вимкнення там, де це справді потрібно.
Для домашньої інфраструктури схема зазвичай проста: один хост підключений до UPS по USB або мережі, решта машин отримують статус через NUT clients. У цій звʼязці важлива не стільки установка пакетів, скільки правильна логіка відключення – що вимикати одразу, що тягнути до low battery, а що взагалі не чіпати.
У small homelab цього часто достатньо, щоб пережити короткі просадки без втрати даних і без ручного бігу до стійки. Але погано зібрана схема дає хибні shutdown-події, завислий драйвер USB і кілька машин, які гасять одна одну раніше за UPS.
Яку схему брати для UPS і NUT
Для більшості сценаріїв підходить одна точка підключення UPS і роздача стану через мережу. Така схема спрощує налаштування NUT, бо драйвер працює тільки на одному вузлі, а інші системи бачать уже готовий статус і реагують на нього своїм shutdown policy.
Практично це виглядає так: невеликий Linux-хост, NAS або гіпервізор має USB-зʼєднання з UPS. На ньому працюють драйвер, сервер і монітор NUT. Інші сервери, роутери або віртуальні машини підписуються на цей вузол як клієнти.
Мережевий UPS із власним management card спрощує фізику підключення, але не прибирає головне питання – хто приймає рішення про завершення роботи. Якщо дати кожній машині окрему локальну логіку без координації, порядок відключення швидко стає випадковим.
Нетривіальний момент: у homelab не завжди варто вимикати все. DNS, router VM, storage і гіпервізор часто треба гасити в конкретній послідовності. Інакше клієнти втрачають мережу раніше, ніж отримують команду на shutdown.
Налаштування NUT на сервері, підключеному до UPS
Базове налаштування NUT складається з драйвера пристрою, процесу upsd і монітора upsmon. На Linux-хості, який фізично бачить UPS, спочатку ставлять пакет NUT, описують модель у конфігу й вказують режим роботи сервера.
У Debian/Ubuntu типовий набір виглядає так:
sudo apt update sudo apt install nut
Далі задають режим standalone або netserver – залежно від того, чи роздаватиме хост статус іншим машинам. Для homelab частіше потрібен netserver.
MODE=netserver
Опис UPS зазвичай додають у конфіг драйвера. Назва драйвера залежить від виробника та того, як пристрій визначився в системі.
[ups]
driver = usbhid-ups
port = auto
desc = "Homelab UPS"
Після цього NUT запускає драйвер і відкриває стан UPS через upsd. Для локального монітора додають облікові дані й джерело подій.
MONITOR ups@localhost 1 monuser strongpassword master
Далі логіка проста: коли мережа живлення пропадає, NUT переводить UPS у статус on battery. Коли батарея доходить до порога low battery, upsmon викликає системне завершення роботи. Поріг зазвичай задає сам UPS, і саме тут часто виникає перша пастка: частина моделей віддає занадто грубий або нестабільний статус, тому тест без реального відключення живлення нічого не доводить.
Як підключити інші машини як NUT clients
Клієнтська частина NUT потрібна там, де сервер не має прямого доступу до UPS, але має завершитись синхронно з ним. На таких вузлах зазвичай достатньо upsmon у режимі slave: машина стежить за мережею станів і гаситься, коли master повідомляє критичний стан батареї.
На клієнті встановлюють пакет NUT, вказують режим netclient і додають підписку на UPS-сервер.
sudo apt install nut
MODE=netclient
MONITOR [email protected] 1 monuser strongpassword slave
У правилах доступу на сервері треба дозволити підключення клієнтів із локальної мережі. Якщо цього не зробити, upsd працюватиме локально, а клієнти бачитимуть timeout або authentication error.
На цьому місці часто ламаються віртуалізовані схеми. Якщо NUT server крутиться у VM, а сам гіпервізор має вимикатись раніше за неї, ланцюг руйнується. Для фізичного USB-підключення надійніше тримати NUT на хості, який гарантовано живе довше за решту учасників відключення.
Порядок вимкнення вирішує більше, ніж сам UPS
Налаштування NUT працює нормально лише тоді, коли визначено порядок зупинки сервісів і вузлів. Спочатку гасять прикладні навантаження, потім залежні VM, далі storage, і тільки після цього – гіпервізор або вузол, що тримає UPS-сесію.
Для Proxmox, libvirt або Docker-хостів проблема однакова: хтось має дожити до моменту, коли клієнти вже завершилися. Якщо storage відключився раніше, журнали файлової системи ще встигнуть закритися, але мережеві сервіси отримають брудний розрив. Якщо раніше падає router VM, частина клієнтів навіть не дочекається команди.
У невеликому стеку корисно розділити вузли на дві групи:
- те, що можна вимикати відразу після переходу на battery;
- те, що має жити до low battery;
- те, що не вимикається автоматично взагалі.
Остання група інколи потрібна для мережевого обладнання або окремого сервера спостереження. Інакше після кожного короткого блекауту вся інфраструктура стартує з нуля, хоча UPS спокійно тримав би її далі.
Як перевірити налаштування NUT без сюрпризів
Перевірка має пройти не тільки на рівні сервісів, а й на рівні реального сценарію зникнення живлення. Якщо налаштування NUT показує статус UPS і клієнти бачать сервер, це ще не гарантує коректний shutdown на low battery.
Спочатку перевіряють, що UPS читається локально:
upsc ups@localhost
На клієнті перевіряють мережевий доступ:
upsc [email protected]
Потім дивляться стан служб:
systemctl status nut-server systemctl status nut-monitor
Нормальний тест – відключити UPS від мережі й подивитися, як змінюється статус: on line, on battery, low battery. Саме тут спливають помилки USB autosuspend, нестабільний кабель, завислий HID-драйвер або затримка між подією й дією клієнтів.
Ще один момент: після повернення живлення не кожен хост повинен стартувати автоматично. Якщо батарея вже майже порожня, а мережа мигнула на кілька секунд, можливий цикл boot-shutdown-boot. На практиці це бʼє по дисках сильніше, ніж саме аварійне вимкнення.
Де налаштування NUT зазвичай ламається
Найчастіша проблема – USB-пристрій бачить kernel, але NUT не має доступу через права або неправильний драйвер. Друга – UPS формально підтримується, але частина полів телеметрії порожня або змінюється ривками. Для моніторингу це терпимо. Для автоматичного shutdown – уже ні.
Часто трапляються й такі збої:
- UPS підключений до NAS або router appliance, але доступ до upsd зовні закритий firewall.
- Клієнти привʼязані до hostname, який перестає резолвитись під час аварії.
- Shutdown запускається всередині контейнера, а не на хості.
- Одна UPS-сесія обслуговує занадто багато вузлів, і вони вимикаються одночасно без пріоритетів.
Останній пункт недооцінюють. До певного масштабу одна точка керування нормальна. Коли від однієї батареї живляться storage, кілька гіпервізорів, PoE-комутатори і мережевий шлюз, простий master-client вже слабкий. Тут краще окремо планувати живлення мережі, окремо – серверної частини, інакше NUT лише фіксує хаос, а не керує ним.
Коли UPS і NUT вже не закривають задачу
UPS і NUT добре працюють у homelab, де треба виграти кілька хвилин на коректне завершення роботи. Для довгих відключень вони не замінять продуману енергосхему, окремі лінії живлення, генератор або orchestration, яке вміє запускати сервіси у правильному порядку після повернення електрики.
Якщо інфраструктура складається з одного NAS і одного хоста віртуалізації, цього вистачає з запасом. Якщо вже зʼявляються кілька шарів залежностей, реплікація, зовнішній storage і мережеві VM, налаштування NUT треба розглядати як нижній рівень захисту, а не як повну стратегію відмовостійкості.
Офіційний сайт проєкту NUT – Network UPS Tools. Там варто перевіряти сумісність драйверів і список підтримуваних пристроїв перед купівлею UPS, а не після.
Коментарі 1