🥇Defektu izturīgas IT infrastruktūras izveide. 2. daļa. oVirt 4.3 klastera instalēšana un konfigurēšana

Šis raksts ir turpinājums iepriekšējam - "Kļūmju izturīgas IT infrastruktūras izveide. 1. daļa — gatavošanās oVirt 4.3 klastera izvietošanai'.

Tas aptvers oVirt 4.3 klastera pamata instalēšanas un konfigurēšanas procesu augsti pieejamu virtuālo mašīnu mitināšanai, ņemot vērā to, ka visas infrastruktūras sagatavošanas sagatavošanas darbības jau ir veiktas iepriekš.

Ievads

Raksta galvenais mērķis ir sniegt soli pa solim instrukcijas, piemēram, “nākamais -> Jā -> apdare"kā parādīt dažas funkcijas, to instalējot un konfigurējot. Jūsu klastera izvietošanas process ne vienmēr var sakrist ar tajā aprakstīto infrastruktūras un vides īpašību dēļ, taču vispārīgie principi būs vienādi.

No subjektīvā viedokļa, oVirt 4.3 tā funkcionalitāte ir līdzīga VMware vSphere versijai 5.x, bet, protams, ar savām konfigurācijas un darbības funkcijām.

Interesentiem visas atšķirības starp RHEV (aka oVirt) un VMware vSphere var atrast internetā, piem. šeit, taču raksta gaitā es tomēr laiku pa laikam atzīmēšu dažas to atšķirības vai līdzības savā starpā.

Atsevišķi es vēlētos nedaudz salīdzināt darbu ar virtuālo mašīnu tīkliem. oVirt ievieš līdzīgu tīkla pārvaldības principu virtuālajām mašīnām (turpmāk tekstā — VM), kā VMware vSphere:

izmantojot standarta Linux tiltu (VMware - Standarta vSwitch), kas darbojas virtualizācijas resursdatoros;
izmantojot Open vSwitch (OVS) (programmā VMware - Izplatīts vSwitch) ir sadalīts virtuālais slēdzis, kas sastāv no diviem galvenajiem komponentiem: centrālā OVN servera un OVN kontrolleriem pārvaldītajos saimniekdatoros.

Jāatzīmē, ka ieviešanas vienkāršības dēļ rakstā tiks aprakstīta tīklu iestatīšana virtuālajā mašīnā oVirt, izmantojot standarta Linux tiltu, kas ir standarta izvēle, izmantojot KVM hipervizoru.

Šajā sakarā ir vairāki pamatnoteikumi darbam ar tīklu klasterī, kurus vislabāk nepārkāpt:

Visiem saimniekdatoru tīkla iestatījumiem pirms to pievienošanas oVirt ir jābūt identiskiem, izņemot IP adreses.
Kad resursdators ir pārņemts oVirt kontrolē, nav ieteicams neko manuāli mainīt tīkla iestatījumos bez pilnīgas pārliecības par savām darbībām, jo oVirt aģents tos vienkārši pārvietos atpakaļ uz iepriekšējiem pēc resursdatora restartēšanas vai aģents.
Jauna tīkla pievienošana virtuālajai mašīnai, kā arī darbs ar to jāveic tikai no oVirt pārvaldības konsoles.

Vēl vienu svarīga piezīme — ļoti kritiskai videi (ļoti jutīgai pret naudas zaudējumiem) tomēr būtu ieteicams izmantot maksas atbalstu un izmantošanu Red Hat virtualizācija 4.3. oVirt klastera darbības laikā var rasties daži jautājumi, kuru risināšanai ieteicams pēc iespējas ātrāk saņemt kvalificētu palīdzību, nevis pašiem tikt galā ar tiem.

Un visbeidzot ieteicams Pirms oVirt klastera izvietošanas iepazīstieties ar oficiālā dokumentācija, lai būtu lietas kursā vismaz par pamatjēdzieniem un definīcijām, citādi būs nedaudz grūti izlasīt pārējo rakstu.

Lai izprastu rakstu un oVirt klastera darbības principus, ir šādi vadlīniju dokumenti:

Apjoms tur nav īpaši liels, stundas vai divu laikā var diezgan labi apgūt pamatprincipus, bet tiem, kam patīk detaļas, ieteicams izlasīt Red Hat virtualizācijas produkta dokumentācija 4.3 — RHEV un oVirt būtībā ir viens un tas pats.

Tātad, ja visi saimniekdatoru, slēdžu un uzglabāšanas sistēmu pamata iestatījumi ir pabeigti, mēs turpinām tieši ar oVirt izvietošanu.

2. daļa. oVirt 4.3 klastera instalēšana un konfigurēšana

Lai atvieglotu orientēšanos, šajā rakstā uzskaitīšu galvenās sadaļas, kuras jāaizpilda pa vienai:

