Soutenance de stage Migration d’un serveur

1. Jilibert Laurent Licence informatique Année 2005/2006 Soutenance de stageMigration d’un serveur Université de Rouen I.U.P. G.M.I. Responsable de stage : M Guesnet Toshiba TEC Imaging System Service Informatique Responsable de stage : M. Hubert Mathelin

2. Sommaire • Remerciements • Introduction • Présentation de Toshiba et de TEIS • Le groupe • TEIS • Le projet • Les objectifs • L’organisation • Analyse de Gold • Le programme Kardex • Les utilisateurs • La mise en forme • La migration • Physique • Matérielle • Conclusion

3. Introduction • But du stage : • permettre d’approfondir, de mettre en pratique les connaissances acquises. • découvrir le monde professionnel. • Situation du stage : • le service informatique de Toshiba TEC Imaging System situé à Martin-Eglise (76370) sur les hauteurs de Dieppe. • une période de trois mois, du 15 mai 2006 au 16 août 2006. • Objectif de ce stage : • accompagner la migration physique et matérielle d’un serveur.

4. Présentation de Toshiba et de TEIS • Toshiba • Groupe leader de l’industrie japonnaise. • Groupe pionnier dans la recherche et le développement de nouvelles technologies (hd-dvd, …). • 10 entités (e-solutions company, …). • 300 filiales (Toshiba TEC, …). • TEIS • Filiale européenne de Toshiba TEC. • Unité industrielle et logistique destinée à la production de Copieur et de Toners. • Composition autour de trois unités : • Le copieur : assemblage et fabrication de copieurs. • Le toner : fabrication des cartouches de toner pour copieur. • Le TLC : stockage et distribution des produits assemblés ou fabriqués.

5. Le projet • Les objectifs • Objectifs principaux : • Changement physique du serveur. • Mise à jour du système d’exploitation. • Mise à jour du SGBDR et de certaines bases de données. • Objectifs associés : • Analyser le programme principal tournant sur le serveur (Gold Copieur/Toner). • S’assurer de la compatibilité du matériel avec le nouveau serveur. • S’assurer de la compatibilité des packages de version antérieure avec ceux de la 9i. • Communiquer et Coordonner les différents acteurs du projet.

6. Le projet • Les objectifs • L’organisation • Enumération des différentes tâches à effectuer (analyse, installation réseau, …). • Prise de contact avec les différents acteurs du projet. • Mise en place d’un espace disque pour l’échange des informations entre les membres du projet. • Mise en place d’un diagramme de Gantt en respectant le cahier des charges.

7. Analyse de Gold • Le programme Kardex Parmi tous les programmes présents dans Gold, le plus important est celui qui permet de piloter les armoires de stockage Kardex. C’est ce programme qu’il est intéressant d’analyser. Ce programme, écrit en Pro*C (mélange subtil d’instructions pl/sql et de C), est assez complexe car il fait appel à un fichier externe pour gérer ces connexions au SGBD(avec des appels sur des packages) tandis que lui effectue des communications avec les supports de stockage. Il est plus simple, pour décrire le programme, de représenter les mouvements effectués lors d’une utilisation par une succession d’organigrammes. Ce qu’il faut surtout comprendre est que le but du programme est se connecter à la base de donnée, de traiter une adresse correspondant à un emplacement dans l’armoire de stockage et de la positionner de telle sorte que l’on puisse prendre le matériel pointé à cette adresse.

8. On lance donc le programme … … et on s’aperçoit que toutes les opérations de connexion (aussi bien entre la base que les armoires se font par le fichier « com.h »).

9. On va donc changer de fichier pour aller exécuter la fonction « connexion » laquelle, en cas de succès de connexion avec Oracle, demande aussitôt une ouverture de ligne série. • L’ouverture de la ligne avec le matériel de stockage se fait de la même manière que la connexion avec la base de donnée. • C’est-à-dire que l’on va vérifier la cohérence des valeurs passées en • paramètre avant de conclure par l’appel de la fonction « serie_open ».

10. Comme toutes les fonctions présentes, serie_open permet de connaître, grâce à son nom, l’objet de sa présence. Ici, on va chercher à ouvrir une connexion entre une armoire de stockage et le poste utilisateur. On va donc ouvrir la communication et si le changement de configuration est validé alors les connexions avec le SGBD et le support de stockage seront entièrement établies. Une fois que ces communications sont établies, on peut enfin poursuivre l’analyse de la fonction main du programme Kardex. C’est-à-dire que l’on va effectuer la phase de traitement de l’information juste après avoir été informé de la position du verrou, son activation signifiant que quelqu’un utilise déjà le programme.

11. L’objectif lorsque l’on lance ce programme étant de pouvoir sortir du matériel en fonction d’une adresse, il faut maintenant traiter cette information avec la base de donnée et l’armoire Kardex afin de savoir si la saisie est valide et qu’elle existe. Si elle existe, alors un appel à la fonction traitement_adresse va être effectué. C’est ici que l’on va « piloter » l’armoire Kardex par le biais d’instructions lues et écrites sur la liaison série. Cette dernière partie va permettre de retirer du stock le matériel souhaité.

