Skapande av en feltolerant IT-infrastruktur. Del 2. Installera och konfigurera oVirt 4.3-klustret

Den här artikeln är en fortsättning på den föregående - "Skapande av en feltolerant IT-infrastruktur. Del 1 - förbereder för att distribuera ett oVirt 4.3-kluster".

Den kommer att täcka processen för grundläggande installation och konfiguration av ett oVirt 4.3-kluster för att vara värd för högt tillgängliga virtuella maskiner, med hänsyn till det faktum att alla preliminära steg för att förbereda infrastrukturen redan har slutförts tidigare.

prodrome

Huvudsyftet med artikeln är att ge steg-för-steg-instruktioner som "Nästa -> Ja -> Finish"hur man visar vissa funktioner när man installerar och konfigurerar det. Processen för att distribuera ditt kluster kanske inte alltid sammanfaller med det som beskrivs i det, på grund av egenskaperna hos infrastrukturen och miljön, men de allmänna principerna kommer att vara desamma.

Ur en subjektiv synvinkel, oVirt 4.3 dess funktionalitet liknar VMware vSphere version 5.x, men naturligtvis med sina egna konfigurations- och driftsfunktioner.

För den intresserade kan alla skillnader mellan RHEV (aka oVirt) och VMware vSphere hittas på Internet, till exempel här, men jag kommer ändå ibland att notera några av deras skillnader eller likheter med varandra när artikeln fortskrider.

Separat skulle jag vilja jämföra lite arbetet med nätverk för virtuella maskiner. oVirt implementerar en liknande princip för nätverkshantering för virtuella maskiner (hädanefter kallade virtuella datorer), som i VMware vSphere:

• med hjälp av standard Linux brygga (i VMware - Standard vSwitch), körs på virtualiseringsvärdar;
• med Open vSwitch (OVS) (i VMware - Distribuerad vSwitch) är en distribuerad virtuell switch som består av två huvudkomponenter: en central OVN-server och OVN-kontroller på hanterade värdar.

Det bör noteras att på grund av implementeringens enkelhet kommer den här artikeln att beskriva hur man konfigurerar nätverk i oVirt för virtuella maskiner med hjälp av standarden Linux brygga, vilket är standardvalet när KVM-hypervisorn används.

I detta avseende finns det flera grundläggande regler för att arbeta med nätverket i ett kluster, som är bäst att inte bryta mot:

• Alla nätverksinställningar på värdar innan de läggs till i oVirt måste vara identiska, förutom IP-adresser.
• När en värd väl har tagits under kontroll av oVirt, rekommenderas det starkt inte att ändra något manuellt i nätverksinställningarna utan att helt lita på dina handlingar, eftersom oVirt-agenten helt enkelt kommer att rulla tillbaka dem till de tidigare efter omstart av värden eller ombud.
• Att lägga till ett nytt nätverk för en virtuell dator, samt att arbeta med det, bör endast göras från oVirt-hanteringskonsolen.

Annan Viktig notering — för en mycket kritisk miljö (mycket känslig för monetära förluster), skulle det fortfarande rekommenderas att använda betald support och användning Red Hat Virtualization 4.3. Under driften av oVirt-klustret kan vissa problem uppstå för vilka det är tillrådligt att få kvalificerad hjälp så snart som möjligt, snarare än att ta itu med dem själv.

Och slutligen rekommenderad Innan du distribuerar ett oVirt-kluster, bekanta dig med officiell dokumentation, för att vara medveten om åtminstone de grundläggande begreppen och definitionerna, annars blir det lite svårt att läsa resten av artikeln.

Grundläggande för att förstå artikeln och principerna för driften av oVirt-klustret är dessa vägledningsdokument:

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

Volymen där är inte särskilt stor, på en timme eller två kan du ganska behärska grundprinciperna, men för den som gillar detaljer rekommenderas att läsa Produktdokumentation för Red Hat Virtualization 4.3 — RHEV och oVirt är i huvudsak samma sak.

