oVirt за 2 часа. Часть 3. Дополнительные настройки20.05.2020 21:55

В этой статье мы рассмотрим ряд необязательных, но полезных настроек:

Эта статья — продолжение, начало см. oVirt за 4 часа Часть 1 и часть 2.

Статьи

1. Введение
2. Установка менеджера (ovirt-engine) и гипервизоров (hosts)
3. Дополнительные настройки — Мы здесь

Дополнительные настройки менеджера

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

$ sudo yum install bash-completion vim

Для включения автодополнения команд bash-completion следует перевойти в bash.

Добавление дополнительных DNS имен

Это потребуется, когда к менеджеру необходимо подключиться по альтернативному имени (CNAME, псевдоним или просто короткое имя без доменного суффикса). Из соображений безопасности менеджер допускает подключение только по разрешенному списку имен.
Создаем файл конфигурации

$ sudo vim /etc/ovirt-engine/engine.conf.d/99-custom-sso-setup.conf

следующего содержания

SSO_ALTERNATE_ENGINE_FQDNS="ovirt.example.com some.alias.example.com ovirt"

и перезапускаем менеджер

$ sudo systemctl restart ovirt-engine

Настройка аутентификации через AD

oVirt имеет встроенную базу пользователей, но также поддерживаются внешние LDAP провайдеры, в т.ч. AD.
Простейший путь для типовой конфигурации — запуск мастера и перезапуск менеджера:

$ sudo yum install ovirt-engine-extension-aaa-ldap-setup
$ sudo ovirt-engine-extension-aaa-ldap-setup
$ sudo systemctl restart ovirt-engine

Использование мастера подходит для большинства случаев. Для сложных конфигураций настройки выполняются вручную. Подробнее в документации oVirt, Users and Roles. После успешного подключения Engine к AD, в окне подключения появится дополнительный профиль, а на вкладке Permissions у объектов системы — возможность выдавать полномочия пользователям и группам AD. Следует отметить, что внешним каталогом пользователей и групп может быть не только AD, но и IPA, eDirectory и др.

Multipathing

