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

Questo articolo è una continuazione del precedente — «Creazione di un'infrastruttura IT resiliente. Parte 1 — preparazione per il dispiegamento del cluster oVirt 4.3».

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

Introduzione

L'obiettivo principale dell'articolo non è tanto fornire un'istruzione dettagliata come «Avanti -> Sì -> Fine», quanto mostrare alcune particolarità durante la sua installazione e configurazione. Il processo di dispiegamento del proprio cluster potrebbe non coincidere sempre con quanto descritto, a causa delle peculiarità dell'infrastruttura e dell'ambiente, ma i principi generali rimarranno gli stessi.

Da un punto di vista soggettivo, oVirt 4.3 ha funzionalità simili a VMware vSphere versione 5.x, ma ovviamente con le proprie peculiarità di impostazione e funzionamento.

Per chi fosse interessato, tutte le differenze tra RHEV (aka oVirt) e VMware vSphere possono essere trovate online, ad esempio qui, ma di tanto in tanto sottolineerò alcune differenze o somiglianze tra di loro, nel corso dell'articolo.

Vorrei confrontare brevemente la gestione delle reti per le macchine virtuali. In oVirt è implementato un principio di gestione delle reti simile a quello di VMware vSphere:

• utilizzando un bridge Linux standard (in VMware — Standard vSwitch), operante sui nodi di virtualizzazione;
• utilizzando Open vSwitch (OVS) (in VMware — Distributed vSwitch) — si tratta di uno switch virtuale distribuito, composto da due componenti principali: un server centrale OVN e controller OVN sui nodi gestiti.

Va notato che, per la semplicità di implementazione, nell'articolo verrà descritta la configurazione delle reti in oVirt per le VM utilizzando un bridge Linux standard, che è la scelta consueta quando si utilizza il hypervisor KVM.

A questo proposito ci sono alcune regole base per il lavoro con la rete nel cluster che è meglio non violare:

• Tutte le impostazioni di rete sui nodi devono essere identiche prima di aggiungerli a oVirt, tranne per gli indirizzi IP.
• Dopo che l'host è stato gestito da oVirt, è fortemente sconsigliato apportare modifiche manuali alle impostazioni di rete senza una piena consapevolezza delle proprie azioni, poiché l'agente oVirt revertirà tali modifiche al precedente stato dopo il riavvio dell'host o dell'agente.
• L'aggiunta di una nuova rete per le VM, così come le operazioni ad essa correlate, deve avvenire esclusivamente dalla console di gestione di oVirt.

Un'altra nota importante è che per ambienti particolarmente critici (molto sensibili a perdite economiche), sarebbe comunque consigliabile utilizzare un supporto a pagamento e adottare Red Hat Virtualization 4.3. Durante l'utilizzo del cluster oVirt, potrebbero sorgere alcune situazioni in cui è preferibile ricevere assistenza qualificata il prima possibile, piuttosto che cercare di affrontarle autonomamente.

E infine, si raccomanda prima di implementare il cluster oVirt, di familiarizzare con la documentazione ufficiale, per essere aggiornati almeno sui concetti e le definizioni di base; altrimenti, leggere l'articolo successivo potrebbe risultare un po' difficile.

I documenti fondamentali per comprendere l'articolo e i principi di funzionamento del cluster oVirt sono i seguenti:

• Guida all'installazione di oVirt
• Guida all'Engine auto-ospitato di oVirt
• Guida all'Amministrazione di oVirt
  

Il volume non è molto grande, in un'ora o due è possibile apprendere i principi fondamentali, e per gli appassionati di dettagli si consiglia di leggere Documentazione del Prodotto per Red Hat Virtualization 4.3 — RHEV e oVirt sono fondamentalmente la stessa cosa.

Quindi, se tutte le impostazioni di base su host, switch e storage sono state effettuate, passiamo direttamente al deployment di oVirt.

Parte 2. Installazione e Configurazione del Cluster oVirt 4.3

Per facilitare l'orientamento, elencherò le principali sezioni di questo articolo, che devono essere completate in sequenza:

1. Installazione del server di gestione oVirt
2. Creazione di un nuovo data center
3. Creazione di un nuovo cluster
4. Installazione di host aggiuntivi nell'ambiente Self-Hosted
5. Creazione di aree di storage o Storage Domains
6. Creazione e configurazione delle reti per le macchine virtuali
7. Creazione di un'immagine di installazione per il deployment della macchina virtuale
8. Creazione di una macchina virtuale

Installazione del server di gestione oVirt

Il server di gestione oVirt è l'elemento principale nell'infrastruttura oVirt, sotto forma di macchina virtuale, host o dispositivo virtuale, che gestisce l'intera infrastruttura oVirt.

I suoi vicini più prossimi nel mondo della virtualizzazione sono:

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

Per l'installazione del server di gestione oVirt, abbiamo due opzioni:

Opzione 1
Distribuzione del server come VM specializzata o host.

Questa opzione funziona, ma a condizione che tale VM operi indipendentemente dal cluster, ovvero non sia in esecuzione su alcun host del cluster come una normale macchina virtuale gestita da KVM.

Perché non si può distribuire tale VM sugli host del cluster?

All'inizio del processo di distribuzione del server di gestione oVirt, ci troviamo di fronte a un dilemma: dobbiamo installare la VM di gestione, ma il cluster effettivamente non esiste ancora, quindi cosa possiamo inventare? Corretto – installare KVM sul futuro nodo del cluster, successivamente creare su di esso una macchina virtuale, ad esempio, con sistema operativo CentOS e distribuire al suo interno l'oVirt engine. Questo può essere fatto di solito per avere un pieno controllo su tale VM, ma è un'idea errata, perché in quel caso, in seguito ci saranno sicuramente problemi con tale VM di gestione:

• non sarà possibile migrare nella console oVirt tra gli host (nodi) del cluster;
• durante la migrazione utilizzando KVM tramite virsh migrate, questa VM non sarà accessibile per la gestione dalla console oVirt.
• i nodi del cluster non potranno essere estratti in Modalità manutenzione (maintenance mode), se si migra questa VM da un nodo a un altro utilizzando virsh migrate.

Quindi seguite tutte le regole: utilizzate per il server di gestione oVirt un nodo separato o una VM indipendente in esecuzione su di esso; meglio ancora, seguite quanto scritto nella seconda opzione.

Opzione 2
Installazione di oVirt Engine Appliance sul nodo gestito dallo stesso.

Questa opzione sarà esaminata di seguito come la più corretta e appropriata nel nostro caso.
I requisiti per tale VM sono descritti di seguito; aggiungo solo che si consiglia di avere almeno due nodi nell'infrastruttura, sui quali può essere eseguita la VM di gestione, per garantire la sua resilienza. Vorrei aggiungere che, come già scritto nei commenti nel precedente articolo, non sono riuscito a ottenere splitbrain nel cluster oVirt con due nodi, con la possibilità di eseguire la VM hosted-engine su di essi.

Installazione di oVirt Engine Appliance sul primo nodo del cluster

Link alla documentazione ufficiale — Guida all'Engine auto-ospitato di oVirt, capitolo «Distribuzione del motore auto-ospitato utilizzando la riga di comando»

Il documento elenca i requisiti preliminari che devono essere soddisfatti prima del deployment della VM hosted-engine, e descrive dettagliatamente il processo di installazione, quindi non è particolarmente utile ripeterlo parola per parola; ci concentreremo su alcuni dettagli importanti.

• Prima di cominciare qualsiasi operazione, assicurati di abilitare il supporto per la virtualizzazione nelle impostazioni del BIOS sull'host.
• Installiamo sul server il pacchetto per l'installatore hosted-engine:

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

• Avviamo sul server la procedura di deployment di oVirt Hosted Engine in una sessione screen (puoi uscire con Ctrl-A + D, chiudere con Ctrl-D):

screen
hosted-engine --deploy

Se desideri, puoi avviare l'installazione con un file di risposte pre-preparato:

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

• Durante il deployment di hosted-engine, specifichiamo tutti i parametri necessari:

- nome del cluster
- numero di vCPU e vRAM (consigliati 4 vCPU e 16 Gb)
- password
- tipo di storage per la VM con hosted engine – nel nostro caso FC
- numero LUN per l'installazione dell'hosted engine
- dove si troverà il database per l'hosted engine – per semplicità consiglio di scegliere Local (è un database PostgreSQL che opera all'interno di questa VM)
e altri parametri. 

