编者按：
本文作者系肖遥（花名），现任甲骨文技术支持工程师 ，目前专注于Oracle RAC领域。个人主页:
https://blog.csdn.net/weixin_50510978，经其本人授权发布。
【免责声明】本公众号文章仅代表个人观点，与任何公司无关。
懒惰了一周没有更新博客。这两天天气不好，索性利用今天下午的时间继续写一篇关于OHAS组件的介绍。
之前我们多次提到了OHAS组件是GI的根守护进程。这个组件是在GI 11.2版本中引入的。随着这个组件的引入，集群的启动方式和资源管理方式发生了根本的改变。
我们先来看一下OHASD启动了哪些进程。
从上图中，我们可以看到OLR(Oracle Local Registry)。从英文全称可以知道，这是一个注册表信息。是为OHASD提供集群配置信息和初始化资源的定义信息。OLR 存在于本地磁盘上，我们可以通过 etc/oracle/olr.loc 文件获得 OLR 文件的位置信息。OLR文件是个二进制文件不可读。我们可以通过以下命令来生成一个OLR的转储文件，该文件是可读的。
[root@node1 ~]# ocrdump -local复制
从转储文件的内容我们可以知道OLR文件配置了诸如GI home，集群版本，HAIP等信息。
在这里我想介绍一下我比较感兴趣的部分就是集群版本信息的内容。我们先来查看一下OLR关于版本信息的记录。
[SYSTEM.version.localhost.patchlevel]UB4 (10) : 724960844SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}...[SYSTEM.version.activeversion]ORATEXT : 19.0.0.0.0SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}复制
从上面的内容我们可以看到patchlevel的信息和activeversion的信息。
我们知道在解决节点间patch不一致的问题的时候经常会用到以下命令。
kfod op=patchlvlcrsctl query crs releasepatchcrsctl query crs softwarepatchcrsctl query crs activeversion复制
我们在我的测试环境中来分别执行以上命令。
[root@node1 ~]# kfod op=patchlvl-------------------Current Patch level===================724960844[root@node1 ~]# crsctl query crs releasepatchOracle Clusterware release patch level is [724960844] and the complete list of patches [29401763 29517242 29517247 29585399 ] have been applied on the local node. The release patch string is [19.3.0.0.0].[root@node1 ~]# crsctl query crs softwarepatchOracle Clusterware patch level on node node1 is [724960844].[root@node1 ~]# crsctl query crs activeversionOracle Clusterware active version on the cluster is [19.0.0.0.0]复制
当打补丁的时候，首先需要将补丁信息更新到OLR中，在所有节点完成补丁安装后会在最后一个节点将补丁信息更新到OCR中。只有当各个节点的OLR中的补丁版本信息与和OCR中的一致的时候，补丁安装才算成功，集群才会正常启动。一旦出现patchlevel不一致的情况，就需要通过以上命令收集补丁信息，如果能够通过rollback补丁修复的则需要rollback掉所有节点的问题补丁。有一些极端情况可能无法修复时，需要重新安装GI软件。
关于OLR的备份和恢复的方法，我们这里只给出命令。
ocrconfig -local -manualbackupocrconfig -local -restore<OLR备份文件>复制
我们从上图可以看到，OHASD分别启动了3个代理进程和1个cssdmonitor资源。
从cssdagent这个代理进程的名字，我们就能猜测到这个代理进程是用来管理CSS组件的进程。而cssdmonitor这个资源的作用也正如其名字所表示的那样，它是用来监控CSS组件的。我们在以后介绍脑裂的部分会进一步说明cssdagent和cssdmonitor的作用，这里不做展开讨论。
接下来我们来看一下orarootagent管理的资源有哪些。
这里面的osysmond和ologgerd进程实际上是ora.crf资源的进程。osysmond收集OS的资源信息，ologgerd则是负责将osysmond收集到的信息写入GIMR中。从12.1开始引入了MGMTDB这个资源，GIMR数据文件则被存储在了MGMTDB中。在解决集群问题时，必不可少的是要收集OS的资源使用信息，所以甲骨文推荐安装使用OSwatcher工具。但有些环境确实没有安装任何监控OS资源信息的工具，这时候我们可以借助ora.crf收集到的信息调查故障。但是这里需要说明的是，ora.crf收集的信息只是对OSwatcher工具的一个补充，其涵盖的信息无法取代OSwatcher收集的信息。比如我们在调查是否是CPU问题导致集群夯的问题时，只是查看ora.crf收集到的信息有时是不够的。因为OS调度CPU时也是存在bug的。比如 vmstat 的 r列 显示了很高的数值，代表排队等待执行的进程数很多，但是 mpstat 却显示很多CPU处于闲置状态，这说明OS并没有正确调度CPU去处理这些待执行的进程。类似这种信息是无法从ora.crf中确认到的。所以甲骨文依然推荐安装使用OSwatcher。
orarootagent还管理CRS组件，这部分内容我们会找个专题去介绍CRSD，这里不做展开。
从上图中我们可以看到diskmon和ACFS Drivers的内容。diskmon是与Exadata相关的资源，我们这里不做研究。ACFS Drivers则是与Storage相关的内容，我们以后会专题介绍。
这里面还有一个CTSS(Cluster Time Synchronize Service)组件。它是负责同步集群节点时间的组件。GI管理的集群作为一个整体对外服务，需要集群内的各个计算机的时间是同步的。因为集群各节点时间无法同步时，可能出现数据库实例可能发生hang或者crash的现象。
在11.2版本之前，GI是没有自己的时间同步的机制的，那时候甲骨文一直依赖OS的NTP等机制。到了11.2之后，甲骨文开发了自己的时间同步机制CTSS。CTSS兼容了NTP等第三方软件，其工作原理如下:
[root@node1 ~]# crsctl stat res ora.ctssd -t -init--------------------------------------------------------------------------------Name Target State Server State details--------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.ctssd1 ONLINE ONLINE node1 OBSERVER,STABLE--------------------------------------------------------------------------------复制
另外上图中并没有标记出来，其实orarootagent还会启动一个非常重要的资源就是HAIP。HAIP提供了私网的高可用和负载均衡。主要负责节点间数据库实例的数据传输，也就是我们所熟知的内存融合。关于HAIP的内容会在以后的私网通信的部分详细说明。
接下来我们来看oraagent管理的资源。
gipcd的内容会结合HAIP的内容在以后的博客中比对说明，请各位持续关注。ASM的内容则是集群极为重要的一大块内容，会专门找时间分多个主题介绍。
接下来我们主要介绍一下关于gpnp(Grid Plug And Play)组件的内容。
gpnp存在的主要目的是为了将集群的一些基本配置信息保存至本地，从而减轻对OCR的功能依赖。
gpnp主要有两个部分构成，分别是gpnp wallet 和gpnp profile。他们分别保存在以下路径下。
{GI_HOME}/gpnp/wallets/peer/cwallet.sso{GI_HOME}/gpnp/profiles/peer/profile.xml复制
GPNP的profile文件中配置了以下主要信息:
关于GPNP的profile信息，我们可以通过以下命令获得。
[root@node1 ~]# gpnptool get -o- | xmllint --format -Success.<?xml version="1.0" encoding="UTF-8"?><gpnp:GPnP-Profile xmlns="http://www.grid-pnp.org/2005/11/gpnp-profile" xmlns:gpnp="http://www.grid-pnp.org/2005/11/gpnp-profie" xmlns:orcl="http://www.oracle.com/gpnp/2005/11/gpnp-profile" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Version=1.0" xsi:schemaLocation="http://www.grid-pnp.org/2005/11/gpnp-profile gpnp-profile.xsd" ProfileSequence="5" ClusterUId="f99ec5bb231ff76ffde27244f2ba4dd" ClusterName="node-cluster" PALocation=""><gpnp:Network-Profile><gpnp:HostNetwork id="gen" HostName="*"><gpnp:Network id="net1" IP="10.10.3.0" Adapter="enp0s8" Use="public"/><gpnp:Network id="net2" IP="192.168.3.0" Adapter="enp0s9" Use="asm,cluster_interconnect"/></gpnp:HostNetwork></gpnp:Network-Profile><orcl:CSS-Profile id="css" DiscoveryString="+asm" LeaseDuration="400"/><orcl:ASM-Profile id="asm" DiscoveryString="/u02/storage/*" SPFile="+DATA/node-cluster/ASMPARAMETERFILE/registry.253.101087503" Mode="remote" Extended="false"/><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="gpnp orcl xsi"/></ds:Transform></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>oVBrQvB4b2NuXOY6pBfE+zeLfTk=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>bFF73cqarX+fmHFWeeC5oSXy6m01+m7LuOWj4TO+69fPkVaDu9BblcMoUbb2Mkhhv5iOIjZwaD7Eb9DN3WZajO1NoPq/BYqZJGpw9JPEifQSlEBtOLbPupYAidt4EPecv6jSaXkl2hhNCsMvZ6aWInrSQOp1lWGu1hEu7wYjHE=</ds:SignatureValue></ds:Signature></gpnp:GPnP-Profile>复制
通过上面的信息我们知道，我的测试环境的ClusterName是"node-cluster"。公网网卡是enp0s8，而私网网卡则是enp0s9。而ASM实例的spfile则保存在+DATA磁盘组上。
gpnp的主线程会扫描profile文件，并将内容加载到内存中。
gpnp会向所有节点发送信息，并确认最新版本，并将拥有最新版本的配置信息发送到各个节点。
关于GI的内容实在太杂太多了，不管谈到哪里都可以继续向下引申很多内容。我时刻告诉自己要适可而止，初衷只是归纳基础知识。接下来打算写一篇关于OCSSD的内容，期待各位继续支持。
后续文章更加精彩，欢迎关注本公众号或访问【阅读原文】。
——End——
专注于技术不限于技术！
用碎片化的时间，一点一滴地提高数据库技术和个人能力。
欢迎关注！
数据库基础系列（从基础了解数据库）：
通过寄存服务来“理解”Oracle数据库基本体系结构和动作流程
浅谈RAC系列：
