Migration Websphere 8

Transcription

1 Migration Websphere 8 22/05/2012 Sébastien GAGGINI & Denis MASNERI

2 Sommaire 1. Contexte et existant 2. Propositions du Projet 3. Déploiement de Websphere 8 4. Principes de la migration 5. Annexe 2

3 1 Contexte et existant 3

4 Contexte Contraintes du Projet Production Fin du support standard IBM sur WAS 6.1 en septembre 2012 Favoriser Linux sur les nouvelles architectures Isoler les différents métiers pour limiter les risques liés à plusieurs équipes de production travaillant sur les mêmes serveurs Limiter les impacts métiers lors des maintenances sur 1 serveur Améliorer le suivis des versions Mise à niveau du PSI sur les Infra WAS Mise à niveau des serveurs et OS Etudes & Métiers Fonctionnalités JEE6 Coûts de migration faibles Limiter les accès aux donnés pour les métiers sensibles 4

5 Contexte Parc de production 3 typologies d architectures sont déployées A. Mutualisée WAS LPAR AIX 5.3 Power 6 2 par site 5 métiers par paire de serveurs partageant les mêmes binaires WAS 6.1 Total de 22 cœurs 400Go de RAM 220 JVM 150+ applications web pour clients interne, groupe et internet 11 métiers différents B. Convergence titres 6 LPAR AIX 5.3 Power 6 3 par site 1 client par paire de serveurs (BP, CE, LBP) Total de 84 cœurs 192Go de RAM 92 JVM 2 applications web pour 3 clients, en Agence et sur Internet C. Divers dédiés ~30 serveurs AIX et Linux ~60 applications dont 40 JCMS 5

6 Contexte Architecture Prod Mutualisé 6

7 2 Propositions du Projet 7

8 Propositions du Projet Le projet propose ces évolutions Front IBM HTTP Server (IHS) Garder les serveurs actuels x86 Linux Red Hat EL 5.4 Montée de version OS en Red Hat EL 6.x Montée de version en IHS 8 Back Websphere Application Server (WAS) Nouveaux serveurs x86 Linux Red Hat EL 6.2 Websphere paire de serveurs par métier en production et qualification 1 serveur de recette et 1 développement par métier Migration manuelle ou automatique avec les procédures IBM, au choix de chaque prod applicatives Industrialisation du déploiement initial et des patchs de Websphere 8

9 Propositions du Projet Perf AIX/Linux Benchmark CPU Processeur standard Natixis Source spec.org Modele Cœur Entier Total Entier /Cœur Flottant Flottant /Cœur Résultat Normalisé IBM Power (3.1 GHz) , ,7 1 IBM HS22 Intel X (3 GHz) , ,9 Soit environ 10% de perf en moins en calcul pur sur Intel Benchmark Java - Processeur similaire Natixis Source spec.org Bench serveur(s) WAS7 + serveur base de donnée Ces résultats sont plus complexes à comparer, le matériel hébergeant la base de donnée du bench variant, et le Power7 testé étant plus puissant que les 770 de Natixis Modèle Cœur Résultat Par Cœur Par GHz 1x IBM Power (4Ghz) x IBM HS22 X5670 6x12=>72 (3 GHz) Les performances sont similaires avec un léger avantage pour les processeurs Intel 9

10 Propositions du Projet - x86 Physique 1ere proposition : Serveurs Physiques Linux Les plus petits serveurs Intel x86 au catalogue Natixis sont des lames IBM avec 2 processeurs de 6 cœurs et 24Go de RAM, soit 12 cœurs par serveurs. A multiplier par le nombre de métiers, sites et environnements. Les calculs initiaux annoncent une augmentation des couts licence/support d un minimum de 150%. Hors ces coûts le nombres de serveurs à déployer physiquement (rack, câblage) est important. 10

11 Propositions du Projet - x86 Virtualisée 2eme proposition : Création d une ferme ESX dédiée pour Websphere. Maîtrise de l allocation CPU de chaque serveurs Coûts de licence/support similaire, voir plus faible PSI principalement géré par le système Déploiement rapide des serveurs une fois la ferme en place Gestion simplifiée des interventions hardware et de l obsolescence et des serveurs (VMotion intrasite) A terme évolution de la solution de stockage sousjacente pour permettre du VMotion intersites. Pas de solution compatible avec les exigences du SSI pour les serveurs en DMZ 11

12 Propositions du Projet Architecture fonctionnelle IHS GROUPE IHS INTERNET ASS AFF TTR INS GIP SRD IHS LAN FSP FCC MON BFI INF SEC DMGR EGE DMGR FIP DMGR SFI DMGR BFI DMGR SEC 12

13 Propositions du Projet Détails 13

14 3 Déploiement de Websphere 8 14

15 Déploiement de WAS 8 Serveur Central Websphere 8 se déploie avec Installation Manager (IM). Pour chaque serveurs il faut : Un FS pour installer IM et son répertoire de conf Un FS pour le cache Eclipse, que IM utilise pendant les déploiements Un accès à un ou des repository contenant les produits à installer, sur un système de fichier ou sur un serveur Web Pour le projet nous avons déployé un serveur technique ( slpmdwj1 ) avec Packaging Utility qui permet de regrouper repository de plusieurs produit (WAS, IHS, RSA, ) dans un unique repo commun, et permet de récupérer les mises à jour de ces produits directement depuis les serveurs IBM Un JobManager pour gérer des opérations à distance sur les serveurs de la ferme. Pour le moment il n est pas réellement utilisé dans nos procédures. Un serveur Web qui sert le contenu du repository unique, des binaires Installation Manager, des réponses files et de fichiers utilisés pour nos installations. 15

