Chapitre 1 : Mise en œuvre d’une

infrastructure informatique
(Création, modification)
1.1 Objectif de ce chapitre.
Ce chapitre présentera une introduction à la méthodologie de conception et d’implémentation d’un
système informatique d’entreprises. Plusieurs points seront abordés :
- Méthodologie générale
- Etude des éléments de choix et des contraintes techniques

1.2 Objectifs d’un projet d’infrastructure

Ce paragraphe développe une approche projet du point de vue des besoins, c’est à dire une vision
client.

A l’heure actuelle, un des points névralgiques d’une entreprise est son système informatique. La
définition de la création ou de l’évolution d’un tel système doit aussi être vue sous un aspect global
et non pas seulement technique.
D’un point de vue hiérarchique, on peut décomposer les objectifs d’un projet d’infrastructure en
plusieurs niveau.

Les objectifs généraux sont des objectifs de gestion, de production,… au sein de l’entreprise donc
complètement indépendants des contraintes informatiques. Par exemple, la mise en œuvre d’une

1
gestion centralisée de toute l’activité de l’entreprise va faire appel à un ERP (Entreprise resource
planning) progiciel de gestion intégrée, solution informatique mais uniquement définie par des
besoins liés à l’activité de l’entreprise (comptabilité, RH, production, commerciale…). Cette mise
en œuvre d’un ERP va certainement modifier profondément la structure informatique de
l’entreprise et donc conduire à la définition d’un projet d’infrastructure informatique.

Les objectifs de haut niveau concernent aussi globalement l’entreprise : ils correspondent à des
choix globaux en cohérence avec un mode de fonctionnement et des besoins déterminés.
Par exemple : un taux de disponibilité pour une entreprise fonctionnant 24H sur 24H, des niveaux
d’inter-communicabilité pour une entreprise multi-sites, une sécurisation des communications pour
une entreprise ayant des contraintes de confidentialité fortes…

En descendant dans l’arborescence on trouve ensuite des objectifs de niveau intermédiaire qui sont
ceux relatifs à un site et/ou un service.
Par exemple : un délai d’assistance technique celui étant fonction de l’éloignement du site
relativement au site hébergeant un service informatique centralisé, la protection des données d’un
service spécifique (Ressources humaines…), des accès aisés aux données pour les commerciaux en
déplacement…

Au dernier niveau on trouve deux catégories d’objectifs :

- des objectifs de bas niveau (techniques) mais concernant les utilisateurs, par exemple : utilisation
de la dernière version d’Access, passage à un logiciel libre pour la messagerie
- des objectifs pratiques qui sont liés à la gestion informatique et donc propre au service
informatique : systèmes d’exploitation des serveurs, matériel de sauvegarde…

1.3 Caractéristiques d’un projet d’infrastructure

Ce point concerne les caractéristiques de mise en œuvre du projet, hors aspect technologique, il est
le fruit d’une négociation entre le client et le concepteur/réalisateur (société de service ou service
interne à l’entreprise). Il est commun à tous types de projets.

On y trouve :
- La définition des délais et phasage
Phasage de l’opération globale
Phasage de chaque élément
- La définition des équipes de conception et déploiement (et aussi de maintenance)
Implication de la sous-traitance
Recherche de personnels temporaires
Prise en compte du travail quotidien des personnels internes (temps libéré pour le projet)
- La définition de la portée du projet
Partie de l’infrastructure
Tout l’existant (client et serveur…)
Différentes applications
- La définition du budget
Achat de matériel/logiciel
Facturation des sous-traitants…

Cette partie va servir de base économique au contrat, le concepteur/réalisateur doit évaluer

le coût global du projet (étude, mise en œuvre, formation) avant d’en faire une étude technique

2
détaillée. Dans le cadre de très gros projet avec appel d’offres, l’évaluation du coût global et de
chaque partie peut-être sous-traitée à une entreprise spécialisée qui va proposer des solutions
adaptées au besoin pouvant correspondre à un budget prévisionnel déterminé.

1.4 Différentes phases de la conception et de la mise en oeuvre

Nous allons maintenant détailler l’aspect méthodologique de la mise en œuvre d’un projet
d’infrastructure informatique. Ce point concerne l’équipe projet agissant en terme de sous-traitant
(interne ou externe) vis à vis de la direction et des autres services de l’entreprise.

On peut décomposer la conception et la mise en œuvre en 6 phases principales.

