Retrouvez-nous le 14/04 pour notre Webinar "Quelle démarche pour votre stratégie de gestion de données ?". Je m'inscris

✖︎
Digora blog

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

09/12/2011
A trier

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 :

 

 

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.