Si vous parlez d’un hôte vSphere, vous pouvez voir ou entendre des gens les appeler ESXi, ou parfois ESX. Non, quelqu’un n’a pas simplement laissé tomber le i, il y avait une version précédente de l’hyperviseur vSphere appelée ESX. Vous pouvez également entendre ESX appelé ESX classic ou ESX full form.
Aujourd’hui, je veux jeter un coup d’œil à ESX vs ESXi et voir quelle est la différence entre eux. Plus important encore, je veux examiner certaines des raisons pour lesquelles VMware a modifié l’architecture de l’hyperviseur vSphere à partir de 2009.
Dans Ce Guide
Qu’est-ce que ESX ? (Ciel élastique X)
Vous vous demandez ce qu’est ESX? ESX signifie Elastic Sky X. ESX est ce que l’hyperviseur bare metal de VMware que nous connaissons et aimons tous s’appelait à l’origine. C’est vraiment là que la virtualisation a commencé.
Pour la leçon d’histoire VMware d’aujourd’hui, nous allons commencer par ESX. ESX était ce que l’hyperviseur bare metal de VMware s’appelait à l’origine. Bien que les fonctionnalités des hôtes ESXi actuels soient très similaires (bien que beaucoup plus avancées) à ESX, il existe une différence architecturale importante.
La principale différence était la console de service ESX. En fait, mon tout premier article de blog était dédié à la console de service ESX.
Considérez la console de service comme une petite machine virtuelle qui s’exécutait à côté de vos machines virtuelles invitées et fournissait un accès de gestion à l’hôte ESX. La console de service vous a permis de vous connecter à ESX et d’émettre des commandes esxcfg sur une ligne de commande pour configurer votre hôte.
Voici une représentation très simple de ce à quoi il ressemblait:
En plus d’accéder à la ligne de commande, vous pouvez télécharger et installer presque n’importe quel agent de votre choix dans la console de service ESX, comme des agents pour la surveillance matérielle, la sauvegarde ou bien tout ce que vous vouliez vraiment.
Les agents de gestion ESX vivaient également ici dans la console de service.
La console de service a parlé au VMkernel, qui est essentiellement le cerveau de votre hôte ESX ou ESXi.
Avant de parler davantage du VMkernel, jetons un coup d’œil à ce qui a changé avec ESXi.
Qu’est-ce que ESXi ? (ESX intégré)
Vous vous demandez ce qu’est ESXi ? Il s’agit de la prochaine génération de l’hyperviseur ESX de VMware. ESXi signifie ESX intégré.
Lors de la création d’ESXi, VMware a intégré la fonctionnalité de la console de service dans le VMkernel, comme ceci: 
Encore une fois, c’est un diagramme très simple mais vous pouvez voir quels étaient les principaux changements, le plus important étant d’éliminer complètement la console de service de l’architecture ESXi.
Même si j’ai résisté à ce changement à l’époque, cela avait du sens pour un certain nombre de raisons. Rappelez-vous, ESXi est sorti avec vSphere 4 en 2009, qui a été le boom de la virtualisation. Tout le monde virtualisait tout sur le site et exécutait ses charges de travail critiques sur ESX.
Voici quelques raisons pour lesquelles VMware a peut-être jugé opportun d’effectuer ce changement.
Performances et stabilité pour VMware ESXi
Bien que la console de service ne puisse utiliser que jusqu’à 800 Mo de RAM (ce qui pourrait être significatif, croyez-le ou non, dans certains des hôtes de l’ère 2009), elle pourrait tout de même faire des ravages en termes de performances et de stabilité.
Vous vous souvenez des agents tiers dont nous avons parlé? Eh bien, dans ce cas, un mauvais agent pourrait vous amener l’hôte ESX à un arrêt criant, ce qui n’était pas une bonne chose.
Sécurité de l’hyperviseur de VMware
La raison pour laquelle il était si facile de développer et d’installer des agents sur la console de service était que la console de service était essentiellement une machine virtuelle linux assise sur votre hôte ESX avec accès au VMkernel.
Cela signifie que la console de service devait être corrigée comme tout autre système d’exploitation Linux, et était sensible à tout ce qu’un serveur Linux était.
Voyez-vous un problème avec cela et l’exécution de charges de travail critiques ? Absolument.
En se débarrassant de cette « machine virtuelle de gestion », VMware a pu réduire considérablement la surface d’attaque de son hyperviseur, qui devenait de plus en plus importante à mesure que l’adoption se développait si rapidement.
Simplification de la gestion de la virtualisation
En intégrant ces fonctions de gestion dans le VMkernel, l’architecture ESXi est devenue beaucoup plus simple qu’ESX. Comme tous ceux qui ont déjà conçu quelque chose peuvent vous le dire, le plus simple sera le mieux.
Par exemple, au lieu d’installer un agent tiers pour la surveillance matérielle, VMware a introduit le modèle d’information commun ou CIM. Cela a permis aux données matérielles d’être facilement visibles dans vCenter Server et aux plates-formes de gestion matérielle courantes d’y accéder via vCenter.
Pour un excellent aperçu de l’ICM, assurez-vous de consulter ce blog sur le site de VMware. C’est à partir de 2011, et explique à merveille cet énorme changement dans l’architecture ESX vs ESXi.
Cela a non seulement simplifié la gestion, mais a ajouté à la stabilité et à la sécurité d’ESXi dans son ensemble.
Qu’est-ce que le VMkernel ?
Nous avons beaucoup parlé du VMkernel, qui est le cerveau d’ESXi.
Je veux vous donner un aperçu simple afin que vous puissiez vraiment commencer à comprendre ses capacités.
Comme je l’ai dit, le VMkernel est le cerveau de l’opération. Il gère des choses comme la planification des ressources et la gestion des ressources.
Les piles de réseau et de stockage se trouvent également dans le VMkernel, et les pilotes de périphériques hôtes de l’ESXi sont également gérés par le VMkernel.
Que sont les ports VMkernel ?
À l’époque d’ESX, nous nous connections à nos hôtes avec un port de console de service spécial. Cela a été configuré lors du processus d’installation d’ESX, afin que nous puissions nous connecter à nos hôtes pour continuer à les configurer et à les gérer.
À partir d’ESXi, nous avons configuré un port VMkernel pour la gestion. Aujourd’hui, les ports VMkernel servent bien plus que la simple gestion, car le produit vSphere a énormément progressé.
Lorsque ESXi a fait ses débuts, les ports VMkernel étaient configurés pour la gestion, vMotion et le stockage basé sur IP si vous l’utilisiez. Si vous configurez un port VMkernel pour le stockage, vous ne dites tout simplement pas à vSphere que c’est dans un but spécial comme ceux énumérés ci-dessus. C’est parce qu’il passe en revue la pile TCP / IP par défaut dans vSphere.
Les ports VMkernel existaient bien sûr avant ESXi, mais à moins que vous utilisiez le stockage IP ou vMotion (qui, au début, le croyiez ou non n’étaient pas couramment utilisés), vous n’aviez probablement jamais configuré un port VMkernel auparavant.
Aujourd’hui, comme vous pouvez le voir, il existe de nombreuses autres applications pour utiliser les ports VMkernel. Vous pouvez en savoir plus à leur sujet dans le guide de mise en réseau VMkernel de VMware.
ESX vs ESXi N’est même pas une Comparaison
Lorsque ESXi est sorti pour la première fois, de nombreux administrateurs de vSphere, y compris moi-même, étaient obsédés par la comparaison ESX vs ESXi. Nous étions tellement habitués à la console de service et à nos opérations vSphere autour qu’il s’agissait d’un énorme changement de paradigme.
Je me souviens que j’ai spécifiquement utilisé un outil dans la console de service pour gérer mon grand environnement ESX. Avant ESXi, des choses comme PowerCLI n’étaient pas largement utilisées car il n’y avait aucune raison de le faire, vous utilisiez simplement les commandes esxcfg dans la console de service.
Le VMware Infrastructure Toolkit (pour Windows), ou le VI Toolkit était le prédécesseur de PowerCLI n’a même pas été publié avant juillet 2008. Avec le recul, vous pouvez voir VMware préparer le terrain pour l’avenir de sa plate-forme, en assurant les performances, en sécurisant la base de code et en rationalisant la gestion.
Avouons-le, ESX comme nous le savions n’allait pas soutenir la trajectoire ascendante continue de vSphere. VMware a dû prendre des mesures pour pérenniser son produit pour ce qui était à venir.
Dans vSphere 4, VMware proposait à la fois ESX et ESXi pour permettre aux clients de faire progressivement le changement, mais lorsque vSphere 5 est arrivé en 2011, ESXi est devenu l’hyperviseur VMware vSphere.
C’est à cette époque que nous avons également vu émerger des outils tels que le déploiement automatique et que les PowerCLI commencent à devenir suralimentés.
Nous avons également vu de plus en plus de fonctionnalités arriver à la fois à ESXi et à vCenter. Si vous compariez ESX 4.1, qui était la dernière version d’ESX full form à ESXi 6.7, vous ririez probablement d’ESX si votre première version de vSphere était 6 ou supérieure.
Alors qu’il était clairement à la pointe lors de sa sortie, les modifications apportées à l’architecture ESX vs ESXi ont ouvert la voie à l’avancement et à la croissance continus de vSphere. Sans ce passage à ESXi, nous ne serions tout simplement pas là où nous en sommes aujourd’hui.