Pilotage de projet --- Déploiement d’une infrastructure de

Projet de déploiement de l’infrastructure technique du site Achères IV de

Jean‐Jacques Frouein Page 1 Rapport de stage RPSI

Pilotage de projet

---

Déploiement d’une infrastructure de production

FORMATION AFPA / RPSI ‐ RAPPORT DE STAGE



0 SOMMAIRE

0 SOMMAIRE ............................................................................................................................................................................ 2

1 LE SECTEUR D’ACTIVITE ......................................................................................................................................................... 5

1.1 HISTORIQUE ................................................................................................................................................................... 5

1.2 LES MARCHÉS ................................................................................................................................................................. 7

1.2.1 LA TÉLÉPHONIE MOBILE .......................................................................................................................................... 8

1.2.2 L’INTERNET ............................................................................................................................................................ 13

1.3 PERSPECTIVES : LA CONVERGENCE .............................................................................................................................. 18

2 L’ENTREPRISE ....................................................................................................................................................................... 22

2.1 INTRODUCTION ............................................................................................................................................................ 22

2.2 IMPLANTATION GÉOGRAPHIQUE ................................................................................................................................ 24

2.2.1 TOUR SEQUOIA, LE SITE DE LA DG ......................................................................................................................... 24

2.2.2 RIVE DEFENSE, LE SITE DE LA DOSI ........................................................................................................................ 25

2.2.3 ACHERES, LE SITE DE PRODUCTION ....................................................................................................................... 25

2.2.4 RENNES, LE SITE DE PRÉ‐PRODUCTION ................................................................................................................. 26

2.2.5 LE BLANC‐MESNIL, LE SITE DE SECOURS (P.R.A) .................................................................................................... 26

2.3 ORGANISATION ............................................................................................................................................................ 27

2.3.1 LES DIRECTIONS GÉNÉRALES ................................................................................................................................. 27

2.3.2 LA DIRECTION GÉNÉRALE DES SYSTÈMES D’INFORMATION (DGSI) ...................................................................... 27

2.3.3 LA DIRECTION DES OPÉRATIONS SI (DOSI) ............................................................................................................ 28



2.3.4 FONCTIONNEMENT DE LA DOSI ............................................................................................................................ 28

2.4 CONTEXTE DE TRAVAIL ................................................................................................................................................ 29

2.4.1 L’URBANISATION DES SYSTÈMES D’INFORMATION .............................................................................................. 30

2.4.2 LES PROCESSUS INTERNES ..................................................................................................................................... 31

2.5 SYSTÊMES D’INFORMATION ........................................................................................................................................ 35

3 LE PROJET ............................................................................................................................................................................. 37

3.1 INTRODUCTION ............................................................................................................................................................ 37

3.2 DÉFINITION D’UNE INFRASTRUCTURE ......................................................................................................................... 38

3.3 DÉFINITION DU PROJET ................................................................................................................................................ 39

3.3.1 DÉFINITION DE L’OBJECTIF .................................................................................................................................... 40

3.3.2 DÉCOUPAGE DU PROJET ........................................................................................................................................ 44

3.3.3 ESTIMATIONS......................................................................................................................................................... 45

3.3.4 PLANIFICATION ...................................................................................................................................................... 45

3.4 APPROCHE GLOBALE DU PROJET ................................................................................................................................. 46

3.4.1 IDENTIFICATION DES PRÉ‐REQUIS COMMUNS ...................................................................................................... 46

3.4.2 POINTS BLOQUANTS .............................................................................................................................................. 47

3.4.3 MACRO‐PLANNING ................................................................................................................................................ 47

3.5 APPROCHE DETAILLÉES PAR SOUS‐PROJET .................................................................................................................. 48

3.5.1 INFRASTRUCTURE DE SAUVEGARDE...................................................................................................................... 48

3.5.2 INFRASTRUCTURE D’ORDONNANCEMENT ............................................................................................................ 53

3.5.3 INFRASTRUCTURE DE SUPERVISION ...................................................................................................................... 57

3.5.4 INFRASTRUCTURE D’ADMINISTRATION DU STOCKAGE ........................................................................................ 61

4 ANNEXES .............................................................................................................................................................................. 65



4.1 URBANISATION & ARCHITECTURE ............................................................................................................................... 65

4.1.1 L’ARBRE DES PLANS D’URBANISATION .................................................................................................................. 65

4.1.2 L’ARBRE DES PLANS D’INFRASTRUCTURES TECHNIQUES ...................................................................................... 69

4.2 L’INFRASTRUCTURE LOGISTIQUE ................................................................................................................................. 71

4.3 L’INFRASTRUCTURE RESEAU ........................................................................................................................................ 73

4.3.1 LES PRINCIPES ........................................................................................................................................................ 73

4.3.2 RESEAUX CLIENT EN ZONE DEMILITARISÉE ........................................................................................................... 74

4.3.3 RESEAUX CLIENT EN ZONE APPLICATIONS ............................................................................................................ 75

4.3.4 RESEAUX D’ADMINISTRATION ............................................................................................................................... 76

4.3.5 RESEAUX DE SAUVEGARDE .................................................................................................................................... 77

4.4 LES ENVIRONNEMENTS ................................................................................................................................................ 78

4.5 Comité de Validation technique (CoVal) ...................................................................................................................... 79

4.6 ANALYSE DES RISQUES ................................................................................................................................................. 85

5 GLOSSAIRE ........................................................................................................................................................................... 86

5.1 GÉNÉRAL ...................................................................................................................................................................... 86

5.2 INTERNE ....................................................................................................................................................................... 88



1 LE SECTEUR D’ACTIVITE

1.1 HISTORIQUE

Etymologiquement, le mot télécommunication vient du préfixe grec «tele» (signifiant : loin), et du latin «communicare»

(signifiant : partager). C’est Édouard Estaunié, ingénieur aux «Postes et Télégraphes», qui a utilisé ce mot pour la première

fois en 1904.

Aujourd’hui, le terme de télécommunication englobe tous

les moyens de transmission d’information à distance (en

émission et réception), quelque soit le mode de

communication : signes, signaux, écrits, images, sons et

ce, quelque soit le support de transmission : fil électrique,

radioélectricité, liaison optique et autres systèmes

électromagnétiques.

Télégraphe

Le moyen de communication le plus élémentaire est

évidemment la parole. Cependant, dans les sociétés

humaines organisées, le besoin de communiquer à des

distances supérieures à la simple portée de voix s’est

rapidement fait sentir. Dés lors, on a vu se développer

moyens primitifs de télécommunications : tambours,

signaux de fumée, langage sifflé, courrier, pavillons puis

les sémaphores, le morse et le télégraphe.

Alphabet sémaphore



Á l’origine, les moyens de télécommunications étaient d’abord optiques (visuels). On confond fréquemment la naissance des

télécoms avec celle du téléphone, qui a été inventé par l’italien Antonio Meucci en 1850.

La télécommunication est alors devenue électrique puis radioélectrique, mais l’ironie du sort veut que les techniques les plus

en pointe utilisent à nouveau des supports de transmission optiques (fibre).

Dans le principe, une liaison de télécommunications comporte quatre éléments principaux :

Un émetteur qui prend l’information et la convertit en signal

Un signal qui peut être analogique ou numérique

Un média de transmission qui relie l’émetteur et le récepteur par un support qui propage une transmission physique,

optique, électrique ou radioélectrique

Un récepteur qui reçoit le signal et le convertit en information utilisable

La télécommunication peut être monodirectionnelle comme en radiodiffusion ou télévision, ou bidirectionnelle, utilisant

alors des équipements qui sont à la fois émetteur et récepteur.

Quand plusieurs liaisons sont interconnectées, on obtient alors un réseau comme le réseau téléphonique ou l’internet.



1.2 LES MARCHÉS

La plupart des entreprises de téléphonie mobile en France sont positionnées sur 2 marchés convergents du secteur des

télécoms :

La téléphonie mobile

L’internet haut debit

Fin 2007, près de 80% des français de plus de 15 ans possèdent un téléphone mobile.



1.2.1 LA TÉLÉPHONIE MOBILE

1.2.1.1 L’état du marché

En France, 3 opérateurs de réseau se partagent le marché de la télécommunication mobile. Leurs revenus sont de 2 types : les

revenus d’usage et les revenus liés aux terminaux (GPS, Emails, Internet mobile, etc.…)

L’essentiel des revenus proviennent toujours des revenus d’usage, mais on observe une très forte croissance des revenus liés

aux terminaux (un peu plus de 20% en un an dont près de 30% sur le seul dernier trimestre 2007)

Les revenus d’usage se décomposent en plusieurs postes d'importance et de dynamique différentes :

les revenus liés au trafic sortant en constituent la part la plus importante (80%). Ils ont progressé de 5,6% au cours de

l’année 2007 (+ 3,9% pour le trafic voix et +17% pour le trafic données)

les revenus liés au trafic entrant représentent un peu plus de 8% des revenus et sont en diminution (‐23,5% pour les

appels de fixe à mobile, sous l'effet d'une baisse de volume du trafic et du prix des terminaisons d'appel ; ‐7,4% pour

les appels internationaux entrants et le roaming in)

les revenus liés aux services à valeur ajoutée (SMS+, services de renseignements, etc.) représentent 5,6% des revenus

et ont progressé de 4,3% en 2007

enfin, les revenus liés aux terminaux ont augmenté d'un peu plus de 20% en un an (près de 30% sur le seul dernier

trimestre de l'année 2007).

En 2007, le marché annuel de la télécommunication

mobile pesait 21,3 milliards d’€uros (après épuration des

refacturations inter‐opérateurs). Son taux de croissance

était 4,8% par rapport à l’année précédente.



1.2.1.2 L’évolution

En 2007, le parc de cartes SIM a augmenté de 3,7 millions (+7,1%) pour atteindre 55,4 millions en fin d'année.

Accroissement du nombre de cartes SIM (millions) en France sur les 15 dernières années

Taux d’accroissement en 2007 du nombre de cartes SIM (millions) en Europe



La progression de ce marché florissant tend à ralentir au fur et à mesure que son potentiel diminue. Il apparaît sur les

graphiques ci‐dessous que 87% de la population française est équipée, voire 97% dans la tranche d’âge 18‐24 ans.

Taux de pénétration de la population en France

Pénétration du Marché

0,0%

20,0%

40,0%

60,0%

80,0%

100,0%

120,0%

1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007

Années

Tau

x

Répartition par tranche d’âge



1.2.1.3 Les offres

Les offres des différents opérateurs se regroupent en 3 types :

Les abonnements : la consommation est payable en fin de mois sur la base d’un forfait. Les éventuels dépassements

sont facturés en plus

Les offres prépayées, pour lesquelles l’utilisateur règle d’avance un crédit de temps. Lorsque le crédit arrive à

épuisement, la communication est automatiquement coupée

Les forfais bloqués : C’est une offre hybride combinant des 2 autres. L’usager est engagé sur un forfait mensuel avec un

crédit de temps qu’il ne peut dépasser

Sur le plan fonctionnel, les deux dernières offres sont en réalité assez similaires et utiliseront les mêmes applications. L’offre

forfait bloqué ne diffère du prépayé que par le fait qu’il existe un contrat d’achat de crédit est automatiquement reconduit

chaque mois.

Chez les opérateurs, il n’existe en fait que deux systèmes applicatifs, l’un correspondant à l’offre « abonnement », l’autre à

l’offre « prépayé »

NB : Globalement l’offre « prépayé » est plus complexe à gérer pour l’opérateur, ce qui explique en partie les coûts

proportionnellement plus élevés. Cela nécessite une interaction en temps réel entre le réseau et le SI, afin d’effectuer en temps

réel un contrôle du crédit de temps, pour maintenir ou non la connexion. Dans le cas de l’abonnement ce contrôle est inutile, la

facturation est établie en fin de période à partir du cumul des unités

