Служба ибп windows server

Всем известно, что для защиты от сбоев электропитания нужно купить бесперебойник. Но сам по себе источник бесперебойного питания не решает проблему, а только отсрочивает негативные последствия. Действительно, если питание пропадет надолго, то после разрядки батарей ИБП ваши системы аварийно завершат работу. Избежать этого позволяют модели, имеющие обратную связь, но, чтобы использовать эти возможности нам потребуется система управления электропитанием и сегодня мы расскажем об открытом и бесплатном продукте — NUT (Network UPS Tools).

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Почему именно NUT? Ведь многие производители ИБП предлагают собственные утилиты, в т.ч. и под Linux, при этом они явно лучше знают свою продукцию. В теории это так, но практика вовсе не так радужна. Во-первых, качество «родного» ПО очень сильно отличается от вендора к вендору. Где-то это вполне неплохие решения, а где-то лютая мешанина скриптов, бинарников и устаревших технологий.

Кроме того, ИБП у вас может быть не один, причем разных производителей и устраивать зоопарк проприетарного ПО — не самый лучший вариант. Что касается второго аргумента, то существует UPS management protocol — RFC 9271, если бесперебойник его поддерживает, то все равно какое ПО мы будем использовать для работы с ним.

NUT — это открытое программное обеспечение, поддерживающее большое количество источников бесперебойного питания и предоставляющее единый интерфейс работы с ними, кроме того оно работает в клиент-серверном режиме что позволяет организовать сетевое управление электропитанием, это удобно, когда к одному бесперебойнику подключено несколько компьютеров. С полным списком поддерживаемых устройств вы можете ознакомиться на официальном сайте: https://networkupstools.org/stable-hcl.html

Структурно NUT состоит из трех основных частей:

• Драйвер — используется для связи с ИБП.
• Сервер (upsd) — при помощи драйвера связывается с ИБП и получает сообщения об его состоянии.
• Служба мониторинга (upsmon) — контролирует сервер и выполняет действия на основе полученной от сервера информации.

Важный момент! Сервер NUT никак не связывается с клиентами и не передает им никаких команд, все решения принимает клиент, который при помощи службы мониторинга получает с сервера состояние выбранного ИБП и сообщения от него, на основании которых затем предпринимаются некоторые действия.

Таким образом один сервер NUT может контролировать сразу несколько физически подключенных к нему через интерфейс обратной связи ИБП и предоставлять информацию об их состоянии клиентам через локальную сеть. Это позволяет реализовывать достаточно сложные схемы управления электропитанием, наподобие приведенной ниже:

Картинка с сайта: interface31.ru

Таким образом имея единственный сервер NUT мы получаем централизованную систему управления питанием, которая обеспечит корректное выключение всех подключенных к ИБП компьютеров, а затем самого ИБП. При возобновлении электропитания сначала включатся ИБП, а затем все подключенные к ним устройства (для этого они должны иметь соответствующие настройки в BIOS).

Установка NUT и настройка драйвера ИБП

Установка NUT проста, в Debian / Ubuntu существует одноименный метапакет, который устанавливает сразу и сервер, и клиент. В других системах обратитесь к документации по доступным пакетам.

apt install nut

Теперь подключим к серверу ИБП и перезагрузим систему, после чего попробуем автоматически определить его настройки при помощи служебного пакета nut-scanner:

nut-scanner

Утилита просканирует все доступные интерфейсы и выведет готовые параметры подключения для обнаруженных устройств, в нашем случае был найдет ИБП серии PowerCom Smart King Pro+ подключенный через USB.

Картинка с сайта: interface31.ru

Фактически это готовые опции для настройки драйвера, советуем сохранить их для использования в дальнейшем. Теперь откроем файл /etc/nut/ups.conf и в самый конец добавим секцию, аналогичную указанной выше. В квадратных скобках указываем желаемое имя, ниже следуют опции подключения. В минимальной конфигурации будет достаточно первых двух: driver и port. Если предполагается использовать несколько ИБП, то мы можем уточнить производителя и модель: vendorid и productid, а вот опцию bus — лучше не использовать, при переключении ИБП в другой разъем она изменится. В случае использования нескольких ИБП одной модели лучше использовать другую опцию — serial с указанием серийного номера устройства.

Также мы советуем изучить документацию производителя, многие из них указывают рекомендуемые конфигурации драйвера для работы с NUT, например, для PowerCom у нас вышло следующее:

[powercom1]
    driver = usbhid-ups
    port = auto
    vendorid = 0d9f
    productid = 0004
    serial = AAA-BBBB-CCC
    pollonly

Последняя опция как раз взята из рекомендаций производителя, без нее ИБП работал с NUT нестабильно, периодически отваливаясь, что требовало либо его переподключения, либо перезагрузки компьютера.

Теперь проверим работу драйвера:

upsdrvctl start

Если все сделано правильно, то вы увидите что-то подобное:

Картинка с сайта: interface31.ru

Как видим, драйвер запустился нормально и увидел наш ИБП, теперь остановим его, чтобы избежать конфликтов при дальнейшей настройке.

upsdrvctl stop

Если же драйвер запускается с ошибками попробуйте переключить ИБП в другой разъем или перезагрузить компьютер.

Настройка сервера NUT

Прежде всего откроем /etc/nut/nut.conf и установим режим работы:

MODE=netserver

Для сервера доступны режимы:

• standalone — сервер запущен локально и принимает соединения только на localhost, используется для управления локально подключенным ИБП, который не питает других ПК,
• netserver — сетевой режим, сервер принимает соединения по локальной сети, подходит для построения сетевой системы управления питанием.

Мы сразу будем настраивать сетевой режим, большинство настроек при этом не будут отличаться от локальных, поэтому вы также можете настроить и локальный режим по этой инструкции.

