Или что будет полезно знать и уметь при замене ИБП после срывы – ущерб профессиональной гордости.
Часть 1 Часть 2 ТЛ;ДР И еще раз приветствую вас, дорогие коллеги и читатели.
За пару лет достаточно плотной работы с источниками бесперебойного питания я сделал для себя немало «чудесных открытий».
Спешу поделиться с вами.
Отказ от ответственности
- Речь идет в основном об ИБП мощностью 400-800ВА, «линейно-интерактивных», со свинцовыми аккумуляторами напряжением 12В;
- Бесперебойное обеспечение преимущественно офисных «пишущих машинок»: CPU до 100 Вт и SSD в качестве системных накопителей, без дискретных видеокарт;
- Централизованного ИБП нет.
- Минимум: иметь хотя бы общее представление о состоянии парка устройств;
- Хорошо: меняйте устройства ДО того, как произойдет отказ, тем самым обеспечив их реальный и экономический смысл.
Да-да, просто установить ИБП совершенно недостаточно;
- Отлично: иметь наглядные данные — что делала ИТ-служба и почему это нужно было делать (тратить на это деньги и человеко-часы).
Об офисном ИБП
Еще раз повторю: поставил и забыл – не работает. ИБП без функции передачи данных практически полностью бесполезны, так как не решают одну из важнейших задач – безопасное завершение работы с сохранением данных.К сожалению, ИБП с передачей данных тоже далеко не панацея.
На это есть несколько причин:
1. Качество связи
По результатам двухлетних наблюдений могу с уверенностью сказать, что это катастрофа.Если не следить за соединениями достаточно внимательно, большинство систем ИБП выйдут из строя в течение полугода.
Такое поведение сильно зависит от конкретных условий и варьируется от машины к машине.
Основные причины потери соединения (насколько мне удалось выяснить): а) чисто физический.
Сюда входят и ненадежные разъемы (а они случаются чаще, чем хотелось бы), случайные сбои подключения (уборщица слишком усердствует, пользователь дергает ногами или двигает системный блок) и, вдруг, качество соединительного кабеля - оно кажется, что ИБП довольно чувствительны к этому параметру, особенно при активном опросе; б) на втором месте не «глючные драйвера», что удивительно, а электроника самих ИБП.
Похоже, поставщики источников бесперебойного питания из нижнего ценового сегмента не очень любят, когда их часто «дергают».
немного подробнее вообще обмен данными с ИБП происходит постоянно, но все же не раз в миллисекунду.
Драйвер usbhid-ups получает данные раз в 2 секунды (виден в режиме отладки, если запустить его вручную с параметром -D+), нечто подобное, вероятно, справедливо и для стандартных драйверов Windows и WMI. Но это только «частичное» обновление, «полное» обновление происходит раз в 30 секунд.
есть вероятность, что «полный» запрос сильно нагружает электронику ИБП, а при частых запросах он начинает давать сбои.
Это напрямую касается реализации обсуждаемого в статьях сервера.
Что это значит и что с этим делать – читайте ниже
2. Работа внутренних систем, датчиков и логики ИБП.
Во-первых, ИБП разных производителей по-разному обращаются с батареей.
В моей практике хуже всего к аккумуляторам относится ИБП Powercom, лучше всего IPPON (далее о аккумуляторе см.
пункт 3).
Разница не принципиальна, Powercom тоже не умрет через полгода, но она есть и весьма заметна, если анализировать накопленные данные за достаточно длительный период. Здесь переходим ко второму: наиболее интересным параметрам, которые рассчитывает и выдает сам ИБП: нагрузка б) прогноз срока службы батареи (времени работы), рассчитанный в зависимости от нагрузки в) текущий заряд батареи (заряд) Я уже ругался на эти параметры в предыдущих статьях, поэтому не буду повторяться, а просто кратко резюмирую: это синтетика, имеющая очень мало отношения к реальности .
В некоторых ИБП эти данные более адекватны, в других полный идиотизм, но в целом без реальной динамики эти данные не только крайне бесполезны - они могут вводить в заблуждение.
.
К сожалению, есть еще много параметров, которые стоило бы проанализировать, посчитать и даже просто получить, но это не реализовано.
Самый простой пример: падение напряжения на аккумуляторе при пропадании питания.
Это очень показательный параметр, на основании которого можно сделать гораздо более точный вывод о севшей батарее.
Память EEPROM, доступная только для чтения, теперь доступна повсюду, и ИБП может легко записать такие данные самостоятельно.
Но с таким функционалом я не встречал ни одного ИБП.
Другой пример: Powercoms после потери питания и разрядки аккумулятора до 30 процентов может «зарядить» 12-вольтовую батарею за 10 минут и заявить, что все в порядке, и Self-test пройден.
если тебя ничего не беспокоит время полной зарядки свинцового аккумулятора 12 В даже в «агрессивном» режиме составит не менее часа, а батарея после этого прослужит недолго Это прямо эпический провал.
Тот же Powercom вообще не умеет рассчитывать напряжение батареи, только в процентах.
На основании чего эти проценты рассчитываются внутри страны покрыто китайской тьмой.
Очень важный параметр «температура» (батарейки, внутри корпуса или чего-либо еще) в офисных ИБП днем не встретишь, хотя датчик дешевый и вообще встроен почти во все микроконтроллеры.
Здесь мы переходим к третьему пункту раздела.
3. Аккумулятор и его состояние
Из зоопарка, с которым я имел дело, серверный ИБП IPPON «посредственно» справляется с задачей анализа состояния батареи.Усилия остальных иначе как «бессмысленными» назвать не могу.
Очень важный параметр аккумулятора – кривая разряда – просто игнорируется.
немного о кривой разряда Свинцовые аккумуляторы ИБП разряжаются нелинейно.
Проще говоря, чем меньше заряда осталось в аккумуляторе, тем быстрее он разряжается.
Еще проще: время разряда со 100% до 90% будет в разы дольше, чем с 20% до 0%.
Но это не все.
Кривая разряда становится более крутой при использовании более старой батареи и/или в зависимости от внешних условий (одна и та же температура).
В итоге это выглядит так:
Чувствуете подвох? Угадайте, ИБП фиксирует скорость последнего разряда, анализирует ее и учитывает дату установки батареи? спойлер ИБП особо не волнует, он это не анализирует, не учитывает. Самое лучшее, что я видел, это то, что через три года он начинает кричать "Аккумулятор старый".
Давайте вспомним, с чего мы начали этот раздел: передача данных с ИБП нужна для того, чтобы сохранить данные, пока еще есть время.
Но ни UPS, ни драйвер не знаю, какое время безопасно: 50% новой батареи — это не то же самое, что 50% батареи годовой давности.
.
И единственное решение проблемы на данный момент: параметр необходимо периодически изменять вручную.
Запись и расчет параметров реализованы в ближайшем обновлении сервера мониторинга.
В частности, теперь вы можете увидеть:
- потеря заряда аккумулятора сразу после пропадания питания.
Если этот показатель низкий, сервер выдаст предупреждение;
- скорость разряда аккумулятора.
Для расчета этого параметра требуется как минимум 2 минуты наблюдаемого разряда ИБП.
Соответствующие изменения внесены в код сервера (см.
раздел «NUT и сервер мониторинга»).
К сожалению, здесь мы упираемся в ранее изложенный пункт «б» части 1 текущего раздела — при частых запросах данных возможны глюки.
Причём в первые секунды после пропадания питания ИБП вообще не передает данные, а вместо этого передает «WAIT».
По-хорошему, после пропадания питания ИБП нужно как можно чаще опрашивать в целях мониторинга.
На данный момент частота опроса составляет от 10 до 30 секунд, в целом этого достаточно для более-менее приличного анализа.
Более интенсивные исследования не тестировались достаточно долго, чтобы можно было сделать какие-либо однозначные выводы.
Краткое содержание раздела :
- Мониторинг самого факта подключения ИБП к машине совершенно необходим;
- вам необходимо собирать и хранить данные о датах установки аккумуляторов;
- В идеале нужно очень детально отслеживать процесс разрядки и зарядки аккумуляторов.
NUT и сервер мониторинга
Изначально NUT был выбран как кроссплатформенное универсальное решение.В целом свои функции выполняет. Однако были некоторые нюансы: а) Не очень дружелюбная и неочевидная установка на клиентские машины, особенно под Windows. В частности:
- иногда отказывается посещать библиотеки;
- Встроенный драйвер давно не обновлялся и не знает половины ИБП.
Драйвер необходимо устанавливать вручную, и это отдельная тема;
- на Windows-клиентах служба запускается «не в то время», раньше, чем это необходимо (аналогичная история при поиске домена в Windows с некоторыми сетевыми адаптерами).
Из-за этого нам приходится пользоваться костылями.
Это устранит необходимость частого опроса ИБП и позволит более целенаправленно отслеживать важные условия (см.
предыдущий раздел).
Однако мне не удалось добиться стабильной работы этой функции.
Некоторые машины вообще не запускают сервер или делают это один раз из десяти.
В то же время есть машины, у которых это работает надежно.
В качестве альтернативы я попробовал (и даже написал «адаптер») получить данные из WMI, как предлагалось.
Суть, в общем-то, та же.
Плюсы: не нужны альтернативные дайверы и библиотеки, не надо костылить какие-то вещи.
Недостатки: информации гораздо меньше, а по сравнению с настроенным NUT-клиентом стабильность точно такая же, при этом нет, по крайней мере потенциальной, возможности «спуска».
По результатам исследования было принято решение оставить NUT в качестве основного решения для сервера.
При этом «гораздо больше данных» в какой-то момент превратилось в базы данных, раздутые по 100 МБ на каждый UPS, что сказалось на производительности.
В результате сервер был переведен из среды Windows в Linux, и:
- на bash написан соответствующий демон-скрипт для непрерывного опроса;
- Оптимизировано хранение данных: если на входе есть питание и некоторые другие параметры в норме, последняя строка не добавляется в базу, а обновляется.
- отображение заряда аккумулятора сразу после последнего отключения питания и соответствующее оповещение;
- Расчет срока службы батареи на основе реальных данных.
В каком-то смысле это тоже синтетика, потому что.
реальная кривая расхода не строится.
Однако следующая формула работала хорошо: время рассчитано на основе последних реальных данных / 1+ лет с десятыми долями .
Итоги, советы, планы
Для тех, кто хочет «сделать все правильно», исходя из полученного опыта, дам следующий совет:- Тщательно выбирайте марку и модель ИБП и по возможности используйте во всем офисе только выбранный ИБП;
- Запишите серийные номера и/или присвойте уникальный номер каждому ИБП.
Запишите дату установки батареи в каждый ИБП.
Меняйте батарейки каждые два года , и сразу, заранее, включите эти расходы в свои бюджеты – для бизнеса запланированные расходы гораздо удобнее непредвиденных;
- В любом случае следите за тем, чтобы машины, оснащенные ИБП, имели с ним постоянную связь;
- Раз в полгода обновляйте параметры низкого заряда батареи и предупреждения о заряде батареи в используемом вами драйвере/решении, прибавляя к ним от 5% до 20%, в зависимости от опыта использования вашей модели ИБП, вручную или с помощью скриптов;
- Если возможно, выполняйте тестирование ИБП вручную (отключите и подождите) раз в квартал или шесть месяцев.
Использование непрерывного и детального мониторинга в целом является довольно чрезмерным, хотя оно может быть полезным и показательным.
Заводить для этого отдельный сервер или нет – решать вам.
Некоторые параметры можно отслеживать в том же Zabbix (и даже через WMI), однако лично у меня в целом не очень хороший опыт работы с активными параметрами Zabbix; Кроме того, сложность реализации некоторых описанных решений внутри Zabbix приближается, на мой взгляд, к сложности реализации представленного сервера мониторинга.
Я удивлен и рад, что немало читателей задумались о мониторинге ИБП после первой статьи, а многие посоветовали после второй статьи принести решение «на предприятие».
Спасибо за ваши отклики и ответы! Учитывая накопленный опыт, внедрение «на предприятие» может оказаться достаточно длительным.
Есть проблемы как на стороне клиента, так и в самом NUT; в веб-интерфейсе многое нужно переносить на бэкенд, нет даже банальной авторизации.
Можно было бы даже запихнуть все это в таком виде в Docker-контейнер как альфа-версию 0.1, но мой энтузиазм по поводу этой темы несколько угас.
Если у кого-то есть энтузиазм, пишите, буду рад сотрудничеству! Рад, если мой опыт вам пригодится.
Спасибо всем, кто прочитал! Теги: #Сделай сам или Сделай сам #программирование #Системное администрирование #открытый код #Энергия и аккумуляторы #мониторинг #автоматизация #велостроение #автоматизация труда администратора #ИБП #ups #веб-интерфейс #ИБП для офиса #гайка
-
Ассамблеи 2013 Г.
19 Oct, 24