Un hyperviseur est une combinaison de logiciels, de matériel ou de firmware qui crée, exécute et gère des machines virtuelles (VM). L’ordinateur qui exécute un hyperviseur est connu comme son hôte, tandis que chaque VM sur l’hôte est connue comme un invité. Un hyperviseur fournit aux invités une plate-forme d’exploitation virtuelle qui gère leurs systèmes d’exploitation (OS), permettant à plusieurs OS de partager des ressources virtualisées sur le même hôte.
La possibilité de partager des ressources est l’une des raisons les plus significatives pour une entreprise de mettre en œuvre des hyperviseurs. Cependant, la variété des hyperviseurs actuellement disponibles peut rendre ce processus de décision difficile. La sélection d’un hyperviseur se résume souvent à un choix entre VMware et KVM (Kernel-based Virtual Machine). VMware est le nom d’une société qui développe une gamme d’hyperviseurs, dont l’ESXi de classe entreprise. KVM est une infrastructure pour le noyau Linux qui lui fournit les capacités d’un hyperviseur.
Les points de comparaison suivants peuvent aider les organisations qui ont besoin d’un hyperviseur à choisir entre VMware et KVM.
- Performance
- Intégration
- Coût
- Complexité
- Maturité
- Scalabilité
- Support des fonctionnalités
Aperçu
Un hyperviseur virtualise un environnement informatique, ce qui signifie que les invités de cet environnement partagent des ressources physiques telles que la capacité de traitement, la mémoire et le stockage englobant un nuage privé. Chaque invité exécute son propre système d’exploitation, ce qui lui donne l’impression de disposer de ses propres ressources, même si ce n’est pas le cas. Le partage efficace des ressources nécessite que le processeur physique prenne en charge la virtualisation, qui est appelée AMD-V pour les processeurs AMD et VT-x pour les processeurs Intel.
Un hyperviseur doit isoler efficacement chaque invité, de sorte que le fonctionnement d’un invité ne puisse pas affecter les autres invités fonctionnant sur l’hôte. Cette exigence signifie qu’un hyperviseur doit émuler avec précision le matériel physique pour empêcher les invités d’y accéder, sauf dans des circonstances soigneusement contrôlées. La méthode qu’un hyperviseur utilise pour ce faire est un facteur clé de ses performances.
Les hyperviseurs utilisent souvent des pilotes « paravirtualisés » (PV) pour émuler le matériel physique, qui agissent comme du matériel tel que les disques de stockage et les cartes réseau. Ces pilotes sont spécifiques au système d’exploitation et souvent spécifiques à un hyperviseur particulier. Les pilotes PV peuvent améliorer les performances d’un hyperviseur d’un ordre de grandeur.
Performance
Les hyperviseurs peuvent être classés en deux types, ce qui peut avoir un impact sur leurs performances. Les hyperviseurs de type 1, également appelés hyperviseurs » bare metal « , s’exécutent directement sur le matériel physique, et le système d’exploitation de chaque invité s’exécute au-dessus de l’hyperviseur. Ces hyperviseurs permettent généralement à certains invités de contrôler l’hyperviseur. La plupart des entreprises utilisent des hyperviseurs de type 1.
Un hyperviseur de type 2, également connu sous le nom d’hyperviseur hébergé, s’exécute au sein d’un OS qui s’exécute sur le matériel physique. Le système d’exploitation de chaque invité s’exécute alors au-dessus de l’hyperviseur. Les hyperviseurs de bureau sont généralement des hyperviseurs de type 2.
Xen est probablement le meilleur exemple d’un pur hyperviseur de type 1, même si ESXi est clairement un hyperviseur de type 1 également, car il ne s’agit pas d’une application installée sur un OS. ESXi comprend un noyau et d’autres composants d’OS qu’il intègre dans l’OS natif.
La classification de KVM est plus difficile car il partage des caractéristiques des deux types d’hyperviseur. Il est distribué en tant que composant Linux, ce qui signifie qu’un utilisateur Linux peut démarrer KVM à partir d’une ligne de commande ou d’une interface utilisateur graphique (GUI). Ces méthodes de démarrage de KVM donnent l’impression que l’hyperviseur s’exécute sur le système d’exploitation hôte, même si KVM s’exécute en réalité sur le métal nu.
Le système d’exploitation hôte fournit à KVM un mécanisme de lancement et établit une relation de coprocessing avec lui, ce qui permet à KVM de partager le contrôle du matériel physique avec le noyau Linux. KVM utilise les instructions de virtualisation du processeur lorsqu’il fonctionne sur du matériel x86, ce qui permet à l’hyperviseur et à tous ses invités de fonctionner directement sur le métal nu. Le matériel physique effectue la plupart des translations de ressources, de sorte que KVM répond aux critères traditionnels d’un hyperviseur de type 1.
Un hyperviseur de type 1 devrait être plus performant qu’un hyperviseur de type 2, tous les autres facteurs étant égaux. Les hyperviseurs de type 1 évitent les frais généraux qu’un hyperviseur de type 2 encourt lorsqu’il demande l’accès aux ressources physiques à l’OS hôte. Cependant, d’autres facteurs jouent également un rôle important dans les performances d’un hyperviseur. Par exemple, ESXi nécessite généralement plus de temps pour créer et démarrer un serveur que KVM. ESXi présente également des performances plus lentes lors de l’exécution de serveurs, bien que cette différence puisse être insignifiante pour des charges typiques.
Intégration
Les hyperviseurs utilisent différentes méthodes pour communiquer avec le matériel physique de l’hôte. KVM utilise un agent installé sur l’hôte pour communiquer avec le matériel, tandis que ESXi utilise le plan de gestion de VMware pour communiquer avec le matériel. Ce processus présente l’avantage de permettre à ESXi d’accéder à d’autres produits VMware qui utilisent ce plan de gestion. Cependant, il exige également qu’ESXi utilise la pile de contrôle de VMware, ce qui peut augmenter les exigences matérielles.
L’intégration étroite avec le système d’exploitation hôte est la principale raison pour laquelle les développeurs Linux préfèrent généralement KVM, qui a été incorporé au noyau Linux peu après sa sortie en 2007. En comparaison, Xen n’a fait officiellement partie du noyau Linux qu’en 2011, huit ans après sa sortie initiale. Les développeurs Linux sont également plus susceptibles d’utiliser KVM parce que Red Hat et d’autres distributeurs Linux l’ont adopté de préférence à d’autres hyperviseurs. Illumos est un OS open-source basé sur OpenSolaris qui a également choisi KVM plutôt que d’autres hyperviseurs lorsqu’il a ajouté la prise en charge de la virtualisation matérielle.
Coût
KVM l’emporte clairement sur VMware sur la base du coût. KVM est open source, il n’entraîne donc aucun coût supplémentaire pour l’utilisateur. Il est également distribué de diverses manières, souvent dans le cadre d’un système d’exploitation open source.
MVMware fait payer une licence pour utiliser ses produits, notamment ESXi. Elle est en mesure de le faire parce que VMware a été la première entreprise à lancer un logiciel de virtualisation de classe entreprise et reste le leader du marché sur ce segment. Sa marque est donc toujours pertinente pour les utilisateurs finaux d’une entreprise, indépendamment de ce que les développeurs peuvent en penser. Un utilisateur d’ESXi doit également acheter une licence pour utiliser vSphere, la suite d’outils de VMware pour le cloud computing qui utilise ESXi. Des licences logicielles supplémentaires peuvent être nécessaires, ce qui augmente encore le coût de la mise en œuvre d’ESXi.
IBM a effectué certains calculs concernant le coût total de possession (TCO) de KVM et de VMware en 2012. Ces calculs ont montré que le TCO de KVM était généralement inférieur de 39 % à celui de VMware, bien que le TCO réel dépende de facteurs spécifiques au site, tels que le cadre opérationnel et la charge de travail. Cette différence de TCO indique que les fournisseurs de services de cloud computing voudront probablement mettre en œuvre KVM sur au moins un cluster, quels que soient les autres facteurs à prendre en compte.
Complexité
Une comparaison de KVM et VMware montre également une nette différence dans la taille de la base de code, qui affecte les coûts de maintenance d’un hyperviseur. KVM a été initialement publié pour tirer parti des extensions des processeurs qui leur permettaient de virtualiser des invités sans traduire le code binaire. Cette origine signifiait que la première version stable de KVM était essentiellement un pilote de virtualisation léger, avec un peu plus de 10 000 lignes de code (LOC).
VMware aurait plus de 6 millions de LOC, bien que ce fait ne puisse pas être vérifié puisque son code source n’est pas accessible au public. Ce total n’affecte pas directement les performances puisque VMware utilise des extensions matérielles pour virtualiser l’invité. Néanmoins, son code original n’a jamais été complètement réécrit, ce qui se traduit par une base de code plus complexe que celle de KVM.
Maturité
KVM et ESXi sont tous deux très matures et stables. KVM fait partie du noyau Linux depuis plus d’une décennie, et ESXi est disponible publiquement depuis 2006. Cependant, KVM est plus largement déployé car il est open source et est inclus dans de nombreux paquets tels que Redhat Enterprise Virtualization (RHEV). KVM prend également en charge plus de fonctionnalités que tout autre hyperviseur.
Évolutivité
KVM est généralement plus évolutif que VMware, principalement parce que vSphere a certaines limitations sur les serveurs qu’il peut gérer. En outre, VMware a ajouté un grand nombre de réseaux de stockage (SAN) pour prendre en charge différents fournisseurs. Cette caractéristique signifie que VMware a plus d’options de stockage que KVM, mais elle complique également la prise en charge du stockage de VMware lors de la mise à l’échelle.
Prise en charge des fonctionnalités
Les hyperviseurs varient considérablement dans leur prise en charge des fonctionnalités. La prise en charge du réseau et du stockage est particulièrement importante et est probablement plus importante que tout autre facteur à part l’intégration du système d’exploitation. Il ne devrait pas être surprenant d’apprendre que le support d’ESXi pour les autres produits VMware est inégalé par tout autre hyperviseur. D’autre part, KVM offre plus d’options pour la prise en charge du réseau que VMware.
Résumé
KVM est généralement le choix le plus populaire pour les utilisateurs qui sont préoccupés par le coût d’exploitation de chaque VM et moins intéressés par les fonctionnalités de niveau entreprise. Cette règle s’applique principalement aux fournisseurs de services de cloud et d’hébergement, qui sont particulièrement sensibles au coût et à la densité de leurs serveurs. Ces utilisateurs sont fortement susceptibles de choisir des hyperviseurs open-source, en particulier KVM.
L’intégration étroite avec le système d’exploitation hôte est l’une des raisons les plus courantes pour lesquelles les développeurs choisissent KVM, en particulier ceux qui utilisent Linux. L’inclusion de KVM dans de nombreuses distributions Linux en fait également un choix pratique pour les développeurs. KVM est également plus populaire parmi les utilisateurs qui ne se soucient pas des noms de marque.
Voir aussi VMWare vs Proxmox
.