Теперь перейдем в /etc/nut/upsd.conf, в нем нам потребуется указать сетевые опции, а именно адрес и порт, на котором будет принимать подключения сервер:

LISTEN 127.0.0.1 3493
LISTEN 192.168.99.120 3493

Обратите внимание на регистр написания, название опции должно быть обязательно в верхнем регистре, для локального режима достаточно будет только указания первой строки.

Следующим шагом заведем пользователей в файле /etc/nut/upsd.users. Мы рекомендуем, как минимум, завести административного пользователя, который будет иметь права менять настройки UPS и пользователей для чтения данных состояния бесперебойника. Вы можете завести разные учетные данные для разных ПК или одну на всех — выбор остается за вами. В нашем случае содержимое файла выглядит так:

[upsadmin]
    password = Pa$$word_1
    actions = SET
    instcmds = ALL[upsmon-m]
    password = 123456789
    upsmon master[upsmon-s]
    password = 987654321
    upsmon slave

В нашем случае мы завели трех пользователей: административного, пользователя локального клиента (master) и удаленных клиентов (slave).

Сохраним все изменения и попробуем запустить службу сервера и сразу проконтролируем ее статус:

systemctl start nut-server
systemctl status nut-server

Картинка с сайта: interface31.ru

Теперь можем получить данные о состоянии ИБП командой:

upsc powercom1@localhost

Где мы указываем имя нашего драйвера и имя или адрес узла, на котором запущена серверная часть NUT.

В выводе мы можем увидеть частоту и напряжение на входе и на выходе устройства, текущую нагрузку в процентах (ups.load) и статус бесперебойника, который может иметь следующие значения:

• OL — On Line — работа от сети
• OB — On Battery — работа от батареи
• LB — Low Battery — низкий заряд батареи

Как мы уже говорили, сам сервер не предпринимает никаких действий, а только получает данные от ИБП и предоставляет их клиентам, но именно состояние LB служит триггером для службы мониторинга инициирующим выключение устройств.

Настройка службы мониторинга в Linux

Начнем с локального сервера, клиентская часть здесь уже установлена, поэтому просто откроем файл /etc/nut/upsmon.conf и добавим в него строку:

MONITOR powercom1@localhost 1 upsmon-m 123456789 master

Разберем указанные опции: powercom1@localhost — указывают имя драйвера и сервер NUT, следующая за ними единица говорит о том, что питание устройства следует отключить, для отладки можно временно указать там ноль, в этом случае будут генерироваться все события и записи в логах, но отключение питания производиться не будет. Затем указываем имя пользователя и пароль, а также тип устройства — master, это говорит о том, что перед нами головное устройство и оно будет выключено только после того, как выключатся все подчиненные компьютеры.

Запустим службу мониторинга:

systemctl start nut-monitor

Остальные параметры можно оставить по умолчанию. Но следует обратить внимание на опции NOTIFYFLAG, которые описывают реакцию службы на те или иные события. По умолчанию, когда опция закомментирована, применяются действия SYSLOG и WALL, т.е. пишется событие в системный лог и отправляется сообщение всем залогиненым пользователям.

Дополнительно можно включить выполнение скрипта действием EXEC, сам скрипт общий для всех событий и указывается в опции NOTIFYCMD, само событие и реакцию на него следует определять в самом скрипте, но это уже выходит за рамки данной статьи, поэтому рекомендуем обратиться к документации.

На удаленных устройствах нам нет необходимости устанавливать все пакеты, достаточно только клиентского:

apt install nut-client

После чего откроем /etc/nut/nut.conf и укажем режим работы:

MODE=netclient

Затем в /etc/nut/upsmon.conf внесем строку:

MONITOR powercom1@192.168.99.120 1 upsmon-s 987654321 slave

Мы не будем подробно разбирать синтаксис, так как это сделали выше, отметим изменения. При указании драйвера и узла мы использовали IP-адрес сервера NUT (можно также его FQDN), а в конце строки указали slave, что обозначает подчиненный мониторинг, кроме состояния ИБП он отслеживает также команды от головного мониторинга (master). Понятно, что в качестве драйвера следует указывать именно тот ИБП, к которому физически подключен данный узел.

После чего точно также запускаем службу:

systemctl start nut-monitor

Для проверки получим сведения об ИБП:

upsc powercom1@192.168.99.120

Для просмотра подключенных клиентов выполните команду:

upsc -с powercom1@192.168.99.120

Картинка с сайта: interface31.ru

А теперь как это все работает, мы не будем углубляться в подробности, а представим максимально упрощенную схему, достаточную для понимания происходящих событий.

• Батареи ИБП разряжаются, и он переходит в состояние LB
• Мониторинг master-узла получает этот статус и выставляет флаг FSD (forced shutdown)
• Мониторинг slave-узлов видит этот флаг и инициирует выключение
• Master-узел ждет отключения подчиненных узлов и выставляет флаг POWERDOWNFLAG
• При необходимости master завершает свою работу и выключает ИБП

Последний момент очень важен, потому что если после того, как slave-узлы будут выключены, подача питания возобновится, то ИБП не выключится и повторного запуска подключенных устройств не произойдет. Поэтому master узел в обязательном порядке выключает ИБП, чтобы при его последующем включении произошел запуск всех подключенных к нему устройств.

Настройка службы мониторинга в Windows

Сервер NUT может управлять и Windows-клиентами, для этого нужно установить один из клиентов NUT, мы используем WinNUT-Client, он поставляется в виде MSI-пакета и проблем с его установкой возникнуть не должно. Настройки его также просты: указываем адрес и порт сервера, имя драйвера, логин и пароль.

Картинка с сайта: interface31.ru

Также советуем пробежаться по прочим вкладкам и настроить автозапуск приложения и выполнить, при желании, более тонкую подстройку. Кроме выполнения своей основной функции приложение также показывает основные параметры ИБП в виде графических индикаторов.

