Virtualisation GPU pour la mise à disposition d`applications 3D à l

Virtualisation GPU pour la mise à
disposition d'applications 3D à
l’AIP-Primeca Dauphiné-Savoie
Thierry HENOCQUE
AIP Primeca DS/Grenoble INP
46 Avenue Felix Viallet
38000 Grenoble
Résumé
La première solution de virtualisation GPU, commercialisée en Juin 2013, a ouvert la voie à la
virtualisation des applications 3D !
L’AIP-Primeca Dauphiné-Savoie, qui est une structure inter-établissements de mutualisation de
ressources dédiées à la mécanique et à la productique et qui distribue des licences auprès des
établissements partenaires pour une trentaine de logiciels, a tout de suite investi dans une architecture de
virtualisation compatible avec les nombreuses applications 3D utilisées dans ces domaines. Après une
année de tests et d’acquisition de compétences sur différentes architectures, une solution a été mise à
disposition des enseignants dès la rentrée 2014.
Motivée par des problématiques techniques de gestion de parc liées à la quantité et à la complexité des
nombreux logiciels distribués, cette architecture novatrice, basée sur une solution Citrix, a
immédiatement répondu à nos attentes sur la gestion et le déploiement des différentes versions de
logiciels.
L’accès distant, indépendant du système d’exploitation et du type de poste client et ne nécessitant pas
d'installation, permet aux enseignants de préparer leurs cours sur la même configuration que celle
utilisée lors des formations. Cet accès permet également aux étudiants d’utiliser leur ordinateur
personnel pour accéder aussi bien aux logiciels qu’à leurs documents de travail.
Ce retour d’expérience apporte des informations techniques sur l'architecture choisie, son
dimensionnement, sa mise en œuvre et les tests de performance qui ont été réalisés pour en assurer son
bon fonctionnement.
Mots-clefs
Virtualisation d'application, accélération graphique, performances, expérience utilisateur, VDI, vGPU
1 Introduction
L’AIP-Primeca est un Groupement d’Intérêt Scientifique créé en 1993 par la fusion des Ateliers InterEtablissements de Productique et des Pôles de Ressources Informatiques pour la MECAnique. Ce réseau
est organisé en pôles régionaux dont la mission est de mutualiser et de mettre à disposition des
compétences et des ressources dans les domaines de la conception intégrée en mécanique et de la
productique au service de l’enseignement, de la recherche et de l’industrie.
Initialement, les plateformes Primeca ont été créées pour mutualiser des stations de travail puissantes type
SGI Octane pour mettre à disposition des établissements des logiciels très onéreux et gourmands en
ressources vidéo tels que CATIA.
JRES 2015 - Montpellier
1/10
L’AIP-Primeca Dauphiné-Savoie est reconnu pour ces ressources relatives au prototypage rapide, à la
fabrication additive (impression 3D) et au prototypage virtuel. Il a la particularité de distribuer un grand
nombre de logiciels métiers sous la forme de jetons de licences et de stations de travail puissantes.
1.1
Evolution du contexte
Avec l’évolution de la puissance des machines dans les composantes, la nécessité de mettre à disposition
des ordinateurs a diminué au profit d’une activité à distance de distribution de jetons de licences de
logiciels, ajoutant une lourde tâche de support à l’installation et de distribution des mises à jours, tant
auprès des enseignants que des informaticiens des établissements partenaires. Les salles informatiques de
l’AIP sont maintenant principalement utilisées pour tous les logiciels pour lesquels le nombre de licences
disponibles est faible et pour les activités de projets qui nécessitent d’être très proche des ressources
matérielles de prototypage.
Le nombre grandissant de logiciels installés pose des difficultés de gestion et de stabilité des postes.
Chaque logiciel arrive avec ses propres services destinés à en optimiser le démarrage, le fonctionnement
et les mises à jour ; il nécessite également ses propres versions de C++, GCC, Python, etc. Lorsque le
nombre de logiciels augmente, les performances de l’ordinateur sont affectées. De plus lors de l’usage
d’un logiciel, une part importante des ressources est consommée par l’ensemble des autres logiciels
installés sur la machine.
Les logiciels étant parfois interdépendants, l’ordre d’installation et de mise à jour est crucial. La mise à
jour d’un seul des logiciels peut nécessiter une réinstallation complète de l’ordinateur, sans garantie de
compatibilité des versions des logiciels entre eux ou pouvant avoir un impact sur le fonctionnement d’un
autre logiciel.
Pour résoudre ces problèmes de compatibilité, la solution consiste à faire tourner les logiciels sur des
systèmes d’exploitation dédiés. La solution qui consiste à virtualiser les bureaux ou les applications
semblait être la seule solution viable, malheureusement elle n’était pas disponible pour les applications
3D du fait de l’absence de carte graphiques sur les serveurs.
La première offre de virtualisation 3D est arrivée en juin 2013. Elle est basée sur un accord entre Citrix et
nVIDIA en apportant la possibilité d’adresser des segments de cartes vidéo Grid-GPU dans des machines
virtuelles installées dans une architecture XenServer et accessible via XenDesktop ou XenApp. Les
solutions basées sur VMware ou Hyper-V ont été disponibles un peu plus d’un an après que nous ayons
lancé le projet.
1.2
Objectifs
Les principaux objectifs du déploiement d’une solution de virtualisation étaient d’économiser du temps
homme sur les installations des logiciels, de fournir une installation fiable et d’augmenter la durée de vie
des ordinateurs par la diminution des besoins en performance.
2 Virtualisation de bureaux et d’applications
Il existe quelques confusions autour du vocable virtualisation qui a tendance à englober beaucoup de
choses. Nous distinguons deux concepts très différents et totalement indépendants qui sont la
virtualisation de système d’exploitation et la mise à disposition de ressources qui peuvent être des
bureaux ou des applications. La distinction est importante car les outils de mise à disposition de
ressources n’impliquent pas forcément qu’elles soient virtualisées. La virtualisation des machines est
parfois indispensable dans les systèmes qui déploient à la volée des machines identiques pour tous les
utilisateurs, mais c’est souvent pour des questions d’optimisation de ressources que l’on a recours à la
virtualisation.
JRES 2015 - Montpellier
2/10
On trouve aussi le terme d’applications virtualisées dans des systèmes qui mettent à disposition des
applications portables.
2.1
Principes de la mise à disposition de bureaux et d’applications
Les principes de mise à disposition de bureaux et d’applications sont utilisés depuis très longtemps. On en
faisait déjà à l’époque des architectures mainframe avec les « terminaux X » ou avec les machines
disposant d’un client X via les commandes « ssh –X » et « ssh –X application ».
La mise à disposition de bureaux consiste à fournir, via le réseau, dans une fenêtre un environnement
graphique complet de la session sur la machine distante alors que la mise à disposition d’applications se
contente de fournir les fenêtres de l’environnement graphique spécifique à l’application qui tourne à
distance dans une session minimale.
Dans un environnement Windows, la mise à disposition de bureaux correspond au service « Bureau à
distance ». Il est disponible en mode mono-utilisateur sur les systèmes d’exploitation clients et en mode
multi-utilisateurs sur les systèmes d’exploitation serveurs. La mise à disposition d’applications, qui n’est
disponible que sur les systèmes d’exploitation serveurs, correspond à la fonctionnalité « RemoteApp » du
même service.
2.2
Virtualisation et optimisation des ressources
L’intérêt majeur de la virtualisation est d’apporter une économie importante en mutualisant entre des
machines virtuelles les composants d’une machine physique (boitier, carte mère, alimentations électrique)
cependant certaines ressources ne sont que partiellement ou pas du tout mutualisables. C’est le cas, entre
autre, du lecteur DVD qui ne peut être affecté qu’à une seule machine virtuelle à la fois.
Les ressources CPU sont très bien mutualisées par le biais des mécanismes natifs de file d’attente d’accès
au processeur, ce qui fait qu’il est courant d’avoir beaucoup plus de processeurs déclarés sur l’ensemble
des machines virtuelles qu’il n’y a de processeurs physiques.
L’espace disque est bien mutualisé, notamment avec la possibilité d’augmenter à chaud les capacités et la
possibilité de partager entre plusieurs machines virtuelle une image partielle. Ces images (snapshot)
offrent aussi une grande souplesse dans la gestion des configurations et des capacités de restauration
d’une configuration antérieure particulièrement rapide.
La mémoire vive peut être partiellement mutualisée avec des mécanismes qui permettent de déclarer un
minimum et un maximum de ressource pour une machine virtuelle. L’usage de ce mécanisme n’est pas
préconisé car le risque en cas de débordement est très important et catastrophique pour la machine
virtuelle qui est supposée disposer d’une ressource qui est en réalité indisponible.
2.2.1
Impact du Système d’exploitation dans la virtualisation de bureaux
La virtualisation de bureaux est disponible sur les systèmes d’exploitation clients et sur les systèmes
d’exploitation serveurs. Dans le cas d’un système type client, il n’y a qu’un seul utilisateur par machine
virtuelle. Il a donc accès individuellement à toutes les ressources de la machine. Dans le cas d’un système
d’exploitation serveur, l’ensemble des ressources, y compris la mémoire vive et la carte graphique du
système, sont partagées entre tous les utilisateurs connectés. L’ensemble des ressources dédiées au
système d’exploitation, telles que l’antivirus ou la communication avec la carte GPU ne sont consommées
qu’une seule fois.
L’utilisation d’un OS serveur est donc un bon moyen d’optimiser et de mutualiser les ressources non
prises en charge par la virtualisation. En contrepartie, le risque qu’un utilisateur consomme toutes les
ressources CPU ou RAM du serveur existe, ce qui a pour effet de perturber le fonctionnement de tous les
autres utilisateurs.
JRES 2015 - Montpellier
3/10
2.2.2
Spécificités liées à la virtualisation des bureaux et des applications
Avec la virtualisation de serveurs, nous avons l’habitude de fonctionner avec des serveurs en cluster, le
plus souvent par grappes de trois serveurs physiques, largement dimensionnés en CPU et en RAM et
raccordés sur une baie réseau de disques pour stocker les machines virtuelles ; le mécanisme de haute
disponibilité se charge alors de migrer les machines virtuelles d’un serveur à un autre en cas de panne.
La virtualisation de bureaux nécessite une architecture différente liée à ces besoins spécifiques en accès
disque et en carte graphique.
2.2.3
Besoins en accès disques
La virtualisation des bureaux nécessite des accès disques rapides et importants lors du démarrage et de
l’exécution des applications. On observe très bien l’importance de ce paramètre depuis l’arrivée des
disques durs SSD. Cette contrainte fait que l’on va devoir travailler sur des disques locaux rapides.
2.2.4
Particularité de la virtualisation GPU
Le mécanisme de virtualisation GPU est en réalité un mécanisme de partage de ressources physiques par
des machines virtuelles. Il s’agit d’un découpage quasi physique d’une ressource (la carte vidéo) en
plusieurs cartes plus petites (qualifiées de vGPU) qui sont rajoutées aux machines virtuelles. C’est
pratiquement comme lorsqu’on affecte une clé USB à un serveur virtuel. La portion de carte vidéo une
fois attribuée n’est plus disponible et aucun remaniement « à chaud » n’est possible. Il est donc exclus de
pouvoir utiliser les mécanismes de haute disponibilité classiques sur une machine virtuelle utilisant une
vGPU.
Actuellement, seulement deux modèles de cartes GPU sont disponibles pour ce type d’architecture. Ce
sont les cartes nVIDIA GPU Grid K1, constituées de 4 cartes Kepler-GK107 avec 768 cœurs CUDA et
16G DDR3 et les cartes nVIDIA GPU Grid K2, constituées de 2 cartes Kepler-GK-104 avec 3072 cœurs
CUDA et 8G GDDR5 de RAM.
Les serveurs rack qui acceptent ce type de carte (PCIe 3.0) peuvent généralement recevoir 2 cartes GPU.
Chaque carte GPU interne peut être divisée en vGPU sans la possibilité de mixer pour un GPU donné des
vGPU de types différents. La figure n° 1 indique les types de découpages vGPU disponibles pour un GPU
GK-104
Figure 1 - Découpages en vGPU disponibles pour un GPU-GK104 (carte Grid-K2)
Il est néanmoins possible de mixer les types de vGPU à l’intérieur d’une carte, par exemple une carte
Grid K2 qui contient 2 cartes GPU-GK104 peut être divisée en 4 vGPU K240 et 2 vGPU K260.
JRES 2015 - Montpellier
4/10
3 Mise en œuvre
3.1
L’architecture de départ
Compte tenu du manque d’expérience sur le déploiement d’architecture de virtualisation d’applications,
l’architecture de départ a été calibrée pour de la virtualisation de bureaux orientés conception avec 2
serveurs d’une capacité de 8 utilisateurs simultanés avec chacun 2 CPU 16 cœurs, 64 Go de RAM et 2
cartes GPU Grid K2. L’investissement de 30K€ a été réalisé en lieu et place du renouvellement de 20
postes type CAO/FAO à 1,5K€.
C’est sur cette architecture que les premiers tests de configuration ont été menés avec une première
version sans virtualisation avec le service RemoteApp sous Windows2008R2. Ce serveur a été utilisé lors
de formations et cette configuration s’est avérée très intéressante, en particulier pour les temps de calcul
sur les logiciels de simulation. Elle a cependant montré quelques défauts, notamment des temps de
réponses un peu lents sur certaines actions telles que les zooms avec la molette de la souris.
L’autre serveur a servi pendant cette première phase de tests de configuration de la solution Citrix
XenServer + XenDesktop/XenApp (seule solution disponible à l’époque pour la virtualisation GPU) pour
la virtualisation de bureaux et d’applications.
3.2
Virtualisation de bureaux vs virtualisation d’applications
Le choix entre ces deux méthodes dépend fortement du contexte. La virtualisation de bureaux offre
l’énorme avantage de cloisonner les ressources et est tout à fait appropriée pour l’enseignement sur des
logiciels peu consommateurs de ressources et en particulier ne nécessitant pas de ressources vidéo. Elle
est aussi adaptée à la fourniture, pour des questions de mobilité, de machines virtuelles individualisées.
Elle résout le problème du nombre de logiciels installés lorsque les enseignements n’utilisent qu’un seul
logiciel spécifique à un moment donné. Elle l’est moins lors d’enseignement utilisant plusieurs logiciels
simultanément car il faudrait éventuellement prévoir une installation par enseignement et non une
installation par logiciel.
La virtualisation d’applications, non préconisée à cause des problèmes de monopolisation de ressources,
nous a semblé néanmoins indispensable pour optimiser les ressources RAM et GPU et pour résoudre les
problèmes liés au nombre de logiciels installés.
3.3
Architecture Citrix XenApp et XenDesktop
L’architecture Citrix peut se décomposer en trois parties.
3.3.1
La virtualisation
L’interface de virtualisation consiste en un système d’exploitation XenServer installé sur les serveurs
physiques et une console d’administration de l’architecture XenCenter. L’interface assez classique permet
de créer et d’administrer l’architecture et les machines virtuelles. Il est indispensable d’avoir un espace de
stockage partagé pour pouvoir créer un cluster.
3.3.2
Le frontal utilisateur
La brique de base est le StoreFront qui distribue les ressources aux utilisateurs authentifiés soit par
l’intermédiaire d’un portail WEB soit directement à partir d’un client lourd (Receiver)
JRES 2015 - Montpellier
5/10
https
ICA/HDX
Netscaler Gateway
https
Internet
Authentification
https
Autorisations
Ressources
Citrix StoreFront
ICA/HDX
Reciever
Clients
Figure 2 - Frontal utilisateur
Le frontal est chargé de récolter les paramètres d’authentification fournis par le client, de lui fournir des
liens vers les ressources auxquelles il est autorisé et de lui fournir les liens vers les sessions (protocole
ICA/HDX) auxquelles il demande l’accès. Ensuite, la communication entre le client Citrix Receiver et
l’agent Citrix Receiver installé sur la ressource est direct.
Pour accéder via internet, sans avoir à ouvrir l’accès aux protocoles d’accès aux ressources, il est possible
d’utiliser un portail supplémentaire (Netscaler Gateway) qui fait office de proxy. Nous n’utilisons pas
cette fonction car nous n’autorisons l’accès qu’aux utilisateurs locaux ou connectés via le VPN de
l’établissement.
3.3.3
Le contrôleur de ressources
Le contrôleur de ressource est l’endroit où l’on va gérer l’ensemble de la configuration de l’architecture
de mise à disposition. Il est totalement lié au système d’authentification Microsoft ActiveDirectory pour
la gestion des utilisateurs, leur authentification, leurs autorisations, mais aussi pour la gestion des
ressources qui doivent être intégrées au domaine. L’administration, constituée d’une MMC (CitrixStudio) pour la configuration et d’une interface WEB (Citrix-Director) pour la gestion de l’activité, peut
être déportée sur un poste d’administrateur.
Licences RDS
Licences KMS
Base MSSQL
Ressources
Frontal
Utilisateur
Serveur
Ordinateurs
Domaine
ActiveDirectory
Authentification
Autorisations
Delivery Controler
Citrix Director
Citrix Studio
Admin
Citrix-Studio
Licences
Citrix
Figure 3 - Le contrôleur de ressources
Une base de données MSSQL est utilisée pour stocker l’ensemble des configurations ainsi que les profils
des utilisateurs.
Les ressources (Windows uniquement) ne sont pas obligatoirement des machines virtuelles Citrix. Elles
peuvent être des machines physiques ou des machines virtualisées sur une architecture VMware ou
Hyper-V. Seules les machines virtuelles peuvent être déployées par clonage, mais là encore, l’architecture
n’est pas limitée par la solution de virtualisation.
JRES 2015 - Montpellier
6/10
3.4
Philosophie et bonnes pratiques de déploiement
Dans l’ordre, on commence par le cluster de virtualisation qui doit être intégré à ActiveDirectory pour
que le contrôleur puisse gérer les machines virtuelles. Ensuite on installe le contrôleur et on termine par
l’installation du frontal.
Des certificats valides sont nécessaires pour pouvoir travailler en HTTPS et certaines fonctionnalités
(comme l’accès direct par le client lourd) ne sont pas disponibles en HTTP.
L’installation des masters est faite en utilisant l’espace de stockage partagé. On y installe dans l’ordre le
système, les outils de communication avec le système de virtualisation, l’antivirus et la carte vidéo.
Attention, la résolution en mode console passe en 2560x1600 lorsque l’on installe les drivers vidéo, il est
donc préférable d’activer le bureau à distance avant de l’installer pour pouvoir accéder à la machine en
bureau à distance.
On installe ensuite les logiciels et l’agent Citrix et on fait un Snapshot de la machine.
Lors du déploiement à partir de la console, on crée un catalogue de machine dans lequel on définit le
nombre de machine à créer à partir du snapshot et d’un profil qui spécifie le vlan et la localisation des
disques. On peut à ce moment changer le nombre de processeurs et la quantité de RAM à affecter à
chaque machine, ainsi que l’OU dans laquelle on doit stocker les comptes d’ordinateur.
Les machines ainsi créées subissent, comme avec sysprep, des modifications destinées à leur déploiement
et à leur gestion par l’infrastructure. Attention, la configuration réseau est forcée en DHCP donc si l’on
désire affecter des adresses fixes, il ne faut pas que le master soit en DHCP, sinon on retrouve des traces
du bail dans la configuration et les machines peuvent prendre l’adresse IP qui lui avait été réservée.
On définit ensuite un groupe de mise à disposition qui va servir à déterminer pour une liste de machines
quelles applications sont disponibles. Le groupe ainsi créé n’intègre pas obligatoirement toutes machines
du catalogue et peut inclure plusieurs catalogues. Par contre, une machine n’appartient qu’à un seul
groupe de mise à disposition.
L’interface de gestion des applications distribuées est identique à la console RemoteApp de Windows
Server.
On peut rajouter des applications manuellement à partir du chemin de l’exécutable et préciser des
paramètres personnalisés.
On définit dans ce groupe de mise à disposition des droits d’accès à partir d’ActiveDirectory en autorisant
des groupes d’utilisateurs à y accéder. Il est possible d’affiner ensuite ces droits application par
application.
Lorsqu’un utilisateur se connecte sur le frontal, il y trouve toutes les applications qu’il est autorisé à
exécuter.
3.5
Gestion des licences
Trois serveurs de licences sont indispensables au fonctionnement de l’architecture (cf. figure 2).
Le serveur de licences Citrix distribue des jetons de licences XenApp ou XenDesktop. La solution Citrix
s’appuie entièrement sur les services Microsoft TSE et RemoteApp. De ce fait, il est nécessaire d’avoir un
serveur de licences RDS pour pouvoir les utiliser.
Etant donné que les machines sont générées à la volée (par clonage) il est nécessaire d’utiliser des
licences KMS, qui, pour les systèmes d’exploitation serveur peuvent être de type DataCenter.
JRES 2015 - Montpellier
7/10
3.6
Partage de charge et tolérance aux pannes
Du fait que nous utilisons des disques locaux et des vGPU, les mécanismes de haute disponibilité basés
sur la migration des VM d’un serveur physique à un autre ne sont pas disponibles. Le partage de charge
se fait par répartition des sessions sur les machines d’un même catalogue.
Les machines virtuelles qui fournissent le service sont des clones avec des disques locaux de « masters »
qui sont stockés et sauvegardés sur une baie externe. En cas de perte totale d’un serveur, on ne perd que
les clones et en cas de perte de la baie, le service continu de fonctionner sur les disques locaux le temps
de restaurer les masters.
4 Tests de performance
Il n’y a pas eu de protocole de tests mis en place, ni de rapports détaillés des résultats. Le principe utilisé
a été de mettre une machine surdimensionnée à disposition de diverses formations avec des enseignants
volontaires pour en étudier le comportement. La surveillance a été menée en direct pour avoir le ressenti
des utilisateurs parallèlement à l’usage des outils de métrologie disponibles sur la console Citrix Studio et
sur le système d’exploitation.
Des problèmes de saturation de la mémoire vidéo ont été observés avec 24 utilisateurs simultanés,
problèmes se traduisant par des bugs d’affichage (des déplacements de fenêtres intempestifs) et par des
temps de latence (images saccadées) importants.
Des problèmes de saturation mémoire et de saturation CPU ont également été observés avec parfois très
peu d’utilisateurs.
Certains logiciels sont capables de réserver la totalité de la mémoire disponible pour accélérer les calculs
d’optimisation. En cas de saturation de la mémoire, l’impact immédiat est un ralentissement pour
l’ensemble des sessions ouvertes et l’interdiction d’en ouvrir de nouvelles.
En cas de saturation CPU par des calculs qui ne rendent pas la ressource, on peut observer un blocage
complet de l’ensemble des sessions ouvertes.
Deux solutions pour résoudre ces problèmes sont possibles.
La première, à mettre en place impérativement, consiste à positionner des stratégies RAM et CPU via le
« Gestionnaire de ressources système Windows ».
La seconde consiste à déporter les calculs sur un serveur de batch dédié. La quasi-totalité des logiciels de
simulation intègrent ce type de configuration. Dans ce cas, l’architecture de virtualisation est là
uniquement pour fournir l’environnement graphique 3D.
5 Dimensionnement de l’architecture
Les résultats des tests ont montré qu’un système Windows2008R2 avec deux ou trois logiciels installés
consomme à vide moins de 1Go de RAM et jusqu’à 4 à 5 Go avec beaucoup de logiciels installés. Pour la
plupart des logiciels de conception en usage pédagogique de base, la consommation n’excède pas 1Go de
RAM par utilisateur.
Il faut réserver 1 CPU pour la communication avec la carte vidéo. La CPU moyenne par utilisateur
dépasse rarement 30%.
Côté GPU, on peut monter sans risque jusqu’à 16 utilisateurs simultanés sur une carte type K280Q
puisque les problèmes sont apparus aux alentours de 24.
Le tableau suivant fait le bilan théorique des ressources nécessaires en fonction des configurations de
cartes vidéo.
JRES 2015 - Montpellier
8/10
GPU
K280
K260
K240
Machines
max
Users Max
/ machine
RAM min /
machine
CPU min /
machine
User
max
RAM
totale
cpu
totale
4
8
16
16
8
4
18
10
6
7
4
3
64
64
64
72
80
96
28
32
48
Ce bilan est un bilan par serveur physique et ne tient pas compte d’une éventuelle réserve destinée à la
tolérance aux pannes. Il est donc important de considérer ce bilan comme étant le bilan en mode dégradé.
On remarque que notre configuration initiale, avec 32 cœurs et 64G de RAM est insuffisante vis-à-vis de
la mémoire vive et qu’il aurait été plus judicieux de partir sur une configuration avec 96 ou 128 Go.
Vu qu’il faut choisir et faire un compromis entre nombre de machines virtuelles (lié au nombre de
logiciels) et performances ou nombre d’utilisateurs, nous utilisons soit des configurations avec des cartes
K260 qui nous permettent d’avoir jusqu’à 8 utilisateurs simultanés, soit des configurations avec des cartes
K240 qui nous permettent d’avoir 4 utilisateurs simultanés.
Dans tous les cas, on crée le nombre de clones nécessaires pour fournir le service demandé au nombre
d’utilisateurs simultanés prévu en privilégiant pour les formations (avec beaucoup d’utilisateurs) des
configurations basées sur des cartes K260.
Notre configuration actuelle est composée de trois serveurs avec chacun 128 Go de RAM, ce qui nous
permet de configurer plus de mémoire vive par utilisateur et de pouvoir fonctionner en mode dégradé
avec potentiellement près de 128 utilisateurs simultanés.
6 Mobilité et enseignement
L’architecture déployée a ouvert des usages nouveaux.
Elle offre la possibilité aux enseignants de préparer leurs cours depuis chez eux, à partir de leur ordinateur
personnel, sur la même installation que celle qui sera utilisée par les étudiants lors de la formation. Il n’y
a donc pas de surprise liée à des paramétrages de menus ou à l’absence de modules ou de fonctionnalités
que l’on peut avoir lorsqu’on passe d’une installation à une autre. Les enseignants disposant d’ordinateur
sous Linux ou sous MacOs ne sont plus limités aux logiciels compatibles avec leur système
d’exploitation. Très rapidement, ceux-ci ont préféré utiliser leur propre ordinateur dans le cadre de cours
dans les salles informatique pourtant équipées d’un poste dédié à l’enseignant.
L’architecture a servi plusieurs fois pour dépanner lors de formations qui avaient été programmées dans
des salles dans lesquelles le logiciel prévu n’était pas correctement installé.
La période la plus intéressante reste le second semestre qui est essentiellement dédiée aux projets des
étudiants. Période pendant laquelle les étudiants conçoivent et réalisent en groupes des prototypes.
Période pendant laquelle ils utilisent fréquemment leurs ordinateurs personnels, ce qui leur permet de
continuer de travailler chez eux sur les documents d’études ainsi que sur leurs rapports.
Ils ont donc très rapidement utilisé l’architecture de virtualisation pour réaliser leurs travaux de
conception.
Grâce à cette architecture, ils ne sont plus limités aux salles informatiques spécialisées, et peuvent
travailler en Wi-Fi autour de grandes tables, plus pratiques pour le travail en groupe. Lorsqu’ils ont des
questions à poser à un enseignant concernant leur modèle, ils se déplacent avec leur portable jusqu’à
l’enseignant pour le lui montrer sans que celui-ci n’ait besoin de se déplacer jusqu’à l’ordinateur fixe sur
lequel l’étudiant aurait travaillé sans virtualisation.
JRES 2015 - Montpellier
9/10
7 Conclusion et perspectives
L’architecture a répondu tout de suite aux attentes en terme de stabilité et de simplification des
installations. Elle apporte une très grande réactivité sur les mises à jour des logiciels et permet lorsque
nécessaire de mettre à disposition plusieurs versions du même logiciel. En dehors du temps passé pour la
mise en place et l’acquisition des connaissances nécessaires au fonctionnement de l’architecture, le temps
économisé, notamment sur la période estivale qui était consacrée aux mises à jour, est très important.
Les salles informatiques qui n’ont pas été remplacées à cause de l’investissement associé à cette
architecture fonctionnent avec une installation minimale du système d’exploitation et d’un antivirus.
L’adhésion des enseignants est totale et l’architecture donne satisfaction lors des enseignements.
Ce type de solution est totalement en accord avec la tendance actuelle à l’usage de portables de plus en
plus légers qui est probablement liée à ce retour vers des architectures centralisées.
L’architecture déployée a été utilisée par l’AIP-Primeca de Nantes pour valider la faisabilité de la
virtualisation du client CATIA-V6. Elle peut servir pour d’autres établissements à en valider et en vérifier
les performances.
Son administration nécessite encore beaucoup d’interventions pour adapter les ressources des machines
aux besoins en fonction des réservations de ressources ; nous travaillons actuellement sur l’automatisation
de ces tâches.
JRES 2015 - Montpellier
10/10