Стварэнне адмоваўстойлівай ІТ інфраструктуры. Частка 2. Устаноўка і настройка кластара oVirt 4.3

Гэты артыкул з'яўляецца працягам папярэдняга.Стварэнне адмоваўстойлівай ІТ інфраструктуры. Частка 1 - падрыхтоўка да разгортвання кластара oVirt 4.3.

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

Уступная частка

Асноўная мэта артыкула – не колькі выдаць пакрокавую інструкцыю відунаступны -> ды -> Заканчэнне», колькі паказаць некаторыя асаблівасці пры яго ўстаноўцы і наладзе. Працэс па разгортванні вашага кластара, не заўсёды можа супадаць з апісаным у ёй, з-за асаблівасцяў інфраструктуры і асяроддзі, але агульныя прынцыпы будуць аднолькавымі.

З суб'ектыўнага пункту гледжання, 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.
• хасты кластара нельга будзе вывесці ў Рэжым абслугоўвання (рэжым абслугоўвання), калі міграваць гэтую ВМ з хаста на хост з дапамогай virsh migrate.

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

варыянт 2
Усталёўка oVirt Engine Appliance на кіраваны ім жа хост кластара.

Менавіта гэты варыянт будзе разгледжаны далей, як больш правільны і прыдатны ў нашым выпадку.
Патрабаванні да такой ВМ апісаны ніжэй, дадам толькі, што рэкамендуецца мець мінімум два хаста ў інфраструктуры, на якіх можа быць запушчана кіруючая ВМ, каб зрабіць яе адмоваўстойлівай. Тут хацелася б дадаць, што як пісаў ужо ў каментарах у папярэднім артыкуле, мне так і не ўдалося атрымаць splitbrain на кластары oVirt з двух хастоў, з магчымасцю запуску hosted-engine ВМ на іх.

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

Спасылка на афіцыйную дакументацыю — oVirt Self-Hosted Engine Guide, кіраўнік «Deploying the Self-Hosted Engine З дапамогай 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 на вузлы кластара, выкарыстаючы пакеты. лібвірт и кэму-квм (Або qemu-kvm-ev) жаданай версіі, хоць пры разгортванні вузла кластара oVirt, ён можа гэта зрабіць і сам.

але калі лібвірт и кэму-квм былі ўсталяваныя не самай свежай версіі, то можна атрымаць такую ​​памылку падчас разгортвання hosted engine:

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

Г.зн. неабходна мець абноўленую версію лібвірт з абаронай ад МДС, які падтрымлівае такую ​​палітыку:

<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 на хасце, дзе яна працуе, пра вірш трэба забыцца, таксама, як і пра тое, што да гэтай ВМ можна падлучыцца па SSH і выканаць на ёй каманду.выключэнне.

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

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 маецца падзел паўнамоцтваў па ролях, і можна наладзіць дазволы персанальна, як на ўзроўні датацэнтра, так і на яго асобныя лагічныя элементы.

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

Каб стварыць датацэнтр, заходзім у адміністрацыйны партал і ствараем новы датацэнтр:
Вылічыць >> цэнтры апрацоўкі дадзеных >> новы

Бо ў нас выкарыстоўваецца агульнае сховішча на СХД, то тып сховішчы (Storage Type) павінен быць Shared:

Скрыншот з майстрам стварэння датацэнтра

Пры ўсталёўцы віртуальнай машыны з hosted-engine, па змаўчанні ствараецца датацэнтр - Цэнтр апрацоўкі дадзеных 1, і далей пры неабходнасці ў яго можна памяняць тып сховішчы (Storage Type) на іншы.

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

Стварэнне новага кластара

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

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

Кластар уваходзіць у склад датацэнтра (з пэўным тыпам сховішча. Мясцовы або Агульныя), а ўсе хасты ў абавязковым парадку павінны належаць якому-небудзь кластару, у залежнасці ад таго, ці ёсць у іх агульнае сховішча ці не.