Картинка с сайта: interface31.ru

Как видим, настроить NUT просто, но данная статья и близко не затронула всех возможностей этой системы. Пока что мы организовали базовую систему централизованного управления электропитанием, но при желании ее можно бесконечно улучшать и дополнять, благо проект прекрасно документирован.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

windows:server:2022:apcupsd

Содержание

Случилось страшное! – старенький IPPON Smart Winner 3000 потерял связь с реальностью сервером по USB…

Не знаю пока, насколько страшная это беда, в ремонт его пока не отвозили, а просто, учитывая его солидный возраст и грядущую массовую замену АКБ¹⁾, заказали новый ИБП Ippon Innova RT II 3000, но последний соизволил задержаться в доставке на несколько месяцев… Т.е. все это время стойка находится под постоянной угрозой – сам ИБП вроде, и работает, и нагрузку какое-то более-менее приличное время держит, но серверам ничего не рассказывает и, в случае чего, они рискуют просто вырубиться в момент!

В связи с недопустимостью такого развития событий, придумалась простая, но рабочая схема – к одному из серверов был подключен по USB простенький APC Back-UPS CS практически без нагрузки²⁾…

Далее планировалось на этот сервер воткнуть PowerChute Personal Edition³⁾ или, если что-то пойдет не так, какой-то альтернативный софт… и естественно, что-то пошло нет так – Personal Edition не устанавливается на сервера, и этим «альтернативным софтом», после долгих мытарств и тестов, был выбран Apcupsd.

Конфигурация

И правильно, что он – настройка там простая и незатейливая при всем необходимом функционале.

Ведущий

После загрузки⁴⁾ и установки приложения на «главном» сервере, куда подключен ИБП, нужно заменить драйвер «American Power Conversion USB ИБП» в разделе «Устройства HID (Human Interface Devices)» на «American Power Conversion USB UPS (Apcupsd)»⁵⁾, после чего он переместится в раздел «Батареи» вместо присутствующего там по умолчанию устройства «Батарея ИБП HID».

Конфигурация примерно такая:

apcupsd.conf

# General
#UPSNAME
UPSCABLE usb
UPSTYPE usb
DEVICE
#POLLTIME 60
SCRIPTDIR c:\apcupsd\etc\apcupsd
PWRFAILDIR c:\apcupsd\etc\apcupsd
NOLOGINDIR c:\apcupsd\etc\apcupsd
 
# Failures
ONBATTERYDELAY 6
BATTERYLEVEL 70
MINUTES 5
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60
NOLOGON disable
KILLDELAY 0
 
# NIS
NETSERVER on
NISIP 0.0.0.0
NISPORT 3551
EVENTSFILE c:\apcupsd\etc\apcupsd\apcupsd.events
EVENTSFILEMAX 10
 
# Sharing
UPSCLASS standalone
UPSMODE disable
 
# Logging
STATTIME 0
STATFILE c:\apcupsd\etc\apcupsd\apcupsd.status
LOGSTATS off
DATATIME 0
#FACILITY DAEMON
 
# UPS EPROM
#UPSNAME UPS_IDEN
#BATTDATE mm/dd/yy
#SENSITIVITY H
#WAKEUP 60
#SLEEP 180
#LOTRANSFER  208
#HITRANSFER 253
#RETURNCHARGE 15
#BEEPSTATE T
#LOWBATT 2
#OUTPUTVOLTS 230
#SELFTEST 336

Значимые переменные, которые необходимо проверить и при необходимости изменить:

• UPSCABLE

• UPSTYPE

• DEVICE

• POLLTIME

• BATTERYLEVEL

• MINUTES

• NETSERVER

• NISIP

• NISPORT

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

Ведомые

На ведомых серверах конфигурация должна быть изменена так⁶⁾:

UPSCABLE ether
UPSTYPE net
DEVICE master-dvs.local:3551
POLLTIME 10
BATTERYLEVEL 80
MINUTES 6

Директива «NETSERVER» должна тоже быть в положении «on»!

Расписания

Для минимизации казусов, я выбрал такие значения директив «BATTERYLEVEL» и «MINUTES»:

Role	BATTERYLEVEL	MINUTES
Primary7)	90	7
Slaves	80	6
Master9)	70	5

Т.к. в этой модели ведомые опрашивают ведущего, а не ведущий уведомляет ведомых, для корректной последовательности выключения важно, чтобы ведущий выключался последним, иначе, при потере связи с ведущим, ведомые сразу выключатся не взирая на «расписание»!

Уведомления

Для отправки уведомлений на почту, в комплекте присутствуют несколько простых скриптов, внутри, по сути, практически идентичных:

• commfailure.vbs.example

• offbattery.vbs.example

• onbattery.vbs.example

Для активации, их нужно отредактировать, добавив правильные настройки почты, и переименовать, убрав «.example» из имени файла.

При необходимости можно повесить уведомления на другие события, скопировав скрипт «commfailure.vbs», отредактировав и переименовав его в одно из этих значений:

• commfailure

• commok

• powerout

• onbattery

• offbattery

• mainsback

• failing

• timeout

• loadlimit

• runlimit

• doshutdown

• annoyme

• emergency

• changeme

• remotedown

• startselftest

• endselftest

• battdetach

• battattach

---

Дисклеймер

• Использование материалов данной базы знаний разрешено на условиях лицензии, указанной внизу каждой страницы! При использовании материалов активная гиперссылка на соответствующую страницу данной базы знаний обязательна!

• Автор не несет и не может нести какую либо ответственность за последствия использования материалов, размещенных в данной базе знаний. Все материалы предоставляются по принципу «как есть». Используйте их исключительно на свой страх и риск.

• Все высказывания, мысли или идеи автора, размещенные в материалах данной базе знаний, являются исключительно его личным субъективным мнением и могут не совпадать с мнением читателей!