Répartition de la clientèle par type d’offre



Les 3 opérateurs de réseaux (Bouygtel, Orange et SFR) ne sont pas les seuls acteurs de la téléphonie mobile en France. Fin

2007, environ 5% du marché étaient représentés par les opérateurs virtuels, dits MVNO (Mobile Virtual Network Operators)

et presque autant pour les licences de marque.

Répartition du marché hors opérateurs



1.2.2 L’INTERNET

1.2.2.1 L’état du marché

Evolution du nombre de foyers équipés de l’accès internet haut‐débit dans le monde (en Millions)

Pour les 30 pays de l’OCDE, la pénétration moyenne était

de 21,3 accès pour 100 habitants.

La plus forte proportion d'habitants abonnés à un accès

Internet haut débit se situe au Danemark avec 36,7 %,

selon les chiffres compilés par l'OCDE. Viennent ensuite

les Pays‐Bas et la Norvège. La France occupe le 13ème

rang mondial avec 26,4 %, soit autant que la Belgique, et

juste devant l'Allemagne (26,2 %) et les Etats‐Unis (25 %).

NB : La Corée du Sud et le Canada sont les seuls pays non

européens du TOP10



1.2.2.2 L’évolution

Le réseau téléphonique commuté (réseau téléphonique) était déjà présent chez le particulier. L’idée de départ était de

l’utiliser comme support pour les communications informatiques.

La problématique résidait principalement dans la manière d’utiliser un support initialement prévu pour des communications

analogiques (voix), pour transporter des données numériques.

1.2.2.2.1 LE RÉSEAU COMMUTÉ

On a d’abord utilisé une porteuse sonore à l’instar des télécopieurs ou du minitel à l’aide d’un appareil baptisé modem (de la

contraction de modulateur‐démodulateur).

Le modem permettait de moduler des signaux numériques

sur la porteuse et de les démoduler.

Les vitesses de connexion étaient d’environ 1200 bauds

(bits/secondes) au début. Puis avec l’amélioration des

équipements et l’utilisation du protocole V92 elles ont

évoluées, pour atteindre des débits de l’ordre de 56 Kilo‐

bauds.

Modem RTC

1.2.2.2.2 LE RESEAU NUMERIQUE A INTEGRATION DE SERVICES

En France, les premières offres grand public de transmissions numériques ont été commercialisées par France Télécom avec

l’offre Numeris.

L’offre s’appuyait sur la technologie des réseaux

numériques à intégration de services (RNIS) et permettait

d’atteindre des vitesses de 64 kbit/s voire de 128 kbit/s par

l’utilisation du canal D.

Chez le particulier, cette offre n’a pas rencontré le succès

escompté car elle nécessitait une modification de la ligne

pour supporter le numérique, ainsi que la pose d’un boitier

baptisé TNR (Terminaison Numérique de Réseau) en fin de

ligne.

Terminaison Numérique de Réseau



1.2.2.2.3 LA TECHNOLOGIE ADSL

Le début des années 2000 voit l’émergence de l’ADSL (Asymetric Digital Suscriber Line) qui offrait à ses débuts des vitesses

allant de 128 kbit/s à 512 kbit/s.

Cette technologie doit une partie de son succès à son coût abordable et au fait qu’elle soit utilisable sur les lignes

téléphoniques analogiques standard.

Pour l’opérateur, elle nécessite l’installation

d’équipements appelés DSLAM dans les centraux

téléphoniques, et pour le client, un adaptateur ADSL

(appelé à tort Modem ADSL).

Les débits sur les lignes ADSL, sont inversement

proportionnels à la distance qui sépare l’utilisateur du

DSLAM. Ils peuvent atteindre 25 Mbit/s dans les

configurations les plus favorables. Les distances sont

généralement limitées à 2,5km

Depuis juillet 2007, pratiquement tous les centraux

téléphoniques du territoire français sont équipés de

DSLAM. Néanmoins les fournisseurs d’accès internet (FAI)

proposent encore les 2 types d’offres au grand public:

Une offre dite Bas‐Débit, sur le Réseau

Téléphonique Commuté

Une offre dite Haut‐Débit, en technologie ADSL

DSLAM



1.2.2.2.4 LE HAUT DÉBIT

La définition du « haut‐débit » varie selon les pays. Aux Etats‐Unis, le haut débit se définit par un débit supérieur à 768 kbit/s,

au Canada le débit doit être supérieur à 1,5 Mbit/s, au Japon on parle de haut débit à partir de 100 Mbit/s et dans les pays de

l’OCDE l’appellation « haut débit » nécessite au minimum 256 kbit/s. Tous les pays n’utilisent pas la même technologie pour

les communications en haut‐débit. En conséquence, le type de raccordement varie. Dans les pays asiatiques comme le Japon

ou la Corée, la fibre optique est le moyen le plus développé. En France comme dans certains pays du Maghreb, l’ADSL est la

technologie la plus utilisée car elle s’appuie sur un réseau téléphonique déjà présent chez les particuliers.

En France, le câble introduit par les fournisseurs de télévision par câble, offre une alternative à l’ADSL, mais celui‐ci n’est

présent que dans les zones urbaines, tout comme le satellite. Après des années de retard, la France est devenue un des pays

les mieux équipés au monde en matière de connexions haut débit. Aujourd’hui, des connexions à 8 Mbit/s sont disponibles

dans les villes de taille moyenne. L'opérateur historique est aujourd’hui tenu de collaborer avec les fournisseurs d'accès

internet, ce qui favorise une concurrence technologique et tarifaire.

En France, tous les nœuds de raccordement abonnés

(NRA) sont équipés pour l'ADSL.

Cela ne signifie pas pour autant que toutes les lignes

téléphoniques raccordées sont éligibles à l'ADSL. Des

dizaines de milliers d'internautes résident dans des zones

dites « blanches », inéligibles à l’ADSL. Ils sont toujours

contraints d’utiliser une connexion bas‐débit avec un

modem (56 Kbits), ou de s'abonner à l’internet par

satellite.

Par ailleurs, tous les centraux téléphoniques ne disposent

pas du même niveau d'équipement. Si une majorité de

NRA sont équipés pour l'ADSL2+, il en reste de nombreux

qui ne supportent que l'ADSL avec un débit limité à 2

Mbit/s.

Nœud de Raccordement Abonnés



Les centraux téléphoniques étaient (et sont encore) la propriété de France Télécom. Pour favoriser la libre concurrence,

l’autorité de régulation des communications électroniques et des Postes (ARCEP / Ex‐ART) permet le dégroupage des lignes. Il

s’agit d’une technique de séparation de la ligne internet et de la ligne téléphonique. Cette séparation permet aux opérateurs

alternatifs de bénéficier d'un accès direct à l'utilisateur final en contrôlant le réseau de bout en bout. Cela leur permet

également d’utiliser leurs propres infrastructures de collecte, induisant une baisse des prix et une diversification des services.

C’est ainsi qu’on a assisté à l'apparition du «triple play» (Internet, téléphone et télévision).

Le marché étant arrivé à une certaine maturité technologique, il est possible que la course à la vitesse ralentisse. Dans la

pratique, les débits disponibles sont souvent supérieurs aux besoins des particuliers. Il est probable que désormais, les

fournisseurs d'accès orienteront leurs efforts vers une offre de services plus riche et des tarifs plus intéressants.

Des techniques plus récentes font leur apparition, telles que le Wi MAX, en cours de déploiement dans plusieurs pays, ainsi

que les autres technologies de Boucle Locale Radio et les courants porteurs en ligne qui utilisent le réseau électrique de

distribution.

Selon les chiffres de l’ACERP, la France comptait 17,1 millions d'abonnements à Internet à haut débit au 30/09/2008, dont

16,3 millions (soit 95%) via leur ligne téléphonique (ADSL). Les 5% restants étant connectés par le câble ou la fibre optique.

Le nombre d’abonnements a augmenté de 490 000 au cours du troisième trimestre de 2008 (+3%). Sur un an, l’accroissement

est de 2,3 millions (+16%).



1.3 PERSPECTIVES : LA CONVERGENCE

Objet de prestige technologique et de curiosité à ses débuts, le téléphone mobile est devenu un bien de consommation

courant. Il n’en reste d’ailleurs pas moins un élément d’identité fort. Certains fabricants de terminaux ont d’ailleurs exploité

ce créneau en offrant à leur clientèle des moyens de personnaliser leur appareil (coques interchangeables et accessoires

divers). Des études sociologiques réalisées au Royaume Uni ont montré que le téléphone mobile avait supplanté la cigarette

chez l’adolescent, en tant que symbole du passage à l'âge adulte.

La technologie a évolué au fil de la demande, et ses

fonctions se sont enrichies. Du simple téléphone, il est

devenu «pager» (SMS/MMS), répertoire, montre, réveille‐

matin, puis appareil photo numérique voire caméscope,

agenda électronique, radio mobile, lecteur MP3 & MPEG4,

dictaphone, périphérique Bluetooth/Wifi, console de jeux,

GPS, etc.…

En parallèle à cette évolution, la technologie des

opérateurs de télécommunication évolue aussi. Les

opérateurs proposent aujourd’hui des bandes passantes

qui autorisent les flux multimédia.

Alors les terminaux sont devenus des ordinateurs de

poche qui permettent de naviguer sur internet, d’envoyer

et recevoir des courriels, de jouer en ligne, de dialoguer,

de se connecter à une visioconférence ou bien de regarder

la télévision.



Plusieurs générations de réseau se sont succédées. Après les premiers essais avec l’onéreux téléphone de voiture Radiocom

2000, on pensait que le devenir de la téléphonie mobile serait probablement dans la communication directe entre le terminal

et le satellite. Rapidement les opérateurs se sont rendus à l’évidence. Outre le problème du rayonnement, la puissance

d’émission pour atteindre un satellite consommait trop d’énergie. Cela était incompatible avec la puissance d’une batterie de

téléphone portable.

A la suite du succès relatif du Bi‐Bop de France Télécom, et

l’arrivée sur le marché de la technologie GSM, considérée

comme la téléphonie mobile de la 2ème génération, les

opérateurs se sont orientés vers le déploiement d’un réseau

de relais terrestres.

Au fur et à mesure, le réseau GSM a évolué vers les

technologies GPRS et EDGE, qui sur la même base

technologique, en ont étendu les performances.

Il faudra attendre fin 2004 pour voir apparaitre en France les

offres basées sur la 3ème génération de réseau : l’UMTS. Cette

technologie marque le début de la convergence de la

téléphonie mobile vers l’informatique.

Des évolutions de l’UMTS ont vu le jour depuis. 2009 sera le

théâtre du déploiement de la technologie HSUPA.

Lorsque l’on aborde le thème des nouvelles technologies, les deux disciplines qui viennent spontanément à l’esprit sont

l’informatique et les télécommunications. A l’aube du développement de la 4ème génération de réseau de téléphonie mobile,

plusieurs orientations technologiques sont possibles mais globalement toutes concourent à faire fusionner les offres de

téléphonie mobile avec offres d’accès internet.

Ainsi on aura probablement remarqué l’orientation stratégique des trois opérateurs français de téléphonie mobile qui ont

chacun à leur manière, doté leur catalogue d’une offre d’accès internet.



Evolution de l’offre de réseau chez les opérateurs de téléphonie mobile en France.

Panorama des principales technologies chez les fournisseurs d’accès internet

Niveau privilégié Débit

(Mbit/s)

Portée

(km)

Coût Observations transport collecte desserte

Filaire

ADSL ‐ ‐ ‐ ‐ ‐ + + + 0,5 20 5‐7 € Utilise le réseau téléphonique. Peu coûteux, largement déployé. Sensible à

la distance

SDSL ‐ ‐ ‐ ‐ + + 0,5 8 4‐5 €€ Utilise le réseau téléphonique. Débit symétrique. Portée limitée. Clientèle

plutôt professionnelle

