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

Questo articolo è un seguito del precedente – «Creazione di un'infrastruttura IT a prova di guasti. Parte 1 - preparazione al dispiegamento del cluster oVirt 4.3».

In esso verrà esaminato il processo di installazione di base e configurazione 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 già stati eseguiti in precedenza.

Introduzione

L'obiettivo principale dell'articolo è non tanto fornire un'istruzione passo-passo del tipo «Next -> Sì -> Fine», quanto mostrare alcune peculiarità durante la sua installazione e configurazione. Il processo di implementazione del tuo cluster potrebbe non sempre corrispondere a quanto descritto, a causa delle peculiarità dell'infrastruttura e dell'ambiente, ma i principi generali saranno gli stessi.

Da un punto di vista soggettivo, oVirt 4.3 per funzionalità è simile a VMware vSphere versione 5.x, ma ovviamente con le sue peculiarità di configurazione e funzionamento.

Per chi fosse interessato, tutte le differenze tra RHEV (alias oVirt) e VMware vSphere possono essere trovate in Internet, ad esempio qui, ma comunque a volte annoterò alcune differenze o similarità tra di loro nel corso dell'articolo.

Inoltre, vorrei confrontare brevemente la gestione delle reti per macchine virtuali. In oVirt è implementato un principio simile di gestione delle reti per macchine virtuali (di seguito VM), come in VMware vSphere:

• utilizzando il bridge Linux standard (in VMware — Standard vSwitch), che opera sui nodi di virtualizzazione;
• utilizzando Open vSwitch (OVS) (in VMware — Distributed vSwitch) – è uno switch virtuale distribuito, costituito da due componenti principali: un server centrale OVN e controller OVN sugli host gestiti.

Vale la pena notare che, a causa della semplicità di implementazione, nell'articolo verrà descritta la configurazione delle reti in oVirt per VM utilizzando il bridge Linux standard, che è la scelta standard quando si utilizza il hypervisor KVM.

A questo proposito, ci sono alcune regole di base per la gestione della rete nel 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.
• Dopo che un host è stato preso sotto la gestione di oVirt, è estremamente sconsigliato modificare manualmente le impostazioni di rete, senza una piena sicurezza nelle proprie azioni, poiché l'agente oVirt le ripristinerà alle precedenti dopo il riavvio dell'host o dell'agente.
• L'aggiunta di una nuova rete per le VM, così come l'interazione con essa, deve avvenire solo tramite la console di gestione di oVirt.

Un'altra nota importante — per ambienti altamente critici (molto sensibili alle perdite finanziarie), si raccomanderebbe comunque di utilizzare supporto a pagamento e impiegare Red Hat Virtualization 4.3. Durante l'operatività del cluster oVirt, potrebbero sorgere alcune situazioni per le quali è preferibile ricevere assistenza qualificata il prima possibile, piuttosto che affrontarle autonomamente.

E infine, si raccomanda Prima di distribuire il cluster oVirt, è consigliabile consultare la documentazione ufficiale, per essere aggiornati almeno sui concetti e definizioni di base, altrimenti sarà un po' difficile leggere ulteriormente l'articolo.

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

• Guida all'installazione di oVirt
• Guida all'Engine Autoinstallato di oVirt
• Guida all'amministrazione di oVirt
  

Il volume non è molto grande, in un'ora o due è possibile assimilare i principi fondamentali, e per gli amanti dei dettagli è consigliato leggere Documentazione del Prodotto per Red Hat Virtualization 4.3 — RHEV e oVirt sono di fatto la stessa cosa.

Quindi, se tutte le impostazioni di base su host, switch e storage SAN sono state eseguite, passiamo direttamente alla distribuzione 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 eseguite 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 in un ambiente Self-Hosted
5. Creazione di aree di storage o Storage Domains
6. Creazione e configurazione di reti per macchine virtuali
7. Creazione di un'immagine di installazione per la distribuzione di una 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, in forma di macchina virtuale, host o dispositivo virtuale, che gestisce l'intera infrastruttura di oVirt.

I suoi analoghi 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 del server come VM specializzata o host.

