🥇Oprettelse af en fejltolerant IT-infrastruktur. Del 2. Installation og konfiguration af oVirt 4.3 cluster

Denne artikel er en fortsættelse af den forrige - "Oprettelse af fejltolerant IT-infrastruktur. Del 1 - Forberedelse til implementering af en oVirt 4.3-klynge'.

Det vil dække processen med grundlæggende installation og konfiguration af en oVirt 4.3-klynge til hosting af meget tilgængelige virtuelle maskiner, idet der tages højde for det faktum, at alle indledende trin til forberedelse af infrastrukturen allerede er afsluttet tidligere.

prodrom

Hovedformålet med artiklen er at give trin-for-trin instruktioner som "Næste -> Ja -> Finish"hvordan du viser nogle funktioner, når du installerer og konfigurerer det. Processen til at implementere din klynge falder muligvis ikke altid sammen med den, der er beskrevet i den, på grund af infrastrukturens og miljøets karakteristika, men de generelle principper vil være de samme.

Fra et subjektivt synspunkt, oVirt 4.3 dens funktionalitet ligner VMware vSphere version 5.x, men selvfølgelig med sine egne konfigurations- og betjeningsfunktioner.

For de interesserede kan alle forskellene mellem RHEV (aka oVirt) og VMware vSphere findes på internettet, f.eks. her, men jeg vil stadig af og til bemærke nogle af deres forskelle eller ligheder med hinanden, efterhånden som artiklen skrider frem.