oVirt pārvaldības servera instalēšana
Jauna datu centra izveide
Jauna klastera izveide
Papildu saimniekdatoru instalēšana pašmitinātā vidē
Krātuves zonas vai krātuves domēnu izveide
Tīklu izveide un konfigurēšana virtuālajām mašīnām
Instalācijas attēla izveide virtuālās mašīnas izvietošanai
Izveidojiet virtuālo mašīnu

oVirt pārvaldības servera instalēšana

oVirt pārvaldības serveris ir vissvarīgākais elements oVirt infrastruktūrā virtuālās mašīnas, resursdatora vai virtuālās ierīces veidā, kas pārvalda visu oVirt infrastruktūru.

Tā tuvi analogi no virtualizācijas pasaules ir:

VMware vSphere — vCenter serveris
Microsoft Hyper-V — sistēmas centra virtuālās mašīnas pārvaldnieks (VMM).

Lai instalētu oVirt pārvaldības serveri, mums ir divas iespējas:

iespēja 1
Servera izvietošana specializētas virtuālās mašīnas vai resursdatora veidā.

Šī opcija darbojas diezgan labi, bet ar nosacījumu, ka šāda VM darbojas neatkarīgi no klastera, t.i. nedarbojas nevienā klastera resursdatorā kā parasta virtuālā mašīna, kurā darbojas KVM.

Kāpēc šādu virtuālo mašīnu nevar izvietot klasteru saimniekdatoros?

Pašā oVirt pārvaldības servera izvietošanas procesa sākumā mums ir dilemma - mums ir jāinstalē pārvaldības VM, bet patiesībā vēl nav paša klastera, un tāpēc ko mēs varam izdomāt lidojumā? Tieši tā – instalējiet KVM nākotnes klastera mezglā, pēc tam izveidojiet tajā virtuālo mašīnu, piemēram, ar CentOS OS un izvietojiet tajā oVirt dzinēju. Parasti to var izdarīt, lai pilnībā kontrolētu šādu VM, taču tas ir kļūdains nolūks, jo šajā gadījumā nākotnē ar šādu vadības VM 100% būs problēmas:

to nevar migrēt oVirt konsolē starp klastera saimniekiem (mezgliem);
migrējot, izmantojot KVM caur virsh migrēt, šī virtuālā mašīna nebūs pieejama pārvaldībai no oVirt konsoles.
klastera saimniekdatorus nevar parādīt Uzturēšanas režīmā (apkopes režīms), ja migrējat šo virtuālo mašīnu no resursdatora uz resursdatoru, izmantojot virsh migrēt.

Tāpēc dariet visu saskaņā ar noteikumiem - izmantojiet vai nu atsevišķu resursdatoru oVirt pārvaldības serverim, vai neatkarīgu VM, kas tajā darbojas, vai vēl labāk, rīkojieties, kā rakstīts otrajā opcijā.

iespēja 2
oVirt Engine Appliance instalēšana tās pārvaldītajā klastera resursdatorā.

Tieši šī iespēja turpmāk tiks uzskatīta par pareizāku un piemērotāku mūsu gadījumā.
Prasības šādai VM ir aprakstītas zemāk, tikai piebildīšu, ka infrastruktūrā, uz kuras var darbināt vadības VM, ieteicams būt vismaz diviem resursdatoriem, lai tā būtu kļūmju izturīga. Te vēlos piebilst, ka, kā jau rakstīju komentāros iepriekšējā rakstā, man tā arī neizdevās iegūt sadalītās smadzenes oVirt klasterī, kurā ir divi saimniekdatori, ar iespēju tajos palaist mitinātā dzinēja virtuālās mašīnas.

oVirt Engine Appliance instalēšana pirmajā klastera resursdatorā

Saite uz oficiālo dokumentāciju - oVirt Self-Hosted Engine Guide, nodaļa "Pašmitinātā dzinēja izvietošana, izmantojot komandrindu»

Dokumentā ir norādīti priekšnosacījumi, kas jāizpilda pirms mitinātā dzinēja virtuālās mašīnas izvietošanas, kā arī detalizēti aprakstīts pats instalēšanas process, tāpēc nav jēgas to atkārtot burtiski, tāpēc mēs pievērsīsimies dažām svarīgām detaļām.

Pirms visu darbību sākšanas resursdatora BIOS iestatījumos noteikti iespējojiet virtualizācijas atbalstu.
Instalējiet mitinātā dzinēja instalētāja pakotni resursdatorā:

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

Mēs sākam oVirt Hosted Engine izvietošanas procedūru resursdatora ekrānā (no tā var iziet, izmantojot Ctrl-A + D, aizvērt, izmantojot Ctrl-D):

screen
hosted-engine --deploy

Ja vēlaties, varat palaist instalāciju ar iepriekš sagatavotu atbildes failu:

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

Izvietojot mitināto dzinēju, mēs norādām visus nepieciešamos parametrus:

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

Lai instalētu ļoti pieejamu virtuālo mašīnu ar mitinātu dzinēju, mēs iepriekš izveidojām īpašu LUN glabāšanas sistēmā ar numuru 4 un 150 GB, kas pēc tam tika prezentēta klastera saimniekiem - sk. iepriekšējais raksts.

