您的位置：首页 > 数据库 > Oracle

[Oracle 11g r2(11.2.0.4.0)]集群资源管理

2017-10-13 10:55 656 查看

对于10g版本，资源管理工作由CRS来完成。

可以通过crs_stat -t -v来查看CRS管理的资源：

根据上面的输出，可以看到CRSD会管理以下资源：

. VIP 资源( ora. ＜节点名＞.vip）。

. ONS资源（ora. ＜节点名＞.ons）。

. GSD资源（ora. ＜节点名＞.gsd）。

. ASM实例资源（ora.. ASM＜节点编号＞.asm）。

. 监昕程序资源（ora. ＜节点名＞．＜监听程序名＞.lsnr）。

. 数据库资源（ora. ＜数据库名＞.db）。

. 数据库实例资源（ora. ＜数据库名＞．＜实例名＞. inst）。

. 数据库服务资源（ ora. ＜数据库名〉．〈服务名＞.cs 和 ora. ＜数据库名＞．＜服务名〉．＜实

例名＞.srv）。

介绍了CRSD 需要管理的资源列表之后，来看一下CRSD是如何实现资源管理的。首先介绍一些资源相关的术语。

1. 动作（Action）：动作定义了CRSD对资源进行启动、停止、检查和清除操作时所需要运行的步骤，它可以是一段shell脚本、一段应用程序、数据库命令等。

2. 资源概要文件（profile）：概要文件定义了资源的很多属性，以便CRSD能够根据概要文件定义的属性来创建资源。例如：检查间隔、动作脚本等。

3. 依赖关系（ Dependency）：资源之间并不是独立的，有些资源之间是存在互相依赖关系的。例如：数据库实例启动的前提是ASM实例先要被启动，这表示数据库实例资源需要依赖于ASM实例资源，而这种依赖关系是通过资源属性REQUIRED_RESOURCES来实现的。

4. 权限：由于不同的资源需要执行的操作也是不同的，这意味着执行操作的用户也会不同（主要是root和Oracle用户）所以，每个资源都会针对不同的用户指定不同的权限。这也是为什么crsd.bin守护进程需要以root用户运行的原因之一。

Oracle集群管理软件（CRS）还定义了一些racg模块，不同的racg模块负责管理不同的资源，例如：racgvip负责管理VIP，这些模块负责定义对资源操作的动作。看到这里，读者对CRSD管理资源的方法应该有了比较清晰的认识，基本上可以将这些方法总结为以下的两点：

第一点：CRSD通过OCR定义资源。当crsd.bin守护进程启动时，通过读取OCR中的信息来获得资源定义。而当资源属性发生改变时，crsd.bin守护进程也会修改OCR中的信息。

第二点：CRSD通过调用racg模块来实现对资源的各种动作。

对于 11gr2版本，ohasd 变成了集群启动的唯一始点。而所有的其他守护进程和集群管理的资源统统被定义为资源，例如： cssd 守护进程就以初始化资源ora.cssd 的形式存在，而obasd 守护进程负责管理集群所有的守护进程对应的资源。

同时，集群管理软件（GI) 不再使用racg 模块来管理资源，而是用代理进程（agent）统一实现对所有资源的管理。

