Transcript Rapport de stage en entreprise

Rapport de stage en entreprise
Hôpital Privé Gériatrique Les Sources
Sylvain Forgione
Formation TSGERI
2013-2014
Table des matières
Introduction............................................................................................................................................. 2
Présentation de la société ....................................................................................................................... 3
Présentation de l’infrastructure existante .............................................................................................. 5
Projet personnel ...................................................................................................................................... 6
Création de la VM ................................................................................................................................ 6
WDS et MDT ........................................................................................................................................ 8
Prérequis ......................................................................................................................................... 8
Windows Deployment Services (WDS) ............................................................................................ 8
Microsoft Deployment Toolkit (MDT) ............................................................................................. 9
Capture .............................................................................................................................................. 10
Personnalisation de l’image capturée ............................................................................................... 10
Applications ................................................................................................................................... 11
Pilotes ............................................................................................................................................ 12
Mises à jour ................................................................................................................................... 12
Séquences de tâche ....................................................................................................................... 13
Assistant de déploiement .............................................................................................................. 14
Déploiement ...................................................................................................................................... 15
Mise en production et monitoring .................................................................................................... 16
Conclusion et remerciements ............................................................................................................... 17
Annexes ................................................................................................................................................. 18
Annexe 1 : Guide d’utilisation du serveur WDS ................................................................................ 18
Annexe 2 : Création d’un disque iSCSI............................................................................................... 28
Annexe 3 : Intégration du serveur dans Nagios ................................................................................ 30
Annexe 4 : Configuration d’un switch de remplacement après une panne...................................... 31
Annexe 5 : Interface GLPI .................................................................................................................. 32
Annexe 6 : Solution de déploiement des imprimantes par GPO....................................................... 33
Introduction
Dans le cadre de la formation TSGERI, il est nécessaire, en fin d’année, de mettre en pratique
nos acquis lors d’un stage de deux mois en entreprise. J’ai pour ma part eu l’opportunité
d’effectuer mon stage à l’Hôpital Privé Gériatrique les Sources.
Lors de mon arrivée, mon tuteur Cyril de Balandras, responsable du service informatique,
m’a dans un premier temps présenté l’infrastructure en place, puis m’a informé des projets
qu’il souhaitait mettre en œuvre. L’un de ces projets était le déploiement d’un système de
SSO (Single Sign-On) pour faciliter l’utilisation des ordinateurs par le personnel de l’hôpital.
En effet, couplé à des lecteurs de cartes, le logiciel SSO permet aux utilisateurs de n’avoir à
rentrer leurs identifiants qu’une seule fois à l’ouverture de session, après cela c’est le logiciel
qui se charge d’identifier l’utilisateur sur les nombreuses applications web et les logiciels
métier. De même, le système de cartes sans contact permet dans le cadre des ordinateurs
« kiosque » de gérer le passage d’une session à une autre beaucoup plus facilement.
Le déploiement de ce système nécessitait cependant un système d’exploitation 64 bits, et
donc la migration du parc informatique sur Windows 7 x64. A partir de là, les objectifs de
mon stage ont pu être fixés avec dans un premier temps un inventaire complet du parc
informatique (plus de 200 postes sur 3 bâtiments) avec intégration dans GLPI (un outil de
gestion du parc) pour recenser plus facilement les systèmes 32 bits, puis la recherche d’une
solution de migration des postes XP et Windows 7 x32 vers Windows 7 x64. Cette solution
devra permettre l’intégration des logiciels métiers et des pilotes spécifiques à chaque
machine, car entre les portables et les PC fixes, le parc comprend une dizaine de types de
machines différentes.
Etant donné le nombre de postes à migrer, il est aussi primordial d’optimiser au maximum le
temps nécessaire pour effectuer chaque migration.
Présentation de la société
Hôpital privé à orientation gériatrique, l'établissement reçoit des patients actifs et retraités,
de 60 ans et plus, et offre une filière complète d’hospitalisation et une permanence des
soins 24 h/24.
Réparties dans trois bâtiments, les unités de soins regroupent 229 lits et places et sont
complétées par :
• un plateau technique médical comprenant :
-
une unité d’Hospitalisation de Jour
un Centre Neuro-Psycho-Gériatrique
un Pôle Clinique de Cardio-Gériatrie
un service central de consultations externes
une unité d’endoscopie digestive, bronchique et ORL
un service d’imagerie médicale.
• un Centre de consultations de Plaies Complexes au sein des SSR.
• un plateau technique de rééducation, de réadaptation fonctionnelle et de balnéothérapie.
Le Système d’Information Hospitalier, dirigé par Mr Cyril de Balandras, assure le maintien en
conditions opérationnelles du parc informatique, des logiciels et des applications métiers.
Les principales missions du SIH sont :
-
l’assistance aux utilisateurs, par le biais d’une interface GLPI permettant de créer des
tickets à partir de l’intranet
la maintenance matérielle des ordinateurs et des serveurs
la sécurité du réseau et des données des patients
garantir un taux de disponibilité élevé du réseau et des serveurs, notamment grâce à
la tolérance de panne et la redondance des équipements
convenir avec différents prestataires de services de l’évolution et de la maintenance
des logiciels métier
Sous la direction de Mr de Balandras, Stéphane Cayel, Antonio Lino et Emmanuelle Priola,
sont chargés d’administrer le parc informatique.
Présentation de l’infrastructure existante
L’hôpital comprend plus de 200 postes répartis sur 3 bâtiments. Les serveurs sont quasiment
tous virtualisés sur deux clusters ESXi (hyperviseur VMware) en tolérance de panne et gérés
par le biais de l’utilitaire VMware vSphere.
Chaque cluster est relié à une baie NetApp pour le stockage, et à un système de sauvegarde
sur bandes. Tous les liens réseau (liens fibre entre les bâtiments, stacks de switches et
câblage des étages de chaque bâtiment) sont doublés ou triplés, cette redondance
permettant un taux de disponibilité le plus élevé possible.
Hôpital Privé Gériatrique les Sources
Bâtiment A
Bâtiment B
Bâtiment C
~120 postes
~80 postes
~20 postes
Brassage A
Liens Fibre
Cluster
ESXi A
Liens Fibre
Cluster
ESXi B
Baie
Netapp
A
Stockage
sur bande
Brassage C
Brassage B
Baie
Netapp
B
Projet personnel
Après avoir réalisé l’inventaire, il m’a donc été confié la mission de mettre en place une
alternative au système de déploiement d’images actuellement utilisé.
Le système en place est un serveur CloneZilla sur lequel sont stockées plusieurs images,
chacune correspondant à un type de machine différent. Bien que fonctionnel, ce procédé
de déploiement est long et fastidieux. En effet, il faut soit mettre à jour les images
régulièrement, soit passer un certain temps après chaque installation pour faire les
modifications nécessaires (mises à jour Windows et applications, installation de nouvelles
applications, etc…). Ce système ne convient donc pas à la migration d’un grand nombre de
postes.
Lors d’une réunion de projet avec les membres du SI, il a donc été décidé de mettre en place
un Serveur de Déploiement Windows (WDS) sur une VM de Windows Server 2012, et les
tâches suivantes m’ont été confiées :
-
Création d’un nouvelle VM sur le cluster ESXi
Installation de Windows Server 2012 et de WDS
Paramétrage de WDS pour permettre l’optimisation du processus de déploiement
Création de la VM
La création de la VM s’est faite entièrement à partir de l’interface vSphere, avec les
spécifications suivantes, établies à partir des recommandations de Windows 2012 et de
WDS.
Un second disque dur a aussi été rajouté pour le stockage en utilisant le protocole iSCSI. Ce
protocole de SAN permet de rassembler les ressources de stockages dans un centre de
données tout en donnant l’illusion que le stockage est local, de ce fait, le disque apparait
comme un disque local sur le serveur alors qu’il se trouve en fait sur la baie NetApp. La
liaison se fait en utilisant l’Initiateur iSCSI inclu avec Windows 2012 pour obtenir un nom
d’initiateur correspondant à la machine, ce dernier est alors associé au volume créé sur la
baie de stockage, et il suffit enfin d’entrer l’IP de cette dernière sur notre serveur pour créer
le lien.
L’utilisation de l’iSCSI explique la présence de deux cartes réseau supplémentaires sur la VM
(pour redondance du lien), et permettra de cloner la VM pour la sauvegarder sans se soucier
de la taille du stockage, puisque le disque iSCSI ne sera pas inclus.
WDS et MDT
Prérequis
Le bon fonctionnement du serveur WDS nécessite la présence de :
-
-
Active Directory, le déploiement à partir de MDT nécessite une connexion à un
répertoire de partage sur le serveur. Il sera demandé un identifiant et un mot de
passe.
DNS, pour la traduction d’adresse.
Serveur DHCP pour fournir un bail aux clients lors du boot PXE.
Ces conditions sont remplies par l’utilisation de l’infrastructure existante. En effet il n’a pas
été jugé nécessaire de créer une plateforme de test car le serveur WDS n’altèrera en rien
l’infrastructure en place et ne s’en servira qu’en consultation.
Windows Deployment Services (WDS)
Le serveur WDS en lui-même ne permet pas de modifier extensivement une image capturée
avant de la redéployer, ceci est uniquement possible grâce au Microsoft Deployment Toolkit.
Cet utilitaire a donc été installé en parallèle.
WDS s'apparente donc aux solutions CloneZilla, Norton Ghost ou Acronis mais à la différence
qu'il ne s'applique généralement que sur des OS Windows et qu’il est gratuit (avec une
licence Windows Server). WDS permet aussi par le biais de la multidiffusion de ne pas
surcharger le réseau si l’on effectue un grand nombre de déploiements simultanés (ce qui ne
sera pas utile dans notre cas).
Le serveur WDS contient deux types d’images :
-
Les images de démarrage (boot.wim) sur lesquelles le poste client va démarrer pour
effectuer l’installation de l’OS. Ces images contiennent Windows PE.
Les images d’installation (install.wim), ce sont les images des systèmes d’exploitation
à installer.
Après installation du serveur, une image de démarrage de type Capture a été créée, afin de
pouvoir capturer une image d’installation à partir d’une machine existante.
Microsoft Deployment Toolkit (MDT)
Microsoft Deployment Toolkit, est un utilitaire permettant la personnalisation d’une image
initiale à partir d'un ensemble de variables (pilotes, applications, mises à jour). Le processus
de déploiement est décomposé en une séquence de tâche entièrement personnalisable.
L'ensemble des fichiers nécessaires au déploiement est stocké dans le Deployment Share,
une zone de partage contenant toutes les ressources.
Ainsi, WDS permet la capture et le déploiement des images, et MDT permet d’altérer ces
images selon le besoin.
Capture
MDT permettant la personnalisation d’une image, il est tout à fait possible de se servir de
l’iso de Windows 7 comme image de base et de la modifier à sa guise. Cependant, certaines
applications métier dont l’installation est requise sur tous les postes de l’hôpital s’intègrent
mal dans le MDT et auraient nécessité une installation manuelle après chaque déploiement,
c’est pourquoi il a été décidé de capturer une machine avec ces applications préalablement
installés.
Cette image « Master » servira de base pour tous les déploiements et est capturée à partir
d’une machine avec Windows 7 64bits, toutes les dernières mises à jour, et les applications
métier installées.
Une fois la machine prête, il suffit de lancer l’utilitaire sysprep.exe en local, en sélectionnant
le mode OOBE (Out Of Box Experience) et l’option Generalize. Cet utilitaire va permettre de
supprimer les données spécifiques à la machine (nom, SID, données utilisateur) et donc de la
« généraliser », permettant son utilisation comme image de déploiement. Une fois le
sysprep terminé, la machine redémarre, et il faut alors choisir de booter sur le réseau. Pour
ce faire, il est nécessaire d’avoir au préalable activé l’option boot PXE (Preboot Execution
Environment) dans les paramètres du BIOS de la carte réseau.
La machine se connecte alors au serveur WDS qui lui fournit un bail DHCP. Il ne reste plus
qu’à sélectionner l’image de démarrage de capture, et l’emplacement sur lequel la nouvelle
image va être sauvegardée.
Personnalisation de l’image capturée
L’image capturée est importée dans le partage de déploiement, et apparait alors dans la
section Operating System.
Il nous est alors possible de procéder à la personnalisation de l’image.
Applications
La section Applications du MDT permet d’ajouter dans le menu d’initialisation du
déploiement un écran de sélection permettant de choisir parmi les différentes applications
préconfigurées celles que l’on souhaite installer.
L’ajout d’application se fait très simplement, il suffit de choisir si l’on souhaite copier les
fichiers sources directement dans le partage de déploiement ou si l’on préfère aller les
chercher sur le réseau. Il convient ensuite d’entrer la commande d’installation en incluant
les paramètres permettant l’installation silencieuse et sans reboot.
Dans le cas d’Office, MDT donne accès à l’Outil de personnalisation Microsoft Office, qui
permet par exemple de sélectionner quels produits à installer ou non et d’enregistrer une clé
de licence KMS si un serveur de gestion des clés est en place (pas dans notre cas).
Pilotes
MDT facile la gestion des pilotes en permettant d’importer directement les packages
correspondants aux divers types de machines utilisées. Le service de déploiement sera alors
capable d’installer le package de driver correspondant en vérifiant le modèle de la machine.
Il est aussi possible de créer des filtres de sélection et de les intégrer directement dans la
séquence de tâche, pour assurer l’installation des bons pilotes.
Mises à jour
En l’absence d’un serveur WSUS, il est possible d’intégrer les packages de mises à jour
Windows directement dans le partage de déploiement. Ces packages seront alors installés
lors du déploiement et permettent donc de ne pas avoir à refaire régulièrement des
captures.
Cette méthode a également pour intérêt de fournir la possibilité de choisir exactement quel
package on souhaite déployer ou non.
Séquences de tâche
Les séquences de tâche sont la représentation étape par étape du procédé de déploiement.
Cette fonctionnalité permet donc d’éditer chaque étape du déploiement comme l’on
souhaite. Dans notre cas, une nouvelle séquence de tâche a donc été créée, correspondant à
l’installation de l’image capturée précédemment. L’étape d’installation des mises à jour,
entre autres, a été activée, et celle de l’exécution de Windows Update désactivée.
Il est aussi possible d’inclure dans la séquence l’exécution de commande à la fin du
déploiement, comme par exemple pour initier un script, ou dans le cas illustré ci-dessous
pour ajouter un profil WiFi.
Le menu propriétés de la séquence de tâche permet aussi d’éditer le fichier unattend.xml,
qui contrôle la configuration des paramètres de Windows lors du déploiement. MDT 2013
fournit une interface graphique qui permet de faciliter l’édition de ce fichier. La plupart des
paramètres du fichier unattend.xml sont modifiés automatiquement par MDT lors de chaque
déploiement selon les options choisies dans l’assistant de déploiement.
Assistant de déploiement
Après voir sélectionné une image de déploiement sur un poste client, c’est l’assistant de
déploiement qui prend en charge la personnalisation des paramètres. C’est cet assistant qui
va par exemple nous permettre de sélectionner les applications à installer, le nom à donner
à la machine ou encore le domaine à rejoindre. L’assistant va aussi demander une
authentification afin de pouvoir accéder au partage de déploiement.
Le fichier Bootstrap.ini nous permet de personnaliser l’assistant et de pré-remplir certains
champs pour maximiser les gains de temps.
Après chaque modification du fichier Bootstrap.ini, et d’une manière générale après toute
modification qui affecte l’image de démarrage, il est important de mettre à jour cette
dernière par le biais de MDT, qui va détecter les changements et les inclure au boot.wim.
Enfin, l’image boot.wim générée peut être ajoutée à WDS en tant qu’image de démarrage.
Déploiement
Une fois l’image de démarrage intégrée à WDS, il ne reste plus qu’à initier le déploiement
sur un poste client. Après avoir démarré sur la carte réseau (PXE), le client obtient son bail
DHCP et se connecte au serveur WDS, on sélectionne alors la bonne image de démarrage.
Le client essaye alors de se connecter au partage de déploiement ce qui nécessite de
s’identifier sur le réseau, sauf si ces identifiants ont été au préalable inscrits dans le fichier
Bootstrap.ini.
Une fois connecté, l’assistant de déploiement prend le relai et l’on peut alors sélectionner la
séquence de tâche qui va être suivie, choisir les applications à installer parmi celles qui ont
été ajoutées au partage de déploiement ou encore nommer le PC et renseigner le domaine à
rejoindre. Encore une fois, ces choix peuvent être automatisés par le biais du fichier
Boostrap.ini.
Il ne reste alors qu’à lancer le déploiement, aucune autre intervention ne sera nécessaire. La
durée du déploiement peut varier selon les spécifications du poste client, mais d’une
manière générale on observe un gain de 50% par rapport à CloneZilla.
Mise en production et monitoring
Le serveur WDS remplissant tous les objectifs fixés (notamment le gain de temps et la
possibilité de personnalisation des images), il a été décidé de le mettre en production pour
remplacer le serveur CloneZilla.
Pour informer les membres du service informatique du fonctionnement du serveur, une
documentation détaillant son utilisation a été créée (cf annexe).
Comme pour tous les serveurs en production à l’hôpital, ses services et ses ressources seront
monitorés par Nagios. L’intégration du serveur WDS à Nagios s’est faite en installant d’une
part un client léger en local, puis en créant un nouveau profil sur le serveur Nagios.
La création de ce profil, un fichier de configuration, s’est faite à l’aide de l’utilitaire WinSCP,
un client SFTP (SSH File Transfer Protocol). Une fois WinSCP connecté au serveur Nagios, le
fichier de configuration a pu être créé à partir d’un modèle en ajoutant notamment le
service de déploiement aux services monitorés.
Conclusion et remerciements
Au cours de ces deux mois de stage, j’ai pu réaliser le projet qui m’avait été confié, mais
aussi en apprendre beaucoup sur le fonctionnement d’un système d’information sur lequel
repose d’énormes responsabilités. Les principes de tolérance de panne et de haute
disponibilité sont appliqués à tous les niveaux, une nécessité dans le milieu hospitalier.
Dans le cadre de mon stage, j’ai donc pu participer à l’amélioration du quotidien du
personnel hospitalier en aidant au déploiement d’un système SSO facilitant l’utilisation de
leur moyen de travail. Ce projet m’a permis de mettre en application les connaissances
acquise au cours de ma formation, de la définition des objectifs et du cahier des charges
jusqu’à la mise en production.
Ma mission lors de ce stage ne s’est pas arrêtée à ce projet principal, j’ai pu en effet me
familiariser avec le quotidien des membres du service informatique, en faisant notamment
de l’assistance aux utilisateurs (remplacements du matériel défectueux, aide à l’utilisation) le
tout géré par un système de tickets implémenté dans GLPI. J’ai pu aussi participer à la
résolution de pannes matérielles avec par exemple le remplacement d’un switch défectueux
et sa reconfiguration par le biais de la console. D’autre part, j’ai pu proposer une solution à
mon tuteur pour optimiser le déploiement des imprimantes au sein de l’hôpital à l’aide de
GPOs.
Je tiens donc à remercier mon tuteur Cyril de Balandras qui m'a accordé sa confiance et m’a
donnée l’opportunité d’approfondir mes connaissances et de les mettre en application en
acceptant de me recevoir comme stagiaire.
Je tiens aussi à remercier Stéphane Cayel et Antonio Lino pour m’avoir assisté au quotidien
dans les missions qui m’ont été données et pour s’être toujours rendu disponible pour
répondre à mes questions et m’orienter dans la bonne direction.
Enfin, je souhaite remercier tout particulièrement mon formateur Denys Garcia pour
m’avoir accompagné dans mon projet professionnel pour devenir un technicien supérieur
gestionnaire exploitant des ressources informatiques. En effet, il est très facile de se perdre
dans un milieu aussi vaste que l’informatique, mais son savoir et ses méthodes
d’enseignement se sont montrés d’une valeur inquantifiable.
Annexes
Annexe 1 : Guide d’utilisation du serveur WDS
Annexe 2 : Création d’un disque iSCSI
Dans un premier temps, il faut créer un nouveau volume et un LUN ou Logical Unit Number
sur la baie NetApp. Le LUN représente un disque ou ensemble de disques faisant parti d’un
SAN. Le LUN est présenté aux serveurs connectés au SAN sous la forme d'un iSCSI Qualified
Name (IQN) avec dans notre cas une connectique Ethernet/iSCSI.
Une fois le LUN créé, il faut fournir l’iqn correspondant à notre serveur, ce dernier est obtenu avec le
service Initiateur iSCSI qui est inclu dans la version 2012 de Windows Server.
Une fois l’iqn renseigné dans NetApp, on peut initier la connexion depuis le serveur en
entrant l’IP du SAN. Le protocole CHAP est utilisé pour l’authentification, puis la connexion
est établie avec le volume avec lequel l’iqn du serveur a été associé.
Une fois la connexion établie, le serveur considère le volume iSCSI du SAN comme un disque
local.
Annexe 3 : Intégration du serveur dans Nagios
Après l’installation du client sur le serveur WDS, l’utilitaire SFTP WinSCP est utilisé pour créer
un nouveau fichier de configuration sur le serveur Nagios.
Ce fichier renseigne les services et ressources à monitorer, et défini les seuils
d’avertissement.
Le serveur WDS pourra alors être monitoré à partir de l’interface graphique de Nagios.
Annexe 4 : Configuration d’un switch de remplacement après une panne
Un des switchs ne s’allumant plus, il a d’abord été tenté de remplacer l’alimentation pour
essayer de solutionner le problème, sans succès. Un nouveau switch a alors été mis en place,
et il a donc fallu le configurer.
Pour ce faire, une connexion est réalisée par le biais du port console et de l’utilitaire PuTTY
en renseignant le taux de Baud obtenu dans le manuel du switch.
Une fois connecté, on donne une IP au switch, ce qui permettra l’utilisation de l’interface
graphique et l’intégration dans Nagios.
Enfin, on affecte les VLANs aux différents ports, selon le besoin.
Ici le port 26 est affecté au VLAN default en mode tagged (port trunk).
Annexe 5 : Interface GLPI
GLPI est un outil de gestion du parc informatique permettant entre autres de fournir un
système de tickets pour le support aux utilisateurs, et d’effectuer le référencement des
équipements du réseau.
L’inventaire des équipements (ordinateurs, imprimantes, switchs etc…) peut se faire
manuellement ou par le biais d’un plugin. Ici, le plugin OCS Inventory est utilisé. Un client est
déployé sur toutes les machines par GPO et remonte les informations qui sont ensuite
intégrée directement dans GLPI.
Ce système permet donc de rechercher très facilement toutes les machines utilisant telle ou
telle version de tel OS, par exemple.
Annexe 6 : Solution de déploiement des imprimantes par GPO
La solution de déploiement en place nécessite que l’utilisateur ajoute manuellement
l’imprimante désirée en passant par l’assistant du panneau de configuration et en la
recherchant dans l’annuaire Active Directory. Un guide détaillant la procédure a été mis à
disposition sur l’intranet mais certains utilisateurs rencontrent tout de même des difficultés.
J’ai donc étudié la possibilité d’effectuer le déploiement par GPO. La structure de l’AD ne
permettant pas d’affecter efficacement les GPO aux unités d’organisation (UO), il a fallu
trouver un moyen d’affecter une GPO à un Groupe d’utilisateurs.
Pour tester différentes solutions, je me suis servis d’utilisateurs test dans une UO à part pour
ne pas perturber le reste de l’AD.
Une GPO de test a ensuite été créé pour tester le déploiement d’une imprimante sur les
comptes de test.
Pour contourner le problème posé par la structure de l’AD, la GPO a été affecté à tout le
domaine, puis restreinte à un seul groupe d’utilisateurs à l’aide du filtrage de sécurité.
Cette solution fonctionne, mais implique de créer un GPO par imprimante ou groupe
d’imprimantes et de les affecter ensuite à tel ou tel utilisateur en l’incluant dans le Groupe
correspondant, ce qui n’est malheureusement pas faisable dans notre cas au vu du nombre
d’imprimantes en fonction (plus d’une centaine).
Ainsi, il a été décidé à la place de simplifier la procédure d’ajout des imprimantes en
déployant un nouveau lien dans les favoris du navigateur de chaque poste qui pointe
directement sur le serveur d’impression. Il suffit alors à l’utilisateur de double cliquer sur
l’imprimante qu’il souhaite ajouter.
Le guide ci-dessous a été créé, expliquant la nouvelle procédure, et a été mis à la disposition
des utilisateurs sur l’intranet.