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

Denne artikel er en fortsættelse af den forrige – „Oprettelse af en fejltolerant IT-infrastruktur. Del 1 - forberedelse til implementeringen af ​​klyngen oVirt 4.3».

Den vil dække processen for grundlæggende installation og opsætning af oVirt 4.3-klyngen til hosting af højt tilgængelige virtuelle maskiner, under forudsætning af at alle de forberedende trin til at klargøre infrastrukturen allerede er blevet udført tidligere.

Indledning

Hovedformålet med artiklen er ikke så meget at give en trin-for-trin vejledning som „Next -> Ja -> Finish“, men snarere at vise nogle af de særlige aspekter ved installation og opsætning. Processen med at implementere din klynge vil ikke altid nødvendigvis svare til det, der er beskrevet her, på grund af forskelle i infrastruktur og miljø, men de generelle principper vil være de samme.

Fra et subjektivt synspunkt, oVirt 4.3 ligner funktionelt VMware vSphere version 5.x, men har selvfølgelig sine egne opsætnings- og driftspecifikationer.

For dem, der er interesserede, kan alle forskelle mellem RHEV (aka oVirt) og VMware vSphere findes på internettet, for eksempel her, men jeg vil stadig nogle gange påpege deres visse forskelle eller ligheder undervejs i artiklen.

Specielt vil jeg gerne sammenligne håndteringen af netværk for virtuelle maskiner lidt. I oVirt er der implementeret en lignende netværksstyringsprincippet for virtuelle maskiner (VM), som i VMware vSphere:

• ved hjælp af standard Linux-bro (i VMware — Standard vSwitch), der fungerer på virtualiserings-værter;
• ved hjælp af Open vSwitch (OVS) (i VMware — Distributed vSwitch) – det er en distribueret virtuel switch, der består af to hovedkomponenter: central server OVN og OVN-controllere på de administrerede værter.

Det skal bemærkes, at på grund af enkelheden i implementeringen vil artiklen beskrive opsætningen af netværk i oVirt for VMer ved hjælp af standard Linux-bro, som er den standardmæssige løsning, når man bruger KVM-hypervisoren.

I den forbindelse er der nogle grundlæggende regler for netværksarbejdet i klyngen, som man bør være opmærksom på:

• Alle netværksindstillinger på værterne skal være identiske, før de føjes til oVirt, bortset fra IP-adresser.
• Når værten er taget under kontrol af oVirt, er det ekstremt frarådet at ændre noget manuelt i netværksindstillingerne uden fuld sikkerhed omkring sine handlinger, da oVirt-agenten derfor blot vil tilbageføre dem til de tidligere indstillinger efter genstart af værten eller agenten.
• Tilføjelse af et nyt netværk til VMer, samt arbejde med det, skal kun udføres fra oVirt's administrationskonsol.

En anden vigtig bemærkning — for a very critical environment (highly sensitive to financial losses), it is still recommended to use paid support and utilize Red Hat Virtualization 4.3. During the operation of the oVirt cluster, there may be some issues where it is preferable to receive qualified assistance as soon as possible rather than figuring them out independently.

And finally, anbefales before deploying the oVirt cluster, review the official documentation, to be aware of at least the basic concepts and definitions; otherwise, it will be a bit challenging to read the article further.

The basic documents necessary for understanding the article and the principles of the oVirt cluster's operation are:

• oVirt Installation Guide
• oVirt Self-Hosted Engine Guide
• oVirt Administration Guide
  

The volume isn’t too large; within an hour or two, one can grasp the main principles, and for those who prefer details, it is recommended to read Product Documentation for Red Hat Virtualization 4.3 — RHEV and oVirt are essentially the same.

So, if all basic settings on hosts, switches, and storage systems are completed, we move directly to deploying oVirt.

Part 2. Installation and Setup of the oVirt 4.3 Cluster

For ease of navigation, I will list the main sections of this article that should be completed sequentially:

1. Installing the oVirt Management Server
2. Creating a New Data Center
3. Creating a New Cluster
4. Installing Additional Hosts in a Self-Hosted Environment
5. Creating Storage Domains
6. Creating and Configuring Networks for Virtual Machines
7. Creating an Installation Image for Deploying a Virtual Machine
8. Creating a Virtual Machine

