Troubleshoot: CRS-2304 GPnP profile signature verification failed.
En el artículo previo les comenté que estoy desarrollando un proyecto de upgrade de Oracle Database Server 11.2 a 19c, y luego de corregir el problema de permisos, todo parecía estar en orden.
El primer paso era tener las bases de datos operando con Oracle 11.2, y fue en ese momento que llamó mi atención un mensaje de error en los archivos alert.log.
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 2
Number of processor cores in the system is 2
Number of processor sockets in the system is 1
2024-10-06 09:50:16.306:
[USER(21480)]CRS-2304:GPnP profile signature verification failed. get-profile request aborted.
WARNING: No cluster interconnect has been specified. Depending on
the communication driver configured Oracle cluster traffic
may be directed to the public interface of this machine.
Oracle recommends that RAC clustered databases be configured
with a private interconnect for enhanced security and
performance.
Picked latch-free SCN scheme 3
. . .
pga_aggregate_target = 128M
diagnostic_dest = "/u01/app/oracle"
Cluster communication is configured to use the following interface(s) for this instance
192.168.0.61
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2Al iniciar la instancia no se lograba obtener los datos de la red a usar para el interconnect, por lo que Oracle optaba por usar la red pública para dicho fin.
Esto no impedía que la base de datos levantara, pero definitivamente era una situación irregular con la que no me había encontrado en proyectos previos.
El problema
Empecemos por recordar que en todo Cluster Oracle se cuenta con 2 redes: una pública y una privada (interconnect), con usos y propiedades diferenciadas.
En el archivo de alerta se registra el uso de la dirección 192.168.1.61 para fines de interconnect, cuando debiera ser la dirección 169.254.13.3, lo cual es comprobable al consultar v$cluster_interconnects.
SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
--------------- -------------------- --------- ----------------------------------------
eth1 192.168.0.61 OS dependent software
Primer intento
| 3004140.1 | Oracle Server Processes Terminated By Fatal Error ORA-27504 In 11.2 DB Managed By 19c GI Cluster |
En él se nos indica que este problema se presenta cuando una base de datos Oracle RAC 11.2 opera bajo Oracle Grid 19c, ya que bajo esa combinación la instancia Oracle 11.2 no logra validar el profile de GPnP 19c (Grid Plug and Play), siendo necesario aplicar el parche 32967645.
Desafortunadamente se requiere de Upgrade Support (antes Market Driven Support) para descargarlo.
Se menciona también que existe un workaround, que consiste en fijar manualmente las direcciones usando el parámetro cluster_interconnects, para cada instancia.
Si bien suena tentador, no parece ser la solución definitiva, después de todo este problema no se me había presentado antes en proyectos similares.
¿Qué tiene de diferente esta instalación?
Segundo intento
Afortunadamente en My Oracle Support existe este documento:
| 2985244.1 | GPNP reports gpnp call get-profile got invalid profile error |
Allí se indica que debido a «requerimientos internos del equipo de seguridad», se ha actualizado el algoritmo usado para verificar el profile de GPnP, desde Oracle 19.16.
Este dato resuelve nuestra interrogante: esta instalación ha nacido directamente con Oracle 19.24, por tanto está sujeta el nuevo algoritmo, y esto impide a las instancias 11.2 poder obtener el dato de la dirección para interconnect.
En la misma nota se presenta un procedimiento a seguir para actualizar manualmente el algoritmo, pues para instalaciones previas a 19.16 está en uso el algoritmo antiguo e inseguro y es recomendado actualizarlo al algoritmo nuevo y seguro.
Pero nuestro caso es distinto, ya tenemos el nuevo algoritmo en uso y deseamos regresar al algoritmo antiguo. ¿Será posible? Probemos.
Por lo indicado en la nota, el nuevo algoritmo es sha512, y revisando una instalación antigua se encuentra que el algoritmo previo es sha1. ¡He allí la discrepancia que nos ha traído hasta acá!
export GI_HOME=/u01/app/grid/19.0.0/grid_1
-- obtener secuencia actual del profile
[oracle@node1 ~]$ gpnptool getpval -prf_sq \
-p=${GI_HOME}/gpnp/node1/profiles/peer/profile.xml
5
-- incrementar la secuencia en 5
[oracle@node1 ~]$ gpnptool edit -prf_sq=10 \
-p=${GI_HOME}/gpnp/node1/profiles/peer/profile.xml \
-o=/tmp/profile_sqenum.xml
-- firmar el profile con el algoritmo antiguo (sha1)
[oracle@node1 ~]$ gpnptool sign -a=sha1 \
-p=/tmp/profile_sqenum.xml -o=/tmp/profile_signed.xml
Warning: sha1 algorithm is deprecated.
-- publicar el profile en todos los nodos
[oracle@node1 ~]$ gpnptool put -p=/tmp/profile_signed.xmlSi bien al firmar el profile se nos da la advertencia de que se está usando un algoritmo obsoleto, sí completa el pedido.
Procedemos a reiniciar la instancia 11.2 y comprobamos que ya no hay mensajes de error en el archivo alert.log.
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 2
Number of processor cores in the system is 2
Number of processor sockets in the system is 1
Private Interface 'eth2:1' configured from GPnP for use as a private interconnect.
[name='eth2:1', type=1, ip=169.254.13.3, mac=08-00-27-25-2a-76, net=169.254.0.0/19, mask=255.255.224.0, use=haip:cluster_interconnect/62]
Public Interface 'eth1' configured from GPnP for use as a public interface.
[name='eth1', type=1, ip=192.168.0.61, mac=08-00-27-7f-71-2e, net=192.168.0.0/24, mask=255.255.255.0, use=public/1]
Public Interface 'eth1:1' configured from GPnP for use as a public interface.
[name='eth1:1', type=1, ip=192.168.0.66, mac=08-00-27-7f-71-2e, net=192.168.0.0/24, mask=255.255.255.0, use=public/1]
Public Interface 'eth1:2' configured from GPnP for use as a public interface.
[name='eth1:2', type=1, ip=192.168.0.65, mac=08-00-27-7f-71-2e, net=192.168.0.0/24, mask=255.255.255.0, use=public/1]
Public Interface 'eth1:3' configured from GPnP for use as a public interface.
[name='eth1:3', type=1, ip=192.168.0.67, mac=08-00-27-7f-71-2e, net=192.168.0.0/24, mask=255.255.255.0, use=public/1]
Public Interface 'eth1:4' configured from GPnP for use as a public interface.
[name='eth1:4', type=1, ip=192.168.0.63, mac=08-00-27-7f-71-2e, net=192.168.0.0/24, mask=255.255.255.0, use=public/1]
Public Interface 'eth1:5' configured from GPnP for use as a public interface.
[name='eth1:5', type=1, ip=192.168.0.64, mac=08-00-27-7f-71-2e, net=192.168.0.0/24, mask=255.255.255.0, use=public/1]
Picked latch-free SCN scheme 3
. . .
db_unique_name = "db112"
open_cursors = 300
pga_aggregate_target = 128M
diagnostic_dest = "/u01/app/oracle"
Cluster communication is configured to use the following interface(s) for this instance
169.254.13.3
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2Se observa que las direcciones de la red pública y de la red privada son reconocidas correctamente, y lo verificamos también en v$cluster_interconnects.
SQL> select * from v$cluster_interconnects;
NAME IP_ADDRESS IS_PUBLIC SOURCE
--------------- -------------------- --------- ------------------------------
eth2:1 169.254.13.3 NOEl caso está finalmente resuelto, afortunadamente se encontró una solución que nos evitó tener que pagar soporte adicional para descargar parches, ni fijar parámetros de instancia!