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

Тази статия е продължение на предишната – «Създаване на отказоустойчив IT инфраструктура. Част 1 – подготовка за разгръщане на кластера oVirt 4.3».

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

Въведителна част

Основната цел на статията е не толкова да предостави стъпка по стъпка инструкция типа «Next -> Да -> Завърши», колкото да покаже някои особености при нейната инсталация и конфигурация. Процесът на разгръщане на вашия кластер не винаги може да съвпада с описаното в нея, поради особеностите на инфраструктурата и средата, но основните принципи ще бъдат идентични.

От субективна гледна точка, oVirt 4.3 по своя функционал е подобен на VMware vSphere версия 5.x, но разбира се с неговите особености в настройката и работата.

За тези, които се интересуват, всички разлики между 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. Това обикновено се прави от съображения за пълен контрол върху такава ВМ, но това е погрешно намерение, защото в такъв случай в бъдеще със сигурност ще възникнат проблеми с тази управляваща ВМ:

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

Така че правете всичко по правилата — използвайте за управляващия сървър oVirt или отделен хост, или независима ВМ, стартирана на него, а още по-добре направете както е написано във втория вариант.

Вариант 2
Инсталация на oVirt Engine Appliance на управлявания от него хост на клъстера.

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

Инсталация на oVirt Engine Appliance на първия хост на клъстера

Връзка към официалната документация — oVirt Self-Hosted Engine Guide, глава „Разгръщане на самостоятелно хоствана машина, използвайки командния ред»

В документа са посочени предварителните условия, които трябва да бъдат изпълнени преди разгръщането на 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 GB)
- пароли
- тип хранилище за виртуалната машина на hosted engine – в нашия случай FC
- номер на LUN за инсталация на hosted engine
- къде ще се намира базата данни за hosted engine – препоръчвам за улеснение да изберете Local (това е PostgreSQL база данни, работеща вътре в тази ВМ)
и др. параметри. 

• За инсталирането на високо налична виртуална машина с hosted engine, в СХД преди това бе създаден специален LUN с номер 4 и размер 150 GB, който след това бе предоставен на хостовете в клъстера – вижте в предишната статия.

По-рано също проверихме видимостта му на хостовете:

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  ] Генериране на файл с отговори '/var/lib/ovirt-hosted-engine-setup/answers/answers-20191129131846.conf'
[ INFO  ] Генериране на файл с отговори '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Етап: Предварително приключване
[ INFO  ] Етап: Приключване
[ INFO  ] Hosted Engine успешно разгръщен

Проверяваме наличието на 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

След това може да продължите с инсталацията на 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
!! Клъстерът е в режим на ГЛОБАЛНА ПОДДРЪЖКА !!
--== Хост host1.test.local (id: 1) статус ==--
conf_on_shared_storage             : True
Статус актуален                  : True
Име на хоста                     : host1.test.local
ID на хоста                       : 1
Статус на двигателя               : {"health": "good", "vm": "up", "detail": "Up"}
Рейтинг                           : 3400
спрян                             : False
Локална поддръжка                 : False
crc32                             : dee1a774
local_conf_timestamp              : 1821
Хостов времеви печат             : 1821
Допълнителни метаданни (валидни на времевия печат):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Съб Ное 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Съб Ное 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
...
Юни 29 14:34:44 host1 журнал: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Неуспешно стартиране на необходимите монитори
Юни 29 14:34:44 host1 журнал: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Стек следствие (най-ново извикване последно):#012  Файл "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", ред 131, в _run_agent#012    return action(he)#012  Файл "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", ред 55, в action_proper#012    return he.start_monitoring()#012  Файл "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", ред 413, в start_monitoring#012    self._initialize_broker()#012  Файл "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", ред 537, в _initialize_broker#012    m.get('options', {}))#012  Файл "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", ред 86, в start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - неуспешно стартиране на монитор чрез ovirt-ha-broker: [Errno 2] Няма такъв файл или директория, [монитор: 'ping', options: {'addr': '172.20.32.32'}]
Юни 29 14:34:44 host1 журнал: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Опит за рестартиране на агента