Iepriekš mēs pārbaudījām arī tā redzamību saimniekiem:

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

Pats mitinātā dzinēja izvietošanas process nav sarežģīts; beigās mums vajadzētu saņemt kaut ko līdzīgu:

[ 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

Mēs pārbaudām oVirt pakalpojumu klātbūtni resursdatorā:

Ja viss tika izdarīts pareizi, pēc instalēšanas pabeigšanas izmantojiet tīmekļa pārlūkprogrammu, lai pārietu uz https://ovirt_hostname/ovirt-engine no administratora datora un noklikšķiniet uz [Administrācijas portāls].

“Administrācijas portāla” ekrānuzņēmums

Logā ievadot pieteikumvārdu un paroli (iestatīto instalēšanas procesā), tāpat kā ekrānuzņēmumā, mēs nonākam Open Virtualization Manager vadības panelī, kurā varat veikt visas darbības ar virtuālo infrastruktūru:

pievienot datu centru
pievienot un konfigurēt klasteru
pievienot un pārvaldīt saimniekdatorus
pievienojiet krātuves apgabalus vai krātuves domēnus virtuālās mašīnas diskiem
pievienot un konfigurēt tīklus virtuālajām mašīnām
pievienot un pārvaldīt virtuālās mašīnas, instalācijas attēlus, VM veidnes

Visas šīs darbības tiks apspriestas tālāk, dažas lielās šūnās, citas sīkāk un ar niansēm.
Bet vispirms es ieteiktu izlasīt šo papildinājumu, kas, iespējams, noderēs daudziem.

Papildinājums

1) Principā, ja ir tāda vajadzība, nekas neliedz jums iepriekš instalēt KVM hipervizoru klastera mezglos, izmantojot pakotnes libvirt и qemu-kvm (Vai qemu-kvm-ev) no vēlamās versijas, lai gan, izvietojot oVirt klastera mezglu, tas var to izdarīt pats.

Bet ja libvirt и qemu-kvm Ja neesat instalējis jaunāko versiju, izvietojot mitināto programmu, var tikt parādīts šāds kļūdas ziņojums:

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

Tie. nepieciešams atjaunināta versija libvirt ar aizsardzību no MDS, kas atbalsta šo politiku:

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

Instalējiet libvirt v.4.5.0-10.el7_6.12 ar md-clear atbalstu:

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

Pārbaudiet “md-clear” atbalstu:

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

Pēc tam varat turpināt mitinātā dzinēja instalēšanu.

2) Programmā oVirt 4.3 ugunsmūra esamība un lietošana ugunsmūris ir obligāta prasība.

Ja viesotajam dzinējam paredzētās virtuālās mašīnas izvietošanas laikā tiek parādīta šāda kļūda:

[ 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

Pēc tam jums ir jāizslēdz cits ugunsmūris (ja tas tiek izmantots), jāinstalē un jāpalaiž ugunsmūris:

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

Vēlāk, instalējot ovirt aģentu jaunā klastera resursdatorā, tas konfigurēs nepieciešamos portus ugunsmūris automātiski.

3) Restartēšana saimniekdatorā, kurā darbojas virtuālā mašīna ar mitinātu dzinēju.

Kā parasti, saite 1 и saite 2 uz regulējošiem dokumentiem.

Visa mitinātā dzinēja VM pārvaldība tiek veikta TIKAI, izmantojot komandu mitinātais dzinējs uz saimniekdatora, kur tas darbojas, apmēram Virsh mums ir jāaizmirst, kā arī par to, ka varat izveidot savienojumu ar šo virtuālo mašīnu, izmantojot SSH, un palaist komandu "izslēgšanu'.

Procedūra virtuālās mašīnas pārslēgšanai uzturēšanas režīmā:

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

Mēs pārstartējam saimniekdatoru ar mitinātā dzinēja aģentu un darām ar to nepieciešamo.

Pēc atsāknēšanas pārbaudiet virtuālās mašīnas statusu ar mitināto programmu:

hosted-engine --vm-status

Ja mūsu virtuālā mašīna ar mitināto dzinēju netiek startēta un pakalpojumu žurnālā tiek rādītas līdzīgas kļūdas:

Kļūda servisa žurnālā:

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

Pēc tam savienojam krātuvi un restartējam aģentu:

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

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

Pēc virtuālās mašīnas palaišanas ar mitināto dzinēju mēs to izslēdzam no uzturēšanas režīma:

Procedūra virtuālās mašīnas noņemšanai no uzturēšanas režīma:

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) Mitinātā dzinēja un visa ar to saistītā noņemšana.

Dažreiz ir nepieciešams pareizi noņemt iepriekš instalētu mitināto dzinēju - saite uz vadlīniju dokumentu.

Vienkārši palaidiet komandu resursdatorā:

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

Pēc tam mēs noņemam nevajadzīgās pakotnes, pirms tam dublējot dažas konfigurācijas, ja nepieciešams:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