Optique + + + + + + + + 100 et + 20 + €€€ Très haut débit. Surtout utilisé en transport et collecte. Introduction

progressive en desserte (FTTx)

CPL ‐ ‐ ‐ ‐ ‐ + 0,5‐10 0,5 € Utilise le réseau électrique de quartier. Manque de

standardisation. Sensible à la distance.

Sans

fil

WiMAX ‐ ‐ ‐ + + + 0,5‐15 5‐15 €€ Nécessite une licence (2 par région + 1 nationale). Norme récente.

Déploiement en cours en France.

Wi‐Fi ‐ ‐ ‐ ‐ ‐ + 0,25‐10 0,5 € Très répandu ; norme bien maîtrisée, nombreux équipements. Peu coûteux.

Performances limitées.

Faisceau

hertzien + + + ‐ 2‐150 20‐50 €€€€

Pour liaisons point‐à‐point. Bonnes performances mais inadapté à la

desserte (point‐multipoint).

Satellite ‐ ‐ + + 0,25‐2 €€ Disponible partout, pas d’infrastructures. Problème de la réactivité des

connexions (latence élevée).



La convergence

Les technologies de téléphonie mobile sont de plus

en plus utilisées pour accéder à internet.

Elles sont généralement fiables et robustes

(protocoles sophistiqués, bandes de fréquences

protégées).

Par contre, elles sont généralement coûteuses et

complexes à déployer sur le terrain.

En conséquence, elles sont réservées à des services

à forte valeur ajoutée et encore limitées aux zones

urbaines



2 L’ENTREPRISE

2.1 INTRODUCTION

SFR (Société Française de Radiotéléphonie) est l’un des trois opérateurs de téléphonie mobile implantés sur le territoire

français.

Née en 1987, l’ entreprise connu une progression régulière. Fin 2007, elle comptait :

plus de 6000 collaborateurs

une clientèle avoisinant les 19 millions d’abonnés (soit 34% du marché)

un chiffre d’affaire de près de 9 milliards d’Euros.

Les facteurs de réussite de l’entreprise sont essentiellement :

La présence commerciale : environ 8000 points de vente sur la France (dont environ 800 « Espaces SFR »).

La qualité du réseau : couverture GPS/GPRS = 91% du territoire (soit près de 99% de la population)

La performance du service client (leader national depuis 4 ans)



Vivendi est l’actionnaire majoritaire de SFR

Le capital de la société est partagé en 2 grands groupes :

Vivendi qui détient la majorité avec 56% et l’opérateur

britanique Vodafone pour 44%.

SFR possède intégralement 2 filiales dans le domaine de la

téléphonie fixe et l’internet haut débit : respectivement

Télé2 et Neuf Cégetel.



2.2 IMPLANTATION GÉOGRAPHIQUE

6 régions en France

16 sites fonctionnels

Près de 8000 points de vente

2.2.1 TOUR SEQUOIA, LE SITE DE LA DG

Située dans le quartier de la Défense sur la commune de Courbevoie, la tour Séquoia contient 35 niveaux dont 3 en sous‐

sol.

Les services localisés dans la tour Séquoia sont:

La Direction Générale

La Direction Commerciale

Les services commerciaux Ile‐de‐France

La Direction du Marketing

La Direction des Ressources Humaines

L’effectif y est de :

3100 personnes

4 locaux techniques par étage

3 salles informatiques



2.2.2 RIVE DEFENSE, LE SITE DE LA DOSI

Le site de Rive Défense est un bâtiment situé sur la commune de Nanterre dans les Hauts‐de Seine.

Ce site est dédié à la Direction des Opérations SI.

Y sont regroupés :

La direction de l’exploitation

Les ingénieries

Les bureaux techniques

L’effectif de Rive Défense est de :

2300 personnes

33 locaux techniques

5 locaux opérateur

1 salle informatique divisée en plusieurs salles dédiées

(TRA, plateforme, intégration, bureautique, packaging)

2.2.3 ACHERES, LE SITE DE PRODUCTION

Autrefois Courbevoie, c’est à présent sur la commune d’Achères au nord‐ouest de Paris, qu’est situé le site de production

de SFR.

Le campus comporte 5 bâtiments dont 4 abritent chacun 4

salles informatiques, soit 16 au total.

Chacune des salle a une superficie de 200 m2.

L’effectif sur site est de :

50 personnes

9 locaux techniques

10 locaux opérateur



2.2.4 RENNES, LE SITE DE PRÉ‐PRODUCTION

C’est sur le site de Rennes que sont centralisés 70% des plateformes packaging (pré‐production). On trouve également

des serveurs dédiés à la recette applicative (environ 10% du parc).

L’effectif à Rennes est de :

200 personnes dont 50% d’externes

3 locaux techniques (1 par étage)

1 salle informatique

2.2.5 LE BLANC‐MESNIL, LE SITE DE SECOURS (P.R.A)

Le site du Blanc‐Mesnil localisé au nord de Paris en Seine‐Saint‐Denis, n’est pas à proprement parlé un site de SFR. Il s’agit

d’infrastructures informatiques dédiées à SFR et hébergées dans les locaux mutualisés chez EDS.

Le PRA (Plan de Reprise d’Activité) est le site de secours de

SFR.

Tous les serveurs de production stratégiques pour

l’entreprise y sont clonés, et les données répliquées en

temps réel ou par batchs quotidiens.



2.3 ORGANISATION

Compte‐tenu du nombre important de directions, et de niveaux dans l’organisation, on se limitera à situer le

service porteur du projet au sein de SFR

2.3.1 LES DIRECTIONS GÉNÉRALES

2.3.2 LA DIRECTION GÉNÉRALE DES SYSTÈMES D’INFORMATION (DGSI)



2.3.3 LA DIRECTION DES OPÉRATIONS SI (DOSI)

2.3.4 FONCTIONNEMENT DE LA DOSI



2.4 CONTEXTE DE TRAVAIL

La culture projet est très implantée dans l’entreprise. De nombreux outils tels que Planisware OPX2, Microsoft Project

sont mis à le disposition du personnel et des formations à l’intérieur des locaux sont organisés régulièrement pour inciter

le personnel à gérer leurs tâches en mode projet.

Ce mode devient obligatoire pour toute opération ayant un impact plus ou moins direct sur l’environnement de

production. Le projet doit alors impérativement être piloté en conformité avec des processus internes prédéfinis (cf.

§2.4.2) et répondre à des exigences de qualités tant sur le plan des objectifs que des moyens de les atteindre.

Le fait que tous les projets doivent être conduits dans un cadre relativement « balisé », necessite que le porteur d’un

projet acquiert une connaissance suffisante de la culture de l’entreprise, de l’organisation des services, des circuits

internes et des règles de mise en œuvre

Le systeme d’information de SFR fait l’objet de référentiels très précis en terme de :

Techniques de conduite de projet

Qualité, performance, «capacity planning»

Architecture applicatives et techniques

Infrastructure logistiques (salles, réseaux)

Choix des couches logicielles et matérielles



2.4.1 L’URBANISATION DES SYSTÈMES D’INFORMATION

L’urbanisation est le service garant de la cohérence du/des système(s) d’information dans les différentes divisions de SFR.

Il effectue des « veilles technologiques », défini les orientations stratégiques et communique les règles de mise en œuvre,

d’évolutivité, de structuration et d’optimisation des SI.

Sur un plan fonctionnel, la démarche conduit à la définition d'une architecture cible conforme, et à la représentation de

l'existant par :

Des référentiels détaillant les composants à même de supporter les évolutions du SI, afin d'en assurer la

pérennité

Des «feuilles de route» (stipulant l'évolution de l'existant vers la cible, d’un point de vue technique)

La mission principale de l’urbanisation est avant tout de simplifier les SI pour en accroître la lisibilité et la sécurité, mais

aussi :

D’assurer l’indépendance des différents métiers ou activités

De structurer les SI en "grands blocs fonctionnels" tels que la CRM, la facturation, etc.

Faire correspondre ces blocs fonctionnels à des systèmes applicatifs (SA) ou des sous‐systèmes applicatifs (SSA),

qui représentent un jeu homogène de fonctions et de données

Les différentes applications (SA/SSA) sont implémentés de façon modulaires, conformément à une architecture orientée

service (SOA). Elles sont :

Autonomes et coopèrent entre eux par des couplages lâches. Ceci autorise le recours à des «middlewares»

standards pour supporter les flux inter‐application

Architecturés (en priorité) autour de progiciels du marché que l'on cherche à mettre en œuvre de la manière la

plus standard possible, afin de minimiser les développements complémentaires.

NB : Les notions d’urbanisation et d’architecture technique sont en rapport direct avec le projet. Cependant, pour ne pas

alourdir ce chapitre consacré à la présentation de l’entreprise, les détails sur ces notions sont reportés en annexe (cf. § 4.1)



2.4.2 LES PROCESSUS INTERNES

Il existe chez SFR une volonté significative de structurer et de rationaliser les actions pour tous les acteurs et à tous les

niveaux de l’organisation. L’objectif est de standardiser au maximum les procédures pour chacune des missions de chaque

entité. On commence par référencer les missions de la DOSI, puis on regroupe les tâches dans des procédures qui sont

ensuite jouées séquentiellement.

Le schéma ci-dessous offre un aperçu synthétique des processus définis pour chaque mission (entités en gris) de la DOSI.

Ce projet s’inscrit dans le cadre de la mission «Build», plus précisément le diagramme «Conduire un Projet d’Infrastructure»

Le processus «Build» de la DGSI



Définition des grandes phases du processus «Build»

Concevoir la solutionC’est à proprement parler la phase d’étude du projet. Celle qui engage le plus le chef de projet car c’est au cours de la phase d’étude que sont réalisés la majorité des documents, de l’étude d’opportunité jusqu’au planning.

Les principaux documents à fournir sont :

Les diagrammes d’architecture technique (DAT, voir Annexe 4.2.2) Les dossiers d’ingénierie technique (DIT), réclamés systématiquement pour les projets

Les documents de présentation au Comité de Validation Technique (CoVal) qui regroupent les spécifications matérielles, logistiques, les matrices de flux, etc.…

Réaliser la solutionC’est une phase dans laquelle on s’intéresse plus spécifiquement aux contraintes de mise en œuvre de l’infrastructure. C’est durant de cette phase que sont délivrées les dossiers de déploiement (DDD), dans lesquels sont livrées les spécifications techniques des serveurs, les contraintes d’implantation, les besoins en connexion réseau/SAN, volumétrie, sécurisation, etc

Intégrer et valider la solutionCette phase est généralement relativement longue car elle consiste à effectuer des déploiements sur différents environnements de test (cf. Annexe 4.1) dans le but de:

Mettre au point les procédures d’installation Paramétrer les progiciels Effectuer des tests de fonctionnalités dans l’environnement de recette Effectuer des tests en charge sur l’environnement de performance Optionnellement former les utilisateurs en environnement de formation Effectuer des tests de compatibilité en environnement de pré production (packaging)

En fin de phase, dresser le procès verbal de validation au bon fonctionnement (VABF)

Mettre en production la solutionC’est la phase d’aboutissement du projet : le déploiement en environnement de production. En règle générale, le rôle du chef de projet se limite à un rôle de superviseur, l’opération étant dans la majorité des cas sous‐traitée aux BT/TMA. Au cours de cette phase, les livrables à fournir sont :

Le plan de mise en production (MEP), où sont généralement détaillées les procédures de retour arrière

Le procès verbal de validation pour service régulier (VSR), rédigé en aval du projet dans la phase de bilan

Détail des sous phases du processus «Build»

Concevoir & réaliser Intégrer & valider Mettre en production

Pré‐étude/étude Étude de la faisabilité des demandes et consolidation des exigences DOSI

Réaliser Pilotage l’avancement des évolutions des différents systèmes impactés

