Étude d`une architecture évolutive et haute disponibilité

Étude d’une architecture évolutive et haute disponibilité pour les postes de travail virtuels
Ziya Aral
Jonathan Ely
DataCore Software
Récapitulatif
Ce rapport fournit une analyse d’une configuration de postes de travail virtuels réduisant le coût matériel total par poste de
travail à environ 32,41 $, infrastructure de stockage comprise. Ce faible coût est obtenu par l’utilisation d’une configuration
comprenant un stockage à double nœud, avec mise en miroir mutuelle et haute disponibilité. Par rapport à de précédentes
études vantant les coûts de l’infrastructure de stockage d’une infrastructure de postes de travail virtuels (VDI), soit de
cinquante à quelques centaines de dollars par machine virtuelle, l’importance de ces données devient évidente. Ce rapport
démontre que les coûts du matériel de stockage perdent toute importance.
Fait encore plus marquant : la configuration en question a engendré ce résultat avec 220 postes de travail virtuels reposant sur
une simple paire de serveurs économiques. L’innovation majeure consiste à cohéberger les systèmes de virtualisation du
stockage redondants sur les mêmes plates-formes matérielles que les postes de travail virtuels. Ainsi, il n’est plus nécessaire
d’amortir les contrôleurs de stockage autonomes au coût élevé sur la base de nombreuses plates-formes de serveurs virtuels
et de milliers de postes de travail virtuels. De précédents rapports avaient analysé des configurations exploitant des milliers de
postes de travail virtuels pour couvrir le coût de ces contrôleurs. En lisant entre les lignes, vous remarquerez immédiatement
que les coûts matériels par poste de travail virtuel augmentent très nettement lorsque la taille de telles configurations diminue.
Pourtant, de la plupart des points de vue pratiques, ces configurations VDI de petite taille sont précisément celles les plus
essentielles.
D’autre part, la taille de cette configuration peut également croître de manière linéaire jusqu’à des milliers de postes de travail
virtuels, éliminant ainsi les configurations distendues créées par la recherche de points d’équilibre artificiels auxquels les coûts
sont optimisés.
Enfin, cette configuration utilise l’outil d’analyse VSI (Virtual Session Indexer) et repose sur le logiciel SANmelody de DataCore
et la plate-forme de virtualisation Microsoft Hyper-V. L’utilisation de Microsoft Hyper-V dans le cadre d’une telle étude est
inhabituelle car l’on adopte en général la plate-forme VMware ESX pour le dimensionnement VDI. DataCore attend des
résultats similaires avec ESX et les publiera dès qu’ils seront disponibles.
Le problème
Les hyperviseurs actuels exploitent les réseaux de stockage (SAN) pour fournir l’infrastructure de stockage nécessaire aux
réseaux de machines virtuelles et hôtes. De telles infrastructures partagées servent à offrir portabilité, capacité de
provisionnement et flexibilité aux machines virtuelles. De plus, le besoin de ces réseaux croît proportionnellement à la
multiplication du nombre de machines virtuelles. Le besoin de configurations haute disponibilité croît au même rythme que le
nombre de machines virtuelles, pour maintenir leur fonctionnement et pour éviter les pannes touchant, non pas une ou deux,
mais peut-être des dizaines de machines. La prolifération des machines virtuelles renforce la dépendance des tâches de
gestion courantes (par exemple, sauvegarde et migration) envers la fonctionnalité de gestion du stockage des réseaux SAN.
Multipliez ces exigences par 10 ou 100 et nous obtenons la synergie entre les postes de travail virtuels et les réseaux SAN.
Le problème des mises en œuvre de postes de travail virtuels réside dans le fait que les SAN sont souvent déployés avec de
grands contrôleurs de stockage coûteux et des réseaux de stockage externe complexes. Bien qu’ils présentent l’avantage
d’assurer une évolutivité raisonnable, ils entraînent un coût minimal très élevé pour les projets VDI. Pour surmonter ce poids,
les fournisseurs de matériel effectuent en général des tests avec un à plusieurs milliers de postes de travail virtuels.
Les postes de travail virtuels n’en restent qu’à leurs débuts. De nombreuses entreprises, bien que comprenant les avantages
potentiels de la technologie, lancent des programmes pilotes ou tentent d’intégrer les déploiements VDI à des architectures
existantes. Si la granularité de ces déploiements porte sur des milliers d’unités, l’utilisateur est alors contraint d’exploiter non
pas seulement un poste dans son intégralité, mais un éventail complet de postes sur un site, et ce avant même de savoir si la
solution convient.
L’alternative s’avère tout aussi peu attractive. L’utilisateur « prend sur soi » et accepte ce coût minimal élevé ainsi que la
complexité d'un réseau SAN complet tout en exploitant un nombre de postes de travail virtuels bien inférieur au nombre
optimal. Le coût de la mise en œuvre par poste de travail devient alors beaucoup plus conséquent qu’il ne l’aurait été si le
modèle classique des postes de travail physiques avait été conservé. Cela ne s’avère pas très engageant pour une nouvelle
technologie censée réduire les coûts… comme le soulignent de plus en plus de bloggeurs toujours pragmatiques.
DataCore
Cette étude est menée en exploitant l’environnement des solutions logicielles de virtualisation du stockage de DataCore sur
une plate-forme identique à celle des hyperviseurs hébergeant les postes de travail virtuels. Le logiciel de DataCore constitue
une mise en œuvre complète d’un réseau SAN haute disponibilité avec toutes les fonctionnalités nécessaires à une
infrastructure d’hébergement de machine virtuelle ainsi que des caractéristiques de performances exceptionnellement élevées.
Outre ces fonctionnalités, le logiciel présente plusieurs caractéristiques recommandées pour cette application. La portabilité du
logiciel lui permet de fonctionner comme une machine virtuelle sous Hyper-V ou ESX et également de s’exécuter sous
Windows Server 2008 au niveau du système d’exploitation, en parallèle avec Hyper-V. Bien que cela signifie que le logiciel
consomme des ressources matérielles communes, cela signifie également que la plupart des interconnexions de réseau SAN
et des éléments de stockage (telles que le cache de bloc) sont déployés localement et virtuellement, sur une couche de base
commune. Un tel modèle gagne ainsi plus de sa proximité avec ses clients qu’il ne « coûte » par le fait de consommer des
ressources matérielles communes, comme vous pourrez le constater en détail dans la partie Analyse des performances cidessous.
En outre, le modèle décrit simplifie la configuration générale en évoluant de manière transparente : dès qu’un nouvel hôte VDI
est ajouté, les ressources de stockage nécessaires à son fonctionnement le sont également. De plus, ce mécanisme
fonctionne dans les deux sens, éliminant ce qui pourrait constituer un sérieux problème lors du dimensionnement adéquat de
l’infrastructure.
Rien de ceci ne devrait être interprété comme un « défi lancé » par les contrôleurs logiciels aux contrôleurs matériels. La
solution DataCore fonctionne souvent de concert avec de tels contrôleurs matériels. Si l’utilisateur a besoin de ces
périphériques, alors il n’y a aucun problème. Mais, s’il n’existe absolument aucun besoin pour de tels périphériques à la base
des architectures VDI, si ni leur coût ni leur capacité ne parlent en faveur de leur intégration initiale, alors les contrôleurs
matériels ne servent qu’à altérer l’architecture VDI.
Les tests
L’outil de test utilisé est Virtual Session Indexer (VSI) Pro 2.1 de Login Consultants. L’outil VSI devient à présent la norme pour
ce type de charge de travail.
Par rapport aux tests « à la carte » utilisés par plusieurs fournisseurs de stockage, et même par rapport aux données de suivi,
l’outil VSI semble n’être qu’un peu plus gourmand en E/S (et en particulier intense en écriture).
L’outil VSI crée également un ensemble fonctionnel plus important que ce à quoi l’on pourrait s’attendre de postes de travail
physiques. L’explication est simple : l’outil VSI exécute chaque élément de son environnement de postes de travail émulé sur
chaque poste de travail virtuel. En outre, la synchronisation des applications entre les postes de travail virtuels est
formellement minimisée.
Il est simple, globalement, de le justifier comme une simple standardisation des charges de travail nécessaire à la création d’un
environnement de test reproductible. L’outil VSI, cependant, pèche par excès de prudence et s’avère un peu plus exigeant que
de nombreuses charges de travail propriétaires.
Configuration
La configuration utilisée dans l’étude consiste en deux nœuds de serveur générique, chacun doté d’une carte mère ASUS
Z8PE-D18 Dual LGA, de deux processeurs Intel Xeon E5640 Westmere 2,66 GHz à quatre cœurs et d’un disque d’amorçage
SATA 80 Go. Le coût total s’élève à 2114,14 $ par serveur, hors mémoire DRAM et stockage des applications. En outre,
chaque nœud est configuré avec 64 Go de mémoire DRAM DDR3 PC3-10600 (à 1056,24 $) et 4 disques applicatifs :
2 disques durs SATA SAMSUNG HD103SJ et 2 disques durs SATA Western Digital VelociRaptor WD3000HLFS (393,60 $
pour les 4 disques durs). Le coût total du matériel serveur s’élève donc à 3564,68 $ par machine et 7129,36 $ pour l’ensemble
de la configuration.
Deux disques SATA sont configurés en tant que pool de stockage, appartenant à SANmelody. Dans cette configuration, le
logiciel SANmelody est exécuté au niveau du système d’exploitation. Que SANmelody fonctionne à ce niveau ou sous forme
de machine virtuelle ne fait que peu de différence. Dans ce cas, la première option est choisie pour la visibilité des tests.
Le pool de stockage, une fois configuré, sert à héberger une « image maître » des postes de travail virtuels. Celle-ci est
ensuite capturée grâce à la fonctionnalité de snapshot de DataCore, et chaque copie créée est présentée comme une LUN de
démarrage sur les postes de travail virtuels. Des expériences ont tenté de déterminer si le fait d’utiliser plusieurs images
maîtres pouvait optimiser les performances. Ce fut non seulement inefficace, mais la présence de multiples images sources a
en réalité augmenté la quantité de mémoire nécessaire à la gestion du jeu de pages de travail dans le cache de bloc DataCore.
Enfin, l’image initiale et ses snapshots sont mis en miroir sur le second serveur (grâce à la mise en miroir asynchrone de
DataCore via iSCSI) pour pouvoir atteindre le niveau requis de haute disponibilité. Cette configuration est alors non seulement
protégée contre les pannes de stockage, mais les postes de travail virtuels peuvent également être redémarrés sur n’importe
quel autre serveur dans l’éventualité d’une défaillance plus critique. Deux disques SATA sont configurés en tant que second
pool de stockage pour recevoir les données en miroir de l’autre nœud.
La configuration décrite ci-dessus est déployée avec quelques simples scripts qui lancent 110 postes de travail virtuels par
serveur et transfèrent l’ensemble de la configuration à l’outil de test VSI.
Nous vivons dans une ère dans laquelle les caractéristiques principales d’une machine informatique de tout type sont gravées
dans des puces et s’avèrent donc presque identiques pour toute machine d’un type donné. Cette configuration fut choisie afin
de créer une référence de base au « plus petit dénominateur commun ». Le choix des plates-formes de serveur et leurs coûts
vont varier suivant le remplacement de tout élément, des solutions spécifiques aux optimisations pour l’encombrement, la
consommation d’énergie et certaines « fonctions » d’entreprise. Pourtant, aucune de ces variantes ne va modifier de manière
sensible les performances, et ces variantes peuvent être perçues comme de simples différences de coûts par rapport à la
référence présentée dans ce rapport.
Résultats
La configuration ci-dessus fut en mesure d’héberger 220 postes de travail utilisant l’outil de test VSI 2.0.1. Le rapport de
présentation et de configuration des tests est reproduit intégralement en tant qu’annexe à ce livre blanc.
Analyse des performances :
Co-hébergement – L’innovation majeure de ces tests repose sur l’exploitation du système de virtualisation du stockage de
DataCore sur les mêmes plates-formes matérielles utilisées pour héberger les postes de travail virtuels. Alors que certaines
idées reçues pourraient suggérer que le logiciel DataCore deviendrait ainsi un concurrent pour les mêmes ressources limitées
de la plate-forme matérielle, telles que la mémoire et les processeurs, de nombreuses expériences tendent à prouver le
contraire. Dans chaque situation, de telles configurations cohébergées ont facilement surpassé les configurations dotées d’un
stockage externe.
Les raisons sont simples à déterminer, a posteriori. L’application des postes de travail virtuels n’est pas particulièrement
intensive en E/S et peut facilement être prise en charge par la solution DataCore en ne consommant que très peu de cycles de
processeur. La suppression de la majeure partie du trafic des canaux externes entraîne une réduction accrue de ces
demandes. En contrepartie, les défaillances au niveau du cache de bloc sont quasiment inexistantes, les surcharges des
canaux disparaissent et les latences d’E/S sont supprimées. La solution résidente SANmelody est rentable, sans aucune perte
en termes de capacité ou de portabilité.
Du point de vue de la mémoire, une dynamique similaire s’applique. Les postes de travail virtuels offrent des ensembles
fonctionnels d’assez petite taille qui tendent à être intenses en lecture. Toutes les lectures s’effectuant sur le volume source
unique, qui est donc la base du volume système différentiel pour chaque poste de travail virtuel, l’ensemble du regroupement
effectue très correctement une mise en cache dans une taille de cache relativement petite. Des caches de taille supérieure
engendrent un rendement décroissant.
Enfin, l’un des avantages prévisibles de ces types de configurations est qu’elles sont intrinsèquement « autoréglables ». Dès
qu’un groupe de postes de travail virtuels est ajouté, l’infrastructure de stockage nécessaire à sa prise en charge l’est
également. Contrairement aux réseaux SAN génériques, qui présentent des besoins évolutifs et sont souvent organisés
comme des réseaux de stockage indépendants, voire complexes, les besoins connus de l’application VDI permettent dans ce
cas de rendre l’infrastructure de stockage en grande partie transparente.
Disques – La mise en cache d’écriture étant efficace, le niveau de performances des disques requis peut baisser de manière
significative. Lors de ces tests, 4 disques SATA furent utilisés et configurés en deux pools de deux disques DataCore. Le
premier pool fut destiné au stockage principal et le second à la mise en miroir du nœud secondaire. L’utilisation d’une
combinaison de disques à 7200 et 10 000 tours-minute n’est pas importante. Les quatre disques SATA (voire même 3) à
7200 tours-minutes présentant des caractéristiques similaires aux disques Samsung ont produit des résultats similaires.
L’importance que nous attachons à cette distinction est expliquée dans un autre document portant sur la création d’une
configuration de base. Nous nous opposions à utiliser d’autres éléments que les composants SATA les plus standard et les
plus facilement configurés. SAS, baies Fibre Channel, périphériques rapides, disques hybrides et SSD : tous ont leur place
dans le monde réel et furent conçus pour délivrer des performances supérieures à la technologie SATA. Néanmoins,
l’intégration de ces périphériques lors de tests de base produit le même effet que la création d’architectures VDI autour de telle
ou telle baie de stockage. De telles optimisations pourraient être comparées à une source de confusion. Elles rendent non
seulement les comparaisons difficiles, mais elles mènent à la subtile intrusion d’une architecture matérielle spécifique dans un
domaine dans lequel les exigences VDI elles-mêmes devraient primer.
Mémoire – Le coût de la mémoire DRAM représente une part importante des coûts totaux de la plate-forme de cette
configuration. Ainsi, il paraît naturellement tentant de réduire la taille de la mémoire de chaque poste de travail virtuel, afin
d’optimiser le nombre de postes de travail que prend en charge chaque plate-forme. La difficulté est que la densité et la
structure des coûts en évolution constante de la mémoire DRAM représentent la seule constante de notre marché... un fait qui
parle en défaveur de l’optimisation de la mémoire DRAM, et non en sa faveur.
À cette difficulté s’ajoute le fait que Microsoft et VMware offrent des fonctionnalités d’hyperviseur permettant le « gonflement »
de la mémoire attribuée à chaque machine virtuelle. En effet, un type de mémoire virtuelle globale est créé entre les machines,
bien que les mécanismes de mise en œuvre réels puissent différer.
Enfin, les tests DataCore avec l’outil VSI ont révélé que les postes de travail virtuels avec très peu d’allocation de mémoire, si
peu qu’un ordinateur physique n’aurait pu démarrer, fonctionnaient néanmoins normalement dans cette configuration. Après
examen, il s’est avéré que le fonctionnement du cache de bloc DataCore a créé une hiérarchie de pagination ne cherchant pas
à empêcher « le thrashing », mais qui l’a pratiquement absorbé en cas d’adéquation avec des tailles de jeu de pages.
Au final, ni le « gonflement » ni le « rapide thrashing » ne furent utilisés dans la mise en œuvre décrite. Cela a permis non
seulement d’effectuer de justes comparaisons pour analyser les données déjà publiées, mais a également évité l’optimisation
pour des modèles en grande partie propriétaires et indépendants de l’opération de dimensionnement VDI. En un mot, le
modèle conventionnel d’allocation utilisé a évité les « diversions ».
La taille de cache réelle DataCore utilisée était de 4 Go. Alors que des caches de taille supérieure produisent de meilleurs
résultats, celui-ci constituait le point auquel le rendement décroissant pouvait être clairement établi. En soustrayant cette
utilisation et l’attribution de mémoire pour Windows Server 2008, la mémoire DRAM restante était simplement divisée par le
nombre de postes de travail résidents selon une allocation conventionnelle fixe.
Coûts logiciels – Il se peut que l’on objecte que l’utilisation par DataCore d’un système logiciel de virtualisation du stockage
au lieu d’un contrôleur matériel doit entraîner le report du coût du logiciel pour réaliser une comparaison entre des éléments
réellement comparables. Mais celui-ci apporte ses propres défis. La majorité des contrôleurs matériels testés s’avèrent assez
minimalistes. La plupart des fonctionnalités qu’offre le logiciel SANmelody ne sont pas disponibles ou le sont à un coût
additionnel pour les configurations en question.
Ceci étant noté, le coût total du logiciel s’élevait à 3848 $ par nœud ou 34,98 $ par poste de travail virtuel. Cela comprend le
coût du système d’exploitation Microsoft Server 2008 R2, qui héberge l’environnement SANmelody et les postes de travail
virtuels reposant sur Hyper-V, et le logiciel SANmelody DataCore.
Le coût total de la configuration testée, incluant l’ensemble des composants matériels et logiciels de son infrastructure mais ne
comprenant pas le système d’exploitation et les applications des postes de travail virtuels, s’élève alors à 67,39 $ par poste de
travail.
Évolution – Comme nous l’avons abordé précédemment, le vrai problème ne résidait pas dans l’évolution vers des milliers de
postes de travail virtuels, mais dans leur adaptation à des configurations pratiques. Il est logiquement inutile de préciser qu’il
faut y parvenir sans alourdir sensiblement les coûts au niveau du poste et également sans renoncer au jeu de fonctionnalités
du réseau SAN assurant portabilité, disponibilité et redondance des données. Sinon, tous les avantages de l’infrastructure de
postes de travail virtuels seraient compromis. La configuration DataCore décrite dans ce livre blanc est intéressante car elle
assure des coûts faibles pour l’infrastructure des 220 postes de travail en créant une solution de paire de serveurs hébergeant
en parallèle les postes de travail virtuels et l’infrastructure de stockage.
Mais qu’en est-il de l’augmentation de la taille de cette configuration ? Comment peut-on parvenir à des milliers de postes de
travail, si cela est nécessaire ? Et, point capital, est-il possible d’y parvenir sans entraîner des coûts marginaux extrêmement
variables ou de complexes reconfigurations ?
Pour obtenir des configurations de taille supérieure, une topologie DataCore connue sous le nom de « Star » est exploitée.
Grâce à la topologie Star, l’ajout d’un troisième nœud sert à créer un centre ou un hub Star. Des nœuds supplémentaires sont
alors ajoutés à la topologie Star. Chacun des nœuds de la topologie Star agit de la même manière qu’auparavant, mais il met
en miroir son contenu sur le nœud central plutôt que sur les autres nœuds. Celui-ci devient alors le seul point de contrôle de
l’ensemble de la configuration.
Avec ce modèle, chaque nouveau serveur ajouté en un point de la topologie apporte ses propres périphériques de stockage,
son infrastructure ainsi que son environnement VDI. Le modèle se configure automatiquement jusqu’à ce que le nœud central
ne puisse plus prendre en charge les données de miroir secondaire. Autre avantage, la plupart des phénomènes VDI
dégénératifs, tels que les « boot storms », demeurent contenus dans des modules assez petits et gérables sans envahir
l’ensemble de la topologie.
La simulation et l’expérience initiale indiquent qu’une simple topologie Star va adapter les performances (et les coûts par poste
de travail virtuel) pour quelques milliers de postes de travail. DataCore publiera les résultats pour étayer ces conclusions
initiales dès leur disponibilité.
Conclusion et orientations futures
Ce livre blanc analyse une architecture VDI reposant sur le logiciel SANmelody de DataCore, Microsoft Windows Server
2008/Hyper-V et un matériel serveur standard. L’outil Virtual Session Indexer (VSI) de Login Consultants est utilisé comme
outil de test.
L’architecture étudiée diffère dans l’ensemble de la majorité des résultats publiés par les autres fournisseurs de stockage. Au
lieu de créer une configuration VDI autour d’un contrôleur de stockage ou d’une architecture SAN préexistante, le réseau SAN
repose sur les serveurs VDI eux-mêmes. Les serveurs VDI agissent en particulier comme des serveurs de virtualisation. Les
résultats obtenus sont près de dix fois supérieurs au ratio prix/performances des autres rapports publiés, tout en réduisant
fortement le nombre de postes de travail virtuels (220) pour lequel de tels résultats sont atteints. L’ensemble est obtenu sur le
matériel le plus simple, au « plus petit dénominateur commun ». Néanmoins, l’environnement semble s’adapter
automatiquement, dans la mesure où il évite les refontes majeures en phase de croissance, tout en restant suffisamment
modulaire pour tolérer les pannes matérielles, les reconfigurations et les anomalies VDI, telles que les « boot storms ».
Quelles sont les perspectives d’avenir ?
Nombre d’optimisations viennent immédiatement à l’esprit. Dans le laboratoire de DataCore, nous avons augmenté avec
succès la densité des postes de travail virtuels de plus de 50 %, pour atteindre le nombre de 175 postes de travail virtuels sur
les mêmes plates-formes de serveurs. Optimisations de la mémoire, matériel amélioré et diverses « astuces » de réglage ont
produit les résultats attendus. Néanmoins, des augmentations en termes de coût et de complexité se traduisent par un
système à peine meilleur en termes de ratio prix/performances que le système testé ici. Pour répondre aux éventuelles
objections, nous avons dû conclure à l’optimisation suffisante de la configuration de base pour atteindre le palier des
configurations VDI pratiques et conclure également que d’autres optimisations de base n’apporteraient que de faibles
améliorations supplémentaires.
Mais qu’en est-il des optimisations de haut niveau ? Bien, peut-être… Le cohébergement du système d’exploitation hôte, de
l’hyperviseur et du serveur de virtualisation, ainsi que des postes de travail virtuels, peut permettre une intégration plus étroite.
D’après notre expérience, toutefois, le fait que ceux-ci demeurent en grande partie indépendants offre à présent un genre tout
à fait différent d’« optimisation ».
L’infrastructure de postes de travail virtuels présente un élément commun avec les autres aspects majeurs de l’évolution
informatique actuelle : le Cloud Computing. Les deux technologies visent à rassembler un très grand nombre de machines du
même type… c’est-à-dire un grand nombre de plates-formes, dont les exigences en termes de ressources sont similaires et
prévisibles à l’avance. Au lieu d’exigences inconnues et hétérogènes, l’objectif repose sur des exigences connues et
homogènes. Dans notre monde, ce qui est « connu » est également pré-configurable.
Il devient ainsi possible d’intégrer un nouveau niveau de virtualisation pour scinder et résoudre l’extraordinaire fait qui frappe
immédiatement toute personne tentant d’exploiter une infrastructure VDI : l’étendue de la gestion individuelle de machines à
composants multiples qui sont néanmoins similaires, paradoxalement.
Que se passerait-il si, au lieu de tenter de gérer individuellement des centaines ou des milliers de machines virtuelles, on
pouvait les diviser en groupes, sous-groupes, « data centers virtuels » ou, selon le jargon de DataCore, en « ruches »
arbitraires, puis traiter l’ensemble de la ruche comme une seule entité ? Dans ce cas, une « ruche » serait constituée d’un
groupe de postes de travail virtuels (50 ou 75 postes de travail virtuels), tous regroupés autour d’un serveur de virtualisation
DataCore et peut-être autour d’autres serveurs nécessaires pour offrir des services locaux… Tous ces serveurs seraient
déployés en tant que machines virtuelles, configurés pour interagir les uns avec les autres et en toute transparence avec
l’environnement matériel sous-jacent. L’ensemble de la ruche serait alors administré, migré et géré en tant qu’une seule unité
et le serveur de virtualisation agirait comme un seul « port » vers le monde externe. Du point de vue de l’environnement, le
seul facteur nécessaire résiderait dans une évaluation approximative de la capacité : deux « ruches » par ici, et quatre autres
par là…
Voici l’orientation future de notre stratégie.
Annexe
Tests et configuration de l’étude
L’outil de tests de performances utilisé pour déterminer le nombre optimal de postes de travail virtuels dans cette
configuration est l’outil de Login Consultants Virtual Session Indexer (VSI) version 2.1.2. L’outil Login VSI crée une charge de
travail utilisateur simulée (Outlook, Internet Explorer, Excel, etc.) sur chaque poste de travail. Les postes de travail consignent
les informations sur les performances dans un dossier commun partagé qui est analysé une fois les tests réalisés.
La charge de travail utilisateur simulée démarre par l’ouverture d’une session de poste de travail distant sur le poste de
travail virtuel. Dans ce cas, le programme VSI Launcher est utilisé dans sa configuration par défaut pour ouvrir les sessions, un
poste de travail toutes les 60 secondes. La charge de travail utilisateur s’exécute en boucle continue de 12 minutes jusqu’à ce
que toutes les sessions de postes de travail soient ouvertes et que la dernière ait fait l’objet d’une boucle.
Une fois que tous les postes de travail virtuels ont exécuté leur charge de travail utilisateur simulée de manière simultanée et
consigné leurs informations dans un dossier partagé, l’outil VSI Analysis se lance. L’outil compile les données dans Excel et
produit un graphique ainsi que des tableaux de temps de réponse, indiquant ainsi une expérience utilisateur satisfaisante ou
non.
Informations de configuration :
Postes de travail virtuels :
Microsoft Windows 7 Enterprise x86 – Configuration avec les optimisations VSI par défaut et celles recommandées dans le
livre blanc du projet Virtual Reality Check « Projet VRC : Phase III » http://www.projectvrc.nl/
Étude :
Login Consultants VSI 2.1.2 http://www.loginǀƐŝ.com/
Sept programmes VSI Launcher furent utilisés sur recommandation de l’outil VSI. Tous les programmes Launcher
fonctionnaient comme des machines virtuelles sur un hôte Hyper-V indépendant des hôtes exécutant les postes de travail
virtuels. Le système d’exploitation de ces machines virtuelles était Microsoft Server 2008 R2.
DataCore SANmelody 3.4 http://www.datacore.com/
Le logiciel SANmelody était exécuté avec deux correctifs inclus dans la mise à jour de maintenance prévue pour ce trimestre.
Analyse de l’outil de test VSI démontrant le fonctionnement opérationnel de 220 postes de travail.
Copyright © 2011 déposé par DataCore Software Corporation.
Tous droits réservés.
DataCore, le logo DataCore, reposant sur la technologie DataCore, SANsymphony et SANmelody sont des marques commerciales ou déposées de DataCore Software Corporation. Les autres noms de produit
ou de service DataCore ou les logos mentionnés dans ce document sont des marques commerciales de DataCore Software Corporation. Les autres noms de produits, de services ou de sociétés mentionnés dans
ce document peuvent être des marques commerciales de leurs détenteurs respectifs.