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

Тази статия е продължение на предишната - “Създаване на отказоустойчива ИТ инфраструктура. Част 1 - Подготовка за внедряване на клъстер oVirt 4.3".

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

продром

Основната цел на статията е да предостави инструкции стъпка по стъпка като „Напред -> Да -> завършеност"как да покажа някои функции, когато го инсталирате и конфигурирате. Процесът на внедряване на вашия клъстер може да не съвпада винаги с описания в него, поради характеристиките на инфраструктурата и средата, но общите принципи ще бъдат същите.

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

За тези, които се интересуват, всички разлики между RHEV (известен още като oVirt) и VMware vSphere могат да бъдат намерени в интернет, напр. тук, но все пак от време на време ще отбелязвам някои от техните разлики или прилики помежду си, докато статията напредва.

Отделно бих искал да сравня малко работата с мрежи за виртуални машини. oVirt прилага подобен принцип на мрежово управление за виртуални машини (наричани по-нататък VM), както във VMware vSphere:

• използвайки стандартен Linux мост (във VMware - Стандартен vSwitch), работещ на хостове за виртуализация;
• с помощта на Open vSwitch (OVS) (във VMware - Разпределен vSwitch) е разпределен виртуален комутатор, състоящ се от два основни компонента: централен OVN сървър и OVN контролери на управлявани хостове.

Трябва да се отбележи, че поради лекотата на внедряване, статията ще опише настройването на мрежи в oVirt за VM, използвайки стандартен Linux мост, който е стандартният избор при използване на KVM хипервайзор.

В тази връзка има няколко основни правила за работа с мрежата в клъстер, които е най-добре да не се нарушават:

• Всички мрежови настройки на хостовете, преди да ги добавите към oVirt, трябва да бъдат идентични, с изключение на IP адресите.
• След като даден хост е взет под контрола на oVirt, силно не се препоръчва да променяте нищо ръчно в мрежовите настройки без пълна увереност в действията си, тъй като агентът на oVirt просто ще ги върне към предишните след рестартиране на хоста или агент.
• Добавянето на нова мрежа за VM, както и работата с нея, трябва да стават само от конзолата за управление на oVirt.

Друг важна забележка — за много критична среда (много чувствителна към парични загуби), все пак би било препоръчително да използвате платена поддръжка и да използвате Виртуализация на Red Hat 4.3. По време на работата на клъстера oVirt могат да възникнат някои проблеми, за които е препоръчително да получите квалифицирана помощ възможно най-скоро, вместо да се справяте сами с тях.

И накрая препоръчва се Преди да разположите клъстер oVirt, запознайте се с официална документация, за да сте наясно поне с основните понятия и дефиниции, иначе ще ви е малко трудно да прочетете останалата част от статията.

Основни за разбирането на статията и принципите на работа на клъстера oVirt са тези насоки:

• oVirt Ръководство за инсталиране
• oVirt Self-Hosted Engine Guide
• Ръководство за администриране на oVirt
  

Обемът там не е много голям, за час-два можете напълно да овладеете основните принципи, но за тези, които обичат подробностите, се препоръчва да прочетете Продуктова документация за виртуализация на Red Hat 4.3 — RHEV и oVirt са по същество едно и също нещо.

И така, ако всички основни настройки на хостовете, комутаторите и системите за съхранение са завършени, преминаваме директно към внедряването на oVirt.

Част 2. Инсталиране и конфигуриране на клъстера oVirt 4.3

За по-лесна ориентация ще изброя основните раздели в тази статия, които трябва да бъдат попълнени един по един:

1. Инсталиране на сървъра за управление oVirt
2. Създаване на нов център за данни
3. Създаване на нов клъстер
4. Инсталиране на допълнителни хостове в Self-Hosted среда
5. Създаване на област за съхранение или домейни за съхранение
6. Създаване и конфигуриране на мрежи за виртуални машини
7. Създаване на инсталационен образ за внедряване на виртуална машина
8. Създайте виртуална машина

Инсталиране на сървъра за управление oVirt

oVirt сървър за управление - това е най-важният елемент в инфраструктурата на oVirt, под формата на виртуална машина, хост или виртуално устройство, което управлява цялата инфраструктура на oVirt.

Неговите близки аналози от света на виртуализацията са:

• VMware vSphere - vCenter сървър
• Microsoft Hyper-V - System Center Virtual Machine Manager (VMM).

За да инсталираме сървъра за управление на oVirt, имаме две възможности:

Опция 1
Разполагане на сървър под формата на специализирана виртуална машина или хост.

Тази опция работи доста добре, но при условие, че такава VM работи независимо от клъстера, т.е. не работи на нито един клъстерен хост като обикновена виртуална машина, работеща с KVM.

Защо такава виртуална машина не може да бъде внедрена на клъстерни хостове?

В самото начало на процеса на внедряване на сървъра за управление на oVirt имаме дилема - трябва да инсталираме виртуална машина за управление, но всъщност все още няма самия клъстер и следователно какво можем да измислим в движение? Точно така - инсталирайте KVM на бъдещ клъстерен възел, след това създайте виртуална машина върху него, например с CentOS OS и разположете двигателя oVirt в него. Това обикновено може да се направи от съображения за пълен контрол над такава VM, но това е погрешно намерение, защото в този случай в бъдеще 100% ще има проблеми с такава контролна VM:

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

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

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

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

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

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

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

• Преди да започнете всички действия, не забравяйте да активирате поддръжката за виртуализация в настройките на BIOS на хоста.
• Инсталирайте пакета за инсталатора на хоствана машина на хоста:

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 в екрана на хоста (можете да излезете от него чрез 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 работающая внутри этой ВМ)
и др. параметры. 

• За да инсталираме виртуална машина с висока достъпност с хостван двигател, преди това създадохме специален 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  ] 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 от компютъра на администратора и щракнете върху [Административен портал].

Екранна снимка на „Портал за администриране“

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

1. добавете център за данни
2. добавяне и конфигуриране на клъстер
3. добавяне и управление на хостове
4. добавете области за съхранение или домейни за съхранение за дискове на виртуална машина
5. добавяне и конфигуриране на мрежи за виртуални машини
6. добавяне и управление на виртуални машини, инсталационни изображения, VM шаблони

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

Допълнение

1) По принцип, ако има такава необходимост, тогава нищо не ви пречи да инсталирате KVM хипервайзора на клъстерни възли предварително с помощта на пакети libvirt и qemu-kvm (Or qemu-kvm-ev) на желаната версия, въпреки че при разполагане на oVirt клъстерен възел, той може да направи това сам.

Но ако libvirt и qemu-kvm Ако не сте инсталирали най-новата версия, може да получите следната грешка при внедряване на хоствана машина:

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'/>

След това можете да продължите с инсталирането на хоствания двигател.

2) В oVirt 4.3, наличието и използването на защитна стена firewalld е задължително изискване.

Ако по време на внедряване на VM за хоствана машина получим следната грешка:

[ 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) Рестартиране на хост с работеща на него виртуална машина с хостван двигател.

Обикновено, Връзка 1 и Връзка 2 към управляващите документи.

Цялото управление на хостваната машина VM се извършва САМО с помощта на командата hosted-engine на хоста, където работи, около вирш трябва да забравим, както и факта, че можете да се свържете с тази виртуална машина чрез SSH и да изпълните командата “изключване".

Процедура за поставяне на VM в режим на поддръжка:

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

Рестартираме хоста с хоствания агент на двигателя и правим каквото трябва с него.

След рестартирането проверете състоянието на VM с хоствания двигател:

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

След като стартираме VM с hosted-engine, ние го извеждаме от режим на поддръжка:

Процедура за премахване на VM от режим на поддръжка:

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) Премахване на хоствания двигател и всичко свързано с него.

Понякога е необходимо да премахнете правилно предварително инсталиран хостван двигател - връзка към документа за ръководство.

Просто изпълнете командата на хоста:

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

След това премахваме ненужните пакети, като архивираме някои конфигурации преди това, ако е необходимо:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

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

Справочна документация - oVirt Administration Guide. Глава 4: Центрове за данни

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

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

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

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

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

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

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

Екранна снимка на съветника за създаване на център за данни

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

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

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

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

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

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

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

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

Ще отбележа най-важните параметри:

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

Екранна снимка с параметри на клъстера

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

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

Допълнителни хостове за Self-Hosted среда се добавят по същия начин като обикновен хост, с допълнителната стъпка за внедряване на VM с хоствана машина - Изберете действие за внедряване на хоствана машина >> Разполагане. Тъй като допълнителният хост също трябва да бъде представен с LUN за VM с хостван двигател, това означава, че този хост може, ако е необходимо, да се използва за хостване на VM с хостван двигател на него.
За целите на толерантността към грешки е силно препоръчително да има поне два хоста, на които може да бъде поставена виртуална машина с хостван двигател.

