Création d'une infrastructure informatique résiliente. Partie 2. Installation et configuration d'un cluster oVirt 4.3

Cet article est une suite de l'article précédent – «Création d'une infrastructure informatique résiliente. Partie 1 — préparation au déploiement du cluster oVirt 4.3».

Il abordera le processus d'installation et de configuration de base du cluster oVirt 4.3, pour l'hébergement de machines virtuelles hautement disponibles, en tenant compte que toutes les étapes préliminaires de préparation de l'infrastructure ont déjà été effectuées.

Introduction

L'objectif principal de cet article n'est pas tant de fournir un guide étape par étape tel que «Suivant -> Oui -> Terminer», mais de montrer certaines caractéristiques de son installation et de sa configuration. Le processus de déploiement de votre cluster peut ne pas toujours correspondre à celui décrit ici, en raison des spécificités de l'infrastructure et de l'environnement, mais les principes généraux resteront les mêmes.

D'un point de vue subjectif, oVirt 4.3 est fonctionnellement semblable à VMware vSphere version 5.x, mais bien sûr avec ses propres particularités de configuration et de fonctionnement.

Pour ceux qui s'intéressent, toutes les différences entre RHEV (alias oVirt) et VMware vSphere peuvent être trouvées sur Internet, par exemple ici, mais je vais néanmoins parfois signaler certaines de leurs différences ou similarités au cours de l'article.

Je voudrais également comparer un peu le travail avec les réseaux pour les machines virtuelles. oVirt adopte un principe de gestion des réseaux pour les machines virtuelles (ci-après VMs) similaire à celui de VMware vSphere :

• à l'aide d'un bridge Linux standard (dans VMware — Standard vSwitch), fonctionnant sur des hôtes de virtualisation ;
• à l'aide d'Open vSwitch (OVS) (dans VMware — Distributed vSwitch) – c'est un commutateur virtuel distribué constitué de deux composants principaux : le serveur central OVN et les contrôleurs OVN sur les hôtes gérés.

Il est à noter qu'en raison de la simplicité de mise en œuvre, l'article décrira la configuration des réseaux dans oVirt pour les VMs à l'aide d'un bridge Linux standard, qui est le choix par défaut lors de l'utilisation de l'hyperviseur KVM.

En raison de cela, il existe quelques règles de base concernant le travail avec le réseau dans le cluster, qu'il vaut mieux ne pas enfreindre :

• Toutes les configurations réseau sur les hôtes avant leur ajout à oVirt doivent être identiques, sauf pour les adresses IP.
• Une fois qu'un hôte est sous la gestion d'oVirt, il est fortement déconseillé de modifier manuellement les paramètres réseau, sans une pleine confiance dans ses actions, car l'agent oVirt les rétablira à leurs valeurs précédentes après le redémarrage de l'hôte ou de l'agent.
• L'ajout d'un nouveau réseau pour les VM, ainsi que son utilisation, doit se faire exclusivement depuis la console de gestion d'oVirt.

Une autre remarque importante — pour un environnement très critique (très sensible aux pertes financières), il est tout de même recommandé d'utiliser un support payant et de se servir de Red Hat Virtualization 4.3. En exploitant le cluster oVirt, il peut survenir certains cas où il est préférable d'obtenir rapidement une aide qualifiée, plutôt que de tenter de résoudre les problèmes soi-même.

Et enfin, il est recommandé avant de déployer le cluster oVirt, il est conseillé de consulter la documentation officielle, afin d'être au courant au moins des concepts et définitions de base, autrement, il sera un peu difficile de lire l'article par la suite.

Les documents fondamentaux pour comprendre l'article et le fonctionnement du cluster oVirt sont les suivants :

• Guide d'installation d'oVirt
• Guide de moteur auto-hébergé d'oVirt
• Guide d'administration d'oVirt
  

Le volume n'est pas très élevé, en une à deux heures, on peut aisément maîtriser les principes de base, et pour les amateurs de détails, il est recommandé de lire Documentation produit pour Red Hat Virtualization 4.3 — RHEV et oVirt sont en fait une seule et même chose.

Ainsi, si toutes les configurations de base sur les hôtes, les commutateurs et le stockage SAN ont été effectuées, nous passons à l'étape de déploiement d'oVirt.

Partie 2. Installation et configuration du cluster oVirt 4.3

Pour faciliter l'orientation, je vais énumérer les principales sections de cet article, qui doivent être effectuées successivement :

1. Installation du serveur de gestion oVirt
2. Création d'un nouveau centre de données
3. Création d'un nouveau cluster
4. Installation d'hôtes supplémentaires dans l'environnement auto-hébergé
5. Création d'une zone de stockage ou de domaines de stockage
6. Création et configuration de réseaux pour les machines virtuelles
7. Création d'une image d'installation pour déployer une machine virtuelle
8. Création d'une machine virtuelle

Installation du serveur de gestion oVirt