Jauna datu centra izveide

Atsauces dokumentācija – oVirt administrēšanas rokasgrāmata. 4. nodaļa: Datu centri

Vispirms definēsim, kas tas ir datu centrs (Citēju no palīdzības) ir loģiska entītija, kas definē resursu kopu, ko izmanto konkrētā vidē.

Datu centrs ir sava veida konteiners, kas sastāv no:

loģiskie resursi klasteru un saimniekdatoru veidā
klasteru tīkla resursus loģisko tīklu un resursdatoros fizisko adapteru veidā,
krātuves resursi (VM diskiem, veidnēm, attēliem) uzglabāšanas apgabalu (Storage Domains) veidā.

Datu centrā var būt iekļauti vairāki klasteri, kas sastāv no vairākiem saimniekdatoriem, kuros darbojas virtuālās mašīnas, kā arī ar to var būt saistītas vairākas krātuves zonas.
Var būt vairāki datu centri, tie darbojas neatkarīgi viens no otra. Ovirt pilnvaras ir sadalītas pēc lomām, un jūs varat konfigurēt atļaujas atsevišķi gan datu centra līmenī, gan tā atsevišķos loģiskajos elementos.

Datu centrs vai datu centri, ja tādi ir vairāki, tiek pārvaldīti no vienas administratīvās konsoles vai portāla.

Lai izveidotu datu centru, dodieties uz administratīvo portālu un izveidojiet jaunu datu centru:
Rēķināt >> datu centri >> Jaunumi

Tā kā krātuves sistēmā izmantojam koplietojamo krātuvi, krātuves veidam jābūt Shared:

Datu centra izveides vedņa ekrānuzņēmums

Instalējot virtuālo mašīnu ar mitināto dzinēju, pēc noklusējuma tiek izveidots datu centrs - Datu centrs1, un pēc tam, ja nepieciešams, varat mainīt tā krātuves veidu uz citu.

Datu centra izveide ir vienkāršs uzdevums, bez sarežģītām niansēm, un visas papildu darbības ar to ir aprakstītas dokumentācijā. Vienīgais, ko atzīmēšu, ir tas, ka atsevišķi resursdatori, kuriem ir tikai vietējā krātuve (disks) virtuālajām mašīnām, nevarēs iekļūt datu centrā ar Storage Type - Shared (tos nevar pievienot tur), un tiem ir jāizveido atsevišķs datu centrs – t.i. Katram atsevišķam resursdatoram ar vietējo krātuvi ir nepieciešams savs atsevišķs datu centrs.

Jauna klastera izveide

Saite uz dokumentāciju – oVirt administrēšanas rokasgrāmata. 5. nodaļa: Kopas

Bez liekām detaļām, klasteris – šī ir loģiska saimniekdatoru grupēšana, kuriem ir kopīgs krātuves apgabals (dalītu disku veidā uzglabāšanas sistēmā, kā tas ir mūsu gadījumā). Ir arī vēlams, lai klastera saimniekdatori būtu identiski aparatūrā un tiem būtu viena veida procesors (Intel vai AMD). Protams, vislabāk ir, ja klastera serveri ir pilnīgi identiski.

Klasteris ir daļa no datu centra (ar noteiktu krātuves veidu - Uz vietas vai Dalījās), un visiem saimniekiem ir jāpieder kāda veida klasterim atkarībā no tā, vai tiem ir koplietota krātuve.

Instalējot resursdatorā virtuālo mašīnu ar mitinātu dzinēju, pēc noklusējuma tiek izveidots datu centrs - Datu centrs1, kopā ar klasteri – Klasteris1, un turpmāk varēsiet konfigurēt tā parametrus, iespējot papildu opcijas, pievienot tai saimniekdatorus utt.

Kā parasti, sīkāku informāciju par visiem klastera iestatījumiem ieteicams skatīt oficiālajā dokumentācijā. No dažām klastera iestatīšanas funkcijām piebildīšu tikai to, ka, to veidojot, pietiek tikai cilnē konfigurēt pamata parametrus. vispārējs.

Es atzīmēšu svarīgākos parametrus:

Procesora tips — tiek izvēlēts, pamatojoties uz to, kuri procesori ir instalēti klastera saimniekdatoros, no kāda ražotāja tie ir un kurš procesors resursdatoros ir vecākais, lai atkarībā no tā tiktu izmantotas visas klasterī pieejamās procesora instrukcijas.
Slēdža tips - mūsu klasterī mēs izmantojam tikai Linux tiltu, tāpēc mēs to izvēlamies.
Ugunsmūra veids - šeit viss ir skaidrs, tas ir ugunsmūris, kas ir jāiespējo un jākonfigurē saimniekdatoros.

Ekrānuzņēmums ar klastera parametriem

Papildu saimniekdatoru instalēšana pašmitinātā vidē

Saite dokumentācijai.