Свързваме хранилището и рестартираме агента:

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. Глава 4: Дата центрове

Първо да определим какво е дата център (цитирам от справката) — това е логическа структура, която определя набор от ресурси, използвани в специфична среда.

Дата центърът е вид контейнер, състоящ се от:

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

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

Дата центърът или дата центровете, ако са повече от един, се управляват от единна административна конзола или портал.

За да създадете дата център, влезте в административния портал и създайте нов дата център:
Изчисление >> Дата Центрове >> Нов

Тъй като използваме общо хранилище на СХД, типът хранилище (Storage Type) трябва да бъде Shared:

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

Когато инсталирате виртуална машина с hosted-engine, по подразбиране се създава датацентър – Datacenter1, и при необходимост можете да промените типа на хранилището (Storage Type) на друг.

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

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

Линк към документацията – oVirt Administration Guide. Глава 5: Кластери

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

Клъстерът е част от датацентъра (с определен тип хранилище – Local или Shared), а всички хостове задължително трябва да принадлежат на някакъв клъстер, в зависимост от това дали имат общо хранилище или не.

Когато инсталирате виртуална машина с hosted-engine на хост, по подразбиране се създава датацентър – Datacenter1, заедно с клъстера – Cluster1, и по-късно можете да настроите параметрите му, да активирате допълнителни опции, да добавите хостове и т.н.

Както обикновено, за да получите подробности за всички настройки на клъстера, е желательно да се обърнете към официалната документация. От особеностите на настройката на клъстера бих добавил само, че при създаването му е достатъчно да настроите само основните параметри на раздела General.

Набелязвам най-важните параметри:

• Тип на процесора — избира се в зависимост от това, какви процесори са инсталирани на хостовете в клъстера, от кой производител са, и кой процесор на хостовете е най-старият, за да се използват всички налични инструкции за процесора в клъстера.
• Тип на комутатора – в нашия клъстер се използва само Linux bridge, затова го избираме.
• Тип на защитната стена – тук всичко е ясно, това е firewalld, който трябва да бъде включен и настроен на хостовете.

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

Инсталиране на допълнителни хостове в Self-Hosted среда

Линк в документацията.

Допълнителните хостове за Self-Hosted среда се добавят по същия начин, както обикновен хост, с изпълнение на допълнителна стъпка за разгръщане на ВМ с hosted engine — Изберете действие за разгръщане на hosted engine >> Разгърни. Тъй като на допълнителния хост също трябва да се предостави 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 в момента е активен, има златна корона и надпис "Работеща ВМ на Hosted Engine", хостът, на който тази ВМ може да бъде стартирана при необходимост – надпис "Може да стартира ВМ на Hosted Engine».

В случай на срив на хостът, на който "Работеща ВМ на Hosted Engine", той автоматично ще се рестартира на втория хост. Освен това, тази ВМ може да бъде мигрирана от активния хост на резервния за обслужване.

Настройка на управление на енергията / fencing на хостовете oVirt

Връзки към документацията:

• Red Hat Virtualization 4.3 –> Техническа справка -> Глава 4. Управа на енергията
• Ръководство на oVirt -> Глава 7: Хостове

Въпреки че може да изглежда, че добавянето и настройването на хоста са изпълнени, не е точно така.
За нормална работа на хостовете и за открие/устранение на неуспехи с някой от тях е необходима настройка на управление на енергията / fencing.

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

Всички подробности по определенията и параметрите на Power Management / ограждане са предоставени, както обикновено в документацията, като ще дам пример как да настроим този важен параметър, приложен към сървърите Dell R640 с iDRAC 9.