Phase de découverte
C’est l’évaluation de l’existant qui n’existe pas forcément dans une entreprise qui a vu évoluer son
système d’information de jour en jour, elle récapitule :
• L’architecture globale du réseau
• Les équipements réseau
• Les équipements serveur
• Les équipements client
• Les applications
• Les besoins des utilisateurs déjà satisfaits

C’est une phase assez simple si l’entreprise possède moins de 200 postes avec un ou deux sites et
du matériel standard et identique.
C’est une phase complexe dans le cas d’une grande entreprise avec de nombreux sites et des
équipements hétérogènes et spécifiques.

Le résultat de cette phase est compilé dans plusieurs documents :

• Inventaire des équipements et machines,

3
 • Diagrammes de réseaux : emplacement de chaque équipement…,
• Documents de configuration (correctifs, service pack,…) : un logiciel d’inventaire peut être
utilisé pour cette partie.

Phase de conception
C’est la partie technique clef du projet. On va y retrouver la définition des choix techniques
généraux et spécifiques du nouveau projet :
• Architecture globale
• Choix des technologies
• Nombre de serveurs
• Position géographique

Elle aboutit à un certain nombre de documents de conception qui vont déterminer pour chaque
sous-partie :
Objectifs ; Contexte ; Approche ; Etat final ; Budget estimé

Phase de planification
Cette phase ne concerne que la planification de la mise en œuvre, elle est donc contrainte par le
document de phasage complet du projet. Elle définit dans un document de migration les étapes pour
parvenir au système final.
C’est une phase importante car même pendant la mise en œuvre du projet, le fonctionnement de
l’entreprise ne doit pas être perturbé (ou au minimum) par les évolutions du système informatique.
De la même manière que dans le plan global du projet, on peut utiliser des outils tels que les
diagrammes de Gantt.

Phase de prototypage
Elle permet la création en laboratoire d’un ensemble regroupant tous les éléments essentiels du
système (isolé du système de production) pour faire des tests et des réglages. Si la conception a été
correcte, elle ne doit conduire qu’à des modifications mineures des choix technologiques. Elle est
souvent effectuée dans les SSII par des ingénieurs débutants.

Phase pilote
Cette phase va permettre la mise en œuvre en production sur un sous-ensemble réduit d’utilisateurs
des solutions retenues pour la nouvelle infrastructure informatique.
Elle concerne par exemple dans un premier temps, 5 à 10 utilisateurs pilotes, puis 10% des
utilisateurs.

Phase d’implémentation
C’est la phase finale de la mise en œuvre (mais non celle du projet). Elle va conformément au
document de planification conduire au déploiement total de la solution informatique. Elle inclut en
général la formation des utilisateurs et les dernières modifications suite aux retours éventuels des
utilisateurs.

Ensuite le projet rentre dans sa phase d’exploitation avec la mise en œuvre d’un support permanent
pour pallier les défauts constatés durant l’usage régulier de l’infrastructure informatique. Un
support efficace et réfléchi dès le début du projet est une condition nécessaire au bon
fonctionnement du système informatique. Ce support peut être assuré par l’équipe de
développement (ce qui permet de gérer au mieux des charges de travail différentes suivant les
phases du projet) soit par un service spécifique, les informations techniques doivent alors transiter
d’une équipe à une autre.

4
Le déroulement présenté ci-dessus n’est qu’un exemple de démarche, chaque entreprise peut
l’adapter. Des méthodologies spécifiques sont aussi imposées par certains constructeurs (Microsoft)
pour que l’entreprise, qui réalise le projet, puisse être certifiée pour l’implantation de projets faisant
appel aux technologies de ces constructeurs.

1.5 Organisation des différents serveurs

Après avoir vu l’aspect gestion de projet, nous allons maintenant nous concentrer sur la partie
technique de la conception et plus particulièrement sur le choix des serveurs et leur organisation.
Plusieurs aspects sont à considérer, tout d’abord concernant les machines serveurs :

- L’organisation logique
Elle va être la conclusion de l’étude concernant le mode de fonctionnement désiré pour
l’infrastructure du système informatique en conformité avec les différentes catégories d’objectifs
définies dans la demande initiale. Elle concerne :
L’organisation en domaines
Le découpage des utilisateurs et des groupes
Les différents droits d’accès aux ressources…

- L’organisation des services