Questa opzione funziona perfettamente, a condizione che la VM funzioni indipendentemente dal cluster, ossia non sia avviata su alcun host del cluster come una normale macchina virtuale sotto 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: la VM di gestione deve essere installata, ma il cluster non esiste ancora effettivamente, quindi cosa si può inventare all'improvviso? Giusto: installare KVM sul futuro nodo del cluster, quindi creare una macchina virtuale, ad esempio, con il sistema operativo CentOS e distribuire il motore oVirt all'interno di essa. Questo può essere fatto normalmente per avere il pieno controllo su tale VM, ma è un'intenzione errata, poiché in questo caso, in seguito ci saranno sicuramente problemi con tale VM di gestione:

• non si potrà migrare nella console oVirt tra gli host (nodi) del cluster;
• durante la migrazione tramite KVM usando virsh migrate, questa VM non sarà gestibile dalla console oVirt.
• Non sarà possibile mettere in modalità di Maintenance mode (modalità manutenzione), se si migra questa VM da un host a un altro usando virsh migrate.

Quindi, seguite tutte le regole: usate per il server di gestione oVirt o un host separato, o una VM indipendente avviata su di esso, o meglio ancora seguite quanto scritto nella seconda opzione.

Opzione 2
Installazione di oVirt Engine Appliance sull'host gestito dallo stesso.

Questo è l'unico opzione che sarà trattata in seguito, in quanto più corretta e adatta nel nostro caso.
I requisiti per tale VM sono descritti di seguito, aggiungo solo che si consiglia di avere almeno due host nell'infrastruttura, sui quali può essere avviata la VM di gestione, al fine di renderla tollerante ai guasti. Qui vorrei aggiungere che, come ho già scritto nei commenti nell'articolo precedente, non sono riuscito a ottenere splitbrain nel cluster oVirt con due host, con la possibilità di avviare la VM hosted-engine su di essi.

Installazione di oVirt Engine Appliance sul primo host del cluster

Collegamento alla documentazione ufficiale — Guida all'Engine Autoinstallato di oVirt, capitolo “Deploying the Self-Hosted Engine Using the Command line»

Il documento specifica le condizioni preliminari che devono essere soddisfatte prima della distribuzione della VM hosted-engine, oltre a descrivere in dettaglio il processo di installazione, quindi non ha molto senso ripeterlo alla lettera, pertanto ci concentreremo su alcuni dettagli importanti.

• Prima di iniziare tutte le operazioni, attiviamo il supporto alla virtualizzazione nelle impostazioni del BIOS sull'host.
• Instaliamo sul host il pacchetto per l'installer del 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 host la procedura di distribuzione di oVirt Hosted Engine in una screen (uscire da essa è possibile tramite Ctrl-A + D, chiuderla tramite Ctrl-D):

screen
hosted-engine --deploy

Se lo si desidera, è possibile avviare l'installazione con un file di risposte preparato in anticipo:

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

• Durante la distribuzione dell'hosted-engine, specificare tutti i parametri necessari:

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

• Per installare una VM ad alta disponibilità con l'hosted engine, abbiamo precedentemente creato un LUN speciale di numero 4 e dimensione 150 GB, che è stato poi presentato agli host del cluster – vedere 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 distribuzione dell'hosted-engine non presenta nulla di complicato, alla fine dovremmo ricevere un messaggio 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

Controlliamo la presenza dei servizi oVirt sull'host:

Se tutto è stato fatto correttamente, al termine dell'installazione accediamo tramite il browser web a https://ovirt_hostname/ovirt-engine dal computer dell'amministratore, e clicchiamo [Pannello di Amministrazione].

Screenshot "Pannello di Amministrazione"

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 il cluster
3. aggiungere host e gestirli
4. aggiungere aree di storage o Storage Domains, per i dischi delle macchine virtuali
5. aggiungere e configurare reti per macchine virtuali
6. aggiungere macchine virtuali, immagini di installazione, modelli di VM e gestirli

Tutte queste azioni saranno trattate in seguito, alcune in modo più dettagliato, altre con maggiore precisione.
Ma prima consiglierei di leggere questo supplemento, che sicuramente sarà utile a molti.

Estensione

1) In linea di principio, se c'è questa necessità, non c’è nulla che ostacoli 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, sebbene durante il dispiegamento di un nodo del cluster oVirt, possa farlo autonomamente.

Ma se libvirt e qemu-kvm sono stati installati non nell'ultima versione, si può ricevere un errore durante il dispiegamento dell'engine hostato:

errore: 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 presenza del supporto 'md-clear':

virsh domcapabilities kvm | grep require

Dopo di ciò, si può continuare con l'installazione dell'engine hostato.

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