На допълнителния хост деактивирайте iptables (ако е активиран), активирайте защитната стена

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

Инсталирайте необходимите хранилища и хоствания инсталатор на двигателя:

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

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

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

Екранна снимка на административния портал - хостове

Хостът, на който хостваната машина VM е активна в момента, има златна корона и надпис „Стартиране на хоствана машина VM", хостът, на който може да се стартира тази VM, ако е необходимо - надписът "Може да стартира Hosted Engine VM".

В случай на повреда на хост, на който "Стартиране на хоствана машина VM“, той автоматично ще се рестартира на втория хост. Тази виртуална машина може също да бъде мигрирана от активния хост към резервния хост за нейната поддръжка.

Настройка на управление на захранването / фехтовка на oVirt хостове

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

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

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

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

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

1. Отидете на административния портал, щракнете Изчисление >> Силите изберете хост.
2. Щракваме редактирам.
3. Щракнете върху раздела Управление на захранването.
4. Поставете отметка в квадратчето до опцията Активирайте управлението на захранването.
5. Поставете отметка в квадратчето до опцията Kdump интеграцияза да попречи на хоста да премине в режим на защита, докато записва дъмп на срив на ядрото.

Забележка.

След активиране на интегрирането на Kdump на вече работещ хост, той трябва да бъде преинсталиран съгласно процедурата в oVirt Administration Guide -> Глава 7: Домакини -> Преинсталиране на хостове.

1. По желание можете да поставите отметка в квадратчето Деактивирайте контрола на правилата за управление на захранването, ако не искаме управлението на мощността на хоста да се контролира от политиката за планиране на клъстера.
2. Щракнете върху бутона (+), за да добавите ново устройство за управление на захранването, ще се отвори прозорецът за редактиране на свойствата на агента.
   За iDRAC9 попълнете полетата:
   • Адрес – iDRAC9 адрес
   • Потребителско име / Парола – съответно логин и парола за влизане в iDRAC9
   • Тип -drac5
   • марка Закрепете
   • добавете следните опции: cmd_prompt=>,login_timeout=30

Екранна снимка с параметри „Управление на захранването“ в свойствата на хоста

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

Връзка към документация - oVirt Administration Guide, Глава 8: Съхранение.

Домейн за съхранение, или зона за съхранение, е централизирано място за съхранение на дискове на виртуални машини, инсталационни изображения, шаблони и моментни снимки.

Зоните за съхранение могат да бъдат свързани към центъра за данни с помощта на различни протоколи, клъстерни и мрежови файлови системи.

oVirt има три вида складова площ:

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

В нашия конкретен случай област за съхранение с тип Data Domain използва протокол за Fibre Channel (FCP), за да се свърже с LUN на системата за съхранение.

От гледна точка на oVirt, когато се използват системи за съхранение (FC или iSCSI), всеки виртуален диск, снимка или шаблон е логически диск.
Блоковите устройства се сглобяват в едно цяло (на клъстерни хостове) с помощта на Volume Group и след това се разделят с помощта на LVM на логически томове, които се използват като виртуални дискове за VM.

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

Виртуалните дискове за виртуални машини могат да бъдат два вида - QCOW2 или RAW. Дисковете може да са "тънък" или "дебел". Моментните снимки винаги се създават като "тънък".

Начинът за управление на домейни за съхранение или области за съхранение, достъпни през FC, е съвсем логичен - за всеки VM виртуален диск има отделен логически том, който може да се записва само от един хост. За FC връзки oVirt използва нещо като клъстерен LVM.

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

Както можем да видим от описанието, клъстер в oVirt, подобно на клъстер във VMware vSphere или Hyper-V, по същество означава едно и също нещо - това е логическо групиране на хостове, за предпочитане идентични по хардуерен състав и имащи общо хранилище за виртуално машинни дискове.

Нека да продължим директно към създаването на зона за съхранение на данни (VM дискове), тъй като без нея центърът за данни няма да бъде инициализиран.
Позволете ми да ви напомня, че всички LUN, представени на хостовете на клъстера в системата за съхранение, трябва да бъдат видими на тях с помощта на командата „многопътен -ll".

Според документация, отидете на портала отидете на Съхранение >> Домейни -> Нов домейн и следвайте инструкциите от раздела „Добавяне на FCP хранилище“.

След като стартирате съветника, попълнете задължителните полета:

• Име — задайте името на клъстера
• Функция на домейна -Данни
• Тип съхранение - Fibre Channel
• Хост за използване — изберете хост, на който LUN, от който се нуждаем, е наличен

