🥇Սխալներին հանդուրժող ՏՏ ենթակառուցվածքի ստեղծում։ Մաս 2. Տեղադրում և կարգավորում oVirt 4.3 կլաստերի

Այս հոդվածը նախորդի շարունակությունն է.Սխալներին հանդուրժող ՏՏ ենթակառուցվածքի ստեղծում: Մաս 1. oVirt 4.3 կլաստերի տեղակայման նախապատրաստում.

Այն կներառի oVirt 4.3 կլաստերի հիմնական տեղադրման և կազմաձևման գործընթացը բարձր հասանելի վիրտուալ մեքենաների հոսթինգի համար՝ հաշվի առնելով այն հանգամանքը, որ ենթակառուցվածքի պատրաստման բոլոր նախնական քայլերն արդեն ավարտվել են:

Նախաբան

Հոդվածի հիմնական նպատակն է տրամադրել քայլ առ քայլ հրահանգներ, ինչպիսիք են «հաջորդ -> այո -> Ավարտել«Ինչպես ցույց տալ որոշ առանձնահատկություններ այն տեղադրելիս և կարգավորելիս: Ձեր կլաստերի տեղակայման գործընթացը միշտ չէ, որ կարող է համընկնել դրանում նկարագրվածի հետ՝ պայմանավորված ենթակառուցվածքի և շրջակա միջավայրի բնութագրերով, սակայն ընդհանուր սկզբունքները նույնն են լինելու:

Սուբյեկտիվ տեսանկյունից. oVirt 4.3 դրա ֆունկցիոնալությունը նման է VMware vSphere 5.x տարբերակին, բայց, իհարկե, իր կոնֆիգուրացիայի և շահագործման առանձնահատկություններով:

Հետաքրքրվողների համար RHEV (aka 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 կառավարման վահանակից:

Մեկ այլ կարևոր նշում — շատ կրիտիկական միջավայրի համար (դրամական կորուստների նկատմամբ շատ զգայուն), դեռ խորհուրդ է տրվում օգտագործել վճարովի աջակցություն և օգտագործել Կարմիր գլխարկի վիրտուալացում 4.3. oVirt կլաստերի շահագործման ընթացքում կարող են առաջանալ որոշ խնդիրներ, որոնց համար խորհուրդ է տրվում որքան հնարավոր է շուտ ստանալ որակյալ օգնություն, այլ ոչ թե ինքներդ զբաղվել դրանցով:

Եվ վերջապես առաջարկվում է Նախքան oVirt կլաստերի տեղակայումը, ծանոթացեք պաշտոնական փաստաթղթեր, գոնե հիմնական հասկացություններին ու սահմանումներին տեղյակ լինելու համար, այլապես մի փոքր դժվար կլինի կարդալ հոդվածի մնացած մասը։

Հոդվածը և oVirt կլաստերի գործունեության սկզբունքները հասկանալու համար հիմք են հանդիսանում հետևյալ ուղեցույց փաստաթղթերը.

Այնտեղ ծավալը այնքան էլ մեծ չէ, մեկ-երկու ժամում կարող եք բավականին տիրապետել հիմնական սկզբունքներին, բայց նրանց, ովքեր սիրում են մանրամասներ, խորհուրդ է տրվում կարդալ. Արտադրանքի փաստաթղթեր Red Hat-ի վիրտուալիզացիայի համար 4.3 — RHEV-ը և oVirt-ը ըստ էության նույն բանն են:

Այսպիսով, եթե հոսթերի, անջատիչների և պահեստավորման համակարգերի բոլոր հիմնական կարգավորումներն ավարտված են, մենք ուղղակիորեն անցնում ենք oVirt-ի տեղակայմանը:

Մաս 2. oVirt 4.3 կլաստերի տեղադրում և կարգավորում

Կողմնորոշվելու հեշտության համար այս հոդվածում կթվարկեմ հիմնական բաժինները, որոնք պետք է լրացվեն մեկ առ մեկ.

oVirt կառավարման սերվերի տեղադրում
Նոր տվյալների կենտրոնի ստեղծում
Նոր կլաստերի ստեղծում
Լրացուցիչ հոսթերի տեղադրում Self-Hosted միջավայրում
Պահեստային տարածքի կամ Պահպանման տիրույթների ստեղծում
Վիրտուալ մեքենաների համար ցանցերի ստեղծում և կարգավորում
Վիրտուալ մեքենայի տեղակայման համար տեղադրման պատկերի ստեղծում
Ստեղծեք վիրտուալ մեքենա

oVirt կառավարման սերվերի տեղադրում

oVirt կառավարման սերվեր oVirt ենթակառուցվածքի ամենակարևոր տարրն է՝ վիրտուալ մեքենայի, հոսթի կամ վիրտուալ սարքի տեսքով, որը կառավարում է ամբողջ oVirt ենթակառուցվածքը:

Վիրտուալիզացիայի աշխարհից նրա մոտ անալոգներն են.

VMware vSphere - vCenter սերվեր
Microsoft Hyper-V - System Center Virtual Machine Manager (VMM):

oVirt կառավարման սերվերը տեղադրելու համար մենք ունենք երկու տարբերակ.

Ընտրանք 1
Սերվերի տեղակայում մասնագիտացված VM-ի կամ հոսթի տեսքով:

Այս տարբերակը բավականին լավ է աշխատում, բայց պայմանով, որ նման VM-ն աշխատում է կլաստերից անկախ, այսինքն. չի աշխատում որևէ կլաստերի հոսթի վրա որպես սովորական վիրտուալ մեքենա, որն աշխատում է KVM-ով:

Ինչու՞ նման VM-ը չի կարող տեղակայվել կլաստերային հոսթերների վրա:

oVirt կառավարման սերվերի տեղակայման գործընթացի հենց սկզբում մենք երկընտրանք ունենք՝ մենք պետք է տեղադրենք կառավարման VM, բայց իրականում ինքնին կլաստեր դեռ չկա, և, հետևաբար, ինչ կարող ենք գալ անմիջապես: Դա ճիշտ է. տեղադրեք KVM-ն ապագա կլաստերային հանգույցի վրա, այնուհետև դրա վրա ստեղծեք վիրտուալ մեքենա, օրինակ՝ CentOS OS-ով և դրա մեջ տեղակայեք oVirt շարժիչը: Սովորաբար դա կարող է արվել նման VM-ի նկատմամբ լիակատար վերահսկողության նկատառումներով, բայց դա սխալ մտադրություն է, քանի որ այս դեպքում ապագայում 100% խնդիրներ կլինեն նման հսկողության VM-ի հետ.

այն չի կարող տեղափոխվել oVirt կոնսոլում կլաստերի հոստերերի (հանգույցների) միջև.
KVM-ի միջոցով տեղափոխելիս virsh գաղթել, այս VM-ը հասանելի չի լինի oVirt վահանակի կառավարման համար:
կլաստերի հոսթերը չեն կարող ցուցադրվել Սպասարկման ռեժիմ (սպասարկման ռեժիմ), եթե դուք տեղափոխում եք այս VM-ը հոսթից հոսթ՝ օգտագործելով virsh գաղթել.

Այսպիսով, արեք ամեն ինչ ըստ կանոնների. օգտագործեք կամ առանձին հոսթ oVirt կառավարման սերվերի համար, կամ դրա վրա աշխատող անկախ VM, կամ ավելի լավ է արեք այնպես, ինչպես գրված է երկրորդ տարբերակում:

Ընտրանք 2
oVirt Engine Appliance-ի տեղադրում նրա կողմից կառավարվող կլաստերային հոսթի վրա:

Հենց այս տարբերակն էլ հետագայում կհամարվի ավելի ճիշտ և հարմար մեր դեպքում։
Նման VM-ի պահանջները նկարագրված են ստորև, ես միայն կավելացնեմ, որ ենթակառուցվածքում խորհուրդ է տրվում ունենալ առնվազն երկու հոսթ, որոնց վրա կարող է գործարկվել վերահսկիչ VM-ն, որպեսզի այն հանդուրժող լինի սխալների նկատմամբ: Այստեղ ես կցանկանայի ավելացնել, որ, ինչպես արդեն գրել էի նախորդ հոդվածի մեկնաբանություններում, ես երբեք չեմ կարողացել ստանալ պառակտված ուղեղ երկու հոսթներից բաղկացած oVirt կլաստերի վրա, որոնց վրա հոսթինգի շարժիչով VM-ներ գործարկելու ունակությամբ:

oVirt Engine Appliance-ի տեղադրում կլաստերի առաջին հոսթի վրա

Հղում դեպի պաշտոնական փաստաթղթեր - oVirt Self-Hosted Engine Guide, գլուխ»Ինքնահոսթինգային շարժիչի տեղակայում հրամանի տողի միջոցով»

Փաստաթուղթը սահմանում է այն նախադրյալները, որոնք պետք է բավարարվեն նախքան հոսթինգ շարժիչով VM-ի տեղակայումը, ինչպես նաև մանրամասն նկարագրում է բուն տեղադրման գործընթացը, ուստի իմաստ չունի բառացիորեն կրկնելը, ուստի մենք կկենտրոնանանք որոշ կարևոր մանրամասների վրա:

Նախքան բոլոր գործողությունները սկսելը, համոզվեք, որ միացրեք վիրտուալացման աջակցությունը հյուրընկալողի 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

Հոսթային շարժիչը տեղակայելիս մենք նշում ենք բոլոր անհրաժեշտ պարամետրերը.

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

Հոսթային շարժիչով բարձր հասանելի VM տեղադրելու համար մենք նախկինում ստեղծեցինք հատուկ 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

Հյուրընկալված շարժիչի տեղակայման գործընթացը ինքնին բարդ չէ, վերջում մենք պետք է ստանանք նման բան.

[ 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 կառավարման վահանակին, որտեղ կարող եք կատարել բոլոր գործողությունները վիրտուալ ենթակառուցվածքով.

ավելացնել տվյալների կենտրոն
ավելացնել և կարգավորել կլաստեր
ավելացնել և կառավարել հյուրընկալողներ
ավելացնել պահեստային տարածքներ կամ Պահպանման տիրույթներ վիրտուալ մեքենայի սկավառակների համար
ավելացնել և կարգավորել ցանցեր վիրտուալ մեքենաների համար
ավելացնել և կառավարել վիրտուալ մեքենաներ, տեղադրման պատկերներ, VM ձևանմուշներ

Այս բոլոր գործողությունները կքննարկվեն հետագա, ոմանք խոշոր բջիջներում, մյուսները ավելի մանրամասն և նրբերանգներով:
Բայց նախ խորհուրդ կտայի կարդալ այս հավելումը, որը հավանաբար շատերին օգտակար կլինի։

Լրացում

1) Սկզբունքորեն, եթե կա այդպիսի անհրաժեշտություն, ապա ոչինչ չի խանգարում ձեզ նախապես տեղադրել KVM հիպերվիզորը կլաստերի հանգույցների վրա՝ օգտագործելով փաթեթներ: գրադարան и քեմու-կվմ (Կամ qemu-kvm-ev) ցանկալի տարբերակի, չնայած oVirt կլաստերային հանգույցը տեղակայելիս այն կարող է դա անել ինքն իրեն:

Բայց եթե գրադարան и քեմու-կվմ Եթե դուք չեք տեղադրել վերջին տարբերակը, դուք կարող եք ստանալ հետևյալ սխալը հոսթինգային շարժիչը տեղակայելիս.

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

Նրանք. պետք է ունենալ թարմացված տարբերակ գրադարան պաշտպանությամբ 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-ում firewall-ի առկայությունը և օգտագործումը 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

Ապա դուք պետք է անջատեք մեկ այլ firewall (եթե այն օգտագործվում է), և տեղադրեք և գործարկեք 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) Հոսթի վերաբեռնում, որի վրա աշխատում է VM՝ հոսթինգային շարժիչով:

Ինչպես միշտ, հղում 1 и հղում 2 կարգավորող փաստաթղթերին:

Հոսթավորված շարժիչի VM-ի ամբողջ կառավարումը կատարվում է ՄԻԱՅՆ հրամանի միջոցով հյուրընկալված-շարժիչ հյուրընկալողի վրա, որտեղ այն աշխատում է, մոտ վիրշ մենք պետք է մոռանանք, ինչպես նաև այն մասին, որ դուք կարող եք միանալ այս VM-ին 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

Եթե հյուրընկալված շարժիչով մեր VM-ը չի սկսվում, և եթե մենք նմանատիպ սխալներ ենք տեսնում սպասարկման մատյանում.

Սխալ սպասարկման մատյանում.

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 --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 կառավարման ուղեցույց: Գլուխ 4. Տվյալների կենտրոններ

Նախ, եկեք սահմանենք, թե ինչ է դա տվյալների կենտրոն (Ես մեջբերում եմ օգնությունից) տրամաբանական միավոր է, որը սահմանում է որոշակի միջավայրում օգտագործվող ռեսուրսների մի շարք:

Տվյալների կենտրոնը մի տեսակ կոնտեյներ է, որը բաղկացած է.

տրամաբանական ռեսուրսներ՝ կլաստերների և հոսթների տեսքով
կլաստերային ցանցային ռեսուրսները տրամաբանական ցանցերի և հոսթների վրա ֆիզիկական ադապտերների տեսքով,
պահեստային ռեսուրսներ (VM սկավառակների, կաղապարների, պատկերների համար) պահեստային տարածքների տեսքով (Storage Domains):

Տվյալների կենտրոնը կարող է ներառել բազմաթիվ կլաստերներ, որոնք բաղկացած են բազմաթիվ հոսթներից, որոնց վրա աշխատում են վիրտուալ մեքենաներ, և այն կարող է ունենալ նաև դրա հետ կապված բազմաթիվ պահեստային տարածքներ:
Կարող են լինել մի քանի տվյալների կենտրոններ, դրանք գործում են միմյանցից անկախ: Ovirt-ն ունի լիազորությունների տարանջատում ըստ դերի, և դուք կարող եք անհատականորեն կարգավորել թույլտվությունները, ինչպես տվյալների կենտրոնի մակարդակում, այնպես էլ նրա առանձին տրամաբանական տարրերի վրա:

Տվյալների կենտրոնը կամ տվյալների կենտրոնները, եթե դրանցից մի քանիսը կան, կառավարվում են մեկ վարչական վահանակից կամ պորտալից:

Տվյալների կենտրոն ստեղծելու համար անցեք վարչական պորտալ և ստեղծեք նոր տվյալների կենտրոն.
Հաշվարկել >> տվյալների կենտրոններ >> նոր

Քանի որ մենք օգտագործում ենք ընդհանուր հիշողություն պահեստավորման համակարգում, Պահպանման տեսակը պետք է համօգտագործվի.

Data Center Creation Wizard-ի սքրինշոթը

Հոսթային շարժիչով վիրտուալ մեքենա տեղադրելիս լռելյայն ստեղծվում է տվյալների կենտրոն. Տվյալների կենտրոն 1, և այնուհետև, անհրաժեշտության դեպքում, կարող եք փոխել դրա Պահպանման տեսակը մեկ այլով:

Տվյալների կենտրոնի ստեղծումը պարզ խնդիր է, առանց որևէ բարդ նրբությունների, և դրա հետ կապված բոլոր լրացուցիչ գործողությունները նկարագրված են փաստաթղթերում: Միակ բանը, որ ես կնշեմ, այն է, որ միայնակ հոսթները, որոնք ունեն միայն տեղական պահեստավորում (սկավառակ) VM-ների համար, չեն կարողանա մուտք գործել տվյալների կենտրոն Storage Type - Համօգտագործված (դրանք այնտեղ չեն կարող ավելացվել), և նրանց համար դուք պետք է ստեղծեք առանձին տվյալների կենտրոն, այսինքն. Տեղական պահեստով յուրաքանչյուր առանձին հյուրընկալող կարիք ունի իր առանձին տվյալների կենտրոնի:

Նոր կլաստերի ստեղծում

Հղում փաստաթղթերին - oVirt կառավարման ուղեցույց: Գլուխ 5. Կլաստերներ

Առանց ավելորդ մանրամասների, կլաստեր – սա հոսթինգների տրամաբանական խմբավորում է, որոնք ունեն ընդհանուր պահեստային տարածք (համօգտագործվող սկավառակների տեսքով պահեստավորման համակարգում, ինչպես մեր դեպքում): Ցանկալի է նաև, որ կլաստերի հոսթերը լինեն նույնական ապարատային առումով և ունենան նույն տեսակի պրոցեսոր (Intel կամ AMD): Լավագույնն է, իհարկե, որ կլաստերի սերվերները լիովին նույնական լինեն:

Կլաստերը տվյալների կենտրոնի մի մասն է (պահեստավորման հատուկ տեսակով. Տեղական. կամ Հղում), և բոլոր հոսթերը պետք է պատկանեն ինչ-որ կլաստերի՝ կախված նրանից, թե արդյոք նրանք ունեն ընդհանուր պահեստ, թե ոչ։

Հոսթ-շարժիչով վիրտուալ մեքենա հոսթինգի վրա տեղադրելու ժամանակ լռելյայն ստեղծվում է տվյալների կենտրոն. Տվյալների կենտրոն 1կլաստերի հետ միասին – Կլաստեր 1, և ապագայում կարող եք կարգավորել դրա պարամետրերը, միացնել լրացուցիչ ընտրանքներ, դրան ավելացնել հոսթեր և այլն։

Ինչպես միշտ, բոլոր կլաստերի կարգավորումների մասին մանրամասների համար խորհուրդ է տրվում դիմել պաշտոնական փաստաթղթերին: Կլաստեր ստեղծելու որոշ առանձնահատկություններից ես միայն կավելացնեմ, որ այն ստեղծելիս բավական է ներդիրում կարգավորել միայն հիմնական պարամետրերը: ընդհանուր.

Նշեմ ամենակարևոր պարամետրերը.

Պրոցեսորի տեսակը — ընտրվում է՝ ելնելով այն բանից, թե որ պրոցեսորներն են տեղադրված կլաստերի հոսթինգների վրա, որ արտադրողից են դրանք, և հոսթերի որ պրոցեսորն է ամենահինը, որպեսզի, կախված դրանից, օգտագործվեն կլաստերի բոլոր հասանելի պրոցեսորների հրահանգները:
Անջատիչի տեսակը – մեր կլաստերում մենք օգտագործում ենք միայն Linux կամուրջ, այդ իսկ պատճառով մենք ընտրում ենք այն։
Firewall տեսակը – այստեղ ամեն ինչ պարզ է, սա firewalld է, որը պետք է միացված լինի և կազմաձևվի հոսթների վրա:

Կլաստերային պարամետրերով սքրինշոթ

Լրացուցիչ հոսթերի տեղադրում Self-Hosted միջավայրում

ՈՒղեցույց փաստաթղթերի համար:

Ինքնահոսթինգային միջավայրի համար լրացուցիչ հոսթեր են ավելացվում այնպես, ինչպես սովորական հոսթը՝ հոսթինգային շարժիչով VM-ի տեղադրման լրացուցիչ քայլով. Ընտրեք հյուրընկալված շարժիչի տեղակայման գործողությունը >> տեղակայել. Քանի որ լրացուցիչ հոսթին պետք է ներկայացվի նաև LUN հոսթինգ շարժիչով VM-ի համար, դա նշանակում է, որ այս հոսթինգը, անհրաժեշտության դեպքում, կարող է օգտագործվել հոսթինգ շարժիչ ունեցող VM-ի վրա:
Սխալների հանդուրժողականության նպատակներով, խորհուրդ է տրվում ունենալ առնվազն երկու հոսթ, որոնց վրա կարող է տեղադրվել հոսթինգ շարժիչ VM:

Լրացուցիչ հոսթի վրա անջատեք iptables-ը (եթե միացված է), միացրեք firewall-ը

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-ը«, այն ավտոմատ կերպով կվերագործարկվի երկրորդ հոսթում: Այս VM-ը կարող է նաև տեղափոխվել ակտիվ հոսթից սպասման հոսթ՝ դրա սպասարկման համար:

Էլեկտրաէներգիայի կառավարման / սուսերամարտի կարգավորում oVirt հոսթերում

Փաստաթղթերի հղումներ.

Red Hat Virtualization 4.3 –> Տեխնիկական տեղեկանք -> Գլուխ 4. Էներգիայի կառավարում
oVirt կառավարման ուղեցույց -> Գլուխ 7. Հյուրընկալողներ

Թեև կարող է թվալ, թե դուք ավարտել եք հոսթինգի ավելացումը և կազմաձևումը, դա ամբողջովին ճիշտ չէ:
Հոսթերի բնականոն աշխատանքի և դրանցից որևէ մեկի հետ կապված ձախողումները հայտնաբերելու/լուծելու համար պահանջվում են էներգիայի կառավարման/ցանկապատերի կարգավորումներ:

Ցանկապատում, կամ ցանկապատումը կլաստերից անսարք կամ ձախողված հոսթերի ժամանակավոր բացառման գործընթացն է, որի ընթացքում կամ դրա վրա գտնվող oVirt ծառայությունները կամ հենց ինքը հոսթերը վերագործարկվում են:

Էլեկտրաէներգիայի կառավարման / ցանկապատի սահմանումների և պարամետրերի վերաբերյալ բոլոր մանրամասները, ինչպես միշտ, տրված են փաստաթղթերում: Ես միայն օրինակ կտամ, թե ինչպես կարելի է կարգավորել այս կարևոր պարամետրը, որը կիրառվում է iDRAC 640-ով Dell R9 սերվերների վրա:

Գնացեք վարչական պորտալ, սեղմեք Հաշվարկել >> Հյուրընկալողներ ընտրել հյուրընկալող.
Սեղմել խմբագրել.
Սեղմեք ներդիրը Power Management.
Նշեք տարբերակի կողքին գտնվող վանդակը Միացնել էներգիայի կառավարումը.
Նշեք տարբերակի կողքին գտնվող վանդակը Kdump ինտեգրումթույլ չտալ, որ հյուրընկալողը չանցնի սուսերամարտի ռեժիմ՝ միջուկի վթարը գրանցելիս:

Նշում.

Արդեն գործող հոսթի վրա Kdump ինտեգրումը միացնելուց հետո այն պետք է նորից տեղադրվի oVirt Administration Guide-ի ընթացակարգի համաձայն -> Գլուխ 7. Հյուրընկալողներ -> Հոսթերի վերատեղադրում:

Ընտրովի, դուք կարող եք ստուգել վանդակը Անջատել էներգիայի կառավարման քաղաքականության վերահսկումը, եթե մենք չենք ցանկանում, որ հյուրընկալող էներգիայի կառավարումը վերահսկվի կլաստերի պլանավորման քաղաքականության կողմից:
Սեղմեք կոճակը (+) էներգիայի կառավարման նոր սարք ավելացնելու համար կբացվի գործակալի հատկությունների խմբագրման պատուհանը:
iDRAC9-ի համար լրացրեք դաշտերը.
- հասցե - iDRAC9 հասցե
- Օգտվողի անուն / գաղտնաբառ – համապատասխանաբար մուտքի և գաղտնաբառ՝ iDRAC9 մուտք գործելու համար
- Տիպ - drac5
- նշան Ապահովել
- ավելացնել հետևյալ տարբերակները. cmd_prompt=>,login_timeout=30

Սքրինշոթ՝ «Էլեկտրաէներգիայի կառավարում» պարամետրերով հյուրընկալող հատկություններում

Պահեստային տարածքի կամ Պահպանման տիրույթների ստեղծում

Հղում դեպի փաստաթղթեր - oVirt կառավարման ուղեցույց, Գլուխ 8. Պահպանում.

Պահպանման տիրույթ, կամ պահեստային տարածքը կենտրոնացված տեղ է վիրտուալ մեքենայի սկավառակների, տեղադրման պատկերների, ձևանմուշների և ակնոցների պահպանման համար:

Պահպանման տարածքները կարելի է միացնել տվյալների կենտրոնին՝ օգտագործելով տարբեր արձանագրություններ, կլաստերային և ցանցային ֆայլային համակարգեր:

oVirt-ն ունի երեք տեսակի պահեստային տարածք.

Տվյալների տիրույթ – պահել վիրտուալ մեքենաների հետ կապված բոլոր տվյալները (սկավառակներ, կաղապարներ): Տվյալների տիրույթը չի կարող համօգտագործվել տվյալների տարբեր կենտրոնների միջև:
ISO տիրույթ (պահեստային տարածքի հնացած տեսակ) – ՕՀ-ի տեղադրման պատկերները պահելու համար: ISO տիրույթը կարող է համօգտագործվել տարբեր տվյալների կենտրոնների միջև:
Արտահանել տիրույթ (պահպանման տարածքի հնացած տեսակ) – տվյալների կենտրոնների միջև տեղափոխված պատկերների ժամանակավոր պահպանման համար:

Մեր կոնկրետ դեպքում տվյալների տիրույթի տիպով պահեստային տարածքը օգտագործում է օպտիկամանրաթելային ալիքի արձանագրություն (FCP)՝ պահեստավորման համակարգի LUN-ներին միանալու համար:

oVirt-ի տեսանկյունից պահեստավորման համակարգերից օգտվելիս (FC կամ iSCSI) յուրաքանչյուր վիրտուալ սկավառակ, snapshot կամ կաղապարը տրամաբանական սկավառակ է։
Բլոկ սարքերը հավաքվում են մեկ միավորի մեջ (կլաստերի հոսթինգների վրա) Volume Group-ի միջոցով և այնուհետև LVM-ի միջոցով բաժանվում են տրամաբանական ծավալների, որոնք օգտագործվում են որպես վիրտուալ սկավառակներ VM-ների համար:

Այս բոլոր խմբերը և շատ LVM հատորներ կարելի է տեսնել կլաստերի հոսթի վրա՝ օգտագործելով հրամանները և այլն и լվ. Բնականաբար, նման սկավառակների հետ բոլոր գործողությունները պետք է կատարվեն միայն oVirt կոնսոլից, բացառությամբ հատուկ դեպքերի:

ՎՄ-ների վիրտուալ սկավառակները կարող են լինել երկու տեսակի՝ QCOW2 կամ RAW: Սկավառակները կարող են լինել «բարակ" կամ "հաստ«. Պատկերները միշտ ստեղծվում են որպես «բարակ".

Storage տիրույթները կամ FC-ի միջոցով մուտք գործած պահեստային տարածքները կառավարելու եղանակը միանգամայն տրամաբանական է. VM-ի յուրաքանչյուր վիրտուալ սկավառակի համար կա առանձին տրամաբանական ծավալ, որը կարող է գրել միայն մեկ հոսթ: FC միացումների համար oVirt-ն օգտագործում է կլաստերային LVM-ի նման մի բան:

Միևնույն պահեստային տարածքում տեղակայված վիրտուալ մեքենաները կարող են տեղափոխվել նույն կլաստերին պատկանող հոսթերների միջև:

Ինչպես տեսնում ենք նկարագրությունից, oVirt-ի կլաստերը, ինչպես VMware vSphere-ում կամ Hyper-V-ում կլաստերը, ըստ էության նշանակում է նույն բանը՝ դա հոսթինգների տրամաբանական խմբավորում է, գերադասելիորեն նույնական ապարատային կազմով և ունի ընդհանուր պահեստավորում վիրտուալ համար: մեքենայի սկավառակներ.

Եկեք ուղղակիորեն անցնենք տվյալների պահպանման տարածքի ստեղծմանը (VM սկավառակներ), քանի որ առանց դրա տվյալների կենտրոնը չի սկզբնավորվի:
Հիշեցնեմ, որ բոլոր LUN-ները, որոնք ներկայացված են պահեստավորման համակարգի կլաստերի հոսթներին, պետք է տեսանելի լինեն դրանց վրա՝ օգտագործելով « հրամանը:բազմուղի -ll.

Ըստ փաստաթղթավորում, գնալ դեպի պորտալ գնալ դեպի Պահեստ >> Domains -> Նոր տիրույթ և հետևեք «FCP պահեստի ավելացում» բաժնի հրահանգներին:

Վիզարդը գործարկելուց հետո լրացրեք պահանջվող դաշտերը.

Անուն - սահմանել կլաստերի անունը
Դոմենի գործառույթը -Տվյալներ
Պահպանման տեսակը - Օպտիկամանրաթելային ալիք
Հոսթ՝ օգտագործելու համար — ընտրեք հոսթ, որի վրա հասանելի է մեր պահանջած LUN-ը

LUN-ների ցանկում նշեք մեզ անհրաժեշտը, սեղմեք Ավելացնել եւ հետո OK. Անհրաժեշտության դեպքում կարող եք կարգավորել պահեստային տարածքի լրացուցիչ պարամետրերը՝ կտտացնելով Ընդլայնված պարամետրեր.

«Պահպանման տիրույթ» ավելացնելու հրաշագործի սքրինշոթը

Վիզարդի արդյունքների հիման վրա մենք պետք է ստանանք նոր պահեստային տարածք, և մեր տվյալների կենտրոնը պետք է տեղափոխվի կարգավիճակ: UP, կամ սկզբնավորվել՝

Տվյալների կենտրոնի և դրա մեջ պահվող տարածքների սքրինշոթները.

Վիրտուալ մեքենաների համար ցանցերի ստեղծում և կարգավորում

Հղում դեպի փաստաթղթեր - oVirt կառավարման ուղեցույց, Գլուխ 6. Տրամաբանական ցանցեր

Ցանցերը կամ ցանցերը ծառայում են oVirt վիրտուալ ենթակառուցվածքում օգտագործվող տրամաբանական ցանցերը խմբավորելու համար:

Վիրտուալ մեքենայի վրա ցանցային ադապտերի և հոսթի ֆիզիկական ադապտերի միջև փոխազդելու համար օգտագործվում են տրամաբանական միջերեսներ, ինչպիսիք են Linux կամուրջը:

Ցանցերի միջև տրաֆիկը խմբավորելու և բաժանելու համար VLAN-ները կազմաձևվում են անջատիչների վրա:

oVirt-ում վիրտուալ մեքենաների համար տրամաբանական ցանց ստեղծելիս նրան պետք է վերագրվի անջատիչի VLAN համարին համապատասխան նույնացուցիչ, որպեսզի VM-ները կարողանան հաղորդակցվել միմյանց հետ, նույնիսկ եթե դրանք աշխատում են կլաստերի տարբեր հանգույցներում:

Վիրտուալ մեքենաների միացման համար ցանցային ադապտերների նախնական կարգավորումները պետք է կատարվեին նախորդ հոդվածը - կազմաձևված է տրամաբանական ինտերֆեյս bondxnumx, ապա ցանցի բոլոր կարգավորումները պետք է կատարվեն միայն oVirt վարչական պորտալի միջոցով։

Հոսթային շարժիչով VM ստեղծելուց հետո, տվյալների կենտրոնի և կլաստերի ավտոմատ ստեղծումից բացի, ավտոմատ կերպով ստեղծվել է նաև տրամաբանական ցանց՝ մեր կլաստերը կառավարելու համար. օվրիտմգմթ, որին միացված էր այս VM-ը։

Անհրաժեշտության դեպքում կարող եք դիտել ցանցի տրամաբանական կարգավորումները օվրիտմգմթ և կարգավորեք դրանք, բայց դուք պետք է զգույշ լինեք, որպեսզի չկորցնեք վերահսկողությունը oVirt ենթակառուցվածքի վրա:

Տրամաբանական ցանցի կարգավորումներ ovritmgmt

Սովորական VM-ների համար նոր տրամաբանական ցանց ստեղծելու համար վարչական պորտալում անցեք Ցանց >> Ցանցեր >> նոր, և ներդիրի վրա ընդհանուր ավելացրեք ցանց ցանկալի VLAN ID-ով, ինչպես նաև նշեք «»VM ցանց«, սա նշանակում է, որ այն կարող է օգտագործվել VM-ին հանձնարարելու համար:

Նոր VLAN32 տրամաբանական ցանցի սքրինշոթ

Ներդիրում Բույլ, մենք կցում ենք այս ցանցը մեր կլաստերին Կլաստեր 1.

Սրանից հետո մենք գնում ենք Հաշվարկել >> Հյուրընկալողներ, հերթով գնացեք յուրաքանչյուր հյուրընկալող՝ ներդիր Ցանցային միջերեսներ, և գործարկեք հրաշագործը Կարգավորեք հյուրընկալող ցանցերը, նոր տրամաբանական ցանցի հոսթներին կապելու համար։

«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.

Տրամաբանական ցանց ավելացնելուց և հոսթի և հոսթինգի շարժիչի VM-ի միջև կապը ստուգելուց հետո այն կարող է օգտագործվել վիրտուալ մեքենայում:

Վիրտուալ մեքենայի տեղակայման համար տեղադրման պատկերի ստեղծում

Հղում դեպի փաստաթղթեր - oVirt կառավարման ուղեցույց, Գլուխ 8. Պահպանում, բաժինը Պատկերների վերբեռնում տվյալների պահպանման տիրույթում:

Առանց ՕՀ-ի տեղադրման պատկերի, հնարավոր չի լինի տեղադրել վիրտուալ մեքենա, թեև դա, իհարկե, խնդիր չէ, եթե, օրինակ, տեղադրված է ցանցում։ Կոբլեր նախապես ստեղծված պատկերներով։

Մեր դեպքում դա հնարավոր չէ, ուստի դուք ստիպված կլինեք ինքներդ ներմուծել այս պատկերը oVirt-ում: Նախկինում դա պահանջում էր ISO տիրույթի ստեղծում, սակայն oVirt-ի նոր տարբերակում այն հնացել է, և, հետևաբար, այժմ կարող եք պատկերներ վերբեռնել անմիջապես Storage տիրույթում վարչական պորտալից:

Վարչական պորտալում անցեք Պահեստ >> Սկավառակներ >> Վերբեռնել >> սկիզբ
Մենք ավելացնում ենք մեր OS պատկերը որպես 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 վկայագիրը «Վստահելի Root CA-ներ«(Trusted Root CA) ադմինիստրատորի կառավարման կայանի վրա, որտեղից մենք փորձում ենք ներբեռնել պատկերը։

Վկայագիրը Trusted Root CA-ին ավելացնելուց հետո կրկին սեղմեք «Փորձարկման միացում», պետք է ստանա.

Connection to ovirt-imageio-proxy was successful.

Հավաստագրի ավելացման գործողությունն ավարտելուց հետո կարող եք նորից փորձել ISO պատկերը վերբեռնել Storage Domain:

Սկզբունքորեն, դուք կարող եք ստեղծել առանձին Storage Domain Տվյալների տիպով՝ պատկերները և ձևանմուշները VM սկավառակներից առանձին պահելու համար, կամ նույնիսկ դրանք պահել Storage Domain-ում հյուրընկալված շարժիչի համար, բայց դա ադմինիստրատորի հայեցողությամբ է:

Սքրինշոթ ISO պատկերներով Storage Domain-ում տեղակայված շարժիչի համար

Ստեղծեք վիրտուալ մեքենա

Փաստաթղթերի հղում.
oVirt վիրտուալ մեքենաների կառավարման ուղեցույց –> Գլուխ 2. Linux վիրտուալ մեքենաների տեղադրում
Վահանակով հաճախորդների ռեսուրսներ

Տեղադրման պատկերը OS-ով oVirt-ում բեռնելուց հետո կարող եք ուղղակիորեն անցնել վիրտուալ մեքենայի ստեղծմանը: Շատ աշխատանք է արվել, բայց մենք արդեն վերջնական փուլում ենք, հանուն որի սկսվել է այս ամենը` ձեռք բերել անսարքության հանդուրժող ենթակառուցվածք` բարձր հասանելի վիրտուալ մեքենաների հոսթինգի համար: Եվ այս ամենը բացարձակապես անվճար է՝ ոչ մի լումա չի ծախսվել ծրագրային ապահովման լիցենզիաներ ձեռք բերելու վրա։

CentOS 7-ով վիրտուալ մեքենա ստեղծելու համար ՕՀ-ից տեղադրման պատկերը պետք է ներբեռնվի:

Մենք գնում ենք վարչական պորտալ, գնացեք Հաշվարկել >> Վիրտուալ մեքենաներ, և գործարկեք VM-ի ստեղծման մոգը: Լրացրեք բոլոր պարամետրերը և դաշտերը և սեղմեք OK. Ամեն ինչ շատ պարզ է, եթե հետևեք փաստաթղթերին:

Որպես օրինակ՝ ես կտամ բարձր հասանելի VM-ի հիմնական և լրացուցիչ կարգավորումները՝ ստեղծված սկավառակով, միացված ցանցին և տեղադրման պատկերից բեռնված.

Սքրինշոթներ՝ բարձր հասանելի VM կարգավորումներով

Վիզարդի հետ աշխատանքն ավարտելուց հետո փակեք այն, գործարկեք նոր VM և տեղադրեք ՕՀ-ն դրա վրա:
Դա անելու համար անցեք այս 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-ը ավտոմատ կերպով կվերագործարկի այն երկրորդ հանգույցում: Այս VM-ը կարող է նաև տեղափոխվել կլաստերային հոսթինգների միջև՝ դրանց պահպանման կամ այլ նպատակների համար:

Ամփոփում

Հուսով եմ, որ այս հոդվածը կարողացավ փոխանցել, որ oVirt-ը միանգամայն նորմալ գործիք է վիրտուալ ենթակառուցվածքի կառավարման համար, որն այնքան էլ դժվար չէ տեղակայել. գլխավորն այն է, որ հետևեք որոշակի կանոններին և պահանջներին, որոնք նկարագրված են ինչպես հոդվածում, այնպես էլ փաստաթղթերում:

Հոդվածի մեծ ծավալի պատճառով հնարավոր չեղավ դրանում շատ բաներ ներառել, օրինակ՝ տարբեր մոգերի քայլ առ քայլ կատարում բոլոր մանրամասն բացատրություններով և սքրինշոթներով, որոշ հրամանների երկար եզրակացություններ և այլն։ Իրականում, սա կպահանջի մի ամբողջ գիրք գրել, որն այնքան էլ իմաստ չունի, քանի որ ծրագրային ապահովման նոր տարբերակները մշտապես հայտնվում են նորարարություններով և փոփոխություններով: Ամենակարևորը հասկանալն է այն սկզբունքը, թե ինչպես է այդ ամենը միասին աշխատում, և ձեռք բերել ընդհանուր ալգորիթմ՝ վիրտուալ մեքենաների կառավարման համար անսարքության հանդուրժող հարթակ ստեղծելու համար:

Թեև մենք ստեղծել ենք վիրտուալ ենթակառուցվածք, մենք այժմ պետք է սովորեցնենք նրան փոխազդել ինչպես իր առանձին տարրերի միջև՝ հյուրընկալողներ, վիրտուալ մեքենաներ, ներքին ցանցեր և արտաքին աշխարհի հետ:

Այս գործընթացը համակարգի կամ ցանցի ադմինիստրատորի հիմնական խնդիրներից մեկն է, որը կքննարկվի հաջորդ հոդվածում՝ VyOS վիրտուալ երթուղիչների օգտագործման մասին մեր ձեռնարկության անսարքությունների հանդուրժող ենթակառուցվածքում (ինչպես կռահեցիք, դրանք կաշխատեն որպես վիրտուալ: մեքենաներ մեր oVirt կլաստերի վրա):

Source: www.habr.com

Սխալներին հանդուրժող ՏՏ ենթակառուցվածքի ստեղծում: Մաս 2. oVirt 4.3 կլաստերի տեղադրում և կարգավորում