CONCEPTION ET DÉVELOPPEMENT D’UNE INTERFACE DE … · 2018. 12. 3. · Aujourd’hui,...

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

sur 39

Déclaration de respect des droits d’auteurs


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.


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


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.


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


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


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


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.


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)


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)


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


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


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


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


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


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


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


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 »


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


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)


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.


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.


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


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


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


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


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


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.


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.


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


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


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.


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 :


• 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 :


• Le nombre de machines

Get-BrokerApplication : Renvoie toutes les applications enregistrées dans l’architecture,

avec pour chaque application :


• 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


sur 39

Annexe C - Schéma de la base de données initiale


sur 39

Annexe D - Schéma de la nouvelle base de données


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)


sur 39

Annexe F - Planning et délais

Outil : Tom’s Planner – https://www.tomsplanner.fr/


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

CONCEPTION ET DÉVELOPPEMENT D’UNE INTERFACE DE … · 2018. 12. 3. · Aujourd’hui,...

Documents

Transcript of CONCEPTION ET DÉVELOPPEMENT D’UNE INTERFACE DE … · 2018. 12. 3. · Aujourd’hui,...