Auto arranque de OSW en RHEL5

Estos dias me ha tocado hacer un poco de troubleshotting en un RAC que sufre reinicios continuos.

Para ayudar en esta tarea he instalado OSWatcher de Oracle, como el reinicio es continuo tenia que habilitar el auto arranque de OSW en los runlevels de Linux, es un Red Hat Enterprise 5 y el rpm que proporciona Oracle de crear scripts de runlevels no funciona aparentemente aunque los mismos funcionan perfectamente en RHEL4.

Parece ser que es por requiretty de sudo (no es por OSW), el script de OSW ejecuta sudo -u $USER ……………….., al estar en la consola el auto arranque da este error:

sudo: sorry, you must have a tty to run sudo

es porque en RHEL 5 requieretty esta activado por defecto. Para quitarlo

visudo
comentar la linea “Defaults requiretty”

Despues de esto ya funciona el auto arranque de OSW

Bye Bye Stonith en Clusterware 11.2.0.2… no del todo

Como es sabido muchos software de Cluster implementan el algoritmo Stonith para situaciones de posibles Split Brain y fencing, Oracle Clusterware no es una excepcion tampoco el nuevo “Grid Infrastructure” de 11gR2 hasta la version 11.2.0.2.

Me consta desde hace ya casi 2 años hablando con un conocido de un foro un fabricante de equipamientos de Telco no estaba muy contento con la resolucion de Split Brain con Stonith en Oracle RAC y habian escalado su disconformidad a desarrollo de Oracle, argumentaban que en un nodo de RAC muchas veces hay mas aplicaciones corriendo y un fast reboot obliga a realizar un failover de todos los procesos del nodo, tienen su razon pero el algoritmo de Stonith no es nuevo y lleva funcionando muchisimo tiempo.

Oracle les hizo caso y en la 11.2.0.2 en vez del fencing por reboot introduce una funcionalidad denominado “reboot-less node fencing”, en vez de un fast reboot el Clusterware intenta en lo posible ejecutar shutdown de todos los recursos de Cluster del nodo problematico, los procesos de E/S son los primeros a ser terminados para evitar corrupcion de datos. En situaciones donde los recursos no terminan correctamente es cuando el Clusterware ejecutara un fast reboot o mediante el mecanismo “remote node-termination” con IPMI para reiniciar el nodo.

Una prueba para observar este comportamiento nuevo es tirar del cable del interconnect donde antes en un RAC de dos nodos siempre se reiniciaba el nodo 2 ahora ya no, simplemente se queda parado.