• При размещении ссылок в данной базе знаний на интернет-страницы третьих лиц автор не несет ответственности за их техническую функциональность (особенно отсутствие вирусов) и содержание! При обнаружении таких ссылок, можно и желательно сообщить о них в комментариях к соответствующей статье.

В этой заметке мы рассмотрим пример настройки свободного программного обеспечения Network UPS Tools (NUT) для контролируемого выключения сервера виртуализации Hyper-V на базе ОС Windows Server 2022. В рассматриваемом примере NUT будет использоваться в связке с двумя ИБП APC Smart-UPS SURT6000XLI, в которые установлены ранее рассмотренные платы Инматикс ПСУ Спутник А21. То есть в нашем случае к двум блокам питания хоста виртуализации подключены два разных ИБП, а ПО NUT, установленное на хост, будет контролировать состояние обоих ИБП и в случае проблем с электропитанием на ИБП инициировать команду завершения работы виртуальных машин хоста и штатного выключения хостовой ОС.

Основную информацию о NUT можно найти на сайте проекта, где в разделе документации можно найти ссылку на полезный для нас документ «NUT Configuration Examples». Кроме того, не лишним будет ознакомление с документом на русском языке, опубликованном на сайте Инматикс «Завершение работы серверов и ПК» с примерами установки и настройки NUT в простых конфигурациях на ОС Linux Debian и Windows.

Инсталляционные сборки NUT существуют под множество разных операционных сред. Найти интересующий нас пакет под ОС Windows можно на сайте в разделе «Binary packages». Имеющийся на данный момент времени пакет NUT-Installer-2.6.5-6.msi является инсталлятором «не первой свежести», но он без нареканий устанавливается на ОС Windows Server 2022.

В ходе установки инсталлятор просит принять лицензионное соглашение GPLv2 и предлагает указать каталог установки (по умолчанию на 64-битной версии Windows Server устанавливается в каталог «C:\Program Files (x86)»). Чтобы в перспективе избежать потенциальных проблем NUT с путями, содержащими пробелы и спецсимволы, изменим каталог установки на «C:\», в результате чего установка будет выполнена в каталог «C:\NUT».

Картинка с сайта: blog.it-kb.ru

На этапе запроса об установке драйвера libUSB можем отключить опцию, так как в нашем случае подключение к ИБП будет выполняться не через USB, а по сети через драйвер snmp-ups, который входит в базовую поставку инсталлятора NUT под Windows.

Картинка с сайта: blog.it-kb.ru

По окончании процесса установки в системе появится служба «Network UPS Tools» с автоматическим типом запуска, но она будет остановлена.

Картинка с сайта: blog.it-kb.ru

Чтобы избежать некоторых ошибок запуска исполняемых файлов, входящих в состав NUT, нам потребуется докинуть несколько библиотек, необходимых для поддержки шифрования, которое, в частности, будет использоваться при работе с протоколом SNMPv3.

Найти эти библиотеки можно в подкаталоге «\Network UPS Tools\windows\libs» архива, который можно загрузить с сайта Инматикс по ссылке Network-UPS-Tools.zip.

Скопируем файлы библиотек по следующим путям:

1) libeay32.dll, msvcr120.dll, ssleay32.dll в каталог «C:\NUT\bin«;
2) libeay32.dll, msvcr120.dll, ssleay32.dll, libgcc_s_dw2-1.dll, libssl32.dll в каталог «C:\NUT\sbin«

Следующим шагом перед запуском службы «Network UPS Tools» будет настройка конфигурационных файлов NUT.

Настройка конфигурационных файлов NUT

Архитектурно в составе NUT можно выделить 3 базовые компоненты:

1) Компонента драйвера (driver), которая отвечает за связь с ИБП и управляется через файл ups.conf;

2) Серверная компонента (upsd), использующая драйвер для сообщений о состоянии ИБП, которая управляется через файл upsd.conf;

3) Компонента мониторинга (upsmon), которая контролирует сервер upsd и выполняет командные действия, такие как, например, выключение ОС. Управляется через файл upsmon.conf.

Приведу наглядный пример взаимодействия компонент NUT для хоста с несколькими блоками питания из документа «NUT Configuration Examples»:

Картинка с сайта: blog.it-kb.ru

Правим конфигурационные файлы в подкаталоге «etc» каталога установки NUT. В нашем случае это «C:\NUT\etc«.

В первую очередь отредактируем файл nut.conf.sample, указав режим работы NUT, сохраним и переименуем файл в nut.conf.

MODE=standalone

NUT может работать в режимах сервера (управляет выключением других устройств в сети), клиента (принимает команды от сервера NUT в сети), изолированном (все компоненты в рамках одного хоста). Справку по этому конфигурационному файлу можно получить в закомментированных строках nut.conf.sample, либо найти в файле \docs\man\nut.conf.html каталога установки NUT.

Настроим конфигурацию драйверов NUT. Для этого отредактируем файл ups.conf.sample и переименуем его в ups.conf. Справку по этому конфигурационному файлу можно получить в закомментированных строках ups.conf.sample, либо найти в файле \docs\man\ups.conf.html каталога установки NUT.

Есть разные варианты настройки драйвера и они зависят от типа подключения компьютера с NUT к ИБП и от модели ИБП. Перечень совместимых моделей ИБП и рекомендуемые параметры конфигурации для них можно найти в «Hardware compatibility list».

В нашем случае NUT будет подключаться к ИБП не напрямую через USB, а по сети по протоколу SNMP. Поэтому нам потребуется настроить драйвер snmp-ups. Простой пример настройки подключения к ИБП по протоколу SNMPv1:

[MYUPS-001]
driver = snmp-ups
port = my-ups-001.example.com
snmp_version = v1
community = public
pollfreq = 10
desc = "APC Smart-UPS 6000"