既然一切都变成了资源，那么和10g 版本类似，就需要有一个注册表来保存资源的属性。OCR 是用于保存CRSD 所管理的资源的注册表，但是在CRSD 启动之前集群还有很多初始化资源（例如asm 实例）需要启动，所以只有OCR 是不够的。Oracle 在11gR2 版本中推出了另一个集群注册表OLR ( Oracle Local regist）。

(1) OLR

顾名思义， OLR 是保存在本地的集群注册表，也就是说OLR 是保存在每个节点本地的，而且其中的信息大部分是针对每个节点的。OLR 的主要作用就是为ohasd 守护进程提供集群的配置信息和初始化资源的定义信息。当集群启动时ohasd 会从／etc/oracle/olr.loc 文件（不同平台，文件位置会不同）中读取OLR 的位置， OLR 默认保存在＜gi home>/cdata 下，文件名为＜节点名＞.olr 。

[root@node1 bin]# more /etc/oracle/olr.loc
olrconfig_loc=/u01/app/11.2.0/grid/cdata/node1.olr
crs_home=/u01/app/11.2.0/grid

接下来看一下OLR信息，OLR信息需要通过ocrdump来产生一个转存储文件才能查看

[grid@node1.localdomain$]ls -l /u01/app/11.2.0/grid/cdata/node1.olr
-rw------- 1 root oinstall 272756736 Oct 13 09:18 /u01/app/11.2.0/grid/cdata/node1.olr

ocrdump使用方法：

[grid@node1.localdomain$]ocrdump -help
Name:
ocrdump - Dump contents of Oracle Cluster/Local Registry to a file.

Synopsis:
ocrdump [-local] [<filename>|-stdout] [-backupfile <backupfilename>] [-keyname <keyname>] [-xml] [-noheader]

Description:
Default filename is OCRDUMPFILE. Examples are:

prompt> ocrdump
writes cluster registry contents to OCRDUMPFILE in the current directory

prompt> ocrdump MYFILE
writes cluster registry contents to MYFILE in the current directory

prompt> ocrdump -stdout -keyname SYSTEM
writes the subtree of SYSTEM in the cluster registry to stdout

prompt> ocrdump -local -stdout -xml
writes local registry contents to stdout in xml format

prompt> ocrdump -backupfile /oracle/CRSHOME/backup.ocr -stdout -xml
writes registry contents in the backup file to stdout in xml format

Notes:
The header information will be retrieved based on best effort basis.
A log file will be created in
$ORACLE_HOME/log/<hostname>/client/ocrdump_<pid>.log. Make sure
you have file creation privileges in the above directory before
running this tool.
Use option '-local' to indicate that the operation is to be performed on the Oracle Local Registry.

转存储LCR文件：

ocrdump -local

[SYSTEM]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.crs]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.crs.usersecurity]
ORATEXT : 1
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.crs.deny]
ORATEXT :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.crs.user_default_dir]
ORATEXT : /u01/app/11.2.0/grid/ohasd/public
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.ORA_CRS_HOME]
ORATEXT : /u01/app/11.2.0/grid
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.WALLET]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_CREATE_SUB_KEY, OTHER_PERMISSION : PROCR_CREATE_SUB_KEY, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.GNS]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.version]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.version.localhost]
ORATEXT : 11.2.0.4.0
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.version.activeversion]
ORATEXT : 11.2.0.4.0
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

[SYSTEM.GPnP]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.GPnP.profiles]
BYTESTREAM (16) :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.GPnP.profiles.peer]
UNDEF :
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

从上面可以看出，OLR文件结构跟OCR文件相同。另外olr的备份策略和ocr不同，默认情况下在GI安装路径下< gi_home>/cdata/<节点>下产生一个备份。

[grid@node1.localdomain$]ls -l /u01/app/11.2.0/grid/cdata/node1
total 6628
-rw------- 1 root root 6787072 Oct 12 12:59 backup_20171012_125920.olr

olr不会自动备份，需要手动进行备份

ocrconfig 使用方法：

[grid@node1.localdomain$]ocrconfig -help
Name:
ocrconfig - Configuration tool for Oracle Cluster/Local Registry.

Synopsis:
ocrconfig [option]
option:
[-local] -export <filename>
- Export OCR/OLR contents to a file
[-local] -import <filename>         - Import OCR/OLR contents from a file
[-local] -upgrade [<user> [<group>]]
- Upgrade OCR from previous version
-downgrade [-version <version string>]
- Downgrade OCR to the specified version
[-local] -backuploc <dirname>       - Configure OCR/OLR backup location
[-local] -showbackup [auto|manual]  - Show OCR/OLR backup information
[-local] -manualbackup              - Perform OCR/OLR backup
[-local] -restore <filename>        - Restore OCR/OLR from physical backup
-replace <current filename> -replacement <new filename>
- Replace an OCR device or file <current filename> with <new filename>
-add <filename>                     - Add a new OCR device/file
-delete <filename>                  - Remove a OCR device/file
-overwrite                          - Overwrite OCR configuration on disk
-repair -add <filename> | -delete <filename> | -replace <current filename> -replacement <new filename>
- Repair OCR configuration on the local node
-help                               - Print out this help information

