🥇Kreado de mistolerema IT-infrastrukturo. Parto 2. Instalado kaj agordo de oVirt 4.3 cluster

Ĉi tiu artikolo estas daŭrigo de la antaŭa - "Kreado de mistolerema IT-infrastrukturo. Parto 1 - Preparado por Deploji oVirt 4.3 Areton".

Ĝi kovros la procezon de baza instalado kaj agordo de oVirt 4.3-grupo por gastigado de tre disponeblaj virtualaj maŝinoj, konsiderante la fakton, ke ĉiuj antaŭaj paŝoj por prepari la infrastrukturon jam estis plenumitaj antaŭe.

Prologo

La ĉefa celo de la artikolo estas doni paŝon post paŝo instrukcioj kiel "sekva -> Jes -> finpoluro"kiel montri kelkajn funkciojn dum ĝi instalas kaj agordas. La procezo por deploji vian areton eble ne ĉiam koincidas kun tiu priskribita en ĝi, pro la karakterizaĵoj de la infrastrukturo kaj medio, sed la ĝeneralaj principoj estos la samaj.

El subjektiva vidpunkto, oVirt 4.3 ĝia funkcieco similas al VMware vSphere versio 5.x, sed kompreneble kun siaj propraj agordaj kaj funkciaj funkcioj.

Por interesatoj, ĉiuj diferencoj inter RHEV (alinome oVirt) kaj VMware vSphere troveblas en la Interreto, ekzemple tie, sed mi ankoraŭ foje notos kelkajn el iliaj diferencoj aŭ similecoj unu kun la alia dum la artikolo progresas.

Aparte, mi ŝatus kompari iomete la laboron kun retoj por virtualaj maŝinoj. oVirt efektivigas similan principon de retadministrado por virtualaj maŝinoj (ĉi-poste nomataj VMoj), kiel en VMware vSphere:

uzante norman Linuksan ponton (en VMware - Norma vSwitch), funkciante sur virtualigaj gastigantoj;
uzante Open vSwitch (OVS) (en VMware - Distribuita vSwitch) estas distribuita virtuala ŝaltilo konsistanta el du ĉefaj komponentoj: centra OVN-servilo kaj OVN-regiloj sur administritaj gastigantoj.

Oni devas rimarki, ke pro la facileco de efektivigo, la artikolo priskribos starigi retojn en oVirt por VM uzante norman Linuksan ponton, kiu estas la norma elekto kiam oni uzas la KVM-hipervizion.

Ĉi-rilate, ekzistas pluraj bazaj reguloj por labori kun la reto en areto, kiuj estas plej bone ne esti malobservitaj:

Ĉiuj retaj agordoj ĉe gastigantoj antaŭ ol aldoni ilin al oVirt devas esti identaj, krom IP-adresoj.
Post kiam gastiganto estas prenita sub la kontrolon de oVirt, estas tre ne rekomendite ŝanĝi ion ajn mane en la retaj agordoj sen kompleta konfido pri viaj agoj, ĉar la oVirt-agento simple revenos ilin al la antaŭaj post rekomenco de la gastiganto aŭ agento.
Aldoni novan reton por VM, same kiel labori kun ĝi, devas esti farita nur de la administra konzolo oVirt.

Alia grava noto — por tre kritika medio (tre sentema al monperdoj), oni ankoraŭ rekomendus uzi pagitan subtenon kaj uzi Red Hat Virtualization 4.3. Dum la funkciado de la aro oVirt, povas ekesti iuj problemoj, por kiuj estas konsilinde ricevi kvalifikitan helpon kiel eble plej baldaŭ, anstataŭ trakti ilin mem.

Fine, rekomendita Antaŭ ol deploji oVirt-grupon, familiariĝu kun oficiala dokumentado, por konscii almenaŭ pri la bazaj konceptoj kaj difinoj, alie estos iom malfacile legi la ceteran artikolon.

Bazaj por kompreni la artikolon kaj la principojn de funkciado de la oVirt-grupo estas ĉi tiuj gviddokumentoj:

La volumo tie ne estas tre granda, en unu aŭ du horoj vi povas sufiĉe regi la bazajn principojn, sed por tiuj, kiuj ŝatas detalojn, oni rekomendas legi Produkta Dokumentaro por Red Hat Virtualization 4.3 — RHEV kaj oVirt estas esence la sama afero.

Do, se ĉiuj bazaj agordoj sur la gastigantoj, ŝaltiloj kaj stokaj sistemoj estas finitaj, ni rekte iras al la disfaldiĝo de oVirt.

Parto 2. Instalado kaj agordo de la oVirt 4.3-grupo

Por facileco de orientiĝo, mi listigos la ĉefajn sekciojn en ĉi tiu artikolo, kiuj devas esti kompletigitaj unuope:

Instalante la administradan servilon oVirt
Kreo de nova datumcentro
Kreante novan areton
Instali pliajn gastigantojn en Mem-Gastigita medio
Kreante stokejon aŭ Stokado-Domajnojn
Krei kaj agordi retojn por virtualaj maŝinoj
Krei instalaĵbildon por deploji virtualan maŝinon
Kreu virtualan maŝinon

Instalante la administradan servilon oVirt

oVirt administra servilo - ĉi tio estas la plej grava elemento en la infrastrukturo de oVirt, en formo de virtuala maŝino, gastiganto aŭ virtuala aparato, kiu administras la tutan infrastrukturon de oVirt.

Ĝiaj proksimaj analogoj de la mondo de virtualigo estas:

VMware vSphere - vCenter Servilo
Microsoft Hyper-V - System Center Virtual Machine Manager (VMM).

Por instali la administradan servilon oVirt, ni havas du eblojn:

Eblo 1
Deplojante servilon en la formo de specialeca VM aŭ gastiganto.

Ĉi tiu opcio funkcias sufiĉe bone, sed kondiĉe ke tia VM funkcias sendepende de la areto, t.e. ne funkcias en iu cluster-gastiganto kiel regula virtuala maŝino kuranta KVM.

Kial tia VM ne povas esti deplojita sur cluster-gastigantoj?

Je la komenco de la procezo de deplojado de la administradservilo oVirt, ni havas dilemon - ni devas instali administran VM, sed fakte ankoraŭ ne ekzistas cluster mem, kaj tial kion ni povas elpensi sur la flugo? Ĝuste - instalu KVM sur estonta grapolnodo, tiam kreu virtualan maŝinon sur ĝi, ekzemple, kun CentOS OS kaj deploji la motoron oVirt en ĝi. Ĉi tio kutime povas esti farita pro kialoj de kompleta kontrolo de tia VM, sed ĉi tio estas erara intenco, ĉar en ĉi tiu kazo, estonte estos 100% problemoj kun tia kontrola VM:

ĝi ne povas esti migrita en la oVirt-konzolo inter gastigantoj (nodoj) de la areto;
dum migrado uzante KVM per virsh migras, ĉi tiu VM ne estos disponebla por administrado de la oVirt-konzolo.
cluster-gastigantoj ne povas esti montrataj en Bontenada reĝimo (funkciserva reĝimo), se vi migras ĉi tiun VM de gastiganto al gastiganto uzante virsh migras.

Do faru ĉion laŭ la reguloj - uzu aŭ apartan gastiganton por la mastruma servilo oVirt, aŭ sendependan VM funkciantan sur ĝi, aŭ pli bone, faru kiel skribite en la dua opcio.

Eblo 2
Instalante oVirt Engine Appliance sur cluster-gastiganto administrita de ĝi.

Estas ĉi tiu opcio kiu estos konsiderata plu kiel pli ĝusta kaj taŭga en nia kazo.
La postuloj por tia VM estas priskribitaj malsupre; Mi nur aldonos, ke oni rekomendas havi almenaŭ du gastigantojn en la infrastrukturo, sur kiu la kontrola VM povas ruliĝi por igi ĝin tolerema al misfunkciado. Ĉi tie mi ŝatus aldoni, ke, kiel mi jam skribis en la komentoj en la antaŭa artikolo, mi neniam povis akiri splitbrain sur oVirt-areto de du gastigantoj, kun la kapablo ruli gast-motorajn VM-ojn sur ili.

Instalante oVirt Engine Appliance sur la unua gastiganto de la areto

Ligo al oficiala dokumentaro - oVirt Mem-Gastigita Motora Gvidilo, ĉapitro "Deplojante la Mem-Gastigitan Motoron Uzante la Komandlinion»

La dokumento precizigas la antaŭkondiĉojn, kiuj devas esti plenumitaj antaŭ deploji gastigitan motoron VM, kaj ankaŭ detale priskribas la instalan procezon mem, do ne utilas ripeti ĝin laŭvorte, do ni koncentriĝos pri iuj gravaj detaloj.

Antaŭ ol komenci ĉiujn agojn, nepre ebligu virtualigan subtenon en la BIOS-agordoj sur la gastiganto.
Instalu la pakaĵon por la gastigita-motora instalilo sur la gastiganto:

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

Ni komencas la proceduron por deploji oVirt Hosted Engine en la ekrano de la gastiganto (vi povas eliri ĝin per Ctrl-A + D, fermi per Ctrl-D):

screen
hosted-engine --deploy

Se vi volas, vi povas ruli la instaladon kun antaŭpreparita responddosiero:

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

Dum deplojado de gastigita motoro, ni specifas ĉiujn necesajn parametrojn:

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