16 Déploiement de WAS8 - Exemple Pour déployer un serveur il faut simplement qu il ait accès port Web sur slpmdwj1. On déploie Installation Manager wget _0824.zip unzip agent.installer.linux.gtk.x86_ _0824.zip userinstc -acceptlicense -datalocation /apps/installationmanager/data -installationdirectory /apps/installationmanager/bin Puis avec IM on installe un noyau WAS 8 (response file en annexe) imcl input " - datalocation /apps/installationmanager/data -acceptlicense - showprogress 16

17 Déploiement de WAS8 - Exemple Les profils sont crées en ligne de commande comme dans les précédentes versions de WAS (manageprofiles.sh). Le principe est le même pour IHS 8. Et il n est plus nécessaire de déployer un GSKit séparément. Un patch se fait de la même manière avec un réponse file qui contient une version supérieure, ou avec une commande IM qui met à jour tout les produit du serveurs avec la dernière version disponible sur le repo. 17

18 4 Principes de la migration 18

19 Principes de la migration des applications Java/JEE Retours du workshop avec IBM Certains pré-requis de la migration WAS8 sont impactants : montée de version système préalable AIX 6.1 / RHEL 5.6 ou 6 Utilisation du driver Oracle JDBC 11g (ce qui permet d accéder à une base Oracle 10g ou 11g) La procédure de migration fournie par IBM convient aux besoins du projet, moyennant certaines adaptations (validées par IBM) Les tests effectués sur quelques applications types Java/JEE (Sphinx, MVC2, WebService) n ont pas nécessité de maintenances applicatives: impact faible a priori sur les parcs applicatifs Principe de migration par «cellules WAS» Une cellule WAS héberge un ensemble d applications JAVA/JEE Elles sont urbanisées par métiers, sur chaque environnements (,,, PROD) Utilisation du système de migration industrialisé d IBM Pas de nécessité à migrer le code des applications sur l architecture JEE6: les applications développées en JEE5 continuent à fonctionnée sur le «runtime Java» de JEE6 de WAS Principes des opérations à mener pour chaque cellules Montée de version sur la partie «Serveur Web IHS» (IHS 8 compatible WAS 6.1) Duplication des applications (+config) de WAS 6.1 sur WAS 8 Bascule au fur et à mesure des applications de WAS 6.1 à WAS 8 Planning à établir avec chaque Domaine Etudes / Productions Applicatives Temps de bascule à minimiser pour éviter les «livraisons en Y» dans la durée et se remettre en conformité sur les licences WAS

20 Enchaînement des opérations pour chaque cellules 1. Montée de version IHS (IHS 8 compatible WAS 6.1) utilisateur LB IHS 6 WAS 6 IHS 6 WAS 6 DMGR 6 utilisateur LB IHS 8 WAS 6 IHS 8 WAS 6 DMGR 6 WAS 6 IHS 8 WAS 6 DMGR 6 2. Installation de nouveaux serveurs WAS 8 utilisateur LB IHS 8 WAS 8 WAS 8 DMGR 8 3. Duplication des applications (+config) de WAS 6.1 sur WAS 8 WAS 6 DMGR 6 IHS 8 WAS 6 LB utilisateur 4. Bascule par applications de WAS 6.1 vers WAS 8 IHS 8 WAS 8 WAS 8 DMGR 8

21 5 Annexe 21

22 Response File pour WAS <?xml version="1.0" encoding="utf-8"?> <server> <repository location=' </server> <profile id='ibm WebSphere Application Server Network Deployment V8.0' installlocation='/apps/websphere/8.0/noyau/mdw_64'> <data key='eclipselocation' value='/apps/websphere/8.0/noyau/mdw_64'/> <data key='cic.selector.nl' value='en,fr'/> </profile> <install modify='false'> <offering id='com.ibm.websphere.nd.v80' version=' _1708' profile='ibm WebSphere Application Server Network Deployment V8.0' features='core.feature,ejbdeploy,thinclient,embeddablecontainer,com.ibm.sdk.6_64bit' installfixes='none'/> </install> <preference name='com.ibm.cic.common.core.preferences.eclipsecache' value='/apps/installationmanager/imshared'/> <preference name='com.ibm.cic.common.core.preferences.connecttimeout' value='30'/> <preference name='com.ibm.cic.common.core.preferences.readtimeout' value='45'/> <preference name='com.ibm.cic.common.core.preferences.downloadautoretrycount' value='0'/> <preference name='offering.service.repositories.areused' value='true'/> <preference name='com.ibm.cic.common.core.preferences.ssl.nonsecuremode' value='false'/> <preference name='com.ibm.cic.common.core.preferences.http.disablepreemptiveauthentication' value='false'/> <preference name='http.ntlm.auth.kind' value='ntlm'/> <preference name='http.ntlm.auth.enableintegrated.win32' value='true'/> <preference name='com.ibm.cic.common.core.preferences.preservedownloadedartifacts' value='true'/> <preference name='com.ibm.cic.common.core.preferences.keepfetchedfiles' value='false'/> <preference name='passportadvantageisenabled' value='false'/> <preference name='com.ibm.cic.common.core.preferences.searchforupdates' value='false'/> <preference name='com.ibm.cic.agent.ui.displayinternalversion' value='false'/> <preference name='com.ibm.cic.common.sharedui.showerrorlog' value='true'/> <preference name='com.ibm.cic.common.sharedui.showwarninglog' value='true'/> <preference name='com.ibm.cic.common.sharedui.shownotelog' value='true'/> </agent-input> 22