🥇Création d'une infrastructure informatique tolérante aux pannes. Partie 2. Installation et configuration du cluster oVirt 4.3

Cet article est la suite du précédent - "Création d'une infrastructure informatique tolérante aux pannes. Partie 1 - Préparation au déploiement d'un cluster oVirt 4.3».

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

Introduction

L'objectif principal de l'article est de fournir des instructions étape par étape telles que «Suivant -> Oui -> Finition"comment afficher certaines fonctionnalités lors de son installation et de sa configuration. Le processus de déploiement de votre cluster peut ne pas toujours coïncider avec celui qui y est décrit, en raison des caractéristiques de l'infrastructure et de l'environnement, mais les principes généraux seront les mêmes.

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

Pour ceux que ça intéresse, toutes les différences entre RHEV (alias oVirt) et VMware vSphere se trouvent par exemple sur Internet ici, mais je noterai encore occasionnellement certaines de leurs différences ou similitudes les unes avec les autres au fur et à mesure de la progression de l'article.

Par ailleurs, je voudrais comparer un peu le travail avec les réseaux pour machines virtuelles. oVirt implémente un principe similaire de gestion de réseau pour les machines virtuelles (ci-après dénommées VM), comme dans VMware vSphere :

en utilisant un pont Linux standard (dans VMware - Commutateur virtuel standard), exécuté sur des hôtes de virtualisation ;
en utilisant Open vSwitch (OVS) (dans VMware - vSwitch distribué) est un commutateur virtuel distribué composé de deux composants principaux : un serveur OVN central et des contrôleurs OVN sur des hôtes gérés.

Il convient de noter qu'en raison de la facilité de mise en œuvre, l'article décrira la configuration de réseaux dans oVirt pour une VM utilisant un pont Linux standard, qui est le choix standard lors de l'utilisation de l'hyperviseur KVM.

À cet égard, il existe plusieurs règles de base pour travailler avec le réseau dans un cluster, qu'il est préférable de ne pas enfreindre :

Tous les paramètres réseau sur les hôtes avant de les ajouter à oVirt doivent être identiques, à l'exception des adresses IP.
Une fois qu'un hôte a été pris sous le contrôle d'oVirt, il est fortement déconseillé de modifier quoi que ce soit manuellement dans les paramètres réseau sans avoir pleinement confiance en vos actions, car l'agent oVirt les restaurera simplement aux précédents après le redémarrage de l'hôte ou agent.
L'ajout d'un nouveau réseau pour une VM, ainsi que l'utilisation de celui-ci, ne doivent être effectués qu'à partir de la console de gestion oVirt.

Une autre note importante — pour un environnement très critique (très sensible aux pertes monétaires), il serait quand même recommandé d'utiliser un support payant et d'utiliser Virtualisation Red Hat 4.3. Lors du fonctionnement du cluster oVirt, certains problèmes peuvent survenir pour lesquels il est conseillé de recevoir une aide qualifiée dans les plus brefs délais, plutôt que de les résoudre vous-même.

Et enfin recommandé Avant de déployer un cluster oVirt, familiarisez-vous avec documents officiels, afin de connaître au moins les concepts et définitions de base, sinon il sera un peu difficile de lire la suite de l'article.

Les documents d'orientation suivants sont essentiels à la compréhension de l'article et des principes de fonctionnement du cluster oVirt :

Le volume n'y est pas très important, en une heure ou deux on peut tout à fait maîtriser les principes de base, mais pour ceux qui aiment les détails, il est recommandé de lire Documentation produit pour Red Hat Virtualization 4.3 — RHEV et oVirt sont essentiellement la même chose.

Ainsi, si tous les réglages de base sur les hôtes, les commutateurs et les systèmes de stockage ont été effectués, nous procédons directement au déploiement d'oVirt.

Partie 2. Installation et configuration du cluster oVirt 4.3

Pour faciliter l'orientation, je vais lister les principales sections de cet article, qui doivent être complétées une par une :