Papildu saimniekdatori pašmitinātai videi tiek pievienoti tāpat kā parastajam saimniekdatoram, veicot papildu darbību, izvietojot virtuālo mašīnu ar mitinātu dzinēju. Izvēlieties mitinātā dzinēja izvietošanas darbību >> izvietot. Tā kā papildu resursdatoram ir jāuzrāda arī virtuālās mašīnas ar mitinātu dzinēju LUN, tas nozīmē, ka šo resursdatoru vajadzības gadījumā var izmantot, lai mitinātu virtuālo mašīnu ar mitinātu dzinēju.
Kļūdu tolerances nolūkos ir ļoti ieteicams, lai būtu vismaz divi saimniekdatori, kuros var ievietot mitinātā dzinēja VM.

Papildu resursdatorā atspējojiet iptables (ja iespējots), iespējojiet ugunsmūri

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Instalējiet nepieciešamo KVM versiju (ja nepieciešams):

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

Instalējiet nepieciešamos repozitorijus un mitināto dzinēja instalētāju:

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

Tālāk dodieties uz konsoli Atveriet virtualizācijas pārvaldnieku, pievienojiet jaunu saimniekdatoru un dariet visu soli pa solim, kā rakstīts dokumentācija.

Rezultātā pēc papildu resursdatora pievienošanas mums vajadzētu iegūt kaut ko līdzīgu attēlam administratīvajā konsolē, tāpat kā ekrānuzņēmumā.

Administratīvā portāla ekrānuzņēmums — saimnieki

Uz saimniekdatora, kurā pašlaik darbojas mitinātā dzinēja VM, ir zelta kronis un uzraksts “Hosted Engine VM palaišana", resursdators, kurā vajadzības gadījumā var palaist šo virtuālo mašīnu - uzraksts "Var palaist Hosted Engine VM'.

Uzņēmēja kļūmes gadījumā, kurā "Hosted Engine VM palaišana", tas tiks automātiski restartēts otrajā resursdatorā. Šo virtuālo mašīnu var arī migrēt no aktīvā saimniekdatora uz gaidstāves resursdatoru tās uzturēšanai.

Enerģijas pārvaldības/nožogojuma iestatīšana oVirt saimniekiem

Dokumentācijas saites:

Red Hat virtualizācija 4.3 -> Tehniskā uzziņa -> 4. nodaļa. Enerģijas pārvaldība
oVirt administrēšanas rokasgrāmata -> 7. nodaļa: Saimnieki

Lai gan varētu šķist, ka esat pabeidzis resursdatora pievienošanu un konfigurēšanu, tā nav gluži taisnība.
Normālai saimniekdatoru darbībai un kļūmju identificēšanai/atrisināšanai ar jebkuru no tiem ir nepieciešami jaudas pārvaldības/nožogojuma iestatījumi.

Žogs, vai nožogošana, ir bojāta vai neveiksmīga saimniekdatora īslaicīgas izslēgšanas process no klastera, kura laikā tiek restartēti tajā esošie oVirt pakalpojumi vai pats resursdators.

Visa informācija par jaudas pārvaldības / nožogojuma definīcijām un parametriem, kā parasti, ir sniegta dokumentācijā; es sniegšu tikai piemēru, kā konfigurēt šo svarīgo parametru, kas tiek piemērots Dell R640 serveriem ar iDRAC 9.

Dodieties uz administratīvo portālu, noklikšķiniet uz Rēķināt >> saimniekiem izvēlieties saimniekdatoru.
Klikšķis rediģēt.
Noklikšķiniet uz cilnes Power Management.
Atzīmējiet izvēles rūtiņu blakus opcijai Iespējot enerģijas pārvaldību.
Atzīmējiet izvēles rūtiņu blakus opcijai Kdump integrācijalai neļautu saimniekdatoram pāriet nožogojuma režīmā kodola avārijas izgāztuves ierakstīšanas laikā.

Piezīme.

Pēc Kdump integrācijas iespējošanas jau strādājošā resursdatorā, tas ir atkārtoti jāinstalē saskaņā ar procedūru oVirt administrēšanas rokasgrāmatā -> 7. nodaļa: Saimnieki -> Saimnieku atkārtota instalēšana.

Ja vēlaties, varat atzīmēt izvēles rūtiņu Atspējot jaudas pārvaldības politikas kontroli, ja nevēlamies, lai saimniekdatora jaudas pārvaldību kontrolētu klastera plānošanas politika.
Noklikšķiniet uz pogas (+), lai pievienotu jaunu enerģijas pārvaldības ierīci, tiks atvērts aģenta rekvizītu rediģēšanas logs.
Ja izmantojat iDRAC9, aizpildiet laukus:
- Adrese - iDRAC9 adrese
- Lietotājvārds Parole – attiecīgi pieteikšanās vārds un parole, lai pieteiktos iDRAC9
- tips -Drac5
- Atzīmēt Drošs
- pievienojiet šādas opcijas: cmd_prompt=>,login_timeout=30

Ekrānuzņēmums ar “Power Management” parametriem saimniekdatora rekvizītos

