Skapa en robust IT-infrastruktur. Del 2. Installation och konfiguration av oVirt 4.3-klustret

Denna artikel är en fortsättning på den tidigare – «Skapande av en redundanssäker IT-infrastruktur. Del 1 - förberedelse för implementering av kluster oVirt 4.3».

I den kommer processen för grundläggande installation och konfigurering av oVirt 4.3-kluster att behandlas, för hosting av högt tillgängliga virtuella maskiner, med antagandet att alla preliminära steg för att förbereda infrastrukturen redan har utförts.

Inledande del

Huvudsyftet med artikeln är inte att ge en steg-för-steg-instruktion av typen «Next -> Ja -> Avsluta», utan att visa några specifika aspekter vid installation och konfigurering. Processen för att distribuera ditt kluster kanske inte alltid överensstämmer med det som beskrivs här, på grund av egenskaper hos infrastrukturen och miljön, men de allmänna principerna kommer att vara desamma.

Ur en subjektiv synpunkt, oVirt 4.3 är funktionellt lik VMware vSphere version 5.x, men självklart med sina egna inställningar och driftkarakteristika.

För den intresserade kan alla skillnader mellan RHEV (även kallat oVirt) och VMware vSphere hittas på internet, till exempel här, men jag kommer ändå ibland att påpeka vissa skillnader eller likheter dem emellan, under artikelns gång.

Separat skulle jag vilja jämföra arbetet med nätverk för virtuella maskiner något. I oVirt implementeras ett liknande princip för hantering av nätverk för virtuella maskiner (VM) som i VMware vSphere:

• med hjälp av standard Linux-brygga (i VMware — Standard vSwitch), som fungerar på virtualiseringsvärdar;
• med hjälp av Open vSwitch (OVS) (i VMware — Distributed vSwitch) – det är en distribuerad virtuell switch som består av två huvudkomponenter: den centrala OVN-servern och OVN-kontrollerna på de hanterade värdarna.

Det är värt att notera att på grund av enkelheten i implementeringen, kommer artikeln att beskriva nätverksinställningar i oVirt för VM med hjälp av standard Linux-brygga, som är det vanligaste valet när man använder KVM-hypervisorn.

I samband med detta finns det några grundläggande regler för nätverksarbete i klustret som bäst undviks att brytas:

• Alla nätverksinställningar på värdarna innan de läggs till oVirt, måste vara identiska, förutom IP-adresserna.
• När värden har tagits under oVirt:s kontroll, rekommenderas det starkt att inte göra några manuella ändringar i nätverksinställningarna utan fullständig säkerhet i sina handlingar, då oVirt-agenten helt enkelt kommer att återställa dem till tidigare inställningar efter omstart av värden eller agenten.
• Tillagning av ett nytt nätverk för VM, liksom att arbeta med det, bör endast göras från oVirt:s administrationskonsol.

Ytterligare en viktig anmärkning — för en mycket kritisk miljö (mycket känslig för ekonomiska förluster), rekommenderas det ändå att använda betald support och använda Red Hat Virtualization 4.3. Under driftsättningsprocessen av oVirt-klustret kan det uppstå vissa situationer där det är önskvärt att få kvalificerad hjälp så snabbt som möjligt istället för att försöka lösa dem själv.

Och slutligen, rekommenderas innan du sätter upp oVirt-klustret, bekanta dig med den officiella dokumentationen, för att vara medveten om åtminstone de grundläggande begreppen och definitionerna, annars kan det bli lite svårt att läsa artikeln längre fram.

De grundläggande dokumenten för att förstå artikeln och principerna för hur oVirt-klustret fungerar är:

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

Omfånget där är inte så stort, på en eller två timmar kan man lätt förstå de grundläggande principerna, och för dem som gillar detaljer rekommenderas att läsa Product Documentation for Red Hat Virtualization 4.3 — RHEV och oVirt är i princip samma sak.

Så, om alla grundläggande inställningar på värdarna, switcharna och lagringssystemen är utförda, går vi vidare till själva driftsättningen av oVirt.

Del 2. Installation och konfiguration av oVirt-klustret 4.3

För att underlätta orienteringen, kommer jag att lista de viktigaste avsnitten i denna artikel som bör genomföras i tur och ordning:

