El parámetro CLUSTER_INTERCONNECTS

Oracle Real Application Clusters (Oracle RAC) es una versión en clúster de Oracle Database basada en una pila integral de alta disponibilidad que asegura escalabilidad y agilidad para cualquier aplicación.

Para que una base de datos con arquitectura de cluster funcione, debe de estar conectada entre sus nodos para mantener comunicación eficaz y sincronizada.

En el caso de un Oracle RAC, esta interconexión es administrada por el software de Oracle Clusterware. Oracle Clusterware es la base o los cimientos para la arquitectura de Oracle RAC. La comunicación entre nodos es una característica denominada CLUSTER INTERCONNECT.

La función principal de esta red (privada: solo visible entre los nodos del cluster) es mantener un “Heartbeat” entre ellos y el cluster en general, en este caso Oracle Clusterware, mediante el cual cada uno de los nodos informara su estado y disposición dentro del cluster. En caso de falla de comunicación Oracle Clusterware tomara las medidas pertinentes para rehabilitar el nodo fallido. Medidas que no analizaremos en este artículo. 

Figura 1: Diagrama Cluster Interconnect

El requerimiento mínimo para la construcción de la red privada (CLUSTER INTERCONNECT) en un cluster de Oracle es una interfaz de red y una ip v4 (por cada nodo). Sin embargo, ante la necesidad de alta disponibilidad no nos podemos dar el lujo de utilizar una sola interfaz física.

Como se muestra en la Figura 1, una o más interfaces pueden, en conjunto, trabajar como la red de interconnect en un cluster, a esta característica la denominaremos REDUNDANT INTERCONNECT.

Esta característica un grupo de interfaces e ip’s conforman un grupo redundante que soporta cierta tolerancia a fallos, evitando depender de una sola interfaz física para la intercomunicación entre nodos.

En versiones anteriores a Clusterware 11.2.02 la redundancia de redes privadas debía ser satisfecha mediante tecnología de terceros, ajenas a Oracle.

Como ejemplos de este tipo de tecnologías puedo mencionar:

• ·         IPMP GROUPS en sistemas operativos UNIX
• ·         Link aggregation bonding en sistemas operativos LINUX

Existe un riesgo en utilizar este tipo de tecnologías y es el punto clave de este artículo: El parámetro CLUSTER_INTERCONNECTS.

Para la descripción del problema voy a citar el documento ID 957531.1 de Metalink: Health Check Alert: If using IPMP for private interconnect, consider setting CLUSTER_INTERCONNECTS

Riesgo de utilización de tecnologías de terceros: cuando se utilizan tecnologías de este tipo para renuncia de redes de interconnect el parámetro CLUSTER_INTERCONNECTS debe ser configurado con el objetivo de que Oracle Clusterware reconozca las interfaces agrupadas como una sola entidad.

Recomendación: no existe problema con utilizar redundancia de redes mediante tecnologías del sistema operativo anfitrión, siempre y cuando Oracle Clusterware este enterado de esta configuración. El parámetro CLUSTER_INTERCONNECTS debe estar configurado hacia la IP física asignada al grupo IPMP o LAB (según los ejemplos que planteaba anteriormente). De esta manera garantizamos la alta disponibilidad ante fallas físicas de alguna de las interfaces que conforman el grupo y el balanceo de carga entre los integrantes.

A continuación les presento el problema puntual que tuve y el porqué de este artículo:

Agregaba una nueva base de datos RAC en un cluster que ya manejaba al menos otras 5 bases de datos.

La instalación del software de base de datos (12c) ocurrió sin ningún problema a través de los 3 nodos. La configuración de la base de datos vía DBCA detecto cada uno de los nodos y todas las características fueron establecidas: sistema de archivos, características de idioma, esquema etcétera.

El problema fue al final de la creación de la base de datos, las instancias fueron creadas pero no lograron iniciar todas. Algunas presentaban el error:

PRCR-1079: Failed to start resource ora.rhsa.db CRS-5017: The resource action "ora.rhsa.db start" encountered the following error: ORA-031113: end-of-file on communication channel

Después de mucho investigar el error y varias pruebas de instalación fallidas encontré que el error podía deberse a configuración de red privada. El archivo ALERT de la base de datos confirmaba mi teoría:

No connectivity to other instances in the cluster during startup. Hence, LMON is terminating the instance. Please check the LMON trace file for details. Also, please check the network logs of this instance along with clusterwide network health for problems and then re-start this instance. LMON (ospid: 1539): terminating the instance Fri Aug 19 14:55:43 2016 Instance terminated by LMON, pid = 1539

El proceso LMON mantiene la integración entre instancias dentro de una base de datos RAC y parecía que las instancias no podían comunicarse entre sí.

Mi punto de análisis paso entonces a las redes privadas, el sistema operativo era Solaris 10 y, como se lo imaginaban, utilizaban IPMP para la redundancia entre redes de interconnect.

Dos interfaces físicas conformaban el grupo IPMP1 dentro de cada nodo:

ipmp1: flags=108001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,IPMP,PHYSRUNNING> mtu 1500 index 5         inet 172.17.233.46 netmask ffffffe0 broadcast 172.17.233.63         groupname ipmp1 net3: flags=100009040943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,PHYSRUNNING> mtu 1500 index 6         inet 172.17.233.44 netmask ffffffe0 broadcast 172.17.233.63         groupname ipmp1 net5: flags=100009040943<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,PHYSRUNNING> mtu 1500 index 8         inet 172.17.233.42 netmask ffffffe0 broadcast 172.17.233.63         groupname ipmp1

Solución:

La solución al problema fue entonces definir el parámetro CLUSTER_INTERCONNECTS en cada una de las instancias del nodo del cluster.

Debido al problema, solamente podía tener una de las instancias corriendo al mismo tiempo. Por suerte CLUSTER_INTERCONNECTS es un parámetro estático y requiere ser modificado en el SPFILE, que en bases de datos RAC es compartido por todas las instancias:

SQL> alter system set cluster_interconnects='172.17.233.45' scope=spfile sid='RHSA1'; System altered. SQL> alter system set cluster_interconnects='172.17.233.46' scope=spfile sid='RHSA2'; System altered. SQL> alter system set cluster_interconnects='172.17.233.59' scope=spfile sid='RHSA3'; System altered.

Después de modificar el parámetro en cada una de las instancias. Basto con reiniciar la única que tenía encendida e iniciar las otras dos que estaban apagadas. El problema fue resuelto y todas las instancias corren ahora al mismo tiempo.

Conclusiones:

A partir de la versión 11.2.0.2 de GRID INFRASTRUCTURE se añadió la característica “Cluster Interconnect Link Aggregation (HAIP)” que permite redundancia entre redes privadas sin necesidad de tecnologías de terceros por lo que es totalmente recomendable utilizar esta característica antes de recurrir a características de sistema operativo.

La característica REDUNDANT INTECRONNECT utilizando tecnologías de terceros es totalmente soportado por Oracle Clusterware, siempre y cuando el parámetro CLUSTER_INTERCONNECTS sea establecido para evitar confusión entre la red interna.

El error a veces es desconocer las características que nos ofrece la tecnología Oracle y optamos por utilizar soluciones que podrían acarrearnos problemas frustrantes e innecesarios.

En mi siguiente articulo voy a mostrar como configurar esta característica en una base de datos RAC 12c.

Además recomiendo leer el artículo informativo: Oracle Clusterware 12c, New Features dentro del blog.

   

Hasta pronto,