Virtualisation de serveurs : avec RHEV 3.0, Red Hat tente de combler son retard
Afin de tenter de combler son retard sur le marché de la virtualisation par rapport à ses grands concurrents VMware, Microsoft et Citrix, Red Hat vient de lancer la version 3.0 de son environnement de virtualisation. Et il promet encore de nombreuses améliorations pour la version 3.1, attendue dans le courant du second semestre.
Red Hat a officiellement lancé la version 3.0 de sa solution de virtualisation RHEV la semaine dernière en dévoilant des capacités renforcées par rapport à la mouture précédente mais moins avancées que prévu à l'origine. La sortie de cette nouvelle mouture est une étape importante dans la stratégie de virtualisation de Red Hat, venu très tard à la virtualisation et qui pointe loin derrière VMware, Microsoft et Citrix en matière de base installée.
En retard face aux acteurs propriétaires comme VMware et Microsoft, Red Hat doit faire face à un double défi sur le marché des solutions de virtualisation libres. Il est coincé entre les tenants de Xen tels qu'Amazon et RackSpace (qui utilisent XenServer de Citrix) et entre les acteurs libres et gratuits comme Ubuntu, qui est aujourd'hui la solution de référence pour les clouds OpenStack utilisant KVM. Ironiquement, Red Hat se voulait le champion de KVM, une technologie de virtualisation qu'il a contribué à promouvoir avec le rachat de Qumranet, mais il a été devancé sur ce marché par Canonical.
RHEV 3.0 veut défier VMware ESX et Hyper-V
La solution de virtualisation RHEV (Red Hat Entreprise Virtualization) est constituée de deux composantes principales : RHEV-M est la console d'administration de la solution de Red Hat, à l'instar de vCenter for vSphere ESX tandis que RHEV-H est la couche hyperviseur. Plus exactement, RHEV-H est une distribution spécifique de Red Hat Enterprise Linux (RHEL), conçue spécifiquement pour faire fonctionner de façon optimale l'hyperviseur KVM.
Avec la version 3.0 de sa solution, Red Hat met en avant les capacités de son hyperviseur, une stratégie aussi utilisée par Microsoft pour Hyper-V 3.0. Il est vrai que les deux hyperviseurs ont plusieurs longueurs de retard sur VMware ESX en matière de fonctionnalités (et nous ne parlons pas là que du nombre de CPU supportés ou de la mémoire, mais plutôt des fonctions avancées de gestion du stockage ou du réseau). Mais en tentant de positionner le débat au niveau de l'hyperviseur, l'éditeur affiche une guerre de retard : cela fait longtemps que le débat s'est déplacé au niveau des outils d'administration, d'orchestration et d'automatisation de "cloud", privés ou publics. Et en la matière la stratégie de Red Hat reste encore plus que floue par rapport à celles de VMware (et ses outils vCenter), Microsoft (et System Center) et Citrix (avec Cloud.com et OpenStack).
RHEV-M 3.0 rompt avec Windows
Avec le lancement de la version 3.0, Red Hat tient toutefois une promesse faite il y a bientôt deux ans, à savoir la réécriture complète de la console d'administration de sa solution. Jusqu'alors basée sur Windows, RHEV-M se présente désormais pour l'administrateur comme une console Web qui ne nécessite plus Microsoft Internet Explorer. La version précédente de RHEV-M était basée sur un environnement Microsoft. NET et s'appuyait sur une couche de base de données motorisée par Microsoft SQL Server.
Le nouvel outil s'appuie quant à lui sur un code redéveloppé en Java (et fonctionnant sur le serveur JBoss) et sur une couche de base de données basée sur PostgreSQL. Cette conversion permet à Red Hat de couper toute dépendance à Windows mais aussi de proposer un outil mieux intégré à sa solution. Reste qu'avec RHEV-M 3.0, Red Hat se concentre essentiellement sur la gestion des machines virtuelles, alors que ses concurrents se concentrent désormais sur les couches supérieures d'administration.
A venir : la migration à chaud du stockage
Red Hat est bien conscient de cette situation et affiche une roadmap ambitieuse pour RHEV-M. Le stockage, par exemple, sera un élément clé de RHEV 3.1, attendu au second semestre 2012, avec la possibilité d'ajouter et de retirer des disques à chaud dans les VM ou de créer des instantanés à chaud des VM via un agent chargé d'assurer la cohérence du filesystem. Cette version 3.1 apportera aussi la capacité de redimensionner dynamiquement des volumes de stockage et de réaliser des migrations de stockage à chaud.
Une autre caractéristique de la version 3.1 sera de permettre à une même machine virtuelle d'utiliser des disques provenant de pools de stockage différents, ce qui est "particulièrement important si vous avez un stockage hiérarchisé ", selon Andrew Cathrow, un chef de produit pour Red Hat. Une autre nouveauté attendue avec la version 3.1 sera l'apparition d'une technologie baptisée "floating disk" qui supportera des systèmes de fichiers en cluster comme GlusterFS (le filesystem en cluster de Red Hat) ou GPFS d'IBM.
Côté réseau, RHEV 3.1 apportera la possibilité de désigner des réseaux différents pour l'administration, le trafic de stockage et les VM, une interface graphique pour le paramétrage des infrastructures Cisco UCS et la capacité de brancher et débrancher à chaud des cartes réseau.
RHEV-H 3.1 amènera encore plus d'évolutivité
Le prochain hyperviseur RHEV-H 3.1 s'appuiera sur Red Hat Enterprise Linux (RHEL) 6.3, et héritera de meilleures performances, de plus d'évolutivité et de nouvelles fonctionnalités. L'évolutivité s'est avérée être une question délicate pour le lancement de RHEV 3.0. Pendant la phase bêta en août dernier, le marketing de Red Hat avait annoncé le support d'un maximum de 64 processeurs virtuels et de 2 To de mémoire vive par serveur. Mais la version finale de la version 3.0 plafonne finalement à 512 Go, soit deux fois moins que ce que propose VMware.
Red Hat explique désormais que la mention des 2 To effectuée en août était une limite théorique. "RHEL 6.2 n'était pas sorti à cette époque, et [lorsque RHEL 6.2 est sorti] l'OS a été certifié que pour 2 téraoctets de RAM par serveur hôte", explique Cathrow. "RHEL peut faire plus et nous avons testé des machines virtuelles jusqu'à 3,5 téraoctets, mais 2 téraoctets est la limite matérielle pour la plupart des serveurs du marché."
Notons qu'avec l'arrivée de RHEL 6.3, Red Hat prévoit de supporter officiellement plus de 2 téraoctets de mémoire vive par hôte. Reste désormais à l'éditeur de clarifier sa position en matière d'orchestration et de gestion de cloud, sous peine de se retrouver pris de vitesse dans les grands clouds de fournisseurs de services par Ubuntu et Xen et de continuer à se traîner derrière VMware, Microsoft et Citrix sur le marché des clouds privés d'entreprise.
Avec Beth Pariseau, SearchServerVirtualization.com