1. Влизаме в административния портал, кликваме Изчисление >> Hosts избираме хост.
2. Кликваме Edit.
3. Кликваме на таба Power Management.
4. Отбелязваме отметката до опцията Enable Power Management.
5. Отбелязваме отметката до опцията Kdump интеграция, за да не премине хостът в режим на ограждане (fencing) по време на запис на аварийния дъмп на ядрото.

Бележка.

След включване на Kdump интеграцията на вече работещ хост, той трябва да бъде преинсталиран в съответствие с процедурата в oVirt Administration Guide -> Глава 7: Хостове -> 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, Глава 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».

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

След стартиране на майстора, попълваме необходимите полета:

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

В списъка с LUN’ове отбелязваме нужния, кликваме Добави и след това ОК. При необходимост можем да коригираме допълнителните параметри на областта на съхранение, като кликнем на Advanced Parameters.

Скриншотът на майстора по добавяне на "Storage domain"

След резултатите от работата на майстора, трябва да получим нова област на съхранение, а нашият датацентър да премине в статус UP, или инициализиран:

Екранни снимки на дата център и области за съхранение в него:

Създаване и настройка на мрежи за виртуални машини

Връзка към документацията — oVirt Administration Guide, Глава 6: Логически мрежи

Мрежите служат за групиране на логически мрежи, използвани във виртуалната инфраструктура oVirt.

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

За групиране и разделяне на трафика между мрежите, на комутаторите са настроени VLAN-и.

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

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

След създаването на ВМ с hosted-engine, освен автоматичното създаване на дата център и клъстер, автоматично е създадена и логическа мрежа за управление на нашия клъстер – ovritmgmt, към която е свързана тази ВМ.

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

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

За създаване на нова логическа мрежа за обикновени ВМ, в административния портал преминаваме в Мрежа >> Networks >> Нов, и на таба General добавяме мрежа с нужния идентификатор VLAN и също поставяме отметка до «VM Network», което означава, че може да се използва за назначаване на ВМ.

Екранен снимка на новата логическа мрежа VLAN32

На таба Cluster, прикрепваме тази мрежа към нашия клъстер Cluster1.

След това преминаваме в Изчисление >> Hosts, последователно влизаме във всеки хост, на таба Network interfaces, и стартираме магьосника Setup host networks, за връзка на хостовете с новата логическа мрежа.

Екранна снимка на магьосника «Setup host networks»

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

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

cat ifcfg-bond1
# Генерирано от VDSM версия 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
# Генерирано от VDSM версия 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
# Генерирано от VDSM версия 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.

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

Създаване на инсталационен образ за разгръщане на виртуална машина

Връзка към документацията — oVirt Administration Guide, Глава 8: Storage, раздел Uploading Images to a Data Storage Domain.

Без инсталационен образ на ОС, не може да се инсталира виртуална машина, въпреки че това, разбира се, не е проблем, ако в мрежата е инсталиран, например, Cobbler с предварително създадени образи.

В нашия случай такава възможност няма, затова ще трябва сами да импортираме този образ в oVirt. По-рано, за това се изискваше да се създаде ISO Domain, но в новата версия на oVirt той беше признат за остарял, затова сега може да се качват образи директно в Storage domain от административния портал.

В административния портал отиваме в Хранилище >> 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 –> Глава 2: Инсталиране на Linux виртуални машини
Консултантски ресурси

След като заредите инсталационния образ на операционната система в oVirt, може да преминете директно към създаването на виртуалната машина. Много работа е свършена, но вече сме в заключителния етап, заради който всичко това беше направено – създаване на отказоустойчива инфраструктура за хостинг на високодостъпни виртуални машини. И всичко това е напълно безплатно – нито един цент е похарчен за закупуване на лицензи за софтуер.

За създаването на виртуална машина с CentOS 7, трябва да бъде зареден инсталационен образ с операционната система.

Влизаме в административния портал, отиваме в Изчисление >> 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