[WEBINARđź’»] NIS 2 en action : StratĂ©gies et solutions pour une cyber-rĂ©silience renforcĂ©e ! Le replay est disponible dès maintenant🎙!

✖︎
Digora blog

SOS DIGORA : Mon Cluster Oracle RAC devient fou...

09/12/2011
Données

La mise en oeuvre de Clusters, qu'ils soient de type actif/passif (ex. HACMP) ou actif/actif (ex. Oracle RAC) a pour but  d'améliorer la disponibilité d'une base. Mais parfois, c'est le contraire. Une société utilisant Oracle RAC nous appelle au secours. Leur Cluster Oracle RAC est devenu complètement instable :  les noeuds du Cluster arrêtent et redémarrent aléatoirement à tour de rôle. Très génant et même insupportable... Pourquoi ? Comment rétablir la fiabilité reconnue d'Oracle RAC ? Quel résultat final ?

1. Le contexte Le client nous a contacté fin Juin 2011 pour des problèmes d'instabilité sur son RAC de production composé de 3 noeuds sous Windows 2003 x86-64. Ce cluster héberge 15 bases de données dont certaines sont critiques pour son activité métier.

Les problèmes ont été détectés au travers de blocages de certaines applications. L’architecture du Cluster utilise également un partage OCFS pour l’hébergement des fichiers communs aux 3 nœuds : Sauvegardes, datapump, etc.
  2. L'analyse du problème DIGORA envoie un de ses meilleurs consultants investiguer...
La première étape d’analyse a montré qu’aléatoirement, un nœud perdait le contact avec les autres nœuds, puis rebootait et enfin était réintégré dans le cluster. Ne voyant rien d’autre lors de l’audit, nous préconisons l’analyse du réseau pour vérifier les conflits etc...
Courant Août, les choses s’accélèrent car cette fois ci, tout le cluster est planté et les reboots unitaires de nœuds n’y font rien. Seul un redémarrage de tous les nœuds du cluster semble redonner une once de stabilité au cluster mais avec une indisponibilité de plate-forme non-acceptable.
La criticité est élevée car l’indisponibilité de certaines applications peut entraîner des problèmes graves sur les équipements gérés par les applications. Le problème est suivi au niveau du préfet de région et de différents ministères. Nous intervenons donc en urgence en déployant tous les moyens nécessaires pour résoudre le problème.
La première analyse montre que, lorsqu’on arrête ou démarre une instance du cluster, les files d’attentes I/O sont très rapidement saturées notamment sur le volume OCFS. L’analyse au niveau de la baie EMC ne donne pas de saturation particulière.
L’analyse OCFS montre que tout le transit réseau d’intercommunication est en fait positionné sur le lien public. Ensuite nous nous apercevons que l’ensemble des fichiers de trace des instances a été modifié pour être écrit sur le volume OCFS.
Nous décidons donc de faire retour arrière sur le stockage de ces fichiers et de reconfigurer OCFS … le cluster ne se bloque plus et le feu est éteint au plus haut niveau, nous enchaînons alors sur une recherche des « root-causes » du problème.
La suite des analyses montre plusieurs choses :
  • Les adresses IPs des cartes agrĂ©gĂ©es et utilisĂ©es pour les rĂ©seaux public et privĂ©es se voient assigner des adresses MAC diffĂ©rentes.
  • Perfmon montre un rĂ©seau public saturĂ© alors que les cartes rĂ©seau travaillent Ă  hauteur de 5 – 10% de leur capacitĂ©. Rien Ă  signaler cĂ´tĂ© rĂ©seau privĂ©.
Le prestataire réseau ne trouvant aucun problème (!!!), notre expert remplace sa casquette DBA par sa casquette d’analyste réseau avec l’aide de deux collègues et une analyse poussée de la configuration débute.
  • Pour le problème d’adressage MAC, nous nous rendons compte que l’agrĂ©gation utilisĂ©e est en mode ACTIF/ACTIF avec chaque NIC connectĂ© Ă  un switch distinct du cĹ“ur de rĂ©seau. Il n’y a donc pas d’agrĂ©gation de lien configurĂ©e cĂ´tĂ© switch, il est donc tout Ă  fait « normal » que des IP se voient assignĂ©es des MACs diffĂ©rentes au travers des nĹ“uds. Nous conseillons donc au client de passer en mode actif/passif (les switchs du cĹ“ur de rĂ©seau n’étant pas capable de rĂ©aliser la virtualisation de port  sans upgrade du firmware)
  • Pour la saturation des liens, nous avons rĂ©alisĂ© des dumps  de chaque carte rĂ©seau (avec des analyseurs de trames rĂ©seau). Sous nos yeux Ă©bahis, on se rend compte que tout le flux http de la sociĂ©tĂ© passe par les interfaces du Cluster. (On ne trouvait que peu de traces partant ou Ă©tant destinĂ© Ă  l’interface Ă©coutĂ©e. De nombreux paquets en TCP out-of-order ou TCP Dup ACK Ă©taient dĂ©tectĂ©s Ă©galement)
Les interfaces sont donc rapidement saturées mais Windows (hors perfmon) ne voyant que le trafic lui étant destiné nous donne 5 à 10% d’utilisation. De plus, il apparait que ce phénomène affecte toutes les machines ayant une carte réseau configurée sur le VLAN dédié au serveur.

 

3. L'explication

Le client a alors diligenté une analyse de son proxy ISA qui a conclu à un problème de configuration NLB (http://www.labo-microsoft.org/articles/win/nlb/2/).
Les résultats de cette correction ont donné un abaissement important de la charge réseau sur le VLAN Serveur.

 

4. Les schémas Voici quelques schémas liés à cette opération : Schématisation de la situation instable de la configuration NLB Légende des différents réseaux Schématisation de la situation stabilisée de la configuration NLB   Schématisation de la situation corrigée de la configuration NLB  

 

5. Le bilan

Le Cluster RAC est désormais stable sans reboot inopiné.  Oracle RAC n'était pas en cause, mais c'était la configuration réseau.
DIGORA a  prouvé sa capacité à diagnostiquer une anomalie sérieuse dans l'infrastructure utilisée par son client.