R

1
Ré-appropriation du Système dInformation

• Sylvain MILLOUR Architecte système

2
LOffice Français de lImmigration et de
lIntégration (1/2)

• LOFII est lopérateur de lEtat en charge de
  lintégration des migrants durant les 5 premières
  années de leur séjour en France.
• LOFII a en outre pour missions la gestion des
  procédures de limmigration professionnelle et
  familiale, la gestion du dispositif national
  daccueil des demandeurs dasile, celle des aides
  au retour et à la réinsertion participant au
  développement solidaire, ainsi que la lutte
  contre le travail illégal.
• Service Informatique DSI
• 2 DataCenter
• 31 DT (Direction Territoriale)
• 7 représentations à létranger
• Environ 800 postes
• 8 applications métiers
• Environ 25 serveurs physiques / 2 baies SAN /
  Environ 300 VMs
• 5 environnements DEV / TEST / Recette / PreProd
  / Prod
• Vmware / Oracle / SQL Server 2008 / Windows
  Server 2003, 2008R2 / AIX / RedHat / NetApp /
  Evault

3
LOffice Français de lImmigration et de
lIntégration (2/2)

• Le métier en quelques chiffres
• Lapplication IMMI-2 traite tous les dossiers des
  migrants en situation régulière (environ 200 000
  dossiers par an), en vue de lobtention dun
  titre de séjour et de la signature éventuelle
  dun Contrat dAccueil et dIntégration (CAI).
• IMMI-2 est interfacée avec plusieurs applications
  métiers
• CAI 100 000 dossiers / an
• CAI Etranger 10 000 dossiers / an
• IMMI-GU 2 000 dossiers / an
• une application comptable
• SIREP_at_NET 40 000 dossiers / an
• et des applications partenaires
• AGDREF 100 000 dossiers / an
• ANTS 30 000 dossiers / an

4
Etat des lieux et constats

• Situation en 2011
• Un environnement qui a rapidement évolué
  (multiplication des VM, utilisation du snapshot
  comme base de sauvegarde, manque de
  documentation, saturation des LUNs)
• Un déménagement à préparer pour 2012
• Une production à maintenir avec de nouveaux
  besoins réguliers
• Les constats
• Nombre important dincidents
• Instabilités quelle que soit la technologie
• Arrêts de production trop fréquents

5
Lancement de la démarche de transformation

• Une démarche en 3 phases
• 2011 à 2013 - Le Datacenter (socle
  infrastructure)
• 2012 à 2013 - Les Services agences et Postes de
  Travail
• 2013 - Les Applications Métier
• Approche par grands jalons
• Adaptation et mise à niveau des composants
  logiciels
• Objectif 1 -gt Améliorer la stabilité et assurer
  un bon support
• Restructuration des composants physiques
  (déménagement, renouvellement du parc micro,
  refonte du stockage)
• Objectif 2 -gt Retrouver la performance et
  minimiser les risques
• Mise en place doutils de monitoring et de
  gestion des services
• Objectif 3 -gt Piloter avec une vue large et des
  indicateurs

6
Datacenter (socle infrastructure)Virtualisation
et Stockage
PAR6
PAR2
7
Bilan et apports

• Une architecture virtuelle transformée en 2 mois
• sans arrêt de production
• 300VMs migrées
• Une migration guidée par le stockage Lun par Lun
• Réorganisation des serveurs en secteurs
• Mise en place des outillages
• SDRS (Gestion automatique du stockage)
• DvS (Configuration réseau étendue sur tous les
  ESXs)
• Linked mode (1 vue unique sur lentièreté de la
  ferme)
• Comptes dadministration nominatifs
• Harmonisation du stockage
• La libération de 4 disques de 450Go
• Une urbanisation optimale
• Une simplification de ladministration et de la
  gestion du stockage

8
Apport Gestion du stockage
SDRS Gestion automatique du stockage
Monitoring et pilotage
9
Apport Gestion des configurations réseaux
DVS Distributed vSwitch
Monitoring et pilotage
10
Piège à éviter événement rencontré lors de la
phase de migration des serveurs

• 1 - Saturation du serveur SQL serveur hébergeant
  la base de données du vCenter
• -gt Perte de la console vCenter
• -gt Tâches programmées de migration toujours
  actives mais plus de contrôle
• -gt Résolution rapide et relance du serveur SQL
  serveur
• -gt Reprise de mains sur la console mais plus de
  contrôle sur les actions programmées
• 2 Les actions liées au stockage de libération
  des LUNs ne sont pas reprises en compte, pour
  autant les actions de migration se poursuivent
• -gt Saturation dune LUN avec un arrêt en chaine
  des serveurs présents sur cette LUN
• -gt Risque de perte de 14 serveurs de production
  et 2 de développement
• -gt La LUN saturée nest plus reconnue par les
  serveurs ESX
• -gt Lancement dun plan durgence de
  reconstruction de lempreinte VMFS (Succès)
• -gt Rattachement de la LUN (perte dun 1 serveur
  de dev uniquement)
• -gt Laction de reprise à démarrée le vendredi à
  22h et la situation a été rétablie le dimanche à
  midi Pas darrêt de production reprise le lundi
  en toute transparence
• Lors dune transformation, les tâches de
  migration sont des périodes délicates où la
  disponibilité du socle technique doit être de 100

11
Constats post-transformation

• La migration a permis de mettre en avant les
  éléments suivants
• Lutilisation des filers Netapp actuels est
  déséquilibrée
• Entre 85 et 95 dutilisation CPU pour la partie
  ESX
• Entre 15 et 25 dutilisation CPU pour la partie
  AIX
• Il en est de même pour les IOPs
• Conseils
• Lespace de stockage gagné par la déduplication
  doit être utilisé avec parcimonie. Le stockage
  SAN se compose aujourdhui dagrégats configurés
  en RAIDDP, de volumes de 1024Go, de LUNs de 500Go
  et lespace dédupliqué est non alloué
• La sécurisation des serveurs vCenter devient
  nécessaire du fait de limportance de ces
  serveurs dans le SI.

12
Recommandations

• Etude précise du parc avant démarrage de la
  migrations des serveurs
• (attachements, dépendances, criticités, impacts)
• Planification fine avec estimation des temps de
  traitement
• Avant le lancement des tâches
• Suivi régulier de lavancement des tâches en
  cours de traitement
• Une sauvegarde avant tout
• Et
• une expertise réactive à portée de la main