В нашем случае к компьютеру с NUT подключены 2 ИБП, доступ к которым мы сконфигурируем по протоколу SNMPv3. Результирующий файл ups.conf (без учёта комментариев):

[KOM-UP001]
driver = snmp-ups
mibs = ietf
port = kom-up001.holding.com
snmp_version = v3
secLevel = authPriv
secName = nut-user
authProtocol = SHA
authPassword = zN3s8fU!sO1sbPMsF
privProtocol = DES
privPassword = H5iXoLe5x4ZY52w-d
pollfreq = 10
desc = "APC Smart-UPS SURT6000XLI with NMC Sputnik"

[KOM-UP002]
driver = snmp-ups
mibs = ietf
port = kom-up002.holding.com
snmp_version = v3
secLevel = authPriv
secName = nut-user
authProtocol = SHA
authPassword = fR!sO1sbPMsFzN3s8
privProtocol = DES
privPassword = Le5x4ZYv2w-dH5iXo
pollfreq = 10
desc = "APC Smart-UPS SURT6000XLI with NMC Sputnik"

Использовать AES в качестве протокола аутентификации не получится, так как NUT не сможет подключиться к ПСУ Спутник в этом случае. По заверениям тех.поддержки Инматикс проблема здесь в NUT, так как с другими программами ПСУ Спутник успешно аутентифицирует AES. Поэтому в данном случае используем DES. Пример настройки SNMPv3 на стороне платы управления ИБП ПСУ Спутник:

Картинка с сайта: blog.it-kb.ru

При задании паролей для пользователя SNMPv3 лучше не злоупотреблять спец.символами, так как это может создать проблемы в работе NUT. Например, использование знака «#» точно вызывает ошибку загрузки драйвера snmp-ups в NUT, при том, что, например, символы «!» и «-» проблем не создадут.

Следующим шагом настроим серверную компоненту upsd таким образом, чтобы upsd не был доступен по сети и прослушивал только локальный порт 3493, переименовав файл upsd.conf.sample в upsd.conf и раскомментировав в нём строку:

LISTEN 127.0.0.1 3493

Далее настроим конфигурационный файл с пользователями, которые будут иметь доступ к серверу upsd, переименовав файл upsd.users.sample в upsd.users. Внесём в файл секцию с описанием пользователя, например, с именем «upsmon-user«:

[upsmon-user]
password = sImplePZsw0rd
upsmon master

Затем настроим конфигурационный файл компоненты мониторинга upsmon. Для этого переименуем файл upsmon.conf.sample в файл upsmon.conf и добавим/отредактируем/раскомментируем в нём следующие строки (прочие открытые строки следует закомментировать):

MONITOR KOM-UP001@localhost 1 upsmon-user sImplePZsw0rd master
MONITOR KOM-UP002@localhost 1 upsmon-user sImplePZsw0rd master
MINSUPPLIES 1
SHUTDOWNCMD "C:\\WINDOWS\\system32\\shutdown.exe -s -t 0"
NOTIFYCMD "C:\\NUT\\sbin\\upssched.exe"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG "C:\\NUT\\killpower"
NOTIFYMSG ONLINE    "UPS %s on line power"
NOTIFYMSG ONBATT    "UPS %s on battery"
NOTIFYMSG LOWBATT   "UPS %s battery is low"
NOTIFYMSG FSD       "UPS %s: forced shutdown in progress"
NOTIFYMSG COMMOK    "Communications with UPS %s established"
NOTIFYMSG COMMBAD   "Communications with UPS %s lost"
NOTIFYMSG SHUTDOWN  "Auto logout and shutdown proceeding"
NOTIFYMSG REPLBATT  "UPS %s battery needs to be replaced"
NOTIFYMSG NOCOMM    "UPS %s is unavailable"
NOTIFYMSG NOPARENT  "upsmon parent process died - shutdown impossible"
NOTIFYFLAG ONLINE   SYSLOG+EXEC
NOTIFYFLAG ONBATT   SYSLOG+EXEC
NOTIFYFLAG LOWBATT  SYSLOG+EXEC
NOTIFYFLAG FSD  SYSLOG
NOTIFYFLAG COMMOK   SYSLOG
NOTIFYFLAG COMMBAD  SYSLOG
NOTIFYFLAG SHUTDOWN SYSLOG
NOTIFYFLAG REPLBATT SYSLOG
NOTIFYFLAG NOCOMM   SYSLOG
NOTIFYFLAG NOPARENT SYSLOG
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

Первые две строки определяют подключение компоненты мониторинга к драйверам, описанным нами в ups.conf с учётной записью, описанной нами в upsd.users. Третья строка с параметром MINSUPPLIES определяет минимально допустимое количество источников питания в состоянии ONLINE. На сервере с двумя блоками питания, подключенным к двум разным ИБП, логично определить значение этого параметра в 1. На сервере с 4 блоками питания, подключенными к разным источникам питания, это значение может быть, например, 2 или 3. Важным здесь также являются параметры NOTIFYFLAG. Обратите внимание на то, что для большинства разных состояний источников питания у нас определено лишь логирование (SYSLOG). И только для трёх состояний (ONLINE, ONBATT, LOWBATT) мы включаем логирование и запуск команды (SYSLOG+EXEC). Под командой здесь подразумевается исполняемый файл планировщика upssched.exe, ссылка на который описана в параметре NOTIFYCMD.

Чтобы лучше понять все описанные параметры, рекомендуется ознакомиться со справкой по этому конфигурационному файлу, которую можно получить в закомментированных строках исходного файла upsmon.conf.sample, либо найти в файле \docs\man\upsmon.conf.html каталога установки NUT.

Настроим конфигурационный файл вспомогательного планировщика upssched, который вызывается в NOTIFYCMD конфигурации компоненты upsmon. Для этого переименуем файл upssched.conf.sample в файл upssched.conf и внесём в него следующие строки (прочие открытые строки следует закомментировать):

