Het creëren van een fouttolerante IT-infrastructuur. Deel 2. Installatie en configuratie van de oVirt 4.3-cluster

Dit artikel is een vervolg op het vorige – «Het creëren van een fouttolerante IT-infrastructuur. Deel 1 — voorbereiding op de uitrol van de oVirt 4.3-cluster».

Hierin wordt het proces van de basisinstallatie en configuratie van de oVirt 4.3-cluster behandeld, voor het hosten van hoog beschikbare virtuele machines, rekening houdend met het feit dat alle voorbereidende stappen voor de infrastructuur al eerder zijn uitgevoerd.

Inleiding

Het belangrijkste doel van het artikel is niet zozeer het geven van een stapsgewijze instructie in de trant van «Volgende -> Ja -> Voltooien», maar vooral enkele kenmerken bij de installatie en configuratie ervan te laten zien. Het proces van het uitrollen van je cluster kan niet altijd overeenkomen met wat hierin is beschreven, vanwege de kenmerken van de infrastructuur en omgeving, maar de algemene principes zullen hetzelfde zijn.

Subjectief gezien, oVirt 4.3 is qua functionaliteit vergelijkbaar met VMware vSphere versie 5.x, maar natuurlijk met zijn eigen instellingen en werking.

Voor geïnteresseerden zijn alle verschillen tussen RHEV (ook bekend als oVirt) en VMware vSphere te vinden op internet, bijvoorbeeld hier, maar ik zal toch af en toe enkele van hun verschillen of overeenkomsten tijdens het artikel opmerken.

Daarnaast wil ik graag de werking met netwerken voor virtuele machines vergelijken. In oVirt is een vergelijkbaar beheerprincipe voor netwerken voor virtuele machines (verder VMs) geïmplementeerd, als in VMware vSphere:

• met behulp van de standaard Linux bridge (in VMware — Standaard vSwitch), die draait op de virtualisatiehosts;
• met behulp van Open vSwitch (OVS) (in VMware — Distributed vSwitch) – dit is een gedistribueerde virtuele switch, bestaande uit twee belangrijke componenten: de centrale OVN-server en de OVN-controllers op de beheerde hosts.

Het is belangrijk op te merken dat, vanwege de eenvoud van de implementatie, in het artikel de netwerkinstellingen in oVirt voor VMs met behulp van de standaard Linux bridge zullen worden beschreven, die de standaardkeuze is bij het gebruik van de KVM-hypervisor.

Daarom zijn er enkele basisregels voor het werken met netwerken in de cluster die beter niet overtreden kunnen worden:

• Alle netwerkinstellingen op de hosts moeten identiek zijn voordat ze aan oVirt worden toegevoegd, met uitzondering van IP-adressen.
• Nadat de host onder beheer van oVirt is genomen, wordt het ten zeerste afgeraden om handmatig iets aan de netwerkinstellingen te veranderen, zonder volledig vertrouwen in uw acties, aangezien de oVirt-agent deze simpelweg terugzet naar de vorige instellingen na een herstart van de host of agent.
• Het toevoegen van een nieuw netwerk voor de VM, evenals het werken ermee, moet alleen vanuit de oVirt-beheerconsole plaatsvinden.

Nog een belangrijke opmerking — voor een zeer kritische omgeving (veelal gevoelig voor financiële verliezen), zou het toch aanbevolen zijn om betaalde ondersteuning te gebruiken en Red Hat Virtualization 4.3. Tijdens de exploitatie van het oVirt-cluster kunnen zich enkele situaties voordoen waarbij het gewenst is om zo snel mogelijk gekwalificeerde hulp te krijgen, in plaats van zelf te proberen deze op te lossen.

En tot slot, is het aanbevolen om zich voor de uitrol van het oVirt-cluster vertrouwd te maken met de officiële documentatie, zodat men tenminste op de hoogte is van de basisprincipes en definities, anders zal het moeilijk zijn om de verdere uitleg te begrijpen.

De basisdocumenten voor het begrijpen van het artikel en de principes van het oVirt-cluster zijn:

• oVirt Installatiehandleiding
• oVirt Zelfgehoste Engine-handleiding
• oVirt Beheerhandleiding
  

De hoeveelheid informatie is niet erg groot, binnen een uur of twee kan men de belangrijkste principes begrijpen, en voor diegenen die van details houden, is het aan te raden om te lezen Productdocumentatie voor Red Hat Virtualization 4.3 — RHEV en oVirt zijn in wezen hetzelfde.

Laten we zeggen, als alle basisinstellingen op de hosts, switches en SAN zijn uitgevoerd, dan gaan we verder met de uitrol van oVirt.

