11G GI启动顺序

--11gR2 Clusterware and Grid Home - What You Need to Know (文档 ID 1053147.1)

 

 

 

 

上图来自《Oracle Clusterware Administration and Deployment Guide》

 

Level 1: OHASD Spawns:

cssdagent - Agent responsible for spawning CSSD.

orarootagent - Agent responsible for managing all root owned ohasd resources.

oraagent - Agent responsible for managing all oracle owned ohasd resources.

cssdmonitor - Monitors CSSD and node health (along wth the cssdagent).

 

Level 2: OHASD rootagent spawns:

CRSD - Primary daemon responsible for managing cluster resources.

CTSSD - Cluster Time Synchronization Services Daemon Diskmon

ACFS (ASM Cluster File System) Drivers 

 

Level 2: OHASD oraagent spawns:

MDNSD - Used for DNS lookup

GIPCD - Used for inter-process and inter-node communication

GPNPD - Grid Plug & Play Profile Daemon

EVMD - Event Monitor Daemon

ASM - Resource for monitoring ASM instances

 

Level 3: CRSD spawns:

orarootagent - Agent responsible for managing all root owned crsd resources.

oraagent - Agent responsible for managing all oracle owned crsd resources.

 

Level 4: CRSD rootagent spawns:

Network resource - To monitor the public network

SCAN VIP(s) - Single Client Access Name Virtual IPs

Node VIPs - One per node

ACFS Registery - For mounting ASM Cluster File System

GNS VIP (optional) - VIP for GNS

 

Level 4: CRSD oraagent spawns:

ASM Resouce - ASM Instance(s) resource

Diskgroup - Used for managing/monitoring ASM diskgroups.  

DB Resource - Used for monitoring and managing the DB and instances

SCAN Listener - Listener for single client access name, listening on SCAN VIP

Listener - Node listener listening on the Node VIP

Services - Used for monitoring and managing services

ONS - Oracle Notification Service

eONS - Enhanced Oracle Notification Service

GSD - For 9i backward compatibility

GNS (optional) - Grid Naming Service - Performs name resolution 

 

 

 

 

代理进程可以由ohasd和crsd守护进程启动，其他的集群守护进程不能启动代理进程。其中，ohasd守护进程的代理进程负责管理集群的初始化资源和其他守护进程，而CRSD守护进程启动的代理进程负责管理集群的其他资源（在这一点上与10g版本一致的）。

 

每个代理进程负责管理的资源可以参考下表：

资源名称	资源拥有者	代理进程
ora.gipcd	grid	oraagent_grid
ora.gpnpd	grid	oraagent_grid
ora.mdnsd	grid	oraagent_grid
ora.cssd	root	cssdagent
ora.cssdmonitor	root	cssdmonitor
ora.diskmon	root	orarootagent_root
ora.ctssd	root	orarootagent_root
ora.crsd	root	orarootagent_root
ora.evmd	grid	oraagent_grid
ora.asm	grid	oraagent_grid
ora.driver.acfs	root	orarootagent_root
ora.cluster_interconnect.haip	root	orarootagent_root
ora.crf	root	orarootagent_root

 

如果集群管理软件和数据库都是使用oracle用户安装的那么上表的代理进程oraagent_grid会是oraagent_oracle。

 

在以上资源中：

ora.gipcd、ora.gpnpd和ora.mdnsd会以守护进程的形式存在，他们负责完成集群在bootstrap阶段的工作。

ora.ctssd会以守护进程的形式存在，它负责集群的时间管理。

ora.cssd和ora.cssdmonitor会以守护进程的形式存在，其中ocssd.bin守护进程负责集群的构建，并维护集群的一致性。

ora.crsd会以crsd.bin守护进程的形式存在，这个守护进程负责管理集群的其他资源。

ora.evmd负责管理集群时间的发布，会以evmd.bin守护进程的形式存在。

ora.asm这个资源负责管理ASM实例，或者说他负责在集群启动时启动ASM实例。

