Les administrateurs systèmes partagent le désagrément de l'important travail d'essai et de qualification qu'ils doivent accomplir lorsqu'une nouvelle version du système d'exploitation de base est introduite. Les avantages du nouveau logiciel peuvent être très minimes pour la majorité des applications, mais peuvent s'avérer indispensables pour accueillir une application ou une nouvelle option matérielle.

La virtualisation permet d'échapper à ce problème de taille. La pile existante peut continuer à fonctionner telle quelle en tant qu'hôte dans une machine virtuelle, tandis que l'hyperviseur le plus récent prend tranquillement en charge le nouveau matériel et apporte tous les avantages de la fiabilité et de la performance. Les quelques applications qui nécessitent la nouvelle version du système d'exploitation peuvent être exécutées sur une autre machine virtuelle dotée de la dernière version.

Cela signifie que les mises à niveau peuvent n'être réalisées que lorsque les administrateurs système le souhaitent. Ils n'auront plus jamais à subir contraints et forcés une mise à niveau logicielle imprévue et coûteuse.

• Regarder la vidéo : Éviter les mises à niveau précipitées

Alors qu'un système uniquement utilisé pour une application peut être solidement verrouillé, de nombreux systèmes ont aujourd'hui un accès partagé et il est important de garantir le maintien de la confidentialité.

La virtualisation permet à chaque application et à chaque ensemble de données d'être placé dans une machine virtuelle distincte. On retrouve ici de nombreux avantages liés au verrouillage de chaque système physique tout en échappant à la prolifération de matériel. La virtualisation isole chaque hôte, qui est ainsi moins exposé à un partage non voulu. Toute attaque réussie se limite au seul hôte qui en a été victime. En ajoutant SELinux et Red Hat Identity Management, il est possible d'atteindre un haut niveau d'isolation d'utilisateur et de données, sans nécessité d'utiliser des serveurs distincts pour chaque utilisateur.

Le développement logiciel nécessite un long cycle ponctué de nombreuses itérations de codage, de débogage et de test. Dans le passé, le débogage et les tests devaient souvent avoir lieu sur de nombreux systèmes distincts. Il a été difficile de construire les réseaux et ensembles de données plus étendus qui étaient nécessaires aux tests. La virtualisation offre un certain nombre de solutions.

Les développeurs peuvent disposer de machines virtuelles individuelles qu'ils peuvent démarrer ou arrêter sans qu'elles n'impactent les unes sur les autres. Ils n'ont plus besoin de disposer de machines physiques individuelles. Cela permet un bien meilleur débogage des codes, y compris les codes de kernel.

Les machines virtuelles pouvant être démarrées, arrêtées et modifiées plus facilement et plus rapidement, il est possible d'automatiser une grande série de tests de régression. Les scripts peuvent approvisionner différentes versions d'applications et de systèmes d'exploitation, exécuter des ensembles de données connus contre ces derniers, noter et rapporter les résultats. Si un système est mort, le script peut détecter cet état de fait, car seul l'invité aura subi le crash et pas le DOM 0 de base.

Lorsque de grandes séries de systèmes doivent être utilisées, plusieurs hôtes en réseau peuvent être évoqués et peuvent simuler un réseau physique étendu avec un petit nombre de serveurs physiques. Ceci peut permettre de réaliser les tests d'évolutivité qui sont rarement menés aujourd'hui. En effet, pendant les heures d'arrêt, les cycles supplémentaires des machines de production inutilisées peuvent également être utilisés pour les tests de façon sécurisée, grâce aux dispositifs de sécurité et coupe-feu de chaque hôte.

La migration dynamique permet la migration d'hôtes para-virtualisés sur Red Hat Enterprise Linux Version 5 depuis un serveur physique vers un autre serveur du réseau. Lorsque l'hôte reçoit l'ordre de se déplacer (de la part d'un programme ou d'un administrateur système utilisant des outils de gestion Red Hat Enterprise Linux standard), l'hyperviseur présent sur le système de départ travaille avec l'hyperviseur du système d'arrivée afin de préparer suffisamment de mémoire pour supporter l'hôte en cours de migration. La mémoire est alors copiée via le réseau jusqu'à ne laisser que la mémoire « à chaud ». Puisque l'hôte de la machine de départ exécute et sert toujours les hôtes, nous définissons la mémoire « à chaud » comme la mémoire utilisée de façon active. L'hyperviseur de départ interrompt alors l'hôte et copie la mémoire à chaud restante. Suite à cela, l'hyperviseur de la machine d'arrivée obtient l'exécution de l'hôte. Puisque la totalité du réseau et des connexions E/S sont maintenues dans la mémoire copiée, toutes ces connexions sont persistantes et, malgré une brève pause ( < 200 ms), le travail se poursuit pour servir les clients. Notez que les systèmes doivent se trouver sur le même sous-réseau pour que le connecteur réseau persiste et doivent être dotés d'un stockage commun pour que les fichiers ouverts persistent. Il est inutile d'utiliser un gestionnaire de verrouillage et les protocoles iSCSI, GNBD ou SAN fonctionneront sans problème.

La migration dynamique est réalisée pour de nombreuses raisons.

1. Un hôte est utilisé de façon si intensive qu'il convient soit de le faire migrer vers une autre machine, soit de faire migrer d'autres hôtes se trouvant sur la même machine afin de libérer davantage de ressources pour cet hôte très occupé.
2. Un système commence à générer des avertissements pour des erreurs logicielles de mémoire, des alertes de surchauffe ou autres indications de panne imminente. Les hôtes peuvent être retirés du serveur et subir une migration avant leur extinction, et le serveur peut être libéré pour la maintenance.
3. Pour préparer l'accueil d'un important flux de données par lot, comme cela est courant avec certains ERP ou financeruns, les hôtes peuvent être déplacés depuis un serveur pour fournir des capacités. De la même façon, les hôtes peuvent être regroupés sur un petit nombre de machines afin que les capacités en excès puissent être retirées de la ligne pour économiser l'énergie.

• Regarder la vidéo : Fixer les serveurs de façon cohérente

Une bonne raison pour créer un grand nombre d'hôtes et exécuter peu de fonctions pour chaque hôte est de minimiser l'effet domino d'un crash. Souvent, si le travail situé sur un système SMP de grande taille subit un crash, il est probable que chaque concentrateur situé sur ce système subira un crash ou une interruption. Avec la virtualisation Red Hat, chaque fonction peut être placée dans son hôte propre. En cas de panne ou de problème de sécurité, il n'y aura donc pas de propagation et seul l'hôte victime sera impacté. En utilisant la migration et le logiciel de grappe HA de façon intelligente, il est facile de garder à disposition des instances de sauvegarde qui sont prêtes à être installées sur d'autres machines en cas de problème avec un hôte ou une charge de travail.