Por instali tre disponeblan VM kun gastigita motoro, ni antaŭe kreis specialan LUN en la stokadsistemo, numero 4 kaj 150 GB en grandeco, kiu tiam estis prezentita al la grapolgastigantoj - vidu antaŭa artikolo.

Antaŭe ni ankaŭ kontrolis ĝian videblecon ĉe gastigantoj:

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

La procezo de deplojo de gastigita motoro mem ne estas komplika; fine ni devus ricevi ion tian:

[ 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

Ni kontrolas la ĉeeston de oVirt-servoj sur la gastiganto:

Se ĉio estis farita ĝuste, tiam post kiam la instalado finiĝos, uzu retumilon por iri al https://ovirt_hostname/ovirt-engine de la komputilo de la administranto, kaj alklaku [Administra Portalo].

Ekrankopio de "Administra Portalo"

Enigante la ensaluton kaj pasvorton (agordita dum la instala procezo) en la fenestron kiel en la ekrankopio, ni alvenas al la kontrolpanelo de Open Virtualization Manager, en kiu vi povas plenumi ĉiujn agojn kun la virtuala infrastrukturo:

aldoni datumcentron
aldoni kaj agordi areton
aldoni kaj administri gastigantojn
aldonu stokajn areojn aŭ Stokajn Domajnojn por virtualaj maŝinaj diskoj
aldoni kaj agordi retojn por virtualaj maŝinoj
aldonu kaj administru virtualajn maŝinojn, instalajn bildojn, VM-ŝablonojn

Ĉiuj ĉi tiuj agoj estos diskutitaj plu, iuj en grandaj ĉeloj, aliaj pli detale kaj kun nuancoj.
Sed unue mi rekomendus legi ĉi tiun aldonaĵon, kiu verŝajne estos utila al multaj.

Suplemento

1) Principe, se ekzistas tia bezono, tiam nenio malhelpas vin instali la KVM-hipervizieron sur la grapolnodoj anticipe uzante pakaĵojn. libreton и qemu-sq.m (aŭ qemu-kvm-ev) de la dezirata versio, kvankam dum deplojado de oVirt-clusternodo, ĝi povas fari tion mem.

Sed se libreton и qemu-sq.m Se vi ne instalis la lastan version, vi eble ricevos la jenan eraron dum deplojado de gastigita motoro:

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

Tiuj. devas havi ĝisdatigita versio libreton kun protekto de MDS, kiu subtenas ĉi tiun politikon:

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

Instalu libvirt v.4.5.0-10.el7_6.12, kun md-clear subteno:

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

Kontrolu pri 'md-clear' subteno:

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

Post ĉi tio, vi povas daŭrigi instali la gastigitan motoron.

2) En oVirt 4.3, la ĉeesto kaj uzo de fajroŝirmilo fajroŝirmilo estas deviga postulo.

Se dum deplojo de VM por gastigita motoro ni ricevas la jenan eraron:

[ 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

Tiam vi devas malŝalti alian fajroŝirmilon (se ĝi estas uzata), kaj instali kaj funkcii fajroŝirmilo:

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

Poste, instalante la ovirt-agenton sur nova gastiganto por la areto, ĝi agordos la postulatajn pordojn enen fajroŝirmilo aŭtomate.

3) Rekomencante gastiganton kun VM funkcianta sur ĝi kun gastigita motoro.

Kiel kutime, ligilo 1 и ligilo 2 al regantaj dokumentoj.

Ĉiu administrado de la gastigita motoro VM estas farita NUR uzante la komandon gastigita-motoro sur la gastiganto kie ĝi kuras, ĉirkaŭ Virsh ni devas forgesi, same kiel la fakton, ke vi povas konekti al ĉi tiu VM per SSH kaj ruli la komandon "haltita".

Proceduro por meti VM en prizorgan reĝimon:

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

Ni rekomencas la gastiganton kun la gastigita motora agento kaj faras tion, kion ni bezonas per ĝi.

Post la rekomenco, kontrolu la staton de la VM kun la gastigita motoro:

hosted-engine --vm-status

Se nia VM kun gastigita-motoro ne komenciĝas kaj se ni vidas similajn erarojn en la serva protokolo:

Eraro en la serva protokolo:

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

Tiam ni konektas la stokadon kaj rekomencas la agenton:

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

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

Post ekfunkciigo de la VM kun gastigita motoro, ni elprenas ĝin el prizorga reĝimo:

Proceduro por forigi VM el prizorga reĝimo:

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) Forigante la gastigitan motoron kaj ĉion rilatan al ĝi.

Foje necesas ĝuste forigi antaŭe instalitan gastigitan motoron - ligilo al la gviddokumento.

