Installation du clustering RHEV et des hyperviseurs RHEL - Partie 5

Dans cette partie, nous allons aborder quelques points importants liés à notre série RHEV. Dans la Partie 2 de cette série, nous avons discuté des déploiements et des installations de l'hyperviseur RHEV. Dans cette partie, nous aborderons d'autres façons d'installer l'hyperviseur RHEV.

La première méthode a été réalisée en utilisant un RHEVH dédié, personnalisé par RedHat lui-même sans aucune modification ni changement du côté de l'administrateur. Dans l'autre sens, nous utiliserons un serveur RHEL normal [Installation minimale] qui fera office d'hyperviseur RHEV.

Étape 1 : Ajouter l'hyperviseur RHEL à l'environnement

1. Installer le serveur RHEL6 abonné [Installation minimale]. Vous pouvez augmenter votre environnement virtuel en ajoutant un serveur RHEL6 supplémentaire souscrit [Installation minimale] qui fait office d'hyperviseur.

Spécification de la machine virtuelle

OS: RHEL6.6 x86_64
Number of processors: 2
Number of cores : 1
Memory : 3G
Network : vmnet3
I/O Controller : LSI Logic SAS
Virtual Disk : SCSI
Disk Size : 20G
IP: 11.0.0.7
Hostname: rhel.mydomain.org

et assurez-vous d'avoir coché l'option virtualisation dans les paramètres du processeur vm.

Astuce : Assurez-vous que votre système est abonné aux chaînes RedHat et à jour. Si vous ne savez pas comment vous abonner à la chaîne d'abonnement RedHat, vous pouvez lire l'article Activer le canal d'abonnement Red Hat.

Astuce : Pour économiser vos ressources, vous pouvez arrêter l'un des hyperviseurs actuellement opérationnels.

2. Pour transformer votre serveur en hyperviseur {utilisez-le comme hyperviseur}, vous devrez peut-être y installer l'agent RHEVM.

yum install vdsm

Une fois l'installation du package terminée, accédez à l'interface Web RHEVM pour l'ajouter.

3. Contrairement à l'hyperviseur RHEVH, vous pouvez ajouter l'hyperviseur RHEL d'une manière à partir de RHEM en utilisant les informations d'identification racine de l'hyperviseur RHEL. Ainsi, depuis rhevm WUI, passez à l'onglet Hôtes et cliquez sur nouveau.

Fournissez ensuite les informations de votre hôte comme indiqué.

Ensuite, ignorez l'avertissement Power mgmt et terminez, puis attendez quelques minutes et vérifiez l'état de l'hôte nouvellement ajouté.

Pour plus de détails sur l'ajout d'un hôte basé sur RHEL, consultez la documentation officielle RHEV de RedHat.

Étape 2 : Gestion du clustering RHEV

Le clustering dans RHEV décrit un groupe d'hôtes du même type de processeur partageant le même stockage [par ex. sur le réseau] et que vous utilisez pour effectuer une tâche spécifique [par ex. Haute disponibilité ]

Le clustering en général comporte de nombreuses tâches supplémentaires. Vous pouvez consulter l'article qui explique ce qu'est le clustering et ses avantages/inconvénients.

Le principal avantage du clustering dans RHEV est de permettre et de gérer la migration des machines virtuelles entre les hôtes appartenant au même cluster.

Alors, Comment les machines virtuelles migrent-elles entre les hôtes ?

RHEV a deux stratégies :

1. Migration en direct
2. Haute disponibilité

1. Migration en direct

Migration en direct utilisée dans une situation non critique, ce qui signifie que tout fonctionne correctement en général, mais vous devez effectuer certaines tâches d'équilibrage de charge (par exemple, vous avez constaté qu'un hôte est chargé par une machine virtuelle sur un autre. Donc, vous Live peut migrer la machine virtuelle d'un hôte à un autre pour réaliser l'équilibrage de charge).

Remarque : il n'y a aucune interruption des services, des applications ou des utilisateurs exécutés dans la VM pendant la migration dynamique. La migration en direct est également appelée réallocation des ressources.

La migration dynamique peut être traitée manuellement ou automatiquement selon une politique prédéfinie :

1. Manuellement : forcez la sélection de l'hôte de destination, puis migrez la VM vers celui-ci manuellement à l'aide de WUI.
2. Automatique : utilisation de l'une des politiques de cluster pour gérer la migration dynamique en fonction de l'utilisation de la RAM, de l'utilisation du processeur, etc.

Basculez vers l'onglet Clusters et sélectionnez Cluster1 puis cliquez sur Modifier.

Dans les onglets de la fenêtre, accédez à l'onglet Politique de cluster.

