У меня установлен ИБП Proline 650 (серийный)
Дополнительные сведения: ИБП имеет последовательное соединение с одной 12-вольтовой батареей SLA. (Он не был указан в списке совместимости NUT, но после компиляции NUT-сканера было обнаружено, что он работает с драйвером blazer_ser. Кажется, он работает отлично, если я оставлю запущенный ups-monitor, сервер автоматически выключится, когда ИБП работал от батареи в течение 30 секунд или минуты или чего-то еще. ОС: Debian 7 Wheezy. Аппаратное обеспечение - это один маломощный безголовый сервер i5 с 1 3,5-дюймовым жестким диском.
ИБП выключается примерно через 5 минут, пока заявленная емкость батареи все еще составляет 65% (вероятно, это заниженная емкость, потому что я только что установил новую батарею), а напряжение батареи сообщается NUT как 12,1 В непосредственно перед включением. с нагрузки. ИБП выключается примерно через 5 минут независимо от того, опрашивает его сервер или нет, и независимо от того, есть ли небольшая нагрузка или нет. (Я питаю сервер напрямую от сети во время некоторых испытаний, чтобы избежать непредвиденных потерь мощности, когда ИБП выполняет энергосбережение)
Я ожидал, что с NUT, опрашивающим ИБП каждые несколько секунд на предмет обновлений статуса, ИБП поймет, что от него зависит компьютер, но ИБП не умен. ИБП показывает, что сервер потребляет 12% от максимальной выходной мощности, что, по-видимому, считается «без нагрузки». После того, как ИБП отключает нагрузку, напряжение на клеммах батареи (одиночный аккумулятор 12 В) имеет напряжение холостого хода около 12,6 В, что указывает на то, что он все еще почти полностью заряжен.
Это поведение при самостоятельном отключении питания упоминается в документах NUT как energy_saving (аккумулятор. энергосбережение).
Драйвер blazer_ser, похоже, не предлагает способ отключить энергосбережение. Это кажется безумным, потому что нет возможности поддерживать выход нагрузки ИБП включенным. Как можно рекламировать ИБП как обеспечивающий x количество энергии, но преждевременно отключающийся, без простого способа исправить поведение в программном обеспечении?
Это мой вывод статуса
$ upsc nutdev1@127.0.0.1 battery.charge: 100 battery.voltage: 13.60 battery.voltage.high: 13.00 battery.voltage.low: 10.40 battery.voltage.nominal: 12.0 device.type: ups driver.name: blazer_ser driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.version: 2.6.4 driver.version.internal: 1.55 input.current.nominal: 3.0 input.frequency: 50.1 input.frequency.nominal: 50 input.voltage: 221.0 input.voltage.fault: 221.0 input.voltage.nominal: 220 output.voltage: 221.0 ups.beeper.status: enabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 12 ups.status: OL ups.temperature: 25.0 ups.type: offline / line interactive
Я также побежал upsrw -u admin -p mypass -s -l nutdev1
но не было энергосбережения или подобного варианта. Только такие вещи, как beeper.toggle (проверено, работает, как ожидалось) и другие базовые вещи. Был вариант моментального снятия нагрузки. Оно работает. Опция была загружена, я пытался вызвать ее несколько раз, надеясь задержать обратный отсчет энергосбережения, но это не сработало. Также была опция отключения выключения, которая тоже не помогла.
Любые предложения приветствуются. Я подумал о нескольких вещах, которые мне не нравятся:
upscmd -u upsadmin1 -p mypass nutdev1 battery.energysave
Unexpected response from upsd: ERR CMD-NOT-SUPPORTED
Кажется, ДОЛЖНО быть простое программное решение, вот почему я спрашиваю.
================
Согласно предложению BillThor, я обновил свой файл upsmon.conf:
$ grep -v '^#' /etc/nut/upsmon.conf MONITOR nutdev1@127.0.0.1 1 foo2 bar2 master MINSUPPLIES 1 SHUTDOWNCMD "/usr/bin/logger fake shutdown" POLLFREQ 5 POLLFREQALERT 5 HOSTSYNC 15 DEADTIME 15 POWERDOWNFLAG /etc/killpower NOTIFYFLAG ONLINE SYSLOG+WALL NOTIFYFLAG ONBATT SYSLOG+WALL NOTIFYFLAG LOWBATT SYSLOG+WALL NOTIFYFLAG FSD SYSLOG+WALL NOTIFYFLAG COMMOK SYSLOG+WALL NOTIFYFLAG COMMBAD SYSLOG+WALL NOTIFYFLAG SHUTDOWN SYSLOG+WALL NOTIFYFLAG REPLBATT SYSLOG+WALL NOTIFYFLAG NOCOMM SYSLOG+WALL NOTIFYFLAG NOPARENT SYSLOG+WALL RBWARNTIME 43200 NOCOMMWARNTIME 300 FINALDELAY 5
Я включил ИБП (без сетевого питания) 3 раза подряд без зарядки. Емкость аккумулятора и напряжение не изменились. Статус LB никогда не наступал. Вот системные журналы
Dec 2 07:08:00 t upsmon[2000]: Startup successful Dec 2 07:08:00 t upsd[1942]: User monuser1@127.0.0.1 logged into UPS [nutdev1] Dec 2 07:08:30 t upsmon[2002]: UPS nutdev1@127.0.0.1 on battery Dec 2 07:13:34 t blazer_ser[1939]: Communications with UPS lost: status read failed! Dec 2 07:13:36 t upsd[1942]: Data for UPS [nutdev1] is stale - check driver Dec 2 07:13:40 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale Dec 2 07:13:40 t upsmon[2002]: Communications with UPS nutdev1@127.0.0.1 lost Dec 2 07:13:45 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale Dec 2 07:13:50 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale Dec 2 07:13:55 t upsmon[2002]: Poll UPS [nutdev1@127.0.0.1] failed - Data stale Dec 2 07:13:55 t upsd[1942]: Client monuser1@127.0.0.1 set FSD on UPS [nutdev1] Dec 2 07:13:55 t upsmon[2002]: Executing automatic power-fail shutdown Dec 2 07:13:55 t upsmon[2002]: Auto logout and shutdown proceeding Dec 2 07:14:00 t logger: fake shutdown Dec 2 07:17:31 t blazer_ser[1939]: Communications with UPS re-established Dec 2 07:17:31 t upsd[1942]: UPS [nutdev1] data is no longer stale Dec 2 07:22:38 t blazer_ser[1939]: Communications with UPS lost: status read failed! Dec 2 07:22:40 t upsd[1942]: Data for UPS [nutdev1] is stale - check driver Dec 2 07:25:23 t blazer_ser[1939]: Communications with UPS re-established Dec 2 07:25:23 t upsd[1942]: UPS [nutdev1] data is no longer stale Dec 2 07:29:54 t upsd[1942]: Instant command: upsadmin1@127.0.0.1 did shutdown.stop on nutdev1 Dec 2 07:29:55 t blazer_ser[1939]: instcmd: command [shutdown.stop] handled Dec 2 07:30:17 t upsd[1942]: Instant command: upsadmin1@127.0.0.1 did shutdown.stop on nutdev1 Dec 2 07:30:18 t blazer_ser[1939]: instcmd: command [shutdown.stop] handled Dec 2 07:30:25 t upsd[1942]: Instant command: upsadmin1@127.0.0.1 did shutdown.stop on nutdev1 Dec 2 07:30:26 t blazer_ser[1939]: instcmd: command [shutdown.stop] handled Dec 2 07:30:31 t blazer_ser[1939]: Communications with UPS lost: status read failed! Dec 2 07:30:33 t upsd[1942]: Data for UPS [nutdev1] is stale - check driver Dec 2 07:31:32 t blazer_ser[1939]: Communications with UPS re-established Dec 2 07:31:32 t upsd[1942]: UPS [nutdev1] data is no longer stale
Как видите, я попытался сбросить флаг / состояние FSD, выполнив эту команду (та же команда, которая может мгновенно отключить нагрузку или включить звуковой сигнал) upscmd -u upsadmin1 -p mypass nutdev1 shutdown.stop
Но это не прояснило состояние FSD.
Вот некоторая информация о статусе (я удалил ненужные строки)
#I ran this immediately after unplugging line power after 07:08:30 $ upsc nutdev1@127.0.0.1 battery.charge: 69 battery.voltage: 12.20 ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.status: OB **$ date && upsc nutdev1@127.0.0.1** Tue Dec 2 07:11:29 EST 2014 battery.charge: 65 battery.voltage: 12.10 ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.status: OB #none of these fields changed the entire time after this, except ups.status **date && upsc nutdev1@127.0.0.1** Tue Dec 2 07:12:29 EST 2014 battery.charge: 65 battery.voltage: 12.10 ups.status: OB $ date && upsc nutdev1@127.0.0.1 Tue Dec 2 07:18:26 EST 2014 battery.charge: 65 battery.voltage: 12.10 ups.status: FSD OB ups.temperature: 25.0 #there were a few more, all identical, then finally **$ date && upsc nutdev1@127.0.0.1** Tue Dec 2 07:30:28 EST 2014 battery.charge: 65 battery.voltage: 12.10 ups.status: FSD OB $ date && upsc nutdev1@127.0.0.1 Tue Dec 2 07:31:11 EST 2014 Error: Data stale
Это мгновенные команды, предположительно поддерживаемые моим ИБП.
**upscmd -u upsadmin1 -p mypass -l nutdev1** Instant commands supported on UPS [nutdev1]: beeper.toggle - Toggle the UPS beeper **works** load.off - Turn off the load immediately **works** load.on - Turn on the load immediately **seems to do nothing** shutdown.return - Turn off the load and return when power is back shutdown.stayoff - Turn off the load and remain off shutdown.stop - Stop a shutdown in progress **doesn't prevent shutdown or remove FSD flag** test.battery.start - Start a battery test test.battery.start.deep - Start a deep battery test test.battery.start.quick - Start a quick battery test test.battery.stop - Stop the battery test
Теперь я испробовал еще больше возможностей. Я попробовал запустить test.battery.start.quick, чтобы немного перекалибровать батарею, при нагрузке 35%. Он проработал минуту или две от батареи, затем снова переключился на питание от сети. Затем у меня возникли еще две идеи. Я попытался отключить звуковой сигнал, надеясь, что ИБП останется включенным, но он отключился, как обычно, через 5 минут. Потом у меня появилась другая идея. Я вытащил шнур питания, затем запустил test.battery.start, надеясь, что смогу проводить «тест батареи» на неопределенный срок. Но ИБП ВСЕ ЕЩЕ выключился через 5 минут.
В основном этот ИБП хорош для выключения, и не более того. Я куплю еще один ИБП.
Многие ИБП имеют автоматическое отключение при низкой нагрузке. Если нагрузка составляет менее 10% от номинальной нагрузки ИБП, он отключится через 5 минут. У меня такая же проблема с моим ИБП Proline. Просто увеличьте нагрузку на ИБП, и он не отключится. Я знаю, что это немного противоречит интуиции, если вы пытаетесь сэкономить заряд батареи.
Мне не удалось найти программную настройку для отключения этой функции. Вроде его жестко закодировали в прошивку.
Я установил интеллектуальный переключатель sonoff на стороне нагрузки и запрограммировал его на включение 10% нагрузки на 10 секунд каждые 4 минуты. Это не элегантно, но поддерживает работу.
Если вы не используете команды в upssched.conf
, NUT должен дождаться, пока ИБП не сообщит о низком заряде батареи, прежде чем выполнять выключение. Убедитесь, что у вас там ничего не запланировано.
Как только NUT начинает отключение, он запускает перезапуск ИБП после тайм-аута. Это необходимо для обеспечения возобновления работы сервера в случае восстановления питания до того, как батарея ИБП разрядится. Время указано как FINALDELAY
в upsmon.conf
.
Вы можете включить регистрацию всех уведомлений для всех событий в upsmon.conf
. Это может позволить вам определить, почему система так скоро отключается. Я использую следующие настройки:
NOTIFYFLAG ONBATT SYSLOG+WALL
NOTIFYFLAG ONLINE SYSLOG+WALL
NOTIFYFLAG FSD SYSLOG+WALL
NOTIFYFLAG SHUTDOWN SYSLOG+WALL
NOTIFYFLAG LOWBATT SYSLOG
NOTIFYFLAG REPLBATT SYSLOG
NOTIFYFLAG COMMOK SYSLOG
NOTIFYFLAG COMMBAD SYSLOG+WALL
NOTIFYFLAG NOCOMM SYSLOG+WALL
NOTIFYFLAG NOPARENT SYSLOG+WALL
Если NUT отключает базы по сценарию таймера, я ожидал увидеть именно такую строку в журнале. Похоже, что ИБП прекращает обмен данными через 5 минут, а NUT выполняет последнюю остановку FSD (принудительное отключение). Это то, что я хотел бы сделать. Пяти минут должно хватить, чтобы указать, что электричество не вернется быстро.
Dec 2 07:13:55 t upsd[1942]: Client monuser1@127.0.0.1 set FSD on UPS [nutdev1]
Я ожидал, что NUT будет использовать shutdown.return
для подачи сигнала о выключении ИБП. Это должно вызвать перезапуск ИБП после восстановления питания и кратковременное отключение, если питание будет восстановлено до завершения выключения.
Я ожидал ups.delay.shutdown
и ups.delay.start
быть настройками для цикла перезапуска при выключении ИБП. ups.delay.shutdown
должен дать серверу время для завершения цикла выключения и, возможно, потребуется увеличить. ups.delay.start
должно быть время, необходимое для стабилизации питания после его восстановления. Это также дает некоторое время для зарядки аккумуляторов перед включением нагрузки.
Обычно вы не хотите разряжать батареи до низкого уровня перед выключением. Вы хотите, чтобы у батареи было достаточно заряда, чтобы пройти еще один или два цикла на случай, если мощность снова упадет.