Nur rulu la komandon sur la gastiganto:

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

Poste, ni forigas nenecesajn pakaĵojn, sekurigante kelkajn agordojn antaŭ ĉi tio, se necese:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

Kreo de nova datumcentro

Referenca dokumentado - oVirt Administration Guide. Ĉapitro 4: Datumoj

Unue ni difinu kio ĝi estas datumcentro (Mi citas el la helpo) estas logika ento, kiu difinas aron da rimedoj uzataj en specifa medio.

Datumcentro estas speco de ujo konsistanta el:

logikaj rimedoj en la formo de aretoj kaj gastigantoj
amasaj retresursoj en la formo de logikaj retoj kaj fizikaj adaptiloj sur gastigantoj,
stokaj rimedoj (por VM-diskoj, ŝablonoj, bildoj) en la formo de stokejoj (Storage Domains).

Datumcentro povas inkluzivi plurajn aretojn konsistantajn el multoblaj gastigantoj kun virtualaj maŝinoj funkcias sur ili, kaj ĝi ankaŭ povas havi plurajn stokajn areojn asociitajn kun ĝi.
Povas ekzisti pluraj datumcentroj; ili funkcias sendepende unu de la alia. Ovirt havas apartigon de potencoj laŭ rolo, kaj vi povas agordi permesojn individue, kaj ĉe la datumcentro-nivelo kaj sur ĝiaj individuaj logikaj elementoj.

La datumcentro, aŭ datumcentroj se ekzistas pluraj da ili, estas administritaj de ununura administra konzolo aŭ portalo.

Por krei datumcentron, iru al la administra portalo kaj kreu novan datumcentron:
Komputi >> datumoj Centroj >> Nova

Ĉar ni uzas komunan stokadon en la stokadsistemo, la Stokado-Tipo devus esti Kunhavita:

Ekrankopio de la Sorĉisto pri Kreado de Datumoj

Kiam oni instalas virtualan maŝinon kun gastigita motoro, datumcentro estas kreita defaŭlte - Datumcentro1, kaj tiam, se necese, vi povas ŝanĝi ĝian Stokan Tipon al alia.

Krei datumcentron estas simpla tasko, sen malfacilaj nuancoj, kaj ĉiuj aldonaj agoj kun ĝi estas priskribitaj en la dokumentado. La nura afero, kiun mi rimarkos, estas, ke unuopaj gastigantoj, kiuj havas nur lokan stokadon (diskon) por VM-oj, ne povos eniri datumcentron kun Stokado-Tipo - Kunhavita (ili ne povas esti aldonitaj tie), kaj por ili vi devas krei. aparta datumcentro - t.e. Ĉiu individua gastiganto kun loka stokado bezonas sian propran apartan datumcentron.

Kreante novan areton

Ligo al dokumentaro - oVirt Administration Guide. Ĉapitro 5: Aretoj

Sen nenecesaj detaloj, areto – ĉi tio estas logika grupiĝo de gastigantoj, kiuj havas komunan stokan areon (en formo de komunaj diskoj sur konserva sistemo, kiel en nia kazo). Ankaŭ estas dezirinde, ke la gastigantoj en la areto estu identaj en aparataro kaj havu la saman tipon de procesoro (Intel aŭ AMD). Plej bone, kompreneble, ke la serviloj en la areto estas tute identaj.

La areto estas parto de datumcentro (kun specifa speco de stokado - lokaj aŭ dividis), kaj ĉiuj gastigantoj devas aparteni al iu speco de areto, depende ĉu ili havas komunan stokadon aŭ ne.

Kiam oni instalas virtualan maŝinon kun gastigita motoro sur gastiganto, datumcentro estas kreita defaŭlte - Datumcentro1, kune kun la areto - Areto 1, kaj estonte vi povas agordi ĝiajn parametrojn, ebligi pliajn opciojn, aldoni gastigantojn al ĝi, ktp.

Kiel kutime, por detaloj pri ĉiuj cluster-agordoj, estas konsilinde raporti al la oficiala dokumentaro. El kelkaj el la funkcioj de agordo de areto, mi nur aldonos, ke kiam oni kreas ĝin, sufiĉas agordi nur la bazajn parametrojn sur la langeto. Ĝenerala.

Mi notos la plej gravajn parametrojn:

Tipo de procesoro — estas elektita surbaze de kiuj procesoroj estas instalitaj sur la grapolgastigantoj, de kia fabrikanto ili estas, kaj kiu procesoro sur la gastigantoj estas la plej malnova, tiel ke, depende de tio, ĉiuj disponeblaj procesoraj instrukcioj en la areto estas uzataj.
Ŝaltila tipo – en nia areto ni nur uzas Linuksan ponton, tial ni elektas ĝin.
Tipo de fajroŝirmilo – ĉio estas klara ĉi tie, ĉi tio estas firewalld, kiu devas esti ebligita kaj agordita ĉe la gastigantoj.