Le serveur de gestion oVirt – est l'élément principal de l'infrastructure oVirt, sous la forme d'une machine virtuelle, d'un hôte ou d'un dispositif virtuel, gérant toute l'infrastructure oVirt.

Ses homologues proches dans le monde de la virtualisation :

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

Pour l'installation du serveur de gestion oVirt, nous avons deux options :

Option 1
Déploiement du serveur sous forme de VM spécialisée ou d'hôte.

Cette option fonctionne, mais à condition que cette VM fonctionne indépendamment du cluster, c'est-à-dire qu'elle ne soit pas lancée sur un hôte du cluster en tant que machine virtuelle classique sous KVM.

Pourquoi ne peut-on pas déployer une telle VM sur les hôtes du cluster ?

Au tout début du processus de déploiement du serveur de contrôle oVirt, nous avons un dilemme : il faut installer la VM de contrôle, mais le cluster n'existe en fait pas encore. Que peut-on alors imaginer rapidement ? Correct : installer KVM sur le futur nœud du cluster, puis créer une machine virtuelle, par exemple avec CentOS, et y déployer l'engin oVirt. Cela peut être fait généralement en raison du contrôle total sur cette VM, mais c'est une intention erronée, car dans ce cas, il y aura 100 % de problèmes avec cette VM de contrôle par la suite :

• elle ne pourra pas être migrée dans la console oVirt entre les hôtes (nœuds) du cluster;
• lors de la migration à l'aide de KVM via virsh migrate, cette VM sera inaccessibile à la gestion depuis la console oVirt.
• les hôtes du cluster ne pourront pas être mis en mode Maintenance mode si cette VM est migrée d'un hôte à l'autre à l'aide de virsh migrate.

Il est donc essentiel de suivre les règles — utilisez pour le serveur de contrôle oVirt soit un hôte distinct, soit une VM indépendante lancée dessus, ou mieux encore, suivez ce qui est écrit dans la deuxième option.

Option 2
Installation de l'Appliance oVirt Engine sur l'hôte qu'elle gère.

C'est exactement cette option qui sera examinée plus en détail comme étant plus correcte et adaptée dans notre cas.
Les exigences pour cette VM sont décrites ci-dessous, je voudrais juste ajouter qu'il est recommandé d'avoir au moins deux hôtes dans l'infrastructure, sur lesquels la VM de contrôle peut être lancée, afin de la rendre tolérante aux pannes. À ce sujet, je voudrais ajouter que, comme je l'ai déjà mentionné dans les commentaires de l'article précédent, je n'ai pas réussi à obtenir splitbrain sur le cluster oVirt de deux hôtes, avec la possibilité de lancer la VM hosted-engine dessus.

Installation de l'Appliance oVirt Engine sur le premier hôte du cluster

Lien vers la documentation officielle — Guide de moteur auto-hébergé d'oVirt, chapitre «Déployer le moteur auto-hébergé à l'aide de la ligne de commande»

Le document présente les prérequis qui doivent être remplis avant le déploiement de la VM hosted-engine, ainsi que le processus d'installation détaillé, donc il n'est pas particulièrement utile de le répéter mot pour mot, mais nous mettons l'accent sur certains détails importants.

• Avant de commencer toute opération, assurez-vous d'activer la prise en charge de la virtualisation dans les paramètres du BIOS sur l'hôte.
• Installez sur l'hôte le paquet pour l'installateur 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

• Lancez sur l'hôte la procédure de déploiement de oVirt Hosted Engine dans un screen (vous pouvez quitter avec Ctrl-A + D, fermer avec Ctrl-D) :

screen
hosted-engine --deploy

Si vous le souhaitez, vous pouvez lancer l'installation avec un fichier de réponses préparé au préalable :

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

• Lors du déploiement de hosted-engine, indiquez tous les paramètres nécessaires :

- nom du cluster
- nombre de vCPU et de vRAM (il est recommandé d'utiliser 4 vCPU et 16 Go)
- mots de passe
- type de stockage pour la VM hosted engine – dans notre cas FC
- numéro LUN pour l'installation de hosted engine
- où se trouvera la base de données pour hosted engine – je recommande pour la simplicité de choisir Local (c'est une base de données PostgreSQL fonctionnant à l'intérieur de cette VM)
et d'autres paramètres. 

• Pour l'installation d'une VM haute disponibilité avec hosted engine, nous avons préalablement créé un LUN spécial numéroté 4 et d'une taille de 150 Go sur le SAN, qui a ensuite été présenté aux hôtes du cluster – voir dans l'article précédent.

Auparavant, nous avions également vérifié sa visibilité sur les hôtes :

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

• Le processus de déploiement de hosted-engine n'est pas compliqué, à la fin nous devrions obtenir un message semblable à celui-ci :

[ INFO  ] Génération du fichier de réponses '/var/lib/ovirt-hosted-engine-setup/answers/answers-20191129131846.conf'
[ INFO  ] Génération du fichier de réponses '/etc/ovirt-hosted-engine/answers.conf'
[ INFO  ] Étape : Pré-termination
[ INFO  ] Étape : Termination
[ INFO  ] Hosted Engine déployé avec succès

Vérifiez la présence des services oVirt sur l'hôte :

Si tout a été fait correctement, après la fin de l'installation, accédez avec un navigateur web à https://ovirt_hostname/ovirt-engine depuis l'ordinateur de l'administrateur, et cliquez sur [Administration Portal].

Capture d'écran de 'Administration Portal'

En saisissant le nom d'utilisateur et le mot de passe (définis lors de l'installation) dans la fenêtre comme sur la capture d'écran, vous accédez au panneau de gestion d'Open Virtualization Manager, où vous pouvez effectuer toutes les opérations sur l'infrastructure virtuelle :

