Je voudrais revenir ici sur l’organisation et le déroulement d’une campagne de patch Exadata, je viens de participer à la réalisation de ce micro projet et je vais partager cette expérience en soulignant les éléments qui peuvent être utiles le jour où, vous aussi, vous devrez réaliser cette opération.

Tout d’abord rappelons quelques éléments.

Il est important de maintenir à jour les composants de la machine Exadata pour les raisons suivantes :

• C’est un engagement contractuel avec Oracle pour continuer à en avoir le support
• Cela préserve la qualité de service
• Cela permet de maintenir un niveau constant de performances
• Vous bénéficiez des dernières améliorations et fonctionnalités
• Vous garantissez que le niveau de sécurité est maintenu au plus haut

Oracle diffuse, chaque trimestre, un ensemble nommé QFSD (Quaterly Full Stack Download) qui contient l’ensemble des mises à jour pour tous les composants de la machine.
Toutes les informations nécessaires sont constamment rafraichies dans la note 888828.1.
C’est le point de départ obligé pour toute campagne de patch.

Avec votre contrat Platinum, et si vous avez bien établi la liaison avec Oracle via la gateway, ce service intégré à votre coût de support peut réaliser les mises à jour sous leurs conditions, voire celles-ci dans le document : http://www.oracle.com/us/support/library/certified-platinum-configs-1652888.pdf.
Vous pouvez aussi, si vous avez les profils techniques à disposition, réaliser vous-même les opérations, c’est ce que font certains clients dans le secteur bancaire par exemple.

Dans la campagne d’exemple que je vous propose, les conditions sont les suivantes :

• Mise à jour d’un 1/8 Exadata X4-2 bare metal (pas de virtualisation), 2 serveurs de bases de données, 3 cellules de stockage.
• Une cinquantaine de bases de données en version 11.2.0.4 réparties sur 5 Oracle Homes différents (en comptant tous les environnements, prod, qualification, intégration, développement et formation)
• Pas de PRA mais des sauvegardes régulières
• Réalisation du patching par les équipes de Platinum, en mode ROLLING car pas de PRA et pour limiter le temps d’indisponibilités des applications
• Versions d’origine : logiciel Exadata 12.1.2.35, Grid infrastructure 12.1.0.2

Cible logiciel choisie : QFSD d’avril 2018 version 18.1.0.5 pour le logiciel Exadata, Mise à jour du composant Grid Infrastructure sur les serveurs de bases de données en version 12.2.0.1

La première étape, dans ce cadre, et ce, jusqu’il y a peu, était d’ouvrir un SR en précisant dans le type de problème que c’est une demande de patching

Problem Category/Subcategory 
--------------------------------------------------- 
Patching Request/Exadata Patching Request 

Puis d’alimenter cette SR avec toutes les informations demandées, et enfin de se mettre d’accord pour la planification avec le coordinateur en fonction des dates de disponibilité de chacun.

Sauf que ce n’est plus la bonne procédure, il faut maintenant passer par l’interface de la gateway ou Oracle Advanced Support Gateway ie OASG Portal.
Voici la réponse du coordinateur Platinum à notre première demande :

"
Please note that as per the change in Platinum Process you will have to schedule these systems via your gateway. 

Kindly find below documentation on the same: 

https://support.oracle.com/rs?type=doc&id=1608308.1 (Video) 

https://support.oracle.com/rs?type=doc&id=2190010.1 (Video + KM note) " 

Le changement d’interface est une bonne idée, surtout que l’on a directement accès aux dates de disponibilité des équipes pour réserver le jour qui nous convient le mieux.

On choisit aussi par l’interface les Oracle Home et les bases.