Separat vil jeg gerne sammenligne lidt arbejdet med netværk til virtuelle maskiner. oVirt implementerer et lignende princip for netværksstyring for virtuelle maskiner (herefter benævnt VM'er), som i VMware vSphere:

ved at bruge en standard Linux-bro (i VMware - Standard vSwitch), kører på virtualiseringsværter;
ved hjælp af Open vSwitch (OVS) (i VMware - Distribueret vSwitch) er en distribueret virtuel switch, der består af to hovedkomponenter: en central OVN-server og OVN-controllere på administrerede værter.

Det skal bemærkes, at på grund af den lette implementering, vil artiklen beskrive opsætning af netværk i oVirt til en VM ved hjælp af en standard Linux-bro, som er standardvalget ved brug af KVM-hypervisoren.

I denne forbindelse er der flere grundlæggende regler for at arbejde med netværket i en klynge, som er bedst ikke at blive overtrådt:

Alle netværksindstillinger på værter, før de tilføjes til oVirt, skal være identiske, undtagen IP-adresser.
Når først en vært er blevet taget under kontrol af oVirt, anbefales det stærkt ikke at ændre noget manuelt i netværksindstillingerne uden fuldstændig tillid til dine handlinger, da oVirt-agenten blot vil rulle dem tilbage til de tidligere efter genstart af værten eller agent.
Tilføjelse af et nyt netværk til en VM, samt arbejde med det, bør kun ske fra oVirt-administrationskonsollen.

En anden vigtig note — for et meget kritisk miljø (meget følsomt over for monetære tab), vil det stadig blive anbefalet at bruge betalt support og brug Red Hat Virtualization 4.3. Under driften af oVirt-klyngen kan der opstå nogle problemer, som det er tilrådeligt at få kvalificeret hjælp til så hurtigt som muligt i stedet for selv at løse dem.

Og endelig anbefales Før du implementerer en oVirt-klynge, skal du gøre dig bekendt med officiel dokumentation, for i det mindste at være bevidst om de grundlæggende begreber og definitioner, ellers bliver det lidt svært at læse resten af artiklen.

Grundlæggende for at forstå artiklen og principperne for driften af oVirt-klyngen er disse vejledningsdokumenter:

Volumen der er ikke særlig stor, på en time eller to kan du ret mestre de grundlæggende principper, men for dem, der kan lide detaljer, anbefales det at læse Produktdokumentation til Red Hat Virtualization 4.3 — RHEV og oVirt er grundlæggende det samme.

Så hvis alle de grundlæggende indstillinger på værterne, switchene og lagersystemerne er blevet gennemført, går vi direkte videre til udrulningen af oVirt.

Del 2. Installation og konfiguration af oVirt 4.3-klyngen

For at lette orienteringen vil jeg liste hovedafsnittene i denne artikel, som skal udfyldes én efter én:

Installation af oVirt-administrationsserveren
Oprettelse af nyt datacenter
Oprettelse af en ny klynge
Installation af yderligere værter i et Self-Hosted miljø
Oprettelse af et lagerområde eller Storage Domains
Oprettelse og konfiguration af netværk til virtuelle maskiner
Oprettelse af et installationsbillede til implementering af en virtuel maskine
Opret en virtuel maskine

Installation af oVirt-administrationsserveren

oVirt management server er det vigtigste element i oVirt-infrastrukturen, i form af en virtuel maskine, vært eller virtuel enhed, der styrer hele oVirt-infrastrukturen.

Dens nære analoger fra virtualiseringens verden er:

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

For at installere oVirt-administrationsserveren har vi to muligheder:

Mulighed 1
Implementering af en server i form af en specialiseret VM eller vært.

Denne mulighed fungerer ganske godt, men forudsat at sådan en VM fungerer uafhængigt af klyngen, dvs. kører ikke på nogen klyngevært som en almindelig virtuel maskine, der kører KVM.

Hvorfor kan sådan en VM ikke implementeres på klyngeværter?

Allerede i begyndelsen af processen med at implementere oVirt-administrationsserveren har vi et dilemma - vi skal installere en management-VM, men faktisk er der ingen klynge i sig selv endnu, og hvad kan vi derfor finde på i farten? Det er rigtigt - installer KVM på en fremtidig klynge node, opret derefter en virtuel maskine på den, for eksempel med CentOS OS, og implementer oVirt-motoren i den. Dette kan normalt gøres af hensyn til fuldstændig kontrol over sådan en VM, men dette er en fejlagtig hensigt, for i dette tilfælde vil der i fremtiden være 100 % problemer med en sådan kontrol VM:

det kan ikke migreres i oVirt-konsollen mellem værter (knudepunkter) i klyngen;
ved migrering ved hjælp af KVM via virsh migrere, vil denne VM ikke være tilgængelig for administration fra oVirt-konsollen.
klyngeværter kan ikke vises i Vedligeholdelsestilstand (vedligeholdelsestilstand), hvis du migrerer denne VM fra vært til vært ved hjælp af virsh migrere.

Så gør alt i henhold til reglerne - brug enten en separat vært til oVirt-administrationsserveren eller en uafhængig VM, der kører på den, eller endnu bedre, gør som skrevet i den anden mulighed.

Mulighed 2
Installation af oVirt Engine Appliance på en klyngevært, der administreres af den.

Det er denne mulighed, der vil blive betragtet som mere korrekt og egnet i vores tilfælde.
Kravene til en sådan VM er beskrevet nedenfor, jeg vil kun tilføje, at det anbefales at have mindst to værter i infrastrukturen, som kontrol VM'en kan køres på, for at gøre den fejltolerant. Her vil jeg gerne tilføje, at jeg, som jeg allerede skrev i kommentarerne i den forrige artikel, aldrig var i stand til at få splitbrain på en oVirt-klynge af to værter med mulighed for at køre VM'er med hostede motorer på dem.

Installation af oVirt Engine Appliance på den første vært i klyngen

Link til officiel dokumentation - oVirt Self-Hosted Engine Guide, kapitel "Implementering af den selvhostede motor ved hjælp af kommandolinjen»

Dokumentet specificerer de forudsætninger, der skal være opfyldt, før en hosted-engine VM implementeres, og beskriver også i detaljer selve installationsprocessen, så det nytter ikke meget at gentage det ordret, så vi vil fokusere på nogle vigtige detaljer.

Før du starter alle handlinger, skal du sørge for at aktivere virtualiseringsunderstøttelse i BIOS-indstillingerne på værten.
Installer pakken til hosted-engine-installationsprogrammet på værten:

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

Vi starter proceduren for implementering af oVirt Hosted Engine på skærmen på værten (du kan afslutte den via Ctrl-A + D, luk via Ctrl-D):

screen
hosted-engine --deploy

Hvis du ønsker det, kan du køre installationen med en på forhånd forberedt svarfil:

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

Når vi implementerer hosted-engine, angiver vi alle de nødvendige parametre:

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

For at installere en høj tilgængelig VM med en hostet motor, lavede vi tidligere en speciel LUN på lagersystemet, nummer 4 og 150 GB i størrelse, som derefter blev præsenteret for klyngeværterne - se forrige artikel.

Tidligere har vi også tjekket dets synlighed på værter:

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

Selve hosted-engine-implementeringsprocessen er ikke kompliceret; i slutningen skulle vi modtage noget som dette:

[ 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

Vi kontrollerer tilstedeværelsen af oVirt-tjenester på værten:

Hvis alt blev gjort korrekt, så brug en webbrowser til at gå til efter installationen er fuldført https://ovirt_hostname/ovirt-engine fra administratorens computer, og klik på [Administrationsportal].

Skærmbillede af "Administrationsportal"

Ved at indtaste login og adgangskode (indstillet under installationsprocessen) i vinduet som på skærmbilledet, kommer vi til Open Virtualization Manager kontrolpanelet, hvor du kan udføre alle handlinger med den virtuelle infrastruktur:

tilføje datacenter
tilføje og konfigurere en klynge
tilføje og administrere værter
tilføje lagerområder eller lagerdomæner til virtuelle maskindiske
tilføje og konfigurere netværk til virtuelle maskiner
tilføje og administrere virtuelle maskiner, installationsbilleder, VM-skabeloner

Alle disse handlinger vil blive diskuteret yderligere, nogle i store celler, andre mere detaljeret og med nuancer.
Men først vil jeg anbefale at læse denne tilføjelse, som nok vil være nyttig for mange.

Addition

1) I princippet, hvis der er et sådant behov, så forhindrer intet dig i at installere KVM-hypervisoren på klyngeknuderne på forhånd ved hjælp af pakker libvirt и qemu-kvm (eller qemu-kvm-ev) af den ønskede version, men når den installerer en oVirt-klyndeknude, kan den gøre dette selv.

Men hvis libvirt и qemu-kvm Hvis du ikke har installeret den seneste version, får du muligvis følgende fejlmeddelelse, når du installerer en hostet motor:

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

De der. må have opdateret version libvirt med beskyttelse fra MDS, som understøtter denne politik:

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

Installer libvirt v.4.5.0-10.el7_6.12 med md-clear-understøttelse:

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

Tjek for 'md-clear'-understøttelse:

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

Herefter kan du fortsætte med at installere den hostede motor.

2) I oVirt 4.3, tilstedeværelsen og brugen af en firewall firewalld er et obligatorisk krav.

