La comparaison entre VMWare ESX3i et ESX 3.5
La technologie ESX3i de VMWare basée sur un système de clé USB pour la mise en place commence à être utilisée. Nous profitons des premières expériences pour faire un comparatif par rapport à la version ESX 3.5 et notamment ses fonctionnalités "Boot from san".
Actuellement, la technologie ESXi est largement évoquée pour les infrastructures VMWare. Plusieurs problèmes apparaissent avec les premiers déploiements. Cela permet de relativiser les gains annoncés.
Par exemple, les outils de gestion, contrôle et monitoring ESXi (difficulté d’avoir l’état à un instant donné d’un serveur ESXi) ne sont pas aussi développés et beaucoup d’actions possibles avec ESX 3.5 ne le sont plus avec ESXi (scripting, agents, etc).
Il se pose également la question de la montée en puissance (scalability) d’une architecture reposant sur ESXi.
Les grands comptes risquent d’avoir un problème d’adoption avec ces contraintes. Le temps que la technologie monte en puissance, notre avis est que des vrais déploiements sur des architectures complexes en production doivent attendre encore un peu (environ 1 an).
La possibilité pour ESXi de démarrer à partir d'une clé usb est une étape intermédiaire pour se rapprocher du Solid State Drive (firmware) et éventuellement l'intégration à terme dans le matériel de vendeurs de serveurs.
Cela a commencé à se produire avec IBM qui a été le premier à annoncer l'intégration, cependant la livraison d'un tel système reste encore inconnu. HP et Dell ont commencé à commercialiser la technologie avec l'intégration d’ESXi avec une clé usb sur un port interne. Boot from SAN ne sera donc plus nécessaire, et peut-être finalement pas supporté.
La licence initiale permet d’avoir VMFS, et vSMP. Le vrai utilitaire viendra de la console de gestion, Virtual Center.
Virtual Center contient les licences de différents niveaux qui donneront la possibilité d'utiliser des fonctionnalités avancées comme Vmotion, DRS, HA.
Les mises à jour sont réduites, puisqu’elles étaient souvent prévues pour le Service Console, qui n’est pas présent dans le produit.
L’absence de service console apporte des gains de performances en libérant des ressources pour utiliser les machines virtuelles.
Les administrateurs qui ont l’habitude d’utiliser des outils externes, scripts bash ou perl pour améliorer les performances et la maintenance, effectuer des actions répétitives et de façon générale toutes les actions nécessitant d’être exécutées dans la console service devront les faire migrer vers le nouvel outil CLI (Command Line Interface), utiliser des APIs via des systèmes distants ou … changer de politique d’administration.
Les agents de gestion des grands constructeurs pour remonter les événements logiciels et matériels vers un serveur de gestion centralisé auront des difficultés à suivre les systèmes ESXi. Pour autant pour continuer à avoir l’accès à cette information VMWare met à disposition une interface CIM. Nous sommes réservés sur une telle interface, notamment parce que cela implique que les gestionnaires de plate-formes (HP SIM, IBM Director, Dell Openmange) s’adaptent, ce qui renvoient à des dates inconnues, probablement pas avant 2009. Dans l’attente, l’utilisation de la version 3.5 reste le plus recommandé.