🥇Creazione di un'infrastruttura IT tollerante ai guasti. Parte 2. Installazione e configurazione del cluster oVirt 4.3

Questo articolo è la continuazione del precedente - “Creazione di un'infrastruttura IT tollerante ai guasti. Parte 1: preparazione alla distribuzione di un cluster oVirt 4.3'.

Riguarderà il processo di installazione e configurazione di base di un cluster oVirt 4.3 per ospitare macchine virtuali ad alta disponibilità, tenendo conto del fatto che tutti i passaggi preliminari per la preparazione dell'infrastruttura sono già stati completati in precedenza.

prodromo

Lo scopo principale dell'articolo è fornire istruzioni dettagliate come "Avanti -> Sì -> Fine"come mostrare alcune funzionalità durante l'installazione e la configurazione. Il processo di distribuzione del tuo cluster potrebbe non sempre coincidere con quello in esso descritto, a causa delle caratteristiche dell'infrastruttura e dell'ambiente, ma i principi generali saranno gli stessi.

Da un punto di vista soggettivo, oVirt 4.3 la sua funzionalità è simile a VMware vSphere versione 5.x, ma ovviamente con le proprie caratteristiche di configurazione e funzionamento.

Per chi fosse interessato, tutte le differenze tra RHEV (aka oVirt) e VMware vSphere possono essere trovate ad esempio su Internet qui, ma noterò ancora occasionalmente alcune delle loro differenze o somiglianze tra loro man mano che l'articolo procede.

Separatamente, vorrei confrontare un po 'il lavoro con le reti per macchine virtuali. oVirt implementa un principio simile di gestione della rete per le macchine virtuali (di seguito denominate VM), come in VMware vSphere:

utilizzando un bridge Linux standard (in VMware - Interruttore virtuale standard), in esecuzione su host di virtualizzazione;
utilizzando Open vSwitch (OVS) (in VMware - Switch virtuale distribuito) è uno switch virtuale distribuito costituito da due componenti principali: un server OVN centrale e controller OVN su host gestiti.

Va notato che, data la facilità di implementazione, l'articolo descriverà la configurazione delle reti in oVirt per una VM utilizzando un bridge Linux standard, che è la scelta standard quando si utilizza l'hypervisor KVM.

A questo proposito, esistono diverse regole di base per lavorare con la rete in un cluster, che è meglio non violare:

Tutte le impostazioni di rete sugli host prima di aggiungerli a oVirt devono essere identiche, ad eccezione degli indirizzi IP.
Una volta che un host è stato preso sotto il controllo di oVirt, è altamente sconsigliato modificare manualmente qualcosa nelle impostazioni di rete senza completa fiducia nelle proprie azioni, poiché l'agente oVirt li riporterà semplicemente a quelli precedenti dopo aver riavviato l'host o agente.
L'aggiunta di una nuova rete per una VM, così come l'utilizzo della stessa, deve essere eseguita solo dalla console di gestione oVirt.

uno in più nota importante — per un ambiente molto critico (molto sensibile alle perdite monetarie), sarebbe comunque consigliabile ricorrere al supporto e all'utilizzo a pagamento Red Hat Virtualizzazione 4.3. Durante il funzionamento del cluster oVirt possono verificarsi alcune problematiche per le quali è consigliabile ricevere al più presto un aiuto qualificato, piuttosto che affrontarle autonomamente.

E infine raccomandato Prima di distribuire un cluster oVirt, familiarizza con documentazione ufficiale, in modo da conoscere almeno i concetti e le definizioni di base, altrimenti sarà un po' difficile leggere il resto dell'articolo.

Fondamentali per comprendere l’articolo e i principi di funzionamento del cluster oVirt sono questi documenti guida:

Il volume non è molto grande, in un'ora o due puoi padroneggiare abbastanza i principi di base, ma per chi ama i dettagli, si consiglia di leggere Documentazione del prodotto per Red Hat Virtualization 4.3 — RHEV e oVirt sono essenzialmente la stessa cosa.

Quindi, una volta completate tutte le impostazioni di base su host, switch e sistemi di storage, si procede direttamente all'implementazione di oVirt.

Parte 2. Installazione e configurazione del cluster oVirt 4.3