Så, om alla grundläggande inställningar på värdarna, switcharna och lagringssystemen har slutförts, fortsätter vi direkt till distributionen av oVirt.

Del 2. Installera och konfigurera oVirt 4.3-klustret

För att underlätta orienteringen kommer jag att lista huvudsektionerna i den här artikeln, som måste fyllas i en efter en:

1. Installera oVirt-hanteringsservern
2. Skapande av ett nytt datacenter
3. Skapar ett nytt kluster
4. Installera ytterligare värdar i en Self-Hosted-miljö
5. Skapa ett lagringsområde eller lagringsdomäner
6. Skapa och konfigurera nätverk för virtuella maskiner
7. Skapa en installationsavbildning för att distribuera en virtuell maskin
8. Skapa en virtuell maskin

Installera oVirt-hanteringsservern

oVirt-hanteringsserver är det viktigaste elementet i oVirt-infrastrukturen, i form av en virtuell maskin, värd eller virtuell enhet som hanterar hela oVirt-infrastrukturen.

Dess nära analoger från virtualiseringsvärlden är:

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

För att installera oVirt-hanteringsservern har vi två alternativ:

Alternativ 1
Distribuera en server i form av en specialiserad virtuell dator eller värd.

Detta alternativ fungerar ganska bra, men förutsatt att en sådan virtuell dator fungerar oberoende av klustret, d.v.s. körs inte på någon klustervärd som en vanlig virtuell maskin som kör KVM.

Varför kan en sådan virtuell dator inte distribueras på klustervärdar?

Alldeles i början av driftsättningsprocessen för oVirt-hanteringsservern står vi inför ett dilemma: vi behöver installera en virtuell hanteringsmaskin, men själva klustret finns ännu inte, så vad är den bästa lösningen? Den rätta lösningen är att installera KVM på den framtida klusternoden och sedan skapa en virtuell maskin på den, kanske med ett operativsystem. CentOS och distribuera oVirt-motorn i den. Detta kan vanligtvis göras för att få full kontroll över en sådan virtuell maskin, men det är en felaktig avsikt, eftersom problem med en sådan kontroll-VM i det här fallet till 100 % kommer att uppstå i framtiden:

• den kan inte migreras i oVirt-konsolen mellan värdar (noder) i klustret;
• vid migrering med KVM via virsh migrera, kommer denna virtuella dator inte att vara tillgänglig för hantering från oVirt-konsolen.
• klustervärdar kan inte visas i underhållsläge (underhållsläge), om du migrerar den här virtuella datorn från värd till värd med hjälp av virsh migrera.

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

Alternativ 2
Installera oVirt Engine Appliance på en klustervärd som hanteras av den.

Det är detta alternativ som kommer att betraktas som mer korrekt och lämpligt i vårt fall.
Kraven för en sådan virtuell dator beskrivs nedan, jag vill bara tillägga att det rekommenderas att ha minst två värdar i infrastrukturen som kontroll-VM kan köras på för att göra den feltolerant. Här skulle jag vilja tillägga att jag, som jag redan skrev i kommentarerna i föregående artikel, aldrig kunde få splitbrain på ett oVirt-kluster med två värdar, med möjlighet att köra virtuella datorer med värdmotorer på dem.

Installera oVirt Engine Appliance på den första värden i klustret

Länk till officiell dokumentation - oVirt Self-Hosted Engine Guide, kapitel "Distribuera den självhostade motorn med hjälp av kommandoraden»

Dokumentet specificerar de förutsättningar som måste uppfyllas innan en VM med värdmotor distribueras, och beskriver också i detalj själva installationsprocessen, så det är ingen mening att upprepa det ordagrant, så vi kommer att fokusera 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 värdmotorinstallationsprogrammet 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 proceduren för att distribuera oVirt Hosted Engine på skärmen på värden (du kan avsluta den via Ctrl-A + D, stäng med Ctrl-D):

screen
hosted-engine --deploy

Om du vill kan du köra installationen med en förberedd svarsfil:

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

• När vi distribuerar en värdmotor anger vi alla nödvändiga parametrar:

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