CMDSCRIPT "PowerShell.exe -NoProfile -Command C:\\NUT\\sbin\\upssched-script.ps1"
PIPEFN "\"C:\\NUT\\upssched.pipe\""
LOCKFN "\"C:\\NUT\\upssched.lock\""
AT LOWBATT * EXECUTE ups-on-battery
AT ONBATT * START-TIMER ups-on-battery 3600
AT ONLINE * CANCEL-TIMER ups-on-battery

Данная конфигурация предполагает то, что после того, как любой из ИБП переходит в состояние работы от батарей (ONBATT) запускается таймер, ожидающий 1 час (3600 секунд). Это время может корректироваться в зависимости от возможностей ваших ИБП по времени автономной работы от батарей при пропадании входного напряжения. Если в течение указанного периода времени входное напряжение на ИБП вернётся и он перейдёт с батарей на питание от сети (возврат в статус ONLINE), то обратный отсчёт времени таймера будет прерван. Если обратный отсчёт времени таймера доработает до конца, то произойдёт вызов скрипта завершения работы (CMDSCRIPT) с передачей ему параметра «ups-on-battery». При этом, в любой из ситуаций, если с ИБП будет получен статус об исчерпании заряда батарей (LOWBATT), то будет выполнен вызов скрипта завершения работы (CMDSCRIPT) с передачей ему параметра «ups-on-battery».

Теперь в каталоге  установки NUT в подкаталоге «sbin» создадим файл PowerShell скрипта, который будет дёргаться планировщиком upssched и выполнять завершение работы виртуальных машин Hyper-V и ОС самого хоста виртуализации, записывая при этом свои действия в event-лог хоста. Пример содержимого файла скрипта upssched-script.ps1:

<#
  .SYNOPSIS
  Helper script for the upssched.exe process from Network UPS Tools (NUT) for Windows.
  The script can be placed in the sbin subdirectory of the NUT installation directory.
  Don't forget to change the $NUTdir variable.

  .DESCRIPTION
  The upssched-script.ps1 script is called by the upssched.exe process.
  The script uses the value of the MINPOWERSUPPLY variable from upsmon.conf file. 
  To obtain the status of the UPS connected to the system, the script calls the upsc.exe utility.
  If the value of the MINPOWERSUPPLY variable is less than the number of UPSs in the 'OL' status, the script begins the system shutdown procedure. 
  When the $vmsshutdown variable is enabled before shutting down the system, a forced shutdown of all Hyper-V virtual machines is performed
  
  The script was tested on Windows Server 2022 with PowerShell 5.1 and Network UPS Tools for Windows 2.6.5

  .PARAMETER State
  Specifies a marker for the current state of the UPS based on data from the upsmon process.  
  Valid values: ups-on-battery

  .INPUTS
  None. You cannot pipe objects to script.

  .OUTPUTS
  The script generates only information output about the operations performed

  .EXAMPLE
  PS> .\upssched-script.ps1 ups-on-battery

  .EXAMPLE
  PS> .\upssched-script.ps1 -State ups-on-battery

  .EXAMPLE
  PowerShell.exe -NoProfile -Command "C:\NUT\sbin\upssched-script.ps1 ups-on-battery"
 
  .NOTES
  Author: Aleksey.Maksimov@it-kb.ru 
  Version: 1.1 (2023-09-22)
  Purpose: Helper script for the upssched.exe process from Network UPS Tools for Windows 
#>

Param (
[Parameter (Mandatory=$true, Position=1)]
[string]$State
)

$NUTdir = "C:\NUT"
$upsmoncfg = $NUTdir + "\etc\upsmon.conf"
$upscexe = $NUTdir + "\bin\upsc.exe"
$vmsshutdown = $true
$writeevents = $true
$eventlogsrc = "Network UPS Tools Script"

If ($writeevents -eq $true) {
    If ([System.Diagnostics.EventLog]::SourceExists($eventlogsrc) -eq $false) {
      [System.Diagnostics.EventLog]::CreateEventSource($eventlogsrc, "Application")
    }
}

Function Logger {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true, Position=1)]
        [string]$Message,
        [Parameter(Mandatory=$false, Position=2)]
        [string]$Color =  "Gray"
    )
    Write-Host $Message -ForegroundColor $Color
    If ($writeevents -eq $true) {
        $EvtType = "Information"
        If ($Color -eq "Yellow") { $EvtType = "Warning" } 
        Write-EventLog -LogName "Application" -Source "Network UPS Tools Script" -Category 0 -EventID 1 -EntryType $EvtType -Message $Message
    }
}