В списъка с LUN маркирайте този, от който се нуждаем, щракнете върху Добави и тогава ОК. Ако е необходимо, можете да коригирате допълнителни параметри на зоната за съхранение, като щракнете върху Разширени параметри.

Екранна снимка на съветника за добавяне на „домейн за съхранение“

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

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

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

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

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

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

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

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

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

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

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

Логически мрежови настройки ovritmgmt

За да създадете нова логическа мрежа за обикновени виртуални машини, в административния портал отидете на мрежа >> Мрежи >> НОВ, и на таб Общи добавете мрежа с желания VLAN ID и също така поставете отметка в квадратчето до „VM мрежа", това означава, че може да се използва за присвояване на VM.

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

В раздела Група, прикачваме тази мрежа към нашия клъстер Клъстер 1.

След това отиваме на Изчисление >> Силите, отидете на всеки хост на свой ред, в раздела Мрежови интерфейсии стартирайте съветника Настройте хост мрежи, за обвързване с хостове на нова логическа мрежа.

Екранна снимка на съветника „Настройка на хост мрежи“.

Агентът 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-бонд1.432 и ifcfg-ovirtvm-vlan432.

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

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

Връзка към документация - oVirt Administration Guide, Глава 8: Съхранение, раздел Качване на изображения в домейн за съхранение на данни.

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

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

В административния портал отидете на Съхранение >> Дискове >> Качи >> Начало
Добавяме изображението на нашата операционна система като ISO файл, попълваме всички полета във формуляра и натискаме бутона "Тестова връзка".

Екранна снимка на съветника за добавяне на инсталационно изображение

Ако получим грешка като тази:

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, щракнете отново върху "Тестова връзка", трябва да взема:

Connection to ovirt-imageio-proxy was successful.

След като завършите действието по добавяне на сертификата, можете да опитате отново да качите ISO изображението в домейна за съхранение.

По принцип можете да създадете отделен домейн за съхранение с типа данни, за да съхранявате изображения и шаблони отделно от VM дисковете или дори да ги съхранявате в домейн за съхранение за хоствания двигател, но това е по преценка на администратора.

Екранна снимка с ISO изображения в домейн за съхранение за хоствана машина

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

Връзка към документацията:
oVirt Ръководство за управление на виртуална машина –> Глава 2: Инсталиране на Linux виртуални машини
Ресурси за конзолни клиенти

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

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

Отиваме на административния портал, отиваме на Изчисление >> Виртуални машинии стартирайте съветника за създаване на VM. Попълнете всички параметри и полета и щракнете ОК. Всичко е много просто, ако следвате документацията.

Като пример ще дам основните и допълнителните настройки на виртуална машина с висока достъпност, със създаден диск, свързан към мрежата и стартиращ от инсталационен образ:

Екранни снимки с високодостъпни VM настройки

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

Екранна снимка на настройките на административния портал за свързване към VM конзолата

За да се свържете с VM конзолата, първо трябва да конфигурирате конзолата в свойствата на виртуалната машина.

Екранна снимка на настройките на VM, раздел „Конзола“.

За да се свържете с VM конзолата, можете да използвате например Преглед на виртуална машина.

За да се свържете с VM конзолата директно в прозореца на браузъра, настройките за връзка през конзолата трябва да са както следва:

След инсталиране на операционната система на виртуалната машина е препоръчително да инсталирате oVirt гост агент:

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

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

Заключение

Надявам се, че тази статия успя да предаде, че oVirt е напълно нормален инструмент за управление на виртуална инфраструктура, който не е толкова труден за внедряване - основното е да следвате определени правила и изисквания, описани както в статията, така и в документацията.

Поради големия обем на статията не беше възможно да се включат много неща в нея, като например стъпка по стъпка изпълнение на различни съветници с всички подробни обяснения и екранни снимки, дълги заключения на някои команди и т.н. Всъщност това би изисквало написването на цяла книга, което няма особен смисъл поради постоянно появяващите се нови версии на софтуер с нововъведения и промени. Най-важното е да разберете принципа на това как работи всичко заедно и да получите общ алгоритъм за създаване на устойчива на грешки платформа за управление на виртуални машини.

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

Този процес е една от основните задачи на системния или мрежовия администратор, която ще бъде разгледана в следващата статия - за използването на VyOS виртуални рутери в устойчивата на грешки инфраструктура на нашето предприятие (както се досещате, те ще работят като виртуални машини в нашия oVirt клъстер).

Източник: www.habr.com