Elle va définir en particulier les différentes catégories de serveurs qu’il sera nécessaire de mettre en
place pour constituer l’infrastructure informatique. On peut dresser une liste (non exhaustive) des
différents serveurs que l’on peut rencontrer :
Serveurs d’infrastructure : DNS, DHCP, LDAP…, contrôleur de domaine, authentification
Serveurs de ressources : fichiers, impression
Serveurs d’accès distant, Serveurs mandataires (proxy, cache)
Serveurs d’applications : terminal server, CITRIX...
Serveurs ftp, http, mail…
Serveurs de base de données
Serveurs d’installation des clients
Serveurs de ressources tierces (liés à d'autres services et non directement accessibles)
Serveurs de sauvegarde

- L’organisation physique
Elle va traduire sous forme physique la mise en œuvre des différents services sur les différentes
machines serveur :
Chapitre1 : Le regroupement de différentes fonctions sur le même serveur,
Chapitre2 : La localisation physique des services et leur duplication éventuelle…

Le bon fonctionnement de cette architecture de serveurs doit aussi s’appuyer sur une organisation
des communications adaptée qui va imposer des choix sur les infrastructures de
communication concernant les couches basses (jusqu’à Transport) :
- Liens réseaux et charge de ces liens
- Equipement réseaux (routeurs, commutateurs…)

Un dernier aspect à considérer est tous ce qui est lié au bon fonctionnement face à des contraintes
extérieures. Cela concerne la fiabilité ou sûreté de fonctionnement (défaillances des équipements et
influence de l’environnement extérieur : bruit, parasites) et la sécurité (tentative d’accès aux
données ou perturbation du bon fonctionnement par des personnes extérieures –ou intérieures- à
l’entreprise). Cela va conduire à définir deux catégories d'architecture :

5
- une architecture liée à la sûreté de fonctionnement (redondance)
- une architecture de sécurité pour faire face à des intrusions ou à des actions interdites

On pourrait compléter ces deux aspects par une architecture de surveillance permettant de manière
active d’analyser les problèmes et de faire évoluer les deux précédentes.

1.6 Les paramètres de dimensionnement des serveurs

Si les choix précédents peuvent être fait préalablement à toute mise en œuvre de l’infrastructure, il
n’en est pas de même pour le dimensionnement des machines et dans une moindre mesure des
équipements de communications.

Concernant les machines serveurs, 4 ressources principales sont à considérer :

• Stockage disques
• Mémoire centrale
• CPU
• Connexion réseaux

Il est difficile de réaliser des prévisions précises de l’usage de ces ressources surtout pour
l’utilisation de l’unité centrale, ce qui affecte directement les performances des services.
Pour la prévision des ressources nécessaires, on peut utiliser des modèles simplifiés et prendre en
compte une bonne marge de sécurité. Un des paramètres importants est le rythme de l’évolution des
besoins qui est difficilement prévisible.

Les paramètres effectifs sont :

• la possibilité de fournir le service
• le délai avec lequel il est fourni
• la fiabilité du service

Il est en général important de déterminer le facteur limitant.

(1) Stockage disques

4 paramètres physiques principaux peuvent être définis :
• La taille,
• Le délai d’accès à une information,
• Le débit en continu
• La sûreté de fonctionnement

Il est assez facile (relativement aux autres ressources) de modéliser les besoins de stockage en
terme de taille. Il faut tout de même considérer qu’un bon usage d’un disque est limité à environ
80% de sa capacité (pour ne pas introduire trop de fragmentation), valeur indicative car elle va
dépendre de l’usage du disque (données utilisateurs ou applications installées à demeure).

Le délai d’accès à une information (contrainte mécanique) sur un disque évolue beaucoup plus
lentement que la capacité ou le débit. Ce paramètre va influer si le disque est utilisé pour des accès
nombreux à des fichiers différents (pas de possibilité de cache), le nombre d’utilisateurs connectés à
un instant donné à donc une influence forte, ainsi que la catégorie d’applications par exemple :
• serveur d’applications (fichiers demandés par une machine)
• serveur WEB (fichiers demandés par un être humain).

6
Le débit est un mélange de caractéristiques mécaniques et électriques (nombre de têtes et débit du
bus). Il va être surtout prépondérant pour des transferts de données de taille importante (images,
vidéo…).
La sûreté de fonctionnement est assurée par des unités de disques en redondance (disk RAID) :
RAID0 : disque en parallèle pas d’augmentation de la fiabilité mais de la vitesse
RAID1 : miroitage complet, vitesse identique, sécurité double
RAID5 : parité répartie, permet de reconstruire le contenu d’un disque sur N si problème (3
minimum).
RAID6 : même chose que RAID5 mais avec gestion de 2 problèmes sur 2 disques.

(2) Mémoire centrale

2 paramètres sont à considérer :
• La taille
• La vitesse d’accès

En fait ces paramètres peuvent être multiples car l’organisation de la mémoire centrale fait souvent
appel à une architecture complexe de mémoire cache (à plusieurs niveaux). Il reste que la principale
différence de temps d’exécution d’une requête quelconque est conditionnée par le fait qu’elle fasse
appel à la mémoire virtuelle (disque) ou non.

(3) CPU
Les unités d’évaluation de la puissance d’un CPU (MIPS, Mflop) ne rendent qu’imparfaitement
compte de sa puissance réelle. L’adaptation d’une unité centrale à un besoin sur une machine de
type serveur ne se vérifie en général que d’une manière pratique.

(4) Connexions réseaux

L’adéquation de ce paramètre à un besoin peut être plus facilement déterminé. Une bonne
connaissance des protocoles liés à chaque service permet de déterminer un débit probable en ce qui
concerne les échanges sur un serveur. Le type d’infrastructure réseau associée peut avoir une
influence sur les résultats. Dans un réseau totalement commuté (ce qui est le cas dans une
infrastructure nouvelle actuellement), le débit sur une liaison vers un serveur est uniquement à
destination de ce serveur. Elle représente en général la somme de toutes les communications à
destination du serveur partant de chaque client connecté à un instant donné. Ceci explique que dans
la mesure du possible le lien switch-serveur doit avoir un débit plus élevé que les liens switch-client
au moins pour un serveur de fichiers.

1.7 La méthodologie de dimensionnement des serveurs

Deux approches peuvent être employées pour définir a priori le dimensionnement d’un serveur :
• La modélisation, c’est à dire l’établissement de relations mathématiques qui vont à partir de
données d’entrées (nombre d’utilisateurs, puissance des machines clients…) de calculer les
besoins de grandeurs de dimensionnement.
• La mesure, qui consiste, dans la « mesure » du possible à évaluer les capacités d’un serveur
mis en situation réelle à répondre à une certaine demande. Un des problème étant de
configurer le fonctionnement du système de test afin d’approcher la situation réelle
forcément inconnue.

7
Ces deux approches font appel à une bonne dose d’approximation, soit liée à la représentation
mathématique du fonctionnement du serveur, soit à la réalité de la mise en situation avec un
nombre limité de machines tests.
La modélisation permet facilement de modifier les paramètres de fonctionnement et ne nécessite
pas un système opérationnel, mais elle est forcément très réductrice relativement à un vrai système
même dans des conditions artificielles.
Une approche couplée peut aussi être envisagée, ce qui permet de définir des paramètres de
modélisation à partir de mesures effectuées en réel.

En pratique, les choix sont souvent effectués à partir de l’expérience des concepteurs (Exemple :
pour un serveur WEB à 100 accès simultanés, il faut 1GO de mémoire, un tel processeur…).
Ensuite, dans la mesure du possible, un bon facteur de sécurité est retenu surtout dans le cas où les
ressources supplémentaires utilisées n’engendrent pas un coût supplémentaire important.

Lorsqu’on dispose d’un système existant, il est possible d’utiliser des outils de mesure
(Performance Monitor sous Windows Server 2008 par exemple) pour évaluer les besoins d’une
nouvelle architecture basée sur le même principe.

Quelques données

Prendre en compte que la durée de vie d’un serveur est, en général, plus longue que celle d’un
client :
• un client : 5 ans maximum
• un serveur : peut aller jusqu’à 10 ans

RAM :
En dix ans la capacité de la RAM est multiplié par 100

Disque :
En dix ans la capacité d’un disque est multiplié par 30
En dix ans le débit est multiplié par 3 ; en dix ans le temps d’accès est divisé par 3

Supports amovibles, supports de sauvegarde :

Quasi disparition des supports magnétiques pour la sauvegarde (sauf disque dur). Utilisation de
disques durs type flash (plus faible capacité mais plus rapide en lecture) pour les disques système.

Disque optique :
Leur fiabilité n’est pas très grande (10 ans maximum pour un stockage sûr)

Réseaux :
Besoins en bande passante triple tous les 3 ans (cela dépend à quel niveau du réseau).
Le débit sur le réseau est inférieur au débit de données provenant d'un disque. Ce n'est pas
forcément le cas pour le temps d'accès (cache en mémoire sur les serveurs pour répondre plus vite
aux requêtes). Un client un peu puissant peut saturer le réseau côté serveur si le lien client/switch et
serveur/switch ont la même capacité. L'augmentation de la puissance des clients a produit le
passage d’un mode de fonctionnement en alternance sur le réseau à un mode de fonctionnement en
rafale.