Post on 04-Apr-2015
Ré-appropriation du Système d’Information
Sylvain MILLOUR – Architecte système
L’OFII est l’opérateur de l’Etat en charge de l’intégration des migrants durant les 5 premières années de leur séjour en France.
L’OFII a en outre pour missions la gestion des procédures de l’immigration professionnelle et familiale, la gestion du dispositif national d’accueil des demandeurs d’asile, 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
L’Office Français de l’Immigration et de l’Intégration (1/2)
Le métier en quelques chiffres :
L’application IMMI-2 traite tous les dossiers des migrants en situation régulière (environ 200 000 dossiers par an), en vue de l’obtention d’un titre de séjour et de la signature éventuelle d’un Contrat d’Accueil et d’Inté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@NET : 40 000 dossiers / an
… et des applications partenaires :• AGDREF : 100 000 dossiers / an• ANTS : 30 000 dossiers / an
L’Office Français de l’Immigration et de l’Intégration (2/2)
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 d’incidents • Instabilités quelle que soit la technologie• Arrêts de production trop fréquents
Etat des lieux et constats
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 -> 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 -> Retrouver la performance et minimiser les risques
- Mise en place d’outils de monitoring et de gestion des services
Objectif 3 -> Piloter avec une vue large et des indicateurs
Lancement de la démarche de transformation
Datacenter (socle infrastructure)Virtualisation et Stockage
PAR6
PAR2
Bilan et apports
Une architecture virtuelle transformée en 2 mois sans arrêt de production
300VMs migréesUne migration guidée par le stockage Lun par Lun
Réorganisation des serveurs en secteurs
Mise en place des outillagesSDRS (Gestion automatique du stockage)
DvS (Configuration réseau étendue sur tous les ESXs)Linked mode (1 vue unique sur l’entièreté de la ferme)
Comptes d’administration nominatifs
Harmonisation du stockage :La libération de 4 disques de 450Go
Une urbanisation optimale
Une simplification de l’administration et de la gestion du stockage
Apport : Gestion du stockage
SDRSGestion automatique du stockage Monitoring et pilotage
Apport : Gestion des configurations réseaux
DVSDistributed vSwitch
Monitoring et pilotage
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 :-> Perte de la console vCenter-> Tâches programmées de migration toujours actives mais plus de contrôle-> Résolution rapide et relance du serveur SQL serveur-> 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 :-> Saturation d’une LUN avec un arrêt en chaine des serveurs présents sur cette LUN-> Risque de perte de 14 serveurs de production et 2 de développement-> La LUN saturée n’est plus reconnue par les serveurs ESX-> Lancement d’un plan d’urgence de reconstruction de l’empreinte VMFS – (Succès)-> Rattachement de la LUN (perte d’un 1 serveur de dev uniquement)-> L’action de reprise à démarrée le vendredi à 22h et la situation a été rétablie le dimanche à midi – Pas d’arrêt de production reprise le lundi en toute transparence…
Lors d’une transformation, les tâches de migration sont des périodes délicates où la disponibilité du socle technique doit être de 100%
Constats post-transformation
La migration a permis de mettre en avant les éléments suivants:- L’utilisation des filers Netapp actuels est déséquilibrée- Entre 85% et 95% d’utilisation CPU pour la partie ESX- Entre 15% et 25% d’utilisation CPU pour la partie AIX- Il en est de même pour les IOPs
Conseils :- L’espace de stockage gagné par la déduplication doit être utilisé avec
parcimonie. Le stockage SAN se compose aujourd’hui d’agrégats configurés en RAIDDP, de volumes de 1024Go, de LUNs de 500Go et l’espace dédupliqué est non alloué
- La sécurisation des serveurs vCenter devient nécessaire du fait de l’importance de ces serveurs dans le SI.
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 traitementAvant le lancement des tâches
Suivi régulier de l’avancement des tâches en cours de traitement
Une sauvegarde avant toutEt
une expertise réactive à portée de la main…
Recommandations