Або що знадобиться знати і вміти, якщо заміна ІБП після поломки - втрата професійної гордості.
Частина 1
Частина 2
TL;DR
І знову вітаю, шановні колеги і читачі. За пару років досить щільної роботи з безперебійниками я зробив для себе багато «» відкриттів дивних «». Поспішаю поділитися з вами.
Disclaimer
- Мова йде в основному про ІБП потужністю 400-800VA, «» лінійно-інтерактивних «», зі свинцевими батареями 12В;
- Безперебійне забезпечення в основному офісних «» друкарських машинок «»: ЦП потужністю до 100 Вт і SSD в якості системних дисків, без дискретних відеокарт;
- Централізованого ІБП немає.
Вирішувані завдання:
- Мінімум: мати хоча б загальне уявлення про стан парку пристроїв;
- Добре: змінювати пристрої ДО виникнення збою, забезпечуючи тим самим їх фактичний і економічний сенс. Так-так, просто поставити ІБП абсолютно недостатньо;
- Відмінно: мати наочні дані - що було зроблено IT-службою і чому це було необхідно зробити (витративши на це гроші і людиногодини).
Про офісні UPS
В черговий раз повторюся: поставити і забути - не прокатує.
ІБП без функції передачі даних марні практично повністю, оскільки не вирішують одну з найважливіших проблем - безпечне вимикання зі збереженням даних. На жаль, ІБП з передачею даних теж далеко не панацея. Тому є кілька причин:
1. Якість з "єднання
На підставі дворічного спостереження можу з упевненістю сказати, що це біда.
Якщо не стежити за підключеннями досить уважно, більшість з безперебійників повідвалюються протягом півроку. Така поведінка сильно залежить від конкретних умов і змінюється від машини до машини. Основні причини втрати з'єднання (наскільки мені вдалося розібратися):
а) суто фізичні. Сюди входять ненадійні роз'єми (і вони трапляються частіше, ніж хотілося б), випадкові порушення з'єднань (прибиральниця занадто ретива, користувач дергає ногами або рухає системник) і, раптово, якість сполучного кабелю - схоже, що ІБП досить чутливі до цього параметра, особливо при активному опитуванні;
б) на другому місці не «» глючні драйвери «», що дивно, а електроніка самих ІБП. Схоже, безперебійникам з нижнього цінового сегмента не дуже подобається, коли їх часто «» дергають «».
трохи детальніше
взагалі, обмін даними з ІБП йде постійно, але все ж не раз в мілісекунду. Драйвер usbhid-ups отримує дані раз на 2 секунди (видно в дебаг-режимі, якщо запускати руками з параметром -D +), щось схоже, напевно, і в стандартному драйвері Windows і WMI. Але це тільки «» часткове «» оновлення, «» повне «» оновлення відбувається раз на 30 секунд
є ймовірність, що «» повний «» запит сильно навантажує електроніку ІПБ, і при частих запитах вона починає підглючувати. Це безпосередньо стосується реалізації сервера, про який йдеться в статтях. Чим це загрожує і що з цим робити - див. далі
2. Робота внутрішніх систем, сенсорів і логіки UPS
По-перше, ІБП від різних виробників поводяться з батареєю по-різному. У моїй практиці гірше всіх поводяться з батареями ІБП Powercom, краще за всіх - IPPON (далі за батареєю див. п.3). Відмінність не принципова, Powercom теж через півроку не дохнуть, але вона є і досить помітно, якщо аналізувати накопичені дані за досить тривалий період. Тут переходимо до по-друге: найбільш цікаві параметри, які ІБП сам вважає і видає:
а) навантаження (load)
б) передбачення часу роботи від батареї (runtime), обчислюване на основі навантаження
в) поточний заряд батареї (charge)
На ці параметри я вже лаявся в попередніх статтях, так що повторюватися не буду, а просто коротко резюмую: це синтетика, що має дуже мало відношення до реальності. В якихось ІБП ці дані поадекватніші, в якихось зовсім ідіотизм, але в цілому без реальної динаміки від цих даних не просто вкрай мало користі - вони можуть ввести в оману.
На жаль, є куди більше параметрів, які аналізувати, рахувати і навіть просто отримувати варто було б, але це не реалізовано.
Найпростіший приклад: просадка напруги на батареї, коли пропадає живлення. Це показовий параметр, на підставі якого можна куди точніше зробити висновок про вбиту батарею. Постійна пам'ять EEPROM є зараз де завгодно, і ІБП запросто може записувати такі дані самостійно. Але жодного ІБП з таким функціоналом мені не попалося.
Інший приклад: Powercom'и після втрати живлення і розряду батареї до 30 відсотків можуть «» зарядити «» 12-вольтову батарею за 10 хвилин і стверджувати, що все прекрасно, а Self-test passed.
якщо вас нічого не бентежить
час повного заряду 12 У свинцевій батареї навіть в «» агресивному «» режимі складе не менше години, і батарея після такого довго не живе
Це прямо натуральний epic fail.
Ті ж Powercom не вміють у вольтаж батареї взагалі, тільки у відсотки. На підставі чого там ці відсотки всередині вважаються - покрито китайською морокою.
Дуже важливого параметра «» температура «» (батареї, всередині корпусу, та хоч чого-небудь) не знайти вдень з вогнем в офісних ІБП, хоча датчик копійчаний і взагалі вбудований в майже всі мікроконтролери. Тут переходимо до третього пункту розділу.
3. Батарея і її стан
З того зоопарку, з яким я мав справу, «» посередньо «» справляється із завданням аналізу стану батареї серверний ІБП IPPON. Потуги інших інакше як «» безглуздо «» назвати не можу. Дуже важливий параметр батареї - крива розряду - просто ігнорується.
трохи про криву розряду
Свинцеві батареї ІБП розряджаються нелінійно. Простіше кажучи, чим менше заряду залишилося в батареї, тим швидше вона розряджається. Ще простіше: час розряду зі 100% до 90% буде в рази більшим, ніж з 20% до 0%. Але і це ще не все. Крива розряду стає крутішою у старішій батареї та/або в залежності від зовнішніх умов (та сама температура). У підсумку це виглядає так:
Відчуваєте підступ? Вгадайте, чи проводить ІБП запис швидкості останнього розряду, аналіз, чи враховує дату встановлення батареї?
спойлер
ІБП ваще пофігу, не аналізує, не враховує. Найкраще, що я бачив - через три роки починає кричати «» чота батарея стара «».
Згадаймо, з чого ми почали цей розділ: передача даних з ІБП потрібна для того, щоб зберегти дані, поки ще залишився час. Але ні ІБП, ні драйвер не знають, який час є безпечним: 50% нової батареї зовсім не те ж саме, що 50% однорічної батареї. І єдине рішення проблеми на даний момент: параметр потрібно періодично модифікувати вручну.
Запис і розрахунок параметрів реалізовано в черговому оновленні сервера моніторингу. Зокрема, тепер видно:
- просадку заряду батареї безпосередньо після втрати живлення. Якщо цей показник низький, сервер видасть попередження;
- швидкість розряду батареї. Цей параметр потребує, щоб розрахувати не менше 2 мін спостереження за розрядом ІБП.
Для коректного врахування цих параметрів потрібно досить часте опитування ІБП. Відповідні зміни внесено до коду сервера (див. розділ «NUT і сервер моніторингу»). На жаль, тут ми впираємося в раніше озвучений п. «» б «» ч. 1 поточного розділу - при частих зверненнях за даними можливі глюки. Більш того, в перші секунди після втрати харчування ІБП дані не віддає взагалі, а замість цього передає "WAIT" ". По-хорошому, після втрати харчування ІБП для цілей моніторингу потрібно б опитувати якомога частіше. На даний момент частота опитування від 10 до 30 секунд, в цілому для більш-менш пристойного аналізу цього вистачає. Більш інтенсивні опитування не тестувалися досить довго, щоб робити якісь однозначні висновки.
Короткі підсумки розділу:
- обов'язково потрібен моніторинг самого факту підключення ІБП до машини;
- потрібно збирати і зберігати дані про дати установки батарей;
- в ідеалі потрібно дуже детально моніторити процес розряду і заряду батарей.
NUT і сервер моніторингу
Спочатку NUT був обраний як кроссплатформенне універсальне рішення. Загалом функції свої виконує. Без нюансів, втім, не обійшлося:
а) Не надто доброзичлива і неочевидна установка на клієнтських машинах, під Windows особливо. Зокрема:
- іноді відмовляється бачити бібліотеки;
- вбудований драйвер не оновлювався давно і половину ІБП не знає. Драйвер треба ставити вручну, і це окрема пісня;
- на клієнтах під Windows служба стартує «» невчасно «», раніше, ніж фактично потрібно (схожа історія є при пошуку домену на Windows з деякими мережевими адаптерами). Через це доводиться городити милиці.
б) Заявлено, що клієнт NUT може сповіщати сервер про зникнення і відновлення харчування, і навіть виконувати скрипти за цими подіями. Це прибрало б і необхідність частого опитування ІБП, і дозволило б вести більш точковий моніторинг важливих станів (див. попередній розділ). Однак змусити стабільно працювати цей функціонал мені не вдалося. Деякі машини не тригерять сервер взагалі, або роблять це один раз з десяти. При цьому є машини, з яких це працює стабільно.
Як альтернативу я спробував (і навіть написав «адаптер») отримувати дані з WMI за пропозицією @ firedragon. Суть, загалом, та ж. Плюси: не потрібно альтернативних дайверів і бібліотек, не потрібно милити деякі речі. Мінуси: інформації сильно менше, а в порівнянні з налаштованим клієнтом NUT стабільність рівно та ж, при цьому відсутня, хоча б потенційна, можливість «» трігера «».
За результатами вишукувань вирішено було залишити NUT як основне рішення для сервера. При цьому «» сильно більше даних «» в якийсь момент обернулося базами, роздутими по 100 Мб на безперебійник, що вплинуло на продуктивність. У підсумку сервер було перенесено з середовища Windows в Linux, і:
- написано відповідний скрипт-демон на bash для безперервного опитування;
- оптимізовано зберігання даних: якщо є живлення на вході і деякі інші параметри в нормі, останній рядок не додається в базу, а оновлюється.
У саму веб-морду сервера, як вже говорилося, додано:
- відображення заряду батареї відразу після останньої втрати живлення і відповідний алерт;
- розрахунок часу роботи від батареї на основі реальних даних. Деяким чином це теж синтетика, оскільки реальна крива розряду не будується. Однак, відмінно себе показала наступна формула: розрахований на основі останніх реальних даних час/1 + років з десятими.
Підсумки, поради, плани
Для тих, хто хоче «» зробити все правильно «», виходячи з отриманого досвіду, дам такі поради:
- Ретельно виберіть марку і модель ІБП і за можливості використовуйте тільки обраний ІБП у всьому офісі;
- Запишіть серійні номери та/або присвойте кожному ІБП унікальний номер. Запишіть дату встановлення батареї в кожен ІБП. Змінюйте батареї раз на два роки, і відразу, заздалегідь, закладайте ці витрати в бюджети - для бізнесу заплановані витрати набагато зручніші раптових;
- Будь-яким способом стежте за тим, щоб машини, забезпечені ІБП, мали з ним постійний зв'язок;
- Раз на півроку оновлюйте параметри battery low і battery warning у використовуваному вами драйвері/рішенні, додаючи до них від 5% до 20% залежно від досвіду використання вашої моделі ІБП, вручну або скриптами;
- По можливості проводьте ручне тестування ІБП (відключити від розетки і почекати) раз на квартал-півроку.
Це те, що потрібно робити обов'язково.
Використання постійного і докладного моніторингу, в цілому, швидше надмірно, хоча і може виявитися корисним і наочним. Заводити для цього окремий сервер чи ні, вирішувати вам. Деякі параметри можна моніторити в тому ж Zabbix (і навіть за допомогою WMI), проте особисто у мене в цілому не дуже вдалий досвід з Zabbix active parameters; до того ж, складність реалізації деяких описаних рішень всередині Zabbix за складністю наближається, на мій смак, до складності реалізації представленого сервера моніторингу.
Я здивований і радий, що досить багато читачів задумалося про моніторинг ІБП після першої статті, і багато хто порадив довести рішення «» до ентерпрайзу «» після другої статті. Дякую за відгуки і відповіді!
Враховуючи накопичений досвід, реалізація «» до ентерпрайзу «» може бути досить тривалою. Є проблеми і на клієнтській стороні, і в самому NUT; у веб-інтерфейсі багато чого треба виносити в бекенд, немає навіть банальної авторизації. Можна було б навіть у такому вигляді запхати все це в контейнер Docker як версію 0.1 alpha, але мій ентузіазм до теми кілька згас. Якщо у когось ентузіазм знайдеться - пишіть, буду радий попрацювати разом!
Радий, якщо мій досвід вам знадобиться. Спасибі всім, хто прочитав!