Installing the oVirt Management Server

The oVirt Management Server – is the most crucial element in the oVirt infrastructure, in the form of a virtual machine, host, or virtual device, managing the entire oVirt infrastructure.

Its close analogues in the virtualization world are:

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

For installing the oVirt Management Server, we have two options:

Mulighed 1
Deploying the server as a specialized VM or host.

This option works well, provided that such a VM operates independently from the cluster, i.e., it is not running on any cluster host as a standard virtual machine managed by KVM.

Why can’t such a VM be deployed on the cluster hosts?

I starten af processen med at implementere kontrolserveren for oVirt har vi et dilemma - vi skal installere kontrol-VM'en, men klyngen findes faktisk ikke endnu. Hvad kan vi så finde på? Rigtigt - installere KVM på den kommende klyngeknude og derefter oprette en virtuel maskine, for eksempel med CentOS, og deployere oVirt engine i den. Dette gøres normalt for at have fuld kontrol over en sådan VM, men det er en fejlagtig hensigt, for i så fald vil der 100 % opstå problemer med den kontrol-VM:

• den kan ikke migreres i oVirt-konsollen mellem værter (knuder) i klyngen;
• ved migration ved hjælp af KVM via virsh migrate, vil denne VM være utilgængelig for administration fra oVirt-konsollen.
• klyngens værter kan ikke bringes i Maintenance mode (vedligeholdelsestilstand), hvis man migrerer denne VM fra vært til vært ved hjælp af virsh migrate.

Så sørg for at gøre alt efter reglerne - brug enten en separat vært eller en uafhængig VM, der kører på den, som kontrolserveren for oVirt, eller helst gør som beskrevet i det andet forslag.

Mulighed 2
Installation af oVirt Engine Appliance på den klyngeknude, som den administrerer.

Netop denne mulighed vil blive behandlet videre, da den er mere korrekt og passende 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øre på, for at gøre den fejltolerant. Her vil jeg gerne tilføje, at som jeg allerede har skrevet i kommentarerne i den tidligere artikel, lykkedes det mig ikke at opnå splitbrain i oVirt-klyngen bestående af to værter, med mulighed for at køre hosted-engine VM'er på dem.

Installation af oVirt Engine Appliance på den første klyngeknude

Link til den officielle dokumentation - oVirt Self-Hosted Engine Guide, kapitel «Deploying the Self-Hosted Engine Using the Command line»

Dokumentet beskriver de forudsætninger, der skal være opfyldt, før man deployerer hosted-engine VM'en, samt den detaljerede proces for installationen, så det giver ikke meget mening at gentage det ordret, derfor fokuserer vi på nogle vigtige detaljer.

• Før vi går i gang, skal vi sørge for at aktivere virtualisering i BIOS-indstillingerne på værten.
• Installer pakken til hosted-engine installatøren 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

• Starter installation of oVirt Hosted Engine på vært via screen (du kan forlade det med Ctrl-A + D, afslutte med Ctrl-D):

screen
hosted-engine --deploy

Hvis ønskes, kan installationen startes med en forudforberedt svarfil:

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

• Under installationen af hosted-engine angiver vi alle nødvendige parametre:

- navnet på klyngen
- antal vCPU og vRAM (anbefales 4 vCPU og 16 GB)
- adgangskoder
- type lager til hosted engine VM – i vores tilfælde FC
- LUN-nummer til installation af hosted engine
- hvor databasen for hosted engine vil være – for nemheds skyld anbefaler jeg at vælge Local (dette er en PostgreSQL database, der kører inden i denne VM)
og andre parametre. 

• For installation af en højtilgængelig VM med hosted engine, havde vi tidligere oprettet et specielt LUN nr. 4 med en størrelse på 150 GB, som derefter blev præsenteret for klyngehostene – se i i den foregående artikel.