Sélectionnez la stratégie evenly_distributed. Cette stratégie vous permet de configurer le seuil maximum d'utilisation du processeur sur l'hôte et le temps autorisé pour le chargement avant de démarrer la migration Live.

Indice

Comme indiqué, j'ai configuré le seuil maximum sur 50 % et la durée sur 1 min.

Ensuite, OK et passez à l'onglet VM.

Sélectionnez Linux vm [Précédemment créé] puis cliquez sur modifier et vérifiez ces points.

1. Depuis l'onglet Hôte : vérifiez que la migration en direct manuelle et automatique est autorisée pour cette VM.

2. Depuis l'onglet HA : Vérifiez le degré de Priorité de votre machine virtuelle. Dans notre cas, ce n’est pas très important puisque nous jouons avec une seule VM. Mais il sera important de définir des priorités pour vos machines virtuelles dans un environnement étendu.

Ensuite, démarrez la machine virtuelle Linux.

Tout d’abord, nous utiliserons la Migration manuelle en direct. La VM Linux fonctionne désormais sur rhel.mydomain.org.

Exécutons la commande suivante sur la console vm, avant de démarrer la migration.

ls -lRZ / 

Sélectionnez ensuite Machine virtuelle Linux et cliquez sur Migrer.

Si vous sélectionnez automatiquement, le système vérifiera que l'hôte le plus responsable est la destination dans le cadre de la politique de cluster. Nous testerons cela sans aucune interférence de l'administrateur.

Ainsi, après avoir sélectionné manuellement et choisi la destination, cliquez sur OK, accédez à la console et surveillez la commande en cours d'exécution. Vous pouvez également vérifier l'état de la machine virtuelle.

Vous devrez peut-être surveiller les événements de tâches.

Après quelques secondes, vous constaterez un changement dans le nom d'hôte de la machine virtuelle.

Votre VM a été migrée manuellement en direct avec succès !!

Essayons la migration en direct automatique, notre objectif est de faire en sorte que la charge CPU sur l'hôte rhevhn1 dépasse 50 %. Nous ferons cela en augmentant la charge sur la machine virtuelle elle-même, donc depuis la console, écrivez cette commande :

dd if=/dev/urandom of=/dev/null

et surveillez la charge sur l'hôte.

Après quelques minutes, la charge sur l'hôte dépassera 50 %.

Attendez encore quelques minutes, puis la migration en direct démarrera automatiquement comme indiqué.

Vous pouvez également consulter l'onglet Tâches, et après peu d'attente, votre machine virtuelle est automatiquement migrée en direct vers rhel Host.

Important : Assurez-vous que l'un de vos hôtes dispose de plus de ressources que l'autre. Si les deux hôtes sont identiques en ressources. La VM ne sera pas migrée car il n'y aura aucune différence !!

Astuce : Mettre l'hôte en Mode de maintenance entraînera automatiquement la migration en direct des machines virtuelles opérationnelles vers d'autres hôtes du même cluster.

Pour plus d'informations sur les migrations de machines virtuelles, lisez Migration de machines virtuelles entre hôtes.

Astuce : La migration en direct entre différents clusters n'est pas officiellement prise en charge, sauf dans un cas, vous pouvez le vérifier ici.

2. Haute disponibilité

Contrairement à la Live Migration, la HA est utilisée pour couvrir les situations critiques et pas seulement pour les tâches d'équilibrage de charge. La section commune dans laquelle votre VM sera également migrée vers un autre hôte mais avec un temps d'arrêt de redémarrage.

Si vous avez un hôte en panne, non opérationnel ou qui ne répond pas dans votre cluster, Live Migration ne peut pas vous aider. HA mettra hors tension la machine virtuelle et la redémarrera sur un autre hôte opérationnel dans le même cluster.

Pour Activer la haute disponibilité dans votre environnement, vous devez disposer d'au moins un périphérique de gestion de l'alimentation [par ex. interrupteur d'alimentation] dans votre environnement.

Malheureusement, nous ne sommes pas en mesure de le faire dans notre environnement virtuel. Donc, pour en savoir plus sur la haute disponibilité dans RHEV, veuillez consulter Améliorer la disponibilité avec la haute disponibilité des VM.

Rappelez-vous : La migration dynamique et la haute disponibilité fonctionnent avec des hôtes du même cluster dotés du même type de processeur et connectés au stockage partagé.

Conclusion:

Nous avons atteint le point culminant de notre série en discutant de l'une des fonctionnalités importantes du clustering RHEV telle que nous l'avons décrite et de son importance. Nous avons également discuté du deuxième type de [méthode] pour déployer des hyperviseurs RHEV basés sur RHEL [au moins 6.6 x86_64].

Dans le prochain article, nous pourrons effectuer certaines opérations sur les machines virtuelles telles que les instantanés, le scellement, le clonage, l'exportation et les pools.