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éparer le déploiement du cluster oVirt 4.3 . »

Il examinera le processus d'installation et de configuration de base du cluster oVirt 4.3 pour l'hébergement de machines virtuelles hautement accessibles, en tenant compte du fait que toutes les étapes préliminaires de préparation de l'infrastructure sont déjà terminées.

Présentation

L'objectif principal de l'article n'est pas de donner des instructions pas à pas du formulaire « Suivant -> Oui -> Terminer », mais de montrer 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 particularités 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 est similaire en fonctionnalités à VMware vSphere version 5.x, mais bien sûr avec ses propres fonctionnalités de configuration et de fonctionnement.

Pour ceux qui sont intéressés, toutes les différences entre RHEV (aka oVirt) et VMware vSphere peuvent être trouvées sur Internet, par exemple ici , mais je noterai occasionnellement certaines de leurs différences ou similitudes, comme le dit l'article.

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

• en utilisant le pont Linux standard (dans VMware - vSwitch standard ) exécuté sur des hôtes de virtualisation;
• L'utilisation d'Open vSwitch (OVS) (dans VMware, Distributed vSwitch ) est un commutateur virtuel distribué qui se compose 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 simplicité de mise en œuvre, l'article décrira la configuration réseau dans oVirt pour les machines virtuelles à l'aide du 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 un réseau dans un cluster qu'il vaut mieux ne pas violer:

• Tous les paramètres réseau sur les hôtes doivent être identiques avant de les ajouter à oVirt, à l'exception des adresses IP.
• Une fois que l'hôte est pris sous le contrôle de oVirt, il est fortement déconseillé de modifier quelque chose dans les paramètres réseau avec vos mains, sans une confiance totale dans vos actions, car l'agent oVirt les ramènera simplement aux précédents, après avoir redémarré l'hôte ou l'agent.
• L'ajout d'un nouveau réseau pour la machine virtuelle, ainsi que l'utilisation de celui-ci, doivent être effectués uniquement à partir de la console de gestion oVirt.

