Présentation de la migration de Dimensions 10.1.3 vers 12.2.0.3

1. Présentation de la migration de Dimensions 10.1.3 vers 12.2.0.3 28/09/2012 Ali Meraoumia

2. Sommaire • Contexte Natixis • Environnement de production Dimensions v12 • Processus de migration • Problèmes rencontrés • Situation actuelle (3 mois après la migration) • Présentation des nouveautés Dimensions v12

3. 1 • Contexte Natixis

4. Contexte Natixis – 1/2 • Dimensions chez Natixis c’est : • Une solution mise en œuvre depuis 2002 • Dimensions V8 puis V10 et enfin V12 • Une solution de GCL gérant • Tous les développements systèmes distribués • Des progiciels • Une partie des développements Mainframe • Une solution utilisée par plus de 300 utilisateurs • Pour la gestion des versions • La fabrication des livrables • Le déploiement des livrables

5. Contexte Natixis – 2/2 • Dimensions chez Natixis c’est : • Un serveur Dimensions v12 unique accédé au travers • Du Desktop client • Du client web • Du plugin eclipse • Du plugin Visual Studio • Des volumétries de données importantes • 300 Product • Plus de 3 millions de révisions d’items • 250 Go pour les items Libraries • 150 Go pour la Base de données

6. 2 • Environnement de production Dimensions v12

7. Environnement de production Dimensions V12 • L’environnement Dimensions est constitué de • Un serveur Dimensions 12.2.0.3 installé sur un serveur AIX 6.1 • Une base de données Oracle 11g installée sur un serveur AIX 6.1 • 15 agents Z/Os • 4 en développent, 4 en recette, 3 en qualification, 3 en production et 1 sur la partition système • 9 agents Windows • 20 agents Unix

8. Architecture Dimensions de production Mainframe Systèmes distribués Agents Windows Agents Unix Partition de rec NBPREC1 Partition de dev NBPDEV1 Partition de qua NBPQUA1 Partition de prod NBPPRD1 Oracle primaire sxporaa2 AIX 6.1 ORAXPA21 Dimensions primaire sxpdim01 AIX 6.1 Données Sur le SAN Bascule automatique Items libraries Sur le SAN Synchronisation Bascule manuelle VIP Utilisateur VIP Données Sur le SAN Oracle backup Sxporaa3 AIX 6.1 ORAXPA21 Dimensions backup sxpdim02 AIX 6.1 Dimensions Oracle

9. 3 • Processus de migration

10. Processus de migration – 1/8 • Contexte • Migration de Dimensions 10.1.3.3 vers Dimensions 12.2.0.3 • Deux plates-formes Dimensions distinctes • Une plate-forme Dimensions 10 • Une nouvelle plate-forme Dimensions 12 • Migration à réaliser en un week-end pour ne pas perturber le service • Serveur Dimensions • Agents Z/Os • Télédistribution des clients, à venir • Migration des agents Windows/Unix, à venir

11. Processus de migration – 2/8 • Opération réalisées avant la bascule • Construction du nouvel environnement de Production • Mise à disposition des serveurs pour Dimensions • Mise à disposition des serveurs Oracle • Installation de Dimensions • Mise en place de la supervision des machines • Démarrage de Dimensions et premiers contrôles • Validation de l’authentification LDAPS • Validation de la configuration de déploiement • Synchronisation des Items Libraries entre l’ancien et le nouveau serveur Dimensions • Opération hebdomadaire réalisée via l’outil « rsync »

12. Processus de migration – 3/8 Base Oracle Dimensions 12 Base Oracle Dimensions 10 Exécution // des traitements par crontab UpgradeDeploy database 1 UpgradeDeploy database 2 Upgrade de la base Mise à jour des données Build_Upgrade_Molist Étape 1 Étape 2 Tests et recette systèmes distribués Ajustement des processus Tests et recette progiciels Ajustement des privilèges Tests et recette Z/Os Déploiements des Template Étape 4 Étape 3

13. Processus de migration – 4/8 • Opération réalisées le week-end de la bascule – Etape 1 • Export de la base Oracle de production • Import dans la nouvelle Base Dimensions v12 • Synchronisation des Items Libraries entre l’ancienne et la nouvelle plate-forme Dimensions • Upgrade de la base • dmdba upgrade all (3 Database, 2 heures) • Installation des vues publiques • Mise à jour des mots de passe des users Oracle (le processus d’upgrade réinitialise les mots de passe Oracle)

14. Processus de migration – 5/8 • Opération réalisées le week-end de la bascule – Etape 1 • Mise à jour des données en base • Mise à jour des Network Nodes • Ajout des nouveaux (Serveur Dimensions, Serveurs Oracle) • Suppression des anciens (Serveur Dimensions, Serveurs Oracle) • Mise à jour des références aux nouveaux serveurs dans les « Node Connections » • Mise à jour des Upload Rules (supprimées par le processus d’Upgrade) • Mise à jour des Item Libraries • Référencer le nouvel emplacement des Items Libraries

