Введение
Сразу предупреждаю, что данная статья это мое знакомство с lxc контейнерами. Я не имею практического опыта работы с ними, поэтому бездумно брать и применять мои рекомендации не стоит.
Не буду много писать о том, что такое контейнеры, чем они отличаются от виртуальных машин, и чем отличаются системы контейнеров (lxc, docker, openvz и др.) друг от друга. Все это можно найти в интернете на сайтах самих продуктов. Расскажу все своими словами.
- Главное отличие контейнера от виртуальной машины в том, что он запускается на том же уровне железа, что и хостовый сервер. Нет необходимости в виртуальных устройствах. Контейнер видит исходное железо. Это плюс к производительности. Используется ядро исходной системы и изоляция ресурсов внутри системы.
- Контейнер может масштабироваться по ресурсам до целого физического сервера. Например, контейнер может использовать тот же диск и файловую систему, что и хостовая машина. Нет необходимости разбивать диск на кусочки, как с виртуальными машинами и давать каждому по кусочку. В итоге, кто-то может свой диск вообще не использовать, а кому-то не хватит. С контейнерами можно поступить проще — все используют общий диск с хостом. Ограничений для диска как в виртуальной машине тем не менее все равно можно устанавливать. То же самое можно сделать с процессором и памятью.
Я почти не работал с контейнерами, кроме докера. С ним приходится работать только в связке с разработчиками. Для своих целей я его не использую, так как для моих задач он мне кажется неудобным. Не хочется сейчас здесь раскрывать эту тему, может быть в другой раз в статье о докер, если таковая будет. Но в целом докер я не люблю, особенно в продакшене.
Расскажу о том, почему мне захотелось посмотреть на контейнеры вместо виртуальных машин, которые использую повсеместно уже много лет.
- Как уже написал ранее, привлекает возможность использовать ресурсы хостовой машины напрямую. Взял системный диск с корнем / на 1Тб и все контейнеры его используют пока есть место.
- Легкий бэкап и доступ к файлам в контейнерах. Посмотреть файлы в контейнере можно просто зайдя в директорию контейнера с хостовой машины. Они все хранятся в открытом виде. Так их очень удобно бэкапить с помощью rsync, или каким-то другим способом.
- Легко копировать, разворачивать, управлять контейнерами. Они занимают мало места, можно руками с хоста поправить какой-то конфиг в системе контейнера.
Например, у меня есть достаточно мощные VDS серверы от ihor. 2 ядра, 8 гигов, 150Гб диск. Иногда то, что там размещается, не использует полностью ресурсы виртуальной машины. Хочется как-то их занять, но при этом никак не затрагивать основные проекты на виртуальной машине. Иногда хочется какие-то тестовые среды создавать для сайтов и пробовать новые версии софта. Для этого надо отдельную виртуалку брать. Вместо этого я решил попробовать lxc контейнеры.
Использовать lxc контейнеры в плане сети можно двумя способами:
- Заказывать каждому контейнеру отдельный внешний IP, настраивать для контейнера bridge на реальном сетевом интерфейсе и выпускать его напрямую в интернет. Этот вариант подходит, если есть ip адреса или не жалко для них денег. Так работать удобнее всего.
- Настраивать виртуальный bridge, настраивать NAT и проброс портов с хостовой машины внутрь контейнеров. Не очень удобно, но тем не менее вполне рабочий вариант.
Я расскажу про оба способа, так как проверял и то и другое. Настраивать все будем на CentOS 7.
Если у вас еще нет своего сервера с CentOS 8, то рекомендую мои материалы на эту тему:
- Установка CentOS 8.
- Настройка CentOS.
Введение
Ранее я рассказывал об устновке и настройке apcupsd на XenServer. Вся теоретическая часть есть там в начале и в конце статьи. В данном случае я предалагю использовать apcupsd в качестве клиента, который получает информацию об электропитании по сети от сервера, в которому подключен ups напрямую. Сам же сервер hyperv подключен к другому ups, который никак не мониторится и не управляется.
После отключения электричества гипервизор hyperv подождет момента, когда заряд батареи упса, подключенного к основному серверу упадет до уровня 50% или время работы от батареи будет ниже 20 минут и начнет завершение своей работы.
Введение
Ранее я рассказывал об устновке и настройке apcupsd на XenServer. Вся теоретическая часть есть там в начале и в конце статьи. В данном случае я предлагю использовать apcupsd в качестве клиента, который получает информацию об электропитании по сети от сервера, в которому подключен ups напрямую. Сам же сервер hyperv подключен к другому ups, который никак не мониторится и не управляется.
После отключения электричества гипервизор hyperv подождет момента, когда заряд батареи упса, подключенного к основному серверу упадет до уровня 50% или время работы от батареи будет ниже 20 минут и начнет завершение своей работы.
Введение
Ранее я рассказывал об устновке и настройке apcupsd на XenServer. Вся теоретическая часть есть там в начале и в конце статьи. В данном случае я предлагю использовать apcupsd в качестве клиента, который получает информацию об электропитании по сети от сервера, в которому подключен ups напрямую. Сам же сервер hyperv подключен к другому ups, который никак не мониторится и не управляется.
После отключения электричества гипервизор hyperv подождет момента, когда заряд батареи упса, подключенного к основному серверу упадет до уровня 50% или время работы от батареи будет ниже 20 минут и начнет завершение своей работы.
Настройка работы машины с ИБП APC
Подключите ИБП к компьютеру с помощью кабеля USB.
Выполните следующие настройки:
/etc/apcupsd/apcupsd.conf
# If during a power failure, the remaining battery percentage # (as reported by the UPS) is below or equal to BATTERYLEVEL, # apcupsd will initiate a system shutdown. BATTERYLEVEL 10 # If KILLDELAY is non-zero, apcupsd will continue running after a # shutdown has been requested, and after the specified time in # seconds attempt to kill the power. This is for use on systems # where apcupsd cannot regain control after a shutdown. # KILLDELAY <seconds> 0 disables KILLDELAY 60
где:
- — уровень заряда батареи (в процентах), при котором инициируется выключение компьютера
-
задаётся в секундах. Через указанное время (в данной конфигурации
60 сек.) после отправки сигнала на выключение компьютера начнёт выключаться ИБП. Данный параметр необходим, чтобы, во-первых, сохранить какой-то заряд батареи, во-вторых, чтобы при подаче питания автоматически включился компьютер.
Важно
При данной конфигурации ИБП будет инициировать выключение компьютера, подключённого через USB, когда заряд батареи составит 10%.
Параметры BATTERYLEVEL и MINUTES работают одновременно. Это означает, что сигнал выключения компьютера будет отправлен при достижении уровня заряда батареи, удовлетворяющего любому из условий, заданных в этих параметрах.
![Apcupsd [мозаика системного администрирования]](https://tehnikaarenda.ru/wp-content/uploads/0/5/d/05de428d9bb3e0dbfb6a30d6cc2cbe0f.jpeg)
![Установка агента ибп apc для автоматического выключения ос centos linux 7.4 - apc powerchute network shutdown [вики it-kb]](https://tehnikaarenda.ru/wp-content/uploads/0/2/d/02d19b81891b8986f7db82082abc1365.jpeg)
Запустите службу apcupsd и добавьте её в автозагрузку:
/etc/init.d/apcupsd restart
rc-config add apcupsd
Для получения информации о статусе ИБП используется следующая команда:
apcacess status
APC : 001,043,1003 DATE : 2018-04-28 17:07:30 +0300 HOSTNAME : pc284 VERSION : 3.14.14 (31 May 2016) gentoo UPSNAME : pc284 CABLE : USB Cable DRIVER : USB UPS Driver UPSMODE : Stand Alone STARTTIME: 2018-04-28 16:48:42 +0300 MODEL : Smart-UPS 750 STATUS : ONLINE LINEV : 223.2 Volts LOADPCT : 9.1 Percent BCHARGE : 100.0 Percent TIMELEFT : 106.0 Minutes MBATTCHG : 0 Percent MINTIMEL : 0 Minutes MAXTIME : 40 Seconds OUTPUTV : 223.2 Volts SENSE : High DWAKE : -1 Seconds DSHUTD : 90 Seconds LOTRANS : 208.0 Volts HITRANS : 253.0 Volts RETPCT : 0.0 Percent ITEMP : 34.6 C ALARMDEL : 30 Seconds BATTV : 27.3 Volts LINEFREQ : 50.0 Hz LASTXFER : No transfers since turnon NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A SELFTEST : NO STESTI : 14 days STATFLAG : 0x05000008 MANDATE : 2007-07-20 SERIALNO : AS0729143376 BATTDATE : 2007-07-20 NOMOUTV : 230 Volts NOMBATTV : 24.0 Volts FIRMWARE : 651.13.I USB FW:7.3 END APC : 2018-04-28 17:07:34 +0300
Настройка apcupsd
На компьютере, с которого происходит управление гипервизором открываете папку на серере, куда установили apcupsd. В моем случае это c:\apcupsd. Дальше в папке \etc\apcupsd располагается конфигурационный файл apcupsd.conf, открываете его и редактируете. Не копируйте мой файл полностью, а укажите необходимые параметры у себя. В моем случае конфиг получился такой:
## apcupsd.conf v1.1 ## # # for apcupsd release 3.14.14 - win32-mingw # # "apcupsd" POSIX config file UPSCABLE ether UPSTYPE net DEVICE 192.168.0.1:3551 SCRIPTDIR c:\apcupsd\etc\apcupsd PWRFAILDIR c:\apcupsd\etc\apcupsd NOLOGINDIR c:\apcupsd\etc\apcupsd ONBATTERYDELAY 6 BATTERYLEVEL 50 MINUTES 20 TIMEOUT 0 ANNOY 300 ANNOYDELAY 60 NOLOGON disable KILLDELAY 0 NETSERVER off NISIP 0.0.0.0 NISPORT 3551 EVENTSFILE c:\apcupsd\apcupsd.events EVENTSFILEMAX 100 UPSCLASS standalone UPSMODE disable STATTIME 10 STATFILE c:\apcupsd\apcupsd.status LOGSTATS off DATATIME 0
Теперь можно запустить службу Apcupsd UPS Monitor в списке служб гипервизора. Сделать это можно с машины, которая настроена на управление гипервизором. В случае успешного запуска в папке c:\apcupsd появятся 2 файла:
- apcupsd.events
- apcupsd.status
В первом файле будет информация о старте сервиса:
2016-09-12 15:59:40 +0300 apcupsd 3.14.14 (31 May 2016) mingw startup succeeded
Во втором информация об UPS:
APC : 001,027,0701 DATE : 2016-09-12 16:28:58 +0300 HOSTNAME : xm-hyperv VERSION : 3.14.14 (31 May 2016) mingw UPSNAME : xm-xen02 CABLE : Ethernet Link DRIVER : NETWORK UPS Driver UPSMODE : ShareUPS Master STARTTIME: 2016-09-12 15:59:40 +0300 MASTERUPD: 2016-09-12 16:28:58 +0300 MASTER : 192.168.0.1:3551 MODEL : Smart-UPS C 1500 STATUS : ONLINE SLAVE BCHARGE : 100.0 Percent TIMELEFT : 75.0 Minutes MBATTCHG : 50 Percent MINTIMEL : 20 Minutes MAXTIME : 0 Seconds BATTV : 27.3 Volts NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A STATFLAG : 0x07000408 SERIALNO : AS1525211660 NOMBATTV : 24.0 Volts FIRMWARE : UPS 10.0 / ID=1005 END APC : 2016-09-12 16:28:58 +0300
На этом настройка apcupsd закончена. При наступлении времени выключения, гипервизор завершит работу всех виртуальных машин и выключится сам. Главное правильно подобрать время, чтобы сам гипервизор успел выключиться и не высохли батареи того упса, к которому подключен он сам. Ставьте приличный запас на всякий случай.
Обязательно нужно проверить, что на всех виртуальных машинах установлены службы интеграции, чтобы гипервизор мог корректно выключать виртуальные машины. Я не проверял, что будет, если службы интеграции не установлены. Может быть два варианта — либо принудительно завершит работу, либо вообще не завершит работу ни виртуалки, ни себя, а потом аварийно выключится, когда заряд батарей закончится.
Настройка и подключение клиента
Клиентские компьютеры должны быть настроены на использование DNS-сервера, который мы сконфигурировали на сервере FreeIPA во время его установки. В сетевых настройках указываем использовать наш сервер ipa для разрешения имен и перезапускаем сетевую службу:
systemctl restart network || systemctl restart networking
Устанавливаем клиента.
а) на компьютеры с Red Hat / CentOS:
yum install freeipa-client
б) на компьютеры с Debian / Ubuntu:
apt-get install freeipa-client
Выполним конфигурирование клиента:
ipa-client-install —mkhomedir
… система на основе данных из DNS попробует определить настройки и отобразить их в консоли, например:
![Установка агента ибп apc для автоматического выключения ос centos linux 7.4 - apc powerchute network shutdown [вики it-kb]](https://tehnikaarenda.ru/wp-content/uploads/3/7/7/377bef9e89bd29fb39cd78cc6e9f6d34.jpeg)
Discovery was successful!
Client hostname: freeipa-client.dmosk.local
Realm: DMOSK.LOCAL
DNS Domain: DMOSK.LOCAL
IPA Server: ipa-server.dmosk.local
BaseDN: dc=dmosk,dc=local
Если эти настройки верны, отвечаем положительно на запрос Continue to configure the system with these values?
Continue to configure the system with these values? : yes
Система спросит, от какого пользователя производить настройку — вводим admin:
User authorized to enroll computers: admin
… и пароль:
Password for [email protected]:
Начнется процесс конфигурации — после его завершения:
…
Configured /etc/openldap/ldap.conf
NTP enabled
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Configuring DMOSK.LOCAL as NIS domain.
Client configuration complete.
… сразу проверим, что клиент может получать билет от сервера:
kinit admin
… и вводим пароль от пользователя admin.
Проверяем, что билет получен:
klist
Ответ должен быть, примерно, следующим:
Ticket cache: KEYRING:persistent:0:0
Default principal: [email protected]
Valid starting Expires Service principal
25.07.2019 23:39:56 26.07.2019 23:39:52 krbtgt/[email protected]
![Установка агента ибп apc для автоматического выключения ос debian gnu/linux 10 (buster) - apc powerchute network shutdown 4.3 [вики it-kb]](https://tehnikaarenda.ru/wp-content/uploads/0/a/b/0abcf099ab106e351c3f9a90db29d24a.jpeg)
![Apcupsd [мозаика системного администрирования]](https://tehnikaarenda.ru/wp-content/uploads/c/f/2/cf2d27b1a6dcc3f0f94c848fa63dd0b6.jpeg)
Клиент настроен.
Настройка apcupsd
Открываем конфигурационный файл apcupsd на сервере, к которому подключен ups и редактируем. Я не рекомендую копировать и вставлять приведенный мной файл, лучше в своем файле измените нужные параметры. Так надежнее. Утилита как минимум читает комментарии в заголовке конфига, если вы их удалите, получите ошибку при старте сервиса.
# mcedit /etc/apcupsd/apcupsd.conf
## apcupsd.conf v1.1 ## # # for apcupsd release 3.14.10 (13 September 2011) - redhat # # "apcupsd" POSIX config file UPSCABLE usb UPSTYPE usb DEVICE LOCKFILE /var/lock SCRIPTDIR /etc/apcupsd PWRFAILDIR /etc/apcupsd NOLOGINDIR /etc ONBATTERYDELAY 6 BATTERYLEVEL 10 MINUTES 2 TIMEOUT 0 ANNOY 300 ANNOYDELAY 60 NOLOGON disable KILLDELAY 0 NETSERVER on NISIP 192.168.0.1 NISPORT 3551 EVENTSFILE /var/log/apcupsd.events EVENTSFILEMAX 50 UPSCLASS sharemaster UPSMODE share STATTIME 10 STATFILE /var/log/apcupsd.status LOGSTATS off DATATIME 0
Я не буду приводить описание параметров, они очень хорошо прокомментированы разработчиками, там все понятно
Обращаю внимание на адрес 192.168.0.1. В данном случае это адрес сервера, на котором установлен apcupsd
По этому адресу к нему будут обращаться остальные серверы за состоянием упса.
Редактируем конфигурационный файл на клиенте:
# mcedit /etc/apcupsd/apcupsd.conf
## apcupsd.conf v1.1 ## # # for apcupsd release 3.14.10 (13 September 2011) - redhat # # "apcupsd" POSIX config file UPSCABLE ether UPSTYPE net DEVICE 192.168.0.1:3551 LOCKFILE /var/lock SCRIPTDIR /etc/apcupsd PWRFAILDIR /etc/apcupsd NOLOGINDIR /etc ONBATTERYDELAY 6 BATTERYLEVEL 20 MINUTES 3 TIMEOUT 0 ANNOY 300 ANNOYDELAY 60 NOLOGON disable KILLDELAY 0 NETSERVER off NISIP 127.0.0.1 NISPORT 3551 EVENTSFILE /var/log/apcupsd.events EVENTSFILEMAX 50 UPSCLASS standalone UPSMODE disable STATTIME 10 STATFILE /var/log/apcupsd.status LOGSTATS off DATATIME 0
Не забудьте так сконфигурировать apcupsd на всех серверах, чтобы самым последним у вас завершал работу сервер, к которому подключен УПС. Если ошибиться и этого не сделать, то если завершит работу сервер с упс, остальные не смогут правильно определить свое время отключения. После пропадания связи с сервером, клиенты apcupsd не будут ничего предпринимать.
Теперь запускаем на обоих серверах службу:
# service apcupsd start
В XenServer 7:
# systemctl start apcupsd
Проверяете лог событий и файл состояния упса. В логе должны увидеть информацию о том, что сервис запущен, в файле состояния информацию от упса. На сервере и клиенте она будет разная.
# cat /var/log/apcupsd.events # cat /var/log/apcupsd.status
Статус сервера:
Статус клиента:
Одно важное замечание. Не забудьте открыть необходимые порты на фаерволе
Лично у меня на гипервизоре был включен фаервол и клиентаская утилита apcupsd не смогла подключиться к серверу и прочитать состояние упса. Исправляем это:
# iptables -I INPUT -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 3551 -j ACCEPT # iptables -I INPUT -p udp -m state --state NEW,ESTABLISHED -m udp --dport 3551 -j ACCEPT # iptables -I OUTPUT -p tcp --sport 3551 -m state --state ESTABLISHED -j ACCEPT # iptables -I OUTPUT -p udp --sport 3551 -m state --state ESTABLISHED -j ACCEPT # service iptables save
Я не знаю, по tcp или udp работает apcupsd, поэтому открыл оба порта на вход и выход. После этого клиент успешно подключился к серверу и получил состояние упса. В завершение настройки, убедившись, что все работает, добавляем apcupsd в автозагрузку:
# chkconfig --add apcupsd # chkconfig apcupsd on
В случае с Xenserver 7 команда будет такая:
# systemctl enable apcupsd
Заключение
Вопрос корректного завершения работы гипервизоров при подключении к UPS достаточно актуальный. Я не однократно сталкивался с такими вопросами в итернете. Какого-то надежного и популярного решения для этого я не встречал. В случае с XenServer или Hyper-V все решается относительно просто с помощью apcupsd. С VMware будет посложнее, но тоже возможно. Там UPS пробрасывают в виртуалку, настраивают apcupsd и с помощью скриптов по ssh отправляют команду на выключение на гипервизор. Я как-то пробовал так сделать, сходу не получилось, а отладить решение не было возможности. В итоге не стал разбираться. Данная схема мной уже проверена на практике и успешно работает.
источник
![Установка агента ибп apc для автоматического выключения ос debian gnu/linux 10 (buster) - apc powerchute network shutdown 4.3 [вики it-kb]](https://tehnikaarenda.ru/wp-content/uploads/2/0/0/200032b6f026f1147c57adff9746ec28.jpeg)
