Работа с кластером
Создание кластера
pvecm create YOUR-CLUSTER-NAME pvecm status
pmxcfs -l
Заставить сервер работать в single mode (вне кластера)
pvecm e 1
При повторном добавлении ноды:
pvecm add proxmox-01 -force
/usr/share/doc/corosync/examples/corosync.conf.example.udpu
transport: udpu
Добавить ноду (выполнить на ноде):
pvecm add IP-ADDRESS-CLUSTER
Обновить сертификаты (pveproxy /etc/pve/local/pve-ssl.key: failed to load local private key (key_file or key) at /usr/share/perl5/PVE/APIServer/AnyEvent.pm line 1626)
pvecm updatecerts
/etc/udev/rules.d/80-net-setup-link.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="38:d5:47:c9:10:d7", NAME="net10"
Настройки сети на гипервизоре
Чтобы наша виртуальная машина стала доступна в сети, нужно выполнить настройки на стороне самого гипервизора.
Включаем , для этого в конец файла на выделенном сервере добавляем строку:
Применяем конфигурацию (вводим в консоли команду):
Теперь добавим маршрут для виртуальной машины:
Чтобы он автоматически добавлялся после перезагрузки сервера, пропишем его в конфигурации сети. В секцию с настройками виртуального интерфейса добавим строки:
Примерно так будет выглядеть файл настройки сети на выделенном сервере:
На этом всё, ваша виртуальная машина должна быть доступна в сети. Если же вы решили использовать VMmanager 6 для создания и работы с виртуальными машинами, то про настройку сети в VPU также можете прочитать в нашей статье — настройка сети в VMmanager 6 на выделенных серверах с VPU.
Алексей Гарин, системный администратор
Проблемы и ошибки
Не устанавливается httpd
Сразу скажу, что в качестве хостовой системы и шаблонов для lxc контейнеров я использовал только centos. Возможно в других системах указанных мной ошибок не будет. Первое с чем сразу же столкнулся было невозможность установить пакет httpd. Была вот такая ошибка:
# yum install httpd
Running transaction Installing : httpd-2.4.6-67.el7.centos.6.x86_64 1/1 Error unpacking rpm package httpd-2.4.6-67.el7.centos.6.x86_64 error: unpacking of archive failed on file /usr/sbin/suexec;5a8adbd2: cpio: cap_set_file Verifying : httpd-2.4.6-67.el7.centos.6.x86_64 1/1 Failed: httpd.x86_64 0:2.4.6-67.el7.centos.6 Complete!
В интернете полно информации по подобной ошибке в контейнерах centos. Она встречается не только в lxc, но и в docker. В докере ее каким-то образом в определенный момент исправили, в lxc до сих пор воспроизводится и я не уверен, что исправление будет.
Суть ошибки в том, что существуют некие ограничения ядра для работы file capabilities. Я не вникал подробно в эти file capabilities, не понимаю до конца сути ошибки, только поверхностно. Подробно ошибка разобрана тут — https://github.com/lxc/lxd/issues/1245. Так как решением проблемы предлагается перевести контейнер в privileged режим, когда хостовый рут и контейнерный имеют одинаковые системные id, то примерно понятно, в чем суть ошибки.
В общем, я не стал переводить контейнер в privileged режим, а поступил следующим образом. Зачрутился с хостовой машины в контейнер и установил httpd оттуда. Выполняем на хосте:
# chroot /var/lib/lxc/lxc_centos/rootfs # yum install httpd
Теперь можно зайти в контейнер и проверить, что httpd установлен и нормально работает. Это рабочее решение, когда вы администратор и хоста и контейнеров. Но если вы кому-то отдаете контейнеры под управление, то либо вам придется самим решать ошибки владельцев контейнеров, либо искать какое-то другое решение.
Зависает контейнер и нагружает cpu хоста
Следующая неприятная ошибка, с которой столкнулся сразу же после начала тестирования lxc контейнеров. Контейнер через несколько минут после запуска зависал. Я не мог его ни остановить, ни удалить. При этом на самом хосте процесс /usr/lib/systemd/systemd-journald на 100% нагружал одно ядро cpu.
Решение проблемы следующее. Добавляем в конфиг контейнера параметр:
lxc.kmsg = 0
Перезапускаем контейнер. Заходим в него и удаляем /dev/kmsg (именно в контейнере, не на хосте!!!)
# rm -f /dev/kmsg
После этого контейнеры стали работать стабильно и перестали зависать. Я установил bitrix-env и развернул сайт. Все заработало без проблем с нормальной скоростью.
Не работает chronyd
После установки и запуска chronyd в lxc контейнере с centos 7 получаем ошибку:
ConditionCapability=CAP_SYS_TIME was not met
Тут я уже немного утомился ковыряться в ошибках lxc и понял, что не хочу использовать в работе эти контейнеры. Но все же собрался с силами и погуглил еще немного. Как оказалось, это не ошибка, это ограничение работы в контейнере. Условием работы chronyd является доступ к системному вызову adjtimex(). У контейнера в не privileged режиме нет этого доступа, поэтому он и не запускается.
Контролирует эту ситуацию параметр
ConditionCapability=CAP_SYS_TIME
в конфиге systemd службы chronyd в контейнере — /etc/systemd/system/multi-user.target.wants/chronyd.service. Если убрать этот параметр и запустить службу, получим ошибку:
adjtimex(0x8001) failed : Operation not permitted
В общем, контейнер без привилегированного режима управлять временем не может. Это архитектурная особенность работы контейнеров, с этим ничего не поделать. Надо на хосте следить за временем.