Ekrankopio kun cluster-parametroj

Instali pliajn gastigantojn en Mem-Gastigita medio

ligilo por dokumentado.

Pliaj gastigantoj por Mem-Gastiga medio estas aldonitaj en la sama maniero kiel regula gastiganto, kun la kroma paŝo de deploji VM kun gastigita motoro - Elektu gastigitan motoran deplojan agon >> Disfaldi. Ĉar la kroma gastiganto ankaŭ devas esti prezentita kun LUN por VM kun gastigita motoro, tio signifas, ke ĉi tiu gastiganto povas, se necese, esti uzata por gastigi VM kun gastigita motoro sur ĝi.
Por faŭltoleremo, estas tre rekomendite ke ekzistas almenaŭ du gastigantoj sur kiuj gastigita motoro VM povas esti metita.

Sur la kroma gastiganto, malŝaltu iptables (se ebligita), ebligu firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Instalu la bezonatan KVM-version (se necese):

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

Instalu la necesajn deponejojn kaj la gastigitan motorinstalilon:

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

Poste, iru al la konzolo Malfermu Virtualization Manager, aldonu novan gastiganton, kaj faru ĉion paŝon post paŝo, kiel enskribite dokumentado.

Kiel rezulto, post aldoni plian gastiganton, ni devus ricevi ion kiel la bildo en la administra konzolo, kiel en la ekrankopio.

Ekrankopio de la administra portalo - gastigantoj

La gastiganto sur kiu la gastigita-motoro VM estas nuntempe aktiva havas oran kronon kaj la surskribon "Kurante la Gastigitan Motoron VM", la gastiganto sur kiu ĉi tiu VM povas esti lanĉita se necese - la surskribo "Povas ruli la Hosted Engine VM".

Okaze de malsukceso de gastiganto sur kiu "Kurante la Gastigitan Motoron VM", ĝi aŭtomate rekomencos sur la dua gastiganto. Ĉi tiu VM ankaŭ povas esti migrita de la aktiva gastiganto al la standby por sia prizorgado.

Agordo de Potenca Administrado / skermado ĉe oVirt-gastigantoj

Dokumentaj ligiloj:

Red Hat Virtualization 4.3 –> Teknika Referenco -> Ĉapitro 4. Potenca Administrado
oVirt Administra Gvidilo -> Ĉapitro 7: Gastigantoj

Kvankam eble ŝajnas, ke vi finis aldoni kaj agordi gastiganton, tio ne estas tute vera.
Por normala funkciado de gastigantoj, kaj por identigi/solvi misfunkciadojn kun iu el ili, estas postulataj agordoj de Potenca Administrado / skermado.

skermado, aŭ skermado, estas la procezo de provizore ekskludo de misa aŭ malsukcesa gastiganto de la areto, dum kiu aŭ la oVirt-servoj sur ĝi aŭ la gastiganto mem estas rekomencitaj.

Ĉiuj detaloj pri la difinoj kaj parametroj de Potenca Administrado / Skermado estas donitaj, kiel kutime, en la dokumentado; Mi nur donos ekzemplon pri kiel agordi ĉi tiun gravan parametron, kiel aplikite al Dell R640-serviloj kun iDRAC 9.

Iru al la administra portalo, alklaku Komputi >> Hostejoj elektu gastiganton.
Klaku redakti.
Alklaku la langeton Potenca Administrado.
Marku la skatolon apud la opcio Ebligu Potencan Administradon.
Marku la skatolon apud la opcio Kdump integriĝopor malhelpi la gastiganton iri en skerman reĝimon dum registrado de kernel-kraŝ-dump.

Notu.

Post ebligo de Kdump-integriĝo sur jam funkcianta gastiganto, ĝi devas esti reinstalita laŭ la proceduro en oVirt Administration Guide -> Ĉapitro 7: Gastigantoj -> Reinstalante Gastigantojn.

Laŭvole, vi povas marki la skatolon Malebligu politikan kontrolon de potenco-administrado, se ni ne volas, ke gastiga potenco-administrado estu kontrolita per la Planadpolitiko de la cluster.
Alklaku la butonon (+) por aldoni novan potencan administradan aparaton, malfermos la redakta fenestro de agentaj proprietoj.
Por iDRAC9, plenigu la kampojn:
- Adreso – adreso iDRAC9
- Uzantnomo / Pasvorto - ensaluto kaj pasvorto por ensaluti en iDRAC9, respektive
- tipo —drac5
- markon sekura
- aldonu la jenajn eblojn: cmd_prompt =>,saluto_timeout=30