Krātuves zonas vai krātuves domēnu izveide

Saite uz dokumentāciju - oVirt administrēšanas rokasgrāmata, 8. nodaļa: Uzglabāšana.

Krātuves domēns, vai krātuves apgabals, ir centralizēta vieta virtuālās mašīnas disku, instalācijas attēlu, veidņu un momentuzņēmumu glabāšanai.

Krātuves zonas var savienot ar datu centru, izmantojot dažādus protokolus, klasteru un tīkla failu sistēmas.

oVirt ir trīs veidu uzglabāšanas zonas:

Datu domēns – glabāt visus ar virtuālajām mašīnām saistītos datus (diskus, veidnes). Datu domēnu nevar koplietot starp dažādiem datu centriem.
ISO domēns (novecojis krātuves veids) – OS instalācijas attēlu glabāšanai. ISO domēnu var koplietot starp dažādiem datu centriem.
Eksportēt domēnu (novecojis uzglabāšanas zonas veids) – starp datu centriem pārvietoto attēlu pagaidu glabāšanai.

Mūsu konkrētajā gadījumā uzglabāšanas apgabals ar datu domēna tipu izmanto Fibre Channel Protocol (FCP), lai izveidotu savienojumu ar uzglabāšanas sistēmas LUN.

No oVirt viedokļa, izmantojot uzglabāšanas sistēmas (FC vai iSCSI), katrs virtuālais disks, momentuzņēmums vai veidne ir loģisks disks.
Bloku ierīces tiek apkopotas vienā vienībā (klasteru saimniekdatoros), izmantojot Volume Group, un pēc tam sadalītas, izmantojot LVM, loģiskajos sējumos, kas tiek izmantoti kā virtuālie diski virtuālajām mašīnām.

Visas šīs grupas un daudzus LVM sējumus var redzēt klastera resursdatorā, izmantojot komandas utt и lvs. Protams, visas darbības ar šādiem diskiem jāveic tikai no oVirt konsoles, izņemot īpašus gadījumus.

Virtuālie diski VM var būt divu veidu - QCOW2 vai RAW. Diski var būt "tievs"vai"biezs". Momentuzņēmumi vienmēr tiek izveidoti kā "plāns".

Veids, kā pārvaldīt krātuves domēnus jeb krātuves apgabalus, kuriem piekļūst, izmantojot FC, ir diezgan loģisks – katram VM virtuālajam diskam ir atsevišķs loģiskais sējums, ko var ierakstīt tikai viens resursdators. FC savienojumiem oVirt izmanto kaut ko līdzīgu kopu LVM.

Virtuālās mašīnas, kas atrodas vienā krātuves apgabalā, var migrēt starp resursdatoriem, kas pieder vienam un tam pašam klasterim.

Kā redzams no apraksta, klasteris oVirt, tāpat kā klasteris VMware vSphere vai Hyper-V, būtībā nozīmē vienu un to pašu - tā ir loģiska saimniekdatoru grupēšana, vēlams identiska pēc aparatūras sastāva un kam ir kopīga krātuve virtuālajai glabāšanai. mašīnu diski.

Turpināsim tieši ar datu krātuves apgabala izveidi (VM diski), jo bez tā datu centrs netiks inicializēts.
Atgādināšu, ka visiem LUN, kas tiek parādīti klastera saimniekiem krātuves sistēmā, tajos jābūt redzamiem, izmantojot komandu “daudzceļu -ll'.

Saskaņā ar dokumentācija, dodieties uz portālu dodieties uz glabāšana >> Domēni -> Jauns domēns un izpildiet norādījumus sadaļā "FCP krātuves pievienošana".

Pēc vedņa palaišanas aizpildiet nepieciešamos laukus:

Vārds — iestatiet klastera nosaukumu
Domēna funkcija — Dati
Uzglabāšanas veids — Šķiedru kanāls
Izmantojamais saimniekdators — atlasiet resursdatoru, kurā ir pieejams mums nepieciešamais LUN

LUN sarakstā atzīmējiet mums vajadzīgo, noklikšķiniet Pievienot un tad ОК. Ja nepieciešams, varat pielāgot papildu uzglabāšanas zonas parametrus, noklikšķinot uz Uzlabotie parametri.

“Storage domain” pievienošanas vedņa ekrānuzņēmums

Pamatojoties uz vedņa rezultātiem, mums vajadzētu saņemt jaunu krātuves apgabalu, un mūsu datu centram vajadzētu pāriet uz statusu UPvai inicializēts:

Ekrānuzņēmumi no datu centra un tajā esošajām krātuves zonām:

Tīklu izveide un konfigurēšana virtuālajām mašīnām

Saite uz dokumentāciju - oVirt administrēšanas rokasgrāmata, 6. nodaļa: Loģiskie tīkli

Tīkli jeb tīkli kalpo oVirt virtuālajā infrastruktūrā izmantoto loģisko tīklu grupēšanai.