1. ajouter un centre de données
2. ajouter et configurer un cluster
3. ajouter des hôtes et les gérer
4. ajouter des domaines de stockage ou Storage Domains, pour les disques des machines virtuelles
5. ajouter et configurer des réseaux pour les machines virtuelles
6. ajouter des machines virtuelles, des images d'installation, des modèles de VM et les gérer

Toutes ces actions seront examinées plus loin, certaines en gros, d'autres plus en détail et avec des nuances.
Mais d'abord, je recommanderais de lire cet ajout, qui peut certainement être utile à beaucoup.

Module complémentaire

1) En principe, s'il y a un besoin, rien n'empêche d'installer à l'avance l'hyperviseur KVM sur les nœuds du cluster en utilisant les paquets libvirt et qemu-kvm ou qemu-kvm-ev) de la version souhaitée, bien que lors du déploiement d'un nœud de cluster oVirt, il peut le faire lui-même.

Mais si libvirt et qemu-kvm des versions moins récentes ont été installées, alors une telle erreur peut survenir lors du déploiement de l'hôte :

error: configuration non prise en charge : feature CPU inconnue : md-clear

C'est-à-dire qu'il est nécessaire d'avoir une version mise à jour libvirt avec la protection contre MDS, qui supporte cette politique :

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

Installons libvirt v.4.5.0-10.el7_6.12, avec support 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

Vérifions le support pour 'md-clear' :

virsh domcapabilities kvm | grep require

Après cela, nous pouvons continuer l'installation de l'hôte.

2) Dans oVirt 4.3, la présence et l'utilisation d'un pare-feu firewalld sont une exigence obligatoire.

Si lors du déploiement de la VM pour l'hôte, nous recevons une telle erreur :

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld doit être activé et actif pour déployer correctement l'hôte. Veuillez vérifier, corriger en conséquence et redéployer.n"}
[ ERROR ] Échec de l'exécution de l'étape 'Clôture' : Échec de l'exécution du playbook ansible
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Il est donc nécessaire de désactiver un autre pare-feu (s'il est utilisé), et d'installer et de démarrer 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

Par la suite, lors de l'installation de l'agent ovirt sur un nouvel hôte pour le cluster, il configurera automatiquement les ports nécessaires. firewalld automatiquement.

3) Redémarrage de l'hôte contenant une VM avec le moteur hébergé.

Comme d'habitude, lien 1 et lien 2 dans les documents de référence.

Toute la gestion de la VM avec moteur hébergé se fait UNIQUEMENT par la commande hosted-engine sur l'hôte où elle fonctionne, concernant virsh il faut l'oublier, tout comme le fait que l'on peut se connecter à cette VM via SSH et exécuter la commande «fermer».

Procédure pour mettre la VM en mode maintenance :

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

