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:
använder en 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 den enkla implementeringen kommer artikeln att beskriva inställning av nätverk i oVirt för en virtuell dator med en standard Linux-brygga, vilket är standardvalet när du använder KVM-hypervisorn.
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:
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:
Installera oVirt-hanteringsservern
Skapande av ett nytt datacenter
Skapar ett nytt kluster
Installera ytterligare värdar i en Self-Hosted-miljö
Skapa ett lagringsområde eller lagringsdomäner
Skapa och konfigurera nätverk för virtuella maskiner
Skapa en installationsavbildning för att distribuera en virtuell maskin
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?
I början av processen med att distribuera oVirt-hanteringsservern har vi ett dilemma - vi måste installera en hanterings-VM, men i själva verket finns det inget kluster i sig än, och vad kan vi därför komma på i farten? Det stämmer – installera KVM på en framtida klusternod, skapa sedan en virtuell maskin på den, till exempel med CentOS OS och distribuera oVirt-motorn i den. Detta kan vanligtvis göras på grund av fullständig kontroll över en sådan virtuell dator, men detta är en felaktig avsikt, för i det här fallet kommer det i framtiden 100% att finnas problem med en sådan kontroll-VM:
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
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:
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:
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:
lägga till datacenter
lägga till och konfigurera ett kluster
lägga till och hantera värdar
lägga till lagringsområden eller lagringsdomäner för virtuella maskindiskar
lägga till och konfigurera nätverk för virtuella maskiner
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 versionlibvirt 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:
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:
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:
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 >> datacenter >> Nya
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 – i vårt kluster använder vi bara Linux-bryggan, det är därför vi väljer det.
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ö
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
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
Ä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.
Gå till den administrativa portalen, klicka Compute >> värdar välj en värd.
Klick Redigera.
Klicka på fliken Power Management.
Markera rutan bredvid alternativet Aktivera Power Management.
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.
Alternativt kan du markera rutan Inaktivera policystyrning av energihantering, om vi inte vill att värdens energihantering ska styras av klustrets schemaläggningspolicy.
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äkerhet
lägg till följande alternativ: cmd_prompt=>,login_timeout=30
Skärmdump med "Power Management"-parametrar i värdegenskaper
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
Nätverk, eller nätverk, tjänar till att gruppera logiska nätverk som används i oVirts virtuella infrastruktur.
För att interagera mellan nätverksadaptern på den virtuella maskinen och den fysiska adaptern på värden används logiska gränssnitt som Linux-bryggan.
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 >> Nya, 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
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.
För att skapa en virtuell maskin med CentOS 7 måste installationsbilden från operativsystemet laddas ner.
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.
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).