+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Proxmox, ИБП и отключение электроэнергии, Proxmox Backup Server

ieronymous

Guest

28.12.2021 09:29:00

Привет! Кто-нибудь настраивал систему, при которой во время отключения питания и когда уровень заряда батарей критически низкий или ниже определённого порога, ИБП сообщает Proxmox, а Proxmox аккуратно завершает работу всех виртуальных машин? Это цепочка так работает: ИБП -> сервер (idrac / ilo) -> Proxmox? Спасибо!

rigel.local

Guest

05.09.2023 14:48:00

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

Dunuin Guest	#3 0 05.09.2023 14:54:00 Нет, сервер NUT и клиенты работают напрямую на хостах PVE через пакеты apt. https://wiki.debian.org/nut https://networkupstools.org/index.html

rigel.local

Guest

05.09.2023 15:11:00

Значит, просто установить сервис NUT в терминале моего хоста Proxmox? И ещё, может ли тот же PVE-хост быть одновременно и сервером, и клиентом NUT? У меня всего один сервер Proxmox, и я хочу, чтобы он корректно завершал работу, когда ИБП фиксирует отключение электроэнергии.

Dunuin Guest	#5 0 05.09.2023 15:19:00 Да, просто установите мета-пакет "nut", который автоматически установит пакеты "nut-server" и "nut-client". Тогда узел PVE сможет работать как сервер и при этом сам себя корректно выключать.

rigel.local Guest	#6 0 05.09.2023 15:58:00 Большое спасибо за разъяснение!

scyto

Guest

01.10.2023 04:29:00

У меня есть 3 узла и один ИБП, который питает все три. Я установил nut и nut-snmp, драйвер успешно показывает статус ИБП, и сейчас я глубоко копаюсь в upsmon.conf... Немного запутался...

1. Каждый узел обнаружит сбой ИБП чуть в разное время.
2. Когда первый узел начнёт завершать работу, я предполагаю, что мои HA-виртуальные машины начнут мигрировать на другой узел.
3. Этот другой узел, скорее всего, сам начнёт выключаться в середине процесса (я использую ceph).

Стоит ли мне из-за этого волноваться и писать более сложный скрипт вместо вызова upsmon /sbin/shutdown?

sienar

Guest

01.09.2024 17:16:00

Не уверен, каким путём ты пошёл, но мне кажется, что неправильно, когда все узлы отдельно следят за одним и тем же UPS. Лучше было бы запустить VM или LXC с NUT-сервером, который мониторит UPS, а на всех машинах, которые нужно корректно выключать при отключении питания, настроить NUT-клиенты, подключённые к этому серверу. Всё, что нужно корректно выключать, должно работать через NUT-клиент с нужными порогами для выключения. А те системы, которым требуется чуть больше автоматизации, могут запускать свои задачи сами.

scyto

Guest

01.09.2024 19:38:00

Эта часть проекта была отложена на второй план, мониторинг работает нормально, а самая сложная часть — тестирование последовательности выключения. Я не понимаю, почему ты считаешь неправильным, что три узла напрямую слушают UPS по сети. Не имеет значения, общаются ли они с nut-сервером или каждый узел напрямую с сетевой картой в UPS. Твое предложение добавить nut-сервер создаёт дополнительную единственную точку отказа, которая не нужна.

sienar

Guest

#10

01.09.2024 19:41:00

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

scyto

Guest

#11

01.09.2024 19:46:00

Честно говоря, я не понимаю, почему подумал, что модуль snp вызовет это, кроме того, что это периодический опрос данных с UPS. Я думал, что nut клиент работает так же, как nut сервер, но если nut сервер передаёт данные на nut клиент, то это интересно, стоит посмотреть.

sienar

Guest

#12

01.09.2024 19:54:00

Думаю, вы правы, что опросный характер мониторинга SNMP вызовет небольшую задержку в том, когда каждый NUT-сервер, который его мониторит, увидит переход ИБП, но клиенты NUT поддерживают постоянное соединение с сервером и фактически увидят переход практически мгновенно. Я всегда выполнял эту задачу с одним сервером NUT, потому что ИБП мониторился по последовательному порту или USB, и следовательно, это мог быть ТОЛЬКО один сервис NUT, напрямую подключённый к устройству. Я даже доходил до того, что ставил сервис NUT на почти выделённое устройство — Raspberry Pi, который параллельно запускал пару других низкоуровневых сетевых сервисов. Конечно, это ещё одна система для поддержки, но мне нравится идея виртуализации, чтобы при необходимости его можно было легко переносить между хостами.

scyto Guest	#13 0 01.09.2024 20:11:00 Да, вот где моя мысль застряла, и, как ни странно, более приоритетные задачи прервали мои исследования. Изначально я думал о том, как остановить нежелательные миграции в процедуре аварийного завершения работы. Только что немного подумал ещё и теперь хочу найти способ изменить политику миграции так, чтобы на всех узлах она замораживалась до тех пор, пока они не вернутся в онлайн. То есть, как-то подстроить эту настройку https://pve.proxmox.com/wiki/High_Availability#ha_manager_shutdown_policy или может что-то из этого, поскольку даже при использовании твоего решения с nut server я вижу риск условий гонки между узлами... будет интересно поиграться с этим. Что касается nut server, я думал о pi, подключённом по USB... То же самое по поводу dns — держать dns в контейнере всегда влечёт за собой интересные последствия, если кластер не запускается из-за проблем с dns... лол.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры