Создание отказоустойчивой ИТ инфраструктуры. Часть 2. Установка и настройка кластера oVirt 4.3

Эта статья является продолжением предыдущей – «Создание отказоустойчивой ИТ инфраструктуры. Часть 1 — подготовка к развёртыванию кластера oVirt 4.3».

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

Вводная часть

Основная цель статьи – не сколько выдать пошаговую инструкцию вида «Next -> Yes -> Finish», сколько показать некоторые особенности при его установке и настройке. Процесс по развёртыванию вашего кластера, не всегда может совпадать с описанным в ней, из-за особенностей инфраструктуры и окружения, но общие принципы будут одинаковыми.

С субъективной точки зрения, oVirt 4.3 по своему функционалу похож на VMware vSphere версии 5.х, но конечно же со своими особенностями настройки и работы.

Для интересующихся, все отличия между RHEV (aka oVirt) и VMware vSphere можно найти в Интернете, например здесь, но всё же буду иногда отмечать их некоторые отличия или похожести между собой, по ходу статьи.

Отдельно хотелось бы немного сравнить работу с сетями для виртуальных машин. В oVirt реализован похожий принцип управления сетями для виртуальных машин (далее ВМ), как и в VMware vSphere:

• с помощью стандартного Linux bridge (в VMware — Standard vSwitch), работающего на хостах виртуализации;
• с помощью Open vSwitch (OVS) (в VMware — Distributed vSwitch) – это распределённый виртуальный коммутатор, состоящий из двух основных компонентов: центрального сервера OVN и контроллеров OVN на управляемых хостах.

Необходимо отметить, что из-за простоты реализации, в статье будет описана настройка сетей в oVirt’е для ВМ с помощью стандартного Linux bridge, который является стандартным выбором, при использовании гипервизора KVM.

В связи с этим имеется несколько базовых правил по работе с сетью в кластере, которые лучше не нарушать:

• Все сетевые настройки на хостах перед добавлением их в oVirt, должны быть идентичными, кроме IP адресов.
• После того, как хост взят под управление oVirt’ом, на нём крайне не рекомендуется что-то менять руками в сетевых настройках, без полной уверенности в своих действиях, так как агент oVirt просто откатит их на предыдущие, после рестарта хоста или агента.
• Добавление новой сети для ВМ, как и работы с ней, должно производиться только из консоли управления oVirt’ом.

Ещё одно важное замечание — для очень критичного окружения (весьма чувствительного к денежным потерям), всё-таки рекомендовалось бы использовать платную поддержку и использовать Red Hat Virtualization 4.3. В процессе эксплуатации кластера oVirt, могут возникать некоторые моменты, по которым желательно как можно скорее получить квалифицированную помощь, а не разбираться с ними самостоятельно.

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

Базовыми для понимания статьи и принципов работы кластера oVirt, являются эти руководящие документы:

• oVirt Installation Guide
• oVirt Self-Hosted Engine Guide
• oVirt Administration Guide
  

Объём там не очень большой, за час-два вполне можно осилить основные принципы, а для любителей подробностей рекомендуется почитать Product Documentation for Red Hat Virtualization 4.3 — RHEV и oVirt по сути одно и тоже.

Итак, если все базовые настройки на хостах, коммутаторах и СХД выполнены, переходим непосредственно к развёртыванию oVirt.

Часть 2. Установка и настройка кластера oVirt 4.3

Для удобства ориентирования, приведу по списку основные разделы в этой статье, которые поочерёдно должны быть выполнены:

1. Установка управляющего сервера oVirt
2. Создание нового датацентра
3. Создание нового кластера
4. Установка дополнительных хостов в Self-Hosted окружение
5. Создание области хранения или Storage Domains
6. Создание и настройка сетей для виртуальных машин
7. Создание установочного образа для развёртывания виртуальной машины
8. Создание виртуальной машины

Установка управляющего сервера oVirt

Управляющий сервер oVirt – это самый главный элемент в инфраструктуре oVirt, в виде виртуальной машины, хоста, или виртуального устройства, управляющего всей инфраструктурой oVirt.

Его близкие аналоги из мира виртуализации:

• VMware vSphere — vCenter Server
• Microsoft Hyper-V — System Center Virtual Machine Manager (VMM).

Для установки управляющего сервера oVirt, у нас имеется два варианта:

Вариант 1
Развёртывание сервера в виде специализированной ВМ или хоста.

Этот вариант вполне работает, но при условии, что такая ВМ работает независимо от кластера, т.е. не запущена на каком-либо хосте кластера в виде обычной виртуальной машины под управлением KVM.

Почему нельзя разворачивать такую ВМ на хостах кластера?

В самом начале процесса развёртывания управляющего сервера oVirt, у нас имеется дилемма — управляющую ВМ ставить нужно, но самого кластера фактически ещё нет, и поэтому что можно с ходу придумать? Правильно – установить KVM на будущий узел кластера, далее на нём создать виртуальную машину, например, с ОС CentOS и в ней развернуть oVirt engine. Это может делаться обычно из соображений полного контроля над такой ВМ, но это ошибочное намерение, потому что в таком случае, в дальнейшем 100% будут проблемы с такой управляющей ВМ:

• её нельзя будет мигрировать в консоли oVirt между хостами (узлами) кластера;
• при миграции средствами KVM через virsh migrate, эта ВМ будет недоступна к управлению из консоли oVirt.
• хосты кластера нельзя будет вывести в Maintenance mode (режим обслуживания), если мигрировать эту ВМ с хоста на хост с помощью virsh migrate.

Так что делайте всё по правилам — используйте для управляющего сервера oVirt или отдельный хост, или независимую ВМ, запущенную на нём, а лучше делайте как написано во втором варианте.

Вариант 2
Установка oVirt Engine Appliance на управляемый им же хост кластера.

Именно этот вариант будет рассмотрен далее, как более правильный и подходящий в нашем случае.
Требования к такой ВМ описаны ниже, добавлю лишь, что рекомендуется иметь минимум два хоста в инфраструктуре, на которых может быть запущена управляющая ВМ, чтобы сделать её отказоустойчивой. Здесь хотелось бы добавить, что как писал уже в комментариях в предыдущей статье, мне так и не удалось получить splitbrain на кластере oVirt из двух хостов, с возможностью запуска hosted-engine ВМ на них.

Установка oVirt Engine Appliance на первый хост кластера

Ссылка на официальную документацию — oVirt Self-Hosted Engine Guide, глава «Deploying the Self-Hosted Engine Using the Command line»

В документе указаны предварительные условия, которые должны быть выполнены перед развёртыванием hosted-engine ВМ, а также детально расписан сам процесс её установки, так что повторять его дословно нет особого смысла, поэтому акцентируем внимание не некоторых важных деталях.

• Перед началом всех действий, обязательно включаем поддержку виртуализации в настройках BIOS на хосте.
• Устанавливаем на хост пакет для установщика hosted-engine:

yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm 
yum -y install epel-release
yum install screen ovirt-hosted-engine-setup

• Запускаем на хосте процедуру развёртывания oVirt Hosted Engine в screen’е (выйти из него можно через Ctrl-A + D, закрыть через Ctrl-D):

screen
hosted-engine --deploy

При желании можно запустить установку с заранее подготовленным файлом ответов:

hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-ohe.conf

• Во время развёртывания hosted-engine, указываем все необходимые параметры:

- имя кластера
- количество vCPU и vRAM (рекомендуется 4 vCPU и 16 Гб)
- пароли
- тип хранилища для hosted engine ВМ – в нашем случае FC
- номер LUN для установки hosted engine
- где будет находиться база данных для hosted engine – рекомендую для простоты выбрать Local (это БД PostgreSQL работающая внутри этой ВМ)
и др. параметры. 