Пры ўсталёўцы віртуальнай машыны з hosted-engine на хост, па змаўчанні ствараецца датацэнтр Цэнтр апрацоўкі дадзеных 1, разам з кластарам – Кластар1, і ў далейшым можна наладзіць яго параметры, уключыць дадатковыя опцыі, дадаць у яго хасты і да т.п.

Як звычайна, для атрымання падрабязнасцяў аб усіх наладах кластара, пажадана звярнуцца да афіцыйнай дакументацыі. З нейкіх асаблівасцяў налады кластара, дадам толькі, што пры яго стварэнні дастаткова наладзіць толькі асноўныя параметры на ўкладцы агульны.

Адзначу найбольш важныя параметры:

• Тып працэсара - выбіраецца, зыходзячы з таго, якія працэсары ўсталяваныя на хастах кластара, ад якога яны вытворцы, і які працэсар на хастах самы стары, каб у залежнасці ад гэтага, выкарыстоўваць усе даступныя працэсарныя інструкцыі ў кластары.
• Тып перамыкача - у нас у кластары выкарыстоўваецца толькі Linux bridge, таму яго і выбіраемы.
• Firewall type - Тут усё зразумела, гэта firewalld, які павінен быць уключаны і настроены на хастах.

Скрыншот з параметрамі кластара

Ўстаноўка дадатковых хастоў у Self-Hosted асяроддзі

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

Дадатковыя хасты для Self-Hosted асяроддзі, дадаюцца гэтак жа, як і звычайны хост, з выкананнем дадатковага пункта па разгортванні ВМ з hosted engine Choose hosted engine deployment action >> разгортванне. Бо дадатковаму хасту таксама павінен быць прэзентаваны 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.

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

Усе падрабязнасці па азначэннях і параметрах Power Management / fencing дадзены, як звычайна ў дакументацыі, я толькі прывяду прыклад, як наладзіць гэты важны параметр, у прымяненні да сервераў Dell R640 з iDRAC 9.

1. Заходзім у адміністрацыйны партал, клікаем Вылічыць >> хасты выбіраемы хост.
2. Клікаем Рэдагаваць.
3. Клікаем ўкладку кіраванне энергаспажываннем.
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, запаўняем палі:
   • Адрас - адрас iDRAC9
   • Імя карыстальніка/пароль – адпаведна лагін і пароль для ўваходу ў iDRAC9
   • тып - drac5
   • адзначыць Бяспечны
   • дадаць наступныя опцыі: cmd_prompt=>,login_timeout=30

Скрыншот з параметрамі «Power Management» ва ўласцівасцях хаста

Стварэнне вобласці захоўвання ці Storage Domains

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

Storage Domain, або вобласць захоўвання - гэта цэнтралізаванае месца для захоўвання дыскаў віртуальных машын, усталявальных вобразаў, шаблонаў і снэпшотаў.

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

У oVirt ёсць тры тыпу вобласці захоўвання:

• Дамен дадзеных - для захоўвання ўсіх дадзеных, звязаных з віртуальнымі машынамі (дыскі, шаблоны). Data Domain не можа падзяляцца паміж рознымі датацэнтрамі.
• ISO Domain (састарэлы тып вобласці захоўвання) - для захоўвання ўсталявальных вобразаў АС. ISO Domain можа падзяляцца паміж рознымі датацэнтрамі.
• Export Domain (састарэлы тып вобласці захоўвання) - для часовага захоўвання выяў, якія перамяшчаюцца паміж датацэнтрамі.

У нашым прыватным выпадку вобласць захоўвання з тыпам Data Domain, выкарыстоўвае Fibre Channel Protocol (FCP), для падлучэння да LUN'ам на СХД.

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

Усе гэтыя групы і мноства тамоў LVM, можна ўбачыць на хасце кластара, з дапамогай каманд г.д и лв. Натуральна, што ўсе дзеянні з такімі кружэлкамі трэба рабіць толькі з кансолі oVirt, акрамя адмысловых выпадкаў.

Віртуальныя дыскі для ВМ могуць быць двух тыпаў - QCOW2 або RAW. Дыскі могуць быць "тонкімі"або"тоўстымі". Снэпшоты заўсёды ствараюцца як "тонкія".