• Per l'installazione di una VM altamente disponibile con hosted engine, su SAN è stato precedentemente creato un LUN speciale con numero 4 e dimensione di 150 Gb, che è stato poi presentato agli host del cluster – vedi in articolo precedente.

In precedenza abbiamo anche verificato la sua 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 deploy dell'hosted-engine non presenta particolari difficoltà, alla fine dovremmo ricevere un messaggio simile:

[ 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 fatto correttamente, dopo aver completato l'installazione, accediamo tramite un browser web a https://ovirt_hostname/ovirt-engine dal computer dell'amministratore e facciamo clic su [Administration Portal].

Screenshot dell'«Administration Portal»

Inserendo il nome utente e la password (impostati durante l'installazione) nella finestra come nello screenshot, accediamo al pannello di controllo di Open Virtualization Manager, dove possiamo eseguire tutte le operazioni con l'infrastruttura virtuale:

1. aggiungere il data center
2. aggiungere e configurare un cluster
3. aggiungere host e gestirli
4. aggiungere aree di archiviazione o Storage Domains, per i dischi delle macchine virtuali
5. aggiungere e configurare reti per le macchine virtuali
6. aggiungere macchine virtuali, immagini di installazione, modelli di VM e gestirli

Tutte queste operazioni saranno trattate successivamente, alcune in modo ampio, altre più dettagliatamente e con sfumature.
Ma prima consiglio di leggere questo supplemento, che potrebbe risultare utile a molti.

Supplemento

1) In linea di principio, se c'è questa necessità, non c'è nulla che impedisca di installare in anticipo l'hypervisor KVM sui nodi del cluster, utilizzando i pacchetti libvirt e qemu-kvm (o qemu-kvm-ev) della versione desiderata, anche se durante il deployment del nodo del cluster oVirt, può farlo autonomamente.

Ma se libvirt e qemu-kvm è stata installata una versione non aggiornata, si può ricevere un errore durante il deployment dell' hosted engine:

error: configurazione non supportata: caratteristica CPU sconosciuta: md-clear

Cioè, è necessario avere una versione aggiornata libvirt con protezione da MDS, che supporta tale politica:

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

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

Controlliamo la disponibilità del supporto per 'md-clear':

virsh domcapabilities kvm | grep require

Dopo questo, si può continuare con l'installazione dell' hosted engine.

2) In oVirt 4.3 la presenza e l'uso del firewall firewalld è un requisito obbligatorio.

Se durante il deployment della VM per hosted-engine otteniamo il seguente errore:

[ ERROR ] fatal: [localhost]: FALLITO! => {"changed": false, "msg": "firewalld deve essere abilitato e attivo per eseguire correttamente il deployment dell'hosted-engine. Si prega di controllare, correggere di conseguenza e ripetere il deployment.n"}
[ ERROR ] Impossibile eseguire la fase 'Chiusura': Impossibile eseguire ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

È necessario disattivare un altro firewall (se in uso) e installare e avviare firewalld:

yum install firewalld
systemctl enable firewalld
systemctl start firewalld

firewall-cmd --state
firewall-cmd --get-default-zone
firewall-cmd --get-active-zones
firewall-cmd --get-zones

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

3) Riavvio dell'host con la VM in esecuzione che utilizza hosted engine.

Come al solito, link 1 e link 2 alla documentazione.

Tutta la gestione della VM hosted engine deve essere effettuata SOLO tramite il comando hosted-engine sull'host dove è in esecuzione, riguardo virsh si deve dimenticare, così come il fatto che ci si può connettere a questa VM tramite SSH e eseguire il comando «shutdown».

Procedura per mettere la VM in modalità di manutenzione:

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