• Для установки высокодоступной ВМ с hosted engine, на СХД нами был заранее создан специальный LUN под номером 4 и размером 150 Гб, который затем был презентован хостам кластера – см. в предыдущей статье.

Ранее мы также проверяли его видимость на хостах:

multipath -ll
…
3600a098000e4b4b3000003c95d171065 dm-3 DELL    , MD38xxf
size=150G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 rdac' wp=rw
|-+- policy='service-time 0' prio=14 status=active
| `- 15:0:0:4  sdc 8:32  active ready running
`-+- policy='service-time 0' prio=9 status=enabled
  `- 18:0:0:4  sdj 8:144 active ready running

• Сам процесс развёртывания hosted-engine ничего сложного в себе не несёт, в его конце мы должны получить примерно такое сообщение:

[ INFO  ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20191129131846.conf'
[ INFO  ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Hosted Engine successfully deployed

Проверяем наличие сервисов oVirt на хосте:

Если всё было сделано правильно, то после окончания установки заходим с помощью веб-браузера на https://ovirt_hostname/ovirt-engine с компьютера администратора, и кликаем [Administration Portal].

Скриншот «Administration Portal»

Введя логин и пароль (заданные в процессе установки) в окно как на скриншоте, попадаем в панель управления Open Virtualization Manager, в которой можно производить все действия с виртуальной инфраструктурой:

1. добавлять датацентр
2. добавлять и настраивать кластер
3. добавлять хосты и управлять ими
4. добавлять области хранения или Storage Domains, для дисков виртуальных машин
5. добавлять и настраивать сети для виртуальных машин
6. добавлять виртуальные машины, установочные образы, шаблоны ВМ и управлять ими

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

Дополнение

1) В принципе, если есть такая необходимость, то ничего не мешает заранее установить гипервизор KVM на узлы кластера, используя пакеты libvirt и qemu-kvm (или qemu-kvm-ev) желаемой версии, хотя при развёртывании узла кластера oVirt, он может это сделать и сам.

Но если libvirt и qemu-kvm были установлены не самой свежей версии, то можно получить такую ошибку во время развёртывания hosted engine:

error: unsupported configuration: unknown CPU feature: md-clear

Т.е. необходимо иметь обновлённую версию libvirt с защитой от MDS, который поддерживает такую политику:

<feature policy='require' name='md-clear'/>

Устанавливаем libvirt v.4.5.0-10.el7_6.12, с поддержкой md-clear:

yum-config-manager --disable mirror.centos.org_centos-7_7_virt_x86_64_libvirt-latest_

yum install centos-release-qemu-ev
yum update
yum install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer libguestfs libguestfs-tools dejavu-lgc-sans-fonts virt-top libvirt libvirt-python libvirt-client

systemctl enable libvirtd
systemctl restart libvirtd && systemctl status libvirtd

Проверяем наличие поддержки 'md-clear':

virsh domcapabilities kvm | grep require
      <feature policy='require' name='ss'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='pku'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='invtsc'/>

После этого можно продолжать установку hosted engine.

2) В oVirt 4.3 наличие и использование файервола firewalld является обязательным требованием.

Если во время развёртывания ВМ для hosted-engine получаем такую ошибку:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld is required to be enabled and active in order to correctly deploy hosted-engine. Please check, fix accordingly and re-deploy.n"}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

То необходимо выключить другой файервол (если он используется), и установить и запустить firewalld:

yum install firewalld
systemctl enable firewalld
systemctl start firewalld

firewall-cmd --state
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --get-zones

В дальнейшем, при установке агента ovirt на новом хосте для кластера, он настроит требуемые порты в firewalld автоматически.

3) Перезагрузка хоста с работающей на нём ВМ с hosted engine.

Как обычно, ссылка 1 и ссылка 2 на руководящие документы.

Всё управление hosted engine ВМ делается ТОЛЬКО с помощью команды hosted-engine на хосте, где она работает, про virsh надо забыть, также, как и про то, что к этой ВМ можно подключиться по SSH и выполнить на ней команду «shutdown».

Процедура по выводу ВМ в режим обслуживания:

hosted-engine --set-maintenance --mode=global

hosted-engine --vm-status
!! Cluster is in GLOBAL MAINTENANCE mode !!
--== Host host1.test.local (id: 1) status ==--
conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Host timestamp                     : 1821
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sat Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sat Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Перезагружаем хост с hosted engine agent и делаем с ним что нам нужно.

После перезагрузки проверяем статус ВМ с hosted engine:

hosted-engine --vm-status

Если наша ВМ с hosted-engine не запускается и если мы видим похожие ошибки в логе сервиса:

Ошибка в журнале сервиса:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Failed to start necessary monitors
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (most recent call last):#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 131, in _run_agent#012    return action(he)#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 55, in action_proper#012    return he.start_monitoring()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 413, in start_monitoring#012    self._initialize_broker()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 537, in _initialize_broker#012    m.get('options', {}))#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - failed to start monitor via ovirt-ha-broker: [Errno 2] No such file or directory, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying to restart agent

То подключаем хранилище и перезапускаем агента:

hosted-engine --connect-storage
systemctl restart ovirt-ha-agent
systemctl status ovirt-ha-agent

hosted-engine --vm-start
hosted-engine --vm-status

После запуска ВМ с hosted-engine, выводим её из режима обслуживания:

Процедура по выводу ВМ из режима обслуживания:

hosted-engine --check-liveliness
hosted-engine --set-maintenance --mode=none
hosted-engine --vm-status

--== Host host1.test.local (id: 1) status ==--

conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : 6d1eb25f
local_conf_timestamp               : 6222296
Host timestamp                     : 6222296
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (Fri Jan 17 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (Fri Jan 17 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        stopped=False

4) Удаление hosted engine и всего с ней связанного.

Иногда бывает необходимо правильно удалить ранее установленный hosted engine — ссылка на руководящий документ.

Просто выполняем команду на хосте:

/usr/sbin/ovirt-hosted-engine-cleanup

Далее удаляем ненужные пакеты, забэкапив перед этим какие-то конфиги, если это необходимо:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Создание нового датацентра

Справочная документация — oVirt Administration Guide. Chapter 4: Data Centers

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

Датацентр — это своего рода контейнер, состоящий из:

• логических ресурсов в виде кластеров и хостов
• сетевых ресурсов кластера в виде логических сетей и физических адаптеров на хостах,
• ресурсов хранения (для дисков ВМ, шаблонов, образов) в виде областей хранения (Storage Domains).

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

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

Чтобы создать датацентр, заходим в административный портал и создаём новый датацентр:
Compute >> Data Centers >> New

Так как у нас используется общее хранилище на СХД, то тип хранилища (Storage Type) должен быть Shared:

Скриншот с мастером создания датацентра

При установке виртуальной машины с hosted-engine, по умолчанию создаётся датацентр – Datacenter1, и далее при необходимости у него можно поменять тип хранилища (Storage Type) на другой.

Создание датацентра — это несложная задача, без каких-то хитрых нюансов, и все дополнительные действия с ним описаны в документации. Единственно замечу, что одиночные хосты имеющие только локальное хранилище (диск) для ВМ, в датацентр c Storage Type — Shared попасть не смогут (нельзя будет их туда добавить), и для них нужно создавать отдельный датацентр – т.е. каждому отдельному хосту с локальным хранилищем, нужен свой отдельный датацентр.

Создание нового кластера

Ссылка на документацию — oVirt Administration Guide. Chapter 5: Clusters

Без излишних подробностей, кластер – это логическая группировка хостов, имеющих общую область хранения (в виде общих дисков на СХД, как в нашем случае). Также желательно, чтобы хосты в кластере были идентичны по железу, и имели бы одинаковый тип процессора (Intel или AMD). Лучше всего конечно, чтобы сервера в кластере были полностью одинаковыми.

Кластер входит в состав датацентра (c определённым типом хранилища — Local или Shared), а все хосты в обязательном порядке должны принадлежать какому-либо кластеру, в зависимости от того, есть ли у них общее хранилище или нет.

При установке виртуальной машины с hosted-engine на хост, по умолчанию создаётся датацентр — Datacenter1, вместе с кластером – Cluster1, и в дальнейшем можно настроить его параметры, включить дополнительные опции, добавить в него хосты и т.п.

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

Отмечу наиболее важные параметры:

• Processor type — выбирается, исходя из того, какие процессоры установлены на хостах кластера, от какого они производителя, и какой процессор на хостах самый старый, чтобы в зависимости от этого, использовать все доступные процессорные инструкции в кластере.
• Switch type – у нас в кластере используется только Linux bridge, поэтому его и выбираем.
• Firewall type – тут всё понятно, это firewalld, который должен быть включен и настроен на хостах.

Скриншот с параметрами кластера

Установка дополнительных хостов в Self-Hosted окружении

Ссылка на документацию.

Дополнительные хосты для Self-Hosted окружения, добавляются так же, как и обычный хост, с выполнением дополнительного пункта по развертыванию ВМ с hosted engine — Choose hosted engine deployment action >> Deploy. Так как дополнительному хосту тоже должен быть презентован LUN для ВМ с hosted engine, то это значит, что этот хост можно при необходимости использовать для размещения на нём ВМ с hosted engine.
В целях отказоустойчивости весьма рекомендуется, чтобы было минимум два хоста, на которых может быть размещена ВМ с hosted engine.

На дополнительном хосте отключаем iptables (если включен), включаем firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Устанавливаем требуемую версию KVM (по необходимости):

yum-config-manager --disable mirror.centos.org_centos-7_7_virt_x86_64_libvirt-latest_

yum install centos-release-qemu-ev
yum update
yum install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer libguestfs libguestfs-tools dejavu-lgc-sans-fonts virt-top libvirt libvirt-python libvirt-client

systemctl enable libvirtd
systemctl restart libvirtd && systemctl status libvirtd

virsh domcapabilities kvm | grep md-clear

Устанавливаем нужные репозитории и установщик hosted engine:

yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm
yum -y install epel-release
yum update
yum install screen ovirt-hosted-engine-setup

Далее переходим в консоль Open Virtualization Manager, добавляем новый хост, и делаем всё пошагово, как написано в документации.

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

Скриншот административного портала — хосты

Хост, на котором ВМ с hosted-engine в данный момент активна, имеет золотую корону и надпись «Running the Hosted Engine VM», хост, на котором эта ВМ может быть запущена при необходимости – надпись «Can run the Hosted Engine VM».

В случае сбоя хоста на котором «Running the Hosted Engine VM», она автоматически перезапустится на втором хосте. Также эту ВМ можно мигрировать с активного хоста на резервный, для его обслуживания.

Настройка Power Management / fencing на хостах oVirt

Ссылки на документацию:

• Red Hat Virtualization 4.3 –> Technical Reference -> Chapter 4. Power Management
• oVirt Administration Guide -> Chapter 7: Hosts

Хотя может показаться, что добавление и настройка хоста выполнены, но это не совсем так.
Для нормальной работы хостов, и выявления/устранения сбоев с кем-либо из них, необходима настройка Power Management / fencing.

Fencing, или огораживание – это процесс временного исключения неисправного или сбойного хоста из кластера, в процессе которого перезапускаются или сервисы oVirt на нём, или сам хост.

Все подробности по определениям и параметрам Power Management / fencing даны, как обычно в документации, я лишь приведу пример, как настроить этот важный параметр, в применении к серверам Dell R640 с iDRAC 9.

1. Заходим в административный портал, кликаем Compute >> Hosts выбираем хост.
2. Кликаем Edit.
3. Кликаем вкладку Power Management.
4. Отмечаем флажок напротив опции Enable Power Management.
5. Отмечаем флажок напротив опции Kdump integration, чтобы хост не перешёл в режим огораживания (fencing), во время записи аварийного дампа ядра.

Примечание.

После включения Kdump integration на уже работающем хосте, он должен быть переустановлен в соответствии с процедурой в oVirt Administration Guide -> Chapter 7: Hosts -> Reinstalling Hosts.

1. Опционально можно отметить флажок Disable policy control of power management, если мы не хотим, чтобы управления питанием хоста, контролировалось бы политикой планирования (Scheduling Policy) кластера.
2. Кликаем кнопку (+), чтобы добавить новое устройство управления питанием, откроется окно редактирования свойств агента.
   Для iDRAC9, заполняем поля:
   • Address – адрес iDRAC9
   • User Name / Password – соответственно логин и пароль для входа в iDRAC9
   • Type — drac5
   • отметить Secure
   • добавить следующие опции: cmd_prompt=>,login_timeout=30

Скриншот с параметрами «Power Management» в свойствах хоста

Создание области хранения или Storage Domains

Ссылка на документацию — oVirt Administration Guide, Chapter 8: Storage.

Storage Domain, или область хранения – это централизованное место для хранения дисков виртуальных машин, установочных образов, шаблонов и снэпшотов.

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

У oVirt имеется три типа области хранения:

• Data Domain – для хранения всех данных, связанных с виртуальными машинами (диски, шаблоны). Data Domain не может разделяться между разными датацентрами.
• ISO Domain (устаревший тип области хранения) – для хранения установочных образов ОС. ISO Domain может разделяться между разными датацентрами.
• Export Domain (устаревший тип области хранения) – для временного хранения образов, перемещаемых между датацентрами.

В нашем частном случае область хранения с типом Data Domain, использует Fibre Channel Protocol (FCP), для подключения к LUN’ам на СХД.

С точки зрения oVirt, при использовании СХД (FC или iSCSI) каждый виртуальный диск, снэпшот или шаблон — это логический диск.
Блочные устройства собираются в одно целое (на хостах кластера) с помощью Volume Group и затем разделяются с помощью LVM на логические тома, используемые как виртуальные диски для ВМ.

Все эти группы и множество томов LVM, можно увидеть на хосте кластера, с помощью команд vgs и lvs. Естественно, что все действия с такими дисками нужно делать только из консоли oVirt, кроме особых случаев.

Виртуальные диски для ВМ могут быть двух типов — QCOW2 или RAW. Диски могут быть "тонкими" или "толстыми". Снэпшоты всегда создаются как "тонкие".

Способ управления Storage domains, или областями хранения, доступ к которым осуществляется через FC, довольно логичен — для каждого виртуального диска ВМ существует отдельный логический том, который доступен для записи только одному хосту. В случае подключений через FC, oVirt использует что-то наподобие кластерного LVM.

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

Как видим из описания, кластер в oVirt, как и кластер в VMware vSphere или в Hyper-V, по сути обозначают одно и тоже – это логическая группировка хостов, желательно одинаковых по составу «железа», и имеющих общее хранилище для дисков виртуальных машин.

Перейдём непосредственно к созданию области хранения для данных (дисков ВМ), так как без неё датацентр не будет проинициализирован.
Напомню, что все презентованные хостам кластера LUN’ы на СХД, должны быть на них видны с помощью команды «multipath -ll».

Согласно документации, идём в портале заходим в Storage >> Domains -> New Domain и выполняем инструкции из раздела "Adding FCP Storage".

После запуска мастера, заполняем требуемые поля:

• Name — задаём имя кластера
• Domain Function — Data
• Storage Type — Fibre Channel
• Host to Use — выбираем хост, на котором доступен требуемый нам LUN

В списке LUN’ов отмечаем нужный нам, кликаем Add и затем ОК. При необходимости можно скорректировать дополнительные параметры области хранения, кликнув на Advanced Parameters.

Скриншот мастера по добавлению «Storage domain»

По результатам работы мастера, мы должны получить новую область хранения, а наш датацентр перейти в статус UP, или инициализирован:

Скриншоты датацентра и областей хранения в нём:

Создание и настройка сетей для виртуальных машин

Ссылка на документацию — oVirt Administration Guide, Chapter 6: Logical Networks

Networks, или сети – служат для группировки логических сетей, используемых в виртуальной инфраструктуре oVirt.

Для взаимодействия сетевого адаптера на виртуальной машине, с физическим адаптером на хосте, используются логические интерфейсы типа Linux bridge.

Для группировки и разделения трафика между сетями, на коммутаторах настроены VLAN’ы.

При создании логической сети для виртуальных машин в oVirt, ей надо обязательно назначить идентификатор, соответствующий номеру VLAN на коммутаторе, чтобы ВМ могли бы взаимодействовать друг с другом, даже если они работают на разных узлах кластера.

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

После создания ВМ с hosted-engine, помимо автоматического создания датацентра и кластера, также автоматически создалась и логическая сеть для управления нашим кластером – ovritmgmt, к которой была подключена эта ВМ.

При необходимости можно посмотреть настройки логической сети ovritmgmt и скорректировать их, но надо быть осторожным, чтобы не потерять управление инфраструктурой oVirt.

Настройки логической сети ovritmgmt

Для создания новой логической сети для обычных ВМ, в административном портале переходим в Network >> Networks >> New, и на вкладке General добавляем сеть с нужным идентификатором VLAN, а также ставим флажок напротив «VM Network», это означает что её можно использовать для назначения на ВМ.

Скриншот новой логической сети VLAN32

На вкладке Cluster, прикрепляем эту сеть к нашему кластеру Cluster1.

После этого переходим в Compute >> Hosts, по очереди заходим в каждый хост, на вкладку Network interfaces, и запускаем мастер Setup host networks, для привязки к хостам новой логической сети.

Скриншот мастера «Setup host networks»

Агент oVirt автоматически сделает все необходимые сетевые настройки на хосте – создаст VLAN и BRIDGE.

Пример конфигурационных файлов для новых сетей на хосте:

cat ifcfg-bond1
# Generated by VDSM version 4.30.17.1
DEVICE=bond1
BONDING_OPTS='mode=1 miimon=100'
MACADDR=00:50:56:82:57:52
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-bond1.432
# Generated by VDSM version 4.30.17.1
DEVICE=bond1.432
VLAN=yes
BRIDGE=ovirtvm-vlan432
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-ovirtvm-vlan432
# Generated by VDSM version 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Ещё раз напомню, что на хосте кластера НЕ НУЖНО заранее создавать руками сетевые интерфейсы ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

После добавления логической сети и проверки соединения между хостом и ВМ c hosted engine, её можно использовать в виртуальной машине.

Создание установочного образа для развёртывания виртуальной машины

Ссылка на документацию — oVirt Administration Guide, Chapter 8: Storage, раздел Uploading Images to a Data Storage Domain.

Без установочного образа ОС, не удастся установить виртуальную машину, хотя это конечно и не является проблемой, если в сети установлен, например, Cobbler с заранее созданными образами.

В нашем случае такой возможности нет, поэтому придётся самостоятельно этот образ импортировать в oVirt. Ранее, для этого требовалось создавать ISO Domain, но в новой версии oVirt он был признан устаревшим, и поэтому теперь можно загружать образы прямо в Storage domain из административного портала.

В административном портале идём в Storage >> Disks >> Upload >> Start
Добавляем наш образ ОС в виде ISO файла, в форме заполняем все поля, и кликаем кнопку "Test connection".

Скриншот мастера добавления установочного образа

Если получаем ошибку такого вида:

Unable to upload image to disk d6d8fd10-c1e0-4f2d-af15-90f8e636dadc due to a network error. Ensure that ovirt-imageio-proxy service is installed and configured and that ovirt-engine's CA certificate is registered as a trusted CA in the browser. The certificate can be fetched from https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA`