Autre point important - pour un environnement très critique (très sensible aux pertes d'argent), il serait toujours recommandé d'utiliser un support payant et d'utiliser Red Hat Virtualization 4.3 . Pendant le fonctionnement du cluster oVirt, il peut y avoir certains points sur lesquels il est conseillé d'obtenir une aide qualifiée dès que possible, plutôt que de les traiter vous-même.

Et enfin, il est recommandé qu'avant de déployer le cluster oVirt, familiarisez-vous avec la documentation officielle afin de connaître au moins les concepts et définitions de base, sinon il sera un peu difficile de lire l'article plus loin.

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

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

Le volume là-bas n'est pas très important, en une heure ou deux, il est tout à fait possible de maîtriser les principes de base, et pour les fans de détails, il est recommandé de lire la documentation produit de Red Hat Virtualization 4.3 - RHEV et oVirt sont essentiellement la même chose.

Donc, si tous les paramètres de base sur les hôtes, les commutateurs et le stockage sont terminés, nous procédons directement au déploiement de 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 à tour de rôle:

1. Installation du serveur de gestion oVirt
2. Création d'un nouveau centre de données
3. Créer un nouveau cluster
4. Installation d'hôtes supplémentaires dans un environnement auto-hébergé
5. Créer une zone de stockage ou des domaines de stockage
6. Créer et configurer des réseaux pour des 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 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'intégralité de l'infrastructure oVirt.

Ses analogues proches du monde de la virtualisation:

• 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éploiement d'un serveur en tant que machine virtuelle ou hôte spécialisé.

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

Pourquoi ne pouvez-vous pas déployer une telle machine virtuelle sur les hôtes de cluster?

Au tout début du processus de déploiement du serveur de gestion oVirt, nous avons un dilemme: vous devez installer la machine virtuelle de gestion, mais le cluster lui-même n'est pas encore réellement, et donc, que pouvez-vous trouver tout de suite? Il est juste d'installer KVM sur le futur nœud de cluster, puis de créer une machine virtuelle sur celui-ci, par exemple, avec CentOS OS et d'y déployer le moteur oVirt. Cela peut généralement être fait pour des raisons de contrôle complet sur une telle machine virtuelle, mais c'est une intention erronée, car dans ce cas, à l'avenir, il y aura 100% de problèmes avec une telle machine virtuelle 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 des outils KVM via virsh migrate , cette machine virtuelle sera inaccessible à la gestion depuis la console oVirt.
• les hôtes de cluster ne peuvent pas être mis en mode Maintenance si vous migrez cette machine virtuelle d'hôte à hôte à l'aide de virsh migrate .

Faites donc tout selon les règles - utilisez un hôte séparé ou une machine virtuelle indépendante exécutée sur celui-ci pour le serveur de contrôle oVirt, ou plutôt faites comme il est écrit dans la deuxième version.

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

C'est cette option qui sera considérée ci-dessous, comme plus correcte et adaptée dans notre cas.
Les exigences pour une telle machine virtuelle sont décrites ci-dessous. J'ajouterai seulement qu'il est recommandé d'avoir au moins deux hôtes dans l'infrastructure sur laquelle la machine virtuelle de gestion peut être exécutée pour 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 pas pu obtenir splitbrain sur le cluster oVirt à partir de deux hôtes, avec la possibilité d'exécuter la machine virtuelle du moteur hébergé sur eux.

Installer oVirt Engine Appliance sur le premier hôte de 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 indique les conditions préalables qui doivent être remplies avant de déployer la machine virtuelle du moteur hébergé, ainsi que le processus d'installation est décrit en détail, donc le répéter mot pour mot n'a pas beaucoup de sens, nous nous concentrons donc sur certains détails importants.

• Avant de commencer toutes les étapes, assurez-vous d'activer la prise en charge de la virtualisation dans les paramètres du BIOS sur l'hôte.
• Installez le package 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 commençons la procédure de déploiement de oVirt Hosted Engine dans l'écran de l'hôte (vous pouvez le quitter via Ctrl-A + D, le fermer via Ctrl-D):

 screen hosted-engine --deploy 

Si vous le souhaitez, vous pouvez démarrer l'installation avec un fichier de réponses 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é, spécifiez tous les paramètres nécessaires:

 -   -  vCPU  vRAM ( 4 vCPU  16 ) -  -    hosted engine  –    FC -  LUN   hosted engine -       hosted engine –     Local (  PostgreSQL    )  . . 

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

Plus tôt, nous avons é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 du moteur hébergé lui-même ne comporte rien de compliqué, à la fin, nous devrions obtenir 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 

Si tout a été fait correctement, une fois l'installation terminée, accédez à https: // ovirt_hostname / ovirt-engine depuis l'ordinateur de l'administrateur à l'aide d'un navigateur Web et cliquez sur [ Administration Portal ].

Après avoir entré le login et le mot de passe (définis lors de l'installation) dans la fenêtre comme dans la capture d'écran, nous arrivons au panneau de configuration d'Open Virtualization Manager, dans lequel vous pouvez effectuer toutes les actions avec 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 zones de stockage ou des domaines de stockage pour les disques de machine virtuelle
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 tard, quelque chose dans une grande cellule, quelque chose de plus en détail et avec des nuances.
Mais d'abord, je recommanderais de lire ce module complémentaire, dont beaucoup peuvent être utiles.

Addition

1) En principe, s'il y a un tel besoin, rien ne vous empêche de pré-installer l'hyperviseur KVM sur les nœuds de cluster à l'aide des packages libvirt et qemu-kvm (ou qemu-kvm-ev ) de la version souhaitée, bien que lors du déploiement du nœud de cluster oVirt, il puisse faites-le vous-même.

Mais si libvirt et qemu-kvm n'ont pas été installés avec la dernière version, vous pouvez obtenir une telle erreur lors du déploiement du moteur hébergé:

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

C'est-à-dire vous devez avoir une version mise à jour de libvirt avec protection MDS qui prend en charge 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 

 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 à installer le moteur hébergé.

2) Dans oVirt 4.3, la présence et l'utilisation du pare - feu firewalld est une condition préalable.

 [ 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é), installer et exécuter le 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 automatiquement les ports requis dans firewalld .

3) Redémarrage d'un hôte avec une machine virtuelle en cours d'exécution avec un moteur hébergé.

Comme d'habitude, référence 1 et référence 2 aux documents d'orientation.

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

 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 moteur hébergé et faisons ce dont nous avons besoin.

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

 hosted-engine --vm-status 

Si notre machine virtuelle avec moteur hébergé ne démarre pas et si nous voyons des erreurs similaires 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 machine virtuelle avec le moteur hébergé, nous la supprimons du mode de 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 s'y rapporte.

Parfois, il peut être nécessaire de supprimer correctement un moteur hébergé précédemment installé - un lien vers un document d'orientation.

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

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

Ensuite, supprimez 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