Installation du serveur de gestion oVirt
Création d'un nouveau centre de données
Créer un nouveau cluster
Installation d'hôtes supplémentaires dans un environnement auto-hébergé
Création d'une zone de stockage ou de domaines de stockage
Création et configuration de réseaux pour machines virtuelles
Création d'une image d'installation pour déployer une machine virtuelle
Créer une machine virtuelle

Installation du serveur de gestion oVirt

Serveur de gestion oVirt est l'élément le plus important de l'infrastructure oVirt, sous la forme d'une machine virtuelle, d'un hôte ou d'un périphérique virtuel qui gère l'ensemble de l'infrastructure oVirt.

Ses analogues proches du monde de la virtualisation sont :

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

Pour installer le serveur de gestion oVirt, nous avons deux options :

Option 1
Déployer un serveur sous forme de VM ou d'hôte spécialisé.

Cette option fonctionne plutôt bien, mais à condition qu'une telle VM fonctionne indépendamment du cluster, c'est-à-dire ne s'exécute sur aucun hôte de cluster en tant que machine virtuelle standard exécutant KVM.

Pourquoi une telle VM ne peut-elle pas être déployée sur des hôtes de cluster ?

Au tout début du processus de déploiement du serveur de gestion oVirt, nous sommes confrontés à un dilemme : nous devons installer une VM de gestion, mais en fait il n'y a pas encore de cluster lui-même, et donc que pouvons-nous proposer à la volée ? C'est vrai - installez KVM sur un futur nœud de cluster, puis créez une machine virtuelle dessus, par exemple avec CentOS OS et déployez-y le moteur oVirt. Cela peut généralement être fait pour des raisons de contrôle total sur une telle VM, mais c'est une intention erronée, car dans ce cas, à l'avenir, il y aura 100 % de problèmes avec une telle VM de contrôle :

il ne peut pas être migré dans la console oVirt entre les hôtes (nœuds) du cluster ;
lors de la migration à l'aide de KVM via virsh migrer, cette VM ne sera pas disponible pour la gestion depuis la console oVirt.
les hôtes du cluster ne peuvent pas être affichés dans Le mode de maintenance (mode maintenance), si vous migrez cette VM d'hôte en hôte à l'aide de virsh migrer.

Alors faites tout selon les règles - utilisez soit un hôte distinct pour le serveur de gestion oVirt, soit une VM indépendante qui s'exécute dessus, ou mieux encore, faites comme écrit dans la deuxième option.

Option 2
Installation d'oVirt Engine Appliance sur un hôte de cluster géré par celui-ci.

C'est cette option qui sera considérée plus loin comme la plus correcte et la plus adaptée dans notre cas.
Les exigences pour une telle VM sont décrites ci-dessous ; j'ajouterai seulement qu'il est recommandé d'avoir au moins deux hôtes dans l'infrastructure sur lesquels la VM de contrôle peut être exécutée afin de la rendre tolérante aux pannes. Ici, je voudrais ajouter que, comme je l'ai déjà écrit dans les commentaires de l'article précédent, je n'ai jamais pu obtenir cerveau divisé sur un cluster oVirt de deux hôtes, avec la possibilité d'exécuter des machines virtuelles à moteur hébergé sur eux.

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

Lien vers la documentation officielle - Guide du moteur auto-hébergé oVirt, chapitre "Déploiement du moteur auto-hébergé à l'aide de la ligne de commande»

Le document précise les prérequis qui doivent être remplis avant de déployer une VM à moteur hébergé, et décrit également en détail le processus d'installation lui-même, il est donc inutile de le répéter textuellement, nous allons donc nous concentrer sur certains détails importants.

Avant de commencer toutes les actions, assurez-vous d'activer la prise en charge de la virtualisation dans les paramètres du BIOS sur l'hôte.
Installez le package pour le programme d'installation du moteur hébergé sur l'hôte :

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

Nous lançons la procédure de déploiement d'oVirt Hosted Engine dans l'écran de l'hôte (vous pouvez le quitter via Ctrl-A + D, fermer via Ctrl-D) :

screen
hosted-engine --deploy

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

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

Lors du déploiement du moteur hébergé, nous spécifions tous les paramètres nécessaires :

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

