Les raisons techniques qui poussent les utilisateurs à migrer vers vSphere 5

Les migrations vers la version 5 de VMware vSphere n'en sont pour l'instant qu'à leur début dans les grandes entreprises, mais certaines nouvelles fonctions du système de fichiers VMFS et les nouveautés apportées par Site Recovery Manager 5.0 émergent comme des raisons clés dans les décisions de mise à niveau.

Virtual Machine File System (VMFS) 5 a été l'une des nouveautés les moins mises en avant par VMware pour le lancement de vSphere 5. Mais les premiers utilisateurs expliquent qu'il apporte des avantages significatifs, en particulier sa nouvelle taille de bloc unifié qui, selon plusieurs utilisateurs, devrait simplifier le provisioning des fichiers de machines virtuelles (VMDK).

Avec VMFS-3, le fichier VMDK le plus gros, avec une taille de bloc de 1 Mo, était de 256 Go. L'utilisation de tailles de blocs plus grandes (2, 4 et 8 Mo) était nécessaire pour créer des fichiers plus volumineux. Maintenant, VMFS-5 prend en charge une taille de bloc unique et unifiée de 1 Mo, avec laquelle il est toutefois possible de créer des machines virtuelles de taille imposante. La taille de bloc unifié se traduit donc par une gestion simplifiée pour les administrateurs.

« Un des problèmes avec VMFS-3 et avec les versions antérieures, était que la taille de bloc que vous définissiez lors du formatage du datastore [un volume de stockage vSphere] déterminait la taille maximale des fichiers VMDK stockés sur elle », explique Christian Mohn, un administrateur chez Seatrans, une compagnie maritime norvégienne. « Cela signifie que lorsque vous planifiez votre infrastructure de stockage, vous deviez avoir une idée de ce que serait la taille de vos fichiers VMDK tout au long du cycle de vie du magasin de données. »

Mohn n'a certes pas encore entamé sa mise à jour vers vSphere 5, mais il fait parti d'une longue liste d'utilisateurs qui attendent avec impatience de pouvoir profiter des évolutions de VMFS. «Je n'attends que ça pour me débarrasser de certaines des restrictions de taille de bloc que nous subissons actuellement sur nos LUN », explique-t-il.

« Je suis impressionné par les caractéristiques de stockage de la version 5 », déclare quant à lui Barry Blakely, architecte infrastructure pour Mazda. Dans les versions précédentes de VMFS, le volume le plus gros pouvait atteindre 2 To. Avec VMFS-5, cette limite a été augmentée à 64 To. «J'aime aussi l'idée de ne plus avoir à gérer qu'une taille de bloc unifié et de pouvoir disposer de datastore de 64 To », explique Blakely.

« J'ai vraiment entendu de bonnes choses des utilisateurs sur VMFS-5. Il a éliminé plusieurs limitations de la version précédente, et les utilisateurs semblent croire que c'est plus simple et plus facile à gérer », opine de son côté Jeff Byrne, analyste senior et consultant pour le Groupe Taneja. « Je crois que VMFS doit être l'une des caractéristiques les plus sous-estimées de vSphere 5. VMware avait l'habitude par le passé de vanter assez fortement les améliorations VMFS, mais leur marketing se concentre désormais sur les couches les plus hautes de leur pile logicielle et les nouvelles fonctions intéressantes, comme celles qu'apporte VMFS, ont tendance à être négligées. "

SRM 5 : un déclencheur de mises à jour

Certains utilisateurs ont accéléré leur migration vers vSphere 5 parce qu'ils veulent tirer parti des nouvelles fonctionnalités comme la réplication basée sur l'hôte qu'offre SRM (Site Recovery Manager) 5.

La nouvelle fonction de SRM, baptisée vSphere Replication, permet de répliquer des machines virtuelles entre plusieurs sites au niveau VMDK, ce qui ouvre la voie à l'utilisation de systèmes de stockage hétérogènes - et donc potentiellement moins coûteux que l'actuelle solution qui requiert l'utilisation de baies similaires sur les deux sites ainsi que la mise en œuvre des outils de réplication des constructeurs.

Mark Vaughn, un consultant en informatique et vExpert, connaît plusieurs clients qui ont migré vers vSphere 5 pour pouvoir utiliser SRM 5. «Il y a encore beaucoup d'entreprises qui n'en sont qu'au début de leurs stratégies de reprise d'activité. Une configuration matérielle homogène peut être coûteuse, il est donc très attrayant pour certaines personnes faisant leurs premiers pas dans la reprise après sinistre de recycler leur ancien système de stockage sur le site secondaire et d'utiliser le nouveau sur le site principal. Et il n'est pas nécessaire qu'ils soient identiques ».

Shannon Snowden, associé chez NewAge Technologies, estime également que SRM 5 tire les mises à jour vers vSphere 5. «Ce n'est pas tellement pour les nouvelles fonctionnalités dans vSphere, c'est plus pour les versions 5 d'autres produits tels que les SRM et View. Les gens qui font la mise à jour, le font généralement pour une raison externe à vSphere 5 mais du coup, l'hyperviseur est mis à jour ».

Adapté d'un texte en anglais de Beth Pariseau, SearchServerVirtualization.com, par Christophe Bardy