В производственной среде система хранения должна быть подключена к хосту несколькими независимыми путями множественного ввода-вывода. Как правило, в CentOS (и следовательно oVirt'е) проблем со сборкой множественных путей к устройству не возникает (find_multipaths yes). О дополнительных настройках для FCoE написано во 2-й части. Стоит обратить внимание на рекомендацию производителя СХД — многие рекомендуют использовать политику round-robin, по умолчанию же в Enterprise Linux 7 используется service-time.

На примере 3PAR

и документа HPE 3PAR Red Hat Enterprise Linux, CentOS Linux, Oracle Linux, and OracleVM Server Implementation Guide EL создается как Host с Generic-ALUA Persona 2, для него в настройки /etc/multipath.conf вносятся следующие значения:

defaults {
           polling_interval      10
           user_friendly_names   no
           find_multipaths       yes
          }
devices {
          device {
                   vendor                   "3PARdata"
                   product                  "VV"
                   path_grouping_policy     group_by_prio
                   path_selector            "round-robin 0"
                   path_checker             tur
                   features                 "0"
                   hardware_handler         "1 alua"
                   prio                     alua
                   failback                 immediate
                   rr_weight                uniform
                   no_path_retry            18
                   rr_min_io_rq             1
                   detect_prio              yes
                   fast_io_fail_tmo         10
                   dev_loss_tmo             "infinity"
                 }
}

После чего дается команда на перезапуск

systemctl restart multipathd

Рис. 1 — политика множественного ввода-вывода по умолчанию.

Рис. 2 — политика множественного ввода-вывода после применения настроек.

Настройка управления питанием

Позволяет выполнить, например, аппаратный сброс машины, если Engine не сможет продолжительное время получить ответ от Host'а. Реализуется через Fence Agent (агент ограждения).
Compute -> Hosts -> HOST — Edit -> Power Management, далее включить «Enable Power Management» и добавить агента — «Add Fence Agent» -> +.
Указываем тип (напр., для iLO5 надо указать ilo4), имя/адрес ipmi интерфейса, а также имя/пароль пользователя. Пользователя рекомендуется создать отдельного (напр., oVirt-PM) и, в случае с iLO выдать ему привилегии:

• Login
• Remote Console
• Virtual Power and Reset
• Virtual Media
• Configure iLO Settings
• Administer User Accounts

Не спрашивайте почему именно так, подобрано опытным путем. Консольный fencing agent требует меньшего набора прав.
При настройке списков контроля доступа следует иметь ввиду, что агент запускается не на engine, а на «соседнем» хосте (так называем Power Management Proxy), т.е., если в кластере окажется только один узел, управление питанием работать не будет.

Настройка SSL

Полная официальная инструкция — в документации, Appendix D: oVirt and SSL — Replacing the oVirt Engine SSL/TLS Certificate.
Сертификат может быть как нашего корпоративного ЦС, так и от внешнего коммерческого центра сертификации.
Важное замечание: сертификат предназначен для подключения к менеджеру, не повлияет на взаимодействие между Engine и узлами — они будут использовать самоподписанные сертификаты, выданные Engine.
Требования:

• сертификат издающего ЦС в формате PEM, со всей цепочкой до корневого ЦС (от подчиненного издающего в начале до корневого в конце);
• сертификат для Apache, выпущенный издающим ЦС (также дополненный всей цепочкой сертификатов ЦС);
• приватный ключ для Apache, без пароля.

Предположим, наш издающий центр сертификации работает под управлением CentOS, называется subca.example.com, а запросы, ключи и сертификаты располагаются в каталоге /etc/pki/tls/.
Выполняем резервные копии и создаем временный каталог:

$ sudo cp /etc/pki/ovirt-engine/keys/apache.key.nopass /etc/pki/ovirt-engine/keys/apache.key.nopass.`date +%F`
$ sudo cp /etc/pki/ovirt-engine/certs/apache.cer /etc/pki/ovirt-engine/certs/apache.cer.`date +%F`
$ sudo mkdir /opt/certs
$ sudo chown mgmt.mgmt /opt/certs

Загрузка сертификатов, выполняем ее со своей рабочей станции либо передаем иным удобным способом:

[myuser@mydesktop] $ scp -3 causer@subca.example.com:/etc/pki/tls/cachain.pem mgmt@ovirt.example.com:/opt/certs
[myuser@mydesktop] $ scp -3 causer@subca.example.com:/etc/pki/tls/private/ovirt.key mgmt@ovirt.example.com:/opt/certs
[myuser@mydesktop] $ scp -3 causer@subca.example.com/etc/pki/tls/certs/ovirt.crt mgmt@ovirt.example.com:/opt/certs

В результате вы должны увидеть все 3 файла:

$ ls /opt/certs
cachain.pem  ovirt.crt  ovirt.key

Установка сертификатов

Копируем файлы и обновляем списки доверия:

$ sudo cp /opt/certs/cachain.pem /etc/pki/ca-trust/source/anchors
$ sudo update-ca-trust
$ sudo rm /etc/pki/ovirt-engine/apache-ca.pem
$ sudo cp /opt/certs/cachain.pem /etc/pki/ovirt-engine/apache-ca.pem
$ sudo cp /opt/certs/ovirt03.key /etc/pki/ovirt-engine/keys/apache.key.nopass
$ sudo cp /opt/certs/ovirt03.crt /etc/pki/ovirt-engine/certs/apache.cer
$ sudo systemctl restart httpd.service

Добавить/обновить конфирурационные файлы

$ sudo vim /etc/ovirt-engine/engine.conf.d/99-custom-truststore.conf

ENGINE_HTTPS_PKI_TRUST_STORE="/etc/pki/java/cacerts"
ENGINE_HTTPS_PKI_TRUST_STORE_PASSWORD=""

$ sudo vim /etc/ovirt-engine/ovirt-websocket-proxy.conf.d/10-setup.conf

SSL_CERTIFICATE=/etc/pki/ovirt-engine/certs/apache.cer
SSL_KEY=/etc/pki/ovirt-engine/keys/apache.key.nopass

$ sudo vim /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf

# Key file for SSL connections
ssl_key_file = /etc/pki/ovirt-engine/keys/apache.key.nopass
# Certificate file for SSL connections
ssl_cert_file = /etc/pki/ovirt-engine/certs/apache.cer

Далее перезапускаем все затронутые службы:

$ sudo systemctl restart ovirt-provider-ovn.service
$ sudo systemctl restart ovirt-imageio-proxy
$ sudo systemctl restart ovirt-websocket-proxy
$ sudo systemctl restart ovirt-engine.service

Готово! Пора подключиться к менеджеру и проверить, что соединение защищено подписанным SSL сертификатом.

Архивация

Куда же без нее! В этой секции речь пойдет об архивации менеджера, архивация ВМ — отдельный вопрос. Архивные копии будем делать 1 раз в сутки и складываать по NFS, напр., на ту же систему, где мы разместили ISO образы — mynfs01.example.com:/exports/ovirt-backup. Не рекомендуется хранить архивы на той же машине, где работает Engine.

Устнавливаем и включаем autofs:

$ sudo yum install autofs
$ sudo systemctl enable autofs
$ sudo systemctl start autofs

Создаем скрипт:

$ sudo vim /etc/cron.daily/make.oVirt.backup.sh

следующего содержания

#!/bin/bash

datetime=`date +"%F.%R"`
backupdir="/net/mynfs01.example.com/exports/ovirt-backup"
filename="$backupdir/`hostname --short`.`date +"%F.%R"`"
engine-backup --mode=backup --scope=all --file=$filename.data --log=$filename.log
#uncomment next line for autodelete files older 30 days 
#find $backupdir -type f -mtime +30 -exec rm -f {} \;

Делаем файл исполняемым:

$ sudo chmod a+x /etc/cron.daily/make.oVirt.backup.sh

Теперь каждую ночь мы будем получать архив настроек менеджера.

Менеджмент-интерфейс хостов

Cockpit — современный административный интерфейс для Linux систем. В данном случае выполняет роль, близкую web-интерфейсу ESXi.

Рис. 3 — внешний вид панели.

Устанавливается очень просто, нужны пакеты cockpit и плагин cockpit-ovirt-dashboard:

$ sudo yum install cockpit cockpit-ovirt-dashboard -y

Включение Cockpit:

$ sudo systemctl enable --now cockpit.socket

Настройка брандмауэра:

sudo firewall-cmd --add-service=cockpit
sudo firewall-cmd --add-service=cockpit --permanent

Теперь можно подключиться к хосту: https://[Host IP or FQDN]:9090

VLANs

Подробнее о сетях стоит почитать в документации. Возможностей много, здесь опишем подключение виртуальных сетей.
Для подключения других подсетей их сперва следует описать в конфигурации: Network -> Networks -> New, здесь обязательным полем является только имя; чекбокс VM Network, разрешающий машинам использовать эту сеть, включен, а для подключения тега надо включить Enable VLAN tagging, прописать номер VLAN и нажать Ок.
Теперь нужно пройти в хосты Compute -> Hosts -> kvmNN -> Network Interfaces -> Setup Host Networks. Добавленную сеть из правой части Unassigned Logical Networks перетащить влево в Assigned Logical Networks:

Рис. 4 — перед добавлением сети.

Рис. 5 — после добавления сети.

Для массового подключения нескольких сетей к хосту удобно при создании сетей присваить им метку(и), и добавлять сети по меткам.
После создания сети хосты перейдут в состояние Non Operational, пока на закончится добавление сети на все узлы кластера. Такое поведение вызывается признаком Require All на вкладке Cluster при создании новой сети. В случае, когда сеть нужна не на всех узлах кластера, этот признак можно отключить, тогда сеть при добавлении хосту будет справа в секции Non Required и можно выбрать, подключать ли ее к конкретному хосту.

Рис. 6 — выбор признака требования сети.

Специфичное для HPE

Почти у всех производителей есть инструменты, повышающие удобство работы с их продуктами. На примере HPE, полезны AMS (Agentless Management Service, amsd для iLO5, hp-ams для iLO4) и SSA (Smart Storage Administrator, работа с дисковым контроллером) и др.

$ sudo rpm --import https://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub
$ sudo vim /etc/yum.repos.d/mcp.repo

[mcp]
name=Management Component Pack
baseurl=http://downloads.linux.hpe.com/repo/mcp/centos/$releasever/$basearch/current/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-mcp

[spp]
name=Service Pack for ProLiant
baseurl=http://downloads.linux.hpe.com/SDR/repo/spp/RHEL/$releasever/$basearch/current/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-mcp

$ sudo yum --disablerepo="*" --enablerepo="mcp" list available
$ yum info amsd

Установка и запуск:

$ sudo yum install amsd ssacli
$ sudo systemctl start amsd

Пример работы утилиты по работе с дисковым контроллером

На этом пока все. В следующих статьях планирую рассказать некоторых базовых операциях и применениях. Напр., как сделать VDI в oVirt'е.

© Habrahabr.ru