Cardinalidad en ASM – Veo más instancias de las que tengo

Últimamente solo ocurren fenómenos extraños. El mundo del clusterware, grid infrastructure y dataguard me va a dar unos cuantos dolores de cabeza. Unos más prolongados, otros más severos y fáciles de mitigar.
En esta ocasión, hemos tenido algunos problemillas de configuración en uno de los clústeres (que ya os contaré más adelante). Tras haber solucionado y reestablecido el clúster y comprobar que funcionaba ya todo correctamente, nos sorprende que en lugar de aparecer dos instancias (dos nodos en el clúster) aparece una tercera, pero no muestra información.
Pues… parece ser que no está todo tan bien como pensábamos. ¿A qué es debido esto? ¿Por qué ocurre?
¿Alguna vez has oído hablar sobre la CARDINALIDAD en ASM?
Te cuento un poco la teoría, qué nos ha pasado, y cómo lo hemos solucionado. ⤵️
Contexto
Este clúster es de dos nodos. El segundo no se instaló correctamente. Si consultábamos el clúster solo reconocía el servidor1, pero ni rastro del servidor2. Si hacíamos la consulta desde el servidor2, el clúster no respondía.
Intentamos añadirlo, pero nos decía que ya formaba parte del clúster, a pesar de que la información del clúster no lo reflejaba. Por este motivo, tuvimos que eliminar el nodo del clúster, y una vez finalizada esta tarea, volver a incluir el nodo en el clúster.
El Problema
Tras haber eliminado y añadido el nodo al clúster correctamente, partimos de este escenario.
Como se puede observar, al consultar los recursos, vemos que los recursos locales están bien, pero hay algunos recursos de clúster que tienen tres entradas en lugar de dos.
Lo especialmente extraño, es que en la tercera entrada no aparece el nombre del servidor donde está ubicado.
También podemos fijarnos en que los recursos que tienen tres entradas son los dedicados a ASM.
[grid@servidor1 ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.LISTENER.lsnr
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.chad
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.net1.network
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.ons
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.proxy_advm
OFFLINE OFFLINE servidor1 STABLE
OFFLINE OFFLINE servidor2 STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)
1 ONLINE ONLINE servidor1 STABLE
2 ONLINE ONLINE servidor2 STABLE
3 ONLINE OFFLINE STABLE
ora.GRID.dg(ora.asmgroup)
1 ONLINE ONLINE servidor1 STABLE
2 ONLINE ONLINE servidor2 STABLE
3 OFFLINE OFFLINE STABLE
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE servidor2 STABLE
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE servidor1 STABLE
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE servidor1 STABLE
ora.asm(ora.asmgroup)
1 ONLINE ONLINE servidor1 Started,STABLE
2 ONLINE ONLINE servidor2 Started,STABLE
3 OFFLINE OFFLINE STABLE
ora.asmnet1.asmnetwork(ora.asmgroup)
1 ONLINE ONLINE servidor1 STABLE
2 ONLINE ONLINE servidor2 STABLE
3 ONLINE OFFLINE STABLE
ora.cvu
1 ONLINE ONLINE servidor1 STABLE
ora.qosmserver
1 OFFLINE OFFLINE STABLE
ora.scan1.vip
1 ONLINE ONLINE servidor2 STABLE
ora.scan2.vip
1 ONLINE ONLINE servidor1 STABLE
ora.scan3.vip
1 ONLINE ONLINE servidor1 STABLE
ora.servidor1.vip
1 ONLINE ONLINE servidor1 STABLE
ora.servidor2.vip
1 ONLINE ONLINE servidor2 STABLE
--------------------------------------------------------------------------------
Consultamos los nodos de nuestro clúster, por si obtenemos alguna información extra.
Lo vamos a hacer con el comando olsnodes añadiendo los siguientes parámetros:
- -n: Muestra el numero del nodo junto al nombre
- -s: Muestra el estado. Activo o inactivo.
- -a: Muestra los roles de los nodos activos en el clúster.
[grid@servidor1 ~]$ olsnodes -n -s -a
servidor1 1 Active Hub
servidor2 2 Active Hub
Ni rastro de qué puede ser la tercera entrada que aparece. El olsnodes no la reconoce y no aparece reflejado como un tercer nodo dentro del clúster.
La Teoría
¿Qué es eso de la cardinalidad?
Si consultamos la documentación de Oracle, aparece una definición de una función de SQL.
CARDINALIDAD: Devuelve el número de elementos en una tabla anidada. El tipo de dato que retorna es NUMBER.
Y… ¿Qué es la cardinalidad aplicada a ASM?
No he encontrado una definición clara en la documentación, porque solo aparece el termino de cardinalidad cuando hablamos de FLEX ASM. Pero interpretando la documentación, allá va mi definición:
CARDINALIDAD EN ASM: Número de instancias ASM que se ejecutan en un mismo clúster.
Causa del Problema
Como comentaba al inicio contextualizando esta situación, este clúster es de dos nodos y todo viene provocado por la mala instalación de uno de ellos.
Revisando todos los logs que me he encontrado, encontré el de la ejecución del script root.sh de la configuración del clúster. Este log muestra lo siguiente:
[grid@servidor2 ~]$ cat /app/oracle/grid/product/19.0.0/install/root_servidor2_2024-12-16_10-26-38-677610542.log
Performing root user operation.
The following environment variables are set as:
ORACLE_OWNER= grid
ORACLE_HOME= /app/oracle/grid/product/19.0.0
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Relinking oracle with rac_on option
Smartmatch is deprecated at /app/oracle/grid/product/19.0.0/crs/install/crsupgrade.pm line 6512.
Using configuration parameter file: /app/oracle/grid/product/19.0.0/crs/install/crsconfig_params
The log of current session can be found at:
/app/oracle/grid/orabase/crsdata/servidor2/crsconfig/rootcrs_servidor2_2024-12-16_10-26-52AM.log
2024/12/16 10:26:57 CLSRSC-594: Executing installation step 1 of 19: 'ValidateEnv'.
2024/12/16 10:26:57 CLSRSC-363: User ignored prerequisites during installation
2024/12/16 10:26:57 CLSRSC-594: Executing installation step 2 of 19: 'CheckFirstNode'.
2024/12/16 10:27:03 CLSRSC-504: The root script cannot proceed on this node servidor2 until the current first-node operations have finished on the first node servidor1.
Died at /app/oracle/grid/product/19.0.0/crs/install/crsutils.pm line 4881.
La causa raíz de este problema es la ejecución del script root.sh al mismo tiempo en el servidor1 y servidor2.
Cuando realizamos la instalación en modo silencioso, y somos nosotros los que ejecutamos los scripts de root manualmente, se nos indica lo siguiente:
Como usuario raíz, ejecute los siguientes scripts:
1. /app/oracle/grid/product/19.0.0/root.sh
Ejecute /app/oracle/grid/product/19.0.0/root.sh en los siguientes nodos:
[servidor1, servidor2]
Ejecute el script en el nodo local primero. Cuando haya terminado, puede iniciar el script en paralelo en el resto de los nodos.
Es por este motivo que el nodo aparecía como parte del clúster, pero sin estarlo.
La operativa a seguir fue eliminar el nodo del clúster y posteriormente añadir el nodo al clúster nuevamente.
Después de este problema, fijandome en el log del proceso de añadir nodo al clúster, encontré esto:
2025-02-10 12:31:06: ASM cardinality is: 2
2025-02-10 12:31:06: modify ASM cardinality to 3 during add node of servidor2
2025-02-10 12:31:06: Invoking "/app/oracle/grid/product/19.0.0/bin/srvctl modify asm -count 3"
2025-02-10 12:31:06: trace file=/app/oracle/grid/orabase/crsdata/servidor2/crsconfig/srvmcfg6.log
2025-02-10 12:31:06: Running as user grid: /app/oracle/grid/product/19.0.0/bin/srvctl modify asm -count 3
A pesar de que habíamos eliminado el servidor2 del clúster, ese proceso no había modificado la cardinalidad del ASM. Pero al añadir un nuevo nodo, sí que suma siempre ese nuevo nodo a la cardinalidad como una nueva instancia ASM.
La Solución
Leyendo las notas del apartado documentación, se indica que es un comportamiento esperado después de eliminar/añadir nodos al clúster. Siempre y cuando el nodo esté eliminado, no hay ningún riesgo en modificar la cardinalidad manualmente.
Por ejemplo si el clúster es de cuatro nodos y eliminamos dos, cuando consultaramos los recursos de clúster, los recursos de ASM aparecerían con cuatro entradas, aunque ya hay dos que se han eliminado.
Para solucionarlo, hay que ejecutar el siguiente comando, estableciendo el -count en el número total de instancias ASM que tenemos en el clúster. En nuestro caso, tenemos dos servidores y dos instancias ASM.
[grid@servidor1 ~]$ srvctl modify asm -count 2
[grid@servidor1 ~]$
Este comando no da ninguna respuesta. Por lo tanto, consultamos de nuevo el clúster, para revisar qué ha cambiado tras este comando, y verificamos que ya se muestra correctamente nuestro clúster.
[grid@servidor1 ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.LISTENER.lsnr
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.chad
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.net1.network
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.ons
ONLINE ONLINE servidor1 STABLE
ONLINE ONLINE servidor2 STABLE
ora.proxy_advm
OFFLINE OFFLINE servidor1 STABLE
OFFLINE OFFLINE servidor2 STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)
1 ONLINE ONLINE servidor1 STABLE
2 ONLINE ONLINE servidor2 STABLE
ora.GRID.dg(ora.asmgroup)
1 ONLINE ONLINE servidor1 STABLE
2 ONLINE ONLINE servidor2 STABLE
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE servidor2 STABLE
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE servidor1 STABLE
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE servidor1 STABLE
ora.asm(ora.asmgroup)
1 ONLINE ONLINE servidor1 Started,STABLE
2 ONLINE ONLINE servidor2 Started,STABLE
ora.asmnet1.asmnetwork(ora.asmgroup)
1 ONLINE ONLINE servidor1 STABLE
2 ONLINE ONLINE servidor2 STABLE
ora.cvu
1 ONLINE ONLINE servidor1 STABLE
ora.qosmserver
1 ONLINE ONLINE servidor2 STABLE
ora.scan1.vip
1 ONLINE ONLINE servidor2 STABLE
ora.scan2.vip
1 ONLINE ONLINE servidor1 STABLE
ora.scan3.vip
1 ONLINE ONLINE servidor1 STABLE
ora.servidor1.vip
1 ONLINE ONLINE servidor1 STABLE
ora.servidor2.vip
1 ONLINE ONLINE servidor2 STABLE
--------------------------------------------------------------------------------
Esto ha sido el final de un largo camino con este clúster. Después de todos los problemas que ha dado, cuando «parecía» que ya estaba resuelto, apareció este error tonto de la cardinalidad, que bueno, es relativamente fácil de solucionar, siempre y cuando sepas lo que está ocurriendo.
En las siguientes te cuento más errores de este clúster. 😉