То необходимо добавить сертификат oVirt в «Доверенные корневые ЦС» (Trusted Root CA) на управляющей станции администратора, откуда пытаемся загрузить образ.

После добавления сертификата в Trusted Root CA, опять кликаем "Test connection", должны получить:

Connection to ovirt-imageio-proxy was successful.

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

В принципе, можно сделать отдельный Storage Domain с типом Data, для хранения образов и шаблонов отдельно от дисков ВМ, или даже хранить их в Storage Domain для hosted engine, но это уже на усмотрение администратора.

Скриншот с образами ISO в Storage Domain для hosted engine

Создание виртуальной машины

Ссылка на документацию:
oVirt Virtual Machine Management Guide –> Chapter 2: Installing Linux Virtual Machines
Console Clients Resources

После загрузки в oVirt установочного образа с ОС, можно переходить непосредственно к созданию виртуальной машины. Много было работы проделано, но мы уже находимся на завершающем этапе, ради чего всё это и затевалось – получение отказоустойчивой инфраструктуры для хостинга высокодоступных виртуальных машин. И причём всё это абсолютно бесплатно – ни одной копейки на приобретение каких-либо лицензий на ПО, не было потрачено.

Для создания виртуальной машины с CentOS 7, должен быть загружен установочный образ с ОС.