Pour installer une VM hautement disponible avec un moteur hébergé, nous avons préalablement créé un LUN spécial sur le système de stockage, au numéro 4 et d'une taille de 150 Go, qui a ensuite été présenté aux hôtes du cluster - voir article précédent.

Auparavant, nous vérifiions également 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 du moteur hébergé en lui-même n'est pas compliqué ; à la fin, nous devrions recevoir quelque chose comme ceci :

[ 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

On vérifie la présence des services oVirt sur l'hébergeur :

Si tout a été fait correctement, une fois l'installation terminée, utilisez un navigateur Web pour accéder à https://ovirt_hostname/ovirt-engine depuis l'ordinateur de l'administrateur, puis cliquez sur [Portail d'administration].

Capture d'écran du « Portail d'administration »

En saisissant le login et le mot de passe (définis lors du processus d'installation) dans la fenêtre comme dans la capture d'écran, nous arrivons au panneau de configuration Open Virtualization Manager, dans lequel vous pouvez effectuer toutes les actions avec l'infrastructure virtuelle :

ajouter un centre de données
ajouter et configurer un cluster
ajouter et gérer des hôtes
ajouter des zones de stockage ou des domaines de stockage pour les disques de machine virtuelle
ajouter et configurer des réseaux pour les machines virtuelles
ajouter et gérer des machines virtuelles, des images d'installation, des modèles de VM

Toutes ces actions seront discutées plus loin, certaines dans de grandes cellules, d'autres plus en détail et avec des nuances.
Mais d'abord, je recommanderais de lire ce module complémentaire, qui sera probablement utile à beaucoup.

Addition

1) En principe, si un tel besoin existe, rien ne vous empêche d'installer au préalable l'hyperviseur KVM sur les nœuds du cluster à l'aide de packages libvirt и 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 puisse le faire lui-même.

Mais si libvirt и qemu-kvm Si vous n'avez pas installé la dernière version, vous pouvez recevoir l'erreur suivante lors du déploiement d'un moteur hébergé :

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

Ceux. doit avoir Version mise à jour libvirt avec protection contre MDS, qui soutient cette politique :

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

Installez libvirt v.4.5.0-10.el7_6.12, avec le 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érifiez la prise en charge de « md-clear » :

virsh domcapabilities kvm | grep require
      <feature policy='require' name='ss'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='pku'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='ssbd'/>
      <feature policy='require' name='invtsc'/>

Après cela, vous pouvez continuer l'installation du moteur hébergé.

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

Si lors du déploiement d'une VM pour un moteur hébergé, nous recevons l'erreur suivante :

[ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "firewalld is required to be enabled and active in order to correctly deploy hosted-engine. Please check, fix accordingly and re-deploy.n"}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook
[https://bugzilla.redhat.com/show_bug.cgi?id=1608467

Ensuite, vous devez désactiver un autre pare-feu (s'il est utilisé), puis l'installer et l'exécuter. pare-feu:

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

Plus tard, lors de l'installation de l'agent ovirt sur un nouvel hôte pour le cluster, il configurera les ports requis dans pare-feu automatiquement.

3) Redémarrer un hôte sur lequel une VM s'exécute avec un moteur hébergé.

Comme d'habitude Lien 1 и Lien 2 aux documents constitutifs.

Toute la gestion de la VM du moteur hébergé se fait UNIQUEMENT à l'aide de la commande moteur hébergé sur l'hôte où il s'exécute, environ Virsh il faut oublier, ainsi que le fait que vous pouvez vous connecter à cette VM via SSH et exécuter la commande «shutdown».

Procédure pour mettre une VM en mode maintenance :

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

hosted-engine --vm-status
!! Cluster is in GLOBAL MAINTENANCE mode !!
--== Host host1.test.local (id: 1) status ==--
conf_on_shared_storage             : True
Status up-to-date                  : True
Hostname                           : host1.test.local
Host ID                            : 1
Engine status                      : {"health": "good", "vm": "up", "detail": "Up"}
Score                              : 3400
stopped                            : False
Local maintenance                  : False
crc32                              : dee1a774
local_conf_timestamp               : 1821
Host timestamp                     : 1821
Extra metadata (valid at timestamp):
        metadata_parse_version=1
        metadata_feature_version=1
        timestamp=1821 (Sat Nov 29 14:25:19 2019)
        host-id=1
        score=3400
        vm_conf_refresh_time=1821 (Sat Nov 29 14:25:19 2019)
        conf_on_shared_storage=True
        maintenance=False
        state=GlobalMaintenance
        stopped=False

hosted-engine --vm-shutdown

Nous redémarrons l'hôte avec l'agent du moteur hébergé et faisons ce dont nous avons besoin avec.

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

hosted-engine --vm-status

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

Erreur dans le journal de service :

journalctl -u ovirt-ha-agent
...
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Failed to start necessary monitors
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Traceback (most recent call last):#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 131, in _run_agent#012    return action(he)#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line 55, in action_proper#012    return he.start_monitoring()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 413, in start_monitoring#012    self._initialize_broker()#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", line 537, in _initialize_broker#012    m.get('options', {}))#012  File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 86, in start_monitor#012    ).format(t=type, o=options, e=e)#012RequestError: brokerlink - failed to start monitor via ovirt-ha-broker: [Errno 2] No such file or directory, [monitor: 'ping', options: {'addr': '172.20.32.32'}]
Jun 29 14:34:44 host1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.agent.Agent ERROR Trying to restart agent

Ensuite, nous 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 avoir démarré la VM avec le moteur hébergé, nous la sortons du mode maintenance :

Procédure pour supprimer une VM du mode maintenance :

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) Suppression du moteur hébergé et de tout ce qui lui est associé.

Parfois, il est nécessaire de supprimer correctement un moteur hébergé précédemment installé - lien au document d’orientation.

Exécutez simplement la commande sur l'hôte :

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

Ensuite, nous supprimons les packages inutiles, en sauvegardant certaines configurations avant cela, si nécessaire :

yum autoremove ovirt* qemu* virt* libvirt* libguestfs

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

Documentation de référence - Guide d'administration oVirt. Chapitre 4 : Centres de données

Définissons d’abord ce que c’est centre de données (je cite l'aide) est une entité logique qui définit un ensemble de ressources utilisées dans un environnement spécifique.

Un data center est une sorte de 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 disques VM, modèles, images) sous forme de zones de stockage (Storage Domains).

Un centre de données peut inclure plusieurs clusters composés de plusieurs hôtes sur lesquels s'exécutent des machines virtuelles, et il peut également être associé à plusieurs zones de stockage.
Il peut y avoir plusieurs centres de données ; ils fonctionnent indépendamment les uns des autres. Ovirt dispose d'une séparation des pouvoirs par rôle et vous pouvez configurer les autorisations individuellement, à la fois au niveau du centre de données et sur ses éléments logiques individuels.

Le ou les datacenters s'il y en a plusieurs sont gérés depuis une seule console d'administration ou un seul portail.

Pour créer un centre de données, rendez-vous sur le portail administratif et créez un nouveau centre de données :
calcul >> Centres de données >> Nouveauté

Puisque nous utilisons le stockage partagé sur le système de stockage, le type de stockage doit être Partagé :

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

Lors de l'installation d'une machine virtuelle avec moteur hébergé, un centre de données est créé par défaut - Centre de données1, puis, si nécessaire, vous pouvez modifier son type de stockage en un autre.

La création d'un centre de données est une tâche simple, sans aucune nuance délicate, et toutes les actions supplémentaires associées sont décrites dans la documentation. La seule chose que je noterai est que les hôtes uniques qui disposent uniquement d'un stockage local (disque) pour les machines virtuelles ne pourront pas accéder à un centre de données avec le type de stockage - Partagé (ils ne peuvent pas y être ajoutés), et pour eux, vous devez créer un centre de données séparé - c'est-à-dire Chaque hôte individuel disposant d'un stockage local a besoin de son propre centre de données distinct.

Créer un nouveau cluster

Lien vers la documentation - Guide d'administration oVirt. Chapitre 5 : Grappes

