Professional Documents
Culture Documents
Jean-Marc Grosjean
Sommaire
1. 2. 3. Rsum...........................................................................................................................3 Introduction .....................................................................................................................4 Contexte et gense du projet...........................................................................................5 3.1. 3.2. 3.3. 3.4. 4. La sauvegarde des donnes du SI de France Telecom...........................................5 Les besoins de scurisation des donnes ...............................................................8 La consolidation des datacenters et la rduction des cots d'exploitation .............10 La gense du projet ..............................................................................................11
Le rle du chef de projet MOA technique.......................................................................17 4.1. 4.2. 4.3. 4.4. 4.5. La relation MOA / sponsor.....................................................................................17 La relation MOA / utilisateurs finaux ......................................................................17 La relation MOA / MOE .........................................................................................19 La relation MOA / exploitants ................................................................................20 Une position dlicate.............................................................................................20
5.
Droulement du projet ...................................................................................................21 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. Architecture technique ..........................................................................................21 Suivi de la relation fournisseurs.............................................................................26 Organisation du projet de dploiement..................................................................27 Installation de l'infrastructure.................................................................................28 Phase pilote ..........................................................................................................32 Organisation de l'exploitation rcurrente ...............................................................33 Dcision de gnralisation ....................................................................................33
6.
Bilan du projet ...............................................................................................................35 6.1. 6.2. Dploiement de l'infrastructure ..............................................................................35 Amlioration de la QS ...........................................................................................35
7. 8. 9.
Bilan personnel .............................................................................................................36 Glossaire .......................................................................................................................37 Annexes ........................................................................................................................38 9.1. 9.2. Cahier des charges initial de DOSI........................................................................38 Vues graphiques du CentricStor en fonctionnement..............................................43
2/48
1.
Rsum
Avec l'explosion des volumes de donnes gres par le systme d'information, la bande magntique, du fait de ses grandes capacits et de son faible cot reste une technologie largement utilise pour raliser la sauvegarde et l'historisation des donnes de production. Les technologies de stockage sur disque profitent elles aussi de l'augmentation de capacit des disques bas cot, elles ont l'avantage de la souplesse, mais elles souffrent tout de mme d'un cot lev et d'une consommation nergtique importante, si l'on prend en compte des temps de rtention long des donnes. L'arrive sur le march de solutions hybrides de virtualisation mariant les avantages des deux solutions (rapidit et flexibilit du disque et bas cot de la bande) a concid avec le besoin de France Tlcom de faire voluer son infrastructure de sauvegarde sur bandes vieillissante et ne rpondant plus aux nouvelles exigences. Le sujet que j'ai choisi de traiter concerne le projet de mise en uvre d'une infrastructure de virtualisation des lecteurs de bandes. Je dcris ici le rle que j'ai jou dans le projet en tant que global project leader, allant de l'expression de besoin la mise en uvre de l'exploitation en passant par l'architecture, la qualification et l'installation du matriel. Ce projet s'tend sur la priode janvier 2005 juin 2006.
3/48
2.
Introduction
Lors de mon arrive chez France Telecom, la formation initiale du cursus IPISO m'a permis de m'immerger trs rapidement dans le contexte de la production informatique d'un systme d'information trs complexe. J'ai t form aux technologies des systmes ouverts, acquis les bases concernant l'architecture technique et les grand principes de l'organisation mise en place pour rpondre au besoin. Mais j'ai aussi t sensibilis aux nouvelles contraintes auxquelles devrait faire face le SI de France Tlcom dans les annes venir : rduction des cots d'exploitation, augmentation toujours plus rapide des capacits de stockage et des puissances de calcul qui, tout comme la demande toujours plus importante de scurit et de qualit de service, apportent autant de dfis relever pour permettre France Tlcom de conserver sa comptitivit. Mon premier poste au sein de la Direction technique Oprationnelle (DTO) du SNPI (Service National de Production Informatique) m'a permis de dvelopper rapidement des comptences d'expert technique en protection des donnes dans une quipe en charge du support niveau 3 sur les infrastructures de sauvegarde (serveurs et logiciels de sauvegarde ainsi que robots et lecteurs de bandes magntiques). En plus de l'aspect technique li la fonction support, j'ai pu me consacrer aux autres activits de l'quipe sauvegarde de la DTO : - mener bien l'volution de l'architecture de sauvegarde : consolidation, rduction des cots, augmentation de la capacit, en relation avec les fournisseurs et diteurs - participer l'volution de l'organisation et des processus permettant une meilleure qualit de service des sauvegardes en relation avec les quipes d'exploitants applicatifs Au cours de la priode de 2 ans (janvier 2003 janvier 2005) entre mon arrive en poste oprationnel chez France Tlcom et le dmarrage du projet, de nombreux mouvements d'organisation ont impact le fonctionnement de l'quipe sauvegarde : - apparition d'une quipe d'exploitation centralise des infrastructures de sauvegarde - fusion des entits SNPI et USEI et des quipes sauvegardes correspondantes - et autres mouvements de direction rvlant une volont d'optimiser l'organisation et les processus Pendant cette priode, mon poste a donc volu dans la continuit pour aboutir un rle d'animation d'une quipe oprationnelle d'une douzaine de personnes charge de raliser l'exploitation quotidienne ainsi que de mener la consolidation des infrastructures sur les datacenters de rgion parisienne. En tant en charge de l'volution d'une infrastructure transverse aux applications et aux projets du SI, j'ai pu prendre la mesure de la complexit du systme d'information et j'ai eu l'occasion d'tre au cur des volutions du permettant de rpondre ces nouveaux challenges de simplification, d'optimisation des cots et de scurisation. A sa mesure, le projet dont j'ai ensuite t charg et qui fait l'objet de ce document rpond ce mme impratif de rationalisation du systme d'information.
4/48
3.
Dans des centres d'exploitation du systme d'information tels que ceux de France Tlcom, le standard de sauvegarde des donnes sur bandes magntiques tait encore peu contest au dbut des annes 2000. La scurit des donnes de l'entreprise tait donc le primtre rserv des fournisseurs de bandes magntiques, des constructeurs de drouleurs de bandes, des constructeurs de librairies automatises effectuant le chargement et le dchargement des supports dans les drouleurs et enfin des diteurs des logiciels de sauvegarde chargs de piloter le tout. Dans une entreprise de la taille de France Tlcom une spcialisation des exploitants s'est donc effectue pour grer cette infrastructure technique. La sauvegarde est souvent, suivant le modle des systmes mainframe, une tche raliser pendant la nuit une fois l'application ferme aux transactions, avant ou aprs les traitements en mode batch, durant ce que l'on appelle une fentre de sauvegarde. Cependant, plusieurs tendances vont faire voluer ce modle - disparition des fentres de sauvegardes avec l'apparition des services 24/24 et besoins de sauvegardes " chaud" - augmentation des volumes sauvegarder - besoin de rduire les cots de manutention des supports magntiques - apparition sur le march de disques de plus en plus capacitifs et technologies de rplication de donnes l'intrieur des baies de stockage
3.1.2.
En 2003, l'exploitation du SI en France est rpartie entre 2 types d'entits. Les USEI (Unit de Supervision et d'Exploitation Informatique) : Nanterre, Savigny, Lille, Nantes, Toulouse, Blagnac, Lyon et Strasbourg, sont le rsultat du regroupement de l'exploitation du SI des Directions Rgionales de France Tlcom, il regroupe par consquent le SI historique et dont l'infrastructure est dploye pour chaque rgion. L'architecture et l'ingnierie de ce SI est pilot par l'OCISI (Organisme de Central d'Intgration et de Soutien du SI). Le SNPI (Service National de Production Informatique), dispose de datacenters en Ile de France (Antony, Vlizy, Paris). Il a t cr plus rcemment et regroupe comme son nom l'indique l'exploitation des applications nationales, quelles soient les anciennes applications mainframe (comme la facturation du fixe) ou de nouvelles applications de France Tlcom ou d'Orange consolides au niveau d'un seul site de production. Du fait de leur volution indpendante et de l'historique qu'elles ont t amenes intgrer, ces entits se trouvent en 2003 dans des situations diffrentes concernant les logiciels de sauvegarde et les robots de mise sur bande. Concernant les logiciels de sauvegarde : - les USEI utilisent le logiciel TiNa (Time Navigator) de la socit Atempo sur l'ensemble de leurs sites 5/48
le SNPI a mis en uvre le logiciel Netbackup de la socit Veritas pour les serveurs UNIX et Windows de l'ensemble de ses sites
Concernant les robots et lecteurs de bandes, les USEI comme le SNPI disposent d'un important parc de robots de moyenne capacit (environ 500 bandes) du constructeur STK (StorageTek) quips de lecteurs de bandes DLT fabriqus par Quantum, ces robotiques arrivent en fin de maintenance, posent des problmes de qualit de service et sont limites en capacit : - les USEI ont lanc un projet de renouvellement de l'ensemble de leur parc par des robots de moyenne capacit ADIC et des lecteurs au standard LTO2 tous deux vainqueurs d'un appel d'offre au niveau du groupe - le SNPI a ce moment termin un projet de virtualisation des bandes dans le domaine MVS (mainframe IBM) qui a libr sur les 3 sites un certain nombre de robots de grandes capacit STK (appels silos en raison de leur forme dodcagonale et de leur capacit de 6000 slots). Le remplacement des lecteurs DLT par des lecteurs STK nouvelle gnration consolids dans ces silos, rendus disponible pour le primtre UNIX, va dispenser le SNPI de dmarrer un projet de remplacement des robots de moyenne capacit.
3.1.3.
L'organisation de l'exploitation
En 2003, les entits USEI et SNPI sont distinctes, mais le mme mouvement d'organisation des quipes se met en place. Au dpart, une seule quipe d'exploitation existe au SNPI (que j'intgre) et au niveau de chaque USEI. Le besoin de maitriser au jour le jour la qualit de service des sauvegardes tout en menant des projets de fond d'volution des infrastructures a conduit centraliser les quipes et les spcialiser : - une quipe d'exploitation en charge du traitement des incidents quotidiens, du reporting ainsi que des relations avec les autres entits d'exploitation - une quipe d'expertise en charge des projets d'volution de l'infrastructure, de l'analyse froid des incidents et de l'laboration des plans d'actions correspondants ainsi que des relations fournisseurs Ct USEI, cela conduit un regroupement du ple exploitation sur le site de Chalons en Champagne et du ple expertise Lille. Ct SNPI, un ple exploitation est cr pour dcharger l'quipe DTO des tches d'exploitation. Dbut 2004, la fusion des USEI et du SNPI pour crer la DOSI (Direction des Oprations du SI) permet de rapprocher les quipes sauvegardes et d'envisager une homognisation des pratiques, des processus d'exploitation ainsi que des infrastructures.
3.1.4.
L'architecture de sauvegarde
Architecture de sauvegarde en USEI : - Pour la majorit des serveurs : sauvegarde via rseau LAN Ethernet. Les flux sont achemins via un LAN (dimensionn 1 Gb/s) ddi la sauvegarde jusqu' un serveur de sauvegarde (catalogue TiNa) raccord en SCSI ou FC (Fiber Chanel) un robot de sauvegarde - Sauvegarde des donnes des filers (stockage sur le rseau IP) : sauvegarde via rseau SAN (Storage Area Network) Fiber Chanel. Les filers disposent d'interfaces FC permettant un raccordement de lecteurs de bandes via le SAN. Ces quipements 6/48
dialoguent avec le robot et le catalogue de sauvegarde via le protocole NDMP (Network Data Management Protocol)
Architecture de sauvegarde en UEI. En plus des architectures en place dans les USEI, les sites UEI comportent aussi des architectures spcifiques aux applications ayant de gros volumes de donnes sauvegarder : - Attachement de lecteurs ddis : certains serveurs ayant un volume de plus de 100 Go de donnes sauvegarder disposent d'un raccordement SCSI ou FC un lecteur de bandes situ dans un robot mutualis - Partage de lecteurs via SAN : une variante utilise le rseau de stockage SAN pour partager via les switchs FC un lecteur entre plusieurs serveurs.
7/48
3.2.
3.2.1.
Plusieurs facteurs sont l'origine de la dgradation de la qualit de service des sauvegardes : - les quipements de mise sur bande (principalement les DLT) sont en fin de vie et provoquent des erreurs d'criture ou des blocages mcaniques, leur rparation ou remplacement se faisant souvent par l'utilisation de pices d'occasion. - l'augmentation des volumes sauvegarder ainsi que la multiplication des serveurs rencontre les limites d'utilisation des rseaux IP, la congestion rseau provoquant l'allongement des sauvegardes, qui ne sont plus compatibles avec les fentres autorises, et une sous-alimentation des lecteurs de bandes qui sont soumis des cycles d'arrt-redmarrage intensifs causant leur usure prmature. La mise en uvre de tableaux de bord de suivi des SLA (Service Level Agreement) avec les MOA, incite cependant l'augmentation du niveau de qualit de service. En dehors du taux d'chec des sauvegardes en lui-mme qui doit tre amlior, l'augmentation des temps de sauvegarde impacte souvent d'autres traitements applicatifs qui ne peuvent tre lancs qu'en dehors des plages de sauvegarde, et aussi l'ouverture du service des applications transactionnelles.
8/48
Ainsi le respect des fentres de sauvegarde est un aspect important de la qualit de service, d'autant plus difficile tenir que les fentres de sauvegardes se rduisent avec l'internationalisation des services ou leur ouverture au grand public. Les solutions apportes ces contraintes de fentre de sauvegarde sont de plusieurs types : - la mise en uvre de moyens de sauvegarde ddis : on associe un lecteur de bandes une seule application afin de s'assurer que la ressource sera disponible au moment ou l'application voudra effectuer sa sauvegarde - la dsynchronisation des sauvegardes : on utilise les mcanismes de snapshot ou rplication internes au baies de stockage pour obtenir avec un temps d'arrt trs faible de l'application une copie des donnes que l'on peut sauvegarder avec peu de contraintes de temps. Ces solutions ont l'inconvnient du cot, qu'il soit port sur l'infrastructure de sauvegarde ou de stockage.
3.2.2.
Les applications les plus critiques, qui sont souvent consolides dans un nombre limit de serveurs sur un mme site doivent se protger de sinistres sur le site de production par la mise en uvre de PRA (Plan de Reprise d'Activit) sur un autre site dans un dlai plus ou moins long, et avec une fraicheur plus ou moins importante des donnes suivant le niveau de criticit. Le PRA comprend : - les procdures dcrivant la prise de dcision, les acteurs, les moyens utiliss et les modes opratoires techniques - la scurisation des donnes l'extrieur du site : via une rplication des donnes au niveau des architectures de stockage (mcanisme SRDF sur les baies EMC, SnapMirror sur les filers NetApp) pour les applications les plus critiques disposant du budget ncessaires, mais le plus souvent via une extraction des bandes de sauvegardes dans coffre anti-feu situ l'extrieur du site. - les serveurs de reprise sur un autre site, qu'ils soient dormants et prconfigurs pour cet usage, ou des serveurs utiliss en pr-production ou dveloppement - la planification rgulire de test des procdures de reprise Un grand nombre d'applications demandent la mise en uvre d'un PRA, ce qui conduit, compte-tenu des moyens limits dont elles disposent, l'externalisation massive des bandes de sauvegarde des sites de production. Malgr la mise en uvre d'automatismes d'externalisation des bandes, que ce soit sur le primtre USEI ou SNPI, l'externalisation des bandes reste un procd manuel qui pose un grand nombre de problmes logistiques : - bandes gares pendant le transfert - difficult pour garantir que l'ensemble des bandes sont extraites du site de production et mises en scurit dans le coffre - identification des bandes concernes par la restauration dans le coffre anti-feu - mouvement de bandes dans des conditions extrieures (variation de temprature, humidit) conduisant une dtrioration du support
9/48
3.2.3.
La loi Sarbanes-Oxley (SOX) relative la fiabilisation des comptes des entreprises cotes en bourse aux USA s'applique France Tlcom. Cette loi un impact sur le systme d'information, un certain nombre d'activits de contrle sur les processus de production des donnes financires via les applications du SI doivent tre mis en uvre. Ces contrles s'appliquent entre autres sur les applications de facturation et sur les applications comptables, ils visent les moyens mis en uvre pour fiabiliser l'intgrit et la disponibilit des donnes utiliss dans la construction des comptes de rsultats ou autres chiffres communiqus aux actionnaires. En plus des procdures d'exploitation des applications, de la scurit physique sur les sites informatiques ou de la scurit logique d'accs au rseau et serveurs, ces contrles concernent aussi la mise en uvre des procdures de PRA, l'externalisation des donnes et le suivi de la qualit de service des sauvegardes. La mise en uvre de ces activits de contrle SOX accentue le besoin d'amliorer la qualit de service des sauvegardes et systmatise le recours l'externalisation des donnes.
Dans le cadre du plan TOP de rduction des cots, un chantier ITN4 (Information Technology and Network) consiste a pour objectif la rduction du nombre de datacenter et leur consolidation en France et en Europe. Certains datacenters de France Tlcom et de ses filiales ont t ferms et les serveurs et application ont t dmnags dans les sites existants ou vers de nouveaux sites de plus grande capacit, principalement en Ile de France. C'est dans ce contexte que DOSI ouvre deux nouveau datacenters Aubervilliers et Paris Montsouris.
3.3.2.
Le programme INCA
La rnovation du SI de France Tlcom contribue la multiplication des serveurs dans les datacenters. L'urgence du besoin, la ncessit d'intgration des applications existantes ainsi que les cycles de dveloppements courts ne facilitent pas une consolidation applicative du SI qui est modifi par petites touches successives. De plus ce mouvement est amplifi par l'application des prconisations d'architecture Archimde (architecture 3 tiers demandant la mise en uvre de 3 couches de serveurs pour une mme application), ainsi que par l'offre de serveurs d'entre de gamme support les OS linux offrant une puissance et une fiabilit accrue. Cette situation conduit un faible taux d'utilisation des serveurs et une efficacit au m2 de datacenter rduite, avec son corollaire conomique. Le programme INCA a pour objectif de rpondre cette problmatique en proposant des solutions de consolidation des applications sur un mme socle technique. Les solutions proposes par INCA sont de plusieurs types. Concernant les serveurs :
10/48
utilisation de gros serveurs partionnables (SUN 25K, HP superdome) utilisation de lames (bladecenter IBM) ou pizza box et en dernier lieu l'utilisation de solutions de virtualisation (virtualisation AIX d'IBM, VMWARE d'EMC)
Concernant le stockage : - mise en uvre d'un rseau de stockage SAN (BROCADE) - consolidation du stockage SAN dans des baies de stockage (DMX d'EMC) - consolidation du stockage rseau (CIFS et NFS) dans des filers (NetApp) La sauvegarde suit le mme mouvement de consolidation des infrastructures, les silos STK mutualisent les lecteurs de bande raccords aux serveurs via un rseau de sauvegarde, tout comme un systme partionnable. Le projet de virtualisation des lecteurs de bandes dcoule lui aussi de ce mouvement, tout en traduisant une acclration puisque c'est sur le projet qu'est mis en pratique le plus tt le principe de virtualisation envisag par INCA pour les serveurs et le stockage.
3.4.
3.4.1.
La gense du projet
L'tude des solutions de virtualisation des lecteurs de bandes
Au dbut de l'anne 2003, une tude est lance dans le cadre du projet INCA pour apporter une solution de renouvellement de l'infrastructure de sauvegarde, qui est soumise la triple contrainte : - obsolescence des infrastructures : qualit de service dgrade et cot de maintenance lev - augmentation des besoins de sauvegarde : croissance des volumes et rduction des fentres de sauvegarde - htrognit du parc de serveurs sauvegarder Les solutions les solutions de partionnement robotique et de mutualisation des lecteurs de bande via le SAN et les logiciels de sauvegarde apportent une premire solution qui est exploite au SNPI, mais ces solutions restent cependant assez onreuses et difficiles exploiter. Comme dans le domaine du stockage sur disque, les diffrents constructeurs, mettent en avant les solutions de virtualisation des lecteurs et bandes de sauvegarde qui doivent offrir une solution souple et moindre coup. Depuis janvier 2004, l'quipe sauvegarde de la DOSI porte la responsabilit de la MOA des infrastructures de sauvegarde, dans ce cadre, en tant que responsable de l'volution des infrastructures de sauvegarde sur les datacenters du SNPI, je contribue fortement la rdaction du cahier des charges d'volution des infrastructures de sauvegarde en dfinissant : volumtries sauvegardes, topologie du parc existant, gains attendus et contraintes d'exploitation. L'tude est mene par la direction d'ingnierie du SNPI qui sera rattache lors de la fusion USEI / SNPI l'OCISI, et qui jouera le rle de MOE au cours du projet. Suite la rception du cahier des charges de la DOSI en avril 2004, la MOE lance un appel d'offre aux fournisseurs.
11/48
3.4.2.
Ci-dessous, un exemple de donnes de description du parc de sauvegarde que j'ai rassembl dans le cahier des charges mis par la DOSI.
Nombre de serveurs :
Site Nombre de domaines Netbackup Nombre de serveurs sauvegarde SAN Netbackup Nombre de catalogues TiNa Nombre de serveurs sauvegarde LAN Netbackup Nombre de serveurs TiNa Nombre de clients TiNa Nombre de serveurs Networker Nombre de clients Networker
Antony 12 86 0 185 0 0 0 0
Vlizy 5 40 7 114 7 29 0 0
Murat 5 40 2 100 2 x 0 0
Aubervilliers 0 0 0 0 0 0 ? 115
Site Nombre de librairies 9310 Nombre de librairies 9740 Nombre de librairies 9710 Nombre de lecteurs (principalement DLT)
Antony 2 7 8
Aubervilliers
49
40
12 9940B
52 9840A dont 24 9840A dont 36 9840A 7 lecteurs en 3 lecteurs en 1 9840B librairies 9710 librairies 9710 2 9940A 16 9940A 7 9840B dont 4 lecteurs en 1 9940B librairies 9710 14 9940A 4 9940B
Volumes sauvegards :
12/48
Volume hebdomadaire 28 To
Sauvpri4 (v3.2) Sauvpri2 (v3.2) Sauvpri6 (v3.2) BAC prod (dmbacdbs) (v3.4) IBU (dmibu) (v3.4) FCT (pnfctb01) (v3.4) QUATUOR (nbuquatm) (v3.4) FE (v3.4) SYMPHONIE (v3.4) Total Netbackup production
Un autre volet du cahier des charges liste les fonctionnalits attendues ainsi que les contraintes respecter. (Voir annexes)
3.4.3.
A la suite de l'tude et au cahier des charges de la DOSI, exploitant de rfrence du groupe, les constructeurs, parmi lesquels STK, EMC, Fujitsu-Siemens, ADIC, NetApp et Neartek sont mis en concurrence dans un appel d'offre dans le cadre du programme TOP sourcing du groupe France Tlcom. Classiquement, cet appel d'offre se droule en 3 phases : - rponse crite des fournisseurs un RFP (Resquest For Proposal) crit par la MOE OCISI. - oral de l'ensemble des fournisseurs dont certain sont retenus en short list - ngociations commerciales avec les fournisseurs de la short list Suite la rdaction du cahier des charges ou j'ai jou un rle de MOA, mon implication dans cette phase d'appel d'offre a t continue, en contribuant cette fois en tant qu'expert technique et reprsentant de l'exploitant, dont l'volution de l'activit quotidienne doit tre prise en compte : - j'ai ainsi particip la relecture du RFP - puis aux oraux des diffrents constructeurs pour valuer la viabilit technique des solutions - et enfin aux ngociations commerciales, en support aux responsables des achats afin d'valuer l'intrt du modle de facturation propos par les constructeurs par rapport l'volution envisage du besoin de sauvegarde
13/48
3.4.4.
En ralit, l'issue des oraux des fournisseurs, seul Fujitsu Siemens (FSC) avec sa solution CentricStor se dmarque nettement et engage des ngociations commerciales avec France Tlcom. Les autres fournisseurs sont disqualifis pour des raisons diffrentes : - StorageTek, dj implant chez France Tlcom avec une solution de virtualisation des lecteurs de bandes MVS, propose une nouvelle solution d'une conception innovante avec un tampon disque, cependant cette solution n'est pas encore prte, aucun client n'a mis en uvre cette solution. - EMC, unique fournisseur de baies de stockage de France Tlcom, propose une solution base sur son offre de stockage massif C700 (bas sur des disques de grande capacit donc peu performants). France Tlcom rejette cette solution de sauvegarde sur disques car elle demande un lourd investissement sans possibilit de rutiliser les robots et lecteurs existants, par ailleurs, la consommation en nergie est trs importante et des doutes existent quand la tenue en charge et au multiplexage de ce type de disques. - Neartek propose un systme de virtualisation bas sur des nuds Windows, le systme ne semble pas en mesure de supporter la capacit demande par France Tlcom - ADIC une solution Pathlight quivalente celles de STK et FSC, cependant, la solution tant rcente, ADIC impose l'utilisation exclusive des robots ADIC. Ce point oblige remplacer tout le parc de robots existants et aggrave le cot de la solution. Le CentricStor rpond en revanche aux critres suivants : - solution disk-to-disk-to-tape compatible avec les robots STK et ADIC du parc FT : permettant de limiter les investissements en rutilisant l'existant - une compatibilit avec les serveurs UNIX et Windows, mais aussi MVS - un parc client important et une exprience de plusieurs annes dans le domaine de virtualisation sur le domaine UNIX Au final, la solution retenue est le leader du march de la virtualisation des lecteurs de bandes : Fujitsu-Siemens CentricStor. La seule rserve apporte ce choix est la conception un peu ancienne du produit CentricStor, conception effectue l'origine pour le domaine mainframe. Des contraintes propres au contexte mainframe (taille des bandes virtuelles limite 2 Go) sont identifies et on envisage des effets de bord sur les logiciels de sauvegarde du monde UNIX, ainsi que des difficults faire voluer une solution qui possde un parc install important pour prendre en compte les besoins spcifiques de France Tlcom.
3.4.5.
Le schma ci-dessous prsente l architecture logique du CentricStor (les composants du CentricStor sont l intrieur de l ovale). La partie haute de ce schma correspond aux fonctions d mulation (gestion des quipements virtuels) et tournent dans des serveurs appels ICP (rectangles bleus) et VLP (rectangle crme). La partie basse de ce schma correspond la gestion du back-end et tournent dans des serveurs appels VLP et IDP (rectangles violets du bas).
14/48
BS2000
MAREN ROBAR -CL
MVS
RM: ROBAR-SV HACC
UNIX/NT/GCOS8/MVS
DAS-ACI ESCON / FC
UNIX/NT/BS2000/MVS
CSC
ESCON / FC
ICP :
EMTAPE 1
EMTAPE x
VTD 1
VTD y
DTVFS / TFS FC
CENTRICSTOR
VLP
VLS : VAMU VLM VLS : VDAS VLS : VACS
Virtuel Physique PLM PLS-1 DTVFS / TFS PDS 1 PDS i PDS j PDS m PLS-2
IDP :
L'ICP (Integrated Channel Processor) permet la connexion aux serveurs et le transfert des donnes vers le cache de disques RAID. L'ICP ralise la compression des donnes avant criture sur disque. Dans l ICP rsident les services suivants : - EMTAPE : lecteur virtuel mainframe ; - VTD (Virtual Tape Drive) : lecteur virtuel monde ouvert ; - DTVFS/TFS service dont la fonction est la gestion du flux de donnes du canal vers le segment disque correspondant un volume logique. L'IDP (Integrated Device Processor) est charg du transfert des donnes vers les lecteurs physiques. Dans l IDP rsident les services suivants : - PDS (Physical Device Server) : Pilote des lecteurs physiques ; - DTVFS/TFS service dont la fonction est la gestion du flux de donnes du segment disque vers le volume physique. Le VLP (Virtual Library Processor) est le cur du CentricStor, il sert la fois de console d'administration de la solution, d'mulateur de librairie virtuelle (vis--vis des hosts) et de pilote des librairies physiques. Pour des besoins de redondance, un SVLP (Stand-by VLP) est activ automatiquement en cas de dfaillance du VLP primaire. Dans le VLP rsident les services suivants : - VLM (Virtual Library Manager) Ce service permet l administration des volumes logiques, des lecteurs virtuels et des diffrents VLS via le LAN interne.
15/48
VLS (Virtual Library Service) Ce sous-service, du service VLM, excute les commandes des logiciels clients des systmes htes. Il y a un VLS spcifique par type de librairies mules. PLM (Physical Library Manager) Ce service excute les commandes de mount/dismount de volumes physiques sur les lecteurs physiques. Il permet d obtenir des informations sur les volumes logiques et physiques. PLS (Physical Library Service) : Ce service reoit les requtes de montage et dmontage de bandes provenant du PLM et les envoie la librairie ou son gestionnaire.
D'un point de vue matriel, l'ensemble des composants du CentricStor sont standard. Les serveurs sont de type primergy (Fujitsu-Siemens) bi-processeur, ils supportent l'OS SINIX propritaire Fujitsu-Siemens. Une version ultrieure de CentricStor porte sur linux est annonce. Les baies de stockage sont des baies EMC Clarion C500 et les switchs du constructeur BROCADE.
3.4.6.
Le lancement du projet
Suite l'arrive de Bob Evans au poste de directeur de la DOSI, au second semestre 2004, le projet est acclr, le contrat est sign avec Fujitsu-Siemens et le projet de dploiement de CentricStor est prvu au budget 2005. Dans c'est dans ce contexte que je suis nomm global project leader du projet virtualisation des lecteurs de bandes CentricStor, ce qui conforte ma position de MOA, le rle de MOE tant confi l'OCISI (devenu entre temps DPS : Direction des Plateformes de Services), dj leader sur la phase de mrissement. Le primtre de dploiement comprend : - les 6 datacenter d'Ile de France (Antony, Vlizy, Paris Murat, Aubervilliers, Paris Montsouris et Nanterre, ex-USEI) ou se concentre l'hbergement de la majeure partie des nouvelles applications. Parmi ces sites, Aubervilliers et Montsouris sont de nouveaux datacenters de DOSI et doivent ne possdent par consquent aucune infrastructure de sauvegarde - les OS UNIX (Solaris, HP-UX, AIX), linux et Windows, une qualification et un support spcifique de Fujitsu-Siemens tant possible pour tendre ultrieurement ce primtre aux systmes Open VMS Lors de la runion de kick-off du projet, Bob Evans prcise que l'architecture cible doit tirer le meilleur parti de la souplesse de CentricStor pour proposer une sauvegarde automatique sur site distant via les liaisons fibre optique DWDM (Dense Wawelength Division Multiplexing) disponibles entre les 6 datacenter de la rgion parisienne. Cette architecture permet d'automatiser la mise disposition des sauvegardes pour le PRA, qui fait partie du primtre des activits de contrle SOX, ce qui permet d'conomiser des ressources logistiques dans la manipulation des bandes ainsi que de simplifier les actions de contrle SOX. Pour cette raison, le projet CentricStor va bnficier la fois de la pression importante lie la tenue des objectifs SOX et du sponsoring important de la part du directeur de la DOSI qui est directement impliqu dans la russite des objectifs SOX.
16/48
4.
En plus de ses propres ressources humaines, le budget gr par la DOSI concerne : - les investissements matriels (DOSI est propritaire des infrastructures et serveurs) - les prestations de professional services des fournisseurs pour la mise en service des quipements Une de mes activits est de raliser le suivi et les prvisions de budget consomm dans les diffrentes directions de DOSI aux postes suivants : - quipements CentricStor - autres quipements matriels (rseau SAN, robots et lecteurs de bandes) - prestations d'installation de FSC - ressources humaines ddies au projet - ressources humaines mobilises dans d'autres directions d'exploitation ou dans la direction technique (experts techniques) - formations des exploitants
4.1.2.
Reporting
La mise en uvre de la virtualisation des lecteurs de bandes est un des 12 projets prioritaires de la DOSI lancs en 2005, ce titre, un reporting direct bihebdomadaire est effectu auprs du directeur de DOSI. Ce reporting indique l'tat d'avancement par rapport au planning prvisionnel, ainsi que les alertes, points de blocage et besoins d'interventions auprs du comit de direction.
4.2.
4.2.1.
Les infrastructures et le service de sauvegarde sont mutualiss l'chelle du datacenter, par consquent, les volutions concernent un grand nombre d'applications et d'utilisateurs clients. Les utilisateurs et clients de l'infrastructure de sauvegarde sont : - les matrises d'ouvrage applicatives contractualisent un service d'exploitation et en particulier de sauvegarde par le biais d'un SLA - les matrises d'uvres applicatives dclinent ce SLA en cahier des charges de sauvegarde et parfois ralisent l'intgration technique des outils de sauvegarde (script de pr et post sauvegarde) - les intgrateurs techniques (exploitant ou autre intgrateur) travaillant la mise en production construisent le plan de sauvegarde dtaill et ralisent la recette des sauvegardes et restaurations. - les exploitants applicatifs s'assurent au quotidien du bon fonctionnement de l'applicatif et contrlent le droulement des tches rcurrentes d'exploitation comme les sauvegardes, ils mettent des signalisations en cas d'erreurs de sauvegarde. En
17/48
cas de besoin : opration programme ou rsolution d'incident, ils lancent des sauvegardes et des restaurations de donnes. les exploitants de l'infrastructure de sauvegarde contrlent la QS des sauvegardes, traitent les signalisations d'incidents, interviennent sur le matriel ou le logiciel de sauvegarde et mettent en uvre les plans de sauvegarde.
4.2.2.
Dans le cas des projets existants, l'volution des moyens de sauvegarde doit se faire dans le respect du SLA qui dfinit les exigences de sauvegarde (frquence, rtention des donnes), ou, dans le cas ou un tel document n'existe pas, la stratgie de sauvegarde en place doit tre reconduite. La mise en uvre de la virtualisation impose de normaliser les plans de sauvegarde, notamment entre TiNa et Netbackup. La principale contrainte se situe au niveau de la rtention des donnes, pour laquelle CentricStor impose un nombre limit de choix, afin de faciliter l'exploitation courante et de ne pas mlanger sur un mme pool de bandes des donnes expirant des dates diffrentes. Lors du passage sur CentricStor, certaines stratgies de sauvegarde doivent tre modifies, ce qui peut avoir un impact sur l'ordonnancement de la production. C'est notamment le cas pour les sauvegardes destines tre externalises dans un coffre anti-feu qui doivent tre supprimes, car toutes les donnes sauvegardes sont crites sur un site distant au niveau du CentricStor. La migration vers CentricStor se fait dans le respect du SLA en vigueur, la MOA applicative n'est pas sollicite dans la mise en uvre des sauvegardes virtualises. En revanche, les autres acteurs, la MOE, suivant son degr d'implication dans l'intgration technique, les exploitants et intgrateurs applicatifs sont concerns et doivent mettre jour le paramtrage de leur ordonnanceur et leur dossier d'exploitation. Les exploitants des logiciels de sauvegarde doivent mettre en uvre un nouveau paramtrage sur les serveurs de sauvegarde.
4.2.3.
Tous les nouveaux projets : nouvelles applications ou refonte d'architecture technique d'applications existantes, sont clients du CentricStor si le site d'implantation est quip. Pour accompagner la mise en uvre de CentricStor sur ces applications, le processus de mise en production doit tre mis jour pour prendre en compte les spcificits de cette nouvelle infrastructure qui porte sur deux points : - l'adhrence entre la topologie de l'infrastructure CentricStor et la rpartition gographique des moyens de production et de secours des applications (voir chapitres suivants) - la gestion prvisionnelle de capacit CentricStor Afin d'accompagner ces nouveaux projets, je ralise des prsentations destination intgrateurs et experts techniques de MEP. Je participe aussi aux chantiers de mise jour du processus de MEP dans le systme qualit et j'initie un nouveau modle de facturation pour prendre en compte les spcificits de l'infrastructure mutualise CentricStor.
18/48
4.3.
4.3.1.
La qualification du bon fonctionnement de CentricStor dans le contexte cible de production est confi la MOE DPS. Je participe la dfinition d'un cahier des charges de qualification comprenant les items suivants : - interfonctionnement avec TiNa / Netbackup - tenue en charge (atteinte des performances annonces par le constructeur) - robustesse (comportement lors de l'interruption de l'alimentation ou du rseau) Lors de la phase de qualification, je participe des runions de suivi des anomalies de qualification avec la MOE et le fournisseur. Afin de raliser la qualification, DPS dispose d'une maquette, mise en uvre pendant la phase de murissement, qui est upgrade pour prendre en compte l'architecture rpartie de production. Ds le dmarrage du projet, on sait cependant que cette phase de qualification ne permet pas elle seule de dceler toutes les anomalies et de gnraliser l'utilisation de CentricStor car il est trs difficile de reproduire en qualification : - l'htrognit des plateformes - les volumes de donnes en production - le comportement des exploitants La mise en place d'un pilote en production est donc une tape plus importante pour valider le fonctionnement du CentricStor en production.
4.3.2.
La MOE DPS a aussi pour rle l'architecture et l'industrialisation de la solution pour l'adapter l'environnement de production de la DOSI. L'architecture cible doit tre dfinie et toutes les contraintes techniques leves avant de commander le premier quipement de production Les livrables d'exploitabilit et d'ingnierie attendus sont ncessaires pour dclarer la gnralisation et doivent tre valids pendant la phase pilote. Je dfini dans le livrable cahier des charges d'intgration la liste des livrables d'industrialisation attendus comprenant notamment : - Fiches d'exploitation CentricStor (plus de 130 fiches seront produites) - Supervision - Scripts d'exploitation - Paramtrage type du CentricStor - Rgles de nommage - Impact sur les rgles d'ingnierie TiNa et Netbackup Je contribue aussi la dfinition de certaines de ces rgles d'ingnierie en tant qu'expert technique.
19/48
4.4.
Les nouveaux quipements CentricStor demandent une surveillance, des tches d'exploitation ainsi que le traitement quotidien des incidents, mon rle est d'identifier les ressources humaines ncessaires pour le fonctionnement rcurrent ainsi que les comptences dvelopper, avant d'identifier et d'accompagner la monte en comptence de l'quipe. Par ailleurs, la mise en uvre de CentricStor impacte les quipes d'exploitation des logiciels de sauvegarde en place, mon rle est ici d'accompagner le changement en recueillant les nouveaux besoins : documents, rgles d'ingnierie produire. J'ai aussi du accomplir avec les exploitants le chantier de supervision et la modification de la chaine de soutien des sauvegardes.
4.5.
Au cours de ce projet, j'ai pu constater l'importance de respecter la rpartition des rles entre les diffrentes parties prenantes (MOA / MOE / Exploitant). Cependant portant moi-mme les deux rles de MOA et d'exploitant et endossant par moments celui d'expert technique en support la MOE, je me suis attach organiser mes interventions dans le projet en jouant un rle la fois, exprience difficile, autant pour moi que pour mes interlocuteurs ! Ce projet, transverse par rapport l'ensemble des applications exploites par DOSI, a aussi rvl des difficults obtenir et formaliser des contributions pour rpondre besoins d'volution des infrastructures internes DOSI, l ou le systme qualit est totalement orient vers et pilot par les besoins clients. Au final, la russite de ce projet est fortement lie au sponsoring effectu au niveau de la direction de DOSI.
20/48
5.
Droulement du projet
5.1.
5.1.1.
Architecture technique
Rutilisation des robots existants
Afin de tirer le meilleur parti des avantages de la virtualisation, et d'obtenir le meilleur ROI, le projet doit s'organiser pour rutiliser les quipements robotiques existants sur les datacenters (robots de consolidation et lecteurs de bandes de nouvelle gnration). Comme indiqu ci-dessus, les sites d'Antony, Vlizy et Murat disposent de silos STK (6000 slots pour les bandes et jusqu' 60 lecteurs). Par ailleurs, grce un autre projet de consolidation des datacenter d'Orange, DOSI ajoute son parc deux librairies de consolidation STK de nouvelle gnration : SL8500 sur les sites d'Aubervilliers et Montsouris. C'est ces robots qui sont choisis pour hberger l'ensemble des lecteurs de bandes raccords CentricStor. Ct lecteurs de bandes, une technologie de lecteurs rapides et de grande capacit est vise, CentricStor supporte les 2 formats concurrents LTO2 et STK 9940B qui offrent des performances semblables : 30 Mo/s et 500 Go/bande hors compression. Si les robots de nouvelle gnration SL8500 supportent les deux technologies, les silos STK prsents sur trois des sites ne sont pas compatibles, par ailleurs, DOSI a commenc (pour cette mme raison) investir massivement dans l'achat de lecteurs 9940B. Afin de maintenir un parc homogne de lecteurs et de bandes et afin de rutiliser au mieux les investissements prcdents, les lecteurs choisis sont de type 9940B. Le projet demande toutefois l'achat initial de certain nombre de lecteurs afin de constituer un fond de roulement, les lecteurs existants sur le parc seront ensuite librs progressivement au cours de la migration et raffects au back-end de CentricStor.
5.1.2.
Lors de la phase d'architecture, diffrentes options sont tudies pour rpondre au besoin d'externaliser automatiquement les donnes sur un site de secours en profitant de la souplesse et de la modularit du CentricStor. Tout d'abord, la solution la plus simple consistant dfinir un centre de secours unique (Paris Murat) ou seraient centralises toutes les sauvegardes et tous les moyens de reprise est cart. On constate en effet que beaucoup d'un bon nombre de PRA existant utilisent d'autres sites pour la reprise d'activit. Mettre disposition les donnes et les moyens de restauration sur un site diffrent de celui ou se trouvent les serveurs destins la reprise du service de l'application n'a en effet pas d'intrt, la connectivit rseau existante empchant le rapatriement des donnes. Pour rpondre cette contrainte, la solution consiste faire coller la topologie de l'infrastructure CentricStor celle des PRA recenss. Les options tudies sont les suivantes : - Positionner l'quipement CentricStor sur le site de production et les robots de sauvegarde sur le site distant
21/48
Avantages : Les flux sur le rseau intersites sont compresss et lisss tout au long de la journe, permettant une utilisation optimale de la bande passante intersites Les liens intersites peuvent tre fdrs au sein d'un rseau SAN, permettant une optimisation du nombre de liaisons point point Inconvnients : Les donnes rsident pendant un certain temps sur le cache local du site avant d'tre rpliques sur site distant. Il est difficile de prvoir quelles donnes seront effectivement rpliques dans le cas d'un sinistre site et de la mise en uvre d'un PRA Le catalogue du CentricStor hberg par son contrleur un prsent sur un seul site, il n'existe aucune procdure d'export et d'import de ce catalogue vers un nouvel quipement en cas de sinistre site. La seule solution est la relecture de l'ensemble des bandes pour reconstruire les donnes du catalogue. Aucun moyen immdiat pour restaurer les bandes sur le site de secours, sauf mettre en place des quipements dormants (les bandes crites par CentricStor ne peuvent tre lues que par CentricStor)
Murat Vlizy
Host
Back-up
ICP
Normal Restore
VLP
Catalogue
DR Restore
Optional
Internal Storage
IDP
9940B 9940B
Positionner l'quipement CentricStor et les robots de sauvegarde sur le site de secours 22/48
Avantages : Les donnes se trouvent externalises sur site distant ds la fin de la sauvegarde. Le catalogue CentricStor ne se trouve pas sur le site production, il n'est pas impact en cas de sinistre sur le site de production Inconvnients : Les flux sur le rseau intersites sont non compresss et prsentent des dbits importants en crte Demande la mise en uvre d'une technologie de routage inter-fabric SAN (entre une fabric locale et un backbone intersites fdrant les liaisons DWDM) non mature et non valide au sein de FT
Rpartir l'quipement CentricStor entre le site de production et le site de secours o Avantages : Le catalogue CentricStor est scuris par la rplication des donnes en temps rel sur le site secours On dispose de moyens de restauration sur le site de secours immdiatement disponibles Les flux sur le rseau intersites sont compresss et lisss tout au long de la journe, permettant une utilisation optimale de la bande passante intersites. o Inconvnients : 23/48
Contrairement aux architectures prcdentes, les liens permettant le transfert de donnes intersites se trouvent l'intrieur du rseau CentricStor, ils ne peuvent pas bnficier de l'agrgation au sein d'un rseau SAN et doivent tre ddis un quipement. Le dialogue entre les composants d'un CentricStor demande une interconnexion rseau de niveau 2 entre les sites, ce qui est contraire aux normes en vigueur
24/48
5.1.3.
Interconnexion rseau IP
Le point dur de l'architecture choisie concerne le besoin d'interconnexion des sites en niveau 2. Ce besoin a deux origines distinctes : - Rseau externe : le contrleur principal (VLP) et le contrleur de secours (SVLP) disposent d'un mcanisme de bascule automatique avec reprise d'adresse (cette adresse est publique, utilise par les serveurs clients) - Rseau interne : les composants s'changent des messages en broadcast La solution mise en uvre comporte 2 VLAN (Virtual LAN) spcifiques : - un VLAN hbergeant les adresses externes du VLP et du SVLP. Du point de vue routage de ces adresses sont cependant affectes un seul site. - un VLAN permettant le raccordement des switchs internes au CentricStor sans allocation d'adresses. Dans une volution ultrieure de l'architecture, ces VLAN sont remplacs par deux switchs ddis et une connexion LAN intersites ddie.
5.1.4.
Interconnexion DWDM
Le transfert de donnes intersites s'effectue via des liaisons fibre optique DWDM sur laquelle sont raccords des switchs Fiber Chanel. Ce type de liaison, permettant de multiplexer un grand nombre de longueurs d'onde assez rapproches sur la mme fibre est dj utilise pour construire le backbone de la fabrique SAN intersites. Chaque longueur d'onde offre un dbit de 1 Gb/s sur plusieurs dizaines de kilomtres. La plus part des sites parisiens sont dj quips de raccordement d'quipements DWDM, seul le site de Nanterre demande la construction de nouveaux accs. Le constructeur de CentricStor n'autorise pas l'utilisation d'un rseau SAN existant pour interconnecter les 2 moitis de l'quipement (pour des raisons de support et de garantie de qualit de service), ce qui permettrait pourtant de mutualiser les liens DWDM existants. Une paire de liens DWM ddie chaque CentricStor est commande l'entit charge de la construction du backbone de FT, quand cela est possible, ces liens sont rpartis sur des chemins physiques et des points d'accs au datacenter spars, afin d'viter un SPOF (Single Point Of Failure) sur le trajet de la fibre. Ces liens sont raccords chaque extrmit sur le switch interne de l'armoire CentricStor. Dans une version ultrieure de l'architecture CentricStor, qui concernera le dernier quipement install, celui de Nanterre, les switchs interne de CentricStor sont doubls, formant 2 rseaux distincts (appels fabric en jargon FC) et redondants. Dans cette architecture, un lien DWDM est affect chaque fabric.
5.1.5.
Topologie
La couverture des scenarii de PRA existants conduit un besoin de 6 couples CentricStor rpartis suivant la topologie suivante :
25/48
Aubervilliers Nanterre
Murat Montsouris
Vlizy Antony
5.2.
5.2.1.
La mise en uvre de CentricStor est une premire en France, par ailleurs, le contexte de France Tlcom prsente des spcificits par rapport aux autres clients : - grand nombre de serveurs connecter par quipement, quasi-exclusivement UNIX (alors que les autres clients possdent un parc majoritairement mainframe avec quelques pri-applications UNIX) - architecture rpartie avec interconnexion interne (rseau et SAN), sous responsabilit de France Tlcom Une structure de suivi est mise en uvre avec le fournisseur pendant les phases de qualification (sous pilotage MOE DPS), pilote et dbut de gnralisation (pendant ces phases, j'effectue ce pilotage pour le compte de DOSI).
26/48
Ce suivi s'effectue lors de runions hebdomadaires avec les interlocuteurs techniques et de comits de pilotages mensuels. Lors de ces points sont voqus et qualifis les anomalies de qualification, de production ainsi que les demandes d'volution. Les difficults principales sont rencontres lors des phases pilote et dbut de gnralisation, le contexte particulier d'utilisation chez France Tlcom a mis au jour une instabilit de certains processus du CentricStor (particulirement ceux mulant les librairies virtuelles) lors de la monte en charge. La rsolution de ces incidents a demand une escalade auprs du fournisseur par la hirarchie de DOSI, la mise en uvre d'un suivi plus rapproch des quipements et du contexte d'exploitation FT par le fournisseur (experts techniques sur site en relation directe avec l'quipe de dveloppement en Allemagne). La livraison d'un certain nombre de patchs a pu permettre le retour une situation nominale. Par ailleurs, les retours de experts techniques et des exploitants, ont permis de remonter et de prioriser des demandes d'volutions au fournisseur pour prise en compte dans des versions ultrieures, mieux adaptes un contexte tel que celui de France Tlcom.
5.2.2.
Bien qu'en thorie transparent pour les logiciels de sauvegarde, car mulant un grand nombre de librairies et lecteurs par ailleurs supports par ces derniers, le CentricStor n'est en ralit pas sans impact sur les logiciels de sauvegarde en place. Tout d'abord la taille des bandes virtuelles, 2 Go dans la premire version (hritage du mainframe), implique que le nombre de bandes vu du logiciel est multipli par un facteur de 10 100. Les effets de bord constats sont un temps d'inventaire du robot trop important, provoquant par ailleurs une indisponibilit temporaire du CentricStor, ainsi que des temps de sauvegarde allongs par des montage/dmontage plus frquents (temps d'attente prvus dans les logiciels de sauvegarde pour des supports mcaniques). Une version ultrieure de CentricStor permet une taille plus leve des bandes, limitant ces effets. Ensuite, l'expiration des donnes sauvegardes, et ainsi le statut de disponibilit des bandes pour de nouvelles sauvegardes, se fait nativement uniquement au niveau du catalogue du logiciel de sauvegarde (aussi bien TiNa que Netbackup), sans action de lecture / criture sur les bandes. Dans ce contexte, CentricStor ne peut tre inform que les donnes stockes sur bandes sont primes, ce qui conduit une surconsommation de bandes physiques, contraire l'objectif attendu. Pour rpondre ces problmes, des volutions ont t demandes aux diteurs de sauvegarde, Atempo et Veritas. Des scripts d'exploitation complmentaires ont aussi t mis en uvre pour traiter le recyclage des bandes supprimes.
5.3.
5.3.1.
Afin d'assurer la contribution DOSI sur le projet, je constitue une quipe projet en recrutant sur appel d'offres deux prestataires de service. Cette quipe intervient d'abord sur les phases de qualification, architecture et pilote en production. 27/48
Cette quipe (DT/SSA dans le diagramme ci-dessous) va ensuite prendre en charge le dploiement de l'infrastructure et le support niveau 3 de l'infrastructure et des clients migrs.
5.3.2.
Autres contributeurs
Le pilotage du chantier de migration est dlgu l'quipe DPSE/PEX3, par ailleurs exploitants des logiciels de sauvegarde. Cette quipe sera aussi l'quipe cible pour l'exploitation CentricStor. D'autres contributeurs exploitants ou intgrateurs applicatifs ainsi que des experts techniques de la direction technique sont identifis. Ci-dessous une reprsentation schmatique de l'organisation projet que j'ai propose et mis en uvre.
Organisation projet
N o u v e a u x P r o j e t s
DT/SSA
DT/SSA
5.4.
Installation de l'infrastructure
L'installation de l'infrastructure comprend plusieurs phases : - dimensionnement des quipements CentricStor - processus d'investissement et commande - prparation du site d'accueil et pilotage de l'installation - recette de l'quipement
28/48
Cette phase du projet est ralise entirement par DOSI, avec une grosse contribution de l'quipe projet sous ma responsabilit.
5.4.1.
Dimensionnement de l'infrastructure
Afin d'optimiser les investissements dans le temps et de prendre en compte la fluctuation des besoins des projets d'un site l'autre et au cours du temps, je propose de mettre en uvre une infrastructure minimale sur chacun des sites. La capacit de ces quipements pourra tre augmente par ajout de composants au cours de la monte en charge. Afin de permettre cette monte en charge progressive, les configurations des armoires sont tudies ds le dpart dans leur configuration cible, ce qui permet de rserver sur les sites les m2, nergie et raccordement rseau ncessaires. Un quipement CentricStor dans sa capacit maximale permet de sauvegarder entre 20 et 30 To de donnes par jour et par site. Un tel quipement occupe 3 armoires de rackage 36U par site et environ 15 KW d'nergie lectrique. Le volume et les dbits sont exprims en capacit brute (vu de l'extrieur) et compress (vu des disques et des bandes). La capacit du disque est dimensionne 2 fois le flux quotidien pour faire face une panne des robots et lecteurs durant un weekend sans impact client. Ci-dessous des exemples de configuration de l'quipement CentricStor AubervilliersMontsouris : la version installe initialement et les prvisions d'extensions.
29/48
Montsouris
Compress Dbit Volume
220 Mo/s 220 Mo/s 440 Mo/s 5,1 To 5,1 To 5,1 To 15,3 To 360 Mo/s 240 Mo/s 75 Mo/s 675 Mo/s
ICP ICP
220 Mo/s 220 Mo/s 440 Mo/s 1,7 To 1,7 To 1,7 To 5,1 To 5,1 To 5,1 To 5,1 To 15,3 To 360 Mo/s 240 Mo/s 75 Mo/s 675 Mo/s
ICP ICP
IDP
220 Mo/s 220 Mo/s Nombre de liens Dbit Nombre de liens Dbit 1 200 Mo/s 1 200 Mo/s
IDP
Dbit pointe entre Volume cache Nombre de lecteurs Temps de vidage total Temps de vidage 1 jour Marge dbit cache Ratio dbitsur8H/cache
Dbit pointe entre Volume cache Nombre de lecteurs Temps de vidage total Temps de vidage 1 jour Marge dbit cache Ratio dbitsur8H/cache
30/48
Montsouris
Compress Dbit Volume
220 Mo/s 220 Mo/s 220 Mo/s 220 Mo/s 880 Mo/s 5,1 To 5,1 To 5,1 To 5,1 To 5,1 To 8,7 To 8,7 To 5,1 To 5,1 To 5,1 To 5,1 To 360 Mo/s 240 Mo/s 75 Mo/s 0 Mo/s 360 Mo/s -180 Mo/s 90 Mo/s 360 Mo/s 240 Mo/s 75 Mo/s 0 Mo/s
220 Mo/s 220 Mo/s 220 Mo/s 220 Mo/s 880 Mo/s 1,7 To 1,7 To 1,7 To 1,7 To 1,7 To 2,9 To 2,9 To 1,7 To 1,7 To 1,7 To 1,7 To 5,1 To 5,1 To 5,1 To 5,1 To 5,1 To 8,7 To 8,7 To 5,1 To 5,1 To 5,1 To 5,1 To 360 Mo/s 240 Mo/s 75 Mo/s 0 Mo/s 360 Mo/s -180 Mo/s 90 Mo/s 360 Mo/s 240 Mo/s 75 Mo/s 0 Mo/s
TVC TVCE FC TVCE FC TVCE FC TVC TVCE ATA TVCE ATA TVC TVCE FC TVCE FC TVCE FC
120 Mo/s 80 Mo/s 25 Mo/s 0 Mo/s 120 Mo/s -60 Mo/s 30 Mo/s 120 Mo/s 80 Mo/s 25 Mo/s 0 Mo/s
TVC TVCE FC TVCE FC TVCE FC TVC TVCE ATA TVCE ATA TVC TVCE FC TVCE FC TVCE FC
120 Mo/s 80 Mo/s 25 Mo/s 0 Mo/s 120 Mo/s -60 Mo/s 30 Mo/s 120 Mo/s 80 Mo/s 25 Mo/s 0 Mo/s
1,7 To 1,7 To 1,7 To 1,7 To 1,7 To 2,9 To 2,9 To 1,7 To 1,7 To 1,7 To 1,7 To
63,3 To
1 620 Mo/s
540 Mo/s
21,1 To
540 Mo/s
21,1 To
IDP IDP
220 Mo/s 220 Mo/s 440 Mo/s Nombre de liens Dbit Nombre de liens Dbit 2 400 Mo/s 2 400 Mo/s
IDP IDP
30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 240 Mo/s
30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 30 Mo/s 240 Mo/s
Dbit pointe entre Volume cache Nombre de lecteurs Temps de vidage total Temps de vidage 1 jour Marge dbit cache Ratio dbitsur8H/cache
Dbit pointe entre Volume cache Nombre de lecteurs Temps de vidage total Temps de vidage 1 jour Marge dbit cache Ratio dbitsur8H/cache
5.4.2.
Commande du matriel
Une fois le dimensionnement de l'quipement effectu, je le soumets au fournisseur pour qu'il en valide son tour la cohrence et qu'il me fournisse un devis. Un passage en comit d'investissement DOSI permet d'autoriser le passage d'une commande dans l'outil du groupe.
31/48
5.4.3.
La prparation du site d'accueil doit se faire longtemps l'avance, ainsi la commande des liaisons DWDM demande 4 mois de dlais. D'autre part, certains datacenter atteignent leurs limites en disponibilit d'espace au sol ou d'nergie lectrique, la rservation de ces ressources doit se faire au plus tt. Ces tches pralables tant effectues, je dois faire valider l'implantation des quipements sur les datacenter en comit d'implantation des infrastructures et des applications (CI2A). Ensuite, les ordres de travaux sont lancs pour prparer les raccordements (cble rseau IP, cblage nergie, cblage optique pour le SAN et le DWDM, cblage tlphonique pour les modems de tlmaintenance). Je dois aussi valider avec le fournisseur l'implantation des quipements : organisation de visites de site pour visualiser l'espace rserv au sol ainsi que les dgagements, vrifier les obstacles sur le parcours de la livraison, le type de raccordements lectriques prvus. Tous les pr-requis sur le site d'installation doivent tre vrifis avant de planifier la livraison, car le fournisseur mobilise plusieurs personnes pour raliser l'installation, la configuration et FT dispose de 20 jours ouvrs pour raliser la recette.
5.5.
Phase pilote
A l'origine du projet, le site Paris Murat est identifi pour accueillir le pilote de CentricStor, ce site accueille en effet majoritairement des serveurs de dveloppement ou de backup, des quipements moins sensibles que des serveurs en production. Cependant, au moment de la livraison des quipements sur le site de Murat, un problme de disponibilit d'nergie sur le site (dcouvert tardivement, malgr les rservations effectues l'avance par le projet) nous empche de raliser la mise en service de l'quipement. Le plan d'action permettant de rsoudre le problme s'tend sur plusieurs mois, je propose que le pilote soit ralis sur l'infrastructure couvrant les sites d'Aubervilliers et Montsouris, dont la livraison est proche. Ces sites, nouveaux datacenters DOSI comportent peu d'applications existantes migrer. Les applications clientes choisies pour le pilotes sont de nouvelles applications s'implantant sur le site, l'avantage tant que durant la phase de MEP, les quipements sont disposition pour raliser des tests de sauvegarde / restauration sans risque pour la production. Cette phase pilote permet de constituer un chantillon reprsentatif des OS (AIX, Solaris, AIX, HP-UX, linux, Windows) et des logiciels de sauvegarde (TiNa, Netbackup) du parc de DOSI. Par ailleurs, un client pilote disposant d'une base de 2 To de donnes sauvegarder permet de valider la tenue en charge de l'quipement et l'atteinte des dbits annoncs. Tout au long de cette phase, les actions suivantes sont menes en parallle : tuning de toute la chaine de sauvegarde (OS, carte FC, logiciels, CentricStor) mise jour des docs d'exploitation et rgles d'ingnierie en relation avec l'exploitant remonte et traitement des anomalies avec le fournisseur
32/48
5.6.
5.6.1.
L'exploitation de l'quipement CentricStor est confie l'quipe exploitant les logiciels de sauvegarde DPSE/PEX3, et plus particulirement l'quipe de Chalons en Champagne, exploitant TiNa (cf ci-dessus). La monte en comptence de l'quipe demande la mise en uvre avec le fournisseur de sessions de formation sur mesure. Par ailleurs, je ralise plusieurs sessions de sensibilisation aux impacts du CentricStor sur les logiciels de sauvegarde ainsi qu'aux problmatiques de gestion de capacit.
5.6.2.
CentricStor doit amliorer la qualit de service, pour atteindre cet objectif, les indisponibilits ou les pannes doivent tre anticipes autant que possible, dtectes au plus vite et diagnostiques et rpares toutes heures du jour et de la nuit (les sauvegardes ayant majoritairement lieu la nuit). Pour rpondre l'objectif de dtection des pannes, CentricStor met des traps SNMP (Simple Network Management Protocol) pour la totalit des alertes. Ces vnements sont ensuite collects l'infrastructure de supervision DOSI, patrol PEM de BMC. Pour rpondre l'objectif d'anticipation, la MOE et le fournisseur dveloppent la demande de DOSI des traps SNMP complmentaires permettant de superviser la disponibilit de l'espace disque ou bandes (alerte au-del de 70 % d'occupation). Enfin pour rpondre au besoin de diagnostic et rparation, CentricStor dispose d'un accs modem qui permet aux quipes support fournisseur de se connecter. Pour des raisons de scurit, l'exploitant doit ouvrir et fermer ces accs chaque intervention. L'ensemble de ces mcanismes sont articuls dans une description de la chaine de soutien.
5.7.
Dcision de gnralisation
La Dcision de gnraliser le dploiement (Jalon J2 du projet) de CentricStor toutes les nouvelles applications et de migrer les applications existantes est prise le 21 novembre 2006, au vu d'un statut satisfaisant sur les critres : tests techniques exploitabilit, supervision et chaine de soutien formation organisation de l'exploitation rcurrente organisation du chantier de migration
Par ailleurs, ce stade du projet, 5 quipements sur les 6 prvus sont dj prts accueillir les dploiements.
33/48
Oc tob er ,
t 5h
DWDM link available DWDM link not usedby the project LAN interconnection not available(2006)
02/10/2007
Antony
Se pt em be ,r
6 00 y2 ar u an J Murat
? Dec , 20th r embe ?
Montsouris
12
34/48
Jully, 1t h 2
t 21h
6.
Bilan du projet
6.1. Dploiement de l'infrastructure
Au mois de Mars 2006, l'ensemble des 6 quipements CentricStor prvus au dmarrage projet sont installs sur les datacenter d'Ile de France. Fin 2005 et tout au long de l'anne 2006, des upgrades matriels ont lieu sur les quipements installs initialement afin de prendre en compte la monte en charge. Au cours de l'anne 2006, de nouveaux projets d'installation de CentricStor voient le jour pour rpondre de nouveaux besoins, un septime quipement entre les datacenter de Paris Montsouris et Paris Murat voit ainsi le jour. Cette volution de l'infrastructure illustre la russite du projet, positionnant le CentricStor comme offre standard de sauvegarde sur les datacenter de DOSI. Voir dans les annexes les statistiques d'utilisation des infrastructures.
6.2.
Amlioration de la QS
La mise en uvre de CentricStor a pour objectif majeur d'amliorer la qualit des sauvegardes. La QS des sauvegardes est ainsi particulirement surveille au cours du projet. Les diffrents problmes rencontrs lors de la mise en uvre de CentricStor n'ont pas aid dmontrer l'intrt de la solution sur cet aspect au dmarrage du projet. Mais la mise en uvre d'une stratgie de supervision proactive 24H/24, ainsi que la livraison de correctifs par Fujitsu-Siemens a permis de stabiliser la QS de l'quipement CentricStor au dbut de l'anne 2006.
35/48
7.
Bilan personnel
La ralisation de ce projet m'a permis de mettre en pratique les connaissances acquises au cours de mes deux annes d'exprience sur la sauvegarde, notamment sur les aspects techniques concernant les logiciels et priphriques de sauvegarde ou sur les politiques de sauvegarde. J'ai eu beaucoup d'intrt mener ce projet l'aspect technique innovant : premier projet mettre en uvre le principe de virtualisation, premier client franais mettre en uvre le produit CentricStor. De plus, j'ai pu m'impliquer fortement sur les diffrents aspects techniques du projet : du choix d'architecture initial au suivi de la relation fournisseur : traitement des anomalies rencontres en phase de qualification et demandes d'volution. Mais cette exprience de gestion d'un projet au contexte organisationnel complexe m'a permis d'apprhender d'autres problmatiques et de dvelopper de nouvelles comptences en gestion de projet sur les thmes suivants : - gestion d'un projet transverse et implication de contributeurs extrieurs - rle de la MOA et relation MOA/MOE - gestion de la relation fournisseur - communication autour du projet - gestion du changement et formation Grce cette exprience trs enrichissante, j'ai dcid de m'orienter dbut 2006, aprs plus de quatre ans dans le domaine de la production informatique et des sauvegardes vers un poste de chef de projet MOE dans le domaine des plateformes de service VoIP.
36/48
8.
DOSI DPS DTO DWDM FC ICP IDP LAN MEP NDMP OCISI PRA RFP SI SAN SLA SNPI SOX USEI VLAN VLP
Glossaire
Direction des Oprations du SI Direction des plateformes de Service Direction Technique Oprationnelle Dense Wavelength Division Multiplexing Fiber Channel Integrated Channel Processor Integrated Device Processor Local Area Network Mise En Production Network Data and Management Protocol Organisme Central d'Intgration et de Soutien Informatique Plan de Reprise d'Activit Request For Proposal Systme d'Information Storage Area Network Service Level Agreement Service National de Production Informatique Sarbanes-Oxley Unit de Supervision et d'Exploitation Informatique Virtual Local Area Network Virtual Library Processor
37/48
9.
Annexes
9.1. Cahier des charges initial de DOSI
Ci-dessous quelques extraits du cahier des charges de mutualisation des lecteurs de bandes mis par la DOSI.
Fonctions attendues No de Pondrati Dsignation Fction on lie (sur un total de 20) 1 5 Optimiser l utilisation des lecteurs de bandes pour amliorer la rentabilit de l investissement en lecteurs. Passer d un mode de fonctionnement ou les lecteurs sont ddis des serveurs et des applications la mise en commun dans un pool de ressources unique de tous les lecteurs de bandes la mise disposition de ressources de sauvegarde toutes les applications de manire interchangeable Critre Niveau Flexib ilit
Temps d utilisation 24 heures des lecteurs par jour (limite thorique) Optimisation du dbit Saturation des lecteurs des lecteurs Taux de remplissage >70% des alvoles robotiques Rentabilit lie la < 1 an consolidation de l existant et cot marginal pour les nouveaux besoins (avec un cot avantageux vis vis d une solution ddie) (ROI*) Amliorer la qualit de service de Taux d chec des X > 2 la sauvegarde sauvegardes < taux permettre une reprise rapide en d chec solution cas d incident matriel (dfaillance ddie / X lecteur ou bande) permettre de fiabiliser le processus de sauvegarde (s affranchir des erreurs dues au lecteur ou la bande) Amliorer la qualit de service de Dbit de restauration X > 2 la restauration > X * dbit solution assurer un meilleur dbit la ddie (ou dbit de restauration qu la sauvegarde sauvegarde) prioriser les travaux de restauration par rapport aux travaux de sauvegarde sans 38/48
No de Pondrati Dsignation Fction on lie (sur un total de 20) autoriser de temps de latence pour le dmarrage d une restauration Grer avec plus de souplesse l architecture de sauvegarde et l volution des besoins de sauvegarde. (= raffecter dynamiquement des ressources des besoins)
Critre
Niveau
Flexib ilit
Absorber l volution latente des besoins de sauvegarde des applications sans volution majeure de l infrastructure Outil d administration facilement exploitable Permettre d assurer des besoins exceptionnels : volumtrie exceptionnelle avant opration, bascule de la charge d un serveur sur l autre, Fonctions de capacity planning permettant d valuer la consommation des ressources et d anticiper d ventuels besoins d volution.
Tirer le meilleur parti des mcanismes de dsynchronisation des sauvegardes lorsqu ils existent. Migration aise de l existant sur la Fourniture d un mode solution de migration permettant d envisager la transition de l existant la cible Disponibilit d un support Ne pas dgrader le performant et rapide niveau de soutien de la chane de sauvegarde la plus sensible
Mode de bascule Retour arrire Reprise de l historique Remise en tat optimise en journe
Contraintes 39/48
Critre
Niveau
Flexibilit
Etre compatible avec le parc OS existant Logiciels sauvegarde (coexistence plusieurs logiciels sur solution) SAN Robots (coexistence la solution et serveurs attachement direct sur mme robot) Lecteurs
OS existants OS Platon de Veritas Netbackup de Atempo TiNa EMC la Networker SLS STK de ACSLS de ADIC en un Lecteurs fibre Lecteurs SCSI Lecteurs DLTs Lecteurs STK Lecteurs LTO2
Etre adaptable un Plan de Reprise d Activit : bas sur l externalisation des bandes dans un coffre anti-feu en vue de la reprise de la production sur un site vierge bas sur la mise jour du backup (sur site distant) par bandes bas sur l utilisation des rseaux inter-site pour la sauvegarde
Cohrence entre la gestion des sauvegardes au niveau du logiciel et le processus logistique (= savoir quelles bandes sortir) Automatisation des sorties de bandes pour les transfert quotidiens de bandes d un site l autre (= savoir jecter les bandes)
40/48
Critre
Niveau
Flexibilit
Etre disponible.
Tracabilit de l externalisation en vue de la reprise de la production sans donnes en provenance du site de production (= savoir retrouver les bonnes bandes) Restauration des bandes sur un site vierge (= savoir restaurer les bandes sur un site de reprise quelconque) Engagement sur un taux de disponibilit de l infrastructure centralise de sauvegarde.
Meilleur taux d indisponibilit que la chane de sauvegarde ddie la plus sensible (logiciel + matriel) Temps pris par Temps d indisponibilit chaque planifi du des opration contraintes d exploitation. (patches, sauvegarde de la solution, reparamtrage, ) Ergonomie d exploitation
1 jour /an
41/48
Critre
Niveau
Flexibilit
Etre scalable
Etre dimensionn pour absorber au moins une augmentation de 30% de volumtrie par an
Etre adapt l utilisation de bandes comme mode de transfert de donnes ou d archivage exceptionnel des donnes
les
A chaud ou temps d indisponibilit gnr Procdure Dynamique ou d upgrade de la temps solution pour d indisponibilit faire face une gnr forte volution du primtre (Goland) *2 Capacit d absorption du volume max par jour Capacit d absorber 50% des flux en storage node Alimentation des plateformes de pr-production Alimentation de la recette Demande d archivage annuel (clture comptable) ou en fin de vie de l application de la part de la MOE Ne pas ajouter un niveau de complexit prendre en compte par les applications. Veritas Netbackup
Facilit d administration Procdures d volution du primtre (ajout de lecteurs, de bandes, de serveurs) Passage de patches
Critre
Niveau
Flexibilit
10
Atempo TiNa EMC Networker SLS Possder un mode commande Ordonnancement CLI et des logs exploitables ($U, VTOM) Supervision (Patrol) Remonter les checs de sauvegardes provenant de la solution pour que les mises sur bandes non valides soient consolides avec les informations en provenance du logiciel de sauvegarde
9.2.
Vues de l'quipement CentricStor de production rparti entre les sites d'Aubervilliers et Montsouris. Interface d'administration des composants CentricStor - ICP : Frontaux mulant les lecteurs de bandes - IDP : Back-end pilotant les lecteurs de bandes - FC Fabric redondante - VLP / SVLP : contrleur et contrleur de secours - STKMTS1 et ursa-acsa : robots de sauvegarde respectivement Montsouris et Aubervilliers
43/48
Interface de monitoring de l'activit - gauche : dbits cumuls en temps-rel - Au milieu : vue temps rel des lecteurs virtuels avec bandes montes en bleu - A droite : vue des lecteurs physiques avec lecteurs monts en bleu
Vue instantane des dbits - Cumuls gauche - Par port en entre sur les lecteurs virtuels en haut (bleu = criture) - Par port en sortie vers les lecteurs physiques en bas (vert = criture, rouge = lecture) 44/48
Vue des pools de bandes physiques - Organis par rtention : 1S = une semaine, 2M = 2 mois - Organis par librairie physique : B = Aubervilliers (PLS1), P = Paris (PLS2) - A droite des jauges, en noir : nombre de bandes total et nombre de bandes libres, en rouge et vert, seuils d'alerte.
45/48
Historique d'utilisation du cache disque - Sur une dure d'une semaine (en abscisse) - En jaune le cache rpliqu sur bande (l'espace peut tre rcupr pour crire de nouvelles donnes) - En rouge le cache non rpliqu sur bande - Beaucoup de sauvegardes ont weekend, ont voit l'occupation du cache augmenter le samedi et dimanche (25 et 26 aot 2007) et se vider progressivement le lundi et mardi
46/48
Historiques des dbits en entre et sortie - Sur une dure d'une semaine (en abscisse) - En bleu le dbit cumul d'criture sur les lecteurs virtuels, on dpasse le Go/s le samedi 25 aot 2007, on constate un pic de dbit pendant la nuit - En vert l'criture sur les lecteurs physiques, le dbit est plus constant et liss, plus faible en moyenne grce la compression en entre du CentricStor - En rouge les lectures de bandes physiques occasionne par les rorganisations de donnes sur les bandes 47/48
48/48