Per comodità di orientamento elencherò in questo articolo le sezioni principali, che dovranno essere completate una per una:

Installazione del server di gestione oVirt
Creazione di un nuovo data center
Creazione di un nuovo cluster
Installazione di host aggiuntivi in un ambiente self-hosted
Creazione di un'area di archiviazione o domini di archiviazione
Creazione e configurazione di reti per macchine virtuali
Creazione di un'immagine di installazione per la distribuzione di una macchina virtuale
Crea una macchina virtuale

Installazione del server di gestione oVirt

oServer di gestione virtuale è l'elemento più importante dell'infrastruttura oVirt, sotto forma di macchina virtuale, host o dispositivo virtuale che gestisce l'intera infrastruttura oVirt.

I suoi analoghi più stretti nel mondo della virtualizzazione sono:

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

Per installare il server di gestione oVirt, abbiamo due opzioni:

opzione 1
Distribuzione di un server sotto forma di VM o host specializzato.

Questa opzione funziona abbastanza bene, ma a condizione che tale VM operi indipendentemente dal cluster, ad es. non è in esecuzione su alcun host cluster come una normale macchina virtuale che esegue KVM.

Perché una macchina virtuale di questo tipo non può essere distribuita su host cluster?

All'inizio del processo di distribuzione del server di gestione oVirt, abbiamo un dilemma: dobbiamo installare una VM di gestione, ma in realtà non esiste ancora il cluster stesso, e quindi cosa possiamo inventare al volo? Esatto: installa KVM su un futuro nodo del cluster, quindi crea su di esso una macchina virtuale, ad esempio, con il sistema operativo CentOS e distribuisci il motore oVirt al suo interno. Di solito questo può essere fatto per motivi di controllo completo su tale VM, ma questa è un'intenzione sbagliata, perché in questo caso in futuro ci saranno problemi al 100% con tale VM di controllo:

non è possibile migrarlo nella console oVirt tra host (nodi) del cluster;
durante la migrazione utilizzando KVM tramite virsh migrare, questa VM non sarà disponibile per la gestione dalla console oVirt.
Gli host del cluster non possono essere visualizzati in Modalità di manutenzione (modalità di manutenzione), se si esegue la migrazione di questa VM da un host all'altro utilizzando virsh migrare.

Quindi fai tutto secondo le regole: usa un host separato per il server di gestione oVirt o una VM indipendente in esecuzione su di esso, o meglio ancora, fai come scritto nella seconda opzione.

opzione 2
Installazione di oVirt Engine Appliance su un cluster host da esso gestito.

È questa opzione che verrà considerata ulteriormente come più corretta e adatta nel nostro caso.
I requisiti per tale VM sono descritti di seguito; aggiungerò solo che è consigliabile avere almeno due host nell'infrastruttura su cui può essere eseguita la VM di controllo per renderla tollerante ai guasti. Qui vorrei aggiungere che, come ho già scritto nei commenti dell'articolo precedente, non sono mai riuscito ad ottenerlo cervello diviso su un cluster oVirt di due host, con la possibilità di eseguire su di essi macchine virtuali con motore ospitato.

Installazione di oVirt Engine Appliance sul primo host del cluster

Link alla documentazione ufficiale - oGuida al motore self-hosted Virt, capitolo "Distribuzione del motore self-hosted utilizzando la riga di comando»

Il documento specifica i prerequisiti che devono essere soddisfatti prima di distribuire una VM con motore ospitato e descrive anche in dettaglio il processo di installazione stesso, quindi non ha molto senso ripeterlo alla lettera, quindi ci concentreremo su alcuni dettagli importanti.

Prima di iniziare tutte le azioni, assicurati di abilitare il supporto della virtualizzazione nelle impostazioni del BIOS sull'host.
Installa il pacchetto per il programma di installazione del motore ospitato sull'host:

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

Iniziamo la procedura per il deploy di oVirt Hosted Engine nella schermata sull'host (puoi uscire tramite Ctrl-A + D, chiudere tramite Ctrl-D):

screen
hosted-engine --deploy

Se lo desideri, puoi eseguire l'installazione con un file di risposte già preparato:

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

Quando si distribuisce il motore ospitato, specifichiamo tutti i parametri necessari:

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