12. Au cours de l’exploration et l’analyse du programme Kardex, j’ai pu remarquer dans les morceaux d’instructions pl/sql que l’on faisait appels à des packages présents dans le SGBD. Les packages utilisés par le programme Kardex sont PAC_MAIL(permet la journalisation et le debug à l’aide de DBMS_PIPE), PAC_UTIL(qui permet de gérer les verrous à partir de DBMS_LOCK) et PAC_DATA(correspondant surtout à un fichier d’en-tête). Ce que l’on remarque est l’inter-connectivité entre les packages. C’est cette relation étroite entre les packages qui va poser le plus gros problème lors de la migration car une erreur dans un des packages va entrainer une erreur dans les autres et dans l’application.

13. On va maintenant s’intéresser aux utilisateurs de l’application. Ils sont au nombre de trois, que l’on classer en deux catégories: • les utilisateurs : Copieur, Toner. • les développeurs : Dev. • La différence entre ces deux groupes se situe essentiellement au niveau de leur initialisation au sein du système et du SGBD. Une fois de plus le meilleur moyen d’expliquer l’initialisation des utilisateurs est de le faire par le biais d’ordinogrammes basés sur le fichier de configuration des utilisateurs : .profile. • On peut d’ailleurs le représenter de la manière suivante : • Analyse de Gold • Les utilisateurs

14. Cet utilisateur n’a rien à voir avec les deux autres pour plusieurs raison: • toutes les informations sont dans le .profile . • la base utilisée est obligatoirement PMS1. • On va d’abord initialiser les variables d’Oracle, le SID et le PATH avant de tester l’environnement pour savoir quelle version des Forms il faudra finalement lancer et de quelle manière. • Analyse de Gold • Les utilisateurs • Dev

15. Contrairement à l’utilisateur Dev, Copieur et Toner appelent des fichiers extérieurs aux .profile pour mener à bien la configuration de leurs environnements de travail. De plus, ils ne positionnent pas le SID sur la même base et possèdent donc leurs propres fichiers externe d’initialisation. Au total chacun des deux comptes va faire appel à quatre fichiers : charente : définition des variables globales. charente_’$login’ : initialisation du SID. env_pms : ajout des variables dans l’environnement. env_oracle : ajout des variables pour Oracle. • Analyse de Gold • Les utilisateurs • Copieur et Toner

16. Analyse de Gold • Les utilisateurs • Copieur et Toner

17. Enfin, l’ensemble de l’application est accessible à partir d’une ihm développée à l’aide • des Forms. Cet outil a été privilégié à d’autre car il est portable (un serveur unix pour • les postes wifi, et un serveur windows pour les postes fixes). • Les avantages dans l’utilisation des Forms sont : • la création d’objet, de menus. • la création de formulaires (comme Visual Basic). • l’interfaçage directe avec une base Oracle grâce à l’utilisation de bibliothèques pl/sql. • la création d’applet java et d’interfaces Web. • Son gros inconvénient est qu’il ne sert que pour interfacer des bases de données Oracle contrairement à Visual Basic qui permet d’implémenter des modules pour la plupart des • SGBD. • Analyse de Gold • La mise en forme

18. Un des objectifs majeurs étant de rajeunir le serveur, ce dernier se voit doté de quelques changements importants : • passage en format « baie ». • deux processeurs U-SparcIII de 750Mhz remplacent les quatre U-SparcII de 248Mhz. • l’espace disque a été doublé, on passe de 118 Go à 218 Go. • carte de communication RS-232 de nouvelle génération. • … • Le nouveau serveur reprend les fonctionnalité de Charente, c’est-à-dire qu’il permet une communication entre un poste client et les armoires de stockage. De plus, il est configuré de la manière suivante: • le système et le SGBR sont mis sur deux disques en raid 1. • l’ensemble des bases de données sont placées sur quatre disques en raid 5. • La migration • Physique

19. La migration logicielle est sans doute celle qui s’avère la plus dure à mettre en place car il va faut effectuer les tâches suivantes : • faire cohabiter Solaris 8 avec Oracle 9i. • vérifier que les packages Oracle et que les packages de Gold fonctionnent. • mettre à jour les forms vers une version 6i. • Le premier point n’est pas le plus difficile car on trouve dans les différentes documentations d’Oracle l’ensemble des correctifs à appliquer pour le bon fonctionnement d’Oracle 9i sur Solaris 8. • Au contraire, la vérification de compatibilité des packages de Gold avec ceux d’Oracle est plus difficile. C’est-à-dire qu’il a fallu trouver pourquoi des erreurs apparaissaient lors de la phase de test. Nous avons donc émis plusieurs hypothèses(évolution des packages standards, fonctions obsolètes, …) pour finalement se rendre compte que les erreurs provoquées venaient du fait que la configuration des packages était différente. • Enfin, il faut aussi mettre à niveau les Forms pour des raison de compatibilité. C’est-à-dire que les formulaires en 4.5 ne sont pas entièrement compatible avec Oracle 9i. Cette opération est sans aucun doute la plus simple car il suffit de faire un batch afin de tous les convertir de 4.5 à 6i. • La migration • Logicielle

20. Conclusion Ce stage m’a permis: • de participer à un projet important qui prend part à la vie de l’entreprise. • de mettre en œuvre l’ensemble des concepts de gestion de projet, domaine qui ne m’était pas entièrement inconnu. • d’approfondir mes connaissances sur l’utilisation du SGBDR Oracle. • d’utiliser mes acquis en langage c, shell, sql, mes bases de pl/sql et de découvrir des outils comme Oracle Forms. • d’exercer mon sens de l’analyse sur des points concrets. • de me projeter dans la vie professionnelle.