Note:
* A log file will be created in
$ORACLE_HOME/log/<hostname>/client/ocrconfig_<pid>.log. Please ensure
you have file creation privileges in the above directory before
running this tool.
* Only -local -showbackup [manual] is supported.
* Use option '-local' to indicate that the operation is to be performed on the Oracle Local Registry.

olr手动备份（建议在集群配置信息改变之后手动进行备份）：

./ocrconfig -local -manualbackup

[root@node1 bin]# ./ocrconfig -local -manualbackup

node1     2017/10/13 13:02:26     /u01/app/11.2.0/grid/cdata/node1/backup_20171013_130226.olr

node1     2017/10/12 12:59:20     /u01/app/11.2.0/grid/cdata/node1/backup_20171012_125920.olr

当olr丢失后，可以使用命令“./ocrconfig -local olr_backupset”,不能从其他节点复制过来充当本地olr。

如果想验证olr文件一致性，可以使用：

./ocrcheck -local

所有适用于OCR的命令同样可以使用在olr文件上，但是必须得加上 -local参数。

集群在ohasd层面的启动过程是：首先，／etc/inittab中的init.ohasd脚本被调用，之后该脚本启动 ohasd.bin守护进程；然后ohasd.bin启动对应的代理进程，每个代理进程负责启动自己管理的集群初始化资源，即对应资源的初始化进程被启动。

ohasd管理的资源

在此对ohasd所管理的集群初始化资源进行介绍，其中，包括HAIP和CHM。

1. HAIP

对于Oracle集群，私网通信是非常重要的，因为节点和节点之间的通信绝大部分都是要通过私网来实现的。

私网通信基本上可以分为两种：

第一种是集群层面之间的通信；

第二种是数据库实例之间的通信。

第一种通信（例如：节点间的网络心跳）的主要特点是持续存在、实时性要求高，但是数据量比较小，所以通过TCP/IP协议传递就可以了。

而第二种通信，也就是读者所熟知的内存融合造成的实例之间的数据传输的特点是数据量很大，而且速度要求非常高，TCP/IP协议此时已经不能满足Oracle的要求了，所以需要使用UDP 或者RDS，同时Oracle也一直建议用户对集群的私网进行高可用性和负载均衡的配置。

对于IOg和llgRI

版本的集群，Oracle并不提供私网的高可用性和负载均衡特性，而从11.2.0.2版本开始，Oracle提供了私网的高可用性和负载均衡特性一－HAIP。

首先，用户需要在安装GI的过程中为集群的私网指定多块网卡。

HAIP顾名思义就是一个（或多个）IP地址。Oracle会自动在集群的每一块私网网卡上绑定一个169.254.XX.XX 网段的IP地址，这个IP地址被称为HAIP，数据库实例（ASM 实例也同样适用）之间在进行通信时，会通过这个Oracle绑定的IP地址来完成。

当某一块私网网卡出现问题时，对应网卡上绑定的IP地址可以漂移到其他的私网网卡上，这就实现了私网的高可用性。从另一个角度来讲，如果集群包含了多块私网，也就意味着会有多个HAIP 被绑定在每一块私网网卡上，每一块网卡都同时承担实例之间的通信，从而实现了私网通信的负载均衡。Oracle在启动集群时会自动把HAIP绑定到网卡上。

node1:

eth1:1    Link encap:Ethernet  HWaddr 00:0C:29:BE:F6:A5
inet addr:169.254.2.113  Bcast:169.254.255.255  Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