Ekrankopio kun parametroj "Potenca Administrado" en gastigaj propraĵoj

Kreante stokejon aŭ Stokado-Domajnojn

Ligo al dokumentaro - oVirt Administration Guide, Ĉapitro 8: Stokado.

Stokado Domajno, aŭ stokejo, estas alcentrigita loko por stoki virtualajn maŝindiskojn, instalbildojn, ŝablonojn kaj momentfotojn.

Stokejoj povas esti konektitaj al la datumcentro uzante diversajn protokolojn, aretojn kaj retajn dosiersistemojn.

oVirt havas tri specojn de stokado:

Datuma Domajno – stoki ĉiujn datumojn asociitajn kun virtualaj maŝinoj (diskoj, ŝablonoj). Datuma Domajno ne povas esti dividita inter malsamaj datumcentroj.
ISO-Domajno (malnoviĝinta speco de stokado) - por stoki OS-instalajn bildojn. ISO-Domajno povas esti dividita inter malsamaj datumcentroj.
Eksporto-Domajno (malnoviĝinta speco de stokado) - por provizora stokado de bildoj movitaj inter datencentroj.

En nia aparta kazo, stokado kun la Data Domain-tipo uzas Fibre Channel Protocol (FCP) por konekti al LUN-oj en la stokadsistemo.

El la vidpunkto de oVirt, kiam oni uzas stoksistemojn (FC aŭ iSCSI), ĉiu virtuala disko, momentfoto aŭ ŝablono estas logika disko.
Blokaj aparatoj estas kunvenitaj en ununuran unuon (sur clustergastigantoj) uzante Volume Group kaj tiam dividitaj uzante LVM en logikaj volumoj, kiuj estas utiligitaj kiel virtualaj diskoj por VMoj.

Ĉiuj ĉi tiuj grupoj kaj multaj LVM-volumoj povas esti viditaj sur la cluster-gastiganto uzante la komandojn ktp и lvs. Kompreneble, ĉiuj agoj kun tiaj diskoj devas esti faritaj nur de la oVirt-konzolo, krom en specialaj kazoj.

Virtualaj diskoj por VMs povas esti de du tipoj - QCOW2 aŭ RAW. Diskoj povas esti "maldika" aŭ "dika". Momentfotoj estas ĉiam kreitaj kiel "maldika".

La maniero administri Stokajn domajnojn, aŭ stokajn areojn alireblajn per FC, estas sufiĉe logika - por ĉiu VM virtuala disko ekzistas aparta logika volumeno, kiu estas skribebla de nur unu gastiganto. Por FC-konektoj, oVirt uzas ion kiel amasigita LVM.

Virtualaj maŝinoj situantaj sur la sama stokejo povas esti migritaj inter gastigantoj apartenantaj al la sama areto.

Kiel ni povas vidi el la priskribo, areto en oVirt, kiel areto en VMware vSphere aŭ Hyper-V, esence signifas la samon - ĝi estas logika grupiĝo de gastigantoj, prefere identaj en aparataro kunmetaĵo, kaj havanta komunan stokadon por virtuala. maŝindiskoj.

Ni iru rekte al kreado de stokado por datumoj (VM-diskoj), ĉar sen ĝi la datumcentro ne estos pravigita.
Mi memorigu vin, ke ĉiuj LUN-oj prezentitaj al la grapolgastigantoj en la stokadsistemo devas esti videblaj sur ili per la komando "plurvoja -ll".

Laŭ dokumentado, iru al la portalo iru al stokado >> domajnoj -> Nova Domajno kaj sekvu la instrukciojn de la sekcio "Aldono de FCP-Stokado".

Post lanĉo de la sorĉisto, plenigu la postulatajn kampojn:

Nomo — agordu la clusternomon
Domajna Funkcio — Datumoj
Stokadotipo - Fibra Kanalo
Gastiganto por Uzo — elektu gastiganton sur kiu la LUN, kiun ni postulas, estas disponebla

En la listo de LUN-oj, marku tiun, kiun ni bezonas, alklaku Aldoni kaj tiam OK. Se necese, vi povas ĝustigi pliajn parametrojn de la stokado per alklako Altnivelaj Parametroj.

Ekrankopio de la sorĉisto por aldoni "Stoka domajno"

Surbaze de la rezultoj de la sorĉisto, ni devus ricevi novan stokejon, kaj nia datumcentro devus moviĝi al la statuso UP, aŭ pravalorigita:

Ekrankopioj de la datumcentro kaj stokejoj en ĝi:

Krei kaj agordi retojn por virtualaj maŝinoj

Ligo al dokumentaro - oVirt Administration Guide, Ĉapitro 6: Logikaj Retoj

