Denne artikkelen er en fortsettelse av den forrige - "'.
Den vil dekke prosessen med grunnleggende installasjon og konfigurasjon av en oVirt 4.3-klynge for hosting av svært tilgjengelige virtuelle maskiner, med tanke på det faktum at alle foreløpige trinn for å forberede infrastrukturen allerede er fullført tidligere.
prodrome
Hovedformålet med artikkelen er å gi trinnvise instruksjoner som "neste -> Ja -> Finish"hvordan du viser noen funksjoner når du installerer og konfigurerer den. Prosessen for å distribuere klyngen din faller kanskje ikke alltid sammen med den som er beskrevet i den, på grunn av egenskapene til infrastrukturen og miljøet, men de generelle prinsippene vil være de samme.
Fra et subjektivt synspunkt, funksjonaliteten ligner på VMware vSphere versjon 5.x, men selvfølgelig med sine egne konfigurasjons- og driftsfunksjoner.
For de som er interessert, kan alle forskjellene mellom RHEV (aka oVirt) og VMware vSphere finnes på Internett, for eksempel , men jeg vil likevel av og til legge merke til noen av deres forskjeller eller likheter med hverandre etter hvert som artikkelen skrider frem.
Separat vil jeg gjerne sammenligne litt arbeidet med nettverk for virtuelle maskiner. oVirt implementerer et lignende prinsipp for nettverksadministrasjon for virtuelle maskiner (heretter referert til som VM-er), som i VMware vSphere:
- bruker en standard Linux-bro (i VMware - Standard vSwitch), kjører på virtualiseringsverter;
- ved hjelp av Open vSwitch (OVS) (i VMware - Distribuert vSwitch) er en distribuert virtuell svitsj som består av to hovedkomponenter: en sentral OVN-server og OVN-kontrollere på administrerte verter.
Det skal bemerkes at på grunn av den enkle implementeringen, vil artikkelen beskrive oppsett av nettverk i oVirt for en VM ved hjelp av en standard Linux-bro, som er standardvalget ved bruk av KVM-hypervisor.
I denne forbindelse er det flere grunnleggende regler for å jobbe med nettverket i en klynge, som er best å ikke brytes:
- Alle nettverksinnstillinger på verter før de legges til i oVirt må være identiske, bortsett fra IP-adresser.
- Når en vert har blitt tatt under kontroll av oVirt, anbefales det sterkt ikke å endre noe manuelt i nettverksinnstillingene uten fullstendig tillit til handlingene dine, siden oVirt-agenten ganske enkelt vil rulle dem tilbake til de forrige etter omstart av verten eller middel.
- Å legge til et nytt nettverk for en VM, samt arbeide med det, bør bare gjøres fra oVirt-administrasjonskonsollen.
En til viktig notat - for et svært kritisk miljø (svært følsomt for økonomiske tap), vil det fortsatt anbefales å bruke betalt støtte og bruk . Under driften av oVirt-klyngen kan det oppstå noen problemer som det er tilrådelig å få kvalifisert hjelp for så snart som mulig, i stedet for å håndtere dem selv.
Endelig, anbefales Før du distribuerer en oVirt-klynge, må du gjøre deg kjent med , for å være klar over i det minste de grunnleggende begrepene og definisjonene, ellers blir det litt vanskelig å lese resten av artikkelen.
Grunnleggende for å forstå artikkelen og prinsippene for drift av oVirt-klyngen er disse veiledningsdokumentene:
Volumet der er ikke veldig stort, på en time eller to kan du ganske mestre de grunnleggende prinsippene, men for de som liker detaljer, anbefales det å lese — RHEV og oVirt er i hovedsak det samme.
Så hvis alle de grunnleggende innstillingene på vertene, bryterne og lagringssystemene er fullført, fortsetter vi direkte til utrullingen av oVirt.
Del 2. Installere og konfigurere oVirt 4.3-klyngen
For å lette orienteringen vil jeg liste opp hoveddelene i denne artikkelen, som må fylles ut en etter en:
- Installere oVirt-administrasjonsserveren
- Opprettelse av nytt datasenter
- Opprette en ny klynge
- Installere flere verter i et Self-Hosted-miljø
- Opprette et lagringsområde eller lagringsdomener
- Opprette og konfigurere nettverk for virtuelle maskiner
- Opprette et installasjonsbilde for å distribuere en virtuell maskin
- Lag en virtuell maskin
Installere oVirt-administrasjonsserveren
oVirt-administrasjonsserver er det viktigste elementet i oVirt-infrastrukturen, i form av en virtuell maskin, vert eller virtuell enhet som administrerer 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 å installere oVirt-administrasjonsserveren har vi to alternativer:
Alternativ 1
Distribuere en server i form av en spesialisert VM eller vert.
Dette alternativet fungerer ganske bra, men forutsatt at en slik VM opererer uavhengig av klyngen, dvs. kjører ikke på noen klyngevert som en vanlig virtuell maskin som kjører KVM.
Hvorfor kan ikke en slik VM distribueres på klyngeverter?
Helt i begynnelsen av prosessen med å distribuere oVirt-administrasjonsserveren har vi et dilemma - vi må installere en administrasjons-VM, men faktisk er det ingen klynge i seg selv ennå, og hva kan vi derfor finne på i farten? Det er riktig - installer KVM på en fremtidig klyngennode, og lag deretter en virtuell maskin på den, for eksempel med CentOS OS og distribuer oVirt-motoren i den. Dette kan vanligvis gjøres på grunn av fullstendig kontroll over en slik VM, men dette er en feilaktig intensjon, fordi i dette tilfellet vil det i fremtiden være 100 % problemer med en slik kontroll VM:
- den kan ikke migreres i oVirt-konsollen mellom verter (noder) i klyngen;
- ved migrering med KVM via virsh migrere, vil denne virtuelle maskinen ikke være tilgjengelig for administrasjon fra oVirt-konsollen.
- klyngeverter kan ikke vises i Vedlikeholdsmodus (vedlikeholdsmodus), hvis du migrerer denne virtuelle maskinen fra vert til vert ved hjelp av virsh migrere.
Så gjør alt i henhold til reglene - bruk enten en separat vert for oVirt-administrasjonsserveren, eller en uavhengig VM som kjører på den, eller enda bedre, gjør som skrevet i det andre alternativet.
Alternativ 2
Installere oVirt Engine Appliance på en klyngevert som administreres av den.
Det er dette alternativet som vil bli vurdert videre som mer riktig og egnet i vårt tilfelle.
Kravene til en slik VM er beskrevet nedenfor, jeg vil bare legge til at det anbefales å ha minst to verter i infrastrukturen som kontroll-VM kan kjøres på for å gjøre den feiltolerant. Her vil jeg gjerne legge til at jeg, som jeg allerede skrev i kommentarene i forrige artikkel, aldri klarte å få splitbrain på en oVirt-klynge med to verter, med muligheten til å kjøre VM-er med vertsmotor på dem.
Installere oVirt Engine Appliance på den første verten i klyngen
Link til offisiell dokumentasjon - , kapittel "»
Dokumentet spesifiserer forutsetningene som må oppfylles før du distribuerer en VM med vertsmotor, og beskriver også i detalj selve installasjonsprosessen, så det er liten vits i å gjenta den ordrett, så vi vil fokusere på noen viktige detaljer.
- Før du starter alle handlinger, sørg for å aktivere virtualiseringsstøtte i BIOS-innstillingene på verten.
- Installer pakken for installeringsprogrammet for vertsmotoren på verten:
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 prosedyren for å distribuere oVirt Hosted Engine på skjermen på verten (du kan avslutte den via Ctrl-A + D, lukk via Ctrl-D):
screen
hosted-engine --deployHvis du ønsker det, kan du kjøre installasjonen med en forhåndsforberedt svarfil:
hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/answers-ohe.conf- Når vi distribuerer vertsmotor, spesifiserer vi alle nødvendige parametere:
- имя кластера
- количество vCPU и vRAM (рекомендуется 4 vCPU и 16 Гб)
- пароли
- тип хранилища для hosted engine ВМ – в нашем случае FC
- номер LUN для установки hosted engine
- где будет находиться база данных для hosted engine – рекомендую для простоты выбрать Local (это БД PostgreSQL работающая внутри этой ВМ)
и др. параметры. - For å installere en svært tilgjengelig VM med en vertsmotor, har vi tidligere laget en spesiell LUN på lagringssystemet, nummer 4 og 150 GB i størrelse, som deretter ble presentert for klyngevertene - se .
Tidligere har vi også sjekket synligheten på verter:
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 distribusjonsprosessen for vertsmotorer er ikke komplisert; på slutten bør vi motta noe sånt 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 deployedVi sjekker tilstedeværelsen av oVirt-tjenester på verten:
Hvis alt ble gjort riktig, bruk en nettleser for å gå til etter at installasjonen er fullført fra administratorens datamaskin, og klikk på [Administrasjonsportal].
Skjermbilde av "Administrasjonsportal"
Ved å skrive inn login og passord (angitt under installasjonsprosessen) i vinduet som på skjermbildet, kommer vi til Open Virtualization Manager-kontrollpanelet, der du kan utføre alle handlinger med den virtuelle infrastrukturen:
- legge til datasenter
- legge til og konfigurere en klynge
- legge til og administrere verter
- legge til lagringsområder eller lagringsdomener for virtuelle maskindisker
- legge til og konfigurere nettverk for virtuelle maskiner
- legge til og administrere virtuelle maskiner, installasjonsbilder, VM-maler
Alle disse handlingene vil bli diskutert videre, noen i store celler, andre mer detaljert og med nyanser.
Men først vil jeg anbefale å lese dette tillegget, som sikkert vil være nyttig for mange.
Tillegg
1) I prinsippet, hvis det er et slikt behov, er det ingenting som hindrer deg i å installere KVM-hypervisoren på klyngenodene på forhånd ved å bruke pakker libvirt и qemu-kvm (eller qemu-kvm-ev) av den ønskede versjonen, men når den distribuerer en oVirt-klyngennode, kan den gjøre dette selv.
Men hvis libvirt и qemu-kvm Hvis du ikke har installert den nyeste versjonen, kan du få følgende feilmelding når du distribuerer en vertsbasert motor:
error: unsupported configuration: unknown CPU feature: md-clearDe. må ha libvirt med beskyttelse fra , som støtter denne policyen:
<feature policy='require' name='md-clear'/>Installer libvirt v.4.5.0-10.el7_6.12, med støtte for md-clear:
yum-config-manager --disable mirror.centos.org_centos-7_7_virt_x86_64_libvirt-latest_
yum install centos-release-qemu-ev
yum update
yum install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer libguestfs libguestfs-tools dejavu-lgc-sans-fonts virt-top libvirt libvirt-python libvirt-client
systemctl enable libvirtd
systemctl restart libvirtd && systemctl status libvirtdSe etter 'md-clear'-støtte:
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'/>Etter dette kan du fortsette å installere den vertsbaserte motoren.
2) I oVirt 4.3, tilstedeværelsen og bruken av en brannmur brannmur er et obligatorisk krav.
Hvis vi under distribusjon av en VM for vertsmotor får følgende feilmelding:
[ 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=1608467Deretter må du slå av en annen brannmur (hvis den brukes), og installere og kjøre brannmur:
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-zonesSenere, når du installerer ovirt-agenten på en ny vert for klyngen, vil den konfigurere de nødvendige portene i brannmur automatisk.
3) Omstart av en vert med en VM som kjører på den med en vertsbasert motor.
Som vanlig, и til styrende dokumenter.
All administrasjon av den vertsbaserte VM-motoren gjøres BARE ved å bruke kommandoen hosted-motor på verten der det går, ca Virsh vi må glemme, så vel som det faktum at du kan koble til denne VM via SSH og kjøre kommandoen "nedleggelse'.
Prosedyre for å sette en VM i vedlikeholdsmodus:
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-shutdownVi starter verten på nytt med den hostede motoragenten og gjør det vi trenger med den.
Etter omstart, sjekk statusen til VM med den vertsbaserte motoren:
hosted-engine --vm-statusHvis vår VM med vertsmotor ikke starter og hvis vi ser lignende feil i tjenesteloggen:
Feil i tjenesteloggen:
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 agentDeretter kobler vi til lagringen og starter agenten på nytt:
hosted-engine --connect-storage
systemctl restart ovirt-ha-agent
systemctl status ovirt-ha-agent
hosted-engine --vm-start
hosted-engine --vm-statusEtter å ha startet VM med vertsmotor, tar vi den ut av vedlikeholdsmodus:
Prosedyre for å fjerne en VM fra vedlikeholdsmodus:
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=False4) Fjerning av den vertsbaserte motoren og alt knyttet til den.
Noen ganger er det nødvendig å fjerne en tidligere installert vertsmotor på riktig måte - til veiledningsdokumentet.
Bare kjør kommandoen på verten:
/usr/sbin/ovirt-hosted-engine-cleanupDeretter fjerner vi unødvendige pakker, og sikkerhetskopierer noen konfigurasjoner før dette, om nødvendig:
yum autoremove ovirt* qemu* virt* libvirt* libguestfs Opprettelse av nytt datasenter
Referansedokumentasjon - oVirt Administration Guide.
La oss først definere hva det er datasenter (Jeg siterer fra hjelpen) er en logisk enhet som definerer et sett med ressurser som brukes i et spesifikt miljø.
Et datasenter er en slags beholder som består av:
- logiske ressurser i form av klynger og verter
- klynge nettverksressurser i form av logiske nettverk og fysiske adaptere på verter,
- lagringsressurser (for VM-disker, maler, bilder) i form av lagringsområder (Storage Domains).
Et datasenter kan inkludere flere klynger som består av flere verter med virtuelle maskiner som kjører på dem, og det kan også ha flere lagringsområder knyttet til seg.
Det kan være flere datasentre, de opererer uavhengig av hverandre. Ovirt har en separasjon av makter etter rolle, og du kan konfigurere tillatelser individuelt, både på datasenternivå og på dets individuelle logiske elementer.
Datasenteret, eller datasentre hvis det er flere av dem, administreres fra én enkelt administrativ konsoll eller portal.
For å opprette et datasenter, gå til den administrative portalen og opprett et nytt datasenter:
Beregn >> datasentre >> Ny
Siden vi bruker delt lagring på lagringssystemet, bør lagringstypen være delt:
Skjermbilde av veiviseren for opprettelse av datasenter
Når du installerer en virtuell maskin med hosted-motor, opprettes et datasenter som standard - Datasenter 1, og deretter, om nødvendig, kan du endre lagringstypen til en annen.
Å lage et datasenter er en enkel oppgave, uten noen vanskelige nyanser, og alle tilleggshandlinger med det er beskrevet i dokumentasjonen. Det eneste jeg vil merke meg er at enkeltverter som kun har lokal lagring (disk) for VM-er ikke vil kunne komme inn i et datasenter med Storage Type - Shared (de kan ikke legges til der), og for dem må du opprette et eget datasenter – dvs. Hver enkelt vert med lokal lagring trenger sitt eget separate datasenter.
Opprette en ny klynge
Link til dokumentasjon - oVirt Administration Guide.
Uten unødvendige detaljer, klynge – dette er en logisk gruppering av verter som har et felles lagringsområde (i form av delte disker på et lagringssystem, som i vårt tilfelle). Det er også ønskelig at vertene i klyngen er identiske i maskinvare og har samme type prosessor (Intel eller AMD). Det beste er selvfølgelig at serverne i klyngen er helt identiske.
Klyngen er en del av et datasenter (med en bestemt type lagring - lokal eller delt), og alle verter må tilhøre en slags klynge, avhengig av om de har delt lagring eller ikke.
Når du installerer en virtuell maskin med en vertsmotor på en vert, opprettes et datasenter som standard - Datasenter 1, sammen med klyngen – Klynge1, og i fremtiden kan du konfigurere parameterne, aktivere flere alternativer, legge til verter til den, etc.
Som vanlig, for detaljer om alle klyngeinnstillinger, anbefales det å se den offisielle dokumentasjonen. Av noen av funksjonene ved å sette opp en klynge, vil jeg bare legge til at når du oppretter den, er det nok å konfigurere bare de grunnleggende parameterne på fanen general.
Jeg vil merke meg de viktigste parametrene:
- Prosessortype — velges basert på hvilke prosessorer som er installert på klyngevertene, hvilken produsent de er fra, og hvilken prosessor på vertene som er den eldste, slik at avhengig av dette brukes alle tilgjengelige prosessorinstruksjoner i klyngen.
- Bryter type – i klyngen vår bruker vi bare Linux-broen, det er derfor vi velger den.
- Brannmurtype – alt er klart her, dette er brannmur, som må aktiveres og konfigureres på vertene.
Skjermbilde med klyngeparametere
Installere flere verter i et Self-Hosted-miljø
for dokumentasjon.
Ytterligere verter for et selvvertsmiljø legges til på samme måte som en vanlig vert, med det ekstra trinnet å distribuere en VM med en vertsmotor - Velg handling for drift av vertsmotor >> Distribuer. Siden den ekstra verten også må presenteres med en LUN for en VM med en vertsmotor, betyr dette at denne verten om nødvendig kan brukes til å være vert for en VM med en vertsmotor på.
For feiltoleranseformål anbefales det på det sterkeste at det er minst to verter som en vertsbasert VM-motor kan plasseres på.
På den ekstra verten, deaktiver iptables (hvis aktivert), aktiver brannmur
systemctl stop iptables
systemctl disable iptables
systemctl enable firewalld
systemctl start firewalldInstaller den nødvendige KVM-versjonen (om nødvendig):
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-clearInstaller de nødvendige depotene og installeringsprogrammet for vertsmotoren:
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-setupGå deretter til konsollen Åpne Virtualization Manager, legg til en ny vert, og gjør alt trinn for trinn, som skrevet i .
Som et resultat, etter å ha lagt til en ekstra vert, bør vi få noe som bildet i administrasjonskonsollen, som i skjermbildet.
Skjermbilde av den administrative portalen - verter
Verten som den vertsbaserte VM-en for øyeblikket er aktiv på har en gullkrone og inskripsjonen "Kjører Hosted Engine VM", verten som denne VM-en kan lanseres på om nødvendig - inskripsjonen "Kan kjøre Hosted Engine VM'.
I tilfelle vertssvikt som "Kjører Hosted Engine VM", vil den automatisk starte på nytt på den andre verten. Denne virtuelle maskinen kan også migreres fra den aktive verten til standby-verten for vedlikehold.
Sette opp strømstyring / fekting på oVirt-verter
Dokumentasjonslenker:
- Red Hat Virtualization 4.3 –> Teknisk referanse ->
- oVirt Administrasjonsveiledning ->
Selv om det kan virke som du er ferdig med å legge til og konfigurere en vert, er det ikke helt sant.
For normal drift av verter, og for å identifisere/løse feil med noen av dem, kreves innstillinger for strømstyring / gjerde.
Gjerder, eller fekting, er prosessen med å midlertidig ekskludere en defekt eller mislykket vert fra klyngen, hvor enten oVirt-tjenestene på den eller selve verten startes på nytt.
Alle detaljer om definisjonene og parameterne for strømstyring / gjerde er gitt, som vanlig, i dokumentasjonen; Jeg vil bare gi et eksempel på hvordan du konfigurerer denne viktige parameteren, slik den brukes på Dell R640-servere med iDRAC 9.
- Gå til den administrative portalen, klikk Beregn >> verter velg en vert.
- Vi klikker Rediger.
- Klikk på fanen Power Management.
- Merk av i boksen ved siden av alternativet Aktiver strømstyring.
- Merk av i boksen ved siden av alternativet Kdump-integrasjonfor å forhindre at verten går inn i gjerdemodus mens den registrerer en kjernekrasjdump.
Note.
Etter å ha aktivert Kdump-integrasjon på en allerede kjørende vert, må den installeres på nytt i henhold til prosedyren i oVirt Administration Guide -> -> Installere verter på nytt.
- Eventuelt kan du merke av i boksen Deaktiver policykontroll av strømstyring, hvis vi ikke vil at vertsstrømstyring skal kontrolleres av klyngens planleggingspolicy.
- Klikk på knappen (+) for å legge til en ny strømstyringsenhet, åpnes vinduet for redigering av agentegenskaper.
For iDRAC9, fyll ut feltene:- Adresse – iDRAC9-adresse
- Brukernavn passord – henholdsvis pålogging og passord for å logge på iDRAC9
- typen — drac5
- mark Sikre
- legg til følgende alternativer: cmd_prompt=>, login_timeout=30
Skjermbilde med "Power Management"-parametere i vertsegenskaper
Opprette et lagringsområde eller lagringsdomener
Link til dokumentasjon - oVirt Administration Guide, .
Lagringsdomene, eller lagringsområde, er et sentralisert sted for lagring av virtuelle maskindisker, installasjonsbilder, maler og øyeblikksbilder.
Lagringsområder kan kobles til datasenteret ved hjelp av ulike protokoller, klynge- og nettverksfilsystemer.
oVirt har tre typer lagringsområde:
- Datadomen – for å lagre alle data knyttet til virtuelle maskiner (disker, maler). Datadomene kan ikke deles mellom ulike datasentre.
- ISO-domene (foreldet type lagringsområde) – for lagring av OS-installasjonsbilder. ISO-domene kan deles mellom ulike datasentre.
- Eksporter domene (foreldet type lagringsområde) – for midlertidig lagring av bilder som flyttes mellom datasentre.
I vårt spesielle tilfelle bruker et lagringsområde med typen Data Domain Fibre Channel Protocol (FCP) for å koble til LUN-er på lagringssystemet.
Fra oVirts synspunkt, når du bruker lagringssystemer (FC eller iSCSI), er hver virtuell disk, øyeblikksbilde eller mal en logisk disk.
Blokkenheter settes sammen til en enkelt enhet (på klyngeverter) ved hjelp av Volume Group og deretter delt ved hjelp av LVM i logiske volumer, som brukes som virtuelle disker for VM-er.
Alle disse gruppene og mange LVM-volumer kan sees på klyngeverten ved å bruke kommandoene etc и lvs. Naturligvis bør alle handlinger med slike disker bare gjøres fra oVirt-konsollen, bortsett fra i spesielle tilfeller.
Virtuelle disker for VM-er kan være av to typer - QCOW2 eller RAW. Plater kan være "tynn" eller "tykk". Øyeblikksbilder opprettes alltid som "tynn".
Måten å administrere lagringsdomener, eller lagringsområder tilgang til gjennom FC, er ganske logisk - for hver virtuelle VM-disk er det et eget logisk volum som kun kan skrives av én vert. For FC-tilkoblinger bruker oVirt noe som clustered LVM.
Virtuelle maskiner plassert på samme lagringsområde kan migreres mellom verter som tilhører samme klynge.
Som vi kan se fra beskrivelsen betyr en klynge i oVirt, som en klynge i VMware vSphere eller Hyper-V, i hovedsak det samme - det er en logisk gruppering av verter, fortrinnsvis identiske i maskinvaresammensetning, og som har felles lagring for virtuelle maskindisker.
La oss gå direkte videre til å lage et lagringsområde for data (VM-disker), siden uten det vil ikke datasenteret bli initialisert.
La meg minne deg på at alle LUN-er som presenteres for klyngevertene på lagringssystemet må være synlige på dem ved å bruke kommandoen "flerveis -ll'.
Ifølge , gå til portalen gå til oppbevaring >> Domener -> Nytt domene og følg instruksjonene fra delen "Legge til FCP-lagring".
Etter å ha startet veiviseren, fyll ut de nødvendige feltene:
- Navn — angi klyngenavnet
- Domenefunksjon -Data
- Lagringstype — Fiberkanal
- Vert å bruke — velg en vert som LUN-en vi trenger er tilgjengelig på
I listen over LUN-er, merk den vi trenger, klikk Legg til og så ОК. Om nødvendig kan du justere ytterligere parametere for lagringsområdet ved å klikke på Avanserte parametere.
Skjermbilde av veiviseren for å legge til "Lagringsdomene"
Basert på resultatene av veiviseren bør vi motta et nytt lagringsområde, og datasenteret vårt skal flytte til status UP, eller initialisert:
Skjermbilder av datasenteret og lagringsområdene i det:
Opprette og konfigurere nettverk for virtuelle maskiner
Link til dokumentasjon - oVirt Administration Guide,
Nettverk, eller nettverk, tjener til å gruppere logiske nettverk som brukes i den virtuelle oVirt-infrastrukturen.
For å samhandle mellom nettverksadapteren på den virtuelle maskinen og den fysiske adapteren på verten, brukes logiske grensesnitt som Linux bridge.
For å gruppere og dele trafikk mellom nettverk, er VLAN konfigurert på svitsjene.
Når du oppretter et logisk nettverk for virtuelle maskiner i oVirt, må det tildeles en identifikator som tilsvarer VLAN-nummeret på svitsjen slik at VM-ene kan kommunisere med hverandre, selv om de kjører på forskjellige noder i klyngen.
Foreløpige innstillinger av nettverkskort på verter for å koble til virtuelle maskiner måtte gjøres i – logisk grensesnitt konfigurert bondxnumx, da bør alle nettverksinnstillinger kun gjøres gjennom oVirts administrative portal.
Etter å ha opprettet en VM med vertsmotor, i tillegg til automatisk opprettelse av et datasenter og klynge, ble det også automatisk opprettet et logisk nettverk for å administrere klyngen vår - ovritmgmt, som denne virtuelle maskinen var koblet til.
Om nødvendig kan du se de logiske nettverksinnstillingene ovritmgmt og justere dem, men du må være forsiktig så du ikke mister kontrollen over oVirt-infrastrukturen.
Logiske nettverksinnstillinger ovritmgmt
For å opprette et nytt logisk nettverk for vanlige VM-er, gå til den administrative portalen Network >> Nettverk >> Ny, og på fanen general legg til et nettverk med ønsket VLAN-ID, og merk også av i boksen ved siden av "VM-nettverk", betyr dette at den kan brukes for tilordning til en VM.
Skjermbilde av det nye logiske VLAN32-nettverket
I fanen Cluster, knytter vi dette nettverket til klyngen vår Klynge1.
Etter dette går vi til Beregn >> verter, gå til hver vert etter tur, til fanen Nettverksgrensesnitt, og start veiviseren Sett opp vertsnettverk, for å binde seg til verter for et nytt logisk nettverk.
Skjermbilde av "Oppsett vertsnettverk"-veiviseren
oVirt-agenten vil automatisk gjøre alle nødvendige nettverksinnstillinger på verten - opprett et VLAN og BRIDGE.
Eksempel på konfigurasjonsfiler for nye nettverk på verten:
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=noLa meg minne deg nok en gang om det på klyngeverten INGEN BEHOV opprette nettverksgrensesnitt manuelt på forhånd ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.
Etter å ha lagt til et logisk nettverk og kontrollert forbindelsen mellom verten og den vertsbaserte VM-motoren, kan den brukes i den virtuelle maskinen.
Opprette et installasjonsbilde for å distribuere en virtuell maskin
Link til dokumentasjon - oVirt Administration Guide, , seksjon Laste opp bilder til et datalagringsdomene.
Uten et OS-installasjonsbilde vil det ikke være mulig å installere en virtuell maskin, selv om dette selvfølgelig ikke er et problem hvis den for eksempel er installert på nettverket med ferdiglagde bilder.
I vårt tilfelle er dette ikke mulig, så du må importere dette bildet til oVirt selv. Tidligere krevde dette opprettelse av et ISO-domene, men i den nye versjonen av oVirt er det utdatert, og derfor kan du nå laste opp bilder direkte til Storage-domenet fra den administrative portalen.
Gå til den administrative portalen oppbevaring >> Disker >> Last opp >> Start
Vi legger til OS-bildet vårt som en ISO-fil, fyller ut alle feltene i skjemaet og klikker på knappen "Test tilkobling".
Skjermbilde av veiviseren for Legg til installasjonsbilde
Hvis vi får en feil som dette:
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`
Deretter må du legge til oVirt-sertifikatet til "Pålitelige rot-CAer"(Trusted Root CA) på administratorens kontrollstasjon, hvor vi prøver å laste ned bildet.
Etter at du har lagt til sertifikatet til Trusted Root CA, klikker du igjen "Test tilkobling", burde få:
Connection to ovirt-imageio-proxy was successful.Etter at du har fullført handlingen med å legge til sertifikatet, kan du prøve å laste opp ISO-bildet til Storage Domain på nytt.
I prinsippet kan du lage et eget Storage Domain med Data-typen for å lagre bilder og maler separat fra VM-disker, eller til og med lagre dem i et Storage Domain for den hostede motoren, men dette er etter administratorens skjønn.
Skjermbilde med ISO-bilder i Storage Domain for hosted motor
Lag en virtuell maskin
Dokumentasjonslenke:
oVirt Virtual Machine Management Guide –>
Etter å ha lastet installasjonsbildet med OS til oVirt, kan du fortsette direkte til å lage en virtuell maskin. Mye arbeid har blitt gjort, men vi er allerede i sluttfasen, for hvilken alt dette ble startet - å skaffe en feiltolerant infrastruktur for hosting av svært tilgjengelige virtuelle maskiner. Og alt dette er helt gratis - ikke en eneste krone ble brukt på å kjøpe noen programvarelisenser.
For å lage en virtuell maskin med CentOS 7, må installasjonsbildet fra operativsystemet lastes ned.
Vi går til den administrative portalen, går til Beregn >> Virtuelle maskiner, og start veiviseren for VM-oppretting. Fyll ut alle parametere og felter og klikk ОК. Alt er veldig enkelt hvis du følger dokumentasjonen.
Som et eksempel vil jeg gi de grunnleggende og tilleggsinnstillingene for en svært tilgjengelig VM, med en opprettet disk, koblet til nettverket og oppstart fra et installasjonsbilde:
Skjermbilder med svært tilgjengelige VM-innstillinger
Etter å ha fullført arbeidet med veiviseren, lukk den, start en ny VM og installer OS på den.
For å gjøre dette, gå til konsollen til denne VM-en gjennom den administrative portalen:
Skjermbilde av de administrative portalinnstillingene for tilkobling til VM-konsollen
For å koble til VM-konsollen må du først konfigurere konsollen i egenskapene til den virtuelle maskinen.
Skjermbilde av VM-innstillinger, "Konsoll"-fanen
For å koble til VM-konsollen kan du bruke f.eks. .
For å koble til VM-konsollen direkte i nettleservinduet, bør tilkoblingsinnstillingene via konsollen være som følger:
Etter å ha installert OS på VM, anbefales det å installere oVirt gjesteagent:
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.serviceDermed, som et resultat av våre handlinger, vil den opprettede VM være svært tilgjengelig, dvs. hvis klyngenoden den kjører på mislykkes, vil oVirt automatisk starte den på nytt på den andre noden. Denne virtuelle maskinen kan også migreres mellom klyngeverter for vedlikehold eller andre formål.
Konklusjon
Jeg håper at denne artikkelen klarte å formidle at oVirt er et helt normalt verktøy for å administrere virtuell infrastruktur, som ikke er så vanskelig å distribuere - det viktigste er å følge visse regler og krav beskrevet både i artikkelen og i dokumentasjonen.
På grunn av det store volumet av artikkelen var det ikke mulig å inkludere mange ting i den, for eksempel trinnvis utførelse av forskjellige veivisere med alle detaljerte forklaringer og skjermbilder, lange konklusjoner av noen kommandoer, etc. Dette ville faktisk kreve å skrive en hel bok, noe som ikke gir mye mening på grunn av at det stadig dukker opp nye versjoner av programvare med innovasjoner og endringer. Det viktigste er å forstå prinsippet for hvordan det hele fungerer sammen, og å få en generell algoritme for å lage en feiltolerant plattform for å administrere virtuelle maskiner.
Selv om vi har laget en virtuell infrastruktur, må vi nå lære den å samhandle både mellom de individuelle elementene: verter, virtuelle maskiner, interne nettverk og med omverdenen.
Denne prosessen er en av hovedoppgavene til en system- eller nettverksadministrator, som vil bli dekket i neste artikkel - om bruken av virtuelle VyOS-rutere i den feiltolerante infrastrukturen til virksomheten vår (som du gjettet, vil de fungere som virtuelle maskiner på vår oVirt-klynge).
Kilde: www.habr.com