15. Processus de migration – 6/8 • Opération réalisées le week-end de la bascule – Etape 2 • Exécution en parallèle des traitements d’Upgrade suivants • UpgradeDeploy des Deployment Areas Z/Os (database 1) • Environ 30 Item à la seconde • Ne fonctionne pas pour les Deployment Areas ayant de grosses volumétries • UpgradeDeploy des Deployment Areas Unix/Windows (database 2) • Environ 15 Item à la seconde • Build_Upgrade_Molist (database 1) • 11h de traitement pour 16 006 123 d’enregistrements • Pour les trois Deployment Areas ayant de très fortes volumétries, un patch a été livré permettant de réaliser l’upgrade des Deployment Areas en mode déconnecté • Environ 7 Item à la seconde

16. Processus de migration – 7/7 • Opération réalisées le week-end de la bascule – Etape 3 • Ajustements des processus • Masquage des types de Baseline inutilisés • Mise à jour des privilèges • Mise à jour des « Profils Views » • Livraison des Template Z/Os • Livraison des développements spécifiques

17. Processus de migration – 8/8 • Opération réalisées le week-end de la bascule – Etape 4 • Tests et recette du processus systèmes distribués • Tests et recette du processus progiciels • Tests et recette du processus Z/Os

18. 4 • Problèmes rencontrés

19. Problèmes rencontrés – 1/3 • Le script d’installation ne fonctionne pas avec un client Oracle 11g • Pour accéder à une base Oracle 11g, Dimensions a besoin d’un client Oracle 10. L’installeur installe son propre client dans tous les cas. Il est possible de le supprimer ensuite. • Authentification LDAPS • Pour que l’authentification LDAPS fonctionne correctement, il faut ajouter le paramètre LDAP_CONFIG_FILE • Problème d’accès au fichier dm.cfg • Le fichier dm.cfg doit être en lecture pour tout les utilisateurs (r-- r-- r--)

20. Problèmes rencontrés – 2/3 • ADP5000048E Error: Unable to execute ADP trigger • Ce problème intervient lorsqu’un état du cycle de vie d’un objet est associé à un stage du GSL. • Mettre à jour la table PCMS_SYS.PCMS_DB_DETAILS avec les informations correspondants au serveur et à la base Oracle • Volume des données de la table MO_LIST trop important • Cette table contient les références croisées (16 millions d’enregistrements). • Impossible d’afficher les Target dans le Desktop client • Impossible de fabriquer les composants Z/Os • Nécessité de purger manuellement la table

21. Problèmes rencontrés – 3/3 • Processus d’upgrade des Deployment Areas • L’UpgradeDeploy tombe en erreur si le volume des données à traiter est trop important (250 000 items) • Impossible de migrer certaines Deployment Areas • Livraison d’un patch par Serena (dmdba) qui réalise l’opération en deux fois • Analyse des Deployment Areas et construction d’un fichier de données • Chargement du fichier dans Dimensions • Impossibilité d’arrêter le serveur Dimensions • Le nouveau processus de gestion des déploiements (dmdeploysrv) bloque, dans certains cas, l’arrêt du serveur • Mise à jour du script d’arrêt « dmshutdown » avec ajout d’un « kill -9 » du processus « dmdeploysrv » avant arrêt du serveur

22. 5 • Situation actuelle (3 mois après la migration)

23. Situation actuelle • La plate-forme Dimensions v12 est en production depuis 3 mois • Très peu d’incidents constatés • Très peu de cas de support enregistrés • Télédistribution du Desktop client v12 planifiée pour la fin du mois de septembre • Télédistribution du plugin eclipse planifiée pour le début du mois d’octobre

24. 6 • Présentation des nouveautés Dimensions

25. Nouveautés Dimensions • Modification du mécanisme de Deploy • Le déploiement est découpé en deux phases • Promote : Mise à jour du « Stage » des objets sans alimentation des déploiement areas • Deploy : Alimentation des Deployment Areas • Il est possible de configurer un déploiement automatique après un « Promote » • Le déploiement est asynchrone • Un processus (dmdeploysrv) gère les déploiements par un mécanisme de files d’attente • Une console de déploiement accessible depuis le client web « Dimensions » permet de • Visualiser l’état des déploiements • Relancer un déploiement tombé en erreur

26. Nouveautés Dimensions

27. Nouveautés Dimensions • Association d’un état du cycle de vie d’un objet avec un stage du GSL • Permet d’exécuter un déploiement lorsqu’un objet est actionné dans son cycle de vie • Permet de masquer l’utilisation du deploy aux utilisateurs (1) TUP TUG TUG TIA TIA TIA QUALIF QUALIF (3) (1) (A) (1) (A) (2) (2) (A) TUG KO TIA KO QUALIF KO TUP Déploiement en TUG TUG Déploiement en TIA TIA Fin TIA Déploiement en QUALIF QUALIF TERMINEE R R R (1) (A) (1) (A) (2) (A) TUP TUG TIA Développement Recette Qualification • : Profil Développeur (DEV) + environnement TIA • : Profil Responsable Application (RA) ou Chef de Projet (CP) • : Profil Responsable de Livraison (RL) (A) : Action d’Administration (User Technique) Build Request Automatique R