Заходим в административный портал, идём в Compute >> Virtual Machines, и запускаем мастер создания ВМ. Заполняем все параметры и поля, и кликаем ОК. Всё очень просто, если следовать документации.

В качестве примера, приведу основные и дополнительные настройки высокодоступной ВМ, с созданным диском, подключенную к сети, и с загрузкой с установочного образа:

Скриншоты с настройками высокодоступной ВМ

После окончания работ с мастером, закрываем его, запускаем новую ВМ и устанавливаем на неё ОС.
Для этого заходим в консоль этой ВМ через административный портал:

Скриншот настроек административного портала для подключения к консоли ВМ

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

Скриншот настроек ВМ, вкладка «Console»

Для подключения к консоли ВМ можно использовать, например, Virtual Machine Viewer.

Чтобы подключиться к консоли ВМ прямо в окне браузера, настройки подключения через консоль должны быть такими:

После установки ОС на ВМ, желательно установить oVirt guest agent:

yum -y install epel-release
yum install -y ovirt-guest-agent-common
systemctl enable ovirt-guest-agent.service && systemctl restart ovirt-guest-agent.service
systemctl status ovirt-guest-agent.service

Таким образом, в результате наших действий, созданная ВМ будет высокодоступной, т.е. в случае сбоя узла кластера, на котором она запущена, oVirt её автоматически перезапустит на втором узле. Также эту ВМ можно мигрировать между хостами кластера для их обслуживания, или других целей.