Pré‐intégration Recette fournisseur permettant de réaliser les tests d’intégration inter systèmes

Recevabilité Réception, et contrôle des livrables afin d’autoriser l’installation

Validation Recette de bout en bout permettant de proposer ensuite la mise en production

MEP Planification et suivi des opérations de mise en production

VSR Exécution des points de contrôle afin d’estimer la qualité de service et la satisfaction des besoins



Matrice globale des processus de gestion des projets Internes / TMA / TRA par phase et responsabilité

Schéma des processus d’un projet spécifique de déploiement d’infrastructure



Logigramme d’un déploiement de serveur type



2.5 SYSTÊMES D’INFORMATION

Quelque soit la taille et l’activité d’une l’entreprise, l’organisation du/des système(s) d’information doit en principe

correspondre au modèle organisationnel de l’entreprise.

Chez SFR l’organisation des SI est de type fonctionnelle (orientée métiers). C'est‐à‐dire qu’à chaque macro fonction de

l’entreprise ou chaque unité d’affaire (Business Unit), il correspond un système d’information.

Dans le but de mettre ce lien en évidence, je me suis aventuré à superposer l’arbre hiérarchique avec la vision applicative

du SI. L’objectif de cet exercice, est d’obtenir une vision suffisamment globale de la société, des interactions entre les

services et par le fait de repérer plus rapidement les différents intervenants sur le projet.



Il existe chez SFR :

2 unités d’affaires : l’une dite « Grand Public » et l’autre « Entreprises »

4 grandes fonctions : Opérateur, Corporate, Réseau (SFR) et les infrastructures. Cette dernière étant vue comme

une fonction transversale sur laquelle s’appuient les autres.

NB : Le SI Fixe récemment recupéré de 9 télécom (et antérieurement de Télé2), se trouve à cheval sur 2 branches. Il est probable qu’à

terme ce SI soit scindé en 2 SA (l’un rattaché au SI Entreprises et l’autre au SI Grand Public à l’identique de la mobilité)



3 LE PROJET

3.1 INTRODUCTION

Le projet vise à déployer l’infrastructure technique d’un nouveau bâtiment, sur l’un des sites de production de SFR situé à

Achères dans les Yvelines. Le site est composé de 5 batiments dont 4 contiennent des salles machines dédiées à la production.

Actuellement les batiments ACH1, ACH2 et ACH3 sont déjà en service. Le déploiement qui fait l’objet de ce rapport, consiste à

déployer une infrastructure similaire à celle déjà en fonction dans trois autres bâtiments.

Du point de vue des processus, bien qu’il s’agisse d’une simple duplication d’architecture, le projet n’en est pas moins un

projet de création (de type « build », cf. § 2.5.2), car il s’inscrit dans le cadre d’une nouvelle implémentation et non dans celui

d’une évolution d’un système existant.

Ce déploiement strategique pour l’entreprise, est toutefois simplifié du fait qu’il s’agisse d’un clonage. Cette particularité

permet de s’affanchir de certaines tâches, voire de phases complètes du processus classique de déploiement de serveurs.



Néanmoins, pour SFR ce projet poursuit un objectif triple :

Le déploiement effectif de l’infrastructure

Le rodage des processus récemment mis en place au sein de l’entreprise

L’enrichissement de la base interne baptisée « Méga », par la collecte des « livrables » des différents projets.

L’extraction des informations qu’ils contiennent permet leur mise à disposition sur un serveur intranet, à l’attention

des projets futurs

3.2 DÉFINITION D’UNE INFRASTRUCTURE

Du point de vue étymologique, le mot infrastructure est la concaténation du mot Infra et du mot Structure.

Infra est un adverbe latin signifiant «au‐dessous de, inférieur à, en bas»

Structure provient du nom latin structura, issu du verbe struere : assembler

En français il existe plusieurs définitions pour le mot structure, toutes ayant trait à la notion de combinaison,

d’organisation, d’arrangement et d’agencement de différents éléments pour former une entité équilibrée

En informatique, l’infrastructure est un terme générique qui

désigne l'ensemble des éléments sous‐jacents qui un système

d’information.

On décline plusieurs types d’infrastructures :

L’infrastructure logistique (cf. §4.2), c'est‐à‐dire tout ce qui

touche à l’hébergement en salle : baies de rackage,

alimentations électriques, climatiseurs, faux

planchers/plafonds, etc.)

L’infrastructure de stockage et d’archivage : SAN, NAS, baies

de disque, robot de sauvegarde, graveurs, jukebox…

L’infrastructure de réseau (cf. §4.3) : Switch, routeurs,

brassage, VLAN, DMZ, équipements spécifiques (clé Transpac

ou autres)

L’infrastructure de serveurs, qui offre des services mutualisés

à l’ensemble du site, tels que l’administration, la sauvegarde,

l’ordonnancement, la supervision



Dans la majorité des organisations, on sépare les applications (SA/SSA) de la technique (infra). Ceci pour différentes

raisons :

Les compétences requises pour l’une et l’autre sont différentes : Les applications requièrent des connaissances

sur les métiers, la technique requière des compétences sur les systèmes.

Une gestion budgétaire plus simple : La cellule Infra étant alors considérée comme un centre de profit au même

titre que les autres unités d’affaires

Les infrastructures techniques sont généralement mutualisables : ce qui présente plusieurs avantages :

o Réduction des coûts par l’industrialisation des processus, l’utilisation optimale des ressources

matérielles, la simplification de la gestion des équipes d’exploitation, voire par l’externalisation de

l’ensemble

o Maintient d’un système d’information urbanisé et cohérent

o Fiabilisation de la sécurité en évitant la prolifération de multiples passerelles d’accès, qui si elles ne sont

pas correctement configurées, mettent en péril l’ensemble du système d’information

o Suivi de la qualité plus simple à mettre en œuvre et plus précis

Cette manière de procéder conduit à mettre en œuvre des structures techniques (Réseaux, SAN, silos de sauvegarde,

etc.…) indépendantes qui viennent en support des systèmes applicatifs (métiers). Le fait d’isoler ces structures, permet

de rester dans la conformité d’une architecture orientée services.

3.3 DÉFINITION DU PROJET

Etendue du projet sur la durée du stage

Compte tenu du temps qui m’est imparti sur ce projet (fixé par la durée du stage) et des contraintes calendaires de

l’entreprise (cf. §3.3.1.4), certaines actions se sont déroulées avant mon arrivée chez SFR, et d’autre se dérouleront après



mon départ. Néanmoins, le planning proposé couvre l’ensemble des actions de la phase d’étude jusqu’à la mise en

production.

On gardera cependant à l’esprit, que le fait que la solution soit techniquement éprouvée sur d’autres site, allège

considérablement la phase de pré‐étude. Une autre des spécificités de ce déploiement tient au fait que la mise en œuvre se

déroule sur un terrain vierge de toute implémentation préalable. En effet, dans la pratique les serveurs d’infrastructure

doivent être les premiers à être implémentés en salle de production. Cette particularité, a pour conséquence de rendre

inutiles les phases de pré‐intégration et de recevabilité. Seuls les tests de validation techniques seront à effectuer avant la

mise en production (MEP).

3.3.1 DÉFINITION DE L’OBJECTIF

3.3.1.1 Quoi ?

Le projet de déploiement de l’infrastructure n’est en réalité qu’une partie du projet global de mise en exploitation du

bâtiment ACH4.

Ce nouveau site de production aura pour vocation d’accueillir le projet BIOS (le futur système de gestion des offres de SFR).

Le bâtiment contient quatre salles séparées par des

locaux techniques. Dans un 1er temps, seules les

salles ACH4‐2 & ACH4‐4 seront mises à disposition

pour le projet BIOS et exploitées.

La cible est l’installation et la mise en œuvre de :

10 serveurs de production, pour 4 types de services :

o La sauvegarde

o La supervision

o L’ordonnancement