L’inconvénient rencontré est que la configuration remontée par la gateway en terme de versions d’Oracle Home installée et de bases de données était incomplète, voire incorrecte.
Pour le choix des éléments à inclure, cela ne facilite pas la tâche.
Pas d’inquiétude, cela peut être reprécisé ensuite une fois la SR automatiquement générée.
Cela n’a pas été immédiat, mais après quelques échanges avec le coordinateur, nous nous sommes mis d’accord sur les éléments.
Sauf pour la version cible de la couche Grid Infrastructure qui était restée sur une simple mise à jour à la version du patch (180417) et non pas à une nouvelle installation et donc une migration en version 12.2, mais cela nous ne nous en apercevrons que plus tard…

Cette SR est très importante car c’est elle qui va servir pour toute la coordination et le passage d’informations avec les équipes Platinum.
Elle contient au départ le cadre de l’opération :

• La configuration de votre Exadata
• Les versions des logiciels cible pour chaque composant
• La liste des Oracle Home à mettre à jour (traitement de seulement deux Oracle Home par Platinum)
• Pour ces Oracle Home, la liste des bases de données (limitées à 20 bases de données, quel que soit le nombre d’Oracle Home)
• Les spécificités du site : comme l’utilisation ou non de Dataguard, la présence d’OJVM dans les bases, une connexion avec un ZFS, etc.
• La durée estimée du temps de patching
• La date de planification de l’opération

L’étape suivante est de fournir, quatre semaines avant la date prévue, le résultat d’un exacheck de l’Exadata.
Là, nous nous sommes ratés, notre SR étant générée 2 mois avant la date, et cette date étant au milieu de la période des congés, la demande d’upload de l’exacheck, réitérée par Platinum, n’a pas été traitée en temps et en heure.
Et ce, malgré la répétition de leur demande 3 semaines de suite.
Heureusement, nous avons pu leur fournir une semaine avant et il n’y a pas eu de report de l’opération.

Pour éviter des mauvaises surprises, je conseille, et nous l’avons réalisé, de faire avant Platinum les mêmes precheck.
Pour cela, il faut télécharger complètement la distribution du QFSD, la pousser sur les serveurs de bases de données des Exadatas et réaliser les opérations :

• Precheck de la mise à jour de l’infiniband, permet de voir si pas de problème de configuration (ssh entre autres)
• Precheck des cellules, rarement en échec, permet de se rassurer.
• Precheck YUM serveurs des bases de données, très important car génère la liste des rpms incompatibles qu’il faut supprimer (et donc réinstaller ensuite)
• Précheck des « bundle patch », Grid Infrastructure, permet de vérifier la compatibilité des nouveaux patchs avec l’existant, intéressant mais sera traité par Platinum normalement

L’exacheck déclenche chez eux la génération de deux éléments.

Le premier appelé le « Patch Assesment » est une synthèse du résultat de l’analyse des informations remontées par l’exacheck et dont la partie la plus importante est le paragraphe 5.2.1 : « Are there any issues in exachk that will prevent patching: YES ». Si YES est inscrit en rouge, vous avez des actions importantes à faire avant l’opération de patching.

Ce n’est cependant pas toujours pertinent, nous avions un superbe « YES » en rouge mais en fait les conditions détectées étaient soient liées à des bases de données hors scope du patching soit sur des conditions de versions qui seront corrigées par ce patching. Si une action est absolument nécessaire , vous serez informé directement dans la SR.

Le deuxième élément, qu’ils peuvent générer un peu plus tard, mais normalement pas moins deux semaines avant l’opération, est le plan de patch, fichier Excel à multiples onglets dont le plus important à vérifier dans le cadre du mode ROLLING est l’onglet « Comm Plan », normalement de couleur bleu : il est la référence pour le déroulement des actions par Platinum et sera intégré dans le mail de communication avec l’opérateur.

Les étapes cruciales pour vous sont les étapes où ils s’arrêtent d’agir et attendent votre validation pour la suite, dans notre cadre le plan résumé, fourni par notre faute seulement la veille de l’opération, était le suivant :

