Mettre à jour les serveurs Linux dans un cluster RAC

En théorie, vous pouvez mettre à jour les noyaux Linux sur les serveurs d’un cluster Real Application Clusters (RAC). Cette opération peut être réalisée un noeud après l’autre et donc, si l’application gère proprement les disconnexions, sans aucune indisponibilité. En pratique, il vaut mieux planifier cette opération avec soin. Les raisons sont multiples. Vous trouverez quelques exemples ci-après.

Oracle Cluster Filesystem (OCFS2) et ASMLib

Oracle Cluster Filesystem est un système de fichiers en cluster. Il peut être téléchargé depuis le site d’Oracle. Il est régulièrement mis en oeuvre avec RAC. C’est, en dehors des raw devices et avant l’utilisation d’Oracle Storage Manager (ASM), la première solution pour stocker une base de données RAC sur un SAN. OCFS2 est encore aujourd’hui obligatoire pour faire du RAC avec SAP. C’est aussi très utilisé si vous faîtes des sauvegardes disques et que vous n’avez pas de NAS.

ASMLib est une interface standard sur les devices qui peut être utilisée pour monter les disques ASM. Oracle fournit une implémentation d’ASMLib sur Suse et Redhat. ASMLib est inclus dans le package Oracle EL.

OCFS2 et ASMLib peuvent généralement être mis à jour séparément sur chacun des noeuds d’un cluster. C’est évidemment le cas d’ASMLib puisqu’il ne s’agit que d’une interface et que le logiciel n’intéragit pas d’un serveur à un autre en dehors des données stockées dans les entêtes des disques. Pour OCFS2, la réponse est un peu plus subtile. La section “File system Compatibility” du guide utilisateur OCFS2 indique qu’à partir de la version 1.4, le protocole supporte théoriquement les “rolling” upgrades. Toutefois, lisez bien le release notes et faîtes des tests avant toute mise à jour de vos systèmes de production.

Quoiqu’il en soit OCFS2 et ASMLib sont des modules intégrés au noyau Linux et tout changement de noyau, même mineur, nécessite de mettre à jour chacun des 2 packages installés. Si vous ne le faites pas, la punition peut aller de (1) ASM ou OCFS ne redémarrent pas à (2) des corruptions de données.

D’ailleurs, un des avantages d’Oracle Unbreakable Linux Network (ULN) sur le Redhat Network (en plus du fait que c’est moins cher!) est surement que les packages OCFS2 et ASMLib y sont disponibles dans le référentiel ce qui évite des erreurs lourdes de conséquences en plus d’accélérer et de simplifier les mises à jour.

Noyaux, RPMs et GRUB

Le fait de gérer les packages OCFS2 et ASMLib n’est pas le seul problème que vous pouvez rencontrer lors d’une mise à jour; vous pouvez :

• Rencontrer des problèmes sur d’autres packages installés sur votre Linux. C’est particulièrement le cas pour les drivers des cartes HBA. dans ce cas, faire un upgrade n’aura pas un forcément le résultat escompté
• Rencontrer des problèmes sur le noyau lui même. Par exemple, si vous utilisez les drivers du noyau, en changer, peut nécessité de changer le noyau. Dans d’autres cas, vous aurez changé les options du noyau et en changer pourra rendre obsolete ces changements
• Rencontrer des problèmes lors du redémarrage du serveur; Il ne faut pas négliger le paramètrage de la configuration du “bootloader”. Dans le cas de GRUB par exemple, changer le noyaux change la configuration du fichier /boot/grub/grub.conf. Ca peut sembler un détail mais vérifiez que vous utiliser le bon noyau après le reboot.

Si vous effectuez des mises à jour régulières, planifiez-les donc avec soin et surtout testez le reboot du serveur; C’est toujours mieux de s’assurer que ça marche plutôt que de découvrir un problème lors de l’éviction d’un serveur.

Une procédure de mise à jour…

Vous trouverez donc ci-dessous une procédure pour effectuer la mise à jour de vos environnements Linux. Si vous avez beaucoup de serveurs, comme c’est parfois le cas, effectuez les opérations sur vos environnements de tests et automatisez les sur les autres serveurs dans vos fenêtres de maintenance.

La procédure de mise à jour pourra ressembler à celle-ci:

• Réaliser la mise à jour serveur par serveur; commencer par un premier serveur.
• Revoir la procédure d’installation du cluster RAC et vérifier que tous les packages nécessaires sont disponibles. Vérifier en particulier ASMLib, OCFS2, les drivers HBA, la solution de multipathing, l’image du noyau, etc…
• Arrêter et désactiver le cluster ainsi que l’ensemble des logiciels Oracle; assurez-vous que la VIP est basculée sur un autre serveur.
• Effectuer la mise à jour de l’OS et des packages associés
• Mettre à jour les packages Oracle comme ASMLib et OCFS2 pour qu’ils fonctionnent après l’application des patchs et le reboot
• Vérifiez le menu de configuration du “bootloader”, e.g. /boot/grub/grub.conf.
• Rebooter le serveur.
• Avant de redémarrer les composants Oracle, valider que les différents composants fonctionnent toujours
• Redémarrer le clusterware et les logiciels Oracle
• Continuer avec les serveurs suivants

En conclusion, vous serez peut-être intéressés d’apprendre qu’Oracle supporte, pour quelques heures, la mise à jour de Linux d’un Redhat à une autre version de Redhat ou d’un Redhat à Oracle EL, par exemple. Pour la référence, consultez la documenation qui suit:”Oracle® Clusterware Installation Guide 11g Release 1 (11.1) for Linux“; Voici l’extrait qui vous intéressera:

Note:
Using mixed operating system versions is only supported for the duration of an upgrade, over the period of a few hours. Oracle does not support operating a cluster with mixed operating systems for an extended period.