Retoj, aŭ retoj, servas por grupigi logikajn retojn uzatajn en la virtuala infrastrukturo oVirt.

Por interagi inter la retadaptilo sur la virtuala maŝino kaj la fizika adaptilo sur la gastiganto, logikaj interfacoj kiel Linukso-ponto estas uzataj.

Por grupigi kaj dividi trafikon inter retoj, VLANoj estas agorditaj sur la ŝaltiloj.

Kiam oni kreas logikan reton por virtualaj maŝinoj en oVirt, oni devas atribui al ĝi identigilon respondan al la VLAN-nombro sur la ŝaltilo, por ke la VM-oj povu komuniki inter si, eĉ se ili funkcias sur malsamaj nodoj de la areto.

Antaŭaj agordoj de retadaptiloj sur gastigantoj por konekti virtualajn maŝinojn devis esti faritaj antaŭa artikolo - logika interfaco agordita obligacio1, tiam ĉiuj retaj agordoj devas esti faritaj nur per la administra portalo oVirt.

Post kreado de VM kun gastigita motoro, krom la aŭtomata kreado de datumcentro kaj areto, ankaŭ aŭtomate kreis logika reto por administri nian areton - ovritmgmt, al kiu ĉi tiu VM estis konektita.

Se necese, vi povas vidi la logikan retajn agordojn ovritmgmt kaj alĝustigu ilin, sed vi devas zorgi por ne perdi kontrolon de la infrastrukturo de oVirt.

Logikaj retaj agordoj ovritmgmt

Por krei novan logikan reton por regulaj VM-oj, en la administra portalo iru al reto >> retoj >> Nova, kaj sur la langeto Ĝenerala aldonu reton kun la dezirata VLAN-ID, kaj ankaŭ marku la skatolon apud "VM-reto", tio signifas, ke ĝi povas esti uzata por asigno al VM.

Ekrankopio de la nova VLAN32-logika reto

En la langeto areto, ni kunligas ĉi tiun reton al nia areto Areto 1.

Post ĉi tio ni iras al Komputi >> Hostejoj, iru al ĉiu gastiganto laŭvice, al la langeto Retaj interfacoj, kaj lanĉu la sorĉiston Agordu gastigajn retojn, por ligi al gastigantoj de nova logika reto.

Ekrankopio de la sorĉisto "Agordu gastigajn retojn".

La oVirt-agento aŭtomate faros ĉiujn necesajn retajn agordojn sur la gastiganto - kreu VLAN kaj PONTON.

Ekzemplaj agordaj dosieroj por novaj retoj sur la gastiganto:

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

Permesu al mi rememorigi vin denove tion sur la cluster-gastiganto NE NECESAS kreu retajn interfacojn mane anticipe ifcfg-obligacio1.432 и ifcfg-ovirtvm-vlan432.

Post aldoni logikan reton kaj kontroli la konekton inter la gastiganto kaj la gastigita motoro VM, ĝi povas esti uzata en la virtuala maŝino.

Krei instalaĵbildon por deploji virtualan maŝinon

Ligo al dokumentaro - oVirt Administration Guide, Ĉapitro 8: Stokado, sekcio Alŝuti Bildojn al Datuma Stokado-Domajno.

Sen OS-instala bildo, ne eblos instali virtualan maŝinon, kvankam ĉi tio kompreneble ne estas problemo se, ekzemple, estas instalita en la reto. Flikisto kun antaŭkreitaj bildoj.

En nia kazo, tio ne eblas, do vi devos mem importi ĉi tiun bildon en oVirt. Antaŭe, tio postulis krei ISO-Domajnon, sed en la nova versio de oVirt ĝi estis malrekomendita, kaj tial vi nun povas alŝuti bildojn rekte al la Stokado-domajno de la administra portalo.

En la administra portalo iru al stokado >> diskoj >> alŝuto >> komenco
Ni aldonas nian OS-bildon kiel ISO-dosieron, plenigu ĉiujn kampojn en la formularo kaj alklaku la butonon "Testa konekto".

Ekrankopio de la Aldoni Instala Bildo-Sorĉisto