Sans détails inutiles, cluster – il s’agit d’un regroupement logique d’hôtes disposant d’une zone de stockage commune (sous forme de disques partagés sur un système de stockage, comme dans notre cas). Il est également souhaitable que les hôtes du cluster soient identiques en termes de matériel et disposent du même type de processeur (Intel ou AMD). Il est bien entendu préférable que les serveurs du cluster soient complètement identiques.

Le cluster fait partie d'un data center (avec un type de stockage spécifique - Lieu ou Owned), et tous les hôtes doivent appartenir à une sorte de cluster, selon qu'ils disposent ou non d'un stockage partagé.

Lors de l'installation d'une machine virtuelle avec un moteur hébergé sur un hôte, un centre de données est créé par défaut - Centre de données1, avec le cluster – Groupe1, et à l'avenir, vous pourrez configurer ses paramètres, activer des options supplémentaires, y ajouter des hôtes, etc.

Comme d'habitude, pour plus de détails sur tous les paramètres du cluster, il est conseillé de se référer à la documentation officielle. Parmi certaines fonctionnalités de configuration d'un cluster, j'ajouterai seulement que lors de sa création, il suffit de configurer uniquement les paramètres de base dans l'onglet Général.

Je noterai les paramètres les plus importants :

Type de processeur — est sélectionné en fonction des processeurs installés sur les hôtes du cluster, de leur fabricant et du processeur le plus ancien sur les hôtes, de sorte que, en fonction de cela, toutes les instructions de processeur disponibles dans le cluster soient utilisées.
Type de commutateur – dans notre cluster, nous utilisons uniquement le pont Linux, c’est pourquoi nous le choisissons.
Type de pare-feu – tout est clair ici, c'est 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 pour les documents.

Les hôtes supplémentaires pour un environnement auto-hébergé sont ajoutés de la même manière qu'un hôte standard, avec l'étape supplémentaire de déploiement d'une VM avec un moteur hébergé : Choisir l'action de déploiement du moteur hébergé >> Déployer. Puisque l'hôte supplémentaire doit également être présenté avec un LUN pour une VM avec un moteur hébergé, cela signifie que cet hôte peut, si nécessaire, être utilisé pour héberger une VM avec un moteur hébergé dessus.
À des fins de tolérance aux pannes, il est fortement recommandé de disposer d'au moins deux hôtes sur lesquels une machine virtuelle de moteur hébergée peut être placée.

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

systemctl stop iptables
systemctl disable iptables

systemctl enable firewalld
systemctl start firewalld