Lai mijiedarbotos starp virtuālās mašīnas tīkla adapteri un resursdatora fizisko adapteri, tiek izmantotas loģiskas saskarnes, piemēram, Linux tilts.

Lai grupētu un sadalītu trafiku starp tīkliem, slēdžos ir konfigurēti VLAN.

Veidojot loģisko tīklu virtuālajām mašīnām programmā oVirt, tam ir jāpiešķir identifikators, kas atbilst slēdža VLAN numuram, lai virtuālās mašīnas varētu sazināties savā starpā, pat ja tās darbojas dažādos klastera mezglos.

Virtuālo mašīnu savienošanai bija jāveic sākotnējie tīkla adapteru iestatījumi resursdatoros iepriekšējais raksts - konfigurēts loģiskais interfeiss Bond1, tad visi tīkla iestatījumi jāveic tikai caur administratīvo portālu oVirt.

Pēc virtuālās mašīnas izveides ar mitināto dzinēju, papildus automātiskai datu centra un klastera izveidei, tika automātiski izveidots arī loģiskais tīkls, lai pārvaldītu mūsu klasteru - ovritmgmt, ar kuru tika pievienota šī virtuālā mašīna.

Ja nepieciešams, varat apskatīt loģiskā tīkla iestatījumus ovritmgmt un pielāgojiet tos, taču jums jābūt uzmanīgiem, lai nezaudētu kontroli pār oVirt infrastruktūru.

Loģiskā tīkla iestatījumi ovritmgmt

Lai izveidotu jaunu loģisko tīklu parastajām virtuālajām mašīnām, administratīvajā portālā dodieties uz tīkls >> tīkli >> Jaunumiun cilnē vispārējs pievienojiet tīklu ar vēlamo VLAN ID, kā arī atzīmējiet izvēles rūtiņu blakus “VM tīkls", tas nozīmē, ka to var izmantot, lai piešķirtu VM.

Jaunā VLAN32 loģiskā tīkla ekrānuzņēmums

Cilnē Grupa, mēs pievienojam šo tīklu mūsu klasterim Klasteris1.

Pēc tam mēs ejam uz Rēķināt >> saimniekiem, dodieties uz katru saimniekdatoru pēc kārtas, uz cilni Tīkla saskarnesun palaidiet vedni Iestatiet resursdatora tīklus, lai izveidotu savienojumu ar jauna loģiskā tīkla saimniekiem.

Vedņa “Iestatīšanas resursdatora tīkli” ekrānuzņēmums

oVirt aģents automātiski veiks visus nepieciešamos tīkla iestatījumus resursdatorā - izveidos VLAN un BRIDGE.

Konfigurācijas failu piemēri jauniem resursdatora tīkliem:

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

Ļaujiet man jums vēlreiz atgādināt, ka klastera saimniekdatorā NAV NEPIECIEŠAMS iepriekš manuāli izveidojiet tīkla saskarnes ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

Pēc loģiskā tīkla pievienošanas un savienojuma pārbaudes starp resursdatoru un mitinātā dzinēja VM to var izmantot virtuālajā mašīnā.

Instalācijas attēla izveide virtuālās mašīnas izvietošanai

Saite uz dokumentāciju - oVirt administrēšanas rokasgrāmata, 8. nodaļa: Uzglabāšana, sadaļa Attēlu augšupielāde datu krātuves domēnā.

Bez OS instalācijas attēla nebūs iespējams instalēt virtuālo mašīnu, lai gan tā, protams, nav problēma, ja, piemēram, ir instalēta tīklā Kobleris ar iepriekš izveidotiem attēliem.

Mūsu gadījumā tas nav iespējams, tāpēc jums pašiem būs jāimportē šis attēls oVirt. Iepriekš tam bija jāizveido ISO domēns, taču jaunajā oVirt versijā tas ir novecojis, un tāpēc tagad varat augšupielādēt attēlus tieši uz krātuves domēnu no administratīvā portāla.

Administratīvajā portālā dodieties uz glabāšana >> Diski >> Upload >> mājas
Mēs pievienojam savu OS attēlu kā ISO failu, aizpildām visus veidlapas laukus un noklikšķiniet uz pogas "Pārbaudīt savienojumu".

Instalācijas attēla pievienošanas vedņa ekrānuzņēmums

