Introduction
Cet article est un retour d’expérience d’une montée de version vécue, et n’a pas vocation a représenter un modèle à suivre.
Chaque contexte est différent et cette montée de version a été préparée et organisée en fonction des moyens et possibilités relatives au contexte client.
Compte tenu du contexte et donc des possibilités, nous avons choisi comme Upgrade Strategy de faire un upgrade « In-place » en comparaison d’un upgrade « Out-of-Place » (ou Migration).
Notre motivation principale était la prise en charge plus poussée de l’architecture REST, notamment dans la partie SOA (BPEL). Nous recherchions également plus de stabilité dans cette dernière version de la 12c.
En (très) bref, nous disposons d’un premier domaine (INTPOA) composé d’un cluster OSB à 2 nœuds et d’un cluster SOA à 2 nœuds. Chaque cluster est installé sur 2 machines, les nœuds « 1 » sur la machine « intpoa-1 » et les nœuds « 2 » sur la machine « intpoa-2 ».
Nous disposons d’un second domaine (ORCPRO) composé d’un cluster BPM à 2 nœuds, installé sur 2 machines, le nœud « 1 » sur la machine « orcpro-1 » et le nœud « 2 » sur la machine « orcpro-2 ».
Nous avions donc 4 machines à upgrader.
En revanche, chaque domaine s’appuie sur une base de données mutualisée. Par exemple, le domaine INTPOA (2 clusters sur 2 machines) s’appuie sur une seule base de données.
C’est un point faible de notre installation, à corriger en accord avec les DBA.
C’est également une des raisons du choix de procéder à un upgrade « In-Place ».
Versions
Versions avant l’upgrade
| JDK | JDK 7 Update 45 (jdk1.7.0_45) |
| Oracle Fusion Middleware | 12.1.3.0.170418 |
Versions cibles
| JDK | JDK 8 Update 162 (jdk1.8.0_162) |
| Oracle Fusion Middleware | 12.2.1.3.0 |
Les premières choses à prévoir
Téléchargement des binaires
Une fois les versions cibles choisies, on peut tout de suite télécharger les binaires et les réserver pour le jour J.
Choix de la date
Il faut d’abord trouver une date. Sans une date fixe, rien n’avancera à part la recherche d’une date fixe, il faut le savoir. Vous ne pourrez convaincre personne de faire quoi que ce soit si vous n’avez pas de date à donner. Il faut bien sûr vous assurer qu’à cette date, tous les acteurs dont vous aurez besoin le jour J seront présents.
Sauvegardes
Il faut tout de suite consulter un DBA et un ingénieur système pour vous assurer que les sauvegardes quotidiennes (bases de données et machines) se déroulent sans erreur et planifier, avec eux, une sauvegarde le jour de l’Upgrade.
Plan d’action
Vous devez préparer le plan d’action qui devra lister dans l’ordre chronologique chaque action (unitaire) à réaliser en précisant la date, l’heure et l’acteur. Vous peaufinerez ce plan d’action en réalisant l’upgrade sur les environnements inférieurs à la Production (Recette, Préprod, etc).
Plans de Rollback
Vous n’oublierez pas de prévoir le ou les différents plans de Rollback au cas où le besoin se présenterait. Tout ne se passera pas forcément comme prévu, même si tout le monde le souhaite. Il faut alors être en mesure d’appliquer un plan préparé et maitrisé si le pire se produit. Il faudra répéter ce plan de Rollback autant que le plan d’action pour ne laisser aucune place à l’improvisation le jour J.
Communication
Une fois que vous avez la date, un plan d’action avancé, un plan de Rollback, vous devez faire une communication officielle à tous les acteurs de l’upgrade ainsi qu’aux responsables des différents périmètres impactés. Ils se chargeront de diffuser votre communication plus largement s’ils estiment que cela est nécessaire.
Il est important de faire cette communication très tôt car vous allez certainement indiquer un créneau de coupure de votre plateforme, que les responsables des périmètres impactés vont forcément devoir gérer.
Avant la coupure
Tout ce qui peut être fait hors coupure doit être fait hors coupure (que ce soit avant ou après). L’objectif est bien évidement de réduire au maximum le temps de coupure des services.
Liste non exhaustive des actions qui peuvent être faites :
- avant la coupure (Pre-Upgrade Tasks) :
- Sauvegarde
- Installation des produits
- Vérification des installations
- après la coupure (Post-Upgrade Tasks) :
- Configuration, paramétrage
- Redéploiement de services
- Postes de développement
Upgrade
Nous sommes le jour J, la coupure est prévue le soir de 18h00 à 21h00.
Hier, les différents binaires ont été déposés sur chacun des serveurs. Les sauvegardes ont été planifiées.
Aujourd’hui, jusqu’à 18h00, nous avons le temps d’installer les différents produits sur chaque serveur (le nouveau JDK et chaque produit de la stack Oracle Fusion Middleware que nous utilisons (ici, OSB, SOA Suite et BPM Suite)).
Nous avons le temps de vérifier le bon déroulé des installations grâce à l’assistant d’Oracle, avec l’appui du DBA (qui dispose des privilèges nécessaires) qui doit saisir ses identifiants de temps en temps.
Les dernières sauvegardes sont exécutées et vérifiées, nous donnant ainsi le GO pour l’upgrade.
18h00 : Coupure de l’environnement complet
Nous avons décidé de profiter de cette coupure majeure de l’environnement pour doubler la quantité de RAM disponibles de nos serveurs.
L’ingénieur système était donc le premier à intervenir pour augmenter la quantité de RAM.
Nous avions prévu le changement dans le script de démarrage de chacune de nos JVM pour que ces nouveaux volumes de RAM soient bien pris en compte.
18h30 : Upgrade
On réalise l’upgrade en tant que tel, grâce aux différents assistants fournis, dans l’ordre suivant :
- Upgrade des schémas (bases de données)
- Reconfiguration du domaine (machines)
- Upgrade des composants (machines)
- Propagation de l’upgrade sur le second nœud du cluster (machines)
Ces différentes tâches à réaliser séquentiellement sur chaque machine ont pu être paralléliser sur les deux domaines (INTPOA et ORCPRO). Cela nous a permis de gagner du (précieux) temps de coupure.
19h30 : Redémarrage partiel, paramétrage
Le nœud Admin, à lui seul, nous a permis de réaliser un certain nombre de tâches, nous évitant de tout redémarrer tout de suite, un redémarrage complet pouvant potentiellement prendre du temps, surtout le premier.
Nous avons donc réalisé ici un premier lot de configuration que nous avions identifié dans notre phase de préparation de l’upgrade.
Certaines refontes et livraisons ont dû être effectuées avant de communiquer sur le redémarrage de l’environnement. Certains de nos services n’auraient pas fonctionné sans un minimum de retouches, certains étaient mineurs et d’autres plus conséquents. Nul besoin de préciser la nature des refontes ici tant elles sont spécifiques au contexte de l’upgrade.
20h30 : Redémarrage de l’environnement complet
Redémarrer un environnement complet, surtout pour la première fois, doit se faire avec beaucoup d’attention. Il faut respecter l’ordre de redémarrage des différents composants et bien prendre le temps d’analyser les logs serveurs du redémarrage pour s’assurer qu’aucune erreur n’apparaisse, aussi petite soit-elle. Un environnement qui redémarre en générant des erreurs ne présage rien de rassurant pour la suite…
Nous n’avons donc pas hésité à prendre tout le temps qu’il nous restait pour redémarrer proprement tout l’environnement, plutôt que de se hâter de rouvrir les services plus tôt que nous l’avions prévu au départ.
21h00 : Communication
Il est l’heure de faire votre communication officielle, demandant aux différents responsables de domaines de rouvrir leurs services puisque vous avez terminé votre opération.
21h05 : Tests, contrôles…
Une fois l’environnement complet effectué, il est temps de jouer une série de tests que vous aurez préparé au préalable pour anticiper l’activité « normale » et ainsi corriger les éventuels premiers bugs avant qu’ils ne soient détectés par les utilisateurs…
Aucun autre environnement n’a autant d’activité que la Production, il est toujours difficile de tout prévoir et de tout tester à l’avance. Essayez à ce moment de l’opération de réaliser un maximum de vérifications, de tests de services, de monitoring de serveurs, de base de données, de files JMS, etc. essayez de déceler tout dysfonctionnement avant que les utilisateurs ne reviennent et ne poussent à bout votre nouvelle installation.
22h00 : Fin des derniers réglages, ajustements, etc
Evidemment, il y a eu des couacs, des problèmes que nous n’avions pas rencontré lors des upgrades des environnements inférieurs.
Migration des postes de développement
Votre poste de développement doit lui aussi être mis à jour. Il ne faut pas prévoir de tout basculer trop tôt, dans le cas où le un plan de Rollback ait été déclenché et qu’il faille continuer à travailler sur l’ancienne version. Vous pouvez aussi décider de maintenir deux environnements de développement le temps de la bascule mais c’est déjà plus contraignant.
Erreurs commises
Des oublis, faute de temps !
Nous obtenions encore certaines erreurs les jours qui ont suivi l’upgrade malgré notre satisfaction générale de l’opération. En fait, il s’est avéré que des patches devaient être installés pour éradiquer certains bugs produits.
Nous avons oubliés de réaliser certaines refontes, qui ont donc dû être réalisées et livrées en urgence après l’upgrade.
Ces deux erreurs (patches et refontes oubliées) sont le résultat d’un seul gros problème : l’intervalle de temps trop court entre l’upgrade en Recette et celui en Production. Il est clair qu’on ne peut pas rester trop longtemps à cheval sur deux versions lors d’un upgrade « In-Place ». Nous avions « la chance » que l’écart entre notre version actuelle et notre version cible était faible et donc de jouer avec deux versions très largement compatibles, mais cela reste risqué de faire de la recette sur un environnement qui n’est pas iso-prod.
Le temps que vous aurez pour faire la recette dépend grandement de la date que vous choisirez pour faire l’upgrade de la Production, car les autres dates découlent toutes de celle-ci.
Des environnements différents
L’histoire de notre client a fait que l’environnement de Développement est structuré différemment de notre environnement de Recette, qui lui-même est structuré différemment de l’environnement de Pré-production, qui lui, fort heureusement, est à l’image de la Production.
De ce fait, l’upgrade a pu se dérouler différemment à certains moments en fonction de l’environnement sur lequel on l’exécutait.
Tant que possible, les environnements doivent se ressembler pour éviter les mauvaises surprises.
Conseils
- Faites régulièrement des montées de version, pour limiter l’écart entre les versions et donc la difficulté de l’upgrade
- Réservez-vous assez de temps pour la recette, afin de n’oublier aucun correctif ou patch à appliquer en Production
- Occupez-vous de tous vos environnements de la même manière, pour ne pas obtenir des résultats différents pour un même Upgrade en fonction de l’environnement
- Choisissez bien la date (période creuse, heures creuses, etc), pour éviter d’impacter trop d’utilisateurs par la coupure de services
- Répétez votre plan d’action, pour le maîtriser du bout des doigts et ne pas devoir se poser de question le jour de la mise en Production
