PowerChute Network Shutdown. Настройка автоматического отключения серверов

Вопрос обеспечения бесперебойного энергоснабжения серверов стоит достаточно остро в любой организации — будь то небольшая контора или датацентр с сотнями стоек. Если во втором случае в чрезвычайных ситуациях с подачей электроэнергии из внешних источников в работу включаются генераторы , которые могут обеспечить в некоторых вариантах несколько суток автономной работы (в зависимости от запаса топлива) без вмешательства из вне, то в первом варианте вся нагрузка при отключении электричества ложится на источники бесперебойного питания. Все бы ничего, но вот только основные задачи ИБП — выравнивание напряжения и обеспечение времени работы от батареи в минимальном представлении чуть больше времени выключения самого медленного сервера. Кто-то может поспорить, но все же ИБП не предназначены для обеспечения долговременной (несколько часов и более) работы серверов в ситуации отсутствия электричества, для этого придумали генераторы. Однако покупка генератора, оборудование для него отдельной площадки, прокладка электросети для большинства организаций является неподъемным сценарием, да и, надо признать, абсолютно не нужным.

В таком случае возникает необходимость автоматического отключения серверов до того момента, когда батареи ИБП разрядятся полностью. Теоретически это можно сделать вручную, но даже если у вас всего несколько серверов, это будет не очень удобно и быстро. Ситуация станет серьезной проблемой, если у вас много серверов или ИБП загружены до уровня, близкого к своему максимальному (в этом случае обычно они проработают не более 5-7 минут, если брать в расчет среднестатистический ИБП без дополнительных батарейных блоков). Да и при ручном выключении кто-то должен мониторить ситуацию 24/7, что тоже нереально.

На помощь приходит PowerChute Network Shutdown 1 от APC (далее по тексту PCNS). Эта утилита предназначена для выполнения различных сценариев (чаще всего обычное корректное выключение серверов) при возникновении каких-либо событий в цепи электропитания. Работает она совместно с UPS Network Management Card 2 2 (далее по тексту UPS NMC), которая по сути является платой расширения для различных ИБП. Решение, конечно же, применимо только для ИБП от APC.

В статье я планирую рассказать о своем личном опыте при работе с оборудованием, описанным выше. Большинство моментов касательно установки и настройки оборудования я опущу, поскольку считаю их описание лишим — в сети очень много подробных любительских инструкций, кроме того, сопроводительная литература ко всем продуктам APC доступна в полном объеме и все моменты эксплуатации расписаны крайне подробно.

Итак, к моменту конфигурирования автоматического отключения серверов у меня было следующее оборудование:

1) ИБП Smart-UPS 3000 RM XL 3 ;

2) Установленная и настроенная плата сетевого управления к ИБП: AP9630 4 ;

3) Локальная сеть, в которой находятся плата сетевого управления и целевые серверы.

Задача: настроить PCNS на серверах виртуализации Microsoft Hyper-V 2008 R2 — 2012 R2. Процесс установки PCNS и начального конфигурирования через веб-интерфейс я, как и обещал ранее, намерен пропустить. Если у кого-то с этим возникают сложности, рекомендую обратиться к официальной документации 5 6 .

Основная сложность настройки заключается в том, что нужно точно себе представлять как будет работать система. Больше всего вопросов возникает на сценарии завершения работы серверов, в официальном руководстве рассматриваются различные варианты отключения и в конечном счете они представляются как красивые диаграммы. Много раз прочитав эти примеры, я выработал для себя следующий алгоритм настройки всей системы:

1) Определите максимальное время работы ИБП при отключенном питании и полной нагрузке. У меня оно равнялось 12-14 минутам, поскольку нагрузка была неполная;

2) Разделите все серверы на два списка (можно и на 3, да хоть на 10, но это усложнит конфигурацию) — критически важные для организации серверы (хотя бы один контроллер домена, почтовый сервер, файловое хранилище и т.п.) и серверы, которые можно безболезненно отключить (обкаточные серверы, WSUS, доп. контроллеры домена и т.п., у каждого свое);