Per installare una VM ad alta disponibilità con motore ospitato, abbiamo precedentemente creato sul sistema di storage uno speciale LUN, numero 4 e di dimensione 150 GB, che è stato poi presentato agli host del cluster - vedi articolo precedente.

In precedenza ne abbiamo verificato anche la visibilità sugli host:

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

Il processo di distribuzione del motore ospitato in sé non è complicato; alla fine dovremmo ricevere qualcosa di simile a questo:

[ 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

Verifichiamo la presenza dei servizi oVirt sull'host:

Se tutto è stato eseguito correttamente, al termine dell'installazione utilizzare un browser Web per accedere a https://ovirt_hostname/ovirt-engine dal computer dell'amministratore e fare clic su [Portale di amministrazione].

Schermata del "Portale di amministrazione"

Inserendo login e password (impostati durante il processo di installazione) nella finestra come nello screenshot, arriviamo al pannello di controllo di Open Virtualization Manager, nel quale è possibile eseguire tutte le azioni con l'infrastruttura virtuale:

aggiungere data center
aggiungere e configurare un cluster
aggiungere e gestire host
aggiungere aree di archiviazione o domini di archiviazione per i dischi delle macchine virtuali
aggiungere e configurare reti per macchine virtuali
aggiungere e gestire macchine virtuali, immagini di installazione, modelli VM

Tutte queste azioni verranno discusse ulteriormente, alcune in grandi celle, altre in modo più dettagliato e con sfumature.
Ma prima consiglierei di leggere questo componente aggiuntivo, che probabilmente tornerà utile a molti.

Aggiunta

1) In linea di principio, se esiste una tale necessità, nulla impedisce di installare in anticipo l'hypervisor KVM sui nodi del cluster utilizzando i pacchetti libvirt и qemu-kvm (o qemu-kvm-ev) della versione desiderata, anche se quando si distribuisce un nodo del cluster oVirt, può farlo da solo.

Ma se libvirt и qemu-kvm Se non hai installato la versione più recente, potresti ricevere il seguente errore durante la distribuzione di un motore ospitato:

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

Quelli. deve avere versione aggiornata libvirt con protezione da MDS, che sostiene questa politica:

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

Installa libvirt v.4.5.0-10.el7_6.12, con supporto 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

Verifica il supporto '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'/>

Successivamente, puoi continuare a installare il motore ospitato.

2) In oVirt 4.3 è prevista la presenza e l'utilizzo di un firewall firewalld è un requisito obbligatorio.

Se durante la distribuzione di una VM per il motore ospitato riceviamo il seguente errore:

[ 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

Quindi è necessario disattivare un altro firewall (se utilizzato), installarlo ed eseguirlo 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

Successivamente, durante l'installazione dell'agente ovirt su un nuovo host per il cluster, configurerà le porte richieste in firewalld automaticamente.

3) Riavvio di un host su cui è in esecuzione una VM con un motore ospitato.

Normalmente, Collegamento 1 и Collegamento 2 ai documenti disciplinari.

Tutta la gestione della VM del motore ospitato viene eseguita SOLO utilizzando il comando motore ospitato sull'host su cui viene eseguito, circa vergognoso dobbiamo dimenticare, così come il fatto che puoi connetterti a questa VM tramite SSH ed eseguire il comando “chiusura'.

Procedura per mettere una VM in modalità manutenzione:

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

Riavviamo l'host con l'agente del motore ospitato e ne facciamo ciò che ci serve.

Dopo il riavvio, controlla lo stato della VM con il motore ospitato:

hosted-engine --vm-status

Se la nostra VM con motore ospitato non si avvia e se vediamo errori simili nel registro del servizio:

Errore nel registro del servizio:

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

Quindi colleghiamo lo storage e riavviamo l'agente:

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

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

Dopo aver avviato la VM con il motore ospitato, la eliminiamo dalla modalità di manutenzione:

Procedura per rimuovere una VM dalla modalità di manutenzione:

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) Rimozione del motore ospitato e di tutto ciò ad esso associato.

A volte è necessario rimuovere correttamente un motore ospitato precedentemente installato - collegamento al documento guida.

Basta eseguire il comando sull'host:

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