Hvis vi under udrulning af en VM til hosted-engine modtager følgende fejl:

[ 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

Så skal du slukke for en anden firewall (hvis den bruges), og installere og køre 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

Senere, når ovirt-agenten installeres på en ny vært for klyngen, vil den konfigurere de nødvendige porte i firewalld automatisk.

3) Genstart af en vært med en VM kørende på den med en hostet motor.

Normalt, link 1 и link 2 til styrende dokumenter.

Al administration af den hostede motor VM udføres KUN ved hjælp af kommandoen hosted-motor på værten hvor den kører, ca Virsh vi skal glemme, såvel som det faktum, at du kan oprette forbindelse til denne VM via SSH og køre kommandoen "nedlukning'.

Fremgangsmåde for at sætte en VM i vedligeholdelsestilstand:

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

Vi genstarter værten med den hostede motoragent og gør, hvad vi har brug for med den.

Efter genstart skal du kontrollere status for VM'en med den hostede motor:

hosted-engine --vm-status

Hvis vores VM med hosted-motor ikke starter, og hvis vi ser lignende fejl i serviceloggen:

Fejl i serviceloggen:

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

Derefter forbinder vi lageret og genstarter agenten:

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

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

Efter at have startet VM'en med hostet motor, tager vi den ud af vedligeholdelsestilstand:

Fremgangsmåde for at fjerne en VM fra vedligeholdelsestilstand:

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) Fjernelse af den hostede motor og alt, der er forbundet med den.

Nogle gange er det nødvendigt at fjerne en tidligere installeret hostet motor korrekt - link til vejledningen.

Bare kør kommandoen på værten:

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

Dernæst fjerner vi unødvendige pakker og sikkerhedskopierer nogle konfigurationer før dette, hvis det er nødvendigt:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

Oprettelse af nyt datacenter

Referencedokumentation - oVirt Administration Guide. Kapitel 4: Datacentre

Lad os først definere, hvad det er datacenter (Jeg citerer fra hjælpen) er en logisk enhed, der definerer et sæt ressourcer, der bruges i et specifikt miljø.

Et datacenter er en slags container bestående af:

logiske ressourcer i form af klynger og værter
klynge netværksressourcer i form af logiske netværk og fysiske adaptere på værter,
lagerressourcer (til VM-diske, skabeloner, billeder) i form af lagerområder (Storage Domains).

Et datacenter kan omfatte flere klynger, der består af flere værter med virtuelle maskiner, der kører på dem, og det kan også have flere lagerområder tilknyttet.
Der kan være flere datacentre, de fungerer uafhængigt af hinanden. Ovirt har en adskillelse af beføjelser efter rolle, og du kan konfigurere tilladelser individuelt, både på datacenterniveau og på dets individuelle logiske elementer.

Datacentret, eller datacentre, hvis der er flere af dem, administreres fra en enkelt administrativ konsol eller portal.

For at oprette et datacenter skal du gå til den administrative portal og oprette et nyt datacenter:
Compute >> datacentre >> Ny

Da vi bruger delt lager på lagersystemet, skal lagertypen være delt:

Skærmbillede af guiden til oprettelse af datacenter

Når du installerer en virtuel maskine med hosted-engine, oprettes et datacenter som standard - Datacenter 1, og derefter, om nødvendigt, kan du ændre dens lagertype til en anden.

Oprettelse af et datacenter er en simpel opgave, uden nogen vanskelige nuancer, og alle yderligere handlinger med det er beskrevet i dokumentationen. Det eneste, jeg vil bemærke, er, at enkelte værter, der kun har lokal lagring (disk) til VM'er, ikke vil være i stand til at komme ind i et datacenter med Storage Type - Shared (de kan ikke tilføjes der), og for dem skal du oprette et separat datacenter - dvs. Hver enkelt vært med lokal lagring har brug for sit eget separate datacenter.

Oprettelse af en ny klynge

Link til dokumentation - oVirt Administration Guide. Kapitel 5: Klynger

Uden unødvendige detaljer, klynge – dette er en logisk gruppering af værter, der har et fælles lagerområde (i form af delte diske på et lagersystem, som i vores tilfælde). Det er også ønskeligt, at værterne i klyngen er identiske i hardware og har samme type processor (Intel eller AMD). Det er selvfølgelig bedst, at serverne i klyngen er fuldstændig identiske.

Klyngen er en del af et datacenter (med en bestemt type lager - Lokale eller delt), og alle værter skal tilhøre en slags klynge, afhængigt af om de har delt lager eller ej.

Når du installerer en virtuel maskine med en hostet motor på en vært, oprettes et datacenter som standard - Datacenter 1sammen med klyngen – Klynge1, og i fremtiden kan du konfigurere dens parametre, aktivere yderligere muligheder, tilføje værter til den osv.

Som sædvanligt, for detaljer om alle klyngeindstillinger, er det tilrådeligt at henvise til den officielle dokumentation. Af nogle af funktionerne ved opsætning af en klynge vil jeg kun tilføje, at når du opretter den, er det nok kun at konfigurere de grundlæggende parametre på fanen Generelt.

Jeg vil bemærke de vigtigste parametre:

Processortype — vælges ud fra hvilke processorer, der er installeret på klyngeværterne, hvilken producent de er fra, og hvilken processor på værterne der er den ældste, så afhængigt af dette bruges alle tilgængelige processorinstruktioner i klyngen.
Skiftetype – i vores klynge bruger vi kun Linux bridge, det er derfor vi vælger det.
Firewall type – alt er klart her, dette er firewalld, som skal aktiveres og konfigureres på værterne.