3) Для каждой группы серверов определите время их работы после отключения входного питания ИБП. Для важных серверов постарайтесь максимально продлить время работы, то есть отключайте их в самую последнюю очередь (у меня это 5 минут). Обеспечить это можно только отключением маловажных серверов как можно раньше (я остановился на 30 секундах).

Дальше остается только перейти к настройкам установленных агентов PCNS. Для физических серверов и хостов виртуализации настройки будут немного отличаться — на хостах виртуализации нужно установить время задержки для выключения или миграции виртуальных машин:

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

Переходим в пункт меню Configure Events, нам нужно первое событие — UPS On Battery (ИБП работает от батареи, то есть входное напряжение либо упало до нуля, либо слишком низкое для нормальной работы), сразу справа от него в столбце Shutdown нажимаем на значок шестеренки (у меня отображается галочка, поскольку я уже настроил действие при работе от батареи). Выставляем нужное вам значение в секундах. Для себя я определил его в 300 секунд. То есть по истечении этого времени система начнет выключаться, но виртуальным машинам будет предоставлено дополнительное время для завершения работы (его мы указали в настройках Shutdown Settings).

После этого самое время протестировать как все работает на реальной ситуации. Для этого я отдельно сымитировал отключение питания — просто выдернул кабель питания из ИБП. Через 30 секунд у меня начали выключаться второстепенные хосты виртуализации и физические серверы, через 5 минут начали заглушаться виртуальные машины на важных инфраструктурных серверах, когда они выключились, хосты виртуализации заглохли и в серверной воцарилась тишина…

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

1) Спланируйте установку CPNS на ваших серверах: далеко не каждая операционная система поддерживается. Нужно также решить что делать с виртуальными машинами на базе unix-систем, возможно придется писать вручную скрипты, чтобы заглушить их корректным образом. С малораспространенными дистрибутивами и, например, системами для NAS (тот же Openfiler) могут быть серьезные проблемы в виду полного отсутствия их поддержки;

2) Не пожалейте дополнительного времени для выключения виртуальных машин. Вы должны понимать, что когда все виртуалки начнут обращаться к жестким дискам, их быстродействие резко снизится и время завершения работы значительно увеличится;

3) Не старайтесь выжать из вашего старичка ИБП полный максимум. Пусть ваши виртуальные машины и серверы завершат работу немного раньше, чем ИБП разрядится полностью. Да даже если он разрядится всего лишь на 50%, что тут такого? Ваша основная задача не продержать серверы включенными как можно дольше, а корректным образом завершить их работу, в конце концов. Также учтите, что со временем ваш ИБП на батареях будет работать все меньше и меньше в виду их износа, а это уже серьезная причина, чтобы оставить достаточный «запас прочности» по времени;

4) Обязательно протестируйте сценарий отключения. Не пожалейте одного выходного и проведите тестирование отключения серверов и виртуальных машин при реальном отключении электричества. Я проводил это ранним субботним утром с секундомеров в руке;

5) Наверно это надо было написать первым пунктом, но все же: купите уже себе плату управления для ИБП, если у вас её все ещё нет (это не реклама). Не жалейте денег, даже если у вас всего пара серверов в стойке и отключение электричества за свою карьеру вы не видели, ведь перебои питания самым худшим образом сказываются на работе приложений, СУБД особенно.

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

Настройка лимитов (таймаутов) для RDP/RDS сессий в Windows

По-умолчанию, когда пользователь со своего компьютера закрывает окно своей RDP/RDS сессией в терминальном клиенте (mstsc, rdcman или rdp html web клиент) простым нажатием по крестику в окне, без выполнения выхода (logoff), его сессия переходит в режим disconnected (разъединённый сеанс). В этом режиме все запущенные пользователем программы, открытые документы и окна продолжают работать на удаленном сервере и потреблять ресурсы.

По-умолчанию в Windows RDP сессия пользователя может находится в состоянии disconnected до перезагрузки компьютера или явного ее завершения пользователем или администратором. Это довольно удобно, т.к. пользователь может в любой момент подключиться к своей старой сессии и продолжить работу с открытыми программами и документами.

На следующем скриншоте видно, что отключенные сессии пользователей на RDS сервере с Windows Server 2016 используют около 35% памяти сервера. Кроме того незавершенные сессии могут блокировать открытые файлы на файловых серверах, вызывать проблемы с корректным сохранением данных в приложениях, профилях или User Profile Disks.