hosted-engine --vm-status
!! Il cluster è in modalità MANUTENZIONE GLOBALE !!
--== Stato host host1.test.local (id: 1) ==--
conf_on_shared_storage             : True
Stato aggiornato                   : True
Nome host                          : host1.test.local
ID Host                            : 1
Stato motore                       : {"health": "good", "vm": "up", "detail": "Up"}
Punteggio                          : 3400
interrotto                         : False
Manutenzione locale                : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Timestamp host                     : 1821
Metadati extra (validi al timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sab Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sab Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Stiamo riavviando l'host con l'agent hosted engine e facciamo ciò che ci serve.

Dopo il riavvio, verifichiamo lo stato della VM con hosted engine:

hosted-engine --vm-status

Se la nostra VM con hosted-engine non si avvia e se vediamo errori simili nel registro del servizio:

Errore nel registro del servizio:

journalctl -u ovirt-ha-agent
...
29 giu 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERRORE Impossibile avviare i monitor necessari
29 giu 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERRORE Traccia (chiamata più recente per ultima):#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", riga 131, in _run_agent#012    return action(he)#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", riga 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", riga 413, in start_monitoring#012    self._initialize_broker()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", riga 537, in _initialize_broker#012    m.get('options', {}))#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", riga 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - impossibile avviare il monitor tramite ovirt-ha-broker: [Errno 2] Nessun file o directory, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
29 giu 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERRORE Tentativo di riavvio dell'agente

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 l'avvio della VM con hosted-engine, la portiamo fuori dalla modalità di manutenzione:

Procedura per rimuovere la 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 hosted e tutto ciò che lo riguarda.

A volte è necessario rimuovere correttamente un motore hosted precedentemente installato — link consultando il 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 eventuali 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

Iniziamo definendo cosa si intende per data center (citiamo dalla documentazione) — è un'entità logica che definisce un insieme di risorse utilizzate in un ambiente specifico.

Il data center è una sorta di contenitore composto da:

• risorse logiche sotto forma di cluster e host
• risorse di rete del cluster sotto forma di reti logiche e adattatori fisici sugli host,
• risorse di archiviazione (per dischi VM, modelli, immagini) sotto forma di aree di archiviazione (Storage Domains).

Un data center può includere più cluster, ciascuno composto da diversi host con macchine virtuali che operano su di essi, e può avere anche più aree di archiviazione ad esso associate.
Possono esserci più data center che operano indipendentemente l'uno dall'altro. In oVirt c'è una divisione dei poteri basata sui ruoli e le autorizzazioni possono essere configurate in modo personalizzato, sia a livello di data center che per i suoi singoli elementi logici.

Il data center, o i data center se ci sono più di uno, sono gestiti da un'unica console amministrativa o portale.

Per creare un data center, accedi al portale di gestione e crea un nuovo data center:
Compute >> Data Centers >> Nuovo

Poiché utilizziamo uno storage condiviso su SAN, il tipo di archiviazione (Storage Type) deve essere Shared:

Screenshot con il wizard di creazione del data center

Durante l'installazione di una macchina virtuale con hosted-engine, viene creato di default un data center – Datacenter1, e successivamente, se necessario, è possibile cambiare il tipo di archiviazione (Storage Type) con un altro.

La creazione di un data center è un compito semplice, senza particolari complicazioni, e tutte le operazioni aggiuntive sono descritte nella documentazione. Va notato, però, che i singoli host con solo archiviazione locale (disco) per VM non possono essere aggiunti al data center con Storage Type – Shared; è necessario creare un data center separato per ciascun host con archiviazione locale.

Creazione di un nuovo cluster

Collegamento alla documentazione – oVirt Administration Guide. Capitolo 5: Cluster

Senza eccessivi dettagli, un cluster è un raggruppamento logico di host che condividono un'area di archiviazione (sotto forma di dischi condivisi su SAN, come nel nostro caso). È anche auspicabile che gli host nel cluster siano omogenei dal punto di vista hardware e abbiano lo stesso tipo di processore (Intel o AMD). È meglio che i server del cluster siano completamente identici.

Il cluster fa parte del data center (con un determinato tipo di archiviazione — Locale o Condiviso), e tutti gli host devono necessariamente appartenere a un cluster, a seconda che abbiano o meno uno storage comune.

Durante l'installazione di una macchina virtuale con hosted-engine su un host, viene creato automaticamente un data center — Datacenter1, insieme al cluster – Cluster1, e in seguito è possibile configurare le sue impostazioni, abilitare opzioni aggiuntive, aggiungere host, ecc.

Come al solito, per dettagli su tutte le impostazioni del cluster, è consigliabile fare riferimento alla documentazione ufficiale. Tra le caratteristiche particolari della configurazione del cluster, vorrei solo aggiungere che durante la sua creazione è sufficiente configurare solo i parametri principali nella scheda Generale.

Voglio sottolineare i parametri più importanti:

• Tipo di processore — viene scelto in base ai processori installati sugli host del cluster, da quale produttore provengono, e quale processore è il più antico sugli host, in modo da utilizzare tutte le istruzioni per i processori disponibili nel cluster.
• Tipo di switch – nel nostro cluster utilizziamo solo il bridge Linux, quindi lo selezioniamo.
• Tipo di firewall – qui è tutto chiaro, si tratta di firewalld, che deve essere abilitato e configurato sugli host.

Screenshot delle impostazioni del cluster

Installazione di host aggiuntivi in un ambiente Self-Hosted

Collegamento alla documentazione.

Gli host aggiuntivi per l'ambiente Self-Hosted vengono aggiunti come un normale host, seguendo un ulteriore passaggio per il deployment della VM con il hosted engine — Scegli l'azione di deployment del hosted engine >> Deploy. Poiché anche l'host aggiuntivo deve essere presentato con un LUN per la VM con il hosted engine, significa che questo host può essere utilizzato, se necessario, per ospitare la VM con il hosted engine.
Per garantire l'affidabilità, è altamente raccomandato avere almeno due host su cui può essere ospitata la VM con il hosted engine.

Sul host aggiuntivo, disabilitiamo iptables (se attivo) e abilitiamo firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installa la versione richiesta di KVM (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

Impostiamo i repository richiesti e l'installer del hosted engine:

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

Successivamente, passiamo alla console Open Virtualization Manager, aggiungiamo un nuovo host e procediamo passo passo come descritto in documentazione.

Di conseguenza, dopo aver aggiunto un host aggiuntivo, dovremmo visualizzare un’immagine nella console di amministrazione simile allo screenshot.

Screenshot del portale di amministrazione — host

L'host su cui la VM con hosted-engine è attualmente attiva ha una corona dorata e la scritta «Running the Hosted Engine VM», l'host su cui questa VM può essere avviata, se necessario, ha la scritta «Can run the Hosted Engine VM».

In caso di guasto dell'host su cui «Running the Hosted Engine VM», essa verrà automaticamente riavviata sul secondo host. Inoltre, questa VM può essere migrata dall'host attivo a quello di riserva per la sua manutenzione.

Configurazione della gestione dell'alimentazione / fencing sugli host oVirt

Link alla documentazione:

• Red Hat Virtualization 4.3 –> Riferimento tecnico -> Capitolo 4. Gestione dell'alimentazione
• Guida all'amministrazione di oVirt -> Capitolo 7: Host

Sebbene possa sembrare che l'aggiunta e la configurazione dell'host siano completate, non è esattamente così.
Per un funzionamento normale degli host e per l'identificazione/riparazione dei guasti, è necessaria la configurazione della gestione dell'alimentazione / fencing.

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

Tutti i dettagli sulle definizioni e i parametri della gestione dell'alimentazione / fencing sono solitamente forniti nella documentazione; qui fornirò un esempio di come configurare questo importante parametro per i server Dell R640 con iDRAC 9.

1. Accediamo al portale di amministrazione e facciamo clic su Compute >> Hosts selezioniamo l'host.
2. Fai clic su Modifica.
3. Fai clic sulla scheda Gestione dell'alimentazione.
4. Seleziona la casella accanto all'opzione Abilita la gestione dell'alimentazione.
5. Seleziona la casella accanto all'opzione Integrazione di Kdump, in modo che l'host non entri in modalità fencing durante la registrazione del dump di emergenza del kernel.

Nota.

Dopo aver abilitato l'integrazione Kdump su un host già attivo, deve essere reinstallato secondo la procedura nel oVirt Administration Guide -> Capitolo 7: Host -> Reinstallazione degli Host.

1. Facoltativamente, è possibile selezionare la casella Disabilita il controllo della politica di gestione dell'alimentazione, se non si desidera che la gestione dell'alimentazione dell'host sia controllata dalla politica di pianificazione (Scheduling Policy) del cluster.
2. Fai clic sul pulsante (+), per aggiungere un nuovo dispositivo di gestione dell'alimentazione; si aprirà una finestra di modifica delle proprietà dell'agente.
   Per iDRAC9, compila i campi:
   • Indirizzo – indirizzo iDRAC9
   • Nome utente / Password – rispettivamente il login e la password per accedere a iDRAC9
   • Tipo — drac5
   • selezionare Sicuro
   • aggiungere le seguenti opzioni: cmd_prompt=>,login_timeout=30

Screenshot delle impostazioni di «Power Management» nelle proprietà dell'host

Creazione di aree di storage o Storage Domains

Collegamento alla documentazione — oVirt Administration Guide, Capitolo 8: Storage.

Storage Domain, o dominio di memorizzazione – è un luogo centralizzato per memorizzare dischi di macchine virtuali, immagini di installazione, modelli e snapshot.

Le aree di memorizzazione possono connettersi al data center utilizzando vari protocolli, sistemi di file cluster e di rete.

oVirt ha tre tipi di aree di memorizzazione:

• Data Domain – per memorizzare tutti i dati relativi alle macchine virtuali (dischi, modelli). Il Data Domain non può essere condiviso tra diversi data center.
• ISO Domain (tipo obsoleto di area di memorizzazione) – per memorizzare immagini di installazione del sistema operativo. L'ISO Domain può essere condiviso tra diversi data center.
• Export Domain (tipo obsoleto di area di memorizzazione) – per la memorizzazione temporanea di immagini spostate tra data center.

Nel nostro caso particolare, l'area di memorizzazione di tipo Data Domain utilizza il protocollo Fibre Channel (FCP) per connettersi ai LUN su SAN.

Dal punto di vista di oVirt, quando si utilizza uno storage (FC o iSCSI), ogni disco virtuale, snapshot o template è un disco logico.
I dispositivi di blocco sono uniti in un insieme (sui nodi del cluster) tramite il Volume Group e poi suddivisi in volumi logici tramite LVM, utilizzati come dischi virtuali per le VM.

Tutti questi gruppi e molti volumi LVM possono essere visualizzati sul nodo del cluster con i comandi vgs e lvs. Naturalmente, tutte le operazioni con tali dischi devono essere eseguite solo dalla console di oVirt, salvo casi particolari.

I dischi virtuali per le VM possono essere di due tipi: QCOW2 o RAW. I dischi possono essere "sottili" o "spessi". Gli snapshot vengono sempre creati come "sottili.".

Il modo di gestire i domini di storage, o le aree di archiviazione, accessibili tramite FC, è piuttosto logico: per ogni disco virtuale di una VM esiste un volume logico separato, accessibile in scrittura solo da un nodo. Nel caso di connessioni tramite FC, oVirt utilizza qualcosa di simile a LVM clusterizzato.

Le macchine virtuali situate in una stessa area di archiviazione possono essere migrate tra nodi appartenenti allo stesso cluster.

Come possiamo vedere dalla descrizione, un cluster in oVirt, proprio come un cluster in VMware vSphere o in Hyper-V, rappresenta essenzialmente la stessa cosa: è un raggruppamento logico di host, preferibilmente identici nella configurazione hardware, che condividono uno storage comune per i dischi delle macchine virtuali.

Passiamo direttamente alla creazione dell'area di archiviazione per i dati (dischi VM), poiché senza di essa il data center non sarà inizializzato.
Ricordo che tutte le LUN presentate agli host del cluster devono essere visibili tramite il comando “multipath -ll».

Secondo documentazione, andiamo al portale e accediamo a Storage >> Domains -> New Domain e seguiamo le istruzioni nella sezione "Aggiunta di FCP Storage".

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

• Name — diamo un nome al cluster
• Domain Function — Data
• Storage Type — Fibre Channel
• Host to Use — scegliamo l'host su cui è disponibile il LUN richiesto

Nell'elenco delle LUN, selezioniamo quella necessaria e clicchiamo su Add e poi OK. Se necessario, è possibile modificare i parametri aggiuntivi dell'area di archiviazione, facendo clic su Advanced Parameters.

Screenshot della procedura guidata per l'aggiunta di "Storage domain"

A seguito dell'operato della procedura guidata, dovremmo ottenere una nuova area di archiviazione, e il nostro data center dovrebbe passare allo stato UP, o inizializzato:

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

Creazione e configurazione delle reti per le macchine virtuali

Collegamento alla documentazione — oVirt Administration Guide, Capitolo 6: Reti Logiche

Le reti, o Networks, servono per raggruppare le reti logiche utilizzate nell'infrastruttura virtuale oVirt.

Per consentire l'interazione tra l'adattatore di rete nella macchina virtuale e l'adattatore fisico sull'host, si utilizzano interfacce logiche di tipo Linux bridge.

Per raggruppare e separare il traffico tra le reti, sono configurati VLAN sugli switch.

Quando si crea una rete logica per le macchine virtuali in oVirt, è necessario assegnarle un identificatore che corrisponde al numero VLAN sullo switch, affinché le VM possano interagire tra loro, anche se operano su nodi diversi del cluster.

Le configurazioni iniziali degli adattatori di rete sugli host per il collegamento delle macchine virtuali devono essere state completate in articolo precedente – interfaccia logica configurata bond1, tutte le ulteriori configurazioni di rete devono essere effettuate solo tramite il portale amministrativo di oVirt.

Dopo la creazione della VM con hosted-engine, oltre alla creazione automatica del data center e del cluster, è stata creata anche una rete logica per gestire il nostro cluster – ovritmgmt, a cui è stata collegata questa VM.

Se necessario, puoi visualizzare le impostazioni della rete logica ovritmgmt e modificarle, ma fai attenzione a non perdere il controllo dell'infrastruttura oVirt.

Impostazioni della rete logica ovritmgmt

Per creare una nuova rete logica per le VM normali, nel portale amministrativo vai su Network log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check >> Reti >> Nuovo, e nella scheda Generale aggiungi una rete con l'identificativo VLAN desiderato e seleziona la casella accanto a «Rete VM», ciò significa che può essere utilizzata per l'assegnazione alle VM.

Screenshot della nuova rete logica VLAN32

Nella scheda Cluster, collega questa rete al nostro cluster. Cluster1.

Dopo di che, accediamo a Compute >> Hosts, entrando in ogni host, nella scheda Interfacce di rete, e avviamo la procedura guidata Imposta reti host, per collegare la nuova rete logica agli host.

Screenshot della procedura guidata «Imposta reti host»

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

Esempio di file di configurazione per le nuove reti sull'host:

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

Ricordo ancora che non è necessario creare manualmente interfacce di rete sul nodo del cluster NON È NECESSARIO creare manualmente le interfacce di rete ifcfg-bond1.432 e ifcfg-ovirtvm-vlan432.

Dopo aver aggiunto la rete logica e verificato la connessione tra il nodo e la VM con hosted engine, questa può essere utilizzata nella macchina virtuale.

Creazione di un'immagine di installazione per il deployment della macchina virtuale

Collegamento alla documentazione — oVirt Administration Guide, Capitolo 8: Storage, sezione Caricamento delle immagini in un dominio di archiviazione dei dati.

Senza l'immagine di installazione del sistema operativo, non sarà possibile installare la macchina virtuale, anche se questo non rappresenta un problema, se nella rete è installato, ad esempio, Cobbler con immagini create in precedenza.

Nel nostro caso non abbiamo questa possibilità, quindi dovremo importare manualmente quest'immagine in oVirt. In precedenza, era necessario creare un ISO Domain per questo, ma nella nuova versione di oVirt è stato considerato obsoleto e ora possiamo caricare le immagini direttamente nel dominio di archiviazione dal portale amministrativo.

Nel portale amministrativo, andiamo su Storage >> Dischi >> Carica >> Inizia
Aggiungiamo la nostra immagine del sistema operativo in formato ISO, compiliamo tutti i campi nel modulo e facciamo clic sul pulsante "Testa connessione".

Screenshot della procedura guidata per l'aggiunta dell'immagine di installazione

Se otteniamo un errore di questo tipo:

Impossibile caricare l'immagine sul disco d6d8fd10-c1e0-4f2d-af15-90f8e636dadc a causa di un errore di rete. Assicurati che il servizio ovirt-imageio-proxy sia installato e configurato e che il certificato CA di ovirt-engine sia registrato come CA fidata nel browser. Il certificato può essere recuperato da https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA`

È necessario aggiungere il certificato oVirt in «Autorità di certificazione radice fidate» (Trusted Root CA) sulla workstation di amministrazione da cui stiamo cercando di caricare l'immagine.

Dopo aver aggiunto il certificato in Trusted Root CA, facciamo nuovamente clic su "Testa connessione", dovremmo ricevere:

La connessione a ovirt-imageio-proxy è stata effettuata con successo.

Una volta completata l'operazione di aggiunta del certificato, possiamo provare di nuovo a caricare l'immagine ISO nel Domain di Storage.

In linea di principio, è possibile creare un Domain di Storage separato di tipo Data, per memorizzare immagini e modelli separati dai dischi VM, o addirittura memorizzarli nel Domain di Storage per l'engine ospitato, ma questo è a discrezione dell'amministratore.

Screenshot delle immagini ISO nel Domain di Storage per l'engine ospitato

Creazione di una macchina virtuale

Collegamento alla documentazione:
Guida alla gestione delle macchine virtuali oVirt –> Capitolo 2: Installazione di macchine virtuali Linux
Risorse dei client della console

Dopo aver caricato l'immagine ISO del sistema operativo in oVirt, puoi procedere direttamente alla creazione della macchina virtuale. Abbiamo già completato molto lavoro e siamo ormai nella fase finale, con l'obiettivo di realizzare un'infrastruttura resistente per l'hosting di macchine virtuali ad alta disponibilità. Inoltre, tutto questo è completamente gratuito: non è stata spesa una sola lira per l'acquisto di licenze software.

Per creare una macchina virtuale con CentOS 7, è necessario caricare l'immagine ISO del sistema operativo.

Accediamo al portale di amministrazione, andiamo su Compute >> Macchine Virtuali, e avviamo la procedura guidata per la creazione della VM. Compiliamo tutti i parametri e i campi, e clicchiamo su OK. È tutto molto semplice se segui la documentazione.

Come esempio, presenterò le impostazioni principali e aggiuntive per una VM ad alta disponibilità, con disco creato, connessa alla rete e avviata dall'immagine ISO:

Screenshot delle impostazioni della VM ad alta disponibilità

Dopo aver terminato le operazioni con la procedura guidata, la chiudiamo, avviamo una nuova VM e installiamo il sistema operativo su di essa.
Per fare ciò, accediamo alla console di questa VM tramite il portale di amministrazione:

Screenshot delle impostazioni del pannello di amministrazione 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 connettersi alla console della VM è possibile utilizzare, ad esempio, Virtual Machine Viewer.

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

Dopo aver installato il sistema operativo sulla VM, è consigliabile installare l'agent guest di 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

Così, a seguito delle nostre azioni, la VM creata sarà altamente disponibile, cioè, in caso di guasto del nodo del cluster su cui è in esecuzione, oVirt la riavvierà automaticamente sul secondo nodo. Inoltre, questa VM può essere migrata tra gli host del cluster per la manutenzione o per altri scopi.

Conclusione

Spero che questo articolo sia riuscito a comunicare che oVirt è uno strumento valido per la gestione di infrastrutture virtuali, la cui installazione non è così complicata — l'importante è seguire alcune regole e requisiti descritti sia nell'articolo che nella documentazione.

A causa dell'ampiezza dell'articolo, non è stato possibile includere molte cose, come le istruzioni passo-passo per vari assistenti con spiegazioni dettagliate e schermate, o le lunghe uscite di alcuni comandi, e così via. In realtà, ci vorrebbe un intero libro per farlo, il che non avrebbe molto senso, considerando le costanti nuove versioni del software con innovazioni e cambiamenti. La cosa più importante è capire il principio di come tutto funzioni insieme e avere un algoritmo generale per creare una piattaforma affidabile per la gestione di macchine virtuali.

Anche se abbiamo creato l'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 è una delle principali responsabilità di un amministratore di sistema o di rete, che sarà approfondita nel prossimo articolo — sull'uso dei router virtuali VyOS in un'infrastruttura resiliente della nostra azienda (come avrete intuito, funzioneranno come macchine virtuali nel nostro cluster oVirt).

Fonte: habr.com