Skærmbillede med klyngeparametre

Installation af yderligere værter i et Self-Hosted miljø

Link til dokumentation.

Yderligere værter til et Self-Hosted-miljø tilføjes på samme måde som en almindelig vært, med det ekstra trin at implementere en VM med en hostet motor - Vælg en hostet motorimplementeringshandling >> Implementer. Da den ekstra vært også skal præsenteres med et LUN for en VM med en hostet motor, betyder det, at denne vært om nødvendigt kan bruges til at hoste en VM med en hostet motor på.
Af fejltoleranceformål anbefales det stærkt, at der er mindst to værter, hvorpå en hostet motor VM kan placeres.

På den ekstra vært, deaktiver iptables (hvis aktiveret), aktiver firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installer den nødvendige KVM-version (hvis nødvendigt):

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

Installer de nødvendige lagre og det hostede motorinstallationsprogram:

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

Gå derefter til konsollen Åbn Virtualization Manager, tilføj en ny vært, og gør alt trin for trin, som skrevet i dokumentation.

Som et resultat, efter at have tilføjet en ekstra vært, skulle vi få noget som billedet i den administrative konsol, som på skærmbilledet.

Skærmbillede af den administrative portal - værter

Værten, som den hostede motor VM er aktiv på i øjeblikket, har en guldkrone og inskriptionen "Kørsel af Hosted Engine VM", værten, som denne VM kan lanceres på om nødvendigt - inskriptionen "Kan køre Hosted Engine VM'.

I tilfælde af en værtsfejl, hvor "Kørsel af Hosted Engine VM", genstarter den automatisk på den anden vært. Denne VM kan også migreres fra den aktive vært til standby-værten for dens vedligeholdelse.

Opsætning af strømstyring / hegn på oVirt-værter

Dokumentationslinks:

Red Hat Virtualization 4.3 –> Teknisk reference -> Kapitel 4. Strømstyring
oVirt Administration Guide -> Kapitel 7: Værter

Selvom det kan virke som om du er færdig med at tilføje og konfigurere en vært, er det ikke helt sandt.
For normal drift af værter og for at identificere/afhjælpe fejl med nogen af dem, kræves strømstyrings-/hegnindstillinger.

Fægtning, eller hegn, er processen med midlertidigt at ekskludere en defekt eller fejlbehæftet vært fra klyngen, hvor enten oVirt-tjenesterne på den eller selve værten genstartes.

Alle detaljer om definitionerne og parametrene for strømstyring/indhegning er som sædvanligt givet i dokumentationen; Jeg vil kun give et eksempel på, hvordan man konfigurerer denne vigtige parameter, som anvendt på Dell R640-servere med iDRAC 9.

Gå til den administrative portal, klik Compute >> værter vælg en vært.
Klik Redigere.
Klik på fanen Power Management.
Marker afkrydsningsfeltet ud for indstillingen Aktiver strømstyring.
Marker afkrydsningsfeltet ud for indstillingen Kdump integrationfor at forhindre værten i at gå i hegnstilstand, mens der optages et kernenedbrudsdump.

Bemærk.

Efter at have aktiveret Kdump-integration på en allerede kørende vært, skal den geninstalleres i henhold til proceduren i oVirt Administration Guide -> Kapitel 7: Værter -> Geninstallation af værter.

Du kan eventuelt markere afkrydsningsfeltet Deaktiver politikkontrol af strømstyring, hvis vi ikke ønsker, at værtsstrømstyring skal kontrolleres af klyngens planlægningspolitik.
Klik på knappen (+) for at tilføje en ny strømstyringsenhed, åbnes vinduet til redigering af agentegenskaber.
For iDRAC9 skal du udfylde felterne:
- Adresse – iDRAC9-adresse
- Brugernavn Kodeord – henholdsvis login og adgangskode til at logge på iDRAC9
- Type — drac5
- mark Sikkert
- tilføje følgende muligheder: cmd_prompt=>, login_timeout=30