С помощью команды quser можно узнать, когда начата RDP сессия пользователя, длительность простоя и статус сессии.

Для автоматического завершения отключенных RDP/RDS сессий через определенный промежуток времени, вам нужно правильно настроить лимиты (таймауты).

При использовании RDS сервера, вы можете настроить параметры таймаутов сессий в настройках RDS коллекций на вкладке Session.

Укажите время, через которое нужно завершить отключенный сеанс в параметре End a disconnected session (по умолчанию срок сеанса неограничен – never). Также вы можете выставить максимальную длительность активной RDP сессии (Active session limit) и отключение бездействующего сеанса (Idle session limit). Это жесткие таймауты применяются для всех сессий в RDS коллекции.

Также можно настроить ограничение времени RDP сессии в свойства локального (консоль lusrmgr.msc) или доменного пользователя (консоль dsa.msc — ADUC).

В Windows Server 2012 R2/2016/2019 можно настроить таймауты RDP сессий с помощью групповых политик. Можно использовать как редактор доменных GPO gpmc.msc, так и редактор локальных групповых политик (gpedit.msc) на конкретном RDS сервере или клиенте (если вы используете десктопную Windows в качестве терминального сервера)

Параметры таймаутов RDP сессий находятся в разделе GPO

Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits (Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Ограничение сеансов по времени). Доступны следующие политики таймаутов:

• Set time limit for disconnected session (Задать ограничение по времени для отключенных сеансов)
• Set time limit for active but idle Remote Desktop Services sessions (Задать ограничение времени для активных, но бездействующих сеансов служб удаленных рабочих столов) – политика позволяет завершить простаивающие RDP сессии, в которых отсутствует ввод со стороны пользователя (движение мышкой, ввод символов с клавиатуры)
• Set time limit for active Remote Desktop Services sessions (Задать ограничение по времени для активных сеансов служб удаленных рабочих столов) – максимальный срок для любой (даже активной) RDP сессии пользователя, после которого она переводится в состояние disconnected;
• End Session when time limits are reached (Завершать сеанс при достижении ограничения по времени) – через какое время нужно завершать RDS сессию (logoff) вместо перевода ее в disconnected;
• Set time limit for logoff of RemoteApp sessions (Задать предел для выхода из сеансов RemoteApp)

По умолчанию эти параметры не настроены. Чтобы автоматически завершать отключенные RDP сеансы пользователей через 8 часов, включите политику “Set time limit for disconnected session” = Enabled, и в выпадающем списке выберите 8 часов.

Сохраните изменения и обновите политики сервера (gpupdate /force). Новые настройки таймаутов будут применяться только к новым RDP сеансам, текущие сеансы придется завершить вручную.

• MaxDisconnectionTime
• MaxIdleTime
• MaxConnectionTime
• MaxDisconnectionTime
• RemoteAppLogoffTimeLimit

Настройка экстренного отключения удаленного сервера Windows

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

Предполагается, что серверы находятся на удаленной площадке за пределами офиса.

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

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

Скрипт отключения сетевого интерфейса:

Расшифровка команд в скрипте:

1. echo %username% %date% %time% — команда, которая запоминает дату, время и имя пользователя, который выполнил скрипт. Нужно для понимания когда и кем был выполнен скрипт.
2. D:\Backup\scripts\shutdown\shutdown_log.txt — путь и имя файла, в который будет записана вышеуказанная информация.
3. C:\WINDOWS\system32\netsh.exe — вызов утилиты, отвечающей за управление сетевыми интерфейсами.
4. interface set interface lan disabled — команда отключения сетевого интерфейса, где lan — название интерфейса.

Проверяем работу скрипта:

Рисунок 1 — Отработка скрипта в командной строке

Скрипт отработал, смотрим состояние интерфейса:

Рисунок 2 — Консоль управления сетевыми подключениями

Интерфейс успешно перешел в отключенное состояние, проверяем лог:

Рисунок 3 — Консоль проводника с файлом лога

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

Услуга Сервер в Израиле имеет функционал удаленного отключения сервера по-умолчанию. Подробнее на странице.