Tidligere har vi også tjekket dens synlighed på værterne:

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=aktiv
| `- 15:0:0:4  sdc 8:32  aktiv klar kørende
`-+- policy='service-time 0' prio=9 status=aktiveret
  `- 18:0:0:4  sdj 8:144 aktiv klar kørende

• Selve installationsprocessen af hosted-engine er ikke kompliceret, i slutningen skal vi have en meddelelse som denne:

[ INFO  ] Genererer svarfil '\/var\/lib\/ovirt-hosted-engine-setup\/answers\/answers-20191129131846.conf'
[ INFO  ] Genererer svarfil '\/etc\/ovirt-hosted-engine\/answers.conf'
[ INFO  ] Trin: Før-terminering
[ INFO  ] Trin: Terminering
[ INFO  ] Hosted Engine er blevet installeret med succes

Vi kontrollerer tilgængeligheden af oVirt-tjenester på værten:

Hvis alt er blevet gjort korrekt, går vi efter installationen ind via webbrowseren på https://ovirt_hostname/ovirt-engine fra administratorcomputer, og klikker på [Administration Portal].

Screenshot af «Administration Portal»

Ved at indtaste brugernavn og adgangskode (angivet under installationen) i vinduet som på screenshotet, kommer vi ind i Open Virtualization Manager, hvor man kan udføre alle handlinger med den virtuelle infrastruktur:

1. tilføje datacenter
2. tilføje og konfigurere klynge
3. tilføje værter og administrere dem
4. tilføje lagringsområder eller Storage Domains til virtuelle maskiners diske
5. tilføje og konfigurere netværk til virtuelle maskiner
6. tilføje virtuelle maskiner, installationsbilleder, VM-skabeloner og administrere dem

Alle disse handlinger vil blive gennemgået senere, noget i store træk, noget mere detaljeret og med nuancer.
Men vil jeg først anbefale at læse dette tillæg, som helt sikkert vil være nyttigt for mange.

Tilføjelse

1) I princippet, hvis der er et sådant behov, er der intet, der forhindrer at installere KVM-hypervisoren på klyngeknudepunkterne på forhånd ved hjælp af pakkerne libvirt og qemu-kvm (eller qemu-kvm-ev) den ønskede version, selvom installationen af klyngeknuden oVirt kan klare det selv.

Men hvis libvirt og qemu-kvm den ikke er den nyeste version, kan man få en fejl under installationen af hosted engine:

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

Det vil sige, det er nødvendigt at have en opdateret version libvirt med beskyttelse mod MDS, som understøtter sådan en politik:

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

Installerer 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 libvirtd

Kontrollerer for støtte til 'md-clear':

virsh domcapabilities kvm | grep require

Efter dette kan installationen af hosted engine fortsætte.

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

Hvis vi under installationen af VM til hosted-engine får denne 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 en anden firewall (hvis den bruges) slukkes, og derefter installeres og startes 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

Fremadrettet, ved installation af oVirt-agenten på en ny vært til klyngen, vil den automatisk konfigurere de nødvendige porte. firewalld automatiske.

3) Genstart af værten med en kørende VM med hosted engine.

Som sædvanlig, link 1 og link 2 til dokumentationsguiden.

Al administration af hosted engine VM'en udføres KUN ved hjælp af kommandoen hosted-engine på den vært, hvor den kører, om virsh man skal glemme, ligesom man også skal glemme, at man kan tilslutte sig denne VM via SSH og udføre kommandoen «shutdown».

Proceduren for at sætte VM i vedligeholdelsestilstand:

hosted-engine --set-maintenance --mode=global

hosted-engine --vm-status
!! Cluster er i GLOBAL MAINTENANCE tilstand !!
--== Vært host1.test.local (id: 1) status ==--
conf_on_shared_storage             : True
Status opdateret                  : True
Værtsnavn                        : host1.test.local
Vært ID                          : 1
Motor status                     : {"health": "good", "vm": "up", "detail": "Up"}
Score                             : 3400
stoppet                           : False
Lokal vedligeholdelse             : False
crc32                             : dee1a774
local_conf_timestamp              : 1821
Vært timestamp                    : 1821
Ekstra metadata (gyldig ved timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Lør Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Lør 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 hosted engine agent og gør hvad vi behøver.

Efter genstarten kontrollerer vi status for VM med hosted engine:

hosted-engine --vm-status

Hvis vores VM med hosted-engine ikke starter, og hvis vi ser lignende fejl i loggen fra tjenesten:

Fejl i loggen fra tjenesten:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Mislykkedes med at starte nødvendige overvågninger
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (seneste kald sidst):#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", linje 131, i _run_agent#012    return action(he)#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", linje 55, i action_proper#012    return he.start_monitoring()#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", linje 413, i start_monitoring#012    self._initialize_broker()#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", linje 537, i _initialize_broker#012    m.get('options', {}))#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", linje 86, i start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - mislykkedes med at starte monitor via ovirt-ha-broker: [Errno 2] Ingen sådan fil eller bibliotek, [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 Forsøger at genstarte agent

Så tilslutter 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 opstart af VM med hosted-engine, fjerner vi den fra vedligeholdelsestilstand:

Proceduren for at fjerne VM fra vedligeholdelsestilstand:

hosted-engine --check-liveliness
hosted-engine --set-maintenance --mode=none
hosted-engine --vm-status

--== Vært 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
Ekstra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (Fre Jan 17 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (Fre Jan 17 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        stopped=False

4) Fjernelse af hosted engine og alt, der er forbundet med det.

Nogle gange er det nødvendigt at fjerne en tidligere installeret hosted engine korrekt — link i den vejledende dokumentation.

Bare udfør kommandoen på værten:

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

Dernæst fjerner vi unødvendige pakker, efter at have sikkerhedskopieret nogle konfigurationer, hvis det er nødvendigt:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Creating a New Data Center

Referencedokumentation — oVirt Administration Guide. Kapitel 4: Data Centre

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

Et datacenter er en slags container, der består af:

• logiske ressourcer i form af klynger og værter
• netværksressourcer i klyngen i form af logiske netværk og fysiske adaptere på værterne,
• lagerressourcer (til VM-drev, skabeloner, billeder) i form af lagersystemer (Storage Domains).

Et datacenter kan inkludere flere klynger, der består af flere værter med virtuelle maskiner, der kører på dem, og det kan også have flere lagersystemer, der er knyttet til det.
Der kan være flere datacentre, og de fungerer uafhængigt af hinanden. I oVirt er der en opdelt myndighed baseret på roller, og man kan indstille tilladelser individuelt, både på datacenter niveau og på dets enkelte logiske elementer.

Datacentre, eller datacentre, hvis der er flere, administreres fra en enkelt administrationskonsol eller portal.

For at oprette et datacenter går vi ind i administrationsportalen og opretter et nyt datacenter:
Compute >> Data Centre >> Ny

Da vi bruger delt lagring på SANS, skal lagringstypen (Storage Type) være Shared:

Screenshot med guiden til oprettelse af datacenter

Når du opretter en virtuel maskine med hosted-engine, oprettes der som standard et datacenter – Datacenter1, og derefter kan du om nødvendigt ændre opbevaringstypen (Storage Type) til en anden.

Oprettelse af et datacenter er en ligetil opgave uden komplicerede nuancer, og alle yderligere handlinger med det er beskrevet i dokumentationen. Jeg vil dog nævne, at enkeltstående værter med kun lokal opbevaring (disk) til VM ikke kan komme ind i et datacenter med Storage Type — Shared (de kan ikke tilføjes dertil), og derfor skal der oprettes et separat datacenter til dem – det vil sige, at hver enkelt vært med lokal opbevaring har brug for sit eget datacenter.

Creating a New Cluster

Link til dokumentationen — oVirt Administrationsguide. Kapitel 5: Klynger

Uden unødige detaljer, cluster – er det en logisk gruppering af værter, der har et fælles lagerområde (i form af delede diske på SAN, som i vores tilfælde). Det er også ønskeligt, at værterne i klyngen har ens hardware og har samme type processor (Intel eller AMD). Det er bedst, hvis serverne i klyngen er fuldt ens.

Klyngen indgår i datacentret (med en bestemt type lager — Local eller Delt), og alle værter skal nødvendigvis tilhøre en klynge, afhængigt af om de har et fælles lager eller ej.

Når du opretter en virtuel maskine med hosted-engine på en vært, oprettes der som standard et datacenter — Datacenter1, sammen med en klynge – Klynge1, og derefter kan du justere dens indstillinger, aktivere ekstra funktioner, tilføje værter mv.

Som sædvanlig, for at få detaljer om alle indstillinger i klyngen, er det bedst at konsultere den officielle dokumentation. Af særlige karakteristika ved klyngeopsætningen vil jeg blot tilføje, at når den oprettes, er det tilstrækkeligt at konfigurere kun de grundlæggende parametre på fanen Generelt.

Jeg vil fremhæve de vigtigste parametre:

• Processor type – vælges baseret på, hvilke processorer der er installeret på værterne i klyngen, hvilken producent de er fra, og hvilken processor der er den ældste på værterne, så alle tilgængelige processorinstruktioner kan anvendes i klyngen.
• Switch type – vi bruger kun Linux bridge i klyngen, så det er den, vi vælger.
• Firewall type – her er det klart, det er firewalld, som skal være aktiveret og konfigureret på værterne.

Skærmbillede med klyngeindstillingerne

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

Link til dokumentationen.

Yderligere værter til Self-Hosted miljøet tilføjes som almindelige værter, med en ekstra opgave om implementering af VM med hosted engine — Vælg handling for implementering af hosted engine >> Udrul. Da den ekstra vært også skal præsenteres for LUN til VM med hosted engine, betyder det, at denne vært kan bruges til at hoste en VM med hosted engine, hvis det er nødvendigt.
Af hensyn til fejltoleranse anbefales det kraftigt at have mindst to værter, hvor en VM med hosted engine kan hostes.

På den ekstra vært slukker vi iptables (hvis det er aktiveret), aktiverer firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installér den nødvendige version af KVM (om 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

Installér de nødvendige repositories og hosted engine installer:

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

Derefter går vi til konsollen Open Virtualization Manager, tilføjer en ny vært, og følger trinene som beskrevet i dokumentationen.

Som resultat, efter tilføjelsen af den ekstra vært, bør vi få et billede i administrationskonsollen som på skærmbilledet.

Skærmbillede af administrationsportalen - værter

Værten, hvor VM med hosted engine i øjeblikket er aktiv, har en gylden krone og teksten "Kører Hosted Engine VM", værten, hvor denne VM kan startes efter behov - teksten "Kan køre Hosted Engine VM».

I tilfælde af fejl på værten, hvor "Kører Hosted Engine VM", vil den automatisk genstarte på den anden vært. Denne VM kan også migreres fra den aktive vært til den sekundære for vedligeholdelse.

Konfiguration af Power Management / fencing på oVirt værter

Links til dokumentation:

• Red Hat Virtualization 4.3 –> Teknisk reference -> Kapitel 4. Power Management
• oVirt Administration Guide -> Kapitel 7: Værter

Selvom det kan virke som om tilføjelsen og konfigurationen af værten er udført, er det ikke helt korrekt.
For normal drift af værterne og for at opdage/retter fejl med nogen af dem, kræves der konfiguration af Power Management / fencing.

Fencing, eller afskærmning – er en proces, hvor en fejlbehæftet eller svigtende vært midlertidigt udelukkes fra klyngen, hvorunder tjenesterne på den eller selve værten genstartes.

Alle detaljer om definitioner og parametre for Power Management / fencing findes, som sædvanligt i dokumentationen, jeg vil blot give et eksempel på, hvordan man konfigurerer denne vigtige parameter i forhold til Dell R640-servere med iDRAC 9.

1. Gå ind på administrationsportalen, klik på Compute >> Hosts vælg værten.
2. Klik på Edit.
3. Klik på fanen Power Management.
4. Marker afkrydsningsfeltet ud for muligheden Enable Power Management.
5. Marker afkrydsningsfeltet ud for muligheden Kdump integration, så værten ikke går ind i afskærmningsmode (fencing) under optagelse af en kernel dump.

Bemærkning.

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

1. Du kan valgfrit markere afkrydsningsfeltet Disable policy control of power management, hvis vi ikke ønsker, at værts strømstyring skal kontrolleres af klyngens planlægningspolitikker (Scheduling Policy).
2. Klik på knappen (+), for at tilføje en ny strømadministreringsenhed, redigeringsvinduet for agentens egenskaber åbnes.
   For iDRAC9 udfylder vi felterne:
   • Adresse – iDRAC9-adresse
   • Brugernavn / Adgangskode – henholdsvis login og adgangskode til at få adgang til iDRAC9
   • Type — drac5
   • markere Sikker
   • tilføje følgende indstillinger: cmd_prompt=>,login_timeout=30

Screenshot med indstillinger for „Power Management“ i værts egenskaber

Creating Storage Domains

Link til dokumentationen — oVirt Administration Guide, Kapitel 8: Opbevaring.

Opbevaringsdomæne, eller opbevaringsområde – er et centraliseret sted til opbevaring af diske for virtuelle maskiner, installationsbilleder, skabeloner og snapshots.

Opbevaringsområder kan tilknyttes datacentret ved hjælp af forskellige protokoller, klyngede og netværksfilsystemer.

oVirt har tre typer opbevaringsområder:

• Data Domain – til opbevaring af alle data relateret til virtuelle maskiner (diske, skabeloner). Data Domain kan ikke deles mellem forskellige datacentre.
• ISO Domain (forældet type opbevaringsområde) – til opbevaring af installationsbilleder til OS. ISO Domain kan deles mellem forskellige datacentre.
• Export Domain (forældet type opbevaringsområde) – til midlertidig opbevaring af billeder, der flyttes mellem datacentre.

I vores specifikke tilfælde bruger opbevaringsområdet af typen Data Domain Fibre Channel Protocol (FCP) til at oprette forbindelse til LUN'erne på SAN.

Fra oVirt's synspunkt er hver virtuel disk, snapshot eller skabelon — en logisk disk, når der bruges storage (FC eller iSCSI).
Blockenheder samles til en helhed (på klyngens værter) ved hjælp af Volume Group og opdeles derefter med LVM i logiske volumener, der bruges som virtuelle diske til VM'er.

Alle disse grupper og mange LVM volumener kan ses på klyngens vært ved hjælp af kommandoerne vgs og lvs. Naturligvis skal 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. Diskene kan være "tynde" eller "tykke". Snapshots oprettes altid som "tynde".

Den måde, hvorpå storage domains, eller opbevaringsområder, styres, hvilket adgangs gennem FC, er ret logisk — for hver virtuel disk i VM'en findes der et separat logisk volumne, der kun kan skrives til af én vært. I tilfælde af forbindelser via FC bruger oVirt noget, der ligner klynge-LVM.

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

Som vi kan se ud fra beskrivelsen betegner en klynge i oVirt, som i VMware vSphere eller Hyper-V, i bund og grund det samme - en logisk gruppering af værter, helst ensartede i hardware, og der har en fælles opbevaring til de virtuelle maskiners diske.

Lad os gå direkte til oprettelse af et opbevaringsområde til data (VM-diske), da datacenteret ikke vil blive initieret uden det.
Jeg vil minde om, at alle LUN'er præsenteret for klyngens værter på storage skal være synlige for dem ved hjælp af kommandoen "multipath -ll».

Ifølge dokumentationen", lad os gå til portalen og gå ind i Storage >> Domains -> New Domain og udføre instruktionerne fra afsnittet "Adding FCP Storage".

Efter lanceringen af guiden udfylder vi de nødvendige felter:

• Navn — angiv clusterets navn
• Domain Function — Data
• Storage Type — Fibre Channel
• Host to Use — vælg den vært, hvor den ønskede LUN er tilgængelig

I listen over LUN'er markerer vi den, vi har brug for, klikker på Tilføj og derefter OK. Om nødvendigt kan yderligere parametre for opbevaringsområdet justeres ved at klikke på Advanced Parameters.

Screenshot af guiden til at tilføje "Storage domain".

Som resultatet af guiden skal vi få et nyt opbevaringsområde, og vores datacenter skal skifte til status UP, eller initialiseret:

Screenshots af datacenteret og opbevaringsområderne i det:

Creating and Configuring Networks for Virtual Machines

Link til dokumentationen — oVirt Administration Guide, Kapitel 6: Logiske netværk

Netværk, eller networks – bruges til at gruppere logiske netværk, der anvendes i den virtuelle infrastruktur oVirt.

For interaktion mellem netværksadapteren på den virtuelle maskine og den fysiske adapter på værten, anvendes logiske interfaces af typen Linux bridge.

For at gruppere og adskille trafik mellem netværk, er VLANs konfigureret på switches.

Når du opretter et logisk netværk for virtuelle maskiner i oVirt, skal du nødvendigvis tildele et identifikationsnummer, der svarer til VLAN-nummeret på switchen, så VM'erne kan interagere med hinanden, selvom de kører på forskellige noder i klyngen.

Forberedende indstillinger af netværksadaptere på værter til tilslutning af virtuelle maskiner skal være udført i i den foregående artikel – logisk interface konfigureret bond1, derefter skal alle netværksindstillinger kun foretages via oVirt administrationsportalen.

Efter oprettelsen af VM med hosted-engine, blev der automatisk oprettet både datacenter og klynge, samt et logisk netværk til styring af vores klynge – ovritmgmt, som denne VM blev tilsluttet.

Om nødvendigt kan du se indstillingerne for det logiske netværk ovritmgmt og justere dem, men vær forsigtig så du ikke mister kontrollen over oVirt infrastrukturen.

Indstillinger for det logiske netværk ovritmgmt

For at oprette et nyt logisk netværk til almindelige VM'er, går vi i administrationsportalen til Netværk >> Networks >> Ny, og under fanen Generelt tilføjer vi netværket med det nødvendige VLAN-identifikationsnummer og sætter flueben ved "VM Network", hvilket betyder, at det kan bruges til tildeling til VM'er.

Screenshot af det nye logiske netværk VLAN32

Under fanen Cluster, forbinder vi dette netværk til vores klynge Klynge1.

Efter dette går vi til Compute >> Hosts, besøger hver vært én ad gangen, under fanen Network interfaces, og starter guiden Setup host networks, for at binde det nye logiske netværk til værterne.

Screenshot af guiden "Setup host networks"

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

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

cat ifcfg-bond1
# Genereret af 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
# Genereret af 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
# Genereret af VDSM version 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bro
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Jeg vil endnu en gang minde om, at det ikke er nødvendigt at PÅ FORHÅND manuelt oprette netværksgrænseflader ifcfg-bond1.432 og ifcfg-ovirtvm-vlan432.

Efter tilføjelse af det logiske netværk og kontrol af forbindelsen mellem værten og VM med hosted engine, kan det bruges i den virtuelle maskine.

Creating an Installation Image for Deploying a Virtual Machine

Link til dokumentationen — oVirt Administration Guide, Kapitel 8: Opbevaring, sektionen Uploading Images to a Data Storage Domain.

Uden installationsbilledet af OS, vil det ikke være muligt at installere den virtuelle maskine, selvom dette selvfølgelig ikke er et problem, hvis der f.eks. er installeret Cobbler med foruddefinerede billeder.

I vores tilfælde er en sådan mulighed ikke tilgængelig, så det bliver nødvendigt at importere dette billede i oVirt manuelt. Tidligere krævede dette oprettelse af ISO Domain, men i den nye version af oVirt er det blevet anset for forældet, og derfor kan man nu uploade billeder direkte til Storage domain fra administrationsportalen.

I administrationsportalen går vi til Storage >> Diske >> Upload >> Start
Vi tilføjer vores OS-billede som en ISO-fil, udfylder alle felter i formularen, og klikker på knappen "Test forbindelse".

Skærmbillede af guiden til tilføjelse af installationsbillede

Hvis vi får en fejl af denne type:

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

Skal du tilføje oVirt-certifikatet til "Dækkende hoved-CA» (Trusted Root CA) på administrationsstationen, hvorfra du prøver at uploade billedet.

Efter tilføjelse af certifikatet til Trusted Root CA, klikker vi igen på "Test forbindelse", vi bør modtage:

Forbindelsen til ovirt-imageio-proxy var vellykket.

Efter at have udført handlingen med at tilføje certifikatet, kan vi forsøge at uploade installationsbilledet til Storage Domain igen.

I princippet kan man gøre et separat Storage Domain med typen Data til opbevaring af billeder og skabeloner adskilt fra VM-diskene, eller endda opbevare dem i Storage Domain til hosted engine, men det er op til administratorens skøn.

Skærmbillede med ISO-billeder i Storage Domain for hosted engine

Creating a Virtual Machine

Link til dokumentationen:
oVirt Virtual Machine Management Guide –> Kapitel 2: Installation af Linux-virtuelle maskiner
Konsolklientressourcer

Når installationsbilledet med OS'et er uploadet til oVirt, kan vi gå direkte videre til oprettelsen af den virtuelle maskine. Der er blevet udført meget arbejde, men vi er allerede i den afsluttende fase, hvilket hele dette projekt handler om – at opnå en fejltolerant infrastruktur til hosting af højtilgængelige virtuelle maskiner. Og alt dette er helt gratis – der er ikke brugt en eneste krone på at erhverve softwarelicenser.

For at oprette en virtuel maskine med CentOS 7, skal installationsbilledet med OS'et være blevet uploadet.

Vi går ind i administrationsportalen og navigerer til Compute >> Virtuelle Maskiner, og starter guiden til oprettelse af VM. Vi udfylder alle parametre og felter og klikker på OK. Det er meget enkelt, hvis man følger dokumentationen.

Som eksempel vil jeg nævne de grundlæggende og supplerende indstillinger for en højtilgængelig VM, med oprettet disk, tilsluttet til netværket, og med opstart fra installationsbilledet:

Screenshots med indstillinger for højtilgængelig VM

Når vi er færdige med guiden, lukker vi den, starter den nye VM og installerer OS'et på den.
For dette går vi ind i konsollen for denne VM via administrationsportalen:

Screenshot af indstillingerne i administrationsportalen for forbindelse til VM-konsollen

For at oprette forbindelse til VM-konsollen skal konsollen først konfigureres i indstillingerne for den virtuelle maskine.

Screenshot af VM-indstillinger, fanebladet 'Konsol'

For at oprette forbindelse til VM-konsollen kan man bruge for eksempel Virtual Machine Viewer.

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

Efter installationen af OS'et på VM'en er det en god idé 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

På den måde, som et resultat af vores handlinger, vil den oprettede VM være højtilgængelig, dvs. i tilfælde af en fejl på klusterknuden, hvor den kører, vil oVirt automatisk genstarte den på den anden knude. Denne VM kan også migreres mellem værter i klusteret for vedligeholdelse eller andre formål.

Konklusion

Jeg håber, at denne artikel har kunnet formidle, at oVirt er et helt udmærket værktøj til administration af virtuel infrastruktur, som ikke er så svært at implementere – det vigtigste er at følge de bestemte regler og krav, der beskrives både i artiklen og i dokumentationen.

På grund af det store omfang af artiklen kunne mange emner ikke inkluderes, såsom trin-for-trin udførelse af forskellige guider med alle detaljerede forklaringer og skærmbilleder, lange output af visse kommandoer, osv. Faktisk ville det kræve at skrive en hel bog, hvilket ikke giver meget mening, da der konstant kommer nye versioner af softwaren med innovationer og ændringer. Det vigtigste er at forstå princippet i, hvordan det hele fungerer sammen, og få den overordnede handlingsplan for at skabe en fejltolerant platform til forvaltning af virtuelle maskiner.

Selvom vi har oprettet den virtuelle infrastruktur, skal vi nu lære den at interagere både mellem sine enkelte elementer: værter, virtuelle maskiner, interne netværk, og med omverdenen.

Denne proces er en af de primære opgaver for en system- eller netværksadministrator, som vil blive udfoldet i den næste artikel — om brugen af virtuelle routere VyOS i vores virksomheds fejltolerante infrastruktur (som du sikkert har gættet, vil de fungere som virtuelle maskiner på vores oVirt-klynge).

Kilde: habr.com