hosted-engine --vm-status
!! Le cluster est en mode de maintenance GLOBAL !!
--== État de l'hôte host1.test.local (id : 1) ==--
conf_on_shared_storage             : True
Statut à jour                      : True
Nom d'hôte                         : host1.test.local
ID Hôte                           : 1
État moteur                       : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
arrêté                             : False
Maintenance locale                 : False
crc32                              : dee1a774
horodatage_conf_local             : 1821
horodatage_hôte                  : 1821
Métadonnées supplémentaires (valables à l'horodatage) :
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (sam. 29 nov. 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (sam. 29 nov. 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Nous redémarrons l'hôte avec l'agent du moteur hébergé et nous faisons ce qu'il nous faut.

Après le redémarrage, vérifions l'état de la VM avec le moteur hébergé :

hosted-engine --vm-status

Si notre VM avec le moteur hébergé ne démarre pas et si nous voyons des erreurs similaires dans le journal du service :

Erreur dans le journal du service :

journalctl -u ovirt-ha-agent
...
29 juin 14:34:44 host1 journal : ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERREUR Échec du démarrage des moniteurs nécessaires
29 juin 14:34:44 host1 journal : ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERREUR Traceback (most recent call last):#012  Fichier "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", ligne 131, dans _run_agent#012    return action(he)#012  Fichier "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/agent.py", ligne 55, dans action_proper#012    return he.start_monitoring()#012  Fichier "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", ligne 413, dans start_monitoring#012    self._initialize_broker()#012  Fichier "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/agent\/hosted_engine.py", ligne 537, dans _initialize_broker#012    m.get('options', {}))#012  Fichier "\/usr\/lib\/python2.7\/site-packages\/ovirt_hosted_engine_ha\/lib\/brokerlink.py", ligne 86, dans start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - échec du démarrage du moniteur via ovirt-ha-broker : [Errno 2] Aucun fichier ou répertoire de ce type, [moniteur : 'ping', options : {'addr': '172.20.32.32'}]
29 juin 14:34:44 host1 journal : ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERREUR Tentative de redémarrage de l'agent

Alors, connectons le stockage et redémarrons l'agent :

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

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

Après le démarrage de la VM avec le moteur hébergé, sortons-la du mode maintenance :

Procédure pour sortir la VM du mode maintenance :

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

--== Hôte host1.test.local (id : 1) statut ==--

conf_on_shared_storage             : True
Statut à jour                       : True
Nom d'hôte                          : host1.test.local
ID de l'hôte                        : 1
Statut de l'engine                  : {"health": "good", "vm": "up", "detail": "Up"}
Score                               : 3400
arrêté                              : False
Maintenance locale                  : False
crc32                               : 6d1eb25f
local_conf_timestamp                : 6222296
Horodatage de l'hôte                : 6222296
Métadonnées supplémentaires (valide à l'horodatage) :
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=6222296 (Ven 17 Jan 11:40:43 2020)
        host-id=1
        score=3400
        vm_conf_refresh_time=6222296 (Ven 17 Jan 11:40:43 2020)
        conf_on_shared_storage=True
        maintenance=False
        state=EngineUp
        stopped=False

4) Suppression de l'hôte et de tout ce qui y est lié.

Il peut parfois être nécessaire de supprimer correctement un hôte précédemment installé — lien dans le document de référence.

Il suffit d'exécuter la commande sur l'hôte :

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

Ensuite, nous supprimons les paquets inutiles, en faisant une sauvegarde préalable de certaines configurations si nécessaire :

yum autoremove ovirt* qemu* virt* libvirt* libguestfs 

Création d'un nouveau centre de données

Documentation de référence — oVirt Administration Guide. Chapitre 4 : Centres de données

Commençons par définir ce qu'est un centre de données (je cite de la documentation) — c'est une entité logique qui définit un ensemble de ressources utilisées dans un environnement spécifique.

Un centre de données est en quelque sorte un conteneur composé de :

• ressources logiques sous forme de clusters et d'hôtes
• ressources réseau du cluster sous forme de réseaux logiques et d’adaptateurs physiques sur les hôtes,
• ressources de stockage (pour les disques de VM, modèles, images) sous forme de domaines de stockage.

Un centre de données peut inclure plusieurs clusters, composés de plusieurs hôtes dotés de machines virtuelles qui s'exécutent sur eux, et peut également avoir plusieurs domaines de stockage associés.
Il peut y avoir plusieurs centres de données, ils fonctionnent de manière indépendante les uns des autres. Dans oVirt, il y a une séparation des pouvoirs par rôle, et il est possible de configurer des autorisations individuellement au niveau du centre de données ainsi que sur ses éléments logiques distincts.

Les centres de données, ou les centres de données s'il y en a plusieurs, sont gérés à partir d'une console administrative unique ou d'un portail.

Pour créer un centre de données, accédez au portail administratif et créez un nouveau centre de données :
Calcul >> Centres de données >> Nouveau

Comme nous utilisons un stockage partagé sur SAN, le type de stockage doit être Partagé :

Capture d'écran avec l'assistant de création du centre de données

Lors de l'installation d'une machine virtuelle avec hosted-engine, un centre de données est créé par défaut – Datacenter1, et par la suite, il est possible de changer le type de stockage (Storage Type) si nécessaire.

La création d'un centre de données est une tâche simple, sans nuances compliquées, et toutes les actions supplémentaires à son égard sont décrites dans la documentation. Je note simplement que les hôtes isolés disposant uniquement d'un stockage local (disque) pour les machines virtuelles ne pourront pas entrer dans un centre de données avec un Storage Type - Shared (il ne sera pas possible de les y ajouter), et pour eux, il faut créer un centre de données séparé – c'est-à-dire que chaque hôte séparé avec un stockage local a besoin de son propre centre de données.

Création d'un nouveau cluster

Lien vers la documentation – oVirt Administration Guide. Chapitre 5 : Clusters

Sans entrer dans les détails superflus, un cluster – est un regroupement logique d'hôtes ayant un espace de stockage commun (sous forme de disques partagés sur le SAN, comme dans notre cas). Il est également souhaitable que les hôtes du cluster soient identiques en termes de matériel et qu'ils aient le même type de processeur (Intel ou AMD). Il est préférable, bien sûr, que les serveurs du cluster soient complètement identiques.

Le cluster fait partie du centre de données (avec un certain type de stockage – Local ou Partagé), et tous les hôtes doivent nécessairement appartenir à un cluster, selon qu'ils ont un stockage commun ou non.

Lors de l'installation d'une machine virtuelle avec hosted-engine sur un hôte, un centre de données est créé par défaut – Datacenter1, en même temps qu'un cluster – Cluster1, et par la suite, il est possible de configurer ses paramètres, d'activer des options supplémentaires, d'ajouter des hôtes, etc.

Comme d'habitude, pour obtenir des détails sur tous les paramètres du cluster, il est recommandé de se référer à la documentation officielle. En ce qui concerne les particularités de la configuration du cluster, je préciserai seulement que lors de sa création, il suffit de configurer uniquement les paramètres principaux dans l'onglet Général.

Je soulignerai les paramètres les plus importants :

• Type de processeur – est choisi en fonction des processeurs installés sur les hôtes du cluster, du fabricant et du processeur le plus ancien parmi les hôtes, afin d'utiliser toutes les instructions processeur disponibles dans le cluster.
• Type de commutateur – dans notre cluster, seul le pont Linux est utilisé, donc c'est celui que nous choisissons.
• Type de pare-feu – ici, tout est clair, il s'agit de firewalld, qui doit être activé et configuré sur les hôtes.

Capture d'écran avec les paramètres du cluster

Installation d'hôtes supplémentaires dans un environnement auto-hébergé

Lien dans la documentation.

Les hôtes supplémentaires pour l'environnement auto-hébergé sont ajoutés de la même manière qu'un hôte ordinaire, avec l'étape supplémentaire d'un déploiement de VM avec un moteur hébergé — Choisir l'action de déploiement du moteur hébergé >> Déployer. Étant donné qu'un hôte supplémentaire doit également être présenté avec un LUN pour la VM avec moteur hébergé, cela signifie que cet hôte peut être utilisé pour héberger une VM avec moteur hébergé si nécessaire.
Pour des raisons de haute disponibilité, il est fortement recommandé d'avoir au moins deux hôtes pouvant héberger une VM avec moteur hébergé.

Sur l'hôte supplémentaire, désactivez iptables (s'il est activé), activez firewalld

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installez la version requise de KVM (si nécessaire):

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

Installez les dépôts nécessaires et l'installateur du moteur hébergé:

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

Ensuite, passez à la console Open Virtualization Manager, ajoutez un nouvel hôte et suivez toutes les étapes, comme indiqué dans documentation.

En conséquence, après avoir ajouté l'hôte supplémentaire, nous devrions obtenir une image similaire dans la console d'administration, comme sur la capture d'écran.

Capture d'écran du portail administratif — hôtes

L'hôte sur lequel la VM avec moteur hébergé est actuellement actif a une couronne dorée et la mention «Exécution de la VM Hosted Engine», l'hôte sur lequel cette VM peut être démarrée si nécessaire – la mention «Peut exécuter la VM Hosted Engine».

En cas de défaillance de l'hôte sur lequel «Exécution de la VM Hosted Engine», cela redémarrera automatiquement sur le deuxième hôte. De plus, cette VM peut être migrée de l'hôte actif vers le secours pour maintenance.

Configuration de la gestion de l'alimentation / fencing sur les hôtes oVirt

Liens vers la documentation :

• Red Hat Virtualization 4.3 –> Référence technique -> Chapitre 4. Gestion de l'alimentation
• Guide de l'administration oVirt -> Chapitre 7 : Hôtes

Bien qu'il puisse sembler que l'ajout et la configuration de l'hôte soient terminés, ce n'est pas tout à fait vrai.
Pour un fonctionnement normal des hôtes, et pour identifier/résoudre les pannes de l'un d'eux, il est nécessaire de configurer la gestion de l'alimentation / fencing.

Fencing, ou le fencing – est le processus d'exclusion temporaire d'un hôte défaillant ou en panne du cluster, durant lequel les services oVirt sur celui-ci ou l'hôte lui-même sont redémarrés.

Tous les détails concernant les définitions et les paramètres de la gestion de l'alimentation / fencing sont, comme d'habitude, fournis dans la documentation, je vais juste donner un exemple de la façon de configurer ce paramètre important, appliqué aux serveurs Dell R640 avec iDRAC 9.

1. Nous accédons au portail administratif, cliquons sur Calcul >> Hôtes sélectionnons un hôte.
2. Cliquons sur Modifier.
3. Cliquons sur l'onglet Gestion de l'alimentation.
4. Cochons la case à côté de l'option Activer la gestion de l'alimentation.
5. Cochons la case à côté de l'option Intégration Kdump, afin que l'hôte ne passe pas en mode de fencing pendant l'enregistrement du dump de noyau.

Remarque.

Après avoir activé l'intégration Kdump sur un hôte déjà en fonctionnement, il doit être réinstallé conformément à la procédure dans le Guide d'administration d'oVirt -> Chapitre 7 : Hôtes -> Réinstaller les hôtes.

1. En option, nous pouvons cocher la case Désactiver le contrôle de la politique de gestion de l'alimentation, si nous ne voulons pas que la gestion de l'alimentation de l'hôte soit contrôlée par la politique de planification du cluster.
2. Cliquons sur le bouton (+), pour ajouter un nouvel appareil de gestion de l'alimentation, une fenêtre de modification des propriétés de l'agent s'ouvrira.
   Pour iDRAC9, remplissons les champs :
   • Address – adresse iDRAC9
   • Nom d'utilisateur / Mot de passe – respectivement le login et le mot de passe pour accéder à iDRAC9
   • Type — drac5
   • notez Sécurisé
   • ajouter les options suivantes : cmd_prompt=>,login_timeout=30

Capture d'écran avec les paramètres « Gestion de l'alimentation » dans les propriétés de l'hôte

Création d'une zone de stockage ou de domaines de stockage

Lien vers la documentation - Guide d'administration d'oVirt, Chapitre 8 : Stockage.

Domaine de stockage, ou le domaine de stockage – est un emplacement centralisé pour le stockage des disques des machines virtuelles, des images d'installation, des modèles et des snapshots.

Les domaines de stockage peuvent se connecter au centre de données en utilisant divers protocoles, systèmes de fichiers cluster et réseau.

oVirt dispose de trois types de domaines de stockage :

• Domaine de données – pour le stockage de toutes les données liées aux machines virtuelles (disques, modèles). Le Domaine de données ne peut pas être partagé entre différents centres de données.
• Domaine ISO (type de domaine de stockage obsolète) – pour le stockage des images d'installation du système d'exploitation. Le Domaine ISO peut être partagé entre différents centres de données.
• Domaine d'exportation (type de domaine de stockage obsolète) – pour le stockage temporaire des images transférées entre centres de données.

Dans notre cas particulier, le domaine de stockage de type Domaine de données utilise le protocole Fibre Channel (FCP) pour se connecter aux LUN sur le SAN.

Du point de vue d'oVirt, lorsqu'on utilise un stockage (FC ou iSCSI), chaque disque virtuel, snapshot ou modèle est un disque logique.
Les dispositifs de blocs sont regroupés en un tout (sur les hôtes du cluster) à l'aide de Volume Group et ensuite divisés en volumes logiques, utilisés comme disques virtuels pour les VM.

Tous ces groupes et de nombreux volumes LVM peuvent être vus sur un hôte de cluster, à l'aide des commandes vgs et lvs. Naturellement, toutes les actions sur ces disques doivent être effectuées uniquement depuis la console oVirt, sauf cas exceptionnels.

Les disques virtuels pour les VM peuvent être de deux types : QCOW2 ou RAW. Les disques peuvent être "minces" ou "épais". Les snapshots sont toujours créés comme "minces".

". La gestion des domains de stockage, ou des zones de stockage, accessibles via FC, est assez logique : pour chaque disque virtuel de la VM, il existe un volume logique distinct, qui est accessible en écriture uniquement par un hôte. En cas de connexions via FC, oVirt utilise quelque chose comme LVM clusterisé.

Les machines virtuelles situées sur une même zone de stockage peuvent être migrées entre des hôtes appartenant au même cluster.

Comme on le voit dans la description, un cluster dans oVirt, tout comme un cluster dans VMware vSphere ou Hyper-V, désigne essentiellement la même chose : un regroupement logique d'hôtes, de préférence similaires en termes de 'hardware', et ayant un stockage commun pour les disques des machines virtuelles.

Passons directement à la création d'une zone de stockage pour les données (disques des VM), car sans cela, le centre de données ne sera pas initialisé.
Je rappelle que tous les LUN présentés aux hôtes du cluster sur le stockage doivent être visibles via la commande «multipath -ll».

Selon documentation, allons dans le portail pour accéder à Stockage >> Domains -> Nouveau Domaine et exécutons les instructions de la section "Ajout de Stockage FCP".

Après avoir lancé l'assistant, remplissons les champs requis :

• Nom — donnons un nom au cluster
• Fonction du Domaine — Données
• Type de Stockage — Fibre Channel
• Hôte à Utiliser — sélectionnons l'hôte sur lequel le LUN requis est disponible

Dans la liste des LUN, sélectionnons celui dont nous avons besoin, cliquons sur Ajouter et ensuite OK. Si nécessaire, il est possible de corriger les paramètres supplémentaires de la zone de stockage en cliquant sur Paramètres Avancés.

Capture d'écran de l'assistant d'ajout de « Domaine de stockage »

Suite au travail de l'assistant, nous devrions obtenir une nouvelle zone de stockage, et notre centre de données passer à l'état UP, ou initialisé :

Captures d'écran du centre de données et des zones de stockage à l'intérieur :

Création et configuration de réseaux pour les machines virtuelles

Lien vers la documentation - Guide d'administration d'oVirt, Chapitre 6 : Réseaux Logiques

Les réseaux, ou networks, servent à regrouper les réseaux logiques utilisés dans l'infrastructure virtuelle oVirt.

Pour l'interaction entre le adaptateur réseau sur la machine virtuelle et l'adaptateur physique sur l'hôte, des interfaces logiques de type pont Linux sont utilisées.

Pour regrouper et séparer le trafic entre les réseaux, des VLAN sont configurés sur les commutateurs.

Lors de la création d'un réseau logique pour les machines virtuelles dans oVirt, il est indispensable de lui attribuer un identifiant correspondant au numéro de VLAN sur le commutateur, afin que les machines virtuelles puissent interagir entre elles, même si elles fonctionnent sur des nœuds différents du cluster.

Les paramètres préliminaires des adaptateurs réseau sur les hôtes pour connecter les machines virtuelles doivent avoir été configurés dans l'article précédent – l'interface logique est configurée bond1, ensuite tous les réglages réseau doivent être effectués uniquement via le portail d'administration oVirt.

Après la création de la VM avec hosted-engine, en plus de la création automatique du centre de données et du cluster, un réseau logique pour la gestion de notre cluster a également été créé automatiquement – ovritmgmt, au quel cette VM a été connectée.

Si nécessaire, les paramètres du réseau logique peuvent être consultés ovritmgmt et ajustés, mais il faut être prudent pour ne pas perdre le contrôle de l'infrastructure oVirt.

Paramètres du réseau logique ovritmgmt

Pour créer un nouveau réseau logique pour des VM ordinaires, dans le portail d'administration, nous allons à Réseau >> Réseaux >> Nouveau, et dans l'onglet Général nous ajoutons un réseau avec l'identifiant VLAN souhaité, et nous coché la case «Réseau VM», cela signifie qu'il peut être utilisé pour être assigné aux VM.

Capture d'écran du nouveau réseau logique VLAN32

Dans l'onglet Cluster, nous attachons ce réseau à notre cluster Cluster1.

Après cela, nous allons dans Calcul >> Hôtes, nous allons tour à tour dans chaque hôte, dans l'onglet Interfaces réseau, et lançons l'assistant Configurer les réseaux hôtes, pour lier la nouvelle réseau logique aux hôtes.

Capture d'écran de l'assistant «Configurer les réseaux hôtes»

L'agent oVirt effectuera automatiquement tous les réglages réseau nécessaires sur l'hôte – créera le VLAN et le BRIDGE.

Exemple de fichiers de configuration pour les nouveaux réseaux sur l'hôte :

cat ifcfg-bond1
# Généré par 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
# Généré par 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
# Généré par 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

Je rappelle encore que sur l'hôte du cluster IL N'EST PAS NÉCESSAIRE de créer manuellement les interfaces réseau à l'avance ifcfg-bond1.432 et ifcfg-ovirtvm-vlan432.

Après avoir ajouté le réseau logique et vérifié la connexion entre l'hôte et la VM avec le moteur hébergé, il peut être utilisé dans la machine virtuelle.

Création d'une image d'installation pour déployer une machine virtuelle

Lien vers la documentation - Guide d'administration d'oVirt, Chapitre 8 : Stockage, section Téléchargement d'images vers un domaine de stockage de données.

Sans l'image d'installation du système d'exploitation, il ne sera pas possible d'installer la machine virtuelle, bien que cela ne soit pas un problème, si par exemple, un Cobbler avec des images déjà créées.

Dans notre cas, cette possibilité n'existe pas, donc nous devrons importer cette image manuellement dans oVirt. Auparavant, il était nécessaire de créer un domaine ISO, mais dans la nouvelle version d'oVirt, il a été considéré comme obsolète, et il est donc maintenant possible de charger des images directement dans le domaine de stockage depuis le portail d'administration.

Dans le portail d'administration, allons à Stockage >> Disks >> Télécharger >> Commencer
Nous ajoutons notre image du système d'exploitation sous forme de fichier ISO, dans le formulaire, nous remplissons tous les champs et cliquons sur le bouton "Tester la connexion".

Capture d'écran de l'assistant d'ajout de l'image d'installation

Si nous obtenons une erreur de ce type :

Impossible de télécharger l'image sur le disque d6d8fd10-c1e0-4f2d-af15-90f8e636dadc en raison d'une erreur réseau. Assurez-vous que le service ovirt-imageio-proxy est installé et configuré et que le certificat CA d'ovirt-engine est enregistré en tant que CA de confiance dans le navigateur. Le certificat peut être récupéré à partir de https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA

Il est donc nécessaire d'ajouter le certificat oVirt dans «CA racines de confiance» (Trusted Root CA) sur la station de gestion de l'administrateur, d'où nous essayons de télécharger l'image.

Après avoir ajouté le certificat dans le Trusted Root CA, nous cliquons à nouveau sur "Tester la connexion", nous devrions obtenir :

La connexion à ovirt-imageio-proxy a réussi.

Après avoir ajouté le certificat, vous pouvez essayer de nouveau de télécharger l'image ISO dans le domaine de stockage.

En principe, il est possible de créer un domaine de stockage distinct de type Data, pour stocker les images et modèles séparément des disques VM, ou même de les stocker dans le domaine de stockage pour le moteur hébergé, mais cela dépend déjà de la décision de l'administrateur.

Capture d'écran avec des images ISO dans le domaine de stockage pour le moteur hébergé

Création d'une machine virtuelle

Lien vers la documentation :
Guide de gestion des machines virtuelles oVirt –> Chapitre 2 : Installation des machines virtuelles Linux
Ressources des clients de console

Après avoir téléchargé l'image d'installation du système d'exploitation dans oVirt, vous pouvez passer directement à la création de la machine virtuelle. Du travail a été fait, mais nous sommes déjà dans la phase finale, pour laquelle tout cela a été entrepris : obtenir une infrastructure tolérante aux pannes pour l'hébergement de machines virtuelles hautement disponibles. Et tout cela est absolument gratuit - aucun centime n'a été dépensé pour l'achat de licences logicielles.

Pour créer une machine virtuelle avec CentOS 7, une image d'installation du système d'exploitation doit être téléchargée.

Connectez-vous au portail d'administration, allez dans Calcul >> Machines Virtuelles, et lancez l'assistant de création de VM. Remplissez tous les paramètres et champs, puis cliquez sur OK. C'est très simple si vous suivez la documentation.

À titre d'exemple, je vais donner les paramètres principaux et supplémentaires d'une VM hautement disponible, avec un disque créé, connectée au réseau, et démarrant à partir de l'image d'installation :

Captures d'écran des paramètres de la VM hautement disponible

Après avoir terminé les travaux avec l'assistant, fermez-le, démarrez la nouvelle VM et installez le système d'exploitation dessus.
Pour ce faire, accédez à la console de cette VM via le portail d'administration :

Capture d'écran des paramètres du portail d'administration pour se connecter à la console de la VM

Pour se connecter à la console de la VM, il faut d'abord configurer la console dans les propriétés de la machine virtuelle.

Capture d'écran des paramètres de la VM, onglet « Console »

Pour se connecter à la console de la VM, vous pouvez utiliser par exemple, Virtual Machine Viewer.

Pour se connecter à la console de la VM directement dans la fenêtre du navigateur, les paramètres de connexion via la console doivent être les suivants :

Après l'installation du système d'exploitation sur la VM, il est conseillé d'installer l'agent invité 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

Ainsi, grâce à nos actions, la VM créée sera hautement disponible, c'est-à-dire qu'en cas d'échec du nœud du cluster sur lequel elle est exécutée, oVirt la redémarrera automatiquement sur le deuxième nœud. Cette VM peut également être migrée entre les hôtes du cluster pour leur maintenance, ou d'autres objectifs.

Conclusion

J'espère qu'à travers cet article, j'ai pu transmettre que oVirt est un outil tout à fait acceptable pour la gestion d'infrastructures virtuelles, qui n'est pas si difficile à déployer - le principal est de respecter certaines règles et exigences, décrites à la fois dans l'article et dans la documentation.

En raison du volume important de l'article, il n'a pas été possible d'y inclure de nombreux éléments, tels que l'exécution pas à pas de divers assistants avec toutes les explications détaillées et les captures d'écran, et les longues sorties de certaines commandes, etc. En fait, il aurait fallu écrire tout un livre pour cela, ce qui n'a pas beaucoup de sens en raison de la constante apparition de nouvelles versions de logiciels avec des nouveautés et des modifications. L'essentiel est de comprendre le principe de fonctionnement global et d'obtenir un algorithme général d'actions pour créer une plateforme résiliente pour la gestion des machines virtuelles.

Bien que nous ayons créé l'infrastructure virtuelle, nous devons maintenant l'apprendre à interagir tant entre ses différents éléments : hôtes, machines virtuelles, réseaux internes, qu'avec le monde extérieur.

Ce processus est l'une des tâches fondamentales d'un administrateur système ou réseau, qui sera développée dans l'article suivant — sur l'utilisation des routeurs virtuels VyOS dans l'infrastructure résiliente de notre entreprise (comme vous l'avez deviné, ils fonctionneront en tant que machines virtuelles sur notre cluster oVirt).

Source : habr.com