Deel 2. Installatie en configuratie van het oVirt 4.3-cluster

Voor een gemakkelijke navigatie, geef ik een lijst van de belangrijkste secties in dit artikel weer, die in volgorde uitgevoerd moeten worden:

1. Installatie van de oVirt-beheerserver
2. Creëren van een nieuwe datacenter
3. Creëren van een nieuw cluster
4. Installeren van extra hosts in een Zelfgehoste omgeving
5. Creëren van opslaggebieden of Storage Domains
6. Creëren en configureren van netwerken voor virtuele machines
7. Creëren van een installatiedisc voor het uitrollen van een virtuele machine
8. Creëren van een virtuele machine

Installatie van de oVirt-beheerserver

De oVirt-beheerserver is het belangrijkste element in de oVirt-infrastructuur, in de vorm van een virtuele machine, host, of virtueel apparaat dat de gehele oVirt-infrastructuur beheert.

De dichtstbijzijnde tegenhangers uit de virtualisatiewereld zijn:

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

Voor de installatie van de oVirt-beheerserver hebben we twee opties:

Optie 1
Het implementeren van de server als een gespecialiseerde VM of als host.

Deze optie werkt prima, maar alleen als die VM onafhankelijk van het cluster draait, d.w.z. niet op een of andere host van het cluster als een gewone virtuele machine onder KVM.

Waarom kan ik zo'n VM niet op de hosts van het cluster implementeren?

Aan het begin van het implementatieproces van de oVirt-beheerserver hebben we een dilemma - we moeten de beheersystem VM installeren, maar het cluster bestaat feitelijk nog niet, dus wat kunnen we in deze situatie bedenken? Juist – KVM installeren op de toekomstige knooppunt van het cluster, vervolgens daarop een virtuele machine creëren, bijvoorbeeld met CentOS en daarin de oVirt-engine implementeren. Dit kan doorgaans gedaan worden vanuit het oogpunt van volledige controle over die VM, maar dit is een foutieve intentie, omdat in dat geval 100% problemen met deze beheersystem VM zullen optreden:

• het kan niet tussen hosts (knooppunten) van het cluster worden gemigreerd in de oVirt-console;
• bij migratie via KVM met virsh migrate, zal deze VM niet toegankelijk zijn voor beheer vanuit de oVirt-console.
• de hosts van het cluster kunnen niet in onderhoudsmodus worden gezet, als deze VM van de ene host naar de andere wordt gemigreerd met behulp van virsh migrate.

Dus doe alles volgens de regels - gebruik voor de oVirt-beheerserver of een aparte host, of een onafhankelijke VM die daarop draait, of beter nog, doe het zoals in de tweede optie beschreven.

Optie 2
Installatie van de oVirt Engine Appliance op de door hem beheerde cluster-host.

Deze optie zal verder worden besproken als de meer correcte en gepaste in ons geval.
De vereisten voor zo'n VM worden hieronder beschreven, ik moet alleen toevoegen dat het aanbevolen is om minstens twee hosts in de infrastructuur te hebben, waarop de beheersystem VM kan draaien, om hem failover-bestendig te maken. Hier zou ik willen toevoegen dat, zoals ik al in de opmerkingen in het vorige artikel schreef, het me nog steeds niet is gelukt om splitbrain te krijgen op de oVirt-cluster van twee hosts, met de mogelijkheid om hosted-engine VM's daarop uit te voeren.

Installatie van de oVirt Engine Appliance op de eerste host van het cluster

Link naar de officiële documentatie - oVirt Zelfgehoste Engine-handleiding, hoofdstuk "De implementatie van de self-hosted engine via de opdrachtregel»

In het document worden de voorafgaande voorwaarden beschreven die moeten worden uitgevoerd voordat de hosted-engine VM wordt uitgerold, evenals het installatieproces zelf in detail uiteengezet, dus het heeft weinig zin om dit letterlijk te herhalen. Daarom richten we ons op enkele belangrijke details.

• Voordat we met alle acties beginnen, moeten we de virtualisatiesupport inschakelen in de BIOS-instellingen op de host.
• We installeren het pakket voor de hosted-engine installer op de host:

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

• We starten de procedure voor de uitrol van de oVirt Hosted Engine in een screen op de host (je kunt daaruit komen via Ctrl-A + D, sluiten via Ctrl-D):

screen
hosted-engine --deploy

Indien gewenst, kan de installatie worden gestart met een vooraf voorbereid antwoordbestand:

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

• Tijdens de uitrol van de hosted-engine geven we alle benodigde parameters op:

- naam van het cluster
- aantal vCPU en vRAM (aanbevolen: 4 vCPU en 16 GB)
- wachtwoorden
- type opslag voor de hosted engine VM – in ons geval FC
- nummer van de LUN voor de installatie van de hosted engine
- waar de database voor de hosted engine zich bevindt – ik raad aan om voor de eenvoud voor Local te kiezen (dit is een PostgreSQL-database die binnen deze VM werkt)
en andere parameters. 

• Voor de installatie van een hoog beschikbare VM met hosted engine hebben we op de SAN vooraf een speciale LUN met nummer 4 en een grootte van 150 GB aangemaakt, die vervolgens aan de hosts van het cluster is gepresenteerd – zie hiervoor vorig artikel.

Eerder hebben we ook de zichtbaarheid ervan op de hosts gecontroleerd:

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

• Het proces van de uitrol van de hosted-engine is niet ingewikkeld; aan het einde zouden we een soortgelijke melding moeten krijgen:

[ 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

We controleren de aanwezigheid van oVirt-services op de host:

Als alles correct is gedaan, kunnen we na de installatie met een webbrowser naar https://ovirt_hostname/ovirt-engine vanuit de computer van de beheerder gaan en klikken op [Administration Portal].

Screenshot van de ‘Administration Portal’

Voer de gebruikersnaam en het wachtwoord (ingevoerd tijdens de installatie) in het venster in zoals op de screenshot, en je komt in het controlepaneel van Open Virtualization Manager, waar je alle acties met de virtuele infrastructuur kunt uitvoeren:

1. een datacenter toevoegen
2. een cluster toevoegen en configureren
3. hosts toevoegen en beheren
4. opslagruimtes of Storage Domains toevoegen voor de schijven van virtuele machines
5. netwerken voor virtuele machines toevoegen en configureren
6. virtuele machines, installatiedisks, VM-sjablonen toevoegen en deze beheren

Al deze acties zullen verder worden besproken, sommige in grote lijnen, andere uitgebreider en met nuances.
Maar eerst zou ik aanbevelen deze aanvulling te lezen, die voor velen beslist nuttig kan zijn.

Aanvulling

1) In principe, als dat nodig is, staat niets je in de weg om vooraf de KVM-hypervisor op de knooppunten van het cluster te installeren met behulp van de pakketten libvirt en qemu-kvm (of qemu-kvm-ev) van de gewenste versie, hoewel bij het uitrollen van een knooppunt van het oVirt-cluster, dit ook automatisch kan gebeuren.

Maar als libvirt en qemu-kvm ze niet de meest recente versie zijn geïnstalleerd, kan het zijn dat je deze foutmelding krijgt tijdens het uitrollen van de hosted engine:

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

Dat wil zeggen, het is noodzakelijk om te beschikken over een bijgewerkte versie libvirt met bescherming tegen MDS, die zo'n beleid ondersteunt:

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

Installeer libvirt v.4.5.0-10.el7_6.12, met ondersteuning voor 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

Controleer of 'md-clear' wordt ondersteund:

virsh domcapabilities kvm | grep require

Daarna kun je doorgaan met de installatie van de hosted engine.

2) In oVirt 4.3 is de aanwezigheid en het gebruik van een firewall firewalld een verplicht vereiste.

Als we tijdens het uitrollen van de VM voor de hosted-engine deze foutmelding krijgen:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld moet ingeschakeld en actief zijn om de hosted-engine correct te implementeren. Controleer dit, corrigeer het en implementeer opnieuw."}
[ ERROR ] Fout bij het uitvoeren van fase 'Afsluiten': Fout bij het uitvoeren van ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Zorg ervoor dat een andere firewall (indien gebruikt) is uitgeschakeld, en installeer en start 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

In de toekomst, bij het installeren van de ovirt-agent op een nieuwe host voor het cluster, stelt deze de benodigde poorten in firewalld automatisch.

3) Herstart de host met een actieve VM met de hosted engine.

Zoals gewoonlijk, link 1 en link 2 in de handleidingen.

Alle beheersing van de hosted engine VM gebeurt ALLEEN via het commando hosted-engine op de host waar deze draait, vergeet virsh ook niet, net zoals dat je deze VM niet via SSH kunt aanroepen en daar het commando "shutdown».

Procedure om de VM in onderhoudsmodus te zetten:

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

Herstart de host met de hosted engine agent en doe wat we nodig hebben.

Na de herstart controleren we de status van de VM met de hosted engine:

hosted-engine --vm-status

Als onze VM met de hosted-engine niet opstart en we vergelijkbare fouten in het servicelog zien:

Fout in het servicelog:

journalctl -u ovirt-ha-agent
...
29 jun 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine FOUT Kan noodzakelijke monitoren niet starten
29 jun 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent FOUT Traceback (meest recente oproep laatst):#012  Bestand "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", regel 131, in _run_agent#012    return action(he)#012  Bestand "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", regel 55, in action_proper#012    return he.start_monitoring()#012  Bestand "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", regel 413, in start_monitoring#012    self._initialize_broker()#012  Bestand "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", regel 537, in _initialize_broker#012    m.get('options', {}))#012  Bestand "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", regel 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - kon monitor niet starten via ovirt-ha-broker: [Errno 2] Geen dergelijk bestand of directory, [monitor: 'ping', opties: {'addr': '172.20.32.32'}]
29 jun 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent FOUT Poging om agent te herstarten

Laten we de opslag aansluiten en de agent opnieuw opstarten:

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

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

Na het opstarten van de VM met hosted-engine, halen we deze uit de onderhoudsmodus:

Procedure om de VM uit de onderhoudsmodus te halen:

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
gestopt                             : False
Lokale onderhoud                   : False
crc32                              : 6d1eb25f
local_conf_timestamp               : 6222296
Host timestamp                     : 6222296
Extra metadata (geldig op timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (vr 17 jan 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (vr 17 jan 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        gestopt=False

4) Verwijdering van de hosted engine en alles wat daarmee verbonden is.

Soms is het noodzakelijk om een eerder geïnstalleerde hosted engine correct te verwijderen — link volgens het leidende document.

Voer gewoon de opdracht uit op de host:

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

Verwijder vervolgens onnodige pakketten, nadat je eventueel enkele configuraties hebt geback-upt:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Creëren van een nieuwe datacenter

Referentiedocumentatie — oVirt Administration Guide. Hoofdstuk 4: Datacenters

Laten we eerst definiëren wat een datacenter (citaat uit de handleiding) — is een logische entiteit die een set middelen definieert, gebruikt in een specifieke omgeving.

Een datacenter is een soort container die bestaat uit:

• logische middelen in de vorm van clusters en hosts
• netwerkresources van de cluster in de vorm van logische netwerken en fysieke adapters op hosts,
• opslagresources (voor VM-schijven, sjablonen, afbeeldingen) in de vorm van opslaggebieden (Storage Domains).

Een datacenter kan meerdere clusters omvatten, bestaande uit verschillende hosts met daarop draaiende virtuele machines, en kan ook verschillende opslaggebieden hebben die eraan zijn gekoppeld.
Er kunnen meerdere datacenters zijn die onafhankelijk van elkaar werken. In oVirt is er een rolgebaseerde autorisatie en kunnen machtigingen op een persoonlijke manier worden ingesteld, zowel op datacenter niveau als op de afzonderlijke logische elementen.

Het datacenter, of de datacenters als er meerdere zijn, worden beheerd vanuit één enkele administratieconsole of portal.

Om een datacenter te creëren, gaan we naar het administratieportal en creëren we een nieuw datacenter:
Compute >> Data Centers >> Nieuw

Aangezien we gebruik maken van gedeelde opslag op de SAN, moet het type opslag (Storage Type) Gedeeld zijn:

Screenshot met de wizard voor het aanmaken van een datacenter

Bij het installeren van een virtuele machine met hosted-engine, wordt er standaard een datacenter aangemaakt - Datacenter1, en later kan het type opslag (Storage Type) indien nodig worden veranderd naar een ander.

Het aanmaken van een datacenter is een eenvoudige taak, zonder ingewikkelde bijzonderheden, en alle aanvullende acties ermee zijn beschreven in de documentatie. Ik wil alleen opmerken dat losse hosts met alleen lokale opslag (schijf) voor VM's niet in een datacenter met Storage Type - Gedeeld kunnen komen (ze kunnen er niet aan worden toegevoegd), en voor hen moet een apart datacenter worden aangemaakt - dat wil zeggen, elke aparte host met lokale opslag heeft een apart datacenter nodig.

Creëren van een nieuw cluster

Link naar de documentatie - oVirt Administration Guide. Hoofdstuk 5: Clusters

Zonder overbodige details, cluster – is dit een logische groepering van hosts die een gemeenschappelijk opslaggebied hebben (in de vorm van gedeelde schijven op de SAN, zoals in ons geval). Het is ook wenselijk dat de hosts in het cluster identiek zijn qua hardware en dezelfde type processor hebben (Intel of AMD). Het is het beste dat de servers in het cluster volledig identiek zijn.

Een cluster maakt deel uit van het datacenter (met een bepaald type opslag - Local of Gedeeld), en alle hosts moeten verplicht tot een cluster behoren, afhankelijk van of ze wel of niet over gemeenschappelijke opslag beschikken.

Bij het installeren van een virtuele machine met hosted-engine op de host, wordt er standaard een datacenter aangemaakt - Datacenter1, samen met een cluster - Cluster1, en later kunnen de parameters ervan verder worden ingesteld, extra opties worden geactiveerd, hosts worden toegevoegd, enzovoort.

Zoals gebruikelijk, voor details over alle clusterinstellingen is het aan te raden de officiële documentatie te raadplegen. Wat betreft de specifieke instellingen van het cluster, wil ik alleen vermelden dat het bij de creatie ervan voldoende is om alleen de basiselementen in te stellen op het tabblad Algemeen.

Ik wil de belangrijkste parameters benadrukken:

• Processor type — wordt gekozen op basis van de processors die zijn geïnstalleerd op de hosts in het cluster, van welke fabrikant ze zijn en welke processor op de hosts het oudst is, zodat we op basis daarvan alle beschikbare instructies voor processors in het cluster kunnen gebruiken.
• Switch type – in ons cluster wordt alleen de Linux bridge gebruikt, dus dat kiezen we.
• Firewall type – hier is het duidelijk, dit is firewalld, dat ingeschakeld en ingesteld moet zijn op de hosts.

Screenshot met de clusterparameters

Extra hosts installeren in een Self-Hosted omgeving

Link in de documentatie.

Extra hosts voor een Self-Hosted omgeving worden op dezelfde manier toegevoegd als een gewone host, met de extra stap om de VM met de hosted engine te implementeren - Kies de actie voor de implementatie van de hosted engine >> Implementeren. Omdat de extra host ook een LUN voor de VM met de hosted engine moet worden gepresenteerd, betekent dit dat deze host, indien nodig, kan worden gebruikt voor de plaatsing van de VM met de hosted engine.
Om de beschikbaarheid te garanderen, wordt sterk aangeraden dat er minimaal twee hosts zijn waar de VM met de hosted engine kan worden geplaatst.

Bij de extra host schakelen we iptables uit (indien ingeschakeld), we schakelen firewalld in

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

We installeren de vereiste versie van KVM (indien nodig):

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

We installeren de benodigde repositories en de installer van de hosted engine:

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

Daarna gaan we naar de console Open Virtualization Manager, we add a new host and do everything step by step as described in de documentatie.

As a result, after adding the additional host, we should get an overview in the admin console similar to the screenshot.

Screenshot of the administrative portal — hosts

The host where the VM with the hosted engine is currently active has a golden crown and the inscription “Running the Hosted Engine VM”, the host where this VM can be started if necessary – the inscription “Can run the Hosted Engine VM».

In case of a failure of the host on which “Running the Hosted Engine VM”, it will automatically restart on the second host. Additionally, this VM can be migrated from the active host to the backup for maintenance.

Setting up Power Management / fencing on oVirt hosts

Links to the documentation:

• Red Hat Virtualization 4.3 –> Technical Reference -> Chapter 4. Power Management
• oVirt Administration Guide -> Chapter 7: Hosts

Although it may seem that adding and configuring a host is completed, it is not entirely so.
For normal operation of hosts and identification/removal of failures with any of them, the setup of Power Management / fencing is necessary.

Fencing, or fencing – is the process of temporarily excluding a faulty or failed host from the cluster, during which services or oVirt will either restart on it or the host itself.

All details regarding the definitions and parameters of Power Management / fencing are provided, as usual, in the documentation; I will just give an example of how to set up this important parameter, in application to Dell R640 servers with iDRAC 9.

1. Log in to the admin portal, click Compute >> Hosts select the host.
2. Click Edit.
3. Click the tab Power Management.
4. Check the box next to the option Enable Power Management.
5. Check the box next to the option Kdump integration, so that the host does not enter the fencing mode during the writing of the kernel crash dump.

Note.

After enabling Kdump integration on an already running host, it must be reinstalled according to the procedure in oVirt Administration Guide -> Chapter 7: Hosts -> Reinstalling Hosts.

1. Optionally, you can check the box Disable policy control of power management, if we do not want the host's power management to be controlled by the cluster's scheduling policy.
2. Click the button (+), to add a new power management device, an agent property editing window will open.
   For iDRAC9, fill in the fields:
   • Address – iDRAC9 address
   • User Name / Password – respectively the login and password to log into iDRAC9
   • Type — drac5
   • check Secure
   • add the following options: cmd_prompt=>,login_timeout=30

Screenshot met de parameters 'Power Management' in de eigenschappen van de host

Creëren van opslaggebieden of Storage Domains

Link naar de documentatie — oVirt Administratiehandleiding, Hoofdstuk 8: Opslag.

Opslagdomein, of opslagdomein – is een centraal punt voor het opslaan van virtuele schijven, install-image's, sjablonen en snapshots.

Opslagdomeinen kunnen verbinding maken met het datacenter via verschillende protocollen, cluster- en netwerkbestandssystemen.

oVirt heeft drie types opslagdomeinen:

• Datadomein – voor het opslaan van alle gegevens die verband houden met virtuele machines (schijven, sjablonen). Datadomein kan niet worden gedeeld tussen verschillende datacenters.
• ISO-domein (verouderd type opslagdomein) – voor het opslaan van installatie-images van besturingssystemen. ISO-domein kan worden gedeeld tussen verschillende datacenters.
• Exporteerdomein (verouderd type opslagdomein) – voor tijdelijke opslag van images die tussen datacenters worden verplaatst.

In ons specifieke geval gebruikt het opslagdomein van het type Datadomein het Fibre Channel Protocol (FCP) om verbinding te maken met de LUN's op de SAN.

Vanuit het perspectief van oVirt, bij gebruik van SAN (FC of iSCSI) is elke virtuele schijf, snapshot of sjabloon een logische schijf.
Blokapparaten worden samengevoegd in één geheel (op de hosts van de cluster) met behulp van Volume Group en worden vervolgens verdeeld met LVM in logische volumes die als virtuele schijven voor VM's worden gebruikt.

Al deze groepen en vele LVM-volumes kunnen op de clusterhost worden gezien met behulp van de opdrachten vgs en lvs. Natuurlijk moeten alle handelingen met zulke schijven alleen vanuit de oVirt-console worden uitgevoerd, behalve in bijzondere gevallen.

Virtuele schijven voor VM's kunnen van twee typen zijn — QCOW2 of RAW. Schijven kunnen 'dun' of 'dik'. Snapshots worden altijd aangemaakt als 'dun".

'. De manier waarop opslagdomeinen worden beheerd, of gebieden waarvoor toegang via FC wordt verkregen, is vrij logisch — voor elke virtuele schijf van een VM bestaat er een apart logische volume dat alleen door één host beschrijfbaar is. In het geval van verbindingen via FC gebruikt oVirt iets dat lijkt op clustered LVM.

Virtuele machines die zich op hetzelfde opslagdomein bevinden, kunnen worden gemigreerd tussen hosts die tot dezelfde cluster behoren.

Zoals uit de beschrijving blijkt, betekent een cluster in oVirt, net als een cluster in VMware vSphere of Hyper-V, in wezen hetzelfde - het is een logische groepering van hosts, bij voorkeur met een gelijke samenstelling van 'hardware', en met een gemeenschappelijke opslag voor de schijven van virtuele machines.

Laten we direct overgaan tot het creëren van een opslaggebied voor gegevens (virtuele schijven), want zonder dit zal het datacenter niet worden geïnitialiseerd.
Ter herinnering, alle aan de hosts van het cluster gepresenteerde LUN's op de opslagarray moeten zichtbaar zijn voor hen met behulp van het commando "multipath -ll».

Volgens de documentatie, laten we naar het portaal gaan en inloggen op Opslag >> Domains -> Nieuw Domein en de instructies in de sectie "FCP Opslag Toevoegen" volgen.

Na het starten van de wizard vullen we de vereiste velden in:

• Naam — we geven een naam aan het cluster
• Domeinfunctie — Gegevens
• Opslagtype — Fibre Channel
• Te gebruiken host — we kiezen de host waarop de gewenste LUN beschikbaar is

In de lijst met LUN's markeren we de benodigde, klikken op Add en vervolgens OK. Indien nodig kunnen aanvullende parameters van het opslaggebied worden aangepast door te klikken op Geavanceerde parameters.

Screenshot van de wizard voor het toevoegen van een "Opslagdomein"

Op basis van de resultaten van de wizard zouden we een nieuw opslaggebied moeten krijgen, en ons datacenter zou in de status moeten zijn UP, of geïnitialiseerd:

Screenshots van het datacenter en de opslaggebieden daarin:

Creëren en configureren van netwerken voor virtuele machines

Link naar de documentatie — oVirt Administratiehandleiding, Hoofdstuk 6: Logische Netwerken

Netwerken, of netwerken - dienen voor het groeperen van logische netwerken die worden gebruikt in de virtuele infrastructuur van oVirt.

Voor de interactie van de netwerkaard op de virtuele machine met de fysieke adapter op de host worden logische interfaces van het type Linux bridge gebruikt.

Voor het groeperen en scheiden van verkeer tussen netwerken zijn VLAN's ingesteld op de switches.

Bij het creëren van een logisch netwerk voor virtuele machines in oVirt, moet het verplicht een identificatienummer toegewezen krijgen dat overeenkomt met het VLAN-nummer op de switch, zodat de VM's met elkaar kunnen communiceren, zelfs als ze op verschillende knooppunten van het cluster draaien.

Voorlopige instellingen van netwerkaansluitingen op de hosts voor het aansluiten van virtuele machines moeten zijn uitgevoerd in vorig artikel – logische interface bond1, daarna moeten alle netwerkinstellingen alleen via het administratieve portaal van oVirt worden uitgevoerd.

Na het aanmaken van de VM met hosted-engine, zijn naast het automatisch aanmaken van het datacenter en het cluster, ook automatisch een logisch netwerk voor het beheer van ons cluster aangemaakt – ovritmgmt, waaraan deze VM was verbonden.

Indien nodig kunnen de instellingen van het logische netwerk worden bekeken ovritmgmt en aangepast, maar wees voorzichtig om de controle over de oVirt-infrastructuur niet te verliezen.

Instellingen van het logische netwerk ovritmgmt

Voor het aanmaken van een nieuw logisch netwerk voor reguliere VM's, gaan we in het beheerdersportaal naar Netwerk global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check >> Netwerken >> Nieuw, en op het tabblad Algemeen voegen we een netwerk toe met de benodigde VLAN-ID, en stellen we het vinkje in bij "VM-netwerk", dit betekent dat het kan worden gebruikt voor toewijzing aan VM's.

Screenshot van het nieuwe logische netwerk VLAN32

Op het tabblad Cluster, koppelen we dit netwerk aan onze cluster Cluster1.

Daarna gaan we naar Compute >> Hosts, en bezoeken we elke host afzonderlijk, naar het tabblad Netwerkinterfaces, en starten de wizard Hostnetwerken instellen, om de nieuwe logische netwerkinstellingen aan de hosts te koppelen.

Screenshot van de wizard "Hostnetwerken instellen"

De oVirt-agent maakt automatisch alle benodigde netwerkinstellingen op de host – maakt VLAN en BRIDGE aan.

Voorbeeld van configuratiebestanden voor nieuwe netwerken op de host:

cat ifcfg-bond1
# Gemaakt door VDSM versie 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
# Gemaakt door VDSM versie 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
# Gemaakt door VDSM versie 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=uit
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Ik herhaal nogmaals, dat op de clusterhost GEEN netwerkinterfaces handmatig vooraf moeten worden aangemaakt ifcfg-bond1.432 en ifcfg-ovirtvm-vlan432.

Na het toevoegen van het logische netwerk en het controleren van de verbinding tussen de host en de VM met de hosted engine, kan het in de virtuele machine worden gebruikt.

Creëren van een installatiedisc voor het uitrollen van een virtuele machine

Link naar de documentatie — oVirt Administratiehandleiding, Hoofdstuk 8: Opslag, sectie Afbeeldingen uploaden naar een gegevensopslagdomein.

Zonder een installatie-ISO kan de virtuele machine niet worden geïnstalleerd, hoewel dit natuurlijk geen probleem is als er in het netwerk bijvoorbeeld Cobbler met vooraf gemaakte afbeeldingen is geïnstalleerd.

In ons geval is die mogelijkheid er niet, dus moeten we deze afbeelding handmatig in oVirt importeren. Voorheen was het nodig om een ISO-domein aan te maken, maar in de nieuwe versie van oVirt is dit als verouderd beschouwd, en daarom kunnen afbeeldingen nu rechtstreeks in het opslagdomein vanuit het beheerdersportaal worden geüpload.

In het beheerdersportaal gaan we naar Opslag >> Schijven >> Uploaden >> Start
We voegen onze OS-afbeelding toe als een ISO-bestand, vullen alle velden in het formulier in en klikken op de knop "Test verbinding".

Screenshot van de wizard voor het toevoegen van de installatieafbeelding

Als we een foutmelding van dit type ontvangen:

Kan afbeelding niet uploaden naar schijf d6d8fd10-c1e0-4f2d-af15-90f8e636dadc door een netwerkfout. Zorg ervoor dat de ovirt-imageio-proxy service is geïnstalleerd en geconfigureerd en dat het CA-certificaat van ovirt-engine is geregistreerd als een vertrouwde CA in de browser. Het certificaat kan worden opgehaald van https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

Het is noodzakelijk het oVirt-certificaat toe te voegen aan «Vertrouwde wortel-CA's» (Trusted Root CA) op de beheerstations van de administrator, waarvandaan we proberen de afbeelding te uploaden.

Na het toevoegen van het certificaat aan de Trusted Root CA, klikken we weer op "Test verbinding", we zouden moeten krijgen:

Verbinding met ovirt-imageio-proxy was succesvol.

Na de actie om het certificaat toe te voegen, kan men proberen de ISO-afbeelding opnieuw te uploaden naar de Storage Domain.

In principe kan men een aparte Storage Domain met het type Data maken voor het opslaan van afbeeldingen en sjablonen, gescheiden van de schijven van de VM, of zelfs deze opslaan in de Storage Domain voor hosted engine, maar dat is al aan de discretie van de administrator.

Screenshot met ISO-afbeeldingen in de Storage Domain voor hosted engine

Creëren van een virtuele machine

Link naar documentatie:
oVirt Virtual Machine Management Guide –> Hoofdstuk 2: Linux Virtuele Machines Installeren
Console Clients Bronnen

Na het uploaden van de installatie afbeelding met de OS naar oVirt, kunnen we direct doorgaan met het creëren van de virtuele machine. Er is veel werk verzet, maar we bevinden ons al in de laatste fase, waarvoor dit alles is gedaan - het verkrijgen van een fouttolerante infrastructuur voor het hosten van hoogbeschikbare virtuele machines. En bovendien is dit alles volledig gratis - er is geen cent uitgegeven aan de aankoop van licenties voor software.

Om een virtuele machine met CentOS 7 te creëren, moet de installatie afbeelding met de OS zijn geüpload.

We gaan naar het administratieve portaal, gaan naar Compute >> Virtuele Machines, en starten de wizard voor het maken van VM. We vullen alle parameters en velden in, en klikken op OK. Het is heel eenvoudig als je de documentatie volgt.

Als voorbeeld geef ik de basis- en aanvullende instellingen van een hoogbeschikbare VM, met een aangemaakte schijf, aangesloten op het netwerk, en opstartend vanaf de installatie afbeelding:

Screenshots van de instellingen van de hoogbeschikbare VM

Na het voltooien van de wizard sluiten we het af, starten we de nieuwe VM en installeren we het OS erop.
Hiervoor gaan we naar de console van deze VM via het administratieve portaal:

Screenshot van de instellingen van het administratieve portaal voor verbinding met de console van de VM

Om verbinding te maken met de console van de VM, moet de console eerst worden ingesteld in de eigenschappen van de virtuele machine.

Screenshot van de instellingen van de VM, tabblad «Console»

Om verbinding te maken met de VM-console kan men bijvoorbeeld gebruiken, Virtual Machine Viewer.

Om rechtstreeks in de browser naar de VM-console te verbinden, moeten de verbindingsinstellingen als volgt zijn:

Na de installatie van het besturingssysteem op de VM is het aanbevolen om de oVirt gastagent te installeren:

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

Zo zullen, als resultaat van onze acties, de gemaakte VM's hoog beschikbaar zijn, dat wil zeggen, in het geval van een storing van de clusterknoop waarop ze draaien, zal oVirt deze automatisch herstarten op een tweede knoop. Tevens kan deze VM tussen de hosts van het cluster gemigreerd worden voor onderhoud of andere doeleinden.

Conclusie

Ik hoop dat dit artikel heeft kunnen overbrengen dat oVirt een volledig normaal gereedschap is voor het beheren van virtuele infrastructuren, dat niet zo moeilijk te implementeren is - het belangrijkste is om bepaalde regels en vereisten na te leven, zoals beschreven in zowel het artikel als de documentatie.

Vanwege de grote omvang van het artikel is het niet gelukt om veel zaken op te nemen, zoals stap-voor-stap uitvoering van verschillende wizard met gedetailleerde uitleg en screenshots, lange uitvoer van bepaalde commando's, enz. Eigenlijk zou daarvoor een heel boek nodig zijn, wat niet echt logisch is gezien de constant nieuwe versies van de software met innovaties en wijzigingen. Het belangrijkste is om het principe te begrijpen hoe alles samenwerkt en een algemeen algoritme van acties te verkrijgen voor het creëren van een fouttolerante platform voor het beheren van virtuele machines.

Hoewel we de virtuele infrastructuur hebben gecreëerd, moeten we deze nu leren om te interageren met zowel zijn afzonderlijke elementen: hosts, virtuele machines, interne netwerken, als met de externe wereld.

Dit proces is een van de belangrijkste taken van de systeem- of netwerkbeheerder, die in het volgende artikel zal worden behandeld - over het gebruik van virtuele routers VyOS in de fouttolerante infrastructuur van ons bedrijf (zoals je al geraden had, zullen ze functioneren als virtuele machines op onze oVirt-cluster).

Bron: habr.com