Skærmbillede med "Power Management"-parametre i værtsegenskaber

Oprettelse af et lagerområde eller Storage Domains

Link til dokumentation - oVirt Administration Guide, Kapitel 8: Opbevaring.

Lagerdomæne, eller lagerområde, er en central placering til lagring af virtuelle maskine-diske, installationsbilleder, skabeloner og snapshots.

Lagerområder kan forbindes til datacentret ved hjælp af forskellige protokoller, klynge- og netværksfilsystemer.

oVirt har tre typer opbevaringsområde:

Datadomæne – at gemme alle data forbundet med virtuelle maskiner (diske, skabeloner). Datadomæne kan ikke deles mellem forskellige datacentre.
ISO domæne (forældet type lagerområde) – til lagring af OS installationsbilleder. ISO Domain kan deles mellem forskellige datacentre.
Eksporter domæne (forældet type lagerområde) – til midlertidig lagring af billeder flyttet mellem datacentre.

I vores særlige tilfælde bruger et lagerområde med typen Data Domain Fibre Channel Protocol (FCP) til at oprette forbindelse til LUN'er på lagersystemet.

Fra oVirts synspunkt, når du bruger lagersystemer (FC eller iSCSI), er hver virtuel disk, snapshot eller skabelon en logisk disk.
Blok-enheder samles til en enkelt enhed (på klyngeværter) ved hjælp af Volume Group og opdeles derefter ved hjælp af LVM i logiske volumener, som bruges som virtuelle diske til VM'er.

Alle disse grupper og mange LVM-volumener kan ses på klyngeværten ved hjælp af kommandoerne etc и LVS. Naturligvis bør alle handlinger med sådanne diske kun udføres fra oVirt-konsollen, undtagen i særlige tilfælde.

Virtuelle diske til VM'er kan være af to typer - QCOW2 eller RAW. Diske kan være "tynd"eller"tyk". Snapshots oprettes altid som "tynd".

Måden at administrere Storage-domæner eller lagerområder, der tilgås via FC, er ret logisk - for hver virtuelle VM-disk er der en separat logisk volumen, som kun kan skrives af én vært. Til FC-forbindelser bruger oVirt noget som clustered LVM.

Virtuelle maskiner placeret på det samme lagerområde kan migreres mellem værter, der tilhører den samme klynge.

Som vi kan se af beskrivelsen, betyder en klynge i oVirt, ligesom en klynge i VMware vSphere eller Hyper-V, i det væsentlige det samme - det er en logisk gruppering af værter, fortrinsvis identiske i hardwaresammensætning, og som har fælles lagring til virtuel maskindiske.

Lad os fortsætte direkte med at oprette et lagerområde for data (VM-diske), da uden det vil datacentret ikke blive initialiseret.
Lad mig minde dig om, at alle LUN'er, der præsenteres for klyngeværterne på lagersystemet, skal være synlige på dem ved hjælp af kommandoen "multipath -ll'.

Ifølge dokumentation, gå til portalen gå til Opbevaring >> domæner -> Nyt domæne og følg instruktionerne fra afsnittet "Tilføjelse af FCP-lager".

Efter at have startet guiden, udfyld de påkrævede felter:

Navn — indstil klyngenavnet
Domæne funktion -Data
Opbevaringstype - Fiberkanal
Vært til brug — vælg en vært, hvor den LUN, vi har brug for, er tilgængelig

Marker den, vi har brug for, på listen over LUN'er, klik Tilføj og så ОК. Om nødvendigt kan du justere yderligere parametre for lagerområdet ved at klikke på Avancerede parametre.

Skærmbillede af guiden til tilføjelse af "Lagringsdomæne"

Baseret på resultaterne af guiden skulle vi modtage et nyt lagerområde, og vores datacenter skulle flytte til status UP, eller initialiseret:

Skærmbilleder af datacentret og lagerområder i det:

Oprettelse og konfiguration af netværk til virtuelle maskiner

Link til dokumentation - oVirt Administration Guide, Kapitel 6: Logiske netværk

Netværk eller netværk tjener til at gruppere logiske netværk, der bruges i den virtuelle oVirt-infrastruktur.