• Attente validation du départ par le client
• Prepatch, reboot dbnode1
• Application Bundle Patches sur GI Home et DBHOME dbnode1
• YUM update dbnode1
• Attente validation client pour la suite (« Pause for customer activities (node) »)
• Prepatch, reboot dbnode2
• Application Bundle Patches sur GI Home et DBHOME dbnode2
• YUM update dbnode2
• Attente validation client pour la suite (« Pause for customer activities (node) »)
• Passage des scripts de postinstallation sur les bases (catbundle dans notre cas)
• Prepatch, reboot des cellules
• Application patch cell01
• Application patch cell02
• Application patch cell03
• Application patch sur switchs infiniband

Pour la partie mise à jour de la couche Grid Infrastructure, il nous a fallu batailler pour que Platinum veuille bien l’inclure à l’opération, car ce n’était plus présent dans le cadre décrit de la SR (d’où la nécessité de préparer plus en amont les choses ! une semaine avant, ce n’est pas suffisant, le plan est livré trop tard).
Finalement, quelques heures avant l’opération, Platinum nous a fourni un document détaillé, là aussi sous forme Excel, où toutes les étapes à réaliser sont décrites (ce document est en fait une reprise de la note MOS 2111010.1 « 12.2 Grid Infrastructure and Database Upgrade steps for Exadata Database Machine running 11.2.0.3 and later on Oracle Linux ».

Ce qui donnait, pour la suite de leur plan, quelque chose du style :

• Attente validation client pour la suite (« Pause for customer activities (node) »)
• Préparation nouveau répertoire Grid Home
• Installation Grid infrastructure avec l’interface graphique des binaires 12.2 sur les deux serveurs
• Application rootupgrade.sh sur le premier serveur
• Attente validation client pour la suite (« Pause for customer activities (node) »)
• Application rootupgrade.sh pour le second serveur
• Actions post install GI
• Action fin patching (Exacheck)
• Fin de l’opération

Donc, tout cela, ce sont les opérations réalisées par Platinum, mais de notre côté, il nous a fallu créer notre propre plan pour :

• Arrêter les instances sur le dbnode1
• Faire basculer sur le dbnode2 toutes les ressources ($U, HAIP utilisée pour les montages Samba des partitions ACFS)
• Supprimer du serveur dbnode1 les rpms gênants pour le YUM d’Oracle
• Valider le bon fonctionnement des applications lorsque seul le serveur dbnode2 est opérationnel. Là, cela c’est mal passé car nous étions déjà en limite mémoire et il a fallu stopper les instances des bases de qualification et de formation en cours sur le serveur dbnode 2
• Donner le GO suite des actions sur le serveur dbnode 1 à Platinum
• Attendre la fin de la fin des actions de Platinum sur le serveur dbnode1
• Remettre les RPMs précédemment supprimés sur le serveur dbnode1
• Valider le fonctionnement des programmes associés (Samba, $U)
• Valider le bon fonctionnement des instances sur le serveur dbnode1
• Arrêter les instances sur le dbdnode2
• Faire basculer sur le dbnode1 toutes les ressources ($U, HAIP utilisée pour les montages Samba des partitions ACFS)
• Supprimer du serveur dbnode2 les rpms gênants pour le YUM d’Oracle
• Arrêter les instances de qualification et de formation du serveur dbnode 1
• Valider le bon fonctionnement des applications lorsque seul le serveur dbnode1 est opérationnel.
• Donner le GO suite des actions sur le serveur dbnode 2 à Platinum
• Attendre la fin de la fin des actions de Platinum sur le serveur dbnode2
• Remettre les RPMs précédemment supprimés sur le serveur dbnode2
• Valider le fonctionnement des programmes associés (Samba, $U)

Là, nous devions être bien, et comme toutes les applications fonctionnaient correctement avec les bases du serveur dbnode 1, nous pensions être prêt pour que la suite soit faite par Platinum jusqu’à la fin de l’étape « Application rootupgrade.sh » sur le serveur dbnode 2.

La suite de notre plan étant:

• Attente fin opération rootupgrade.sh sur premier serveur (pour nous serveur dbnode 2)
• Valider le bon fonctionnement des instances sur le serveur dbnode2
• Faire basculer sur le dbnode2 toutes les ressources ($U, HAIP utilisée pour les montages Samba des partitions ACFS )
• Vérifier ou arrêter toutes les instances du serveur dbnode 1
• Valider le bon fonctionnement des applications alors que seuls les instances du serveur dbnode 2 (alors dans la nouvelle version 12.2 de la couche Grid Infrastructure) sont ouvertes.
• Donner le GO pour le passage de rootupgrade.sh sur le serveur dbnode 1
• Attendre la fin du passage de rootupgrade.sh sur le serveur dbnode 1
• Vérifier le bon fonctionnement des instances
• Vérifier le bon fonctionnement des applications avec les deux serveurs opérationnels
• Fin des opérations

Fier de cette chronologie, l’ensemble des acteurs concernés étant au courant des consignes, concernés et motivés, nous avons donc donné le GO à Platinum pour cette opération le mardi matin à 8h30.
Tout s’est très bien déroulé jusqu’à fin de l’étape « Application patch sur switch infiniband » et voici un tableau qui récapitule la durée de chacune des étapes :

Etape du plan	Acteur	Durée HH:MI
Pre-patch reboot of serveur dbnode1	Platinum	00:20
Apply Bundle Patches on dbnode1	Platinum	00:50
Apply YUM update on dbnode1	Platinum	02:15
Validation et bascule appli vers dbnode1	Client	02:45
Pre-patch reboot of serveur dbnode2	Platinum	00:10
Apply Bundle Patches on dbnode2	Platinum	00:30
Apply YUM update on dbnode2	Platinum	02:00
Validation et GO pour suite	Client	00:10
Post-Install scripts (catbundle/datapatch)	Platinum	00:15
Pre-patch reboot of all cells	Platinum	02:00
Apply Cell patch on cell01	Platinum	00:59
Apply Cell patch on cell02	Platinum	00:46
Apply Cell patch on cell03	Platinum	00:35
Apply Infiniband Patch	Platinum	01:29
Temps total	NA	15:04

Avec une durée d’à peine plus de 15h00, à 23h40 à l’horloge, cette partie là était terminée.

On pourrait s’améliorer sur le temps mis pour la première bascule, on est pas fier de nos 2h45, principalement lié à la recherche de la bonne version des rpms pour les librairies 32 bits de $U, qui aurait put être anticipé : Il faut que la version de la librairie 32 bits soit exactement la même que la version 64 bits installée pour Exadata.
Pour cela il faut aller chercher les rpms sur le répertoire yum public d’Oracle.

Pour la seconde partie de notre opération, je rappelle, la mise à niveau de la couche Grid Infrastructure, c’est là que commencent les difficultés.
A la fin du traitement des switchs infiniband, Platinum a demandé un GO pour la suite (non prévu) et la coordination n’a pas répondu de suite, le GO a été donné 1 heure plus tard, premier délai inutile, mais là encore, rien de grave.

A ce moment là (nous sommes vers 2h du matin) Platinum rencontre un problème pour l’installation des binaires de la couche Grid Infrastructure, mais il ne nous informe sur ce fait seulement 2 heures et 1/2 plus tard, au changement d’interlocuteur.
Pendant ce temps, nous étions en attente de nouvelles.
Platinum a résolu cette problématique au bout de 6h30 de recherches, une fois que nous leur avons donné une solution de contournement.
Le problème venait d’une fausse erreur survenant lors de la vérification des pré-requis,le problème était déjà survenu chez Oracle et référencé dans la note : « Grid Infratstructure Upgrade to 12.2.0.1 Reports Missing Patch 21255373 Even Though Patch Applied in Existing Grid Home (Doc ID 2280843.1) ».
Une des solutions préconisée étant de mettre la dernière version d’opatch, Platinum a perdu 1h à faire ce test, qui s’avérera négatif. Ils se débloqueront une fois que nous leur demanderons de tester en ignorant les preérequis :

"Have you try that ;
Workaround is to use 'gridSetup.sh -skipPrereqs' after verifying all other pre-requisites manually"

Il est déjà 8h00 le lendemain, soit déjà 24h00 passés sur l’opération.

Survient alors l’autre point de blocage : le script rootupgrade.sh doit s’exécuter en premier sur ce qui est considéré comme le premier nœud du cluster (celui sur lequel l’installation initiale a été faite) et pour nous c’est le serveur dbnode1 et non pas dbnode2 comme nous l’avions prévu. L’erreur est cette fois claire et juste :

2018/07/25 07:54:14 CLSRSC-504: The root script cannot proceed on this node dbnode02 until the current first-node operations have finished on the first node dbnode01.

Comme il est déjà 8h30 lorsque Platinum nous prévient, nous ne sommes plus dans un créneau possible pour l’arrêt des applications et nous devons donc tout préparer pour 12h30 :

• Démarrer les instances sur dbnode2
• Basculer les ressources sur dbnode2
• Arrêter les instances sur dbnode 1
• Valider que les applications fonctionnent toutes correctement (et relancer les serveurs si besoin) avec les bases sur dbnode2.

Le GO pour exécuter rootupgrade.sh sur le serveur dbnode1 est donné à 12h30 : 30 minutes après, le cluster de dbnode1 est opérationnel en version 12.2.

Nous anticipons toutes les opérations possibles de bascule et procédons au basculement des applications dans le flux sans attendre plus.
Après validation, le GO est donné à 15h30 pour le passage de rootupgrade.sh sur le serveur dbnode 2, suivi par les opérations post rootupgrade, comme la mise à jour de la base -MGMMT et les dernières vérifications.

A 17h00, l’opération est enfin terminée, soit près de 33h00 après le début de cette campagne.

Sans compter le déroulement de l’exacheck post opération et son analyse par Platinum.

Certes, l’impact sur les applications a été réduit, avec moins de 15 minutes d’indisponibilité pour les plus longues, mais ce fut rude pour les équipes en action.

 
Pour ceux qui n’auraient pas eu le courage de lire l’intégralité de l’article, voici la synthèse des points importants :

En amont :

• Ne pas oublier de fournir le résultat d’un exacheck 4 semaines avant l’opération
• Regarder aussi de près les résultats de l’exacheck pour se faire sa propre opinion
• Valider le cadre de l’opération le plus tôt possible (intégration de la mise à jour Grid Infrastructure)
• Télécharger l’ensemble du QFSD et faire le plus de prechecks possible pour anticiper les problèmes et les résoudre avant l’opération
• Vérifier l’espace disponible et agrandir si besoin les systèmes de fichiers, pour les répertoires Oracle Home (nouveau ou ancien) et le répertoire de dépôt des patchs (30Go pour Grid Home, 30 Go pour dépôt des patchs)
• Vérifier les points d’attente dans le plan de déroulement pour que les applications restent toujours opérationnelles (jamais d’arrêt de nœud avec des instances actives)
• Dans le plan de patch, prévoir qu’au moment du passage du script rootupgrade.sh (mise à jour Grid Infrastructure), le premier serveur (celui qui a servi pour la première installation, pour nous serveur dbnode 1) soit libre

Pendant le déroulement :

• Il y a un changement d’opérateur toutes les 8 heures, ne pas hésiter à reprécisez les phases de mise en attente.
• Prévoir plusieurs personnes pour le suivi, c’est une opération continue qui ne s’arrête pas la nuit
• En cas de flottement, généralement suite à un problème, demander rapidement les conditions d’erreurs (code d’erreur etc..) pour pouvoir faire votre propre analyse et éventuellement proposer vos solutions
• Faire un disable des instances sur le nœud qui va être traité (et donc redémarré), pour être certain de pouvoir décider à quel moment ces instances seront rendues disponibles

 
Voilà, l’histoire fut intense mais riche, je souhaite qu’elle vous ait un tant soit peu intéressé et qu’elle vous sera d’une certaine utilité.
Si toute cette complexité vous inquiète un peu, n’hésitez à nous demander de l’aide.