If ($State -eq 'ups-on-battery') {
     
    If (![System.IO.File]::Exists($upsmoncfg)) {
        Logger -Message "The path to the upsmon.conf file is incorrect. `nScript stopped." -Color "Yellow"
        Break    
    }
    [int]$ACSourcesMin = ((Get-Content $upsmoncfg | Where-Object {$_.StartsWith("MINSUPPLIES")}).Trim()[-1]).ToString() -as [int]
    Logger -Message "Retrieved the value of the MINPOWERSUPPLY variable from upsmon.conf : '$ACSourcesMin'"
    
    If ($ACSourcesMin -lt 1) {
        Logger -Message "The value of the MINPOWERSUPPLY variable in the upsmon.conf file is incorrect. `nScript stopped." -Color "Yellow"
        Break
    }
    
    If (![System.IO.File]::Exists($upscexe)) {
        Logger -Message "The path to the upsc.exe file is incorrect. `nScript stopped." -Color "Yellow"
        Break    
    }
    [int]$ACSourcesCurr = 0
    $Sources = @(& $upscexe -l)
    If ($Sources.Count -lt 1) {
        Logger -Message "The 'upsc' program returned less than one UPS. `nScript stopped." -Color "Yellow"
        Break
    }
    #Logger -Message "Retrieved the count of the UPS from 'upsc -l' : '$($Sources.Count)'"
    
    ForEach ($Source in $Sources) {
        $Status = @(& $upscexe $Source ups.status)
        Logger -Message "Retrieved UPS status from 'upsc $Source ups.status' : '$Status'"
        If ($Status -eq 'OL') { $ACSourcesCurr = $ACSourcesCurr + 1 }
    }
    #Logger -Message "Counted number of UPSs in ONLINE state : $ACSourcesCurr"
    
    If ($ACSourcesCurr -lt $ACSourcesMin) {
        Logger -Message "Counted number of UPSs in ONLINE state ($ACSourcesCurr) less than value of the MINPOWERSUPPLY variable in upsmon.conf ($ACSourcesMin)"
        If ($vmsshutdown -eq $true) {
            Logger -Message "Shutting down Hyper-V virtual machines..."
            Get-VM | Where State -eq 'Running' | Stop-VM -Force;
        }
        Logger -Message "Shutting down the system..."
        Stop-Computer -ComputerName localhost -Force;
    } 
    Else {
        Logger -Message "Counted number of UPSs in ONLINE state ($ACSourcesCurr) greater than or equal to value of the MINPOWERSUPPLY variable in upsmon.conf ($ACSourcesMin).`nThe script completed without shutting down the system"
    }
}

В начале своей работы скрипт регистрирует в системном event-логе «Application» новый источник «Network UPS Tools Script«, который будет использоваться для записи событий, связанных с работой скрипта.
Затем из каталога установки NUT (указывается через переменную $NUTdir), предпринимается попытка чтения конфигурационного файла upsmon.conf и считывания значение параметра MINSUPPLIES.
Затем с помощью утилиты upsc.exe извлекается информация о всех подключенных к NUT ИБП в состоянии ONLINE.
Если оказывается, что штатно работающих от входящей электросети ИБП меньше, чем значение полученного ранее параметра MINSUPPLIES, то инициируется процедура завершения работы всех виртуальных машин Hyper-V, а затем самого хоста виртуализации.

Конфигурационные файлы подготовлены и теперь можем попробовать выполнить запуск службы «Network UPS Tools«, например с помощью PowerShell:

Start-Service "Network UPS Tools"

NUT регистрирует события в event-логе «Application«. В случае возникновения проблем при запуске службы в первую очередь стоит заглянуть в этот лог.

Картинка с сайта: blog.it-kb.ru

Замечено, что подключение драйвера snmp-ups к ИБП в некоторых случаях происходит с небольшой задержкой и несколько первичных попыток подключения в течение примерно первой минуты безуспешны. Это приводит к появлению ошибки «upsmon — Poll UPS failed — Data stale» в event-логе Application. Причём данное поведение не зависит от выбора версии протокола SNMP. То есть NUT не сразу подключается к плате управления и получает с неё актуальные данные. По имеющейся информации на более актуальных версиях NUT под Linux такое поведение не воспроизводится, поэтому можно предполагать, что связано с это с «шероховатостями» в реализации NUT под Windows. Есть ощущение, что ошибки появляются по той причине, что модуль upsmon запускается немного раньше, чем успевает пройти инициализацию каждый экземпляр драйвера snmp-ups. По логам можно заметить, что драйвер snmp-ups для второго ИБП загружается позже, чем начинает работу upsmon. После ряда экспериментов стало очевидно то, что это проявляется для разных ИБП и разных плат Спутник, но по сути на работу NUT негативно не влияет.

Кроме того, замечено, что иногда NUT 2.6.5 перестаёт писать в event-лог Application. Закономерности такого поведения мне выяснить не удалось. Похоже, что эта проблема проявляется плавающим образом. Наличие этой проблемы стало одним из аргументов, который побудил реализовать дополнительный функционал записи в event-лог в скрипте выключения upssched-script.ps1, который мы представили выше. По большому счёту на ключевую функциональность NUT эта проблема влияния не имеет.

Проверка состояния подключений NUT к ИБП

Убедиться в правильности настройки связи NUT с платами управления ИБП можно вызвав утилиту upsc (upsc (8)), передав ей в качестве параметра имя ИБП, которое мы указали ранее в конфигурации NUT:

"C:\NUT\bin\upsc" KOM-UP001

При успешно установленной связи драйвера NUT с платой управления ИБП мы должны получить вывод, отображающий текущие показатели работы ИБП

Картинка с сайта: blog.it-kb.ru

Запрос к ИБП можно конкретизировать. Например, чтобы запросить только текущий статус ИБП, можно выполнить:

"C:\NUT\bin\upsc" KOM-UP001 ups.status

Картинка с сайта: blog.it-kb.ru

В данном случае статус «OL» означает, что ИБП работает в штатном режиме от входящей электросети. «OB» означает работу от батарей. «LB» говорит о почти полном разряде батарей («LB OL» при низком заряде и питании от сети, «LB OB» при низком заряде и питании от батарей).

Тестирование сценариев отключения питания на ИБП

После того, как вся конфигурация NUT настроена и мы убедились в успешности подключения NUT к обоим ИБП, правильным будет отработать возможные сценарии с наступлением случаев, когда на любом одном или сразу двух ИБП пропадает входное напряжение.

Перечень проверок, которые покажут нам корректность работы настроенной конфигурации NUT:

1) Отключаем ввод на первом ИБП и ожидаем N минут (по значению указанному нами в upssched.conf). Все виртуальные машины и сам хост виртуализации должны продолжить работу.

2) Отключаем ввод на втором ИБП и ожидаем N минут. Все виртуальные машины и сам хост виртуализации должны продолжить работу.