For at interagere mellem netværksadapteren på den virtuelle maskine og den fysiske adapter på værten, bruges logiske grænseflader såsom Linux bridge.

For at gruppere og opdele trafik mellem netværk er VLAN'er konfigureret på switchene.

Ved oprettelse af et logisk netværk til virtuelle maskiner i oVirt skal det tildeles en identifikator svarende til VLAN-nummeret på switchen, så VM'erne kan kommunikere med hinanden, selvom de kører på forskellige noder i klyngen.

Foreløbige indstillinger af netværksadaptere på værter til tilslutning af virtuelle maskiner skulle foretages i forrige artikel – logisk grænseflade konfigureret obligation1, så bør alle netværksindstillinger kun foretages gennem oVirts administrative portal.

Efter at have oprettet en VM med hosted-engine blev der udover den automatiske oprettelse af et datacenter og klynge også automatisk oprettet et logisk netværk til at administrere vores klynge - ovritmgmt, som denne VM var forbundet til.

Om nødvendigt kan du se de logiske netværksindstillinger ovritmgmt og justere dem, men du skal passe på ikke at miste kontrollen over oVirt-infrastrukturen.

Logiske netværksindstillinger ovritmgmt

For at oprette et nyt logisk netværk til almindelige VM'er skal du i den administrative portal gå til Netværk >> Netværk >> Ny, og på fanen Generelt tilføj et netværk med det ønskede VLAN ID, og marker også afkrydsningsfeltet ud for "VM netværk", betyder det, at den kan bruges til tildeling til en VM.

Skærmbillede af det nye VLAN32 logiske netværk

I fanen Cluster, knytter vi dette netværk til vores klynge Klynge1.

Herefter går vi til Compute >> værter, gå til hver vært efter tur, til fanen Netværksgrænseflader, og start guiden Konfigurer værtsnetværk, for at binde til værter for et nyt logisk netværk.

Skærmbillede af guiden "Opsætning af værtsnetværk".

oVirt-agenten vil automatisk foretage alle de nødvendige netværksindstillinger på værten - opret et VLAN og BRIDGE.

Eksempel på konfigurationsfiler til nye netværk på værten:

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

Lad mig igen minde dig om det på klyngeværten INTET BEHOV oprette netværksgrænseflader manuelt på forhånd ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

Efter at have tilføjet et logisk netværk og kontrolleret forbindelsen mellem værten og den hostede motor VM, kan den bruges i den virtuelle maskine.

Oprettelse af et installationsbillede til implementering af en virtuel maskine

Link til dokumentation - oVirt Administration Guide, Kapitel 8: Opbevaring, afsnit Upload af billeder til et datalagerdomæne.

Uden et OS installationsbillede vil det ikke være muligt at installere en virtuel maskine, selvom det naturligvis ikke er et problem, hvis den f.eks. er installeret på netværket tærte med færdige billeder.

I vores tilfælde er dette ikke muligt, så du skal selv importere dette billede til oVirt. Tidligere krævede dette oprettelse af et ISO-domæne, men i den nye version af oVirt er det blevet udfaset, og derfor kan du nu uploade billeder direkte til Storage-domænet fra den administrative portal.

Gå til den administrative portal Opbevaring >> Skiver >> Upload >> Starten
Vi tilføjer vores OS-billede som en ISO-fil, udfylder alle felterne i formularen og klikker på knappen "Test forbindelse".

Skærmbillede af guiden Tilføj installationsbillede