Ja tiek parādīta šāda kļūda:

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`

Pēc tam jums jāpievieno oVirt sertifikāts "Uzticamie saknes CA"(Trusted Root CA) administratora vadības stacijā, no kurienes mēs cenšamies lejupielādēt attēlu.

Pēc sertifikāta pievienošanas Trusted Root CA, noklikšķiniet vēlreiz "Pārbaudīt savienojumu", vajadzētu iegūt:

Connection to ovirt-imageio-proxy was successful.

Kad esat pabeidzis sertifikāta pievienošanas darbību, varat mēģināt vēlreiz augšupielādēt ISO attēlu krātuves domēnā.

Principā jūs varat izveidot atsevišķu krātuves domēnu ar datu tipu, lai saglabātu attēlus un veidnes atsevišķi no VM diskiem vai pat saglabātu tos mitinātās programmas krātuves domēnā, taču tas ir pēc administratora ieskatiem.

Ekrānuzņēmums ar ISO attēliem mitinātās programmas krātuves domēnā

Izveidojiet virtuālo mašīnu

Dokumentācijas saite:
oVirt virtuālās mašīnas pārvaldības rokasgrāmata -> 2. nodaļa: Linux virtuālo mašīnu instalēšana
Konsoles klientu resursi

Pēc instalācijas attēla ielādes ar operētājsistēmu oVirt varat pāriet tieši uz virtuālās mašīnas izveidi. Liels darbs ir paveikts, taču esam jau beigu posmā, kura labad tas viss tika uzsākts - defektizturīgas infrastruktūras iegūšana augsti pieejamu virtuālo mašīnu mitināšanai. Un tas viss ir pilnīgi bez maksas – programmatūras licenču iegādei netika iztērēts neviens santīms.

Lai izveidotu virtuālo mašīnu ar CentOS 7, ir jālejupielādē instalācijas attēls no OS.

Mēs ejam uz administratīvo portālu, dodamies uz Rēķināt >> Virtuālās mašīnasun palaidiet virtuālās mašīnas izveides vedni. Aizpildiet visus parametrus un laukus un noklikšķiniet uz ОК. Viss ir ļoti vienkārši, ja sekojat dokumentācijai.

Kā piemēru es sniegšu ļoti pieejamās virtuālās mašīnas pamata un papildu iestatījumus ar izveidotu disku, savienotu ar tīklu un sāknēšanu no instalācijas attēla:

Ekrānuzņēmumi ar ļoti pieejamiem VM iestatījumiem

Kad esat pabeidzis darbu ar vedni, aizveriet to, palaidiet jaunu virtuālo mašīnu un instalējiet tajā OS.
Lai to izdarītu, administratīvajā portālā dodieties uz šīs virtuālās mašīnas konsoli:

Ekrānuzņēmums ar administratīvā portāla iestatījumiem savienojuma izveidei ar virtuālās mašīnas konsoli

Lai izveidotu savienojumu ar virtuālās mašīnas konsoli, vispirms ir jākonfigurē konsole virtuālās mašīnas rekvizītos.

VM iestatījumu ekrānuzņēmums, cilne “Console”.

Lai izveidotu savienojumu ar VM konsoli, varat izmantot, piemēram, Virtuālās mašīnas skatītājs.

Lai izveidotu savienojumu ar VM konsoli tieši pārlūkprogrammas logā, savienojuma iestatījumiem, izmantojot konsoli, jābūt šādiem:

Pēc OS instalēšanas virtuālajā mašīnā ieteicams instalēt oVirt viesaģentu:

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

Tādējādi mūsu rīcības rezultātā izveidotā VM būs ļoti pieejama, t.i. ja klastera mezgls, kurā tas darbojas, neizdodas, oVirt automātiski restartēs to otrajā mezglā. Šo virtuālo mašīnu var arī migrēt starp klasteru saimniekdatoriem to uzturēšanai vai citiem mērķiem.

Secinājums

Ceru, ka šajā rakstā izdevās pateikt, ka oVirt ir pilnīgi normāls virtuālās infrastruktūras pārvaldības rīks, kuru nav nemaz tik grūti izvietot - galvenais ir ievērot noteiktus noteikumus un prasības, kas aprakstītas gan rakstā, gan dokumentācijā.

Raksta lielā apjoma dēļ tajā nebija iespējams iekļaut daudzas lietas, piemēram, dažādu burvju soli pa solim izpildi ar visiem detalizētiem paskaidrojumiem un ekrānuzņēmumiem, dažu komandu garus secinājumus utt. Patiesībā tas prasītu uzrakstīt veselu grāmatu, kam nav lielas jēgas, jo pastāvīgi parādās jaunas programmatūras versijas ar jauninājumiem un izmaiņām. Vissvarīgākais ir saprast principu, kā tas viss darbojas kopā, un iegūt vispārīgu algoritmu, lai izveidotu defektu tolerantu platformu virtuālo mašīnu pārvaldībai.

Lai gan esam izveidojuši virtuālo infrastruktūru, tagad mums ir jāiemāca tai mijiedarboties gan starp atsevišķiem elementiem: saimniekdatoriem, virtuālajām mašīnām, iekšējiem tīkliem, gan ar ārpasauli.

Šis process ir viens no galvenajiem sistēmas vai tīkla administratora uzdevumiem, par kuru tiks runāts nākamajā rakstā - par VyOS virtuālo maršrutētāju izmantošanu mūsu uzņēmuma defektu izturīgajā infrastruktūrā (kā jau uzminējāt, tie darbosies kā virtuālie mašīnas mūsu oVirt klasterī).

Avots: www.habr.com

Kļūmju izturīgas IT infrastruktūras izveide. 2. daļa. oVirt 4.3 klastera instalēšana un konfigurēšana