Post on 21-Jul-2021
DÉPARTEMENT INFORMATIQUE – IUT 2 GRENOBLE
Année universitaire 2017-2018
MÉMOIRE DE STAGE
CONCEPTION ET DÉVELOPPEMENT D’UNE INTERFACE DE
GESTION DES RESSOURCES DANS UNE ARCHITECTURE DE
VIRTUALISATION BASÉE SUR CITRIX XENAPP
Du 24 avril au 29 juin
AIP Primeca Dauphiné-Savoie
Présenté par
Emile CALIXTE
Jury
IUT : Mme Michelle ROSSET
IUT : M. Jérôme GOULIAN
AIP Primeca : M. Thierry HENOCQUE
Emile CALIXTE Mémoire de stage 2017-2018
Page 2 sur 39
Déclaration de respect des droits d’auteurs
Emile CALIXTE Mémoire de stage 2017-2018
Page 3 sur 39
Remerciements
Je tiens à remercier ma tutrice de stage, Mme. Michelle ROSSET, pour le temps qu’elle m’a
consacré et les conseils qu’elle m’a apportés au cours de mon stage.
Un grand merci à mon maitre de stage, M. Thierry HENOCQUE, pour son accueil et les
connaissances qu’il m’a apportées.
Enfin, je remercie les responsables de la plateforme GINOVA d’AIP Primeca pour leur
gentillesse et leur bienveillance.
Emile CALIXTE Mémoire de stage 2017-2018
Page 4 sur 39
Sommaire
Déclaration de respect des droits d’auteurs ................................................................................ 2
Remerciements ........................................................................................................................... 3
Sommaire ................................................................................................................................... 4
Résumé ....................................................................................................................................... 5
Introduction ................................................................................................................................ 6
I. Présentation et analyse de l’existant ................................................................................. 10
I.1 Architecture informatique actuelle ............................................................................ 10
Structure des machines virtuelles ..................................................................................... 10
Métrologie ........................................................................................................................ 14
I.2 Problématique et objectif du stage ............................................................................. 14
II. Réalisation ........................................................................................................................ 16
II.1 Prise en main de l’architecture et création d’une première interface ........................ 16
II.2 Conception du modèle de données et développement de l’interface ......................... 18
Modèle de données ........................................................................................................... 18
Alimentation de la base de données ................................................................................. 20
Application web ............................................................................................................... 20
II.3 Problèmes rencontrés ................................................................................................. 26
II.4 Tâches restantes ......................................................................................................... 27
Conclusion ................................................................................................................................ 28
Glossaire ................................................................................................................................... 29
Webographie ............................................................................................................................ 31
Table des figures ...................................................................................................................... 32
Annexes .................................................................................................................................... 33
Abstract .................................................................................................................................... 39
Emile CALIXTE Mémoire de stage 2017-2018
Page 5 sur 39
Résumé
J’ai effectué mon stage à l’AIP Primeca (Atelier Inter-établissements de Productique et Pôle de
Ressources Informatiques pour la MECAnique) Dauphiné-Savoie. Il s’agit d’un des neuf pôles
régionaux de l’AIP Primeca. L’AIP Primeca est un réseau national inter-établissements de
mutualisation de ressources dans les domaines de la conception mécanique et de la productique.
La plateforme Tricholome d’AIP Primeca Dauphiné-Savoie met à disposition des logiciels
professionnels qui sont virtualisés et accessibles depuis n’importe quel appareil. Ces logiciels
sont installés sur une centaine de machines virtuelles, elles-mêmes hébergées sur sept serveurs
physiques puissants. Cette architecture de virtualisation repose sur le logiciel Citrix XenApp,
qui permet d’accéder à distance à des applications.
Le nombre d’utilisateurs de l’architecture grandissant implique d’avoir de plus en plus de
machines virtuelles, ce qui complique la gestion et l’administration de l’architecture. Ma
mission pendant ce stage est donc de concevoir et réaliser une interface d’affichage synthétique
de l’organisation des machines virtuelles et de leur état (nombre d’utilisateurs connectés et état
de marche). Cette interface doit aussi permettre d’effectuer des actions sur les machines : les
démarrer, les arrêter, les mettre en mode maintenance (plus personne ne peut s’y connecter), et
tuer les sessions plantées.
Pour atteindre cet objectif, il a d’abord fallu créer une base de données dans laquelle l’interface
viendra chercher les informations. Comme une base de données avait déjà été mise en place
dans le but d’en sortir des statistiques concernant l’utilisation de l’infrastructure (nombre
d’utilisateurs simultanés, nombre d’utilisateurs par jour, logiciels utilisés...), je m’en suis
inspiré en simplifiant sa structure et en ajoutant des colonnes pour les données manquantes et
dont l’interface aurait besoin. Cette base de données est alimentée par un script PowerShell, qui
est exécuté toutes les cinq minutes et qui va récupérer les informations dans l’architecture grâce
à des commandes fournies par Citrix pour mettre à jour la base. Je me suis également inspiré
du script existant pour créer le mien.
L’interface en elle-même a été réalisée avec les standards du web : HTML et CSS pour la
structuration et la mise en forme des pages, PHP pour générer les pages via le serveur, MySQL
pour enregistrer les données et JavaScript pour afficher la vue dynamiquement et permettre à
l’interface d’être plus interactive (notamment en permettant d’actualiser instantanément et de
changer le groupe de machines qui est affiché sans avoir à recharger la page).
Cette interface permet donc d’afficher une vue synthétique des machines de chaque modèle de
machines (appelé master) ainsi que les groupes d’utilisateurs qui ont accès à ces machines. Elle
permet également d’afficher les détails de chaque machine, et une vue d’ensemble des différents
masters. Elle facilite grandement les tâches d’administrations de l’infrastructure, puisqu’elle
permet d’afficher les machines d’une manière différente de l’interface Citrix, qui pour certaines
tâches ne répond pas aux besoins des administrateurs de la plateforme.
Ce stage fut très enrichissant et instructif pour moi, puisqu’il m’a permis d’appliquer les
connaissances que j’ai acquises au cours de mes deux années d’IUT Informatique, de découvrir
le monde du travail en informatique et de développer mon autonomie. J’ai également découvert
de nouvelles technologies et une nouvelle façon de mettre à disposition des logiciels.
Emile CALIXTE Mémoire de stage 2017-2018
Page 6 sur 39
Introduction
Dans le but de valider leur DUT Informatique, les étudiants de deuxième année doivent
effectuer un stage en entreprise d’une durée de dix semaines au minimum. Ce stage est
l’occasion pour les étudiants d’avoir une première approche du monde du travail en
informatique, et d’appliquer les connaissances qu’ils ont acquises pendant ces deux années
d’études. J’ai effectué mon stage à l’AIP Primeca Dauphiné-Savoie, dans la plateforme
Tricholome située au 46 avenue Félix Viallet à Grenoble, dans l’enceinte de l’INP.
L’AIP Primeca (Atelier Inter-établissements de Productique et Pôle de Ressources
Informatiques pour la MECAnique) est un réseau national inter-établissements créé en 1993
dont l’objectif est de mutualiser des ressources et de les mettre à la disposition des étudiants et
des chercheurs dans les domaines de la conception et de la production de produits manufacturés.
Les plateformes Primeca ont été initialement créées pour mettre en commun des stations de
travail puissantes et mettre à disposition des logiciels onéreux qui nécessitent une grande
quantité de ressources. Ces logiciels sont mis à disposition sous forme de licences flottantes1.
L’AIP Primeca est divisé en plusieurs pôles répartis en France, dont le pôle Dauphiné-Savoie
qui est structuré en six plateformes thématiques localisées sur Grenoble, Saint-Martin-d’Hères
et Annecy2.
Les différentes plateformes du pôle Dauphiné-Savoie proposent chacune des services
spécifiques3 :
• Plateforme CIM : cette plateforme propose des équipements matériels et logiciels dans
les domaines de la commande, de la supervision, de l’ordonnancement et de
l’optimisation des systèmes de production.
• Plateforme GINOVA : cette plateforme propose des équipements dans le domaine du
R&D (Recherche et Développement), notamment la réalisation de prototypes, la réalité
virtuelle ou encore la rétroconception.
• Plateforme MOCN : cette plateforme propose des services pour l’usinage de précision
et la métrologie des pièces.
• Plateforme SeISM : cette plateforme permet aux étudiants de comparer des résultats de
simulations numériques et des résultats expérimentaux mesurés sur de vrais systèmes.
L’objectif de cette plateforme est de « développer l’esprit critique des étudiants face aux
outils purement numériques » et « utiliser les résultats expérimentaux mesurés sur le
système physique afin de caler le modèle numérique afin qu’il soit représentatif du
comportement réel du mécanisme ».
• Plateforme Annecy : cette plateforme met à disposition des moyens matériels et
logiciels dans les domaines de la conception et de la production mécanique.
• Plateforme Tricholome : cette plateforme met à disposition des logiciels professionnels
qui recouvrent les thématiques de l’AIP Primeca Dauphiné-Savoie. La particularité de
cette plateforme est qu’elle distribue les applications sous forme virtualisée4, accessibles
depuis un simple navigateur web et sans installation.
1 Voir glossaire – Licence flottante 2 Voir webographie – Présentation de l’AIP Primeca Dauphiné-Savoie 3 Voir webographie – Présentation des plateformes de l’AIP Primeca Dauphiné-Savoie 4 Voir glossaire – Virtualisation
Emile CALIXTE Mémoire de stage 2017-2018
Page 7 sur 39
Figure 1 : Emplacements des plateformes d’AIP Primeca à Grenoble
Mon stage s’est déroulé sur la plateforme Tricholome, qui n’a pas de localisation physique mais
qui est gérée depuis un bureau de la plateforme GINOVA, qui se situe dans l’enceinte de l’INP
au 46 avenue Félix Viallet à Grenoble.
La plateforme Tricholome a obtenu le statut de plateforme fin 2016, mais existe depuis 2013.
C’est Thierry HENOCQUE, mon maître de stage, qui est à l’origine de cette plateforme. La
problématique était la suivante : étant donné que chaque logiciel installé sur une machine utilise
des services d’optimisation de démarrage et de fonctionnement qui lui sont propres, et que
chacun de ces logiciels nécessite des versions spécifiques de C++, du framework .NET, etc., la
quantité grandissante de logiciels installés sur chaque machine pose des problèmes de stabilité
et de gestion.
Aussi, le nombre important de logiciels installés avaient une influence négative sur les postes
sur lesquels ils étaient installés : en effet, lors de l’exécution d’un logiciel, une part importante
des ressources de la machine est utilisée pour les autres logiciels. Parfois même, les logiciels
sont interdépendants et il faut suivre un ordre d’installation et de mise à jour précis pour assurer
le bon fonctionnement de ces programmes. La maintenance des postes dans les salles
informatiques était donc de plus en plus complexe, c’est pourquoi il a fallu trouver une
alternative.
Une solution intéressante était la virtualisation1 : au lieu d’installer tous les logiciels nécessaires
sur une machine, on les installe séparément sur des systèmes d’exploitation dédiés. Avant 2013,
cette solution était disponible uniquement pour les applications ne nécessitant pas de ressources
graphiques. Il était alors impossible de mettre à disposition des logiciels de conception tels que
SolidWorks, CATIA, etc.
1 Voir glossaire – Virtualisation
Emile CALIXTE Mémoire de stage 2017-2018
Page 8 sur 39
En juin 2013, un accord est passé entre Citrix1 et Nvidia2, qui permet d’utiliser des GPU3 Nvidia
dans des serveurs pour faire de la virtualisation 3D. C’est alors à cette période que Thierry
HENOCQUE a décidé d’installer une infrastructure de virtualisation pour les logiciels de l’AIP
Primeca4. En octobre 2013, il recevait ses deux premiers serveurs.
D’octobre 2013 à février 2014, des tests concernant différentes solutions ont été effectués : du
simple bureau à distance à de la virtualisation d’applications, c’est finalement la solution
d’applications à distance de Citrix qui a été adoptée. Cet outil permet de gérer facilement les
différentes machines virtuelles et de mettre à disposition des applications. En septembre 2014,
l’architecture Citrix était en place et les machines virtuelles étaient accessibles aux enseignants,
à quelques doctorants et depuis une vingtaine de postes dans une salle informatique.
A partir de février 2015, l’existence de cette infrastructure est annoncée publiquement, et 90
étudiants de deuxième année de Génie Industriel l’utilisent régulièrement. Progressivement, des
serveurs sont ajoutés à l’architecture et de plus en plus d’étudiants l’utilisent. En septembre
2016, les étudiants de deuxième et de troisième année de Génie Industriel, mais aussi des
étudiants de PhITEM utilisent ce service.
En novembre 2016, Tricholome est officiellement une plateforme à part entière de l’AIP
Primeca Dauphiné-Savoie. Depuis septembre 2017, la plateforme est accessible à tous les
étudiants de Génie Industriel, et également depuis une salle informatique équipée de Raspberry
Pi5.
Aujourd’hui, l’architecture informatique compte environ une centaine d’utilisateurs simultanés
en moyenne, et 40 000 sessions par an. Elle peut supporter 250 utilisateurs simultanés. Le
nombre d’utilisateurs référencés est d’environ 800, avec presque 900 machines utilisatrices.
Figure 2 : Nombre de sessions Citrix par jour du 23 novembre 2017 au 20 mai 2018
1 Voir glossaire – Citrix Systems 2 Voir glossaire – Nvidia 3 Voir glossaire – GPU 4 Voir webographie –Virtualisation GPU pour la mise à disposition d’applications 3D à l’AIP-Primeca Dauphiné-
Savoie 5 Voir glossaire – Raspberry Pi
Emile CALIXTE Mémoire de stage 2017-2018
Page 9 sur 39
Une telle architecture n’est pas courante, mais confère de nombreux avantages pour les
utilisateurs comme pour l’administrateur : du côté des utilisateurs, ceux-ci peuvent se connecter
et utiliser les logiciels qu’ils souhaitent depuis n’importe quel appareil, sans aucune installation
nécessaire. La puissance de l’appareil client et son système d’exploitation n’importent pas
puisqu’il ne sert que d’affichage du logiciel. Du côté de l’administrateur, cette architecture lui
permet de déployer des groupes de machines virtuelles, machines qui seront accessibles à des
groupes d’utilisateurs. Cette séparation en plusieurs machines virtuelles permet de ne pas avoir
tous les logiciels installés sur les mêmes machines et donc d’éviter les problèmes de
compatibilité, de performances et de gestion évoqués précédemment.
Au cours de ce mémoire, nous aborderons dans un premier temps l’architecture informatique
actuelle, la problématique et l’objectif du stage. Nous verrons ensuite ce que j’ai réalisé pendant
mon stage ainsi que les quelques problèmes qui ont été rencontrés et les tâches restantes.
Emile CALIXTE Mémoire de stage 2017-2018
Page 10 sur 39
I. Présentation et analyse de l’existant
A mon arrivée, une architecture conséquente était déjà en place. Nous allons voir dans cette
partie comment se présente cette infrastructure de virtualisation, et quelle était la problématique.
I.1 Architecture informatique actuelle
Structure des machines virtuelles
Comme exposé en introduction, l’architecture informatique actuelle repose sur Citrix XenApp.
Il s’agit d’un logiciel développé par la société Citrix Systems, qui permet d’accéder à distance
à des applications depuis un client léger1. Pour l’utilisateur, le principe est très simple : il doit
uniquement télécharger et installer le logiciel Citrix Receiver (il s’agit de la partie « client » de
Citrix XenApp). Une fois connecté sur l’interface, l’utilisateur n’a qu’à sélectionner le logiciel
qu’il souhaite utiliser, qui se lance alors instantanément. Ce programme est disponible sur
Windows, macOS, Linux, mais aussi sur Android, iOS et Windows Phone, ce qui permet une
véritable portabilité de tous les logiciels qui sont mis à disposition via l’infrastructure.
La connexion sur une machine virtuelle est totalement transparente pour l’utilisateur : c’est
Citrix XenApp qui se charge automatiquement de lui attribuer la machine la moins chargée lors
de sa connexion.
Du côté de l’administration, la tâche est un peu plus complexe puisqu’il faut déployer des
machines en y installant les logiciels nécessaires et en gérant les ressources qu’on leur alloue
en fonction de l’utilisation qui en sera faite. Ces machines sont hébergées sur des serveurs
physiques puissants, mais de configuration matérielle différente2, ce qui implique que les
configurations logicielles des machines sont différentes selon le serveur sur lequel elles sont
hébergées. Pour ne pas s’y perdre, il existe une structure d’organisation bien spécifique qui
permet de regrouper les machines en fonction de leur configuration (configuration
« matérielle », c’est à dire les cœurs3 de processeurs4 alloués, la mémoire5 allouée, etc., mais
aussi leur système d’exploitation6), des logiciels qui y sont installés et des serveurs physiques
sur lesquels elles sont hébergées.
Tout d’abord, on définit les principaux types de machines qui vont être créées. Dans cette
architecture, trois grands types de machines ont été définis :
• Machines de calcul 3D : il s’agit des machines qui demandent le plus de ressources.
Elles ont besoin d’une grande quantité de ressources graphiques7, de CPU (processeurs)
et de mémoire
• Machines de CFAO (Conception et Fabrication Assistées par Ordinateur) : ces
machines demandent principalement des ressources CPU et de la mémoire
• Machines de simulation 2D et de bureautique : ces machinent demandent plus ou moins
de ressources CPU
1 Voir glossaire – Client léger 2 Voir annexe A – Configuration des serveurs physiques 3 Voir glossaire – Cœur 4 Voir glossaire – CPU (processeur) 5 Voir glossaire – RAM (mémoire vive) 6 Voir glossaire – Système d’exploitation 7 Voir glossaire – GPU (processeur graphique)
Emile CALIXTE Mémoire de stage 2017-2018
Page 11 sur 39
Une fois qu’on a défini les principaux types de machines, on crée des « masters1 ». Un master
est une machine « modèle », qui sera ensuite dupliquée pour créer les machines virtuelles.
Concrètement, lorsqu’on veut déployer de nouvelles machines, on va d’abord créer une
machine virtuelle sur laquelle on installe le système d’exploitation (Windows en l’occurrence),
et les logiciels qui seront mis à disposition sur les machines. Cette machine ne sera pas
directement utilisée, elle sera dupliquée en « snapshots2 ».
Un snapshot est une image système de la configuration d’un master, comportant les pilotes3
nécessaires au bon fonctionnement de la machine sur un serveur physique. Un snapshot n’est
utilisable que sur un serveur physique identique à celui sur lequel était hébergée la machine
virtuelle d’origine, puisqu’il contient les pilotes destinés au bon fonctionnement de la machine
sur ce serveur, pilotes qui diffèrent selon la configuration matérielle du serveur.
Les snapshots sont ensuite dupliqués en plusieurs machines identiques, qui elles, seront utilisées
par les utilisateurs. On a donc une structure semblable à ceci :
Figure 3 : Schéma récapitulatif d’un exemple de déploiement des masters et des snapshots
Deux masters sont représentés sur ce schéma, chacun contenant deux snapshots. Comme on
peut le voir, il est tout à fait possible de créer plusieurs snapshots de masters différents sur un
même serveur physique. On va ensuite créer des groupes de machines, qui seront des
duplications des snapshots (pour rappel, un snapshot est une image disque d’une machine, une
copie, qui contient un système d’exploitation, des pilotes et des logiciels).
1 Voir glossaire – Master 2 Voir glossaire – Snapshot 3 Voir glossaire – Pilote (driver)
Emile CALIXTE Mémoire de stage 2017-2018
Page 12 sur 39
Une dernière étape consiste à créer, pour chaque snapshot, des sous-groupes appelés
« catalogues ». Un catalogue est un groupe de machines identiques (donc créées à partir d’un
même snapshot) hébergées sur le même serveur physique (on rappelle que les machines d’un
snapshot peuvent être hébergées sur des serveurs physiques différents ci ceux-ci sont
identiques). On peut donc avoir une structure semblable à celle-ci :
Figure 4 : Schéma récapitulatif d’un exemple de déploiement des catalogues
Comme on peut le voir, il est possible de créer plusieurs catalogues de machines hébergées sur
plusieurs serveurs. Sur ce schéma, en considérant que les serveurs s1 et s3 ont la même
configuration matérielle, on a donc deux catalogues de machines qui seront hébergées sur les
serveurs s1 et s3, alors que les machines de ces deux catalogues ont été créées à partir d’un
même snapshot, lui-même créé sur le serveur s1.
Le principal intérêt des catalogues est de faciliter les mises à jour des serveurs physiques. En
effet, lors d’une mise à jour de l’architecture (mise à jour du système d’exploitation XenServer
de Citrix), il faut mettre à jour les serveurs physiques ce qui implique généralement une mise à
jour les machines qui y sont hébergées. Séparer les machines en différents catalogue est alors
une bonne solution pour effectuer les mises à jour sans avoir à interrompre le service.
Une fois qu’on a nos machines subdivisées en différents snapshots et en différents catalogues,
il faut attribuer ces machines à des groupes de mise à disposition1 : il s’agit de groupes
d’utilisateurs auxquels on attribue des machines. Par exemple, on peut créer un groupe
« Bureautique » qui aura accès à des machines sur lesquelles sont installés les logiciels de
bureautique (Microsoft Word, etc.).
1 Voir glossaire – Groupe de mise à disposition
Emile CALIXTE Mémoire de stage 2017-2018
Page 13 sur 39
Les utilisateurs peuvent faire partie de plusieurs groupes de mise à disposition, on crée donc
généralement un groupe de mise à disposition par thème (bureautique, CAO...). Il est également
possible, si on le souhaite, de spécifier pour un groupe de mise à disposition quelles applications
sont disponibles ou non.
Une fois les groupes de mise à disposition créés et les machines attribuées, on obtient donc une
structure que l’on peut schématiser comme ceci :
Figure 5 : Schéma synthétique des groupes de mise à disposition
Comme on peut le voir, un groupe de mise à disposition peut avoir plusieurs machines
(représentées par les cercles jaunes) de plusieurs catalogues, snapshots et masters différents (sur
ce schéma, les snapshots A et B ne sont pas forcément issus du même master). Les machines
non attribuées sont celles qui ne sont attribuées à aucun groupe de mise à disposition, et qui ne
sont donc pas accessibles aux utilisateurs.
Pour gérer toute cette architecture, Citrix met à disposition plusieurs interfaces d’administration
qui permettent :
• D’afficher la liste des groupes de mise à disposition
• D’afficher la liste des catalogues
• D’afficher la liste des machines d’un groupe de mise à disposition
• D’afficher la liste des machines d’un catalogue,
• D’obtenir les détails d’une machine :
o Sa configuration matérielle, logicielle et réseau
o Les sessions en cours sur cette machine
o Son catalogue et son groupe de mise à disposition
• D’effectuer des actions sur une machine :
o La démarrer et l’arrêter
o Activer le mode maintenance (ce mode permet d’empêcher toute nouvelle
connexion sur cette machine ; il est utile lorsqu’on souhaite attendre la fermeture
des sessions en cours avant d’arrêter la machine)
o Tuer une session plantée
o Changer son groupe de mise à disposition
• De créer des nouveaux masters, snapshots et machines
Emile CALIXTE Mémoire de stage 2017-2018
Page 14 sur 39
Ces interfaces, très complètes, permettent donc d’effectuer toutes les tâches d’administrations
de l’architecture. Toutefois, pour certaines tâches, elles ne sont pas adaptées au mode de
fonctionnement défini par les administrateurs, et ne permettent pas d’avoir accès rapidement à
certaines informations importantes.
Métrologie
Citrix XenApp met à disposition une multitude de commandes PowerShell12 qui permettent
d’obtenir toutes les informations que l’on peut obtenir avec l’interface classique. En réalité,
l’interface Citrix utilise ces mêmes commandes pour obtenir les informations désirées, qui sont
ensuite affichées de façon plus visuelle.
Figure 6 : Résultat d’une commande PowerShell : quelques informations sur une machine
Pour obtenir des statistiques concernant l’utilisation de l’infrastructure par les utilisateurs, une
base de données a été mise en place3 par mon maitre de stage. Elle est régulièrement alimentée
par un script PowerShell qui utilise les librairies Citrix XenApp et l’outil « Connector/Net » de
MySQL4, et qui est exécuté toutes les cinq minutes via le planificateur de tâches Windows, sur
un serveur. Cette base de données permet donc d’obtenir facilement un historique des sessions
et des statistiques (comme la figure 1 vue en introduction).
Cette base de données contient, entre autres, une table pour les machines, une pour les
catalogues, une pour les groupes de mise à disposition et deux pour les sessions (une pour les
sessions en cours, et une pour l’historique des sessions). Il y a une troisième table pour les
sessions (« Last_sessions »), qui n’est utilisée que pour du traitement : à chaque fois que le
script de mise à jour de la base de données est exécuté, il copie la table des sessions courantes
dans la table « Last_Sessions », puis met à jour la table des sessions courantes, puis compare
les deux pour savoir lesquelles ont été fermées.
I.2 Problématique et objectif du stage
Avec plus d’une centaine de machines dans l’architecture actuelle, l’administration des
machines et leur organisation est de plus en plus complexe. En effet, bien que Citrix mette à
disposition des interfaces d’administration très complètes, celles-ci ne répondent pas à certains
besoins des administrateurs. En effet, il n’est pas possible de visualiser d’un coup d’œil les
machines dans leur ensemble, avec leur état (par état d’une machine, nous entendons son état
d’alimentation : allumée ou éteinte, mais également sa charge : le nombre de sessions ouvertes
sur la machine). Par conséquent, il arrive fréquemment qu’une machine soit surchargée car elle
était la seule disponible dans un catalogue pour un groupe de mise à disposition, et que trop
d’utilisateurs aient eu besoin subitement d’utiliser les logiciels de cette machine dans ce groupe
de mise à disposition.
1 Voir glossaire – Windows PowerShell 2 Voir annexe B – Détails de quelques commandes PowerShell fournies par Citrix XenApp 3 Voir annexe C – Schéma de la base de données existante 4 Voir glossaire – MySQL
Emile CALIXTE Mémoire de stage 2017-2018
Page 15 sur 39
Une quantité insuffisante de machines disponibles peut survenir dans deux cas :
• Des machines sont éteintes
• Des machines sont en mode maintenance alors qu’elles ne devraient pas l’être
o Parce qu’on l’a activé en attendant que les utilisateurs se déconnectent pour
l’éteindre
o Parce qu’on a démarré la machine sans désactiver le mode maintenance
Dans les deux cas, cela pose alors des problèmes de performances et de stabilité sur les
machines surchargées, et il faut attendre que le problème soit signalé – ou qu’il soit détecté par
hasard – pour qu’il soit corrigé par l’ajout d’une ou plusieurs machines.
Avec une vue synthétique, semblable au schéma vu précédemment1, qui montrerait non
seulement l’organisation des machines dans les catalogues et les groupes de mise à disposition,
mais aussi leur état avec leur charge, on pourrait voir d’un simple coup d’œil s’il y a des
machines surchargées, ou des machines qui sont en mode maintenance. Cela permettrait donc
de détecter rapidement les problèmes et de les corriger.
Ma mission, pendant ces dix semaines, est de concevoir et de commencer à développer une
interface web qui simplifierait l’administration de l’architecture, en ayant une vue synthétique
de l’état des machines (leur état d’alimentation, leur charge...). Cette interface permettra
également d’effectuer des actions sur les machines : les arrêter, les démarrer, activer le mode
maintenance et tuer les sessions plantées.
Mon travail peut se découper en deux principales parties :
• Conception d’un modèle de base de données adapté : en effet, la base de données
actuelle contient des tables2 vides et des données inutilisées. Elle contient également des
données redondantes, qui permettaient de visualiser plus facilement les informations sur
phpMyAdmin3. Il s’agit donc de refaire une base de données propre, sans redondance
de données (qui ne sera plus nécessaire puisque toutes les informations seront visibles
depuis l’application web)
• Développement du script PowerShell d’alimentation de la nouvelle base de données
• Développement de l’application web se basant sur la base de données
L’application web ne sera pas accessible à tous : une personne qui voudra y accéder devra
s’authentifier sur le domaine de l’AIP Primeca Dauphiné-Savoie (domaine AIPDS).
Ma réalisation s’inscrira dans un gros projet, que je vais seulement commencer durant mon
stage. D’autres personnes viendront ensuite développer les autres fonctionnalités faisant suite à
ce que j’ai commencé : réservation des machines par les utilisateurs, puis automatisation des
démarrages et arrêts des machines en fonction de la charge et des réservations. Je dois donc
fournir un code clair, documenté et qui respecte les règles de nommage que nous avons définies.
1 Voir figure 5 – Schéma synthétique des groupes de mise à disposition 2 Voir glossaire – Table 3 Voir glossaire – phpMyAdmin
Emile CALIXTE Mémoire de stage 2017-2018
Page 16 sur 39
II. Réalisation
Pour résoudre cette problématique, j’ai développé une application web qui affiche une vue
synthétique de l’état des machines et des masters. Nous verrons dans cette partie comment j’ai
pris en main les commandes fournies par Citrix, puis nous parlerons de la conception de la base
de données et de la réalisation de l’interface.
II.1 Prise en main de l’architecture et création d’une première interface
Lorsque je suis arrivé, il m’a d’abord fallu bien comprendre l’organisation de l’infrastructure
et son fonctionnement, décrits en première partie. Pour ce faire, après des explications et des
démonstrations de mon maitre de stage, j’ai commencé à travailler sur une interface basique
répertoriant la liste des machines de l’infrastructure. Cette interface se basait sur une copie de
la base de données existante, dans laquelle il y avait plus de 20 000 enregistrements d’historique
de sessions.
Au bout d’une petite semaine de travail, l’interface permettait déjà d’obtenir la liste des
machines, qu’on pouvait trier et filtrer selon différents critères (voir figure ci-après), la liste des
catalogues, et les informations détaillées de chaque machine.
Figure 7 : Capture d’écran de la liste des machines sur la première interface
Emile CALIXTE Mémoire de stage 2017-2018
Page 17 sur 39
Figure 8 : Capture d’écran de la liste des catalogues sur la première interface
Pour le développement de l’application, les langages HTML1 et PHP2 étaient imposées pour
réaliser une interface web se basant sur des données enregistrées dans une base de données
MySQL3. Dans le but d’obtenir une interface plus dynamique et interactive, j’ai proposé
d’ajouter du JavaScript4, proposition qui a été acceptée.
Une grosse partie de l’application est donc construite en JavaScript (le programme s’exécute
du côté de l’utilisateur). Cela permet à l’interface d’être très dynamique et de s’actualiser
automatiquement régulièrement, sans que l’utilisateur soit obligé de rafraichir la page.
Concrètement, au chargement de la page, c’est le script JavaScript qui construit la vue en
effectuant une requête AJAX5 (requête asynchrone au serveur) et en affichant le résultat sous
forme visuelle.
Figure 9 : Schéma récapitulatif de la construction d’une page de l’interface
1 Voir glossaire – HTML 2 Voir glossaire – PHP 3 Voir glossaire – MySQL 4 Voir glossaire – JavaScript 5 Voir glossaire – Requête AJAX
Emile CALIXTE Mémoire de stage 2017-2018
Page 18 sur 39
Cette interface était un exercice demandé pour me familiariser avec le fonctionnement de
l’architecture. En explorant la base de données existante, et en testant des commandes
PowerShell pour voir ce qu’il en résultait, j’ai ainsi pu bien comprendre l’architecture et les
besoins de mon maitre de stage. Cela m’a également permis de visualiser la manière dont j’allais
concevoir mon application, et de confirmer mon intention de développer l’application avec les
technologies choisies initialement, qui m’ont semblées parfaitement adaptées à notre objectif
final.
II.2 Conception du modèle de données et développement de l’interface
Modèle de données
Une fois la structure de l’architecture bien comprise, une étape importante consiste à réaliser
une nouvelle base de données, qui sera utilisée par l’application web. Pour cela, j’ai d’abord du
analyser quelles informations étaient disponible grâce aux commandes PowerShell fournies par
Citrix XenApp1. J’ai finalement vu que ces commandes mettaient à ma disposition toutes les
informations dont j’avais besoin, et même bien plus.
J’ai donc créé une base de données2 qui reprenait globalement le schéma de la base existante,
en simplifiant sa structure et en réduisant les données qui y étaient enregistrées. Pour
commencer, j’ai déjà supprimé les informations redondantes. Par exemple, dans la table des
machines, il y avait les identifiants du catalogue et du groupe de mise à disposition de chaque
machine, mais aussi leur nom. Pour identifier le catalogue ou le groupe de mise à disposition
d’une machine, seul l’identifiant est nécessaire, le nom est inutile puisqu’il est déjà sauvegardé
dans la table des catalogues et des groupes de mise à disposition. Cela servait simplement à ce
que la visualisation des données sur phpMyAdmin soit simplifiée. En effet, on pouvait voir sur
une seule table le nom de la machine, le nom de son catalogue et le nom de son groupe. Pour la
nouvelle base de données, j’ai choisi de supprimer ces informations redondantes pour réduire
la taille de la base et supprimer les risques d’incohérence dans les données.
Figure 10 : Exemple d’optimisation de la base de données
1 Voir annexe B – Détails de quelques commandes PowerShell fournies par Citrix XenApp 2 Voir annexe D – Schéma de la nouvelle base de données
Emile CALIXTE Mémoire de stage 2017-2018
Page 19 sur 39
J’ai également simplifié l’enregistrement des sessions : au lieu d’avoir une table pour les
sessions en cours et une pour l’historique des sessions, j’ai choisi de tout regrouper en une table
avec une colonne « StartTime » qui correspond à la date et l’heure d’ouverture de session, et
une colonne « StopTime » qui correspond à la date et l’heure de fermeture de session. Nous
avions vu que dans l’ancienne base de données, il y avait une table « Last_Sessions » utilisée
pour le traitement. Cette table n’est plus nécessaire, puisqu’on enregistre l’heure de début et de
fin d’une session pour avoir un historique des sessions.
Enfin, j’ai ajouté une table « ProvisioningScheme », nom qui découle directement du nom de
la commande PowerShell utilisée pour obtenir ces informations : Get-ProvScheme. Un
« Provisioning Scheme » peut se traduire par « Modèle de déploiement ». Il s’agit
d’informations concernant les ressources déployées pour les catalogues. Chaque catalogue est
associé à un modèle de déploiement. Nous ne rentrerons pas dans des explications détaillées
concernant ces éléments, il faut simplement retenir que récupérer ces données nous permet de
savoir quel snapshot de quel master est utilisé par un catalogue, information essentielle pour la
réalisation de l’application.
Après avoir optimisé la base et ajouté les informations manquantes, pour que la lecture puisse
être possible sur phpMyAdmin et pour que la récupération des données par l’application soit
plus simple par la suite, j’ai créé une vue1 regroupant toutes les informations des machines2.
Cela permet d’effectuer des requêtes en appelant une seule vue qui regroupe toutes les
informations dont l’application aura besoin.
Figure 11 : Schéma de la vue « machines » dans la nouvelle base de données
1 Voir glossaire – Vue 2 Voir annexe E – Nouvelle base de données – vue « machines »
Emile CALIXTE Mémoire de stage 2017-2018
Page 20 sur 39
Alimentation de la base de données
Une fois la base de données mise en place, il faut y insérer des données. Pour cela, nous utilisons
un script PowerShell qui est exécuté toutes les cinq minutes. Ce script utilise les librairies Citrix
pour utiliser les commandes PowerShell1, et un outil appelé « Connector/Net », qui permet de
se connecter à la base de données MySQL pour y insérer les informations récupérées par les
commandes.
Pour créer ce script d’alimentation, je me suis inspiré de celui qui existait déjà et qui servait à
alimenter la base de données existante. Il comporte :
• Une fonction générique d’insertion dans une table : cette fonction prend en paramètre
le nom de la table et l’objet à insérer. Elle décompose l’objet, et pour chaque champ de
l’objet, elle insère la valeur dans la colonne de la table qui correspond
• Une fonction pour chaque récupération (récupération des machines, des sessions, des
catalogues...). Cette fonction effectue la récupération des informations (par exemple la
commande Get-BrokerMachine), puis, pour chaque élément retourné, appelle la
fonction d’insertion dans la table correspondante
• Une fonction pour exécuter une requête dans la base de données.
Comme il est important de garder un historique des sessions et de l’architecture, nous avons
choisi de rajouter un champ « Is_Active » dans les tables des sessions, des machines, des
catalogues et des groupes de mise à disposition. Ce champ permet de connaitre, pour chaque
élément, si celui-ci est un historique ou s’il est encore utilisé.
Par exemple, lorsque le script récupère la liste des sessions, il va d’abord effectuer une requête
pour mettre le champ « Is_Active » de toutes les sessions à False (valeur 0 dans MySQL), puis
insérer les sessions qu’il a récupérées avec la commande Get-BrokerSession et pour chaque
session qu’il insère, remettre le champ « Is_Active » à True (valeur 1 dans MySQL). Le
fonctionnement est exactement le même pour les autres tables.
Application web
Comme précisé précédemment, l’application est développée en PHP et HTML pour la
structuration de la page, et en Javascript pour l’affichage et la mise à jour des données. La
réalisation rapide de la première interface m’a permis de confirmer que ces choix étaient adaptés
au type d’interface que nous voulions avoir à la fin. En effet, grâce à JavaScript, il est possible
de recharger les informations en cliquant sur un bouton, mais aussi d’effectuer des tris et des
filtrages, le tout instantanément et sans rafraichir la page.
1 Voir annexe B – Détails de quelques commandes PowerShell fournies par Citrix XenApp
Emile CALIXTE Mémoire de stage 2017-2018
Page 21 sur 39
J’ai donc développé plusieurs pages de l’application, permettant de visualiser l’architecture
dans sa globalité. Il est possible de voir une liste des masters, avec pour chacun un aperçu rapide
de l’état des machines :
Figure 12 : Capture d’écran de l’affichage de la liste des masters
Sur cette page, chaque ligne correspond à un master. Les carrés de couleur représentent le
nombre de machines et leur charge (un nombre d’utilisateurs maximum souhaitable est défini
pour chaque machine selon les ressources qui lui sont allouées) :
• Gris : machine éteinte
• Blanc : machine allumée avec 0 utilisateur
• Vert : machine allumée un nombre d’utilisateurs inférieur à ½ de la charge maximale
• Jaune : machine allumée avec un nombre d’utilisateurs entre ½ et ¾ de la charge
maximale
• Orange : machine allumée avec un nombre d’utilisateurs entre ¾ et 1 × la charge
maximale
• Rouge : machine allumée avec un nombre d’utilisateurs supérieur ou égal au nombre
maximum d’utilisateurs défini
Par exemple, dans le premier master de la liste, on peut voir qu’il y a trois machines éteintes,
huit machines allumées mais non utilisées et une machine à demi-charge. Un point
d’exclamation rouge s’affiche si une ou plusieurs machines ont une situation anormale : état
d’alimentation inconnu ou nombre maximal d’utilisateurs non défini par exemple.
On voit également pour chaque master quelques informations supplémentaires :
• Le nombre de machines en maintenance s’il y en a
• Un avertissement si des machines sont non attribuées (point d’exclamation orange)
• Un avertissement si des machines ont un nombre maximum d’utilisateurs non défini ou
un état d’alimentation inconnu (point d’exclamation rouge)
Emile CALIXTE Mémoire de stage 2017-2018
Page 22 sur 39
L’application comporte également une page qui affiche sous forme de tableau les machines
d’un master :
Figure 13 : Capture d’écran de l’affichage synthétique d’un master
Comme on peut le voir, le tableau est à double entrée : les colonnes du tableau représentent les
groupes de mise à disposition, et les lignes représentent les catalogues (qui sont regroupés par
snapshot). Chaque case contient donc les machines qui sont dans le catalogue et le groupe de
mise à disposition correspondant. Les machines sont représentées par les rectangles de couleur,
toujours pour indiquer leur état et leur charge.
Cet affichage en couleur permet de voir d’un coup d’œil la charge globale des machines, et
surtout de détecter lorsqu’une ou plusieurs machines sont surchargées. Il permet également de
voir lorsque des machines sont allumées en mode maintenance, par un clignotement de bordure
bleue autour des rectangles représentant les machines. Nous avons choisi le clignotement pour
conserver l’information de la couleur en fonction de la charge, et pour que l’œil soit attiré
puisque le mode maintenance sur une machine allumée n’est pas normal : la machine est
démarrée, donc consomme des ressources, mais n’est accessible à personne.
Comme on peut le deviner, les nombres écrits dans les rectangles représentent le nombre
d’utilisateurs connectés sur cette machine sur le nombre maximum d’utilisateurs souhaitable
(ce nombre est défini manuellement en fonction du modèle de GPU de la machine). Par un
souci de lisibilité, comme les noms des machines sont souvent longs, le nom de la machine
n’est pas directement affiché. Toutefois, en survolant un rectangle avec la souris, un rectangle
d’information s’affiche instantanément pour afficher le nom de la machine.
Emile CALIXTE Mémoire de stage 2017-2018
Page 23 sur 39
Figure 14 : Lorsqu’on survole une machine, des informations s’affichent
Techniquement, cela est fait via les événement « onmouseenter » et « onmouseleave » de
JavaScript sur chaque rectangle (chaque rectangle étant une « div » HTML). Lorsque la souris
entre dans le rectangle, une « div » est générée au-dessus. Lorsque la souris sort de la zone, la
« div » est supprimée.
Cet affichage permet de connaitre rapidement le nom d’une machine qui attire notre attention
par exemple, sans avoir à cliquer dessus pour afficher ses détails.
L’application propose également un affichage détaillé d’une machine, disponible en cliquant
simplement sur le rectangle associé à la machine :
Figure 15 : Capture d’écran de l’affichage détaillé d’une machine
Cette page permet de voir l’état d’alimentation de la machine, si le mode maintenance est activé
ou non, les ressources allouées et les sessions qui y sont ouvertes. On voit également dans quel
catalogue, snapshot, master et groupe de mise à disposition se trouve la machine.
Emile CALIXTE Mémoire de stage 2017-2018
Page 24 sur 39
On peut également accéder à une page qui affiche la liste des groupes de mise à disposition,
avec la même charte graphique que la liste des masters, puis accéder aux détails d’un groupe :
Figure 16 : Capture d’écran des détails d’un groupe de mise à disposition
Sur cette page, on retrouve l’affichage des machines sous la même forme que pour le détail
d’un master : les machines sont triées par catalogue, par snapshot et par master.
Techniquement, toutes les pages sont construites de la même manière : le serveur web envoie
au client la structure de la page, puis c’est le client qui se charge de récupérer les données auprès
du serveur et de les afficher.
Côté serveur, un fichier PHP est destiné à exécuter les requêtes à la base de données pour
récupérer les informations qui seront affichées sur la page. Il contient une classe1 DAO
(Database Access Object, ou Objet d’Accès à la Base de Données) qui se connecte à la base de
données via PDO (PHP Data Object)2 et qui contient toutes les fonctions de récupération des
données, chaque fonction exécutant une requête à la base de données. Cette classe permet donc,
entre autres, :
• De récupérer la liste des masters
• De récupérer, pour un master, la liste des machines triées par catalogues, chaque
catalogue étant trié par snapshot
• De récupérer les détails d’une machine
• De récupérer la liste des groupes de mise à disposition
• De récupérer, pour un groupe de mise à disposition, ses informations et la liste de ses
machines triées par catalogue, par snapshot et par master.
1 Voir glossaire – Classe 2 Voir webographie – PHP Data Object
Emile CALIXTE Mémoire de stage 2017-2018
Page 25 sur 39
Les fonctions de cette classe sont appelées par les fichiers PHP qui sont eux-mêmes appelés par
l’application côté client sous forme de requêtes AJAX. Le principe de ces fichiers est d’appeler
une fonction de la classe DAO pour obtenir les informations souhaitées, puis d’écrire le résultat.
Ce résultat sera ensuite lu par le script JavaScript de la page, qui pourra afficher les
informations.
Pour que le résultat de la fonction PHP puisse être lu par le script JavaScript, il faut écrire le
résultat dans un format que les deux langages comprennent. Il s’agit du format JSON1. C’est
est un format texte qui permet de représenter les données de façon structurée. Par exemple, si
on a un objet « Machine » qui s’appelle « Burotic1 », dont l’identifiant est « 42 » et dont le nom
du catalogue est « Bureautique-Oronge », on obtient en JSON :
{
"machine": {
"name": "Burotic1",
"id": "42",
"catalogName": "Bureautique-Oronge"
}
}
On peut, avec ce langage, représenter facilement un master comportant une liste de snapshots,
avec pour chaque snapshot une liste de catalogues, et pour chaque catalogue une liste de
machines.
Une fois que le script JavaScript a récupéré ce texte au format JSON, il va le « parser », c’est à
dire le parcourir pour le transformer en objet JavaScript, qui pourra ensuite être parcouru et
traité.
Pour résumer, voici comment le script procède une fois qu’il a récupéré les informations :
• Création de l’en-tête du tableau
• Parcours de toutes les machines pour savoir dans quelle colonne les mettre en fonction
de leur groupe de mise à disposition
• Pour chaque snapshot du master :
o Afficher une case du tableau contenant le nom du snapshot. La case a une
hauteur, en nombre de lignes, correspondant au nombre de catalogues que le
snapshot contient
o Pour chaque catalogue
▪ Afficher une case du tableau contenant le nom du catalogue
▪ Pour chaque machine
− Ajout, dans la case du tableau correspondant, d’un rectangle
(« div » HTML) dont la couleur dépend du nombre d’utilisateurs
divisé par le nombre maximal défini
• Fermeture et affichage du tableau
1 Voir glossaire - JSON
Emile CALIXTE Mémoire de stage 2017-2018
Page 26 sur 39
L’interface est accessible uniquement aux personnes authentifiées sur le domaine AIPDS
(domaine de l’AIP Primeca Dauphiné-Savoie). Pour l’authentification, le serveur se connecte à
l’annuaire LDAP1 du domaine et vérifie si l’identifiant et le mot de passe fournis sur l’interface
de connexion existent et sont corrects. Pour vérifier, sur chaque page, que l’authentification est
correcte, l’application utilise le système de sessions de PHP2. Nous ne rentrerons pas dans des
explications détaillées concernant cela ; pour faire simple, lors de l’authentification sur la page
de connexion, une « session » est créée. A chaque chargement de page, le serveur vérifie sur
l’ordinateur du client (grâce aux cookies3) si une session existe. Si c’est le cas, il affiche la page,
sinon il redirige l’utilisateur vers la page de connexion.
II.3 Problèmes rencontrés
Dans sa globalité, la réalisation du projet s’est bien passée. Les quelques problèmes que nous
avons rencontrés ne nous ont pas bloqués, et nous avons rapidement su les contourner.
Un des problèmes que nous avons eus se produisait lorsqu’on tentait d’afficher ou de rafraichir
les données de l’application au moment où le script PowerShell mettait à jour la base de
données ; comme expliqué précédemment, pour garder un historique, les sessions, machines,
catalogues et groupes de mise à disposition ont un champ « Is_Active » dans la base de données.
Or, lorsque le script met à jour la base, il met d’abord le champ « Is_Active » de toutes les
lignes à False, puis remet le champ à True pour les ligne qu’il insère ou qu’il met à jour (donc
pour les éléments qu’il a récupéré via la commande Citrix). Si la requête des données est faite
par l’application pendant ce court laps de temps, on ne récupérait donc pas toutes les données,
voire pas de données du tout.
Pour résoudre ce problème, un système de vérification a été mis en place : une table a été ajoutée
dans la base de données, contenant une seule valeur booléenne indiquant si la base de données
est en cours de mise à jour ou non. L’application, avant de récupérer les informations, va vérifier
cette donnée. Si la base de données est en cours de mise à jour, l’application va attendre
quelques secondes avant de réessayer (tant que la base de données est en cours de mise à jour,
l’application refait cette opération toutes les trois secondes).
Dans le but de réduire au maximum le temps d’inaccessibilité des données, nous avons optimisé
le script de mise à jour de la base de données en séparant les étapes de récupération des données
et de mise à jour de la base, car certaines commandes Citrix utilisées peuvent mettre plus de dix
secondes à s’exécuter. Concrètement, au lieu de mettre le champ « Is_Updating » de la base de
données à True, puis récupérer les données, puis mettre à jour la base, puis remettre le champ
« Is_Updating » à False, on sauvegarde les données dans des variables avant de mettre le champ
« Is_Updating » à True et de mettre à jour la base de données.
1 Voir glossaire – LDAP 2 Voir webographie – PHP et les sessions 3 Voir glossaire – Cookies
Emile CALIXTE Mémoire de stage 2017-2018
Page 27 sur 39
Figure 17 : Organigrammes de l’affichage des données sur la page et de mise à jour de la base de données
Le second problème important que nous avons rencontré est que nous n’avons, à ce jour, pas
trouvé comment obtenir facilement le modèle de GPU des machines. Or, nous souhaitions
initialement définir le nombre maximum d’utilisateurs par machine en fonction du modèle de
GPU de la machine. En analysant les données contenues dans les modèles de déploiement (les
« Provisioning Scheme »), nous avons vu qu’il y avait un « GPU ID », un identifiant de GPU.
Il s’agit de la seule donnée qui soit accessible concernant le GPU. Nous avons finalement décidé
de regarder le GPU manuellement pour chaque modèle de déploiement et de leur attribuer un
nombre maximum d’utilisateurs en conséquence.
II.4 Tâches restantes
Mon stage n’étant pas terminé, et la taille du projet étant conséquente, il reste encore de
nombreuses tâches à effectuer.
Premièrement, un gros objectif est de mettre en place une interaction avec l’application : il doit
être possible d’arrêter et de démarrer une machine. Pour cela, lors du clic sur un bouton d’arrêt
par exemple, une requête AJAX sera faite au serveur, qui effectuera un appel à la base de
données pour y insérer l’instruction correspondante dans une table. Puis, comme pour
l’alimentation de la base de données, un script sera exécuté régulièrement et automatiquement
pour venir lire les instructions en attente dans la base de données, et effectuer les actions en
conséquence.
Aussi, il faudra que l’application propose des actions en adéquation avec la personne
authentifiée : Pour l’instant, cette application est destinée à être utilisée par les informaticiens
qui administrent l’architecture, mais le but final est qu’elle puisse être accessible à tous pour
visualiser les informations, et que certaines personnes aient accès aux actions sur les machines
et à certaines informations supplémentaires. Actuellement, le service d’authentification ne fait
aucune distinction entre un simple utilisateur et un administrateur, et permet simplement de
restreindre l’accès aux personnes enregistrées dans le domaine.
Après mon stage, d’autres personnes viendront continuer le projet. Il s’agit notamment
d’automatiser le démarrage et l’arrêt des machines virtuelles en fonction de la charge des
groupes, des catalogues et des serveurs physiques. Un objectif est aussi de développer une
interface de réservation des ressources, que les utilisateurs pourront utiliser pour réserver
l’utilisation d’un logiciel à une certaine heure. La réservation des ressources impliquera de
démarrer et arrêter les machines en conséquence, pour que des ressources soient toujours
disponibles, mais ne soient pas gaspillées lorsqu’il y a peu d’utilisateurs connectés
Emile CALIXTE Mémoire de stage 2017-2018
Page 28 sur 39
Conclusion
Cette application web, qui a été réalisée pour débuter un gros projet de gestion des ressources
des machines virtuelles, facilite déjà grandement la gestion des machines virtuelles. L’affichage
synthétique et visuel permet qu’un éventuel problème dans l’architecture, pouvant affecter les
performances, soit maintenant rapidement détecté.
Ce stage a été pour moi une excellente première expérience dans le monde du travail en
informatique. J’ai pu non seulement appliquer les notions et concepts vus en cours au long de
ces deux années d’études, mais aussi découvrir les différences entre le monde des études et le
monde professionnel (les imprévus, mais aussi le fait que l’application que j’ai développé sera
réellement utile). J’ai également approfondi mes connaissances en développement web, ce qui
est pour moi une grande satisfaction puisque j’aimerais en faire mon métier. J’ai aussi pu
apprendre beaucoup de choses concernant la virtualisation, les bases de données et le langage
PowerShell que je n’avais jamais utilisé auparavant et qui s’est avéré être un langage de script
orienté objet très intéressant et très puissant.
J’ai été satisfait de ma réalisation : j’ai pour l’instant largement respecté les délais prévus dans
le planning1, j’ai réalisé un code propre et lisible qui pourra être repris par les autres personnes
qui travailleront sur ce projet, en implémentant d’autres fonctionnalités à l’application. Nous
avons contourné les problèmes que nous avons rencontré, et les quelques tâches qu’il me reste
à faire pendant le stage devraient être terminées dans les temps.
Sur le plan personnel, je suis très satisfait de l’ambiance qu’il y a eu tout au long de mon stage.
Mon maitre de stage et moi-même nous sommes très bien entendus, de même avec les
responsables de la plateforme. J’ai développé mon autonomie et j’ai confirmé mon souhait de
continuer mes études dans le domaine de l’informatique que j’apprécie beaucoup.
Pour conclure, ce stage a été très enrichissant pour moi. J’ai découvert le monde du travail en
informatique, appris de nouvelles notions et approfondi mes connaissances dans le domaine du
développement web et de l’informatique en général.
1 Voir annexe F – Planning et délais
Emile CALIXTE Mémoire de stage 2017-2018
Page 29 sur 39
Glossaire
AJAX : Technologie utilisée par le client pour appeler un script PHP qui va exécuter un
programme du côté du serveur, et renvoyer un résultat au client.
Citrix Systems : Entreprise qui propose des solutions de virtualisation.
Classe : En programmation Orienté Objet, élément contenant des attributs et des
comportements (méthodes).
Client léger : Appareil, dans une architecture client-serveur, qui n’a quasiment pas de logique
d’application et dont la quasi-totalité du traitement repose sur le serveur.
Cœur : Unité capable d’exécuter des instructions individuellement. De nos jours, la plupart des
processeurs ont plusieurs cœurs et peuvent donc traiter plusieurs instructions en même temps,
contrairement à un processeur monocœur.
Cookie : Petit fichier sauvegardé côté client, qui enregistre certaines informations qui seront
récupérées à la prochaine connexion.
CPU (processeur) : Composant de l’ordinateur qui exécute les instructions des programmes
informatiques.
GPU (processeur graphique) : Composant semblable au processeur, adapté pour effectuer des
calculs d’affichage.
Groupe de mise à disposition : Groupe d’utilisateurs auxquels on donne accès à des machines
virtuelles.
HTML : HyperText Markup Language, langage de structuration des données utilisé pour
structurer les pages web.
JavaScript : Langage de programmation utilisé sur les pages web, exécuté par le client web
(navigateur internet) permettant de rendre des pages web interactives.
JSON : JavaScript Object Notation, format de structuration des données en texte.
LDAP : Lightweight Directory Access Protocol, protocole permettant d’interroger un service
d’annuaire.
Licence flottante : Mode de commercialisation d’un logiciel qui consiste à disposer d’autant de
licences que d’utilisateurs simultanés : lorsqu’un utilisateur commence à utiliser le logiciel, il
prend un jeton de licence, qu’il libère une fois le logiciel fermé et qui peut alors être utilisé par
quelqu’un d’autre.
Master : Grand groupe de machine défini en fonction du type de machine, du système
d’exploitation qui va être installé sur les machines et des logiciels que l’on souhaite y déployer.
MySQL : Système de gestion de bases de données relationnelles.
Nvidia : Fabricant de processeurs graphiques
PHP : HyperText Preprocessor, langage de programmation exécuté sur un serveur web
permettant de générer dynamiquement des pages web en HTML.
Emile CALIXTE Mémoire de stage 2017-2018
Page 30 sur 39
phpMyAdmin : Application web de visualisation de base de données MySQL.
Pilote (driver) : Programme informatique dont le but est de permettre à un autre programme
d’interagir avec un composant ou un périphérique.
Programmation orientée objet (POO) : Mode de programmation qui consiste à manipuler des
objets. Un objet est un conteneur qui contient des informations et des comportements qui lui
sont propres. Exemple : un objet ville peut contenir les informations « nom », « superficie »,
« localisation » et les fonctions « ajouter un habitant », « changer le nom » et «
RAM (mémoire vive) : Random Access Memory, mémoire temporaire dans laquelle sont
chargées les informations traitées par le système informatique.
Raspberry Pi : Nano-ordinateur de la taille d’une carte bancaire qui peut être utilisé comme un
ordinateur classique.
Snapshot : Image de la configuration matérielle et logicielle d’une machine.
Système d’exploitation : Ensemble de programmes qui permettent le bon fonctionnement des
applications de l’utilisateur sur les composants matériels de l’ordinateur, en gérant au mieux les
ressources matérielles.
Table : Dans une base de données, une table désigne un ensemble de données organisées en
tableau. Les colonnes du tableau correspondent aux informations (nom, identifiant...), et chaque
ligne est une entrée, une donnée.
Virtualisation : Mécanisme qui consiste à exécuter plusieurs systèmes et applications sur un
même serveur physique.
Vue : Dans une base de données, une vue peut être considérée comme une table virtuelle. Il
s’agit du résultat d’une requête qu’on a enregistré et qu’on peut appeler dans une requête comme
si c’était une table.
Windows PowerShell : Suite développée par Microsoft qui gère un langage de script orienté
objet et une interface en lignes de commandes.
Emile CALIXTE Mémoire de stage 2017-2018
Page 31 sur 39
Webographie
Présentation de l’AIP Primeca Dauphiné-Savoie :
http://aip.grenoble-inp.fr/aip-primeca-ds/aip-primeca-ds-presentation-729918.kjsp
Présentation des plateformes de l’AIP Primeca Dauphiné-Savoie :
http://aip.grenoble-inp.fr/aip-primeca-ds/plateformes-du-pole/plateformes-758575.kjsp
Virtualisation GPU pour la mise à disposition d’applications 3D à l’AIP-Primeca Dauphiné-
Savoie :
https://conf-ng.jres.org/2015/planning.html#article_93
Documentation complète Citrix :
https://developer-docs.citrix.com/projects/delivery-controller-sdk/en/latest/
PHP Data Object :
http://php.net/manual/fr/book.pdo.php
PHP et les sessions :
http://php.net/manual/fr/session.examples.basic.php
Emile CALIXTE Mémoire de stage 2017-2018
Page 32 sur 39
Table des figures
Figure 1 : Emplacements des plateformes d’AIP Primeca à Grenoble ..................................... 7 Figure 2 : Nombre de sessions Citrix par jour du 23 novembre 2017 au 20 mai 2018 ............. 8 Figure 3 : Schéma récapitulatif d’un exemple de déploiement des masters et des snapshots. 11 Figure 4 : Schéma récapitulatif d’un exemple de déploiement des catalogues ....................... 12
Figure 5 : Schéma synthétique des groupes de mise à disposition ......................................... 13 Figure 6 : Résultat d’une commande PowerShell : quelques informations sur une machine . 14 Figure 7 : Capture d’écran de la liste des machines sur la première interface ........................ 16 Figure 8 : Capture d’écran de la liste des catalogues sur la première interface ...................... 17 Figure 9 : Schéma récapitulatif de la construction d’une page de l’interface ......................... 17
Figure 10 : Exemple d’optimisation de la base de données .................................................... 18
Figure 11 : Schéma de la vue « machines » dans la nouvelle base de données ...................... 19
Figure 12 : Capture d’écran de l’affichage de la liste des masters .......................................... 21 Figure 13 : Capture d’écran de l’affichage synthétique d’un master ...................................... 22 Figure 14 : Lorsqu’on survole une machine, des informations s’affichent ............................. 23 Figure 15 : Capture d’écran de l’affichage détaillé d’une machine ........................................ 23 Figure 16 : Capture d’écran des détails d’un groupe de mise à disposition ............................ 24
Figure 17 : Organigrammes de l’affichage des données sur la page et de mise à jour de la base
de données ................................................................................................................................ 27
Emile CALIXTE Mémoire de stage 2017-2018
Page 33 sur 39
Annexes
Annexe A - Configuration des serveurs physiques
• Serveurs Griset et Girolle (DELL R720) :
o Processeurs : 2 × Intel® Xeon® E5-2670 (8 cœurs, 16 threads : au total 32 threads
par serveur)
o RAM : 128 Go
o Cartes graphiques : 2 × Nvidia® Grid K2 (8 Go GDDR5, 2 GPU, 3072 cœurs
CUDA)
o Stockage : 6 × HDD 2 To en RAID 10 (6 To au total)
• Serveur Fistuline (DELL R730) :
o Processeurs : 2 × Intel® Xeon® E5-2660 v3 (10 cœurs, 20 threads : au total 40
threads)
o RAM : 128 Go
o Cartes graphiques : 2 × Nvidia® Grid K2 (8 Go GDDR5, 2 GPU, 3072 cœurs
CUDA)
• Serveurs Polypore, Xylère, Mousseron et Oronge (DELL R730) :
o Processeurs : 2 × Intel® Xeon® E5-2660 v4 (14 cœurs, 28 threads : au total 56
threads par serveur)
o RAM : 256 Go
o Cartes graphiques : 2 × Nvidia® Tesla M60 (16 Go GDDR5, 2 GPU, 4096 cœurs
CUDA)
o Stockage : 8 × SSD 500 Go en RAID 5 + 2 × HDD 300 Go en RAID 1 = environ
2,2 To pour Polypore, environ 1,3 To pour les trois autres.
Emile CALIXTE Mémoire de stage 2017-2018
Page 34 sur 39
Annexe B - Détails de quelques commandes PowerShell fournies par Citrix XenApp
Ces commandes renvoient des listes d’objets, chaque objet comportant beaucoup
d’informations. Sont détaillées ici les principales informations utilisées dans le projet. Voir
webographie pour la documentation complète.
Get-BrokerMachine : Renvoie toutes les machines de l’architecture. Cette commande donne
énormément de détails sur les machines, dont, pour chaque machine :
• Son identifiant, son nom, sa description
• Son état d’alimentation et si elle est en mode maintenance
• Son adresse IP sur le réseau
• Les sessions et applications en cours sur la machine
• Le catalogue et le groupe de mise à disposition
Get-BrokerDesktopGroup : Renvoie tous les groupes de mise à disposition de l’architecture.
Cette commande donne des détails sur les groupes, dont, pour chaque groupe :
• Son identifiant, son nom, sa description
• Le nombre de sessions ouvertes
Get-BrokerCatalog : Renvoie tous les catalogues de l’architecture. Cette commande donne
des détails sur les catalogues, dont, pour chaque catalogue :
• Son identifiant, son nom, sa description
• Le nombre de machines
Get-BrokerApplication : Renvoie toutes les applications enregistrées dans l’architecture,
avec pour chaque application :
• Son identifiant, son nom, sa description
• Le chemin d’accès vers l’exécutable (fichier de lancement de l’application)
Get-BrokerApplicationInstance : Renvoie toutes les instances d’applications, c’est-à-dire
toutes les utilisations des applications par les utilisateurs (couples utilisateur-application). Pour
chaque instance :
• L’identifiant de l’application et son nom
• L’identifiant de la session et le nom d’utilisateur
• L’identifiant et le nom de la machine sur laquelle est utilisée l’application
Get-BrokerSession : Renvoie toutes les sessions, avec pour chacune :
• Un identifiant de session
• L’heure d’ouverture de la session
• L’utilisateur et la machine et l’application utilisée
Get-ProvScheme : Renvoie tous les « Provisioning Scheme », c’est-à-dire tous les snapshots
avec pour chacun :
• Sa configuration : nombre de cœurs, taille de mémoire, taille du disque dur
• Son master
• Le nombre de machines
Emile CALIXTE Mémoire de stage 2017-2018
Page 35 sur 39
Annexe C - Schéma de la base de données initiale
Emile CALIXTE Mémoire de stage 2017-2018
Page 36 sur 39
Annexe D - Schéma de la nouvelle base de données
Emile CALIXTE Mémoire de stage 2017-2018
Page 37 sur 39
Annexe E - Nouvelle base de données – vue « machines »
La vue « machines » contient les champs suivants :
• machineUid (BrokerMachines.Uid)
• machineSID (BrokerMachines.SID)
• machineRegistrationState (BrokerMachines.RegistrationState)
• machinePowerState (BrokerMachines.PowerState)
• inMaintenanceMode (BrokerMachines.InMaintenanceMode)
• machineIPAddress (BrokerMachines.IPAddress)
• machineName (BrokerMachines.MachineName)
• nbSessions (BrokerMachines.SessionCount)
• maxUsers (ProvisioningScheme.MaxUsers)
• CatalogUid (BrokerMachines.CatalogUid)
• CatalogName (BrokerCatalogs.Name)
• DesktopGroupUid (BrokerMachines.DesktopGroupUid)
• DesktopGroupName (DesktopGroup.Name)
• machineHostingServerName (BrokerMachine.HostingServerName)
• machineOS (BrokerMachines.OSType)
• machineCPUCount (ProvVM.CpuCount)
• machineMemoryMB (ProvVM.MemoryMB)
• ProvSchemeName (ProvisioningScheme.ProvisioningSchemeName)
• machineGpuTypeId (ProvisioningScheme.GpuTypeId)
• machineMasterImageVMDate (ProvisioningScheme.MasterImageVMDate)
• machineMaster (ProvisioningScheme.Master)
• machineSnapshot (ProvisioningScheme.Snapshot)
Emile CALIXTE Mémoire de stage 2017-2018
Page 38 sur 39
Annexe F - Planning et délais
Outil : Tom’s Planner – https://www.tomsplanner.fr/
Emile CALIXTE Mémoire de stage 2017-2018
Page 39 sur 39
Abstract
AIP Primeca Dauphiné-Savoie is one of the nine hubs of AIP Primeca in France, which is a
service providing resources in the field of mechanic and production engineering. The platform
where I did my internship makes available virtualized professional software in this same field,
available from any device.
Year after year, more and more students and teachers use this infrastructure, this implies to
create more and more virtual machines to host the software and support all these users. But
more virtual machines mean more difficult management, and the default administration
interface is not really suitable for a big number of machines.
During my internship, I’ve made a web application which provides a synthetic view of groups
of machines and groups of users. This view allows to visualize the power state and the number
of users of each machine at a glance. We can also perform actions on machines: start, stop,
enable or disable maintenance mode (nobody can connect to the machine) and kill broken
sessions.
This application provides an easier way to manage virtual machines by showing the architecture
in a more visual way that the default administration interface.
Keywords: web application, virtualization, software, administration