1. Installation av oVirt-hanteringsserver
2. Skapande av ett nytt datacenter
3. Skapande av ett nytt kluster
4. Installation av ytterligare värdar i Self-Hosted-miljö
5. Skapande av lagringsområden eller Storage Domains
6. Skapande och konfiguration av nätverk för virtuella maskiner
7. Skapande av installationsbild för driftsättning av en virtuell maskin
8. Skapa en virtuell maskin

Installation av oVirt-hanteringsserver

oVirt-hanteringsserver – är den viktigaste komponenten i oVirt-infrastrukturen, antingen som en virtuell maskin, värd, eller virtuellt enhet, som styr hela oVirt-infrastrukturen.

Dess närstående motsvarigheter inom virtualisering är:

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

För installationen av oVirt-hanteringsservern har vi två alternativ:

Alternativ 1
Driftsätta servern som en specialiserad VM eller värd.

Detta alternativ fungerar helt okej, men under förutsättning att VM:n opererar oberoende av klustret, d.v.s. den är inte igång på någon av klustrets värdar som en vanlig virtuell maskin under KVM.

Varför kan man inte driftsätta en sådan VM på klustrets värdar?

I början av processen för att distribuera oVirt-styrservern har vi en dilemma — vi måste installera den styrande virtuella maskinen, men själva klustret finns egentligen inte, så vad kan vi snabbt komma på? Rätt — installera KVM på den framtida klusterknuten, och därefter skapa en virtuell maskin där, till exempel med CentOS, och i den distribuera oVirt-engine. Detta görs vanligtvis av skäl för full kontroll över den virtuella maskinen, men det är en felaktig avsikt, eftersom det i detta fall kommer att uppstå problem med den styrande virtuella maskinen senare.

• Den kan inte migreras i oVirt-konsolen mellan värdarna (noderna) i klustret;
• vid migrering med hjälp av KVM genom virsh migrate, kommer denna virtuella maskin vara otillgänglig för hantering från oVirt-konsolen.
• Klustervärdarna kan inte sättas i Maintenance mode (underhållsläge), om man migrerar denna virtuella maskin från värd till värd med hjälp av virsh migrate.

Så gör allt enligt reglerna — använd antingen en separat värd för oVirt-styrservern eller en oberoende virtuell maskin som körs på den, men ännu bättre, gör som det beskrivs i det andra alternativet.

Alternativ 2
Installation av oVirt Engine Appliance på den hanterade klusterknuten.

Just detta alternativ kommer att behandlas nedan, som mer korrekt och lämpligt i vårt fall.
Krav för denna virtuella maskin beskrivs nedan, jag vill bara tillägga att det rekommenderas att ha minst två värdar i infrastrukturen där den styrande virtuella maskinen kan köras för att göra den redundant. Här vill jag tillägga, som jag redan nämnt i kommentarer i den tidigare artikeln, att jag fortfarande inte lyckades få splitbrain i oVirt-klustret med två värdar, med möjlighet att köra hosted-engine-vm på dem.

Installation av oVirt Engine Appliance på den första klusterknuten.

Länk till den officiella dokumentationen — oVirt Self-Hosted Engine Guide, kapitel "Deploying the Self-Hosted Engine Using the Command line»

Dokumentet anger förutsättningarna som måste uppfyllas innan den hosted-engine-vm distribueras och beskriver detaljerat installationsprocessen, så det finns ingen särskild mening med att upprepa den ordagrant; därför fokuserar vi på några viktiga detaljer.

• Innan du påbörjar alla åtgärder, se till att aktivera virtualiseringsstöd i BIOS-inställningarna på värden.
• Installera paketet för hosted-engine-installeraren på värden:

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 startar distributionen av oVirt Hosted Engine på värden i screen (man kan lämna det genom Ctrl-A + D, stänga det genom Ctrl-D):

screen
hosted-engine --deploy

Om så önskas kan installationen inledas med en förberedd svarfil:

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

• Under distributionen av hosted-engine anger vi alla nödvändiga parametrar:

- kluster namn
- antal vCPU och vRAM (rekommenderas 4 vCPU och 16 GB)
- lösenord
- lagringstyp för hosted engine VM – i vårt fall FC
- LUN-nummer för installation av hosted engine
- var databasen för hosted engine kommer att befinna sig – rekommenderar att för enkelhetens skull välja Local (detta är en PostgreSQL-databas som körs inuti denna VM)
och andra parametrar. 