node2:

eth1:1    Link encap:Ethernet  HWaddr 00:0C:29:6E:06:00
inet addr:169.254.93.8  Bcast:169.254.255.255  Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

oracle集群最多支持4块私网网卡，网卡数量跟HAIP数量关系如下：

1块私网网卡，1个HAIP

2块私网网卡，2个HAIP

3块私网网卡，4个HAIP

4块私网网卡，4个HAIP。

查看集群初始化资源：

crsctl stat res -t -init

[grid@node1.localdom
b7e5
ain$]crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
1        ONLINE  ONLINE       node1                    Started
ora.cluster_interconnect.haip
1        ONLINE  ONLINE       node1
ora.crf
1        ONLINE  ONLINE       node1
ora.crsd
1        ONLINE  ONLINE       node1
ora.cssd
1        ONLINE  ONLINE       node1
ora.cssdmonitor
1        ONLINE  ONLINE       node1
ora.ctssd
1        ONLINE  ONLINE       node1                    ACTIVE:0
ora.diskmon
1        OFFLINE OFFLINE
ora.evmd
1        ONLINE  ONLINE       node1
ora.gipcd
1        ONLINE  ONLINE       node1
ora.gpnpd
1        ONLINE  ONLINE       node1
ora.mdnsd
1        ONLINE  ONLINE       node1

crsctl stat res命令用法：

[grid@node1.localdomain$]crsctl stat res -t -help
Usage:
crsctl status resource [<resName>[...]|-w <filter>] [<-p|-v> [-e]] | [[-f|-l|-g]] | [[-k <cid>|-n <server>] [-d <did>]] | [-s -k <cid> [-d <did>]]
Check status of designated resources

crsctl status resource [<resName>[...]|-w <filter>] -t
Print status of resources in tabular format

crsctl status resource [<resName>[...]] -dependency [-stop | -pullup]
Print resource dependencies
where
resName [...]     One or more blank-separated resource names
-w                Resource filter (e.g., "TYPE = ora.database.type")
-p                Print static configuration
-v                Print runtime configuration
-e                Evaluate a resource instance's special values
-f                Print full configuration
-l                Print all cardinal and degree members
-g                Check if resources are registered
-k                Cardinality ID
-d                Degree ID
-n                Server name
-s                Get target servers for relocation
-t                Tabular display
-dependency       Display resource dependencies, default is start dependencies
-stop             Display resource stop dependencies
-pullup           Display resource pullup dependencies

CHM

CHM ( Cluster Health Monitor）是Oracle 提供的一款工具，用来自动收集操作系统资源(CPU、内存、SWAP 、进程、I/0 以及网络等）的统计信息。从1 1.2.0.2 版本开始， CHM 会以初始化资源ora.crf 的形式存在于集群的每一个节点上。

CHM 搜集的系统资源数据对于诊断集群系统的节点重启、hang、实例驱逐（Eviction）、性能问题等是非常有帮助的。另外，CHM还可作为单独的工具安装在Linux和Windows平台上。

CHM组件：

1：组件I: CHM档案库（Repository）：默认情况下，它会存在于＜ gi_home>/crf/db／＜节点名〉下，默认占用I GB 的磁盘空间，是CHM 最大允许的信息保留天数为3天。

2：系统监控服务（System Monitor Service）：它会以osysmond.bin守护进程的方式在所有节点运行，osysmond.bin负责定期搜集本地节点的操作系统统计信息，并将搜集到的统计信息发送给主节点上的集群日志服务。

3：集群日志服务（Cluster Logger Service）：这个服务会以守护进程ologgerd 的形式运行在集群的CHM主节点（Master Node）和副节点（Replication Node）上。

总结：

Oracle 通过新增的mdns 和IPDP 组件使集群在boot 阶段变得更加灵活， gipc 组件让集群开始能够独立地管理集群私网，cssdagent/cssdmontor 的出现使集群能够更加准确地了解ocssd 守护进程和节点的状态。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航