Hvis vi får en fejl som denne:

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`

Derefter skal du tilføje oVirt-certifikatet til "Pålidelige rod-CA'er"(Trusted Root CA) på administratorens kontrolstation, hvorfra vi forsøger at downloade billedet.

Når du har tilføjet certifikatet til Trusted Root CA, skal du klikke igen på "Test forbindelse", skulle få:

Connection to ovirt-imageio-proxy was successful.

Når du har fuldført handlingen med at tilføje certifikatet, kan du prøve at uploade ISO-billedet til Storage Domain igen.

I princippet kan du lave et separat Storage Domain med Data-typen til at gemme billeder og skabeloner adskilt fra VM-diske, eller endda gemme dem i et Storage Domain til den hostede motor, men dette er efter administratorens skøn.

Skærmbillede med ISO-billeder i Storage Domain for hostet motor

Opret en virtuel maskine

Dokumentationslink:
oVirt Virtual Machine Management Guide –> Kapitel 2: Installation af virtuelle Linux-maskiner
Ressourcer til konsolkunder

Efter at have indlæst installationsbilledet med OS i oVirt, kan du fortsætte direkte til at oprette en virtuel maskine. Der er gjort en del arbejde, men vi er allerede i den sidste fase, hvor alt dette blev påbegyndt - at skaffe en fejltolerant infrastruktur til hosting af højst tilgængelige virtuelle maskiner. Og alt dette er helt gratis - ikke en eneste krone blev brugt på at købe nogen softwarelicenser.

For at oprette en virtuel maskine med CentOS 7 skal installationsbilledet fra operativsystemet downloades.

Vi går til den administrative portal, går til Compute >> Virtuelle maskiner, og start guiden til oprettelse af VM. Udfyld alle parametre og felter og klik ОК. Alt er meget enkelt, hvis du følger dokumentationen.

Som et eksempel vil jeg give de grundlæggende og yderligere indstillinger for en meget tilgængelig VM, med en oprettet disk, forbundet til netværket og opstart fra et installationsbillede:

Skærmbilleder med meget tilgængelige VM-indstillinger

Når du er færdig med at arbejde med guiden, skal du lukke den, starte en ny VM og installere operativsystemet på den.
For at gøre dette skal du gå til konsollen på denne VM gennem den administrative portal:

Skærmbillede af de administrative portalindstillinger for tilslutning til VM-konsollen

For at oprette forbindelse til VM-konsollen skal du først konfigurere konsollen i egenskaberne for den virtuelle maskine.

Skærmbillede af VM-indstillinger, fanen "Konsol".

For at oprette forbindelse til VM-konsollen kan du bruge f.eks. Virtual Machine Viewer.

For at oprette forbindelse til VM-konsollen direkte i browservinduet, skal forbindelsesindstillingerne via konsollen være som følger:

Efter installation af operativsystemet på VM'en, er det tilrådeligt at installere oVirt-gæsteagenten:

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

Som et resultat af vores handlinger vil den oprettede VM således være yderst tilgængelig, dvs. hvis cluster node, som den kører på, fejler, vil oVirt automatisk genstarte den på den anden node. Denne VM kan også migreres mellem klyngeværter til deres vedligeholdelse eller andre formål.

Konklusion

Jeg håber, at denne artikel formåede at formidle, at oVirt er et helt normalt værktøj til at administrere virtuel infrastruktur, som ikke er så svært at implementere – det vigtigste er at følge visse regler og krav, der er beskrevet både i artiklen og i dokumentationen.

På grund af artiklens store volumen var det ikke muligt at inkludere mange ting i den, såsom trin-for-trin udførelse af forskellige guider med alle de detaljerede forklaringer og skærmbilleder, lange konklusioner af nogle kommandoer osv. Faktisk ville dette kræve at man skriver en hel bog, hvilket ikke giver meget mening på grund af, at der konstant dukker nye versioner af software op med innovationer og ændringer. Det vigtigste er at forstå princippet om, hvordan det hele fungerer sammen, og at opnå en generel algoritme til at skabe en fejltolerant platform til styring af virtuelle maskiner.

Selvom vi har skabt en virtuel infrastruktur, skal vi nu lære den at interagere både mellem dens individuelle elementer: værter, virtuelle maskiner, interne netværk og med omverdenen.

Denne proces er en af hovedopgaverne for en system- eller netværksadministrator, som vil blive dækket i den næste artikel - om brugen af virtuelle VyOS-routere i vores virksomheds fejltolerante infrastruktur (som du gættede, vil de fungere som virtuelle maskiner på vores oVirt-klynge).

Kilde: www.habr.com

Oprettelse af en fejltolerant IT-infrastruktur. Del 2. Installation og konfiguration af oVirt 4.3-klyngen