ora.cluster_interconnect.haip这个资源负责集群的HAIP资源。

ora.crf负责管理11gR2版本集群管理软件的新特性CHM。

 

GI启动顺序

 

基本上我们可以把GI的启动过程分成3个阶段，ohasd阶段，构建集群阶段，启动资源阶段。

 

ohasd阶段

 

1． /etc/inittab文件中的脚本

 

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1  被调用，产生下面的进程

 

root 4865 1 0 Dec02 ? 00:01:01 /bin/sh /etc/init.d/init.ohasd run

 

所以如果说你没有发现这个进程，那么说明

 

+init.ohasd 脚本可能没有被调用

 

+ os运行在不正确的级别

 

+ 一些S* ohasd脚本挂起， 例如S96ohasd

 

+ GI没有配置自动启动（crsctl enable crs）

 

之后，ohasd.bin 进程会被启动，这个时候OLR会被访问，所以，如果ohasd.bin不能正常工作，就需要查看OLR是否存在而且能够被正常访问。OLR存放在$GRID_HOME/cdata/${HOSTNAME}.olr

 

 

 

2. ohasd.bin进程会启动对应的agents(orarootagent, oraagent, cssdagnet 和 cssdmonitor) 来启动集群的初始化资源。如果说，您发现这些agent进程不能启动，很多时候都是由于路径$GRID_HOME/bin 下的可执行文件存在问题，例如，文件权限设置有问题，文件corruption. 

 

构建集群阶段

 

1． Mdnsd 进程透过多播（Multicast）发现集群中的节点和所有的网卡信息。所以，一定要确定集群中的网卡支持多播。而且节点间的通信正常。

 

2． Gpnpd 进程启动，发布构建集群所需要的bootstrap 信息，并且在集群的所有节点之间同步gpnp profile。当然，同步是透过mdnsd实现的。所以，如果是这个进程存在问题，您需要确认节点间的通信正常，而且gpnp profile （/gpnp/profiles/peer/profile.xml）存在而且可以被访问。

 

3． Gipcd 进程启动，这个进程负责管理集群中所有的私网（cluster interconnect）网卡。当然，私网信息是通过gpnpd获得的，所以，如果这个进程存在问题，您需要确认gpnpd 进程正常运行。

 

4． Ocssd.bin 进程启动。这个进程首先通过gpnp profile中的信息发现表决盘(Voting Disk)，之后通过gpnpd 进程获得集群私网信息，和其他的节点建立连接。所以，如果ocssd.bin 不能正常运行，您需要确认一下的信息

 

+ gpnp profile 存在而且可以被访问。

 

+ gpnpd 进程正常运行。

 

+ 表决盘所在的asm disk 或设备能够正常被访问。

 

+ 节点私网间的通信正常。

 

5． 启动其他的初始化进程：ora.ctssd, ora.asm, ora.cluster_interconnect.haip, ora.crf, ora.crsd 等。

 

注意：以上的过程是同时进行的。也就是说ocssd.bin, gpnpd.bin 和 gipcd.bin 同时启动，直到gpnpd.bin正常运行，ocssd.bin 和 gipcd.bin 才能获得相应的信息，在gpnpd.bin没有正常运行之前,ocssd.bin 和 gipcd.bin 中出现的无法访问gpnp profile错误是可以忽略掉的。

 

资源启动阶段

在这个阶段，主要是通过crsd进程启动各个资源。

 

1． Crsd进程启动。这个进程需要访问OCR，如果您的OCR是存放在ASM上，需要确保ASM实例正常运行，并且OCR所在的ASM磁盘组已经装载。如果OCR存放在裸设备上，那么需要确保对应的设备正常运行。

 

2． Crsd 启动对应的agents(orarootagent, oraagent_, oraagent_ )。如果agent不能启动，很多时候都是由于路径$GRID_HOME/bin 下的可执行文件存在问题，例如，文件权限设置有问题，文件corruption.

 

3． 所有的资源启动。

 