Se durante il dispiegamento della VM per l'hosted-engine si riceve un errore del genere:

[ ERROR ] fatale: [localhost]: FALLITO! => {"changed": false, "msg": "firewalld deve essere abilitato e attivo per poter dispiegare correttamente l’hosted-engine. Controlla, correggi di conseguenza e ripeti il dispiegamento.
"}
[ ERROR ] Impossibile eseguire la fase 'Chiusura': Impossibile eseguire ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

È necessario quindi disattivare un altro firewall (se utilizzato) 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à automaticamente le porte richieste. firewalld automaticamente.

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

Come al solito, link 1 e link 2 ai documenti guida.

Tutta la gestione del motore hosted VM avviene SOLO tramite il comando hosted-engine sull'host in cui opera, riguardo a virsh devi dimenticarlo, così come il fatto che puoi collegarti a questa VM tramite SSH ed eseguire il comando «shutdown».

Procedura per portare la VM in modalità di manutenzione:

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

hosted-engine --vm-status
!! Il Cluster è in modalità di MANUTENZIONE GLOBALE !!
--== Stato dell'host host1.test.local (id: 1) ==--
conf_on_shared_storage             : True
Stato aggiornato                     : True
Nome host                            : host1.test.local
ID host                             : 1
Stato del motore                     : {"health": "good", "vm": "up", "detail": "Up"}
Punteggio                             : 3400
fermo                               : False
Manutenzione locale                  : False
crc32                               : dee1a774
timestamp_conf_locale               : 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

Riavviamo l'host con l'agente hosted engine e facciamo quello che ci serve.

Dopo il riavvio, controlliamo 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 log del servizio:

Errore nel log 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 ERROR Impossibile avviare i monitor necessari
29 giu 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traccia (call più recente in 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 di questo tipo, [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 ERROR Tentativo di riavviare l'agente

Colleghiamo quindi 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 portare la VM fuori dalla modalità di manutenzione:

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

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

conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "In funzione"}
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 (Ven Jan 17 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (Ven Jan 17 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        stopped=False

4) Rimozione dell'hosted engine e di tutto ciò che è ad essa collegato.

A volte è necessario rimuovere correttamente un hosted engine precedentemente installato — link nel documento guida.

Basta eseguire il comando sull'host:

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

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

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Creazione di un nuovo data center

Documentazione di riferimento — oVirt Administration Guide. Capitolo 4: Data Centers

Innanzitutto definiamo cos'è un data center (citando dalla documentazione) — è 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 del cluster sotto forma di reti logiche e adattatori fisici sugli host,
• risorse di storage (per dischi VM, modelli, immagini) sotto forma di aree di storage (Storage Domains).

Un data center può includere diversi cluster, composti da più host con macchine virtuali in esecuzione su di essi, e può avere più aree di storage associate.
Possono esserci più data center, che operano in modo indipendente l'uno dall'altro. In ovirt c'è una separazione dei privilegi basata sui ruoli e si possono configurare permessi personalizzati, sia a livello di data center che per i suoi singoli elementi logici.

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

Per creare un data center, accediamo al portale amministrativo e creiamo un nuovo data center:
Calcolo >> Data Center >> Nuovo

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

Screenshot con il wizard di creazione del data center

Quando si installa una macchina virtuale con hosted-engine, viene creato automaticamente un data center - Datacenter1, e successivamente, se necessario, è possibile cambiare il tipo di archiviazione (Storage Type) in un altro.

La creazione del data center è un compito semplice, senza alcuna complicazione particolare, e tutte le azioni aggiuntive sono descritte nella documentazione. L'unica cosa che vorrei menzionare è che gli host singoli con solo archiviazione locale (disco) per VM non potranno entrare in un data center con Storage Type - Shared (non sarà possibile aggiungerli lì), quindi è necessario creare un data center separato per loro: ogni singolo host con archiviazione locale avrà bisogno del proprio data center separato.

Creazione di un nuovo cluster

Link alla documentazione - oVirt Administration Guide. Capitolo 5: Cluster

Senza troppi dettagli, cluster – è un raggruppamento logico di host condividendo un'area di archiviazione (sotto forma di dischi condivisi su SAN, come nel nostro caso). È inoltre desiderabile che gli host nel cluster siano identici come hardware e abbiano lo stesso tipo di processore (Intel o AMD). È migliore se i server nel cluster sono completamente identici.

Un cluster fa parte di un data center (con un determinato tipo di archiviazione - Local o Condiviso), e tutti gli host devono appartenere a un cluster, a seconda che abbiano o meno un'archiviazione comune.

Quando si installa una macchina virtuale con hosted-engine su un host, viene creato automaticamente un data center - Datacenter1, insieme a un cluster - Cluster1, e successivamente è possibile configurare le sue impostazioni, abilitare opzioni aggiuntive, aggiungervi host, ecc.

Come sempre, per ottenere dettagli su tutte le impostazioni del cluster, è consigliabile consultare la documentazione ufficiale. Tra le particolarità delle impostazioni del cluster, aggiungo solo che durante la sua creazione è sufficiente configurare solo le impostazioni principali nella scheda Generale.

Sottolineerò le impostazioni più importanti:

• Tipo di processore – viene scelto in base ai processori installati sugli host del cluster, dal quale produttore provengono e qual è il processore più vecchio negli host, in modo da utilizzare tutte le istruzioni del processore disponibili nel cluster.
• Tipo di switch – nel nostro cluster si utilizza solo Linux bridge, quindi scegliamo quello.
• Tipo di firewall – qui è tutto chiaro, è firewalld, che deve essere abilitato e configurato sugli host.

Screenshot con le impostazioni del cluster

Installazione di host aggiuntivi nell'ambiente Self-Hosted

Link alla documentazione.

Gli host aggiuntivi per l'ambiente Self-Hosted vengono aggiunti allo stesso modo degli host normali, seguendo un ulteriore passaggio per il deployment della VM con hosted engine — Scegliere l'azione di deployment dell'engine ospitato >> Deploy. Poiché anche all'host aggiuntivo deve essere presentato un LUN per la VM con hosted engine, significa che questo host può essere utilizzato, se necessario, per l'hosting di una VM con hosted engine.
Per motivi di tolleranza ai guasti, è altamente consigliato avere almeno due host su cui possa essere eseguita una VM con hosted engine.

Su un host aggiuntivo disabilitiamo iptables (se attivi), attiviamo firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installiamo 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

Installiamo i repository necessari e l'installer dell'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

Poi passiamo alla console Open Virtualization Manager, aggiungiamo un nuovo host e procediamo passo dopo passo come indicato in documentazione.

Di conseguenza, dopo aver aggiunto l'host aggiuntivo, dovremmo vedere un'immagine simile nella console di amministrazione, come nello 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 «Esecuzione della VM Hosted Engine», l'host su cui questa VM può essere avviata se necessario – la scritta «Può eseguire la VM Hosted Engine».

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

Configurazione della gestione dell'alimentazione / fencing sugli host di 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 è proprio così.
Per il corretto funzionamento degli host e per identificare / risolvere guasti su uno di essi, è necessaria la configurazione della gestione dell'alimentazione / fencing.

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

Tutti i dettagli sulle definizioni e i parametri della gestione dell'alimentazione / fencing sono forniti, come al solito, nella documentazione; presenterò solo un esempio di come configurare questo importante parametro, applicandolo ai server Dell R640 con iDRAC 9.

1. Accediamo al portale di amministrazione, clicchiamo su Calcolo >> Hosts selezioniamo l'host.
2. Clicchiamo su Edit.
3. Clicchiamo sulla scheda Power Management.
4. Selezioniamo la casella accanto all'opzione Enable Power Management.
5. Selezioniamo la casella accanto all'opzione Integrazione Kdump, affinché l'host non entri in modalità fencing durante la registrazione di un dump di emergenza del kernel.

Nota.

Dopo aver attivato l'integrazione Kdump su un host già funzionante, deve essere reinstallato seguendo la procedura nella oVirt Administration Guide -> Capitolo 7: Host -> Reinstalling Hosts.

1. Facoltativamente, possiamo selezionare la casella Disable policy control of power management, se non vogliamo che la gestione dell'alimentazione dell'host sia controllata dalla politica di pianificazione del cluster.
2. Clicchiamo sul pulsante (+), per aggiungere un nuovo dispositivo di gestione dell'alimentazione, si aprirà la finestra di modifica delle proprietà dell'agente.
   Per iDRAC9, compiliamo i campi:
   • Address – indirizzo iDRAC9
   • User Name / Password – rispettivamente nome utente e password per accedere a iDRAC9
   • Type — drac5
   • segnalare Sicuro
   • aggiungere le seguenti opzioni: cmd_prompt=>, login_timeout=30

Screenshot con i parametri 'Power Management' nelle proprietà dell'host

Creazione di aree di storage o Storage Domains

Link alla documentazione - oVirt Administration Guide, Capitolo 8: Storage.

Storage Domain, o dominio di archiviazione – è un luogo centralizzato per l'archiviazione dei dischi delle macchine virtuali, delle immagini di installazione, dei modelli e degli snapshot.

I domini di archiviazione possono connettersi al data center utilizzando vari protocolli, sistemi di file cluster e di rete.

oVirt ha tre tipi di dominio di archiviazione:

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

Nel nostro caso specifico, il dominio di archiviazione di tipo Data Domain utilizza il Fibre Channel Protocol (FCP) per connettersi ai LUN su SAN.

Dal punto di vista di oVirt, quando si utilizza un sistema di archiviazione (FC o iSCSI), ogni disco virtuale, snapshot o modello è un disco logico.
Le unità a blocchi vengono aggregate in un'unica entità (sugli host del cluster) tramite il Volume Group e poi suddivise in volumi logici utilizzati come dischi virtuali per le VM.

Tutti questi gruppi e molteplici volumi LVM possono essere visualizzati sull'host del cluster tramite i comandi vgs e lvs. È ovvio che tutte le operazioni con questi dischi devono essere eseguite esclusivamente dalla console di oVirt, ad eccezione di particolari casi.

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 metodo di gestione dei domini di archiviazione, o aree di storage, a cui si accede tramite FC, è piuttosto logico: per ogni disco virtuale di una VM esiste un volume logico separato, che è accessibile in scrittura solo a un host. In caso di collegamenti tramite FC, oVirt utilizza qualcosa di simile a un LVM clusterizzato.

Le macchine virtuali situate su un'area di storage possono essere migrate tra host appartenenti allo stesso cluster.

Come possiamo vedere dalla descrizione, un cluster in oVirt, così come un cluster in VMware vSphere o in Hyper-V, indica essenzialmente la stessa cosa: è un raggruppamento logico di host, preferibilmente omogenei sotto il profilo hardware, e dotati di uno storage condiviso per i dischi delle macchine virtuali.

Procediamo direttamente alla creazione di un'area di storage per i dati (dischi delle VM), poiché senza di essa il data center non verrà inizializzato.
Ricordo che tutti i LUN presentati agli host del cluster devono essere visibili su di essi tramite il comando “multipath -ll».

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

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

• Name — diamo un nome al cluster
• Funzione del Dominio — Dati
• Tipo di Archiviazione — Fibre Channel
• Host da Utilizzare — selezioniamo l'host su cui è disponibile il LUN richiesto

Nell'elenco dei LUN selezioniamo quello desiderato, clicchiamo Aggiungi e poi OK. Se necessario, è possibile modificare ulteriori parametri dell'area di storage cliccando su Parametri Avanzati.

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

A seguito del lavoro svolto dalla procedura guidata, dovremmo ottenere una nuova area di storage, e il nostro data center passare allo stato UP, o inizializzato:

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

Creazione e configurazione di reti per macchine virtuali

Link 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 l'interazione dell'adattatore di rete sulla macchina virtuale con l'adattatore fisico sull'host, vengono utilizzate interfacce logiche di tipo Linux bridge.

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

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

Le configurazioni preliminari degli adattatori di rete sugli host per collegare le macchine virtuali devono essere state eseguite in articolo precedente – interfaccia logica configurata bond1, successivamente tutte le configurazioni di rete devono essere effettuate esclusivamente attraverso il portale amministrativo di oVirt.

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

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

Impostazioni della rete logica ovritmgmt

Per creare una nuova rete logica per le VM comuni, nel portale amministrativo andiamo su Network global 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 aggiungiamo una rete con l'identificatore VLAN desiderato, e spuntiamo la casella accanto a "VM Network", questo significa che può essere utilizzato per l'assegnazione alle VM.

Screenshot della nuova rete logica VLAN32

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

Dopo di che andiamo in Calcolo >> Hosts, entrando uno ad uno in ogni host, nella scheda Interfacce di rete, e avviamo la guida Configurazione reti host, per legare la nuova rete logica agli host.

Screenshot della guida "Configurazione reti host"

L'agente oVirt eseguirà automaticamente tutte le configurazioni 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

Vorrei ricordare ancora che sull'host del cluster NON È NECESSARIO creare manualmente in anticipo interfacce di rete ifcfg-bond1.432 e ifcfg-ovirtvm-vlan432.

Dopo aver aggiunto la rete logica e verificato la connessione tra l'host e la VM con hosted engine, può essere utilizzata nella macchina virtuale.

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

Link alla documentazione - oVirt Administration Guide, Capitolo 8: Storage, sezione Caricamento immagini in un dominio di archiviazione dati.

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

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

Nel portale amministrativo andiamo a Storage >> Dischi >> Upload >> Avvia
Aggiungiamo la nostra immagine del sistema operativo come file ISO, compilando tutti i campi nel modulo e cliccando sul pulsante "Testa connessione".

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

Se riceviamo un errore di questo tipo:

Impossibile caricare l'immagine nel 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 attendibile 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 nel «CA radice attendibili» (Trusted Root CA) sulla stazione di amministrazione da cui si sta tentando di caricare l'immagine.

Dopo aver aggiunto il certificato nel Trusted Root CA, facciamo di nuovo clic su "Testa connessione", dovremmo ricevere:

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

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

In linea di principio, è possibile creare un dominio di archiviazione separato di tipo Dati, per conservare le immagini e i modelli separati dai dischi delle VM, o addirittura conservarli nel dominio di archiviazione per hosted engine, ma questo è a discrezione dell'amministratore.

Screenshot con le immagini ISO nel dominio di archiviazione per hosted engine

Creazione di una macchina virtuale

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

Dopo aver caricato l'immagine di installazione del sistema operativo in oVirt, è possibile passare direttamente alla creazione della macchina virtuale. Molto lavoro è stato fatto, ma siamo già nella fase finale, per la quale è stato tutto organizzato: ottenere un'infrastruttura ad alta disponibilità per l'hosting di macchine virtuali altamente disponibili. E tutto questo è assolutamente gratuito: non è stata spesa nemmeno una lira per acquistare licenze software.

Per creare una macchina virtuale con CentOS 7, deve essere stato caricato l'immagine di installazione del sistema operativo.

Accediamo al portale amministrativo, andiamo su Calcolo >> Macchine Virtuali, e avviamo la procedura guidata per la creazione della VM. Compiliamo tutti i parametri e i campi, e facciamo clic su OK. È tutto molto semplice, se si segue la documentazione.

Come esempio, fornirò le impostazioni principali e aggiuntive per una VM ad alta disponibilità, con disco creato, connessa alla rete e con avvio dall'immagine di installazione:

Screenshot delle impostazioni della VM ad alta disponibilità

Dopo aver completato il lavoro con la procedura guidata, chiudiamola, avviamo la nuova VM e installiamo il sistema operativo su di essa.
Per farlo, accediamo alla console di questa VM tramite il portale amministrativo:

Screenshot delle impostazioni del portale amministrativo per connettersi alla console della VM

Per collegarsi 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, si può usare, 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'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

In questo modo, a seguito delle nostre azioni, la VM creata sarà ad alta disponibilità, 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 loro manutenzione o per altri scopi.

Conclusione

Spero che questo articolo sia riuscito a trasmettere che oVirt è uno strumento del tutto valido per la gestione di un'infrastruttura virtuale, che non è difficile da implementare: l'importante è seguire correttamente le regole e i requisiti descritti sia nell'articolo che nella documentazione.

A causa dell'elevato volume dell'articolo, non è stato possibile includere molte cose, come esecuzioni dettagliate di vari processi con tutte le spiegazioni e gli screenshot, lunghe uscite di alcuni comandi, ecc. In realtà, ci vorrebbe un intero libro per farlo, il che non ha molto senso, considerando le nuove versioni del software con innovazioni e cambiamenti che emergono continuamente. La cosa più importante è comprendere il principio di come tutto funzioni insieme e ottenere un algoritmo generale per creare una piattaforma resiliente per la gestione delle 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 è uno dei compiti principali dell'amministratore di sistema o di rete, che sarà esaminato nel prossimo articolo — sull'utilizzo dei router virtuali VyOS nell'infrastruttura resiliente della nostra azienda (come avrete intuito, funzioneranno come macchine virtuali nel nostro cluster oVirt).

Fonte: habr.com