Successivamente, rimuoviamo i pacchetti non necessari, eseguendo prima il backup di alcune configurazioni, se necessario:

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

Creazione di un nuovo data center

Documentazione di riferimento - Guida all'amministrazione di oVirt. Capitolo 4: Data Center

Per prima cosa definiamo di cosa si tratta centro dati (cito dall'help) è un'entità logica che definisce un insieme di risorse utilizzate in un ambiente specifico.

Un data center è una sorta di contenitore composto da:

risorse logiche sotto forma di cluster e host
risorse di rete cluster sotto forma di reti logiche e adattatori fisici su host,
risorse di storage (per dischi VM, template, immagini) sotto forma di aree di storage (Domini di Storage).

Un data center può includere più cluster costituiti da più host su cui sono in esecuzione macchine virtuali e può anche avere più aree di archiviazione ad esso associate.
Possono esserci più data center che funzionano indipendentemente l'uno dall'altro. Ovirt prevede una separazione dei poteri per ruolo ed è possibile configurare i permessi individualmente, sia a livello di data center che sui suoi singoli elementi logici.

Il data center, o i data center se ce ne sono più, sono gestiti da un'unica console o portale amministrativo.

Per creare un data center, vai al portale amministrativo e crea un nuovo data center:
Calcolare >> data Center >> New

Poiché utilizziamo l'archiviazione condivisa sul sistema di archiviazione, il Tipo di archiviazione dovrebbe essere Condiviso:

Screenshot della creazione guidata del data center

Quando si installa una macchina virtuale con motore ospitato, per impostazione predefinita viene creato un data center: Centro dati1e quindi, se necessario, è possibile modificare il Tipo di archiviazione in un altro.

Creare un data center è un compito semplice, senza sfumature complicate, e tutte le azioni aggiuntive con esso sono descritte nella documentazione. L'unica cosa che noterò è che i singoli host che hanno solo spazio di archiviazione locale (disco) per le VM non saranno in grado di entrare in un data center con Tipo di archiviazione - Condiviso (non possono essere aggiunti lì), e per loro è necessario creare un data center separato, ad es. Ogni singolo host con archiviazione locale necessita di un proprio data center separato.

Creazione di un nuovo cluster

Collegamento alla documentazione - Guida all'amministrazione di oVirt. Capitolo 5: Cluster

Senza dettagli inutili, grappolo – si tratta di un raggruppamento logico di host che hanno un'area di storage comune (sotto forma di dischi condivisi su un sistema di storage, come nel nostro caso). È inoltre auspicabile che gli host nel cluster siano identici nell'hardware e abbiano lo stesso tipo di processore (Intel o AMD). Naturalmente è meglio che i server nel cluster siano completamente identici.

Il cluster fa parte di un data center (con un tipo specifico di storage - Locali o diviso) e tutti gli host devono appartenere a un tipo di cluster, a seconda che dispongano o meno di spazio di archiviazione condiviso.

Quando si installa una macchina virtuale con un motore ospitato su un host, per impostazione predefinita viene creato un data center: Centro dati1, insieme al cluster – Grappolo1e in futuro potrai configurarne i parametri, abilitare opzioni aggiuntive, aggiungere host, ecc.

Come di consueto, per i dettagli su tutte le impostazioni del cluster si consiglia di fare riferimento alla documentazione ufficiale. Di alcune delle funzionalità della configurazione di un cluster, aggiungerò solo che durante la creazione è sufficiente configurare solo i parametri di base nella scheda Generale.

Noterò i parametri più importanti:

tipo di processore — viene selezionato in base a quali processori sono installati sugli host del cluster, da quale produttore provengono e quale processore sugli host è il più vecchio, in modo che, a seconda di ciò, vengano utilizzate tutte le istruzioni del processore disponibili nel cluster.
Tipo interruttore – nel nostro cluster utilizziamo solo bridge Linux, ecco perché lo scegliamo.
Tipo di firewall – Qui è tutto chiaro, questo è firewalld, che deve essere abilitato e configurato sugli host.

Screenshot con parametri del cluster

Installazione di host aggiuntivi in un ambiente self-hosted

Collegamento per la documentazione.

Gli host aggiuntivi per un ambiente self-hosted vengono aggiunti allo stesso modo di un host normale, con l'ulteriore passaggio di distribuire una VM con un motore ospitato: Scegli l'azione di distribuzione del motore ospitato >> Schierare. Poiché all'host aggiuntivo deve essere presentato anche un LUN per una VM con un motore ospitato, ciò significa che questo host può, se necessario, essere utilizzato per ospitare una VM con un motore ospitato su di esso.
Ai fini della tolleranza agli errori, è altamente consigliabile che siano presenti almeno due host su cui è possibile posizionare una VM del motore ospitato.

Sull'host aggiuntivo, disabilita iptables (se abilitato), abilita firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installa la versione KVM richiesta (se necessario):

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

Installa i repository necessari e il programma di installazione del motore ospitato:

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

Successivamente, vai alla console Apri Gestore della virtualizzazione, aggiungi un nuovo host e fai tutto passo dopo passo, come scritto in documentazione.

Di conseguenza, dopo aver aggiunto un host aggiuntivo, dovremmo ottenere qualcosa di simile all'immagine nella console di amministrazione, come nello screenshot.

Screenshot del portale amministrativo - host

L'host su cui è attualmente attiva la VM del motore ospitato ha una corona d'oro e la scritta "Esecuzione della VM del motore ospitato", l'host su cui è possibile avviare questa VM, se necessario - la scritta "Può eseguire la VM del motore ospitato'.

In caso di guasto dell'host su cui "Esecuzione della VM del motore ospitato", si riavvierà automaticamente sul secondo host. Questa VM può anche essere migrata dall'host attivo all'host in standby per la sua manutenzione.

Configurazione del risparmio energetico/fencing sugli host oVirt

Collegamenti alla documentazione:

Red Hat Virtualization 4.3 –> Riferimento tecnico -> Capitolo 4. Gestione energetica
oGuida all'amministrazione Virt -> Capitolo 7: Host

Anche se può sembrare che tu abbia finito di aggiungere e configurare un host, non è del tutto vero.
Per il normale funzionamento degli host e per identificare/risolvere i guasti di uno qualsiasi di essi, sono necessarie le impostazioni di gestione dell'alimentazione/fencing.

Scherma, o fencing, è il processo di esclusione temporanea di un host difettoso o guasto dal cluster, durante il quale vengono riavviati i servizi oVirt su di esso o l'host stesso.

Tutti i dettagli sulle definizioni e sui parametri di Power Management/fencing sono riportati, come di consueto, nella documentazione; fornirò solo un esempio di come configurare questo importante parametro, applicato ai server Dell R640 con iDRAC 9.

Vai al portale amministrativo, fai clic su Calcolare >> Host seleziona un ospite.
Clicchiamo Modifica.
Fare clic sulla scheda Power Management.
Seleziona la casella accanto all'opzione Abilita gestione alimentazione.
Seleziona la casella accanto all'opzione Integrazione di Kdumpper impedire all'host di entrare in modalità fencing durante la registrazione di un crash dump del kernel.

Nota.

Dopo aver abilitato l'integrazione di Kdump su un host già in esecuzione, è necessario reinstallarlo secondo la procedura nella Guida all'amministrazione di oVirt -> Capitolo 7: Host -> Reinstallazione degli host.

Facoltativamente, puoi selezionare la casella Disabilita il controllo dei criteri di gestione dell'alimentazione, se non vogliamo che la gestione energetica dell'host sia controllata dalla politica di pianificazione del cluster.
Fare clic sul pulsante (+) per aggiungere un nuovo dispositivo di gestione dell'energia, si aprirà la finestra di modifica delle proprietà dell'agente.
Per iDRAC9, compilare i campi:
- Indirizzo – Indirizzo iDRAC9
- Nome utente/Password – login e password per l'accesso a iDRAC9, rispettivamente
- Tipologia —drac5
- contrassegno Sicuro
- aggiungi le seguenti opzioni: cmd_prompt=>,login_timeout=30

Screenshot con i parametri "Risparmio energia" nelle proprietà dell'host

Creazione di un'area di archiviazione o domini di archiviazione

Link alla documentazione - Guida all'amministrazione di oVirt, Capitolo 8: Archiviazione.

Dominio di archiviazione, o area di archiviazione, è una posizione centralizzata in cui archiviare dischi di macchine virtuali, immagini di installazione, modelli e snapshot.

Le aree di storage possono essere collegate al data center utilizzando vari protocolli, cluster e file system di rete.

oVirt dispone di tre tipologie di aree di stoccaggio:

Dominio dei dati – per archiviare tutti i dati associati alle macchine virtuali (dischi, modelli). Data Domain non può essere condiviso tra diversi data center.
Dominio ISO (tipo obsoleto di area di archiviazione): per archiviare le immagini di installazione del sistema operativo. Il dominio ISO può essere condiviso tra diversi data center.
Esporta dominio (tipo obsoleto di area di archiviazione) – per l'archiviazione temporanea di immagini spostate tra data center.

Nel nostro caso particolare, un'area di storage di tipo Data Domain utilizza Fibre Channel Protocol (FCP) per connettersi ai LUN sul sistema di storage.

Dal punto di vista di oVirt, quando si utilizzano sistemi di storage (FC o iSCSI), ogni disco virtuale, snapshot o modello è un disco logico.
I dispositivi a blocchi vengono assemblati in una singola unità (su host cluster) utilizzando Volume Group e quindi divisi utilizzando LVM in volumi logici, che vengono utilizzati come dischi virtuali per le VM.

Tutti questi gruppi e molti volumi LVM possono essere visualizzati sull'host del cluster utilizzando i comandi eccetera и LVS. Naturalmente tutte le azioni con tali dischi dovrebbero essere eseguite solo dalla console oVirt, tranne in casi speciali.

I dischi virtuali per le macchine virtuali possono essere di due tipi: QCOW2 o RAW. I dischi potrebbero essere "sottile"O"di spessore". Le istantanee vengono sempre create come "sottile".

Il modo di gestire i domini di archiviazione, o le aree di archiviazione a cui si accede tramite FC, è abbastanza logico: per ogni disco virtuale della VM esiste un volume logico separato che è scrivibile da un solo host. Per le connessioni FC, oVirt utilizza qualcosa come LVM in cluster.

Le macchine virtuali situate nella stessa area di storage possono essere migrate tra host appartenenti allo stesso cluster.

Come possiamo vedere dalla descrizione, un cluster in oVirt, come un cluster in VMware vSphere o Hyper-V, significa essenzialmente la stessa cosa: è un raggruppamento logico di host, preferibilmente identici nella composizione hardware, e con spazio di archiviazione comune per virtual dischi della macchina.

Procediamo direttamente alla creazione di un'area di archiviazione per i dati (dischi VM), poiché senza di essa il data center non verrà inizializzato.
Ti ricordo che tutti i LUN presentati agli host del cluster sul sistema di storage devono essere visibili su di essi utilizzando il comando “multipercorso -ll'.

Secondo documentazione, vai al portale vai a Archiviazione >> Domini -> Nuovo dominio e seguire le istruzioni della sezione "Aggiunta di spazio di archiviazione FCP".

Dopo aver avviato la procedura guidata, compilare i campi richiesti:

Nome — imposta il nome del cluster
Funzione di dominio -Dati
Tipo di archiviazione — Canale in fibra ottica
Host da utilizzare — seleziona un host su cui è disponibile il LUN richiesto

Nell'elenco dei LUN, contrassegna quello di cui abbiamo bisogno, fai clic Aggiungi e poi Bene. Se necessario è possibile modificare ulteriori parametri dell'area di memorizzazione facendo clic su Parametri avanzati.

Screenshot della procedura guidata per l'aggiunta del “dominio di archiviazione”

In base ai risultati della procedura guidata, dovremmo ricevere una nuova area di archiviazione e il nostro data center dovrebbe passare allo stato UPo inizializzato:

Schermate del data center e delle aree di archiviazione al suo interno:

Creazione e configurazione di reti per macchine virtuali

Link alla documentazione - Guida all'amministrazione di oVirt, Capitolo 6: Reti logiche

Le Reti, o network, servono a raggruppare le reti logiche utilizzate nell'infrastruttura virtuale oVirt.

Per interagire tra l'adattatore di rete sulla macchina virtuale e l'adattatore fisico sull'host, vengono utilizzate interfacce logiche come il bridge Linux.

Per raggruppare e dividere il traffico tra le reti, sugli switch vengono configurate le VLAN.

Quando si crea una rete logica per macchine virtuali in oVirt, è necessario assegnargli un identificatore corrispondente al numero VLAN sullo switch in modo che le VM possano comunicare tra loro, anche se girano su nodi diversi del cluster.

È stato necessario eseguire le impostazioni preliminari degli adattatori di rete sugli host per la connessione delle macchine virtuali articolo precedente – interfaccia logica configurata bond1, tutte le impostazioni di rete devono essere effettuate solo tramite il portale amministrativo oVirt.

Dopo aver creato una VM con motore ospitato, oltre alla creazione automatica di data center e cluster, è stata creata automaticamente anche una rete logica per gestire il nostro cluster - ovritmgmt, a cui era connessa questa VM.

Se necessario, è possibile visualizzare le impostazioni della rete logica ovritmgmt e modificarli, ma devi fare attenzione a non perdere il controllo dell'infrastruttura oVirt.

Impostazioni di rete logica ovritmgmt

Per creare una nuova rete logica per le VM regolari, nel portale amministrativo andare su Network NetPoulSafe >> Reti >> Newe nella scheda Generale aggiungi una rete con l'ID VLAN desiderato e seleziona anche la casella accanto a "Rete VM", ciò significa che può essere utilizzato per l'assegnazione a una VM.

Screenshot della nuova rete logica VLAN32

linguetta Cluster, colleghiamo questa rete al nostro cluster Grappolo1.

Dopodiché andiamo a Calcolare >> Host, vai a ciascun host a turno, alla scheda Interfacce di retee avviare la procedura guidata Configurare le reti host, per associarsi agli host di una nuova rete logica.

Schermata della procedura guidata "Configurazione reti host".

L'agente oVirt effettuerà automaticamente tutte le impostazioni di rete necessarie sull'host: creerà una VLAN e un BRIDGE.

File di configurazione di esempio per nuove reti sull'host:

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

Permettimi di ricordarti ancora una volta che sull'host del cluster NON NECESSARIO creare manualmente le interfacce di rete in anticipo ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

Dopo aver aggiunto una rete logica e aver verificato la connessione tra l'host e la VM del motore ospitato, è possibile utilizzarla nella macchina virtuale.

Creazione di un'immagine di installazione per la distribuzione di una macchina virtuale

Link alla documentazione - Guida all'amministrazione di oVirt, Capitolo 8: Archiviazione, sezione Caricamento di immagini su un dominio di archiviazione dati.

Senza un'immagine di installazione del sistema operativo non sarà possibile installare una macchina virtuale, anche se ovviamente questo non rappresenta un problema se, ad esempio, è installata in rete Ciabattino con immagini già create.

Nel nostro caso questo non è possibile, quindi dovrai importare tu stesso questa immagine in oVirt. In precedenza questo richiedeva la creazione di un Dominio ISO, ma nella nuova versione di oVirt è stato deprecato e quindi ora è possibile caricare le immagini direttamente nel dominio Storage dal portale amministrativo.

Nel portale amministrativo vai a Archiviazione >> Dischi >> Caricare >> Inizio
Aggiungiamo la nostra immagine del sistema operativo come file ISO, compiliamo tutti i campi del modulo e facciamo clic sul pulsante "Verificare la connessione".

Screenshot dell'Aggiunta guidata immagine di installazione

Se riceviamo un errore come questo:

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`

Quindi è necessario aggiungere il certificato oVirt a “CA radice attendibili"(Trusted Root CA) sulla stazione di controllo dell'amministratore, da dove stiamo tentando di scaricare l'immagine.

Dopo aver aggiunto il certificato alla CA radice attendibile, fare nuovamente clic su "Verificare la connessione", dovrebbe ottenere:

Connection to ovirt-imageio-proxy was successful.

Dopo aver completato l'azione di aggiunta del certificato, puoi provare a caricare nuovamente l'immagine ISO nel dominio di archiviazione.

In linea di principio, puoi creare un dominio di archiviazione separato con il tipo Dati per archiviare immagini e modelli separatamente dai dischi VM o persino archiviarli in un dominio di archiviazione per il motore ospitato, ma ciò è a discrezione dell'amministratore.

Screenshot con immagini ISO nel dominio di archiviazione per il motore ospitato

Crea una macchina virtuale

Collegamento alla documentazione:
oGuida alla gestione della macchina virtuale Virt –> Capitolo 2: Installazione di macchine virtuali Linux
Risorse dei client della console

Dopo aver caricato l'immagine di installazione con il sistema operativo in oVirt, puoi procedere direttamente alla creazione di una macchina virtuale. È stato fatto molto lavoro, ma siamo già nella fase finale, per il bene di cui tutto è stato avviato: ottenere un'infrastruttura tollerante ai guasti per ospitare macchine virtuali ad alta disponibilità. E tutto questo è assolutamente gratuito: non è stato speso un solo centesimo per l'acquisto di licenze software.

Per creare una macchina virtuale con CentOS 7 è necessario scaricare l'immagine di installazione dal sistema operativo.

Andiamo al portale amministrativo, vai a Calcolare >> Macchine Virtualie avviare la procedura guidata di creazione della VM. Compila tutti i parametri e i campi e fai clic Bene. Tutto è molto semplice se si segue la documentazione.

Ad esempio, fornirò le impostazioni di base e aggiuntive di una VM ad alta disponibilità, con un disco creato, connesso alla rete e avvio da un'immagine di installazione:

Schermate con impostazioni della VM a disponibilità elevata

Dopo aver terminato il lavoro con la procedura guidata, chiudila, avvia una nuova VM e installa il sistema operativo su di essa.
Per fare ciò, vai alla console di questa VM attraverso il portale amministrativo:

Screenshot delle impostazioni del portale amministrativo per la connessione alla console della VM

Per connettersi alla console della VM, è necessario prima configurare la console nelle proprietà della macchina virtuale.

Screenshot delle impostazioni della VM, scheda "Console".

Per connetterti alla console VM puoi utilizzare, ad esempio, Visualizzatore di macchine virtuali.

Per connettersi alla console della VM direttamente nella finestra del browser, le impostazioni di connessione tramite la console dovrebbero essere le seguenti:

Dopo aver installato il sistema operativo sulla VM, è consigliabile installare l'agente guest oVirt:

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

Pertanto, come risultato delle nostre azioni, la VM creata sarà altamente disponibile, ovvero se il nodo del cluster su cui è in esecuzione fallisce, oVirt lo riavvierà automaticamente sul secondo nodo. Questa VM può anche essere migrata tra host cluster per la loro manutenzione o altri scopi.

conclusione

Spero che questo articolo sia riuscito a trasmettere che oVirt è uno strumento del tutto normale per la gestione dell'infrastruttura virtuale, che non è così difficile da implementare: l'importante è seguire determinate regole e requisiti descritti sia nell'articolo che nella documentazione.

A causa del grande volume dell'articolo, non è stato possibile includere molte cose al suo interno, come l'esecuzione passo passo di varie procedure guidate con tutte le spiegazioni dettagliate e le schermate, le lunghe conclusioni di alcuni comandi, ecc. In realtà, ciò richiederebbe la scrittura di un intero libro, il che non avrebbe molto senso a causa delle nuove versioni del software che appaiono costantemente con innovazioni e cambiamenti. La cosa più importante è comprendere il principio su cui tutto funziona insieme e ottenere un algoritmo generale per creare una piattaforma tollerante ai guasti per la gestione delle macchine virtuali.

Sebbene abbiamo creato un’infrastruttura virtuale, ora dobbiamo insegnarle a interagire sia tra i suoi singoli elementi: host, macchine virtuali, reti interne, sia con il mondo esterno.

Questo processo è uno dei compiti principali di un amministratore di sistema o di rete, di cui parleremo nel prossimo articolo - sull'uso dei router virtuali VyOS nell'infrastruttura tollerante ai guasti della nostra azienda (come avete intuito, funzioneranno come router virtuali macchine sul nostro cluster oVirt).

Fonte: habr.com

Creazione di un'infrastruttura IT tollerante ai guasti. Parte 2. Installazione e configurazione del cluster oVirt 4.3