Installez la version KVM requise (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 référentiels nécessaires et le programme d'installation 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, allez dans la console Gestionnaire de virtualisation ouvert, ajoutez un nouvel hôte et faites tout étape par étape, comme écrit dans documentation.

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

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

L'hôte sur lequel la VM du moteur hébergé est actuellement active possède une couronne en or et l'inscription «Exécuter la VM du moteur hébergé", l'hôte sur lequel cette VM peut être lancée si nécessaire - l'inscription "Peut exécuter la VM du moteur hébergé».

En cas de panne d'hôte sur laquelle "Exécuter la VM du moteur hébergé", il redémarrera automatiquement sur le deuxième hôte. Cette VM peut également être migrée de l'hôte actif vers l'hôte de secours pour sa maintenance.

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

Liens vers les documents :

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

Même s'il peut sembler que vous avez fini d'ajouter et de configurer un hôte, ce n'est pas tout à fait vrai.
Pour le fonctionnement normal des hôtes et pour identifier/résoudre les pannes de l’un d’entre eux, des paramètres de gestion de l’alimentation/clôture sont requis.

Escrime, ou fencing, est le processus d'exclusion temporaire d'un hôte défectueux ou en panne du cluster, au cours duquel les services oVirt qui s'y trouvent ou l'hôte lui-même sont redémarrés.

Tous les détails sur les définitions et les paramètres de Power Management / fencing sont donnés, comme d'habitude, dans la documentation ; je donnerai seulement un exemple de configuration de ce paramètre important, tel qu'appliqué aux serveurs Dell R640 avec iDRAC 9.

Accédez au portail administratif, cliquez sur calcul >> Hôtes sélectionnez un hôte.
Cliquez ici Modifier.
Cliquez sur l'onglet Gestion de l'alimentation.
Cochez la case à côté de l'option Activer la gestion de l'alimentation.
Cochez la case à côté de l'option Intégration de Kdumppour empêcher l'hôte de passer en mode clôture lors de l'enregistrement d'un vidage sur incident du noyau.

Note.

Après avoir activé l'intégration de Kdump sur un hôte déjà en cours d'exécution, il doit être réinstallé selon la procédure dans le Guide d'administration oVirt -> Chapitre 7 : Hôtes -> Réinstallation des hôtes.

En option, vous pouvez cocher la case Désactiver le contrôle des politiques 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.
Cliquez sur le bouton (+) pour ajouter un nouveau périphérique de gestion de l'alimentation, la fenêtre d'édition des propriétés de l'agent s'ouvrira.
Pour iDRAC9, remplissez les champs :
- Adresse – Adresse iDRAC9
- Identifiant Mot de passe – identifiant et mot de passe pour se connecter à iDRAC9, respectivement
- Type —drac5
- marque Sécurisés
- ajoutez les options suivantes : cmd_prompt=>,login_timeout=30

Capture d'écran avec les paramètres « Power Management » 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 oVirt, Chapitre 8 : Stockage.

Domaine de stockage, ou zone de stockage, est un emplacement centralisé pour stocker les disques de machine virtuelle, les images d'installation, les modèles et les instantanés.

Les zones de stockage peuvent être connectées au centre de données à l'aide de divers protocoles, systèmes de fichiers en cluster et réseau.

oVirt dispose de trois types de zones de stockage :

Domaine de données – pour stocker toutes les données associées aux machines virtuelles (disques, modèles). Data Domain ne peut pas être partagé entre différents centres de données.
Domaine ISO (type de zone de stockage obsolète) – pour stocker les images d’installation du système d’exploitation. Le domaine ISO peut être partagé entre différents centres de données.
Exporter le domaine (type de zone de stockage obsolète) – pour le stockage temporaire des images déplacées entre les centres de données.

Dans notre cas particulier, une zone de stockage de type Data Domain utilise le protocole Fibre Channel (FCP) pour se connecter aux LUN du système de stockage.

Du point de vue d'oVirt, lors de l'utilisation de systèmes de stockage (FC ou iSCSI), chaque disque virtuel, instantané ou modèle est un disque logique.
Les périphériques blocs sont assemblés en une seule unité (sur les hôtes de cluster) à l'aide du groupe de volumes, puis divisés à l'aide de LVM en volumes logiques, qui sont utilisés comme disques virtuels pour les machines virtuelles.

Tous ces groupes et de nombreux volumes LVM peuvent être vus sur l'hôte du cluster à l'aide des commandes vg и lvs. Naturellement, toutes les actions avec de tels disques doivent être effectuées uniquement à partir de la console oVirt, sauf cas particuliers.

Les disques virtuels pour machines virtuelles peuvent être de deux types : QCOW2 ou RAW. Les disques peuvent être "mince"Ou"épais". Les instantanés sont toujours créés comme "mince".

La manière de gérer les domaines de stockage, ou les zones de stockage accessibles via FC, est tout à fait logique : pour chaque disque virtuel de VM, il existe un volume logique distinct qui n'est accessible en écriture que par un seul hôte. Pour les connexions FC, oVirt utilise quelque chose comme LVM en cluster.

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

Comme nous pouvons le voir dans la description, un cluster dans oVirt, comme un cluster dans VMware vSphere ou Hyper-V, signifie essentiellement la même chose : il s'agit d'un groupe logique d'hôtes, de préférence identiques en termes de composition matérielle, et ayant un stockage commun pour les serveurs virtuels. disques des machines.

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

selon documentation, allez sur le portail allez sur Stockage >> Domaines -> Nouveau domaine et suivez les instructions de la section « Ajout de stockage FCP ».

Après avoir lancé l'assistant, remplissez les champs obligatoires :

Nom — définir le nom du cluster
Fonction de domaine -Données
Type de stockage — Fibre Channel
Hôte à utiliser — sélectionnez un hôte sur lequel le LUN dont nous avons besoin est disponible

Dans la liste des LUN, marquez celui dont nous avons besoin, cliquez sur Ajouter puis OK. Si nécessaire, vous pouvez ajuster des paramètres supplémentaires de la zone de stockage en cliquant sur Paramètres avancés.

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

Sur la base des résultats de l'assistant, nous devrions recevoir une nouvelle zone de stockage et notre centre de données devrait passer au statut UP, ou initialisé :

Captures d'écran du centre de données et des zones de stockage qu'il contient :

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

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

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

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

Pour regrouper et diviser 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 faut lui attribuer un identifiant correspondant au numéro de VLAN sur le switch afin que les VM puissent communiquer entre elles, même si elles s'exécutent sur différents nœuds du cluster.

Les paramètres préliminaires des adaptateurs réseau sur les hôtes pour connecter des machines virtuelles devaient être effectués dans article précédent – interface logique configurée bondxnumx, alors tous les paramètres réseau doivent être effectués uniquement via le portail administratif oVirt.

Après avoir créé une VM avec moteur hébergé, en plus de la création automatique d'un centre de données et d'un cluster, un réseau logique a également été automatiquement créé pour gérer notre cluster - ovritmgmt, à laquelle cette VM était connectée.

Si nécessaire, vous pouvez afficher les paramètres du réseau logique ovritmgmt et ajustez-les, mais vous devez faire attention à ne pas perdre le contrôle de l'infrastructure oVirt.

Paramètres réseau logiques

Pour créer un nouveau réseau logique pour les machines virtuelles classiques, dans le portail d'administration, accédez à Réseau >> Réseaux >> Nouveauté, et sur l'onglet Général ajoutez un réseau avec l'ID VLAN souhaité, et cochez également la case à côté de "Réseau de machines virtuelles", cela signifie qu'il peut être utilisé pour l'affectation à une VM.

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

patte Grappe, nous attachons ce réseau à notre cluster Groupe1.

Après cela, nous allons à calcul >> Hôtes, allez sur chaque hôte tour à tour, dans l'onglet Interfaces réseau, et lancez l'assistant Configurer les réseaux hôtes, pour se lier aux hôtes d'un nouveau réseau logique.

Capture d'écran de l'assistant « Configuration des réseaux hôtes »

L'agent oVirt effectuera automatiquement tous les paramètres réseau nécessaires sur l'hôte - créera un VLAN et un BRIDGE.

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

cat ifcfg-bond1
# Generated by VDSM version 4.30.17.1
DEVICE=bond1
BONDING_OPTS='mode=1 miimon=100'
MACADDR=00:50:56:82:57:52
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-bond1.432
# Generated by VDSM version 4.30.17.1
DEVICE=bond1.432
VLAN=yes
BRIDGE=ovirtvm-vlan432
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

cat ifcfg-ovirtvm-vlan432
# Generated by VDSM version 4.30.17.1
DEVICE=ovirtvm-vlan432
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

Permettez-moi de vous rappeler encore une fois que sur l'hôte du cluster PAS BESOIN créer manuellement des interfaces réseau à l'avance ifcfg-bond1.432 и ifcfg-ovirtvm-vlan432.

Après avoir ajouté un réseau logique et vérifié la connexion entre l'hôte et la VM du 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 oVirt, Chapitre 8 : Stockage, section Téléchargement d'images vers un domaine de stockage de données.

Sans image d'installation du système d'exploitation, il ne sera pas possible d'installer une machine virtuelle, même si ce n'est bien sûr pas un problème si, par exemple, elle est installée sur le réseau Cobbler avec des images pré-créées.

Dans notre cas, cela n’est pas possible, vous devrez donc importer vous-même cette image dans oVirt. Auparavant, cela nécessitait la création d'un domaine ISO, mais dans la nouvelle version d'oVirt, il est obsolète et vous pouvez donc désormais télécharger des images directement sur le domaine de stockage à partir du portail d'administration.

Dans le portail administratif, allez sur Stockage >> disques >> Téléchargement >> Accueil
Nous ajoutons l'image de notre système d'exploitation sous forme de fichier ISO, remplissons tous les champs du formulaire et cliquons sur le bouton "Tester la connexion".

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

Si nous obtenons une erreur comme celle-ci :

Unable to upload image to disk d6d8fd10-c1e0-4f2d-af15-90f8e636dadc due to a network error. Ensure that ovirt-imageio-proxy service is installed and configured and that ovirt-engine's CA certificate is registered as a trusted CA in the browser. The certificate can be fetched from https://ovirt.test.local/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA`

Ensuite, vous devez ajouter le certificat oVirt à «Autorités de certification racine de confiance"(Trusted Root CA) sur la station de contrôle de l'administrateur, à partir de laquelle nous essayons de télécharger l'image.

Après avoir ajouté le certificat à la Trusted Root CA, cliquez à nouveau sur "Tester la connexion", devrait avoir:

Connection to ovirt-imageio-proxy was successful.

Une fois l'action d'ajout du certificat terminée, vous pouvez réessayer de télécharger l'image ISO sur le domaine de stockage.

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

Capture d'écran avec des images ISO dans Storage Domain pour le moteur hébergé

Créer une machine virtuelle

Lien vers les documents :
Guide de gestion des machines virtuelles oVirt -> Chapitre 2 : Installation de machines virtuelles Linux
Ressources des clients de console

Après avoir chargé l'image d'installation avec le système d'exploitation dans oVirt, vous pouvez procéder directement à la création d'une machine virtuelle. Beaucoup de travail a été fait, mais nous en sommes déjà à la dernière étape pour laquelle tout cela a été commencé : 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 de logiciel.

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

On va sur le portail administratif, on va sur calcul >> Machines virtuelleset lancez l'assistant de création de VM. Remplissez tous les paramètres et champs et cliquez sur OK. Tout est très simple si vous suivez la documentation.

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

Captures d'écran avec paramètres de VM hautement disponibles

Après avoir terminé le travail avec l'assistant, fermez-le, lancez une nouvelle VM et installez le système d'exploitation dessus.
Pour cela, rendez-vous sur la console de cette VM via le portail d'administration :

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

Pour vous connecter à la console VM, vous devez 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 vous connecter à la console VM, vous pouvez utiliser, par exemple, Visionneuse de machines virtuelles.

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

Après avoir installé l'OS 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 si le nœud du cluster sur lequel il s'exécute échoue, oVirt le 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 fins.

Conclusion

J'espère que cet article a réussi à faire comprendre qu'oVirt est un outil tout à fait normal de gestion d'infrastructure virtuelle, qui n'est pas si difficile à déployer - l'essentiel est de suivre certaines règles et exigences décrites à la fois dans l'article et dans la documentation.

En raison du grand volume de l'article, il n'a pas été possible d'y inclure beaucoup de choses, comme l'exécution étape par étape de divers assistants avec toutes les explications détaillées et les captures d'écran, les longues conclusions de certaines commandes, etc. En fait, cela nécessiterait d’écrire un livre entier, ce qui n’a pas beaucoup de sens en raison des nouvelles versions des logiciels qui apparaissent constamment avec des innovations et des changements. Le plus important est de comprendre le principe de fonctionnement de tout cela et d'obtenir un algorithme général pour créer une plate-forme tolérante aux pannes pour gérer les machines virtuelles.

Bien que nous ayons créé une infrastructure virtuelle, nous devons maintenant lui apprendre à interagir à la fois entre ses éléments individuels : hôtes, machines virtuelles, réseaux internes et avec le monde extérieur.

Ce processus est l'une des tâches principales d'un administrateur système ou réseau, qui sera abordée dans le prochain article - sur l'utilisation des routeurs virtuels VyOS dans l'infrastructure tolérante aux pannes de notre entreprise (comme vous l'avez deviné, ils fonctionneront comme des routeurs virtuels). machines sur notre cluster oVirt).

Source: habr.com

Création d'une infrastructure informatique tolérante aux pannes. Partie 2. Installation et configuration du cluster oVirt 4.3