Заключение

Надеюсь, что этой статьёй удалось донести, что oVirt – вполне нормальный инструмент по управлению виртуальной инфраструктурой, который развернуть не так и сложно — главное соблюдать определённые правила и требования, описанные как в статье, так и в документации.

Из-за большого объёма статьи в неё не удалось поместить многие вещи, типа пошагового выполнения различных мастеров со всеми подробными пояснениями и скриншотами, длинные выводы каких-то команд, и т.п. На самом деле для этого потребовалось бы написать целую книгу, что не имеет особого смысла, из-за постоянно появляющихся новых версий ПО с нововведениями и изменениями. Самое главное – это понять принцип, как оно всё вместе работает, и получить общий алгоритм действий по созданию отказоустойчивой платформы по управлению виртуальными машинами.

Хотя виртуальную инфраструктуру мы создали, но теперь надо научить её взаимодействовать как между своими отдельными элементами: хостами, виртуальными машинами, внутренними сетями, так и с внешним миром.

Этот процесс является одной из основных задач системного или сетевого администратора, которая будет раскрыта в следующей статье — про использование виртуальных маршрутизаторов VyOS в отказоустойчивой инфраструктуре нашего предприятия (как вы догадались, они будут работать в виде виртуальных машин на нашем кластере oVirt).

Источник: habr.com