• För att installera en högtillgänglig virtuell dator med en värdmotor skapade vi tidigare ett speciellt LUN på lagringssystemet, nummer 4 och 150 GB i storlek, som sedan presenterades för klustervärdarna - se tidigare artikel.

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 driftsättningsprocessen för värdmotorer är inte komplicerad; i slutet bör vi få något i stil med detta:

[ INFO  ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20191129131846.conf'
[ INFO  ] Generating answer file '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ INFO  ] Hosted Engine successfully deployed

Vi kontrollerar närvaron av oVirt-tjänster på värden:

Om allt gjordes korrekt, använd en webbläsare för att gå till efter installationen är klar https://ovirt_hostname/ovirt-engine från administratörens dator och klicka på [Administrationsportal].

Skärmdump av "Administrationsportal"

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

1. lägga till datacenter
2. lägga till och konfigurera ett kluster
3. lägga till och hantera värdar
4. lägga till lagringsområden eller lagringsdomäner för virtuella maskindiskar
5. lägga till och konfigurera nätverk för virtuella maskiner
6. lägga till och hantera virtuella maskiner, installationsbilder, VM-mallar

Alla dessa åtgärder kommer att diskuteras vidare, vissa i stora celler, andra mer detaljerat och med nyanser.
Men först skulle jag rekommendera att läsa detta tillägg, som förmodligen kommer att vara användbart för många.

Dessutom

1) I princip, om det finns ett sådant behov, hindrar ingenting dig från att installera KVM-hypervisorn på klusternoder i förväg med hjälp av paket libvirt и qemu-kvm (eller qemu-kvm-ev) av den önskade versionen, även om den kan göra detta själv när en oVirt-klusternod distribueras.

Men om libvirt и qemu-kvm Om du inte har installerat den senaste versionen kan du få följande felmeddelande när du distribuerar en värdmotor:

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

De där. måste ha uppdaterad version libvirt med skydd från MDS, som stöder denna 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 det finns stöd för 'md-clear':

virsh domcapabilities kvm | grep require
      <feature policy='require' name='ss'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='pku'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='invtsc'/>

Efter detta kan du fortsätta att installera den värdbaserade motorn.

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

Om vi ​​under distributionen av en virtuell dator för värdmotor får följande felmeddelande:

[ 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

Sedan måste du stänga av en annan brandvägg (om den används) och installera och köra 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

Senare, när du installerar ovirt-agenten på en ny värd för klustret, kommer den att konfigurera de nödvändiga portarna i firewalld automatiskt.

3) Starta om en värd med en virtuell dator som körs på den med en värdmotor.

Som vanligt, länk 1 и länk 2 till styrande dokument.

All hantering av den värdbaserade motorns virtuella dator görs ENDAST med hjälp av kommandot värd-motor på värden där den körs, ca Virsh vi måste glömma, liksom det faktum att du kan ansluta till denna virtuella dator via SSH och köra kommandot "avstängning".

Procedur för att sätta en virtuell dator i underhållsläge:

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

hosted-engine --vm-status
!! Cluster is in GLOBAL MAINTENANCE mode !!
--== Host host1.test.local (id: 1) status ==--
conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Host timestamp                     : 1821
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sat Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sat Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Vi startar om värden med den värdbaserade motoragenten och gör vad vi behöver med den.

Efter omstarten kontrollerar du statusen för den virtuella datorn med den värdbaserade motorn:

hosted-engine --vm-status

Om vår virtuella dator med värdmotor inte startar och om vi ser liknande fel i tjänsteloggen:

Fel i serviceloggen:

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Failed to start necessary monitors
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (most recent call last):#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 131, in _run_agent#012    return action(he)#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 55, in action_proper#012    return he.start_monitoring()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 413, in start_monitoring#012    self._initialize_broker()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 537, in _initialize_broker#012    m.get('options', {}))#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - failed to start monitor via ovirt-ha-broker: [Errno 2] No such file or directory, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying to restart agent

Sedan 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 ha startat den virtuella datorn med värdmotor tar vi den ur underhållsläge:

Procedur för att ta bort en virtuell dator från underhållsläge:

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

--== Host host1.test.local (id: 1) status ==--

conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : 6d1eb25f
local_conf_timestamp               : 6222296
Host timestamp                     : 6222296
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (Fri Jan 17 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (Fri Jan 17 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        stopped=False

4) Ta bort den värdbaserade motorn och allt som är associerat med den.

Ibland är det nödvändigt att korrekt ta bort en tidigare installerad värdmotor - länk till vägledningsdokumentet.

Kör bara kommandot på värden:

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

Därefter tar vi bort onödiga paket och säkerhetskopierar några konfigurationer innan detta, om det behövs:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Skapande av ett nytt datacenter

Referensdokumentation - oVirt Administration Guide. Kapitel 4: Datacenter

Låt oss först definiera vad det är datacenter (Jag citerar från hjälpen) är en logisk enhet som definierar en uppsättning resurser som används i en specifik miljö.

Ett datacenter är en slags behållare som består av:

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

Ett datacenter kan inkludera flera kluster som består av flera värdar med virtuella maskiner som körs på dem, och det kan också ha flera lagringsområden kopplade till sig.
Det kan finnas flera datacenter, de fungerar oberoende av varandra. Ovirt har en uppdelning av befogenheter efter roll, och du kan konfigurera behörigheter individuellt, både på datacenternivå och på dess individuella logiska element.

Datacentret, eller datacenter om det finns flera av dem, hanteras från en enda administrativ konsol eller portal.

För att skapa ett datacenter, gå till den administrativa portalen och skapa ett nytt datacenter:
Compute >> Datacentraler >> Nytt

Eftersom vi använder delad lagring på lagringssystemet bör lagringstypen vara delad:

Skärmdump av guiden för att skapa datacenter

När du installerar en virtuell maskin med värdmotor skapas ett datacenter som standard - Datacenter1, och sedan, om det behövs, kan du ändra dess lagringstyp till en annan.

Att skapa ett datacenter är en enkel uppgift, utan några knepiga nyanser, och alla ytterligare åtgärder med det beskrivs i dokumentationen. Det enda jag kommer att notera är att enstaka värdar som bara har lokal lagring (disk) för virtuella datorer inte kommer att kunna komma in i ett datacenter med Storage Type - Shared (de kan inte läggas till där), och för dem måste du skapa ett separat datacenter - d.v.s. Varje enskild värd med lokal lagring behöver ett eget separat datacenter.

Skapar ett nytt kluster

Länk till dokumentation - oVirt Administration Guide. Kapitel 5: Kluster

Utan onödiga detaljer, klunga – detta är en logisk gruppering av värdar som har ett gemensamt lagringsområde (i form av delade diskar på ett lagringssystem, som i vårt fall). Det är också önskvärt att värdarna i klustret är identiska i hårdvara och har samma typ av processor (Intel eller AMD). Det bästa är förstås att servrarna i klustret är helt identiska.

Klustret är en del av ett datacenter (med en specifik typ av lagring - Lokala eller Delade), och alla värdar måste tillhöra något slags kluster, beroende på om de har delad lagring eller inte.

När du installerar en virtuell maskin med en värdmotor på en värd skapas ett datacenter som standard - Datacenter1, tillsammans med klustret – Kluster 1, och i framtiden kan du konfigurera dess parametrar, aktivera ytterligare alternativ, lägga till värdar till den, etc.

Som vanligt, för detaljer om alla klusterinställningar, är det lämpligt att hänvisa till den officiella dokumentationen. Av några av funktionerna för att ställa in ett kluster, lägger jag bara till att när du skapar det räcker det att bara konfigurera de grundläggande parametrarna på fliken Allmänt.

Jag kommer att notera de viktigaste parametrarna:

• Processortyp — väljs utifrån vilka processorer som är installerade på klustervärdarna, vilken tillverkare de kommer från och vilken processor på värdarna som är äldst, så att beroende på detta används alla tillgängliga processorinstruktioner i klustret.
• Brytartyp – Vi använder det bara i vårt kluster Linux bron, det är därför vi valde den.
• Typ av brandvägg – allt är klart här, detta är brandvägg, som måste aktiveras och konfigureras på värdarna.

Skärmdump med klusterparametrar

Installera ytterligare värdar i en Self-Hosted-miljö

Länk för dokumentation.

Ytterligare värdar för en Self-Hosted-miljö läggs till på samma sätt som en vanlig värd, med det ytterligare steget att distribuera en virtuell dator med en värdmotor - Välj driftsättningsåtgärd för värdmotor >> Distribuera. Eftersom den extra värden också måste presenteras med ett LUN för en virtuell dator med en värdmotor, betyder detta att denna värd vid behov kan användas för att vara värd för en virtuell dator med en värdmotor på.
För feltoleransändamål rekommenderas starkt att det finns minst två värdar på vilka en värddator-VM kan placeras.

På den extra värden, inaktivera iptables (om aktiverat), aktivera brandvägg

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installera den nödvändiga KVM-versionen (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

Installera de nödvändiga förråden och det värdbaserade motorinstallationsprogrammet:

yum -y install http://resources.ovirt.org/pub/yum-repo/ovirt-release43.rpm
yum -y install epel-release
yum update
yum install screen ovirt-hosted-engine-setup

Gå sedan till konsolen Öppna Virtualization Manager, lägg till en ny värd och gör allt steg för steg, som skrivet i dokumentation.

Som ett resultat, efter att ha lagt till en extra värd, bör vi få något som bilden i den administrativa konsolen, som i skärmdumpen.

Skärmdump av den administrativa portalen - värdar

Värden på vilken den värddrivna VM:n för närvarande är aktiv har en guldkrona och inskriptionen "Kör Hosted Engine VM", den värd på vilken denna virtuella dator kan startas om det behövs - inskriptionen "Kan köra Hosted Engine VM".

I händelse av ett värdfel där "Kör Hosted Engine VM", startar den automatiskt om på den andra värden. Denna virtuella dator kan också migreras från den aktiva värden till standby-värden för dess underhåll.

Ställa in Power Management / stängsel på oVirt-värdar

Dokumentationslänkar:

• Red Hat Virtualization 4.3 –> Teknisk referens -> Kapitel 4. Energihantering
• oVirt Administration Guide -> Kapitel 7: Värdar

Även om det kan verka som att du är klar med att lägga till och konfigurera en värd, är det inte helt sant.
För normal drift av värdar, och för att identifiera/lösa fel med någon av dem, krävs inställningar för strömhantering/stängsel.

Fäktning, eller fäktning, är processen att tillfälligt utesluta en felaktig eller misslyckad värd från klustret, under vilken antingen oVirt-tjänsterna på den eller själva värden startas om.

All information om definitionerna och parametrarna för Power Management/stängsel ges som vanligt i dokumentationen; Jag kommer bara att ge ett exempel på hur man konfigurerar denna viktiga parameter, som tillämpas på Dell R640-servrar med iDRAC 9.

1. Gå till den administrativa portalen, klicka Compute >> värdar välj en värd.
2. Klick Redigera.
3. Klicka på fliken Power Management.
4. Markera rutan bredvid alternativet Aktivera Power Management.
5. Markera rutan bredvid alternativet Kdump integrationför att förhindra att värden går in i fäktningsläge medan du spelar in en kärnkraschdump.

Observera.

Efter att ha aktiverat Kdump-integrering på en redan körd värd måste den installeras om enligt proceduren i oVirt Administration Guide -> Kapitel 7: Värdar -> Installera om värdar.

1. Alternativt kan du markera rutan Inaktivera policystyrning av energihantering, om vi inte vill att värdens energihantering ska styras av klustrets schemaläggningspolicy.
2. Klicka på knappen (+) för att lägga till en ny energisparenhet öppnas redigeringsfönstret för agentegenskaper.
   För iDRAC9, fyll i fälten:
   • Adress – iDRAC9-adress
   • Användarnamn Lösenord – inloggning och lösenord för att logga in på iDRAC9, respektive
   • Typ — drac5
   • mark Säkra
   • lägg till följande alternativ: cmd_prompt=>,login_timeout=30

Skärmdump med "Power Management"-parametrar i värdegenskaper

Skapa ett lagringsområde eller lagringsdomäner

Länk till dokumentation - oVirt Administration Guide, Kapitel 8: Förvaring.

Lagringsdomän, eller lagringsområde, är en centraliserad plats för lagring av virtuella maskindiskar, installationsbilder, mallar och ögonblicksbilder.

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

oVirt har tre typer av förvaringsutrymmen:

• Datadomän – för att lagra all data som är associerad med virtuella maskiner (diskar, mallar). Datadomän kan inte delas mellan olika datacenter.
• ISO-domän (föråldrad typ av lagringsområde) – för lagring av OS-installationsbilder. ISO Domain kan delas mellan olika datacenter.
• Exportera domän (föråldrad typ av lagringsområde) – för tillfällig lagring av bilder som flyttas mellan datacenter.

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

Från oVirts synvinkel, när du använder lagringssystem (FC eller iSCSI), är varje virtuell disk, ögonblicksbild eller mall en logisk disk.
Blockenheter sätts samman till en enda enhet (på klustervärdar) med volymgrupp och delas sedan upp med LVM i logiska volymer, som används som virtuella diskar för virtuella datorer.

Alla dessa grupper och många LVM-volymer kan ses på klustervärden med hjälp av kommandona vGS и jag mot. Naturligtvis bör alla åtgärder med sådana diskar endast göras från oVirt-konsolen, utom i speciella fall.

Virtuella diskar för virtuella datorer kan vara av två typer - QCOW2 eller RAW. Skivor kan vara "tunn" eller "tjock". Ögonblicksbilder skapas alltid som "tunn".

Sättet att hantera lagringsdomäner, eller lagringsområden som nås via FC, är ganska logiskt - för varje virtuell virtuell disk finns det en separat logisk volym som bara kan skrivas av en värd. För FC-anslutningar använder oVirt något som klustrade LVM.

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

Som vi kan se av beskrivningen betyder ett kluster i oVirt, som ett kluster i VMware vSphere eller Hyper-V, i huvudsak samma sak - det är en logisk gruppering av värdar, helst identiska i hårdvarusammansättning, och som har gemensam lagring för virtuella maskindiskar.

Låt oss fortsätta direkt till att skapa ett lagringsområde för data (VM-diskar), eftersom datacentret inte kommer att initialiseras utan det.
Låt mig påminna dig om att alla LUN som presenteras för klustervärdarna på lagringssystemet måste vara synliga på dem med kommandot "flervägs -ll".

Enligt dokumentation, gå till portalen gå till lagring >> domäner -> Ny domän och följ instruktionerna i avsnittet "Lägga till FCP-lagring".

Efter att ha startat guiden, fyll i de obligatoriska fälten:

• Namn — ställ in klusternamnet
• Domänfunktion -Data
• Lagringstyp — Fiberkanal
• Värd att använda — välj en värd där det LUN vi behöver är tillgängligt

I listan över LUN, markera den vi behöver, klicka Lägg till och sedan ОК. Om det behövs kan du justera ytterligare parametrar för lagringsområdet genom att klicka på Avancerade parametrar.

Skärmdump av guiden för att lägga till "Storage-domän"

Baserat på resultaten av guiden bör vi få ett nytt lagringsområde och vårt datacenter bör flyttas till status UP, eller initierat:

Skärmdumpar av datacentret och lagringsutrymmen i det:

Skapa och konfigurera nätverk för virtuella maskiner

Länk till dokumentation - oVirt Administration Guide, Kapitel 6: Logiska nätverk

Nätverk, eller nätverk, tjänar till att gruppera logiska nätverk som används i oVirts virtuella infrastruktur.

För att kommunicera mellan ett nätverkskort på en virtuell maskin och ett fysiskt kort på värden används logiska gränssnitt av typen . Linux bro.

För att gruppera och dela trafik mellan nätverk konfigureras VLAN på switcharna.

När man skapar ett logiskt nätverk för virtuella maskiner i oVirt måste det tilldelas en identifierare som motsvarar VLAN-numret på switchen så att de virtuella datorerna kan kommunicera med varandra, även om de körs på olika noder i klustret.

Preliminära inställningar av nätverkskort på värdar för att ansluta virtuella maskiner måste göras i tidigare artikel – logiskt gränssnitt konfigurerat bondxnumx, då bör alla nätverksinställningar endast göras via oVirts administrativa portal.

Efter att ha skapat en virtuell dator med värdmotor skapades, förutom det automatiska skapandet av ett datacenter och kluster, ett logiskt nätverk också automatiskt för att hantera vårt kluster - ovritmgmt, som denna virtuella dator var ansluten till.

Om det behövs kan du se de logiska nätverksinställningarna ovritmgmt och justera dem, men du måste vara försiktig så att du inte tappar kontrollen över oVirt-infrastrukturen.

Logiska nätverksinställningar ovritmgmt

För att skapa ett nytt logiskt nätverk för vanliga virtuella datorer, gå till den administrativa portalen nätverks >> Nätverk >> Nytt, och på fliken Allmänt lägg till ett nätverk med önskat VLAN-ID och markera även rutan bredvid "VM nätverk", betyder det att den kan användas för tilldelning till en virtuell dator.

Skärmdump av det nya logiska nätverket VLAN32

I fliken kluster, kopplar vi detta nätverk till vårt kluster Kluster 1.

Efter detta går vi till Compute >> värdar, gå till varje värd i tur och ordning, till fliken Nätverksgränssnitt, och starta guiden Konfigurera värdnätverk, för att binda till värdar för ett nytt logiskt nätverk.

Skärmdump av guiden "Setup host networks".

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

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

cat ifcfg-bond1
# Generated by VDSM version 4.30.17.1
DEVICE=bond1
BONDING_OPTS='mode=1 miimon=100'
MACADDR=00:50:56:82:57:52
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-bond1.432
# Generated by VDSM version 4.30.17.1
DEVICE=bond1.432
VLAN=yes
BRIDGE=ovirtvm-vlan432
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-ovirtvm-vlan432
# Generated by VDSM version 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Låt mig återigen påminna dig om det på klustervärden BEHÖVS INTE skapa nätverksgränssnitt manuellt i förväg ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

Efter att ha lagt till ett logiskt nätverk och kontrollerat anslutningen mellan värden och den värdbaserade motorns virtuella dator kan den användas i den virtuella maskinen.

Skapa en installationsavbildning för att distribuera en virtuell maskin

Länk till dokumentation - oVirt Administration Guide, Kapitel 8: Förvaring, avsnitt Ladda upp bilder till en datalagringsdomän.

Utan en OS-installationsavbildning går det inte att installera en virtuell maskin, även om detta naturligtvis inte är något problem om den till exempel är installerad på nätverket Skomakare med färdiga bilder.

I vårt fall är detta inte möjligt, så du måste importera den här bilden till oVirt själv. Tidigare krävde detta att man skapade en ISO-domän, men i den nya versionen av oVirt har den blivit utfasad, och därför kan man nu ladda upp bilder direkt till Storage-domänen från den administrativa portalen.

I den administrativa portalen gå till lagring >> diskar >> Ladda >> Start
Vi lägger till vår OS-bild som en ISO-fil, fyller i alla fält i formuläret och klickar på knappen "Testanslutning".

Skärmdump av guiden Lägg till installationsbild

Om vi ​​får ett fel så här:

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`

Sedan måste du lägga till oVirt-certifikatet till "Betrodda rotcertifikatutfärdare"(Trusted Root CA) på administratörens kontrollstation, varifrån vi försöker ladda ner bilden.

När du har lagt till certifikatet till Trusted Root CA, klicka igen "Testanslutning", borde få:

Connection to ovirt-imageio-proxy was successful.

När du har slutfört åtgärden att lägga till certifikatet kan du försöka ladda upp ISO-avbildningen till lagringsdomänen igen.

I princip kan du göra en separat lagringsdomän med typen Data för att lagra bilder och mallar separat från VM-diskar, eller till och med lagra dem i en lagringsdomän för den hostade motorn, men detta är efter administratörens gottfinnande.

Skärmdump med ISO-bilder i Storage Domain för värdmotor

Skapa en virtuell maskin

Dokumentationslänk:
oVirt Virtual Machine Management Guide –> Kapitel 2: Installation Linux Virtuella maskiner
Resurser för konsolklienter

Efter att ha laddat installationsbilden med operativsystemet till oVirt kan du fortsätta direkt till att skapa en virtuell maskin. Mycket arbete har gjorts, men vi är redan i slutskedet, för vars skull allt detta startades - att skaffa en feltolerant infrastruktur för att hysa högt tillgängliga virtuella maskiner. Och allt detta är helt gratis - inte ett enda öre spenderades på att köpa några programvarulicenser.

Att skapa en virtuell maskin med CentOS 7, installationsavbildningen med operativsystemet måste laddas.

Vi går till den administrativa portalen, går till Compute >> Virtuella maskiner, och starta guiden för att skapa virtuella datorer. Fyll i alla parametrar och fält och klicka ОК. Allt är väldigt enkelt om du följer dokumentationen.

Som ett exempel kommer jag att ge de grundläggande och ytterligare inställningarna för en mycket tillgänglig virtuell dator, med en skapad disk, ansluten till nätverket och startar från en installationsavbildning:

Skärmdumpar med högt tillgängliga VM-inställningar

När du har avslutat arbetet med guiden, stäng den, starta en ny virtuell dator och installera operativsystemet på den.
För att göra detta, gå till konsolen för denna virtuella dator via den administrativa portalen:

Skärmdump av administrativa portalinställningar för anslutning till VM-konsolen

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

Skärmdump av VM-inställningar, fliken "Konsol".

För att ansluta till VM-konsolen kan du använda t.ex. Virtual Machine Viewer.

För att ansluta till VM-konsolen direkt i webbläsarfönstret bör anslutningsinställningarna via konsolen vara följande:

Efter att ha installerat operativsystemet på den virtuella datorn, är det lämpligt 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 handlingar, kommer den skapade virtuella datorn att vara mycket tillgänglig, d.v.s. om klusternoden som den körs på misslyckas, kommer oVirt automatiskt att starta om den på den andra noden. Denna virtuella dator kan också migreras mellan klustervärdar för deras underhåll eller andra ändamål.

Slutsats

Jag hoppas att den här artikeln lyckats förmedla att oVirt är ett helt normalt verktyg för att hantera virtuell infrastruktur, vilket inte är så svårt att distribuera - huvudsaken är att följa vissa regler och krav som beskrivs både i artikeln och i dokumentationen.

På grund av den stora volymen av artikeln var det inte möjligt att inkludera många saker i den, såsom steg-för-steg exekvering av olika guider med alla detaljerade förklaringar och skärmdumpar, långa slutsatser av vissa kommandon, etc. I själva verket skulle detta kräva att man skrev en hel bok, vilket inte är så vettigt på grund av att nya versioner av mjukvara ständigt dyker upp med innovationer och förändringar. Det viktigaste är att förstå principen för hur allt fungerar tillsammans, och att få en generell algoritm för att skapa en feltolerant plattform för att hantera virtuella maskiner.

Även om vi har skapat en virtuell infrastruktur, behöver vi nu lära den att interagera både mellan dess individuella element: värdar, virtuella maskiner, interna nätverk och med omvärlden.

Denna process är en av huvuduppgifterna för en system- eller nätverksadministratör, som kommer att behandlas i nästa artikel - om användningen av virtuella VyOS-routrar i den feltoleranta infrastrukturen i vårt företag (som du gissat, kommer de att fungera som virtuella maskiner på vårt oVirt-kluster).

Källa: will.com