3) Отключаем ввод на обоих ИБП и ожидаем N минут, после чего должно начаться выключение виртуальных машин, а затем самого хоста виртуализации.

4) Отключаем ввод на ИБП (на любом одном или на обоих сразу), ожидаем период времени, меньший чем N минут. Снова включаем ввод на ИБП. В event-логе должны появиться соответствующие уведомления, а процесс выключения ВМ и хоста не должен запуститься.

5) Отключение по событию слабого заряда батарей, наступающему до истечения N минут. То есть обрабатывается ситуация, когда оба ИБП работают от батарей и у одного любого наступает событие низкий заряд – инициируем выключение виртуальных машин и хоста виртуализации.

При проверке сценариев 3 и 5 следует убедиться в том, что гостевые ОС в виртуальных машинах штатным образом завершают свою работу.

Вариант поднятия версии NUT на Windows

Если есть какие-либо причины или выявленный проблемы, препятствующие использованию указанной готовой сборки NUT «не первой свежести» 2.6.5 на Windows, то можно попробовать обновить исполняемые файлы NUT до актуальной версии из сборок, которые доступны по ссылке «AppVeyor — nut-travis» с вкладки Artifacts:

Картинка с сайта: blog.it-kb.ru

Скачиваем и распаковываем архив NUT-for-Windows-x86_64-SNAPSHOT-2.8.*-master.7z.

Останавливаем службу NUT и убеждаемся, что все процессы NUT (nut.exe, upsd.exe, upsmon.exe, snmp-ups.exe) выгружены из памяти.

Всё содержимое архивного подкаталога «\NUT-for-Windows-x86_64-SNAPSHOT\mingw64» копируем с заменой файлов в каталог установки NUT.

При подобном тестировании одной из предыдущих сборок NUT (2.8.0.806) обнаружилось, что для работы обновлённого драйвера snmp-ups.exe потребуется библиотека libcrypto-1_1-x64.dll. Где взять эту библиотеку их состава OpenSSL? Ссылки на источники загрузки готовых библиотек можно найти здесь: «OpenSSL Wiki — Binaries» . Выбираем на этой странице како-либо из источников, например «ICS Download» и качаем с него архив библиотек OpenSSL 1.1 для x64 Windows. Из архива текущей версии, например openssl-1.1.1w-win64.zip, извлекаем интересующий нас файл библиотеки libcrypto-1_1-x64.dll в каталог с исполняемым файлом snmp-ups.exe (C:\NUT\bin).

Запускаем службу и наблюдаем за event-логом. Не исключено, что в более свежих версиях NUT потребуется корректировка выше описанных параметров конфигурационных файлов NUT.

Диагностика работы NUT

В некоторых случаях может возникнуть какая-либо проблема, причину которой не получается понять по регистрируемым событиям event-лога. В такой ситуации можно воспользоваться отладочным запуском исполняемых файлов NUT в интерактивном режиме.

1) Останавливаем службу «Network UPS Tools» и убеждаемся, что все процессы NUT (nut.exe, upsd.exe, upsmon.exe, snmp-ups.exe) выгружены из памяти.

2) Открываем первую консоль cmd.exe и запускаем в интерактивном режиме экземпляры драйвера с помощью утилиты upsdrvctl.exe:

"C:\NUT\bin\upsdrvctl.exe" -D start

Процедура отработает и в системе должно появится 2 процесса snmp-ups (по процессу на каждый ИБП) из ups.conf. Если требуется более подробный вывод информации, то можно менять ключ «-D» на «-DD» , «-DDD» и так далее. Оставляем эту консоль в запущенном состоянии.

3) Открываем вторую консоль cmd.exe и запускаем в интерактивном режиме процесс сервера NUT upsd.exe:

"C:\NUT\sbin\upsd.exe" -D

В этот момент процесс сервера должен подключиться к ранее запущенным в первой консоли экземплярам драйвера. Оставляем эту консоль в запущенном состоянии.

4) Открываем третью консоль cmd.exe и запускаем в интерактивном режиме процесс клиента NUT upsmon.exe:

"C:\NUT\sbin\upsmon.exe" -D

Процесс должен подключиться к ранее запущенному во второй консоли экземпляру сервера upsd и получить от него данные о состоянии ИБП. Оставляем эту консоль в запущенном состоянии.

После этого можно выполнять всевозможные тестирования и отладочные мероприятия, например выключить автомат ИБП и наблюдать за реакцией в открытых консолях с процессами upsd и upsmon будет.

Для отладки работы самой службы «Network UPS Tools» можно попробовать выполнить интерактивный запуск исполняемый файл службы. Для этого останавливаем службу NUT и запускаем приложение в командной строке в интерактивном режиме:

"C:\NUT\bin\nut.exe" -N

На консоль при этом будет выводиться больше информации, чем мы можем увидеть в событиях event-лога.

Картинка с сайта: blog.it-kb.ru

После прерывания процесса отладки через Ctrl+C потребуется дополнительно через Task Manager удалить процессы upsd.exe, upsmon.exe и snmp-ups.exe (процессы snmp-ups создаются на каждый ИБП отдельно).

Картинка с сайта: blog.it-kb.ru

Заключение

Проведённые испытания свободного ПО Network UPS Tools  на хосте виртуализации c ОС Windows Server 2022, подключенном разными блоками питания к разным ИБП APC Smart-UPS, показали, что данное ПО вполне справляется с задачей контролируемого выключения виртуальных машин Hyper-V и хостовой ОС. То есть NUT может рассматриваться в качестве альтернативы теперь уже платному ПО APC PCNS (PowerChute Network Shutdown).

В рассматриваемом примере компоненты NUT взаимодействовали с платами управления ИБП ПСУ Спутник, но следует понимать, что NUT это универсальное средство и может использоваться с множеством других плат управления ИБП, позволяющих выполнять опрос состояния ИБП по протоколу SNMP (и не только).