Спосаб кіравання Storage domains, ці абласцямі захоўвання, доступ да якіх ажыццяўляецца праз FC, даволі лагічны – для кожнага віртуальнага дыска ВМ існуе асобны лагічны том, які даступны для запісу толькі аднаму хасту. У выпадку падлучэнняў праз FC, oVirt выкарыстоўвае нешта накшталт кластарнага LVM.

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

Як бачны з апісання, кластар у oVirt, як і кластар у VMware vSphere або ў Hyper-V, у сутнасці пазначаюць адно і тое ж - гэта лагічная групоўка хастоў, пажадана аднолькавых па складзе "жалеза", і якія маюць агульнае сховішча для дыскаў віртуальных машын.

Пяройдзем непасрэдна да стварэння вобласці захоўвання для дадзеных (дыскаў ВМ), так як без яе датацэнтр не будзе праініцыялізаваны.
Нагадаю, што ўсе прэзентаваныя хастам кластара LUN'ы на СХД павінны быць на іх бачныя з дапамогай каманды.multipath -ll.

Згодна з дакументацыі, ідзем у партале заходзім у захоўванне >> дамены -> Новы дамен і выконваем інструкцыі з падзелу "Adding FCP Storage".

Пасля запуску майстра, запаўняем патрабаваныя палі:

• Імя - задаём імя кластара
• Domain Function - Data
• Тып захоўвання - Fibre Channel
• Host to Use - выбіраемы хост, на якім даступны патрабаваны нам LUN

У спісе LUN'аў адзначаем патрэбны нам, клікаем Дадаваць і затым ОК. Пры неабходнасці можна скарэктаваць дадатковыя параметры вобласці захоўвання, клікнуўшы на Пашыраныя параметры.

Скрыншот майстра па даданні «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

Для стварэння новай лагічнай сеткі для звычайных ВМ, у адміністрацыйным партале пераходзім у сетка >> Сеткі >> новы, і на ўкладцы агульны дадаем сетку з патрэбным ідэнтыфікатарам VLAN, а таксама ставім сцяжок насупраць.VM Network», гэта азначае, што яе можна выкарыстоўваць для прызначэння на ВМ.

Скрыншот новай лагічнай сеткі VLAN32

на ўкладцы Кластар, прымацоўваем гэтую сетку да нашага кластара Кластар1.

Пасля гэтага пераходзім у Вылічыць >> хасты, па чарзе заходзім у кожны хост, на ўкладку Сеткавыя інтэрфейсы, і запускаем майстар 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.

Пасля дадання лагічнай сеткі і праверкі злучэння паміж хастом і ВМ з hosted engine, яе можна выкарыстоўваць у віртуальнай машыне.

Стварэнне ўсталявальнай выявы для разгортвання віртуальнай машыны

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

Без усталявальнай выявы АС, не атрымаецца ўсталяваць віртуальную машыну, хоць гэта вядома і не з'яўляецца праблемай, калі ў сетцы ўсталяваны, напрыклад, Шавец з загадзя створанымі выявамі.

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

У адміністрацыйным партале ідзем у захоўванне >> дыскі >> Загружаць >> дома
Дадаем нашу выяву АС у выглядзе 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 у 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, павінен быць загружаны ўсталявальная выява з АС.

Заходзім у адміністрацыйны партал, ідзем у Вылічыць >> віртуальныя машыны, і запускаем майстар стварэння ВМ. Запаўняем усе параметры і палі, і клікаем ОК. Усё вельмі проста, калі прытрымлівацца дакументацыі.

У якасці прыкладу, прывяду асноўныя і дадатковыя налады высокадаступнай ВМ, са створаным дыскам, падлучаную да сеткі, і з загрузкай з усталявальнай выявы:

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

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

Скрыншот настроек адміністрацыйнага партала для падлучэння да кансолі ВМ

Каб падлучыцца да кансолі ВМ, папярэдне трэба наладзіць кансоль ва ўласцівасцях віртуальнай машыны.

Скрыншот налад ВМ, укладка «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