o L’administration du stockage (c'est‐à‐dire les serveurs destinés à administrer les baies de stockage SAN/NAS)

1 serveur de secours (PRA) pour la sauvegarde seulement

NB : Le plan de reprise d’activité fait l’objet d’une externalisation. Le projet d’implémentation de ce serveur est donc

hors périmètre pour le moment.



3.3.1.2 Qui ?

Les services d’ingénierie (par fonction : sauvegarde, ordonnancement, etc.…), dont le rôle est de communiquer les

informations techniques (spécificités d’architecture, besoins en volumétrie)

Les bureaux techniques sur le site d’Achères (BT Infra, BT systèmes, BT réseaux, BT Stockage), intervenant tout au long

du projet pour effectuer les actions sur les machines ou leur environnement. NB : Ces équipes techniques externes sont

intégralement gérées par une entreprise sous‐traitante dans le cadre d’un contrat global avec SFR. Vue des projets,

l’interlocuteur unique est le BT Coordination qui est chargé d’enregistrer les « ordres de travaux », de planifier les actions

et gérer les ressources pour répondre aux demandes dans le délai contractuel.

Le service achats qui vue du projet, ont un rôle unique d’interface avec les fournisseurs.

Le comité de validation technique, dont la fonction est de garantir la viabilité technique du projet dans l’environnement

cible. L’accord du Comité de Validation (CoVal) est un jalon incontournable dans le processus de déploiement.

Le comité de déploiement a la vision de l’ensemble des projets en cours. Il jouer un rôle de planificateur général. En

fonction de :

o De la planification présentée par les différents chefs de projets

o De l’indice de priorité des projets

o Des pré‐requis et dépendances des projets entre eux

o De la charge des bureaux technique (exécutants)

Le directeur de projet en charge du projet Achères 4, dont la responsabilité est de superviser les grandes phases du

projet : logistique, réseau, infra, etc.…

Le service de déploiement, en charge de la rédaction des ordres de travaux et du pilotage des bureaux techniques

3.3.1.3 Où ?

Bien que piloté depuis le site de la DOSI à Rive Défense, les serveurs seront implémentés sur le site de production à Achères.



Sur les 5 bâtiments du campus, l’un d’entre eux (ACH0) accueille les facilités (bureaux, restaurant, etc…), les 4 autres

(ACH1ACH4) les salles informatiques. Les bâtiments les plus importants sont les bâtiments ACH2 & ACH3, car ce sont ceux

qui abritent les cœurs de réseaux.

Historiquement, le 1er bâtiment fût achevé en 2003. Il a d’abord servi de base arrière pour le transfert du précédent site de

production situé à Courbevoie dans les hauts‐de‐Seine.

Le bâtiment 4 fît l’objet d’un rachat en 2006, adapté aux normes SFR et sera mis en service en 2009.

Sur les 11 serveurs à mettre en production, la répartition aura lieu comme suit :

9 serveurs dans les salles informatiques 2 & 4 du bâtiment ACH4

1 serveur sur le bâtiment ACH3

1 serveur sur le site du Blanc‐Mesnil, dans le cadre du plan de reprise d’activité

3.3.1.4 Quand ?

Une part importante du chiffre d’affaire des opérateurs de téléphonie mobile est réalisée pendant les fêtes de fin d’année.

Cette période que le personnel de SFR à baptisée

«Avalanche», démarre généralement à la mi‐novembre

pour s’achever à la mi‐janvier.

Elle est particulièrement propice aux ventes et aux

souscriptions de contrat. Elle entraîne un accroissement

de charge sur un certain nombre de systèmes applicatifs

(SA) : « vente & souscription » évidemment, mais

également sur l’activation, la collecte, la valorisation,

l’éditique, etc.…

Pour prévenir tout incident de production durant cette

période, la direction impose une période de gel de la

production. Sauf dérogation, aucune mise en production

ne peut avoir lieu pendant «Avalanche».

Chaque année après la période «Avalanche», les indicateurs de charge sont remontés au service du «capacity planning». C’est

à partir de ces résultats que sont calculées les prévisions de charge pour l’année suivante. Ces estimations sont ensuite

communiquées aux différents projets, afin qu’ils fassent évoluer leurs plateformes technique si le besoin s’en fait sentir.

TOTAL MENSUEL D'ACTES VS

0

200000

400000

600000

800000

1000000

1200000

janv-07

févr-07

mars-07

avr-07

mai-07

juin-07

juil-07

août-07

sept-07

oct-07

nov-07

déc-07

janv-08

févr-08

mars-08

avr-08

mai-08

TOUT ACTES DE GESTION

CREATIONS DE LIGNES

VOLUMETRIE DU JOUR LE PLUS CHARGE DU MOIS

0

20000

40000

60000

80000

janv-07

févr-07

mars-07

avr-07

mai-07

juin-07

juil-07

août-07

sept-07

oct-07

nov-07

déc-07

janv-08

févr-08

mars-08

avr-08

mai-08

TOUT ACTES DE GESTION

CREATIONS DE LIGNES

Projet de déploiement de l’infrastructure technique du site Achères IV

AFPA/RPSI 2008 ‐ 43 ‐ Jean‐Jacques FROUEIN

Les premières implémentations du projet BIOS sont planifiées au début 2009. Compte‐tenu de certains pré‐requis et de délais

incompressibles (voir planning), la mise en production des serveurs ne pourra avoir lieu avant la période avalanche. Aussi, il

est impératif que les serveurs d’infra soient implémentés dés la sortie de la période « avalanche », afin que les projets

applicatifs ne soient pas retardés du fait de la non disponibilité de l’infrastructure.

3.3.1.5 Comment ?

Le schéma global d’un projet d’infra

Le stage ne couvre que 2 phases du projet :

La phase d’étude, au cours de laquelle :

o Sont effectués :

Les réunions de prises d’information avec les services d’ingénierie, récupération information

techniques (attachements réseau, matrices de flux, DIT, volumétrie, contraintes spécifiques de

sécurité, etc…)

La collecte des documents techniques (caractéristiques des serveurs, attachements LAN/SAN)

Mise à jour des Documents d’Architecture Techniques (DAT)

Diverses tâches administratives (attribution d’adresse IP, nommage, déclaration DNS,

inscriptions des projets aux différents comités)

Les présentations en COmité de VALidation technique (CoVal)

NB : Un exemple de présentation est présenté en annexe § 4.5

o Sont fournis :

Compte‐rendus de réunion

Le macro‐planning

Les documents d’architecture technique

Les documents de présentation au CoVal



La phase de réalisation, au cours de laquelle :

o Sont effectués :

Les réunions de déploiement

Les différents ordres de travaux relatifs aux serveurs (installation en salle, installation des

socles technique et des applications, création des comptes, réservation de volumétrie

SAN/NAS, ouvertures de flux, etc…)

La levée des éventuelles réserves formulées au CoVal

Le suivi des commandes/livraisons

La présentation au comité de déploiement

o Sont fournis

Les micro‐plannings

Les fiches serveurs (1 par machine)

Les Dossiers De Déploiement (DDD)

3.3.2 DÉCOUPAGE DU PROJET

Comme défini au § 3.3.1.1, les applications composant l’infrastructure sont au nombre de quatre (sauvegarde, supervision,

ordonnancement et administration du stockage). Ces composantes sont relativement indépendantes les unes des autres (*),

ce qui rend le découpage évident.

Cet état de fait, permet un découpage simple en 4 sous‐projets :

Déploiement des serveurs de sauvegarde

Déploiement des serveurs d’ordonnancement

Déploiement des serveurs de supervision

Déploiement des serveurs d’administration du stockage



(*) Ceci ne signifie pas pour autant qu’ils n’ont entre eux aucune interaction. En production, nombre de services d’infra

s’appuient sur d’autres. A titre d’exemple, l’ensemble des serveurs du SI doivent être sauvegardés et surveillés qu’ils soient

applicatifs ou d’infrastructure. Les serveurs d’ordonnancement jouent un rôle important dans le déclanchement et

l’enchaînement des sauvegardes. Il existe une règle stipulant que toutes les données et applications doivent être déployés sur

des baies de disques (cf. §3.5.4). Cette règle est également applicable aux serveurs d’infrastructure, d’où l’utilité des serveurs

d’administration du stockage dans l’attribution et l’évolution de ces volumétries, etc.

3.3.3 ESTIMATIONS

Cette tâche qui théoriquement se déroule dans la phase de pré‐étude, n’est pas traitée à mon niveau. Comme précisé au §

3.3, des actions ont été réalisées en amont du projet dans le cadre du projet global «Achères 4», avant mon arrivée.

Les plateformes matérielles nécessaires à la réalisation des projets ont déjà été définies et chiffrées par les services

d’ingénierie compétents, budgétées et commandées par les achats et une partie d’entre elles étaient déjà livrées à mon

arrivée sur le projet.

Etant donné que toutes les tâches d’exécution doivent être réalisées par différents bureaux technique externes, les

estimations de charge de travail sont difficiles à réaliser et assez dépourvu d’intérêt dans la mesure où toutes les tâches sont

sous‐traitées. Des OT (Ordres de Travaux) étant adressés au BT Coordination qui se doit de les faire exécuter dans un délai

contractuel. En conséquence, pour toutes les tâches de réalisation, seuls les délais contractuels sont représentés sur le

planning, la charge réelle

on été réalisées à titre indicatifs, mais toutefois non valorisées. Les équipes techniques (BTs) sont externalisées, les coûts sont

forfaitaires et mutualisés à l’ensemble des services de la DOSI. Les impacts financiers sont certes reversés sur les projets par

les services administratifs, mais de manière forfaitaire. Le chiffrage des charges ne présente donc pas d’intérêt dans ce

contexte.

3.3.4 PLANIFICATION

Les phases d’étude et certaines tâches de la phase de réalisation des quatre sous‐projets peuvent être aisément parallélisées.

Toutefois, compte‐tenu de la charge prévisionnelle sur les BTs (Bureaux Techniques) à la sortie de la période « avalanche », il

peut s’avérer opportun de « séquentialiser » les mises en production, sachant que les interconnexions entre services devront

être réalisées au fil de l’eau.

Certains pré‐requis sont communs à la mise en œuvre des quatre axes de déploiement. Ces actions devront être dans la

logiques, traitées de façon prioritaire.



3.4 APPROCHE GLOBALE DU PROJET

3.4.1 IDENTIFICATION DES PRÉ‐REQUIS COMMUNS La disponibilité de l’infrastructure logistique

Il s’agit de la capacité d’accueil physique des serveurs. Autrement dit les conditions nécessaires à leur implantation en

salle informatique :

o Baie de rackage conditionné par la hauteur en « Units » des serveurs

o Alimentation électrique conditionné par la consommation électrique en Watt

o Les besoins en climatisation conditionné par la dissipation thermique en calories

o Les besoins en câblage cuivre conditionné par le nombre d’attachements réseau

o Les besoins en fibre optique conditionnés par le nombre d’attachements au SAN

La disponibilité de l’infrastructure réseau

Le réseau local d’Achères est organisé de manière à simuler 2 zones distinctes : APP & DMZ, séparées par un pare‐feu

nommé « Firewall Client » (Voir Annexe). Plusieurs VLAN sont définis en standard à l’intérieur de chacune de ces zones.

La règle est que chaque serveur doit être connecté sur 3 VLAN au minimum dans l’une ou/et l’autre des 2 zones :

VLAN CLI pour le « réseau CLIent »

VLAN SVG pour le « réseau de SauVeGarde »

VLAN ADM pour le « réseau d’ADMinistration »

NB : Bien que cette règle établies par les ingénieries et inscrite au référentiel technique de l’urbanisation soit une condition

sine qua non pour la mise en production d’un serveur, l’installation ne requière en théorie que l’accès au réseau ADM. Les

serveurs sur lesquels sont stockés les images du Socle Technique Etendu (STE) se situent sur le réseau ADM, par

conséquent il est indispensable que ces serveurs soient visible des serveurs à installer. Le raccordement aux autres réseaux

pouvant être effectué ultérieurement. Les pré‐requis en réseau pour l’installation des serveurs sont donc :

o Le raccordement du réseau ADM : obligatoire

o Le raccordement au réseau SVG : optionnel (sauf pour l’infra de sauvegarde)

o Le raccordement au réseau CLI : facultative

La disponibilité de l’infrastructure SAN/NAS

La disponibilité du SAN et/ou du NAS est préliminaire au déploiement d’application sur serveur, mais pas à l’installation

du système d’exploitation qui selon le référentiel technique doit être installé sur des disques internes en miroirs (pour les

serveurs de pré‐production et production). En revanche, les autres composantes du Socle Technique Etendu (CFT, MQ‐

Series, client/moteur Oracle…) n’échappent pas à la règle du déploiement sur des baies externes. Bien qu’il ne s’agisse

pas d’une procédure référencée, il est possible d’effectuer l’installation du STE en deux temps.

NB : La raison principale du déploiement des outils sur des disques externes, est que les serveurs de production et pré‐

production critiques sont toujours secourus. Un clone du serveur actif (préconfiguré à l’identique) est en salle prêt à être

activé en cas de défaillance du serveur primaire. Au moment de la bascule, ce serveur doit être capable de monter en

l’état l’ensemble des systèmes de fichiers en lieu et place du serveur primaire.

La disponibilité des serveurs



La disponibilité des serveurs est simplement conditionnée par la livraison de l’ensemble des composants sur le site

d’accueil.

3.4.2 POINTS BLOQUANTS

L’infrastructure réseau. Après plusieurs essais infructueux, le VLAN ADM & SVG sont délivrés le 20/10/2008, puis

débranché peu de temps après pour éviter tout risque d’impact sur le réseau de production pendant la période

« avalanche ».

La mise en production de l’infrastructure SAN et NAS est repoussée au 20/01/2009.

Période « Avalanche », du 17 décembre au 12 janvier.

3.4.3 MACRO‐PLANNING

Macro‐planning (la zone grisée sur le schéma correspond à la période « avalanche »)

L’ordre logique de déploiement est :

1. Les serveurs de sauvegarde en premier. Bien que les jobs de sauvegarde soient effectivement lancés par les serveurs

d’ordo, une première sauvegarde de la configuration est systématiquement lancée par les administrateurs au moment de

l’installation d’un SSA.

2. Les serveurs d’ordonnancement en second. Dans la pratique, se sont les serveurs d’ordonnancement qui sont chargés de

démarrer les processus sur les autres serveurs, en particulier les processus de sauvegarde.



3. Les serveurs d’administration du stockage en troisième. Bien qu’il soit possible de gérer les baies de stockage en «mode

commande» depuis des serveurs d’administration, l’industrialisation et l’automatisation de ce type de tâche est

incontournable en production.

4. Les serveurs de supervision en dernier lieu. La supervision a pour rôle la surveillance des autres serveurs. A l’instar de la

sauvegarde, la supervision en production est aussi indispensable qu’une alarme ou une assurance. Cependant un arrêt

momentané de la supervision n’a pas avoir d’impact sur la production. Par ailleurs, il est tout à fait évident que

l’infrastructure complète doit être déployée avant l’arriver des serveurs métiers. Aussi, s’il est indispensable que tous les

serveurs métiers soient supervisés, on peut concevoir que les autres serveurs d’infra ne soient pas supervisés tant qu’ils

ne sont pas en charge de serveurs métier.

3.5 APPROCHE DETAILLÉES PAR SOUS‐PROJET

3.5.1 INFRASTRUCTURE DE SAUVEGARDE

3.5.1.1 Consignes de déploiement

Déploiement de 4 serveurs de type HP‐RX6600 :

1 sur le site d’Achères 3

2 sur le site d’Achères 4

1 sur le site du Blanc‐Mesnil (PRA)

Host Serveur CPU

Ram(Go)

Socle Technique

Constr. Modèle Type Nb Cœurs Fréq.

SU1243 HP RX6660 Itanium Dual‐Core 4 8 1,6 16 Hpux 11iV2




Les serveurs sont déployés avec le dernier socle qualifié pour les plateformes à base de processeurs «Itanium», sur le système

HPUX 11iV2.

L’outil utilisé pour la sauvegarde est : «Legato Networker» de la société EMC2.

Le prix de l’espace disque ayant considérablement diminué, on effectue à présent les sauvegardes quotidiennes sur disque. A

cette fin, on installe en salles des baies dédiées spécifiquement aux sauvegardes (baies CLARIION).

L’infrastructure Networker se compose ainsi :

Une ou plusieurs baies CLARIION, doublement attachées en fibre multi‐modes aux nœuds de sauvegarde (nodes)



Un serveur (maître) dont le rôle est de piloter des nœuds de sauvegarde. C'est‐à‐dire de collecter les remontées

d’information en provenance des nœuds, si nécessaire effectuer les relances et centraliser les données de

paramétrages. Le serveur Networker utilise 2 bases de données :

o Une base RMAN (base Oracle utilisées pour les catalogues Networker), dont le déploiement est prévu sur le SAN

mais toutefois possible sur le NAS.

o Une base Networker (base propriétaire utilisée pour les index de fichiers/cartouches) dont le déploiement

ailleurs que sur le SAN est probablement possible mais non qualifié pour l’instant.

Plusieurs nœuds de sauvegarde (esclaves) qui dupliquent (et éventuellement compressent et/ou encryptent) les

données des clients de sauvegardes (serveurs métiers ou d’infra). En fonction des volumétries à sauvegarder et des

contraintes spécifiques à chaque client (confidentialité des informations, plage de disponibilité…), les nœuds peuvent

adopter des configurations différentes. Sur le site d’Achères 4, il est prévu de déployer :

o 1 nœud «standard», en attachement redondé simple de 2 Gb/s sur le VLAN SVG

o 1 nœud «performance», en multi‐trunking redondé de 4 x 2Gb/s sur le VLAN SVG

Les ressources réseau ne sont utilisées que dans le cadre des sauvegardes des disques internes ou du NAS. Comme il est

mentionné plus loin (cf. §3.5.4), les données applicatives sont stockées sur des baie SAN (EMC2‐DMX4000), par conséquent la

grande majorité des flux de sauvegarde transitent directement par les attachements fibre des baies DMX4000 vers les baies

CLARIION (via le nœud Networker)

Bien qu’il soit prévu pour piloter les nœuds installé sur d’Achères 4, le serveur maître sera cependant installé physiquement à

Achères 3. En pratique il est beaucoup plus commode d’installer les serveurs maîtres sur les «cœurs de réseau»* pour

plusieurs raisons :

Il est parfois nécessaire d’effectuer des restaurations croisées entre serveurs situés sur des bâtiments différents

Cela simplifie l’accès au silo de sauvegarde situé sur le site du PRA

Les flux entre le maître et les nœuds sont faibles (administration essentiellement)

(*) Les «cœurs de réseau» situés sur les sites d’Achères 2 & 3 (voir annexe §4.3.1) ont la particularité de voir l’ensemble

des VLAN du site. Les attachements réseau des serveurs Networker sont d’ailleurs configurés en «VLAN Tagging» sur la

totalité des VLAN SVG du site d’Achères.

3.5.1.2 Pré‐requis de déploiement

Réseau :

Serveurs installés en zone APP en :

Double attachement sur le réseau ADM

Double attachement sur le réseau CLI

Spécificités pour le réseau SVG décrites plus haut



Logistique :

Serveurs rackés en baie EFIRACK

Serveur maître Networker (SU1246) installé sur le site d’Achères 3

Serveurs esclaves (SU1244 & SU1245) installés sur le site d’Achères 4 dans 2 salles distinctes

Stockage :

Comme à l’accoutumé, les systèmes d’exploitation seront installés sur systèmes de fichiers localisés sur les disques

internes (en miroir) pour une volumétrie globale d’environ 100Go

Coté serveur (maître), les outils ainsi que la base Networker et la base RMAN seront déployés sur le SAN.

Coté nœuds (esclaves), une volumétrie de 4To par nœud est à réserver sur les baies CLARIION pour les données de

sauvegarde.

3.5.1.3 Caractéristiques logistique

Host Serveur

Env. Localisation Caractéristiques Techniques

Constr. Modèle N° Série Site Salle Trav Empl Hauteur Surface Puiss. Elec. (kVA) Puiss. Calor. (btu)

SU1243 HP RX6660 DEH4837XL PRA LBM 7U 1,8 5572

SU1244 HP RX6660 DEH48375XK Production ACH4 1 T2 I 7U 1,8 5572

SU1245 HP RX6660 DEH48375XW Production ACH4 2 T2 I 7U 1,8 5572

SU1246 HP RX6660 DEH48375XV Production ACH3 7U 1,8 5572

3.5.1.4 Étude des flux

Matrice des flux

N° Source/Cible Type Commentaire

1 HEPATIQUE ‐‐> SU1246 TCP / 22 Flux SSH : Station d'admin ‐‐> Server Networker

2 BELLE ‐‐> SU1246 TCP / 22 Flux SSH : Station d'admin ‐‐> Server Networker

3 SM0020 ‐‐> SU1246 TCP / 22 Flux SSH : Station d'admin ‐‐> Server Networker

4 SU1246 ‐‐> SU1244 TCP / 22 Flux SSH : Serveur Nerworker ‐‐> Storage Node performance

5 SU1246 ‐‐> SU1245 TCP / 22 Flux SSH : Serveur Nerworker ‐‐> Storage Node standard

6 Client de svg ‐‐> SU1244 TCP/111/7937‐9936/10001‐30000 Flux Networker : agent ‐‐> Storage Node performance

7 Client de svg ‐‐> SU1245 TCP/111/7937‐9936/10001‐30000 Flux Networker : agent ‐‐> Storage Node standard

8 SU1244 ‐‐> SU1246 TCP/111/7937‐9936/10001‐30000 Flux Networker : Storage Node performance ‐‐> Serveur Networker

9 SU1245 ‐‐> SU1246 TCP/111/7937‐9936/10001‐30000 Flux Networker : Storage Node standard ‐‐> Serveur Networker

10 SU1246 ‐‐> HEPATIQUE TCP/111/7937‐9936/10001‐30000 Flux Networker : Serveur Networker ‐‐> Station d'admin

11 SU1246 ‐‐> BELLE TCP/111/7937‐9936/10001‐30000 Flux Networker : Serveur Networker ‐‐> Station d'admin

12 SU1246 ‐‐> SM0020 TCP/111/7937‐9936/10001‐30000 Flux Networker : Serveur Networker ‐‐> Station d'admin

13 SU1246 ‐‐> PRAACSL1 TCP‐UDP/111/1024‐65535 Flux ACSLS : Serveur Nerworker ‐‐> Serveur ACSLS



Schéma d’architecture flux

3.5.1.5 Architecture technique



3.5.1.6 Micro‐planning



3.5.2 INFRASTRUCTURE D’ORDONNANCEMENT


Déploiement de 2 serveurs de type HP‐RX2660 sur le site d’Achères 4

Hostname Serveur CPU Ram

(Go) Socle

Technique Constr. Modèle Type Nb Cœurs Fréq.



Les serveurs sont déployés avec le dernier socle qualifié pour les plateformes à base de processeurs «Itanium», sur le système

HPUX 11iV2.

L’outil utilisé pour l’ordonnancement est : «Control‐M» de la société BMC Software.

La fonction d’un outil d’ordonnancement est d’assurer une gestion complète du lancement de travaux sur les autres

machines. Chaque machine cliente est pourvu d’un client Control‐M, prévu pour lancer une suite de tâches sur ordre du

serveur Control‐M et renvoyer des codes de retour relatifs au(x) déroulement de la (des) taches.

Le paramétrage des serveurs d’ordonnancement est une tâche qui réclame une certaine attention car les règles de

déclanchement des jobs en théorie assez simple, peuvent se révéler assez complexe lorsque plusieurs conditions

interdépendantes sont à réunir pour démarrer effectuer une action. Par ailleurs, une erreur d’ordonnancement peut avoir un

impact direct sur la production.

La puissance du serveur requise pour l’outil Control‐M est assez faible et les flux générés sporadique et bref. En conséquence,

un seul serveur actif est nécessaire pour l’ensemble du bâtiment. Le second serveur est configuré et installé prêt à démarrer

en cas de défaillance du serveur principal.


Réseau :

Serveurs installés en zone APP en :



Double attachement sur le réseau SVG

Logistique :


Serveur actif (SU1230) et serveur de secours (SU1231) devront être installés sur le site d’Achères 4 dans 2 salles

distinctes



Stockage :

Les systèmes d’exploitation seront installés sur systèmes de fichiers localisés sur les disques internes (en miroir)

L’outil Control‐M nécessite pour son exploitation une base de données ainsi que le moteur Oracle 10G. La volumétrie

sera stockée sur le NAS et demandée que pour un seul serveur, compte‐tenu du fait que les 2 serveurs ne sont pas

prévu pour fonctionner simultanément.


Serveur Env.

Localisation Caractéristiques Techniques

Hostname N° Série Site Zone Salle Trav Empl Hauteur Surface Puiss. Elec. (kVA) Puiss. Calor. (btu)

SU1230 DEH48387HL Production ACH4 APP 2 T2 I 2U 0,72 1900

SU1231 DEH48387HM Production ACH4 APP 1 T2 I 2U 0,72 1900


Matrice des flux

N° Source / Cible Type Commentaire

1 su0420adm/su1230adm TCP/2380 Flux EM HR2 ‐> SM1 HR4, Interface

2 su0420adm/su1231adm TCP/2380 Flux EM HR2 ‐> SM2 HR4 , Interface

3 Su1230adm/HR4‐APP‐ALL TCP/7016 FLUX SM1 ‐> AGENT, Interface

4 Su1230adm/HR4‐DMZ‐ALL TCP/7016 FLUX SM1 ‐> AGENT, Interface

5 Su1230adm/HR4‐RAPID, TCP/7016 FLUX SM1 ‐> AGENT, Interface

6 Su1231adm/HR4‐APP‐ALL TCP/7016 FLUX SM2 ‐> AGENT, Interface

7 Su1231adm/HR4‐DMZ‐ALL TCP/7016 FLUX SM2 ‐> AGENT, Interface

8 Su1231adm/HR4‐RAPID TCP/7016 FLUX SM2 ‐> AGENT, Interface

9 HR4‐APP‐ALL/Su1230adm TCP/7015 FLUX AGENT ‐> SM1, Interface

10 HR4‐DMZ‐ALL/Su1230adm TCP/7015 FLUX AGENT ‐> SM1, Interface

11 HR4‐RAPID/Su1230adm TCP/7015 FLUX AGENT ‐> SM1, Interface

12 HR4‐APP‐ALL/Su1231adm TCP/7015 FLUX AGENT ‐> SM2, Interface

13 HR4‐DMZ‐ALL/Su1231adm TCP/7015 FLUX AGENT ‐> SM2, Interface

14 HR4‐RAPID/Su1231adm TCP/7015 FLUX AGENT ‐> SM2, Interface










3.5.3 INFRASTRUCTURE DE SUPERVISION


Déploiement de 4 serveurs de type SUN‐T5220 sur le site d’Achères 4

Hostname Serveur CPU Ram

(Go) Socle

Technique Constr. Modèle Type Nb Cœurs Fréq.

SU1232 SUN T5220 UltraSpark T2 1 4 1,2 16 Solaris 10 / STE 8




Les serveurs sont déployés avec le dernier socle qualifié pour les plateformes à base de processeurs «UltraSpark» en SUN

Solaris.

L’outil utilisé pour la supervision est : «Patrol» de la société BMC Software.

La vocation des serveurs de supervision est principalement la surveillance des autres serveurs et le traitement des alertes. Si

l’on peut comparer l’infra de sauvegarde à une police d’assurance, alors on comparera l’infra de supervision à une installation

de télésurveillance.

Du fait de la multiplicité des alertes potentielles multiplié par la nature et la diversité des équipements à surveillés, les

systèmes de supervisions sont de fait relativement complexes. Le but n’est pas d’entrer dans la technique, mais de déployer

ces systèmes dans les mêmes conditions que les autres infrastructures.

La supervision est bien sûr nécessaire dans la zone APP, où sont installés la majorité des serveurs critiques, mais également

dans une zone de plus grande vulnérabilité telle que la DMZ.

Comme pour l’ordonnancement, les critères de fiabilité et de continuité de services ont un indice de priorité plus fort que les

critères de performances. C’est donc des configurations avec un serveur actif et un serveur de secours qui seront déployée.


Réseau :

Deux serveurs installés en zone APP et deux en zone DMZ en :



Double attachement sur le réseau SVG

Logistique :


Pour la zone APP, le serveur actif (SU1232) et le serveur de secours (SU1234) installés sur le site d’Achères 4 dans 2

salles distinctes



Pour la zone DMZ, pour des raisons de configurations de salles le serveur actif (SU1233) et le serveur de secours

(SU1235) installés sur le site d’Achères 4 dans la même salle

Stockage :

Les systèmes d’exploitation seront installés sur systèmes de fichiers localisés sur les disques internes (en miroir)


Serveur Env.

Localisation Caractéristiques Techniques

Hostname N° Série Site Zone Salle Trav Empl Hauteur Surface Puiss. Elec.(kVA) Puiss. Calor.(btu)

SU1232 DEH4837XL Production ACH4 APP 2 T2 I 2U 0,75 2560

SU1234 DEH48375XK Production ACH4 APP 1 T2 I 2U 0,75 2506

SU1233 DEH48375XW Production ACH4 DMZ 2 T2 I 2U 0,75 2560

SU1235 DEH48375XV Production ACH4 DMZ 2 T2 I 2U 0,75 2560


Matrice des flux


1 Agent Patrol RT Server TCP/2059 Protocole utilisé pour la communication avec les RT Server.

2 RT Server RT Server TCP/2059 Protocole utiliser pour la communication avec les RT Server.

3 Console Server RT TCP/2059 Protocole utiliser pour la communication avec les RT Server.

4 Distrib. Server RT TCP/2059 Protocole utiliser pour la communication avec les RT Server.

5 PCM RT Server TCP/2059 Protocole utiliser pour la communication avec les RT Server.

6 PCO Web RT Server TCP/2059 Protocole utiliser pour la communication avec les RT Server.

7 PCO Windows RT TCP/2059 Protocole utiliser pour la communication avec les RT Server.

8 Distrib. Server Agent TCP/3181 Protocole utiliser pour la communication avec les RT Server.

9 PCM Agent Patrol TCP/3181 Protocole utiliser pour la communication avec les RT Server.

10 BEM BEM TCP/1828 Protocole utiliser pour l'envoie des alarmes générées par les agents patrol

11 IXS BEM TCP/1828 Protocole utiliser pour l'envoie des alarmes générées par les agents patrol

12 IX BEM TCP/1828 Protocole utiliser pour l'envoie des alarmes générées par les agents patrol

13 BII4P BEM TCP/1828 Protocole utiliser pour l'envoie des alarmes générées par les agents patrol

14 BIEA BEM TCP/1828 Protocole utiliser pour l'envoie des alarmes générées par les agents patrol

15 IX IXS TCP/3084 Protocole utiliser pour la communication entre IX et IXS

16 BII4P Console Server TCP/4097 Protocole utilisé par BII4P (BMC Impact Integ. for Patrol) pour l'utilisation de la console server

17 SNMP BIEA UDP/162 Protocole utiliser pour la remontée des alarmes des équipements SNMP de type (Sonde, RP, …)










3.5.4 INFRASTRUCTURE D’ADMINISTRATION DU STOCKAGE

Déploiement de 2 serveurs de type HP‐DL385 sur le site d’Achères 4.

Host Serveur CPU Ram

(Go)Socle

Technique

Constr. Modèle Type Nb Cœurs Fréq.

SW0062 HP DL385 Opteron Quad‐Core 1 4 2,3 4 Windows Server 2003

SW0063 HP DL385 Opteron Quad‐Core 1 4 2,3 4 Windows Server 2003

Les serveurs sont déployés avec le dernier socle qualifié pour les plateformes à base de processeurs «Wintel» en MS Windows

2003 Server US.

NB : La politique interne de l’entreprise interdit le stockage des données applicatives sur les disques internes de serveurs. Le

stockage est composé d’armoires de disques (baies) installées en salle. L’espace disque contenu dans les baies est mis à la

disposition des projets sur demande des responsables de projet. En fonction de leur technologie et des besoins propres aux

projets, les baies sont connectées aux serveurs de 2 manières : soit via un réseau local (NAS), soit via un réseau spécifique de

fibre optique (SAN).

L’outil utilisé pour l’administration des baies de stockage est : «ECC» de la société EMC2.

ECC est actuellement utilisé pour l’administration des switch SAN et des baies EMC2 SYMMETRIX et CLARiiON. Les baies NAS

ne font pas encore partie du panel des baies administrables par ECC, mais des annonces publiées par EMC2 font état de

développements dans ce sens. Actuellement les liens réseaux ne sont pas sollicités pour les tâches d’administration, se sont

les liens fibre qui sont utilisés.

L’outil ECC tourne sur des plateformes Windows, les 2 serveurs sont actifs. Chaque serveur est configuré et attachés

préférentiellement à certaines baies, mais chacun des serveurs est en mesure de reprendre l’ensemble des attachements en

cas d’indisponibilité de l’autre.


Réseau :

Deux serveurs seront installés en zone en :

Attachement simple sur le réseau ADM

Attachement simple sur le réseau CLI

Attachement simple sur le réseau SVG

Logistique :


Pour la zone APP, les serveurs (SW0062 & SU1234) seront installés sur le site d’Achères 4 dans 2 salles distinctes



Stockage :

Les systèmes d’exploitation ainsi que les outils seront installés sur les disques internes (en miroir)


Host Serveur

Env. Localisation Caractéristiques Techniques

Constr. Modèle N° Série Site Salle Trav Empl Hauteur Surface Puiss. Elec.(kVA) Puiss. Calor.(btu)

SW0062 HP DL385 CZ835116C Production ACH4 2 T2 I 2U 0,6 1300

SW0063 HP DL385 CZ8351190 Production ACH4 1 T2 I 2U 0,6 1300


Matrice des flux


1 Serveur ECC ‐> Agent ECC TCP / 5798 MGA

2 Agent ECC ‐> Serveur ECC TCP / 5799 MGA

3 Serveur ECC ‐> Agent ECC TCP / 10222 EGS

4 Agent ECC ‐> Serveur ECC TCP / 10222 EGS

5 Serveur ECC ‐> Agent ECC TCP / 11011 EGN

6 Agent ECC ‐> Serveur ECC TCP / 11011 EGN

7 Serveur ECC ‐> Agent ECC TCP / 11031 EGF

8 Agent ECC ‐> Serveur ECC TCP / 11031 EGF

9 Serveur ECC ‐> Agent ECC TCP / 11041 MGL

10 Agent ECC ‐> Serveur ECC TCP / 11041 MGL

11 Switch ‐> Agent ECC TCP / 161 SNMP

12 Switch ‐> Agent ECC TCP / 162 SNMP

13 Switch ‐> Agent ECC TCP / 80 FAL



16 Agent ECC ‐> serveur Windows TCP / 10444

17 Agent ECC ‐> serveur AIX TCP / 11018

18 Agent ECC ‐> serveur Solaris / i

TCP / 10555

19 Agent ECC ‐> serveur HP‐UX TCP / 11021

20 Agent ECC ‐> Baie Clarion TCP / 11041 MGL

21 Agent ECC ‐> Baie Clarion TCP / 6389 MGL










4 ANNEXES

4.1 URBANISATION & ARCHITECTURE

4.1.1 L’ARBRE DES PLANS D’URBANISATION

En fonction des acteurs, il y a plusieurs manières de regarder le système d’information :

4.1.1.1 Une vision fonctionnelle

Généralement, Les dirigeants voient l’entreprise par

domaines fonctionnels

Dont chacun est composé de blocs fonctionnels

Eux‐mêmes constitués de sous‐blocs. Chaque niveau

étant appelé un niveau d’urbanisation



4.1.1.2 Une vision applicative

Les utilisateurs regardent l’entreprise en termes

de métier(s)

Chaque métier correspond à un système

d’information dont les composants (SA et SSA)

sont en théorie, indépendants de ceux des autres

SI

Les plateformes d’infrastructure techniques qui font l’objet du projet du déploiement dont il est question, font exception

à cette règle. Elles sont par définition, attachées à une localisation géographiques (le site, le bâtiment voire la salle. Elles

ne peuvent donc être associées à l’ensemble d’un SI multisite. A contrario, elles s’associent de manière transverse sur

l’ensemble des SI locaux au même titre que les infrastructures logistiques (salles blanches, groupes électrogènes,

équipements réseaux, climatisations…)

Depuis l’UMTS, on assiste à une convergence des équipements (et donc des architectures) entre les systèmes

d’informations (SI) et les plateformes de service(PFS). Il n’est toutefois pas encore possible d’étendre la mutualisation des

plateformes d’infrastructure techniques aux PFS, et encore moins au réseaux.



Chaque SI est composé de SA (systèmes applicatifs)

Puis de SSA (sous‐systèmes applicatifs)

Puis d’application(s)



Les applications communiquent entre elles par l’intermédiaire de flux applicatifs. On modélise ces flux en réalisant un Diagramme d’Architecture Applicative (DAA)



4.1.2 L’ARBRE DES PLANS D’INFRASTRUCTURES TECHNIQUES

Les services informatiques, en particulier le personnel responsable de l’exploitation des serveurs (les architectes, les

administrateurs systèmes et réseaux, les DBA, les techniciens de maintenance, etc…), regardent le système

d’information sous d’autres angles:

4.1.2.1 La vision architecture technique

Le diagramme d’architecture technique représente les matériels (serveurs, équipements réseau, Vlan, stockage…)

Pour chaque SSA, il est possible à partir du Diagramme d’Architecture Applicative (DAA) et de la connaissance des

matériels, de décliner une vision logique par un Diagramme d’Architecture Technique (DAT)



4.1.2.2 la vision chaîne d’accès

Les diagrammes de chaîne d’accès modélisent les flux techniques (systèmes d’exploitation et middlewares)

Partant du DAT, avec la connaissance des couches système et middleware, on peut réaliser le schéma les flux techniques

qui impactent les serveurs



4.2 L’INFRASTRUCTURE LOGISTIQUE

Plan du bâtiment 4

SO : Salle Opérateur RGI : Répartiteur Général Informatique

CVC : Chauffage, Ventilation, Climatisation LTC : Local Technique de Communication

SAS : Salle Accueil Sécurité

Plan des salles Informatiques / Travées / Local Technique de Communication (LTC)



Plan d’une salle



4.3 L’INFRASTRUCTURE RESEAU

4.3.1 LES PRINCIPES Les VLAN ne s’étendent pas entre les bâtiments

Seuls les cœurs de réseaux (ACH2 & ACH3) voient l’ensemble des VLAN du site

Chaque serveur est systématiquement connecté sur 3 réseaux :

o Réseau CLI (Client) qui supporte les flux métiers (flux clients, flux inter serveurs, …)

o Réseau ADM (Administration) qui supporte les flux d’administration des infrastructures ou des SSA

(accès des Bureaux Techniques, plan d’ordonnancement, supervision, etc.)

o Réseau SVG (Sauvegarde) qui supporte les flux de sauvegarde et de chargement de systèmes

d’exploitation (init).

L’infrastructure est découpée en 2 entités (zone réseau)

o Une zone APP où se trouvent les serveurs applicatifs de production. C’est une zone sécurisée, aucun

serveur de présentation (serveur web) n’y est présent.

o Une zone DMZ où se trouvent : les serveurs de présentation (Internet, intranet, extranet)

o Toutes les machines des SSA critiques non‐conforme au référentiel Achères, qui doivent être isolés de

la production (Architecture WAB par exemple)

L’accès aux serveurs passe par :

o Un pare‐feu client (FW Client) qui filtre les accès aux réseaux clients (DMZ ou APP)

o Un pare‐feu d’administration (FW Administration) qui filtre les accès aux réseaux d’administration



4.3.2 RESEAUX CLIENT EN ZONE DEMILITARISÉE

Rôle de la zone CLIDMZ :

Supporter toutes les DMZ créées derrière le pare‐feu d’accès (FW Client)

Héberger des équipements (mutualisés pour toutes les DMZ) de :

o Répartition de charge

o Compression de données

Permettre la création des zones démilitarisées étanches et sécurisées*

(*) Aucune DMZ ne peut discuter avec l’extérieur ou avec une autre DMZ sans passer par le pare‐feu de production



4.3.3 RESEAUX CLIENT EN ZONE APPLICATIONS

Rôle de la zone CLI APP :

Supporter les 6 catégories de VLAN applicatifs de la zone APP(*) :

o Mobilité

o OSS

o SAP (Business)

o Corp

o Middleware

o SGP

(*) Les accès vers ou depuis une DMZ ou l’extérieur sont filtrés par le pare‐feu de production, en revanche il n’existe aucun

filtrage entre les différents VLAN de la zone APP



4.3.4 RESEAUX D’ADMINISTRATION

Rôle de la zone ADM :

Supporter les VLAN d’administration des serveurs situés en zone APP et DMZ

Filtrer les accès entre les VLAN d’administration et avec l’extérieur, grâce au pare‐feu d’administration (FW

administration)

NB1 : Dans la zone APP, il n’existe qu’un seul VLAN d’administration par bâtiment. En revanche, il faut passer par le pare‐feu

d’administration (FW Administration) pour accéder au VLAN d’administration d’un autre bâtiment.

NB2 : Dans la zone DMZ, il existe autant de VLAN d’administration que de VLAN DMZ. Le passage d’un VLAN d’administration

à l’autre sera systématiquement filtré par le pare‐feu d’administration (FW Administration)



4.3.5 RESEAUX DE SAUVEGARDE

Rôle de la zone SVG :

Supporter les VLAN de sauvegarde des serveurs situés en zone APP et DMZ

Les infrastructures de sauvegarde sont directement connectées au réseau SVG

La zone est inaccessible depuis l’extérieur (non routée). Pour y accéder il est nécessaire d’activer le service adéquat

(sauvegarde, boot, …) depuis l’intérieur

NB1 : Dans la zone APP, le VLAN de sauvegarde est commun à tout le bâtiment.

NB2 : Dans la zone DMZ, il existe un VLAN de sauvegarde dédié par DMZ. La sécurisation entre les différents VLAN SVG est

assurée par un boîtier de sécurité sur lequel est raccordée l’infrastructure de sauvegarde



4.4 LES ENVIRONNEMENTS

Dans le but de répondre à des finalités spécifiques, il existe 7 types d’environnement distincts. En fonctions de leur

vocation, ce sont des répliques plus ou moins fidèles de l’environnement de production.

L’environnement de développement : généralement installées chez les fournisseurs, ces plateformes sont utilisées

par les développeurs pour développer les programmes et effectuer les tests unitaires.

L’environnement de recette (intégration) : la plupart du temps dans les locaux de SFR, quelque fois chez les

fournisseurs, ces plateformes reproduisent (ou simulent) l’architecture de production et permettent d’effectuer

des tests de bout en bout (BeB) (ou tests d’intégration)

L‘environnement de packaging (pré‐production) : situé sur le site de Rennes, le packaging est un clone de la

production. Tout y est reproduit, des versions de système (patch compris) jusqu’aux applications en passant par les

versions du middleware. L’objectif étant de faire cohabiter toutes les applications appelées à tourner sur les

mêmes plateformes et simuler les flux entre SSA. C’est le dernier sas avant la production, les jeux de tests déroulés

en packaging ont vocation à déceler les éventuels bogues qui n’auraient pas été identifiés en intégration.

L’environnement de production : c’est l’environnement qui est utilisé pour les affaires de l’entreprise. Les garanties

pour évitées l’incident ont été prises en amont. Tout incident en environnement de production a un impact plus ou

moins sérieux sur le business de l’entreprise.

L’environnement de formation : les environnements de formation comme leurs noms l’indiquent, sont utilisés pour

former le personnel ou les partenaires à une application ou à une chaîne d’application. En général, ce sont des

environnements plus ou moins taillés à la demande en fonction de l’étendu du SSA à reproduire.

L’environnement de performances : cet environnement est utilisé pour qualifier des machines pour une utilisation

bien déterminée. Toute une panoplie de logiciels est utilisée pour charger les serveurs à différents niveaux.

L’objectif est de stresser les machines pour en étudier le comportement. A partir des relevés de mesures, des

courbes d’extrapolation sont établies. Les environnements de performance sont utilisés par les projets pour des

essais ponctuels, et surtout par le « capacity planning » dans le but d’établir de prévisions de charge.

Le PRA (Plan de Reprise d’Activité) : Il s’agit d’un site de secours externalisé et géographiquement déporté. Cet

environnement reçoit régulièrement des répliques des données de production. Tous les serveurs critiques pour

l’entreprise y sont clonés. Cet environnement à pour vocation de redémarrer le business de l’entreprise en cas de

désastre sur le site de production.



4.5 COMITE DE VALIDATION TECHNIQUE (COVAL)













4.6 ANALYSE DES RISQUES

L’objectif est d'identifier le plus exhaustivement possible les événements générateurs de risques pour le projet, pouvant

conduire au non‐respect des objectifs. Une fois la liste établie, il convient d’inclure et d’évaluer les risques combinatoires,

c'est‐à‐dire résultant de la combinaison d’autres facteurs de risques.

A contrario, certains risques non fondés ou acceptables (c'est‐à‐dire sans conséquence notable) peuvent être supprimés de la

liste (ou marqués comme tels) pour ne garder que ceux réellement susceptibles d'affecter le déroulement du projet et devant

faire l'objet d'un suivi particulier.

On établit une matrice dans laquelle un indice est affecté à chaque risque. Il est calculé comme le produit de la probabilité

d'apparition par son niveau d'impact (incidence).

L’activité de réduction des risques consiste ensuite à mettre en œuvre des dispositions appropriées visant à rendre les risques

acceptables pour le projet. Ces dispositions peuvent être de différents types :

suppression des causes

partage de responsabilités

limitation des conséquences

acceptation du risque tout en le surveillant

Le choix des actions préventives à engager est effectué en comparant les coûts de leur mise en œuvre avec les coûts des

conséquences du risque, en tenant compte de leur indice.



5 GLOSSAIRE

5.1 GÉNÉRAL

SIGLE LANG DEFINITION

ACL A Listes d'accès contrôlés (Acces Controled Lists)

BU A Unité d'affaires (Business Unit)

CRM A Gestion de la Relation Client (Customer Relation Management)

DAF F Direction Administrative & Financière

DSI F Directeur des Systèmes d'Information / Direction des Systèmes Informatiques

GED F Gestion Electronique de Documents

GPRS A Norme pour la téléphonie mobile dérivée du GSM permettant un débit de données plus élevé (General Packet Radio Service)

GSM A Norme numérique de 2ème génération pour la téléphonie mobile (Global System for Mobile communications)

ICP F Indicateurs clé de performance (KPI en anglais)

IT A Informatique (Information Technology)

KPI A Indicateurs clé de performance (Key Performance Indicator) ‐ ICP en français

MCO F Ensemble des mesures qui garantissent la bascule vers un environnement dégradé (Maintient en Conditions Opérationnelles)

MEP F Mise en Production

NSI F Nouveau Système d'Information

OAT A Synonyme de VABF en français (Operational Acceptance Test)

OHC A Synonyme de VSR en français (Operational Health Check)

OLA A Accord sur les niveaux de Opérationnels (Operational Level Agreement)



OPX2 ‐ Outil de gestion de projet édité par Planisware.

OTP A Mot de passe à usage unique (One Time Password)

PAQ F Plan d'Assurance Qualité

PRA F Plan de reprise d'activité

PRM A Gestion de la Relation des Partenaires (Partner Relationship Management)

QoS A Qualité de Service (Quality of Service)

ROI A Retour sur Investissement (Return on Invest)

RSS A Famille de formats XML utilisés pour la syndication de contenu Web (Really Simple Syndication)

SI F Système d'Information

SID A Identifiant de sécurité (Security Identifier) utilisé par les systèmes windows pour gérer les accès à partir des ACL

SLA A Accord sur les niveaux de Service (Service Level Agreement)

TCO A Coût total de possession (Total Cost of Ownership)

TMA F Tierce Maintenance Applicative

TTD A Propriété electrique de transmission (True‐Time Delay)

TTM A Temps de mise sur le marché (Time to Market)

UMTS A Technologies de téléphonie mobile de 3ème génération (3G) européenne (Universal Mobile Telecommunications System)

VABF F Jalon de fin de phase de recette (Vérification d'Aptitude au Bon Fonctionnement) OAT en anglais

VBF A Fonction d'affaire vitale (Vital Business Function)

VSR F Jalon de fin de phase pilote (Vérification de service régulier)



5.2 INTERNE

SIGLE LANG DEFINITION

AEM F Annuaire Externe Mobilité

ASTUCE ‐ Helpdesk des applications métiers

AT F Assistance Technique

BE F Branche Entreprise (BU Entreprise)

BeB F Bout en Bout (tests)

BGP F Branche Grand Public (BU Grand Public)

BIOS A Projet de Refonte de la Gestion des Offres Commande/Valorisation/Facturation (Billing, Invocing, Ordering

CoDep F Comité de Déploiement

CORE A Système de consolidation et du déblonnage des moyens de paiement (Customer Operational Repository)

CoVal F Comité de Validation Technique

DECLIC ‐ Helpdesk des applications bureautiques

DGRS F Direction Générale des Réseaux & Systèmes

DOSSI F Direction des Opérations de Service et des Systèmes d'Information

DSI GP F Direction des Systèmes d'Information Grand Public

DSI O&C F Direction des Systèmes d'Information Opérateur & Corporate

DSIE F Direction des Systèmes d'Information Entreprise

GCPP F Gestion Client Pré‐Payé

LS F Ligne de service

MEGA ‐ Base de Donnée SFR contenant les schémas d'architecture des SA/SSA



PFS F Plate‐Forme de Services

PMT F Palier de Montée Technique

PVCS ‐ Outil de gestion du Workflow (Annomalies/Changements/Configurations)

RevCo F Revue de Conception

RSS F Réseau Sécurité Sociale

S3P F Gestionnaire Personnel Pré‐Payé

SA F Système Applicatif

SDM F Suivi des Dossiers de Maintenance

SFR F Société Française de Radiotéléphonie

SIMP F Système d'Information des Moyens de Paiement

SIMPA F Système d'Information des Micro‐Paiements

SIRENE ‐ Méthode de gestion de projet (obselète)

SRR F Société Réunionaise de Radiotéléphonie

SSA F Sous‐Système Applicatif

STE F

Socle Technique Etendu: Ensemble de outils allant des systèmes d’exploitation aux moteurs de bases de données en

passant par toute la panoplie des middlewares inscrits au référentiels technique

UMM A Offre SFR (Universal Mobile Music)

V&S F SSA : Vente & Souscription