Tout d'abord, nous définissons ce qu'est un centre de données (je cite l'aide) - il s'agit d'une entité logique qui définit un ensemble de ressources utilisées dans un environnement spécifique.

Un centre de données est un type de conteneur composé de:

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

Un centre de données peut comprendre plusieurs clusters constitués de plusieurs hôtes sur lesquels s'exécutent des machines virtuelles, 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 a une séparation des pouvoirs par rôle, et vous pouvez configurer les autorisations personnellement, à la fois au niveau du centre de données et sur ses éléments logiques individuels.

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

Pour créer un centre de données, accédez au portail d'administration et créez un nouveau centre de données:
Calculer >> Centres de données >> Nouveau

Étant donné que nous utilisons le stockage partagé sur le système de stockage, le type de stockage doit être partagé:

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

La création d'un centre de données est une tâche simple, sans nuances délicates, et toutes les actions supplémentaires avec celui-ci sont décrites dans la documentation. Je noterai seulement que les hôtes uniques qui n'ont que du stockage local (disque) pour la machine virtuelle ne peuvent pas entrer dans le centre de données avec le type de stockage - partagé (vous ne pouvez pas les ajouter là-bas), et pour eux, vous devez créer un centre de données distinct - c'est-à-dire chaque hôte individuel avec stockage local a besoin de son propre centre de données distinct.

Créer un nouveau cluster

Lien de documentation - Guide d'administration oVirt. Chapitre 5: Clusters

Sans détails inutiles, un cluster est un regroupement logique d'hôtes qui ont une zone de stockage commune (sous la forme de lecteurs 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 matériel et aient le même type de processeur (Intel ou AMD). Il est bien sûr préférable que les serveurs du cluster soient complètement identiques.

Le cluster fait partie du centre de données (avec un type de stockage spécifique - local ou partagé ), et tous les hôtes doivent nécessairement appartenir à un cluster, selon qu'ils disposent ou non d'un stockage commun.

Lors de l'installation d'une machine virtuelle avec moteur hébergé sur l'hôte, par défaut, un centre de données est créé - Datacenter1 , avec un cluster - Cluster1 , et à l'avenir, vous pouvez 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 la configuration du cluster, j'ajouterai seulement que lors de sa création, il suffit de configurer uniquement les paramètres de base de l'onglet Général .

Je noterai les paramètres les plus importants:

• Type de processeur - il est sélectionné en fonction des processeurs installés sur les hôtes du cluster, de quel fabricant ils sont et du processeur sur les hôtes le plus ancien afin que, selon cela, toutes les instructions de processeur disponibles dans le cluster soient utilisées.
• Type de commutateur - dans notre cluster, nous utilisons uniquement un pont Linux, nous le sélectionnons donc.
• Type de pare-feu - tout est clair ici, c'est firewalld, qui doit être activé et configuré sur les hôtes.

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

Lien vers la documentation.

Des hôtes supplémentaires pour l'environnement auto-hébergé sont ajoutés de la même manière qu'un hôte standard, avec le point supplémentaire pour le déploiement d'une machine virtuelle avec un moteur hébergé - Choisissez l'action de déploiement du moteur hébergé >> Déployer . Étant donné que le LUN de la machine virtuelle avec le moteur hébergé doit également être présenté à l'hôte supplémentaire, cela signifie que cet hôte peut être utilisé si nécessaire pour héberger la machine virtuelle avec le moteur hébergé sur celui-ci.
Pour la tolérance aux pannes, il est fortement recommandé qu'il existe au moins deux hôtes sur lesquels une machine virtuelle de moteur hébergée peut être hébergée.

Sur l'hôte supplémentaire, désactivez iptables (si activé), activez le pare-feu

 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 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, accédez à la console Open Virtualization Manager , ajoutez un nouvel hôte et faites tout étape par étape, comme cela est écrit dans la documentation .

Par conséquent, après avoir ajouté un hôte supplémentaire, nous devrions obtenir environ une image dans la console d'administration, comme dans la capture d'écran.

L'hôte sur lequel la machine virtuelle hébergée est actuellement active a une couronne en or et l'inscription « Running the Hosted Engine VM », l'hôte sur lequel cette machine virtuelle peut être exécutée si nécessaire est l'inscription « Can run the Hosted Engine VM ».

En cas de défaillance d'un hôte sur lequel " Exécution de la machine virtuelle du moteur hébergé ", il redémarrera automatiquement sur le deuxième hôte. En outre, cette machine virtuelle peut être migrée de l'hôte actif vers celui de sauvegarde, pour sa maintenance.

Configurer la gestion de l'alimentation / l'escrime sur les hôtes oVirt

Liens de documentation:

• Red Hat Virtualization 4.3 -> Référence technique -> Chapitre 4. Gestion de l'alimentation
• Guide d'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 entièrement vrai.
Pour le fonctionnement normal des hôtes et l'identification / l'élimination des pannes avec l'un d'entre eux, le paramètre Gestion de l'alimentation / clôture est requis.

L'escrime , ou boîtier, est le processus d'exclusion temporaire d'un hôte défaillant ou défaillant d'un cluster, au cours duquel les services oVirt sur celui-ci ou l'hôte lui-même sont redémarrés.

Tous les détails sur les définitions et les paramètres de gestion de l'alimentation / clôture sont donnés, comme d'habitude dans la documentation, je ne donnerai qu'un exemple de la façon de configurer ce paramètre important lorsqu'il est appliqué aux serveurs Dell R640 avec iDRAC 9.

1. Nous allons dans le portail administratif, cliquez sur Calculer >> Hôtes, sélectionnez l'hôte.
2. Cliquez sur Modifier .
3. Cliquez sur l'onglet Gestion de l' alimentation .
4. Cochez la case en regard de l'option Activer la gestion de l'alimentation .
5. Nous cochons la case à côté de l'option d' intégration de Kdump afin que l'hôte ne passe pas en mode d'escrime lors de l'écriture d'un vidage sur incident du noyau.

1. Facultativement, vous pouvez 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. Cliquez sur le bouton ( + ) pour ajouter un nouveau dispositif de gestion de l'alimentation, la fenêtre de modification des propriétés de l'agent s'ouvrira.
   Pour iDRAC9, remplissez les champs:
   
   • Adresse - adresse iDRAC9
   • Nom d'utilisateur / mot de passe - respectivement identifiant et mot de passe pour entrer dans iDRAC9
   • Type - drac5
   • marque Secure
   • ajoutez les options suivantes: cmd_prompt =>, login_timeout = 30

Créer une zone de stockage ou des domaines de stockage

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

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

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

OVirt dispose de trois types de zones de stockage:

• Data Domain - 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.
• Domaine d'exportation (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, un domaine 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 de oVirt, lorsque vous utilisez des systèmes de stockage (FC ou iSCSI), chaque disque virtuel, instantané ou modèle est un disque logique.
Les périphériques de bloc 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 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 vgs et lvs . Naturellement, toutes les actions avec de tels disques doivent être effectuées uniquement à partir de la console oVirt, sauf dans des cas particuliers.

Les disques virtuels pour machines virtuelles peuvent être de deux types - QCOW2 ou RAW. Les disques peuvent être minces ou épais . Les instantanés sont toujours créés aussi fins .

La façon de gérer les domaines de stockage ou les zones de stockage accessibles via FC est assez logique - pour chaque disque virtuel d'une machine virtuelle, il existe un volume logique distinct qui n'est accessible en écriture que sur un seul hôte. Dans le cas de connexions via 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 vous pouvez le voir dans la description, le cluster dans oVirt, comme le cluster dans VMware vSphere ou Hyper-V, signifie essentiellement la même chose - il s'agit d'un regroupement logique d'hôtes, de préférence identiques en matériel, et ayant un stockage commun pour les disques de machines virtuelles.

Nous procédons 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é.
Permettez-moi de vous rappeler que tous les LUN présentés aux hôtes du cluster sur le stockage doivent leur être visibles à l'aide de la commande " multipath -ll ".

Selon la documentation , accédez au portail, accédez à Stockage >> Domaines -> Nouveau domaine et suivez les instructions de la section "Ajout de stockage FCP".

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

• Nom - définissez le nom du cluster
• Fonction de domaine - Données
• Type de stockage - Fibre Channel
• Hôte à utiliser : sélectionnez l'hôte sur lequel le LUN requis est disponible.

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

Selon les résultats de l'assistant, nous devrions obtenir une nouvelle zone de stockage et notre centre de données devrait passer à l'état UP ou initialisé:

Créer et configurer des réseaux pour des machines virtuelles

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

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

Les interfaces logiques telles que le pont Linux sont utilisées pour interagir avec une carte réseau dans une machine virtuelle, avec une carte physique sur l'hôte.

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

oVirt, , VLAN , , .

– bond1 , oVirt.

hosted-engine, , – ovritmgmt , .

ovritmgmt , , oVirt.

, Network >> Networks >> New , General VLAN, « VM Network », .

Cluster , Cluster1 .

Compute >> Hosts , , Network interfaces , Setup host networks , .

oVirt – VLAN BRIDGE.

 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 

, ifcfg-bond1.432 ifcfg-ovirtvm-vlan432 .

c hosted engine, .

— oVirt Administration Guide, Chapter 8: Storage , Uploading Images to a Data Storage Domain.

, , , , , Cobbler .

, oVirt. , ISO Domain, oVirt , Storage domain .

Storage >> Disks >> Upload >> Start
ISO , , " Test connection ".

oVirt « » (Trusted Root CA) , .

Trusted Root CA, " Test connection ", :

 Connection to ovirt-imageio-proxy was successful. 

, ISO Storage Domain.

, Storage Domain Data, , Storage Domain hosted engine, .

:
oVirt Virtual Machine Management Guide –> Chapter 2: Installing Linux Virtual Machines
Console Clients Resources

oVirt , . , , – . – - , .

CentOS 7, .

, Compute >> Virtual Machines , . , . , .

, , , , :

, , .
:

, .

, , Virtual Machine Viewer .

, :

, oVirt guest agent:

 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 

, , , .. , , oVirt . , .

Conclusion

, , oVirt – , — , , .

- , , - , .. , , - . – , , .

, : , , , .

, — VyOS ( , oVirt).