ORACLE 11.2.0.4 RAC Cluster not starting cssd with Cannot get GPnP profile
最近，处理一次oracle 11.2.0.4 rac cluster由于cssd无法启动，导致集群一个节点的CRS集群无法正常启动的故障。原本，计划变更是从ASM剔除磁盘，解除存储到数据库服务器的映射；磁盘已经成功从ASM剔除，也已经成功从存储解除到操作系统的映射，为了验证磁盘剔除是否对集群有影响，重启了集群两个节点，重启之后节点1能够成功启动CRS集群，但是节点2确启动不了cssd。于是，将盘从新映射到集群两台主机，但是并没有将其加入任何ASM磁盘组，然后再重启集群两台服务器，节点1能够启动集群，节点2第一次没有启动集群原因还是CSSD无法启动，但是手工清理集群进程后再次尝试启动集群成功。
由于变更目的是要将磁盘从主机端释放，于是再次unmap磁盘，重启两台服务器，重启之后尝试启动oracle集群，节点1最终成功启动集群，节点2依然无法启动cssd而集群无法启动，无论是整个CRS集群先启动节点2、还是后启动节点2，节点2都无法启动到正常状态。后来，仔细观察集群alert日志输出内容，还是提示gpnp profile无法获取到。报错内容如下：
--首先提示gpnp进程启动
2023-09-02 15:05:12.014: [ GPNP][2895390528]clsgpnp_Init: [at clsgpnp0.c:619] GPnP pid=91293, GPNP comp tracelevel=1, depcomp tracelevel=0, tl
src:ORA_DAEMON_LOGGING_LEVELS, apitl:0, complog:1, tstenv:0, devenv:0, envopt:0, flags=3
2023-09-02 15:05:12.017: [ GPNP][2895390528]clsgpnpkwf_initwfloc: [at clsgpnpkwf.c:399] Using FS Wallet Location : /u01/app/11.2.0/gpnp/rac11gn2/profiles/peer
--最终，集群日志提示gpnp由于获取不到gpnp profile没有运行
2023-09-02 15:05:12.025: [ default][2895390528]Cannot get GPnP profile. Error CLSGPNP_NO_DAEMON (GPNPD daemon is not running). 但是，分别查看报错提示路径下的gpnp profile，两个节点都是存在的。尝试使用gpnptool get也都能输出gpnp profile内容，对比两个节点gpnp profile文件内容也完全是一致的，包括使用scp方式将一个节点的gpnp profile传输到另外一个节点，然后diff对比也没有任何区别。
[grid@rac11gn1 peer]$ gpnptool get
Warning: some command line parameters were defaulted. Resulting command line:
/u01/app/11.2.0/bin/gpnptool.bin get -o-
l9tBwYqpzw5wzpzvAugvKkBi3xg= jQC6gEiuuVUIts8bvQmmfNGSA/A4zBWmIKiKqynYAdEfhAV1bN7wAsQqvGB9HOgrqeXspLFph6C6Xu8Kugt8oZLh5pOLrXCXT/4kK1cI/UX3224M9PkY13wtaG31joaIjxOAnhlyqnN11Oik865WNyonG0LuGPAhuW5eqQQ4uek= l9tBwYqpzw5wzpzvAugvKkBi3xg= jQC6gEiuuVUIts8bvQmmfNGSA/A4zBWmIKiKqynYAdEfhAV1bN7wAsQqvGB9HOgrqeXspLFph6C6Xu8Kugt8oZLh5pOLrXCXT/4kK1cI/UX3224M9PkY13wtaG31joaIjxOAnhlyqnN11Oik865WNyonG0LuGPAhuW5eqQQ4uek= 后来，认真观察两个节点的本地的gpnp profile目录，均存在pending.xml.
[grid@rac11gn1 peer]$ ll
total 16
-rw-r--r--. 1 grid oinstall 1876 Sep 3 09:32 pending.xml
-rw-r--r--. 1 grid oinstall 1946 Jul 26 08:11 profile.old
-rw-r--r--. 1 grid oinstall 1874 May 19 15:59 profile_orig.xml
-rw-r--r--. 1 grid oinstall 1876 Jul 26 08:24 profile.xml
[grid@rac11gn1 peer]$
[root@rac11gn2 peer]# ll
total 20
-rw-r--r--. 1 grid oinstall 1876 Sep 3 09:30 pending.xml
-rw-r--r--. 1 grid oinstall 1946 Aug 2 14:47 profile.old
-rw-r--r--. 1 grid oinstall 1874 May 19 16:08 profile_orig.xml
-rw-r--r--. 1 grid oinstall 1876 Aug 2 15:00 profile.xml
[root@rac11gn2 peer]#猜测rac集群两个节点虽然是都能读写，但是也存在主从节点之分。
[grid@rac11gn2 rac11gn2]$ oclumon manage -get master replica
Master = rac11gn2
Replica = rac11gn1
Done
[grid@rac11gn2 rac11gn2]$经过沟通，将节点2的pending.xml文件mv走，然后再次尝试重启crs集群，集群竟然很顺利的成功启动到正常状态。
后续测试，先停止两个节点的crs集群，两个节点的crs停止后，节点1的gpnp profile本地文件目录中原来就存在pending.xml文件；然后手工复制profile.xml一份作为节点2的pending.xml文件。然后，启动节点1的crs集群，能够成功启动到正常状态，再启动节点2的crs集群，也能成功启动到正常状态，但是，查询集群主节点发现是节点2，并且节点1的pending.xml文件被删除，节点2的gpnp profile文件目录中多了一份pending.old文件，原先的pending.xml文件时间戳发生变化。
[root@rac11gn2 peer]# ll
total 20
-rw-r--r--. 1 grid oinstall 1876 Sep 3 09:30 pending.old
-rw-r--r--. 1 grid oinstall 1876 Sep 3 09:30 pending.xml
-rw-r--r--. 1 grid oinstall 1946 Aug 2 14:47 profile.old
-rw-r--r--. 1 grid oinstall 1874 May 19 16:08 profile_orig.xml
-rw-r--r--. 1 grid oinstall 1876 Aug 2 15:00 profile.xml
[root@rac11gn2 peer]#测试中，如果关闭节点2的crs集群，pending.xml又会自动被清理掉；但是，节点1并没有生成pending.xml文件，但是节点1变成了master。
[root@rac11gn2 peer]# ll
total 16
-rw-r--r--. 1 grid oinstall 1876 Sep 3 09:30 pending.old
-rw-r--r--. 1 grid oinstall 1946 Aug 2 14:47 profile.old
-rw-r--r--. 1 grid oinstall 1874 May 19 16:08 profile_orig.xml
-rw-r--r--. 1 grid oinstall 1876 Aug 2 15:00 profile.xml
[root@rac11gn2 peer]#
[grid@rac11gn1 peer]$ oclumon manage -get master replica
Master = rac11gn1
Replica =
Done
[grid@rac11gn1 peer]$ 分析：可能是故障前，节点2是master，节点2的gpnp profile相关的pending.xml文件在主机reboot时没有被正常自动清理，后续启动集群先启动集群节点1，节点1启动后成为master并生成了pending.xml文件，再启动节点2的crs集群时，不自动生成新的pending.xml文件导致节点2的CRS集群无法启动。但是，在模拟测试时，该故障没有重现。然而，客户环境中，清理了节点2的pending.xml文件后却很顺利的启动了crs集群。