ora.net1.network : 网络资源，这个资源负责管理集群的公网，scanvip, vip, listener资源都依赖于这个资源。所以，如果这个资源存在问题，vip, scanvip 和listener 都会offline，您需要检查公网是否存在问题。

 

ora..vip：scan对应的vip资源，最多可以有3个。

 

ora..vip : 节点对应的vip 资源

 

ora..lsnr: 监听程序资源。在这里我们要注意，从11gR2开始，listener.ora文件会自动生成，不再需要手动修改。

 

ora.LISTENER_SCAN.lsnr: scan 监听程序。

 

ora.<磁盘组名>.dg: ASM 磁盘组资源。这个资源会在磁盘组被mount时创建，dismount时删除。

 

ora.<数据库名>.db: 数据库资源。在11gR2中实例资源已经不再存在了，新的数据库资源会管理rac 数据库的所有实例，而数据库包含哪些实例，是通过资源参数“USR_ORA_INST_NAME@SERVERNAME( )”来决定的。另外，如果您的数据库存储在ASM磁盘上，那么数据库资源会依赖于对应的磁盘组资源，这个dependency是自动添加的。但是，如果数据库被转移到了其他的磁盘组之后，原有的dependancy不会被自动删除，需要手动删除(crsctl modify res ……)。

 

ora.<服务名>.svc：数据库服务资源。从11gR2 开始，这个资源只有一个了，不会像10gR2一样，每个数据库服务资源包含，srv 和cs 两个资源。

 

ora.cvu ：这个资源从11.2.0.2被引入，定期对集群执行cluvfy操作，验证集群是否存在一些配置上的问题

 

ora.ons : ONS资源，和之前版本的功能，基本相同。

 

另外，我们对诊断GI启动问题所需要查看的文件进行简单的介绍

 

$GRID_HOME/log//ocssd <== ocssd.bin 日志

 

$GRID_HOME/log//gpnpd <== gpnpd.bin 日志

 

$GRID_HOME/log//gipcd <== gipcd.bin 日志

 

$GRID_HOME/log//agent/crsd <== crsd.bin 日志

 

$GRID_HOME/log//agent/ohasd <== ohasd.bin 日志

 

$GRID_HOME/log//mdnsd <== mdnsd.bin 日志

 

$GRID_HOME/log//client <== 用户使用GI 工具(ocrdump, crsctl, ocrcheck, gpnptool等等)对集群进行操作的日志。

 

$GRID_HOME/log//ctssd <== ctssd.bin 日志

 

$GRID_HOME/log//crsd <== crsd.bin 日志

 

$GRID_HOME/log//cvu <== cluvfy 日志

 

$GRID_HOME/bin/diagcollection.sh <== 通过这个脚本获得更全面的诊断日志。

 

最后，集群的套接字文件(/var/tmp/.oracle 或 /tmp/.oracle)，由于集群中很多进程之间的通信都是通过ipc实现的，所以，这些套接字文件一定要存在而且权限正确。

 

可以用下面的命令来查看GI相关的deamon的启动情况：

 

1. #ps -ef|grep init， 对于11gR2，这个命令只会返回init.ohasd的信息， 如果没有类似于下面的信息显示，说明init.ohasd并没有启动，问题可能出现在/etc/init.d/init.ohasd脚本没有被调用。

root      7305     1  0 Mar05 ?        00:00:00 /bin/sh /etc/init.d/init.ohasd run

 

2. #ps -ef|grep d.bin， 这个命令可以帮我们找到有哪些daemon已经产生，例如crsd.bin, ocssd.bin 等等。

 

3. #crsctl stat res -t -init，这个命令用于查看哪些 init 资源被启动了(所谓的init资源是指由 ohasd 启动的资源)。 如果要查看集群的其他资源，可以用命令

crsctl stat res -t

 

4. #crsctl check crs , 这个命令主要是验证，ohasd, css, crs 和 evm 这几个层面的健康型。对于我们了解问题出现在哪个层面是有帮助的。