Gpnp(grid plug and play)守护进程是11gR2中新增的进程，它的资源名称是ora.gpnpd。
Why 为什么会有这个新的守护进程呢？
在11g之前，集群启动的时候，ORACLE要从OCR中读取所有的配置信息，而OCR是存放在共享存储中的，如果某一个节点不能访问共享存储，那么这个节点就不能加入集群，这会带来很多问题。
从11gR2开始，GI把集群的配置信息本地化，引入OLR，gpnp profile。这样一来，即使OCR出现了问题，那么仅仅是由CRSD管理的资源会跟着倒霉，而cssd层面仍然可以正常运行。
也就是说有了gpnp，ORACLE在启动集群的时候，不再完全依赖OCR，而且gpnp通过和mdns通信，与远程节点同步gpnp profile，如此就能更灵活的识别集群中的信息，不需要读OCR来获取节点列表和节点的配置信息。
gpnp由两部分组成，gpnp wallet和gpnp profile
Gpnp wallet保留了需要访问gpnp profile文件的客户签名信息，只有通过验证的用户才能访问gpnp profile文件。
Gpnp profile是一个XML文件，用于存放构建集群的bootstrap 信息，也就是保存集群节点启动时的必要信息。其中包括集群名称，集群GUID, ASM discovery string, 公网和私网信息等等。所以，当我们在启动集群的某一个节点时，需要读取这个文件从而获得构建集群的基本信息(比如ocssd.bin)。
ORACLE使用守护进程gpnpd.bin来维护gpnp profile，该守护进程的资源名为ora.gpnpd,而gpnpd由ohasd 的oraagent 负责管理,gpnpd通过gpnp 的wallet文件验证后读取gpnp prfofile，如果gpnpd读取本地gpnp profile文件失败，它会尝试从OLR中取得相应的信息来重建gpnp profile。当集群的配置发生改变，如果有必要的话，gpnpd还会修改gpnp profile。
我们可以使用gpnptool来获取gpnp profile文件的内容。如果gpnp profile中的信息出现了错误导致系统异常，也可以使用gpnptool工具来修正。
Profilesequence表示gpnp profile的序列号，该文件每产生一次变动，profilesequence就会增加1，序列号最大的gpnp profile文件是最新的。
Clusterid表示集群的global id,从oracle 12c开始，GI通过ClusterID来唯一标识一个集群，这个cluster id是安装GI时随机产生的，不可以手动更改。
Gpnp:network id=net1表示集群的公网信息,use区分网络用途，用途只能是public或者cluster_interconnect。
Gpnp:network id=net2表示集群私网信息。
Orcl:css-profile表示这部分信息是css需要使用的，discovery表示表决磁盘的保存路径，cssd启动时会到该路径下扫描表决盘，leaseduration定义了节点号的租借有效期。
Orcl:asm-profile表示这部分信息是asm需要使用的,spfile指定了asm实例启动时需要访问的spfile位置。
Gpnpd守护进程的工作原理
首先gpnp是一个多线程进程，这些线程包括：主线程、push线程、派遣线程、OCR线程。
下面分别介绍这4个线程
主线程(clsgpnpd_mainwork)，该进程完成主要的工作，访问gpnp profile。
Push线程(clsgpnpd_pushthread)，当本地gpnp profile发生变化，该进程会向远程节点推送新的gpnp profile，负责传输。
派遣线程(clsgpnpd_dispatchthread)，接受gpnpd守护进程收到的消息，并分派到对应的线程。
OCR线程(clsgpnpd_ocrdetectthread)，OCR发生变化，该线程发现并通知派遣线程。
因为gpnp profile保存的是整个集群的基本信息，所以集群中每个节点上的gpnp profile内容应当一致。当某一个节点配置信息发生变动，本地OCR线程发现并通知派遣线程，派遣线程给远程节点的派遣线程发送通知，告知他们配置信息发生变化，接着push线程将gpnp profile发送到远程节点，远程节点的派遣线程接受gpnp profile从而保证每个节点的gpnp profile文件相同。
举个例子，一个双节点的集群，其中节点2无法启动，在此期间，集群的私网配置发生了改变，当节点2可以启动时，节点2的gpnpd进程需要和其他节点的gpnpd进程通信，获得最新版本的gpnp profile。
当gpnp因故障无法启动，通常我们需要检查几点：
1. Gpnpd 的pid 文件是否存在？是否可以被访问？
2. mdnsd 是否启动？
3. gpnp 的wallet 文件是否存在？gpnp profile是否能够被grid 用户访问？
4. 两个节点之间的网络连接是否正常？
5. 其他节点的gpnpd.bin 是否正常？因为，在启动本地gpnpd.bin之后，它需要和集群其他节点的gpnpd.bin进行通信，以便确认集群中最新的gpnp profile。
怎么查？从哪儿查？
1. gpnpd.log记录gpnpd 是否被启动，启动过程到了哪一步，问题是在哪一步出现的。
2. crsctl stat res –t -init查看ora.gpnpd资源的状态。
3. 如果问题出现在mdns无法发现集群中的其他节点，mdnsd.log会记录相关信息。
4. OSW 报告记录了OS当时的负载状况&集群网络统计信息。