Se ni ricevas eraron kiel ĉi tio:

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`

Tiam vi devas aldoni la oVirt-atestilon al "Fidindaj Radikaj CAoj"(Trusted Root CA) sur la kontrolstacio de la administranto, de kie ni provas elŝuti la bildon.

Post aldoni la atestilon al la Fidinda Radika CA, alklaku denove "Testa konekto", devus ricevi:

Connection to ovirt-imageio-proxy was successful.

Post kiam vi kompletigas la agon aldoni la atestilon, vi povas denove provi alŝuti la ISO-bildon al la Stoka Domajno.

Principe, vi povas fari apartan Stokan Domajnon kun la Datuma tipo por stoki bildojn kaj ŝablonojn aparte de VM-diskoj, aŭ eĉ stoki ilin en Stokado-Domajno por la gastigita motoro, sed ĉi tio estas laŭ la bontrovo de la administranto.

Ekrankopio kun ISO-bildoj en Stokado-Domajno por gastigita motoro

Kreu virtualan maŝinon

Dokumenta ligilo:
oVirt Virtual Machine Management Guide -> Ĉapitro 2: Instalado de Linukso Virtualaj Maŝinoj
Rimedoj de Konzolaj Klientoj

Post ŝarĝo de la instala bildo kun la OS en oVirt, vi povas rekte krei virtualan maŝinon. Multe da laboro estas farita, sed ni jam estas en la fina etapo, pro kiu ĉio ĉi estis komencita - akiri misfunkcian infrastrukturon por gastigi tre disponeblajn virtualajn maŝinojn. Kaj ĉio ĉi estas absolute senpaga - eĉ ne unu penco estis elspezita por aĉeti iujn ajn programarlicencojn.

Por krei virtualan maŝinon kun CentOS 7, la instala bildo de la OS devas esti elŝutita.

Ni iru al la administra portalo, iru al Komputi >> Virtualaj maŝinoj, kaj lanĉu la VM-kreadsorĉiston. Plenigu ĉiujn parametrojn kaj kampojn kaj alklaku OK. Ĉio estas tre simpla se vi sekvas la dokumentadon.

Kiel ekzemplo, mi donos la bazajn kaj kromajn agordojn de tre disponebla VM, kun kreita disko, konektita al la reto, kaj ekŝarganta de instala bildo:

Ekrankopioj kun tre disponeblaj VM-agordoj

Post fino de laboro kun la sorĉisto, fermu ĝin, lanĉu novan VM kaj instalu la OS sur ĝi.
Por fari tion, iru al la konzolo de ĉi tiu VM per la administra portalo:

Ekrankopio de la administraj portalaj agordoj por konektiĝi al la VM-konzolo

Por konektiĝi al la VM-konzolo, vi unue devas agordi la konzolon en la propraĵoj de la virtuala maŝino.

Ekrankopio de VM-agordoj, langeto "Konzolo".

Por konektiĝi al la VM-konzolo vi povas uzi, ekzemple, Vidilo de Virtuala Maŝino.

Por konektiĝi al la VM-konzolo rekte en la retumila fenestro, la konekto-agordoj per la konzolo devus esti jenaj:

Post instalo de la OS sur la VM, estas konsilinde instali oVirt-gastagenton:

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

Tiel, kiel rezulto de niaj agoj, la kreita VM estos tre disponebla, t.e. se la grapolnodo sur kiu ĝi funkcias malsukcesas, oVirt aŭtomate rekomencos ĝin sur la dua nodo. Ĉi tiu VM ankaŭ povas esti migrita inter cluster-gastigantoj por ilia bontenado aŭ aliaj celoj.

konkludo

Mi esperas, ke ĉi tiu artikolo sukcesis transdoni, ke oVirt estas tute normala ilo por administri virtualan infrastrukturon, kiu ne estas tiel malfacila disfaldi - la ĉefa afero estas sekvi iujn regulojn kaj postulojn priskribitajn kaj en la artikolo kaj en la dokumentado.

Pro la granda volumo de la artikolo, ne eblis enmeti multajn aferojn en ĝi, kiel paŝon post paŝo ekzekuto de diversaj sorĉistoj kun ĉiuj detalaj klarigoj kaj ekrankopioj, longaj konkludoj de iuj ordonoj ktp. Fakte, tio postulus verki tutan libron, kio ne havas multe da senco pro novaj versioj de programaro senĉese aperantaj kun novigoj kaj ŝanĝoj. La plej grava afero estas kompreni la principon de kiel ĉio funkcias kune, kaj akiri ĝeneralan algoritmon por krei mistoleran platformon por administri virtualajn maŝinojn.

Kvankam ni kreis virtualan infrastrukturon, ni nun devas instrui ĝin interagi ambaŭ inter ĝiaj individuaj elementoj: gastigantoj, virtualaj maŝinoj, internaj retoj, kaj kun la ekstera mondo.

Ĉi tiu procezo estas unu el la ĉefaj taskoj de administranto de sistemo aŭ reto, kiu estos traktata en la sekva artikolo - pri la uzo de virtualaj enkursigiloj VyOS en la misfunkcia infrastrukturo de nia entrepreno (kiel vi divenis, ili funkcios kiel virtualaj). maŝinoj sur nia oVirt-grupo).

fonto: www.habr.com

Kreado de mistolerema IT-infrastrukturo. Parto 2. Instalado kaj agordo de la oVirt 4.3-grupo