• För att installera en hög tillgänglighets-VM med hosted engine har vi på lagringssystemet i förväg skapat en speciell LUN med nummer 4 och storlek 150 GB, som sedan presenterades för klustrets värdar – se i den föregående artikeln.

Tidigare har vi också kontrollerat dess synlighet på värdar:

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

• Själva processen för distribution av hosted-engine är inte komplicerad, i slutet bör vi få ett meddelande som liknar följande:

[ INFO  ] Genererar svarfil '\/var\/lib\/ovirt-hosted-engine-setup\/answers\/answers-20191129131846.conf'
[ INFO  ] Genererar svarfil '\/etc\/ovirt-hosted-engine\/answers.conf'
[ INFO  ] Steg: Pre-termination
[ INFO  ] Steg: Termination
[ INFO  ] Hosted Engine har framgångsrikt distribuerats

Kontrollerar existensen av oVirt-tjänster på värden:

Om allt har gjorts korrekt, så går vi efter installationen in med webbläsaren på https://ovirt_hostname/ovirt-engine från administrationsdatorn och klickar på [Administration Portal].

Skärmdump av "Administration Portal"

Genom att ange användarnamn och lösenord (anges under installationsprocessen) i fönstret som på skärmdumpen, kommer vi in i kontrollpanelen för Open Virtualization Manager, där vi kan utföra alla åtgärder med den virtuella infrastrukturen:

1. lägga till datacenter
2. lägga till och konfigurera kluster
3. lägga till värdar och hantera dem
4. lägga till lagringsområden eller Storage Domains för virtuella maskiners diskar
5. lägga till och konfigurera nätverk för virtuella maskiner
6. lägga till virtuella maskiner, installationsbilder, VM-mallar och hantera dem

Alla dessa åtgärder kommer att gås igenom vidare, vissa i stort och vissa mer detaljerat med nyanser.
Men först skulle jag rekommendera att läsa detta tillägg som säkert kan vara användbart för många.

Tillägg

1) I princip, om det finns ett sådant behov, så finns det inget som hindrar att installera KVM-hypervisorn på klusterknutarna i förväg med hjälp av paketen libvirt och qemu-kvm (eller qemu-kvm-ev) av önskad version, även om oVirt kan göra detta själv vid utplacering av klusterknuten.

Men om libvirt och qemu-kvm de installerades i en äldre version, kan man få följande fel under utplaceringen av hosted engine:

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

Det vill säga, det är nödvändigt att ha en uppdaterad version libvirt med stöd för MDS, som stöder en sådan policy:

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

Installera libvirt v.4.5.0-10.el7_6.12 med stöd för 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

Kontrollera om stöd för 'md-clear' finns:

virsh domcapabilities kvm | grep require

Efter detta kan installationen av hosted engine fortsätta.

2) I oVirt 4.3 är närvaron och användningen av en brandvägg firewalld ett obligatoriskt krav.

Om vi får följande fel under utplaceringen av VM för hosted-engine:

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld måste vara aktiverad och aktiv för att korrekt kunna deploya hosted-engine. Vänligen kontrollera, åtgärda och re-deploy.
"}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Måste en annan brandvägg stängas av (om den används), och installera och starta 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

Fortsättningsvis, vid installationen av ovirt-agenten på en ny värd för klustret kommer den att automatiskt konfigurera de nödvändiga portarna. firewalld automatiskt.

3) Omstart av värden med en VM som kör hosted engine.

Som vanligt, länk 1 och länk 2 om guiderna.

All hantering av hosted engine VM görs ENDAST med hjälp av kommandot hosted-engine på värden där den körs, om virsh ska glömmas bort, liksom att denna VM kan anslutas via SSH och kommandot ‘avstängning».

Procedur för att ställa in VM i underhållsläge:

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

hosted-engine --vm-status
!! Kluster är i GLOBALT UNDERHÅLLsläge !!
--== Värd host1.test.local (id: 1) status ==--
conf_on_shared_storage             : True
Status uppdaterad                 : True
Värdnamn                         : host1.test.local
Värd-ID                           : 1
Motors status                     : {"health": "good", "vm": "up", "detail": "Up"}
Poäng                             : 3400
stoppad                           : False
Lokalt underhåll                  : False
crc32                             : dee1a774
lokal_conf_timestamp              : 1821
Värd timestamp                    : 1821
Extra metadata (giltig vid 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 startar om värden med hosted engine-agenten och gör det vi behöver.

Efter omstarten kontrollerar vi status för VM med hosted engine:

hosted-engine --vm-status

Om vår VM med hosted-engine inte startar och om vi ser liknande fel i tjänstjournalen:

Fel i tjänstjournalen:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine FEL Misslyckades med att starta nödvändiga övervakare
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent FEL Spårning (senaste samtalet längst ner):#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", rad 131, i _run_agent#012    return action(he)#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", rad 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", rad 413, i start_monitoring#012    self._initialize_broker()#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", rad 537, i _initialize_broker#012    m.get('options', {}))#012  Fil "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", rad 86, i start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - misslyckades med att starta övervakaren via ovirt-ha-broker: [Errno 2] Ingen sådan fil eller katalog, [övervakare: 'ping', alternativ: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent FEL Försöker att starta om agenten

Då ansluter vi lagringen och startar om agenten:

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

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

Efter att VM med hosted-engine har startats, tar vi den ur underhållsläge:

Procedur för att ta ut VM ur underhållsläge:

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

--== Värd host1.test.local (id: 1) status ==--

conf_on_shared_storage             : True
Status up-to-date                  : True
Värdnamn                           : host1.test.local
Värd ID                            : 1
Motorstatus                        : {"health": "good", "vm": "up", "detail": "Up"}
Poäng                              : 3400
stoppad                            : False
Lokal underhåll                    : False
crc32                              : 6d1eb25f
local_conf_timestamp               : 6222296
Värd tidsstempel                   : 6222296
Extra metadata (giltigt vid tidsstämpel):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (Fredag 17 Jan 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (Fredag 17 Jan 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        stopped=False

4) Borttagning av hosted engine och allt relaterat.

Ibland kan det vara nödvändigt att korrekt ta bort en tidigare installerad hosted engine — länk enligt handboken.

Vi kör helt enkelt kommandot på värden:

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

Därefter tar vi bort onödiga paket, efter att vi ha säkerhetskopierat några konfigurationer om det behövs:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Skapande av ett nytt datacenter

Referensdokumentation — oVirt Administration Guide. Kapitel 4: Datanätverk

Först definierar vi vad som menas med datanätverk (citat från handboken) — en logisk enhet som definierar en uppsättning resurser som används i en specifik miljö.

Datanätverk är en slags behållare som består av:

• logiska resurser i form av kluster och värdar
• nätverksresurser för klustret i form av logiska nätverk och fysiska adaptrar på värdar,
• lagringsresurser (för VM-diskar, mallar, bilder) i form av lagringsdomäner.

Ett datanätverk kan inkludera flera kluster, bestående av flera värdar med virtuella maskiner som körs på dem, och kan också ha flera lagringsdomäner associerade med det.
Det kan finnas flera datanätverk som fungerar oberoende av varandra. I oVirt finns det en rollbaserad behörighetsindelning, och du kan ställa in behörigheter individuellt, både på datanätverksnivå och för dess enskilda logiska delar.

Datanätverket, eller datanätverken om det finns flera, hanteras från en enhetlig administrativa konsol eller portal.

För att skapa ett datanätverk, går vi in i den administrativa portalen och skapar ett nytt datanätverk:
Beräkning >> Datanätverk >> Ny

Eftersom vi använder delad lagring på SANS, så måste lagringstypen (Storage Type) vara Delad:

Skärmdump med guiden för att skapa ett datanätverk

Vid installation av en virtuell maskin med hosted-engine skapas som standard ett datacenter – Datacenter1, och vid behov kan man ändra lagringstypen (Storage Type) till en annan.

Att skapa ett datacenter är en enkel uppgift utan några komplicerade detaljer, och alla ytterligare åtgärder med detta beskrivs i dokumentationen. Jag vill bara påpeka att enskilda värdar med endast lokal lagring (disk) för VM inte kan läggas till i ett datacenter med Storage Type – Shared, och för dem måste man skapa ett eget datacenter – d.v.s. varje enskild värd med lokal lagring behöver sitt eget datacenter.

Skapande av ett nytt kluster

Länk till dokumentationen – oVirt Administration Guide. Kapitel 5: Kluster

Utan onödiga detaljer, kluster – detta är en logisk gruppering av värdar som har ett gemensamt lagringsområde (i form av delade diskar på lagringssystemet, som i vårt fall). Det är också önskvärt att värdarna i klustret är identiska vad gäller hårdvara och har samma processorstyp (Intel eller AMD). Bäst av allt är det om servrarna i klustret är helt identiska.

Klustret ingår i ett datacenter (med en viss lagringstyp – Local eller Dela), och alla värdar måste nödvändigtvis tillhöra något kluster, beroende på om de har gemensam lagring eller inte.

Vid installation av en virtuell maskin med hosted-engine på värden skapas som standard ett datacenter – Datacenter1, tillsammans med klustret – Cluster1, och i framtiden kan du konfigurera dess inställningar, aktivera ytterligare alternativ, lägga till värdar osv.

Som vanligt, för att få detaljerad information om alla inställningar för klustret, rekommenderar jag att du konsulterar den officiella dokumentationen. En liten särskildhet i klusterinställningen är att när du skapar det räcker det att ställa in de grundläggande parametrarna på fliken General.

Jag vill nämna de viktigaste parametrarna:

• Processor typ – väljs baserat på vilken typ av processorer som är installerade på värdarna i klustret, från vilken tillverkare de kommer ifrån, och vilken processor som är den äldsta på värdarna, så att man beroende på detta kan använda alla tillgängliga processorinstruktioner i klustret.
• Switch typ – vi använder endast Linux bridge i vårt kluster, så vi väljer det.
• Firewall typ – här är allt klart, det är firewalld, som måste vara aktiverad och konfigurerad på värdarna.

Skärmbild med parametrar för klustret.

Installation av ytterligare värdar i en Self-Hosted miljö

Länk i dokumentationen.

Ytterligare värdar för Self-Hosted miljö kan läggas till precis som vanliga värdar, med ett extra steg för att distribuera en VM med hosted engine — Välj åtgärd för distribution av hosted engine >> Distribuera. Eftersom den extra värden också måste presentationen av LUN för VM med hosted engine, innebär det att denna värd kan användas för att vara värd för en VM med hosted engine om så behövs.
För att säkerställa hög tillgänglighet rekommenderas det starkt att ha minst två värdar där en VM med hosted engine kan placeras.

På den extra värden inaktiverar vi iptables (om det är aktiverat), aktiverar firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installerar den erforderliga versionen av KVM (om nödvändigt):

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

Installerar nödvändiga repository och installation av 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

Därefter går vi till konsolen Open Virtualization Manager, lägger till en ny värd och gör allt steg för steg, precis som det står i dokumentationen.

Som ett resultat, efter att ha lagt till den extra värden, bör vi få en cirka bild i administrationskonsolen, som på skärmdumpen.

Skärmdump av administrationsportalen — värdar

Värden där VM med hosted-engine för närvarande är aktiv har en gyllene krona och inskrift "Kör den Hosted Engine VM", värden där denna VM kan startas vid behov – inskriften "Kan köra den Hosted Engine VM».

I händelse av att värden som "Kör den Hosted Engine VM", automatiskt kommer att startas om på den andra värden. Denna VM kan även migreras från den aktiva värden till den reservens, för underhåll.

Inställning av Power Management / fencing på oVirt-värdar

Länkar till dokumentationen:

• Red Hat Virtualization 4.3 –> Teknisk referens -> Kapitel 4. Power Management
• oVirt Administrationsguide -> Kapitel 7: Värdar

Även om det kan verka som att tillägg och konfiguration av värdena är genomförda, är det inte helt så.
För att säkerställa att värdarna fungerar korrekt och identifiera/lösa eventuella fel med dem, behövs en inställning av Power Management / fencing.

Fencing, eller inhägnad – är en process för tillfällig uteslutning av en felaktig eller störd värd från klustret, under vilken antingen oVirt-tjänster på den, eller själva värden, startas om.

All information om definitioner och parametrar för Power Management / inhägnad ges, som vanligt, i dokumentationen; jag kommer bara att ge ett exempel på hur man konfigurerar denna viktiga parameter i samband med Dell R640-servrar med iDRAC 9.

1. Vi går in i administrationsportalen, klickar på Beräkning >> Hosts väljer värden.
2. Klicka på Edit.
3. Klicka på fliken Power Management.
4. Markera kryssrutan bredvid alternativet Enable Power Management.
5. Markera kryssrutan bredvid alternativet Kdump integration, så att värden inte går in i inhägnadsläge (fencing) under skrivning av kärnans kraschdump.

Anteckning.

Efter att ha aktiverat Kdump integration på en redan fungerande värd, måste den installerats om enligt proceduren i oVirt Administration Guide -> Kapitel 7: Värdar -> Reinstalling Hosts.

1. Valfritt kan man markera kryssrutan Disable policy control of power management, om vi inte vill att värdhantering ska styras av klustrets schemaläggningspolicy (Scheduling Policy).
2. Klicka på knappen (+), för att lägga till en ny energihanteringsenhet, en redigeringsruta för agentens egenskaper öppnas.
   För iDRAC9, fyll i fälten:
   • Address – adress till iDRAC9
   • User Name / Password – respektive inloggning och lösenord för att logga in på iDRAC9
   • Type — drac5
   • notera Secure
   • lägga till följande alternativ: cmd_prompt=>,login_timeout=30

Skärmdump med parametrarna 'Power Management' i värdens egenskaper

Skapande av lagringsområden eller Storage Domains

Länk till dokumentationen – oVirt Administration Guide, Chapter 8: Storage.

Storage Domain, eller lagringsområde – är en centraliserad plats för lagring av diskar för virtuella maskiner, installationsbilder, mallar och snapshots.

Lagringsområden kan kopplas till datacentret med hjälp av olika protokoll, kluster- och nätverksfilsystem.

oVirt har tre typer av lagringsområden:

• Data Domain – för lagring av all data relaterad till virtuella maskiner (diskar, mallar). Data Domain kan inte delas mellan olika datacenter.
• ISO Domain (en föråldrad typ av lagringsområde) – för lagring av installationsbilder för OS. ISO Domain kan delas mellan olika datacenter.
• Export Domain (en föråldrad typ av lagringsområde) – för tillfällig lagring av bilder som flyttas mellan datacenter.

I vårt specifika fall använder lagringsområdet av typen Data Domain Fibre Channel Protocol (FCP) för att ansluta till LUN på lagringssystemet.

Ur oVirt, när man använder lagringsnätverk (FC eller iSCSI), är varje virtuell disk, snapshot eller mall en logisk disk.
Blocklagringsenheter sammanförs till en helhet (på värdarna i klustret) med hjälp av en Volymgrupp och delas sedan upp i logiska volymer som används som virtuella diskar för VM.

Alla dessa grupper och mängder av LVM-volymer kan ses på värden i klustret med hjälp av kommandon vgs och lvs. Naturligtvis bör alla åtgärder med sådana diskar endast göras från oVirt-konsolen, med undantag för särskilda fall.

Virtuella diskar för VM kan vara av två typer - QCOW2 eller RAW. Diskarna kan vara "tunna" eller "tjocka". Snapshots skapas alltid som "tunna".

". Hantering av lagringsdomäner, eller lagringsområden, som nås via FC är ganska logisk - för varje virtuell disk av VM finns det en separat logisk volym, som endast är skrivbar för en värd. Vid anslutningar via FC använder oVirt något som liknar kluster-LVM.

Virtuella maskiner som ligger på samma lagringsområde kan migreras mellan värdar som tillhör samma kluster.

Som vi kan se av beskrivningen betyder kluster i oVirt, precis som kluster i VMware vSphere eller Hyper-V, i grunden samma sak - en logisk gruppering av värdar, helst av samma hårdvarukonfiguration, och har en gemensam lagring för virtuella maskiners diskar.

Låt oss gå direkt till skapandet av lagringsområde för data (diskar för VM), eftersom utan det kommer datacentret inte att initieras.
Jag påminner om att alla LUN:er som presenteras för klustervärdarna på lagringssystemet måste synas för dem med hjälp av kommandot "multipath -ll».

Enligt dokumentationen", vi går till portalen och går in i Storage >> Domäner -> New Domain och följer instruktionerna i avsnittet "Adding FCP Storage".

Efter att ha startat guiden, fyller vi i de nödvändiga fälten:

• Namn — anger namnet på klustret
• Domain Function — Data
• Storage Type — Fibre Channel
• Host to Use — väljer värden där den önskade LUN är tillgänglig

I listan över LUN:er markerar vi den vi behöver, klickar på Add och sedan Okej. Om nödvändigt kan ytterligare parametrar för lagringsområdet justeras genom att klicka på Advanced Parameters.

Skärmdump av guiden för att lägga till "Storage domain"

Som resultat av guiden bör vi få ett nytt lagringsområde, och vårt datacenter gå över till status UP, eller initierad:

Skärmdumpar av datacentret och lagringsområdena i det:

Skapande och konfiguration av nätverk för virtuella maskiner

Länk till dokumentationen – oVirt Administration Guide, Kapitel 6: Logiska nätverk

Nätverk, eller nätverk – används för att gruppera logiska nätverk som används i den virtuella infrastrukturen oVirt.

För att interagera mellan nätverksadaptern på den virtuella maskinen och den fysiska adaptern på värden, används logiska gränssnitt av typen Linux bridge.

För att gruppera och separera trafik mellan nätverk, är VLAN konfigurerade på switcharna.

Vid skapandet av ett logiskt nätverk för virtuella maskiner i oVirt, måste ett identifieringsnummer tilldelas som motsvarar VLAN-numret på switchen, så att VM:erna kan interagera med varandra även om de körs på olika noder i klustret.

Förberedande inställningar av nätverksadaptrar på värdarna för anslutning av virtuella maskiner bör ha utförts i den föregående artikeln – logiskt gränssnitt konfigurerat bond1, därefter ska alla nätverksinställningar göras endast via den administrativa portalen oVirt.

Efter skapandet av VM med hosted-engine, förutom automatisk skapelse av datacenter och kluster, skapades också ett logiskt nätverk för att hantera vårt kluster – ovritmgmt, till vilket denna VM var ansluten.

Vid behov kan man se inställningarna för det logiska nätverket ovritmgmt och justera dem, men man måste vara försiktig så att man inte tappar kontrollen över oVirt-infrastrukturen.

Inställningar för det logiska nätverket ovritmgmt

För att skapa ett nytt logiskt nätverk för vanliga VM:er, går vi in i den administrativa portalen Nätverk >> Nätverk >> Ny, och på fliken General lägger vi till ett nätverk med det önskade VLAN-identifieringsnumret och markerar också rutan bredvid "VM-nätverk", vilket innebär att det kan användas för tilldelning till VM:er.

Skärmbild av det nya logiska nätverket VLAN32

På fliken Kluster, vi kopplar detta nätverk till vårt kluster Cluster1.

Efter detta går vi till Beräkning >> Hosts, går in i varje värd i tur och ordning, på fliken Nätverksgränssnitt, och startar guiden Konfigurera värdnätverk, för att koppla det nya logiska nätverket till värdarna.

Skärmbild av guiden "Konfigurera värdnätverk"

Agenten oVirt kommer automatiskt att göra alla nödvändiga nätverksinställningar på värden – skapa VLAN och BRIDGE.

Exempel på konfigurationsfiler för nya nätverk på värden:

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

Jag vill återigen påminna om att på värden i klustret DE BEHÖVER INTE manuellt skapa nätverksgränssnitt ifcfg-bond1.432 och ifcfg-ovirtvm-vlan432.

Efter att ha lagt till det logiska nätverket och kontrollerat anslutningen mellan värden och VM med hosted engine, kan det användas i den virtuella maskinen.

Skapande av installationsbild för driftsättning av en virtuell maskin

Länk till dokumentationen – oVirt Administration Guide, Chapter 8: Storage, avsnittet Uppladdning av bilder till en datalagringsdomän.

Utan installationsbilden av operativsystemet kommer det inte att vara möjligt att installera den virtuella maskinen, även om det visserligen inte är ett problem, om det i nätverket finns exempelvis Cobbler med förbereda bilder.

I vårt fall finns den möjligheten inte, så vi måste importera denna bild själv till oVirt. Tidigare krävdes det att skapa en ISO-domän för detta, men i den nya versionen av oVirt har den ansetts föråldrad, och därför kan bilder nu laddas upp direkt till lagringsdomänen från administrationsportalen.

I administrationsportalen gå till Storage >> Disks >> Ladda upp >> Start
Lägg till vår bild av operativsystemet som en ISO-fil, fyll i alla fält i formuläret och klicka på knappen "Testa anslutning".

Skärmdump av guiden för att lägga till installationsbilden

Om vi får ett fel av denna typ:

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

Då måste certifikatet oVirt läggas till i "Betrodda rot-CAi administratörens arbetsstation, därifrån vi försöker ladda upp bilden.

Efter att ha lagt till certifikatet i Betrodda rot-CA, klickar vi igen på "Testa anslutning", bör vi få:

Anslutningen till ovirt-imageio-proxy var framgångsrik.

När åtgärden att lägga till certifikatet är utförd kan vi försöka ladda upp ISO-bilden till lagringsdomänen igen.

I princip kan man skapa en separat lagringsdomän med typ Data, för att lagra bilder och mallar separat från VM-diskar, eller till och med lagra dem i lagringsdomänen för hosted engine, men det är upp till administratören.

Skärmdump med ISO-bilder i lagringsdomänen för hosted engine

Skapa en virtuell maskin

Länk till dokumentationen:
oVirt Virtual Machine Management Guide –> Kapitel 2: Installera Linux Virtuella Maskiner
Konsolklientresurser

Efter att ha laddat upp installationsavbilden med operativsystemet i oVirt kan vi gå vidare till att skapa en virtuell maskin. Mycket har redan gjorts, men vi är nu på det sista steget för att uppnå en hög tillgänglighet infrastruktur för hosting av högpresterande virtuella maskiner. Och allt detta är helt gratis – inga pengar har lagts på att köpa några mjukvarulicenser.

För att skapa en virtuell maskin med CentOS 7 måste installationsavbilden med operativsystemet vara laddad.

Logga in på administrationsportalen och gå till Beräkning >> Virtual Machines, och starta guiden för att skapa en VM. Fyll i alla parametrar och fält, och klicka på Okej. Det är mycket enkelt om man följer dokumentationen.

Som exempel kommer jag att ge de grundläggande och ytterligare inställningarna för en hög tillgänglighets-VM, med en skapad disk, kopplad till nätverket, och som startar från installationsavbilden:

Skärmbilder med inställningar för hög tillgänglighets-VM

Efter att ha avslutat arbetet med guiden stänger vi den, startar den nya VM och installerar operativsystemet på den.
För detta går vi in i konsolen för denna VM via administrationsportalen:

Skärmbild av inställningarna för administrationsportalen för att ansluta till konsolen för VM

För att ansluta till konsolen för VM måste konsolen först konfigureras i egenskaperna för den virtuella maskinen.

Skärmbild av inställningarna för VM, fliken «Console»

För att ansluta till konsolen för VM kan man använda till exempel Virtual Machine Viewer.

För att ansluta till konsolen för VM direkt i webbläsarfönstret måste anslutningsinställningarna vara sådana:

Efter att ha installerat operativsystemet på VM är det önskvärt att installera oVirt-gästagent:

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

Således, som ett resultat av våra åtgärder, kommer den skapade VM att vara hög tillgänglig, det vill säga om noden i klustret där den körs går ner, kommer oVirt automatiskt att starta om den på den andra noden. Denna VM kan också migreras mellan värdar i klustret för underhåll eller andra ändamål.

Slutsats

Jag hoppas att denna artikel lyckades förmedla att oVirt är ett fullt fungerande verktyg för hantering av virtuell infrastruktur som inte är så svårt att implementera — det viktigaste är att följa vissa regler och krav, beskrivna både i artikeln och i dokumentationen.

På grund av artikelns stora omfattning har många saker inte kunnat inkluderas, såsom steg-för-steg-instruktioner för olika guider med alla detaljerade förklaringar och skärmdumpar, långa utdata från olika kommandon, osv. Egentligen skulle detta kräva att skriva en hel bok, vilket inte är särskilt meningsfullt med tanke på att nya versioner av programvaran ständigt dyker upp med nya funktioner och ändringar. Det viktigaste är att förstå principen för hur allt fungerar tillsammans och få en övergripande handlingsplan för att skapa en redundant plattform för hantering av virtuella maskiner.

Även om vi har skapat den virtuella infrastrukturen, måste vi nu lära oss att få den att interagera både mellan sina olika element: värdar, virtuella maskiner, interna nätverk, och med omvärlden.

Denna process är en av de viktigaste uppgifterna för en system- eller nätverksadministratör, som kommer att behandlas i nästa artikel — om användningen av virtuella routrar, VyOS, i vår företags redundanta infrastruktur (som ni kanske har gissat, kommer de att fungera som virtuella maskiner på vår oVirt-kluster).

Källa: habr.com