11gR2 集群管理软件(GI) 启动顺序和诊断方法简介

在这篇文章里我们会对11gR2 GI 的启动顺序进行介绍,并且对常见的GI启动时遇到的问题和对应的解决办法进行介绍。

 

 

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

 

首先,ohasd阶段。

 

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

 

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 /null

 

被调用,产生下面的进程

 

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
 

$GRID_HOME/log//gpnpd
 

$GRID_HOME/log//gipcd
 

$GRID_HOME/log//agent/crsd
 

$GRID_HOME/log//agent/ohasd
 

$GRID_HOME/log//mdnsd
 

$GRID_HOME/log//client
 

$GRID_HOME/log//ctssd
 

$GRID_HOME/log//crsd
 

$GRID_HOME/log//cvu
 

$GRID_HOME/bin/diagcollection.sh
 

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

可以用下面的命令来查看GI相关的deamon的启动情况:
#ps -ef|grep init
#ps -ef|grep d.bin
#crsctl stat res -t -init
#crsctl check crs
关于这些命令,再详细解释一下。

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 这几个层面的健康型。对于我们了解问题出现在哪个层面是有帮助的。

对于10g, 过程要简单很多。

1. 首先, /etc/inittab(不同平台文件名可能不同),文件中的下面3行被调用。

h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 /null

h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 /null

h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 /null

 

这三个脚本是被同时调用的,每个脚本负责启动对应的守护进程。

 

 

2. 接下来,init.cssd 脚本负责把 ocssd.bin 守护进程启动并确认它正常工作, 之后crsd.bin 守护进程在发现ocssd.bin 正常云信之后,开始完成自己的启动,并开始启动集群的各个资源。

 

3. 最后,当crsd.bin 正常工作之后, evmd.bin 后台进程也就可以被正常启动并运行了。

 

 

所以,虽然那3个脚本是同时被调用,但是守护进程之间是有依赖关系的, ocssd.bin --> crsd.bin --> evmd.bin

以上,我们对GI启动的顺序和基本的诊断方法进行了简单的介绍,希望能够为大家在诊断GI启动问题时能够提供一些帮助。

时间: 2024-08-03 09:22:35

11gR2 集群管理软件(GI) 启动顺序和诊断方法简介的相关文章

pdsh、ClusterSSH和mussh集群管理软件

我是想把 /etc/hosts 文件 分发到 10.205.10.11至20机器上 安装命令 sudo yum -y install clusterssh pdsh pdsh-rcmd-ssh pdsh-rcmd-rsh mussh pdcp -w ssh:root@srv[11-20] /etc/hosts /etc/ pdsh软件包还包括一个pdcp命令,可以将文件拷贝到一组机器上,用法如下:pdsh -w [SSH_OR_RSH]:[USERNAME]@nodesrv[1,2-4,5] S

Linux SureHA集群共享磁盘一直处于启动中的处理方法

在日志中查看可以看到磁盘有FSCK操作,如下图:   原因分析: Linux SureHA集群中,默认设置磁盘挂载一定次数后,会自动进行fsck操作.进行该操作时,共享磁盘资源将无法正常启动. 解决方案: 建议直接取消默认设置的FSCK参数.   登录webmanager,切换到设定模式,在磁盘资源上右键单击选择属性,在"详细"-->"调整"-->"FSCK"中将相关选项设置为不执行,如下图:   通过上面的设置一直显示启动中的问题也

利用Pacemaker集群管理让Apache最大可用性

实验环境: 系统版本:CentOS release 6.5 (Final)_x64 node1: ip :192.168.0.233 #写进/etc/hosts文件中 node2: ip :192.168.0.234 vip: 192.168.0.183 注意:1.两台机器务必写静态ip,切记莫用dhcp获取ip,确保两个机器互相能ping通 2. 先禁用防火墙和SELinux 一.配置SSH SSH 是一个方便又安全的用来远程传输文件或运行命令的工具. 在这个文档中, 我们创建ssh key(

Google披露:大规模集群管理工具Borg的细节

Google最近发布了一篇名为"Google使用Borg进行大规模集群的管理"的论文,披露了这个在过去极少提及的技术的细节. Borg是一个集群管理器,它负责对来自于几千个应用程序所提交的job进行接收.调试.启动.停止.重启和监控,这些job将用于不同的服务,运行在不同数量的集群中,每个集群各自都可包含最多几万台服务器.Borg的目的是让开发者能够不必操心资源管理的问题,让他们专注于自己的工作,并且做到跨多个数据中心的资源利用率最大化.下面这张图表描述了Borg的主要架构: Borg

Docker 开源集群管理和容器编排工具 SwarmKit

最近Docker公司开源了Docker集群管理和容器编排工具SwarmKit,其主要功能包括节点发现.基于raft算法的一致性和任务调度等. 基本概念 服务器上运行SwarmKit工具的swarmd命令后,即可将其加入到服务器集群中,该服务器就成为集群中的一个节点.SwarmKit将节点分为两类: 工作节点负责通过执行器运行任务.SwarmKit的默认执行器为Docker容器执行器(Docker Container Executor); 管理节点负责接收和响应用户的请求,将集群状态调节成最终状态

一步到位分布式开发Zookeeper实现集群管理

说到分布式开发Zookeeper是必须了解和掌握的,分布式消息服务kafka .hbase 到hadoop等分布式大数据处理都会用到Zookeeper,所以在此将Zookeeper作为基础来讲解.   Zookeeper 是分布式服务框架,主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务.状态同步服务.集群管理.分布式应用配置项的管理等等. Zookeeper 的核心是广播,这个机制保证了各个Server之间的同步.实现这个机制的协议叫做Zab协议. Zab协议有两种模式,

集群管理可以很简单,Google又放大招

集群管理的名字并不像"云计算"或" appconomy"那样诱人,但是它确实是相当迷人和重要的技术.如果使用恰当,能够令Google.Facebook和Twitter等公司轻松运营数十亿的用户,并且不用浪费时间和金钱在服务器的管理上. 现在,Google在大力推广其IT技术,它希望每一个人都知道并来体验这项技术.在Google六月份宣布其容器管理技术Kubernetes开源时,我就曾撰文解释过其中的原因.上个月Google又和多个大公司签署合作共同支持Kuberne

[喵咪Liunx(5)集群管理利器pssh

[喵咪Liunx(5)集群管理利器pssh 前言 哈喽大家好呀!大家在管理服务器的时候如果只是一两台还好,当你管理三台以上的服务器的时候,你安装任何一个软件更改任何一个配置文件就要无比麻烦的每一台机器都去执行命令(当然用docker等的请无视),pssh可以帮我们解决这些问题,可以吧准备好的脚本批量在所有机器上进行执行,帮助你批量管理服务器集群! 附上: 喵了个咪的博客:w-blog.cn pssh官网地址:http://www.theether.org/pssh/ 1. 安装 pssh和mon

Java微服务开发指南 -- 集群管理、失败转移和负载均衡的实践

集群管理.失败转移和负载均衡的实践     在前一章节中,我们快速的介绍了集群管理.Linux容器,接下来让我们使用这些技术来解决微服务的伸缩性问题.作为参考,我们使用的微服务工程来自于第二.第三和第四章节(Spring Boot.Dropwizard和WildFly Swarm)中的内容,接下来的步骤都适合上述三款框架. 开始     我们需要将微服务打包成为Docker镜像,最终将其部署到Kubernetes,首先进入到项目工程hola-springboot,然后启动jboss-forge,