Les couches de communication représentent une partie importante de l’application. Il faut dis- tinguer plusieurs aspects :
– la communication entre le serveur applicatif et les hôtes ;
– la synchronisation entre les parties serveur et client de l’application ; – la gestion des ressources de calcul.
4.4.1 Communication entre le serveur applicatif et les hôtes
Le premier aspect dépend essentiellement des systèmes d’exploitation utilisés et des possibili- tés offertes pour l’exécution des commandes. Les grappes de la grille de calcul utilisant nativement le protocole SSH, celui-ci a été retenu comme protocole principal pour l’application.
4.4. IMPLÉMENTATION DES COUCHES DE COMMUNICATION Pour la communication entre l’application et les différentes machines, le protocole SSH a été retenu. En effet, il allie souplesse et sécurité. Une connexion SSH permet de se connecter à distance sur un hôte et d’y exécuter des commandes. Par le biais d’une couche FTP (SFTP), il est possible d’échanger des fichiers.
Différentes implémentations sont disponibles pour le langage PHP. La première est une exten- sion à activer dans la configuration. Elle est basée sur libssh et offre ainsi de bonnes performances. Malheureusement, elle souffre de quelques défauts et n’est pas forcément disponible sur tous les systèmes.
La deuxième solution, phpSecLib, est une implémentation native en PHP. De ce fait, son uti- lisation offre des performances moins bonnes que libssh puisque son code doit être interprété à chaque appel. En revanche, son principal avantage est d’être ainsi disponible sur n’importe quel système sans aucune contrainte de configuration puisqu’elle se trouve directement intégrée au code source de l’application.
La bibliothèque phpSecLib est disponible sur le site http://phpseclib.sf.net en li- cence LGPL. Après avoir téléchargé la dernière version, il faut la décompresser dans un sous- dossier du projet tel que/library/ssh. Afin d’utiliser phpSecLib dans le code de l’application,
il est nécessaire d’inclure les fichiers adéquats.
4.4.1.1 Ouverture de connexion
Selon qu’on souhaite ouvrir une connexion SSH ou SFTP, la bibliothèque nous propose plu- sieurs constructeurs, chacun ayant les mêmes paramètres : l’hôte, le numéro de port (22 par défaut) et le délai d’attente (10 secondes par défaut). L’instance ainsi créée est ensuite utilisée dans tous les traitements jusqu’à la fermeture de la connexion. Pour terminer la phase d’ouverture de connexion, il est nécessaire de s’authentifier auprès de l’hôte soit avec un couple nom d’utilisateur/mot de passe, soit avec un couple nom d’utilisateur/clé privée.
Voici un exemple de connexion SFTP avec authentification par mot de passe :
include(’Net/SFTP.php’);
$sftp = new Net_SFTP(’www.domain.tld’);
4 if (!$sftp->login(’username’, ’password’)) { exit(’Login Failed’);
}
Voici un exemple de connexion SSH avec authentification par clé privée :
include(’Crypt/RSA.php’); include(’Net/SSH2.php’);
4 $key = new Crypt_RSA();
//$key->setPassword(’whatever’); $key->loadKey(file_get_contents(’privatekey’)); $ssh = new Net_SSH2(’www.domain.tld’); 9 if (!$ssh->login(’username’, $key)) { exit(’Login Failed’); } 65
CHAPITRE 4. RÉALISATION DE LA NOUVELLE PLATEFORME DE SIMULATION 4.4.1.2 Exécution de commandes
Une fois que la connexion SSH est établie, il suffit d’utiliser la méthode exec() de l’objet
instancié pour exécuter une commande sur l’hôte distant. Cela donne par exemple :
echo $ssh->exec(’pwd’); echo $ssh->exec(’ls -la’);
4.4.1.3 Gestion de fichiers
Une connexion ouverte en mode SSH ne permet que d’exécuter des commandes. Le mode SFTP présente l’avantage de proposer des méthodes dédiées à la gestion de fichiers.
La méthodepwd()retourne le chemin courant.chdir($chemin)permet de changer de dos-
sier avec la chaîne passée en paramètre.mkdir($chemin) crée un dossier etrmdir($chemin)
le supprime.
Pour renommer un fichier, il faut utiliser la méthode rename($ancien_nom, $nouveau_nom). La méthode delete($chemin) permet quant à elle de supprimer un
fichier dont le chemin est passé en paramètre.
Pour déposer un fichier, il faut utiliser la méthode put(chemin, contenu) en spéci-
fiant en paramètre, le chemin de destination et le contenu à écrire. A l’inverse, la méthode
get($chemin_source, $chemin_cible)récupère le contenu du chemin source pour l’écrire
dans le chemin cible.
4.4.1.4 Fermeture de connexion
La connexion est interrompue automatiquement à la destruction de l’objet. Il est cependant pos- sible de le faire manuellement en appelant la méthodedisconnect()comme dans cet exemple :
$ssh->disconnect();
4.4.2 La synchronisation entre les parties serveur et client
La communication entre l’application serveur et une application cliente itinérante sera basée sur le protocole HTTP via le port 80 afin qu’elle ne soit pas bloquée par d’éventuels pares-feu ou proxies comme c’est le cas au LPG. Pour cela, l’architecture REST a été retenue pour sa facilité d’utilisation et de mise en œuvre.
En fait, le terme REST ne désigne pas un protocole ou un format mais un style d’architecture. Tout est basé sur l’URI et les différentes opérations fournies par le protocole HTTP. Les données échangées peuvent être formatées via les langages XML ou JSON.
Par exemple, l’URI http://simulation-consert.obs.ujf-grenoble.fr/ rest/project/1 désigne la ressource composée par l’objet projet d’identifiant « 1 ». Les opérations HTTP suivantes sont possibles :
– GETpour obtenir le contenu de la ressource ;
– PUTetPOSTpour modifier la ressource en envoyant un nouveau contenu ;
4.5. BILAN Ainsi, en établissant certaines règles de construction d’URI, il est possible de définir une API qui sera utilisable pour l’échange entre l’application principale et ses versions clientes itinérantes mais également pour faciliter la création d’une interface native en Delphi.
Malheureusement, cet aspect n’a été qu’abordé pendant le stage et le développement de cette couche n’a pas été entièrement réalisé. Celle-ci ne fait donc pas partie de la version de l’application livrée en fin de stage.
4.4.3 Gestion des ressources de calcul
La grille CIMENT propose deux intergiciels pour soumettre et gérer des calculs. Leur utilisa- tion est rendue possible grâce à la couche de communication SSH présentée plus haut. Il s’agit OAR et CiGri dont les commandes ont été décrites au chapitre précédent.
4.5 Bilan
La nouvelle plateforme se décompose en quatre blocs distincts : – la grille de calcul sur laquelle fonctionne l’outil de simulation ;
– le serveur de stockage sur lequel sont centralisés les fichiers produits par les simulations ; – le serveur web accueillant l’application principale de la plateforme et sa base de données ; – le poste client accueillant l’outil d’interprétation des résultats et servant de point d’accès à
l’application principale.
L’application « principale » est donc au cœur de la plateforme. Son architecture interne a été conçue afin de paramétrer aisément les différentes tâches composant une chaîne de simulation générique. Pour cela, plusieurs types de tâches ont été définis :
– commandepour l’exécution distante d’une commande quelconque ;
– transfert,envoi,réceptionpour échanger des fichiers entre les hôtes ;
– job CiGripour gérer spécifiquement l’intergiciel de grille CiGri ;
– attentepour marquer une pause dans la séquence.
L’application a été réalisée dans le langage PHP à l’aide du cadriciel Zend Framework. L’ar- chitecture respecte le patron MVC et le découpage en couches proposé par le cadriciel.
La communication entre l’application est les différents hôtes se fait via une connexion SSH. La librairiephpSecLiba ainsi été utilisée pour faciliter l’implémentation de cette couche au sein
de l’application. Par ailleurs, seul l’intergiciel CiGri a été nativement interfacé. Son utilisation se fait également au travers d’une liaison SSH.
CHAPITRE
5
Utilisation de la nouvelle plateforme de simulation
Avant de présenter les différents écrans de l’application Web réalisée, il peut être utile de pré- ciser leurs enchaînements. Nous utiliserons pour cela les diagrammes de cas d’utilisation issus du formalisme UML. Ainsi les principaux cas d’utilisation seront présentés afin de préciser les possibilités offertes aux utilisateurs en fonction de leurs rôles.