关于oracle rac节点的驱逐

2^#

发表于 2012-4-17 19:04:30

请参考拙作 Oracle RAC Brain Split Resolution

http://www.oracledatabase12g.com ... lit-resolution.html

有不清楚再提问

3^#

发表于 2012-4-18 12:01:36

原帖由 maclean 于 2012-4-17 19:04 发表
请参考拙作 Oracle RAC Brain Split Resolution

http://www.oracledatabase12g.com/archives/oracle-rac-brain-split-resolution.html

有不清楚再提问

首先可以肯定不是拙作，写得灰常好，但是有些地方不明白的：

在脑裂检查阶段Reconfig Manager会找出那些没有Network Heartbeat而有Disk Heartbeat的节点，并通过Network Heartbeat(如果可能的话)和Disk Heartbeat的信息来计算所有竞争子集群(subcluster)内的节点数目，并依据以下2种因素决定哪个子集群应当存活下去

1.在脑裂检查阶段为什么不检查Disk Heartbeat有问题的节点，如果单纯Disk Heartbeat有问题而Network Heartbeat正常的话算不算脑裂？需不需要发生驱逐？
2.什么时候会发生NM Reconfiguration？

[ 本帖最后由 gdpr-dba 于 2012-4-18 12:04 编辑 ]

4^#

发表于 2012-4-18 13:05:47

“1.在脑裂检查阶段为什么不检查Disk Heartbeat有问题的节点，如果单纯Disk Heartbeat有问题而Network Heartbeat正常的话算不算脑裂？需不需要发生驱逐？"

如《Oracle RAC Brain Split Resolution》文中所说：

Question:
若节点间的网络心跳正常，且节点所能正常心跳的vote disk 大于不能正常访问的，如3个votedisk 时恰巧有1个vote disk 的disk heartbeat 超时，此时Brain split 会发生吗？

Answer:
这种情况即不会触发Brain Split，也不会引发节点驱逐协议(eviction protocol)。当单个或小于(N/2+1)个的voting disk心跳失败(disk heartbeat failure)时，这种心跳失败可能是由于短期内节点访问voting disk发生I/O error错误而引起的，此时css会立刻将这些失败的voting disk标记为OFFLINE。虽然有一定数量的voting disk OFFLINE了，但是我们仍有至少(N/2+1)个投票磁盘可用，这保证了eviction protocol不会被调用，所以没有节点会被reboot重启。紧接着node monitor模块的Disk ping Monitor Thread(DPMT-clssnmDiskPMT)会重复尝试访问这些失败的OFFLINE voting disk，若这些投票磁盘变得再次可I/O访问且经过验证其上的数据也没有讹误，那么css会再次将此voting disk标记为ONLINE；但是如果在45s( 这里的45s是基于misscount和内部算法获得的) 内仍不能正常访问相关的voting disk，那么DMPT将在cssd.log中生成警告信息，如：

CSSD]2011-11-11 20:11:20.668 >
WARNING: clssnmDiskPMT: long disk latency >(45940 ms) to voting disk (0//dev/asm-votedisk1)

假设以上发生clssnmDiskPMT警告的RAC场景共有3个voting disk，现已有一个asm-votedisk1因为I/O error或其他原因而被标记为OFFLINE，若此时再有一个votedisk也出现了问题并disk heartbeat 失败，那么节点会因为少于规定数目(2)的votedisk而引发eviction protocol，进而重启reboot。

“什么时候会发生NM Reconfiguration？”

split brain situation 或者某个节点nodes 加入或离开cluster时都会发生 NM Reconfiguration

5^#

发表于 2012-4-18 14:21:23

原帖由 maclean 于 2012-4-18 13:05 发表
“1.在脑裂检查阶段为什么不检查Disk Heartbeat有问题的节点，如果单纯Disk Heartbeat有问题而Network Heartbeat正常的话算不算脑裂？需不需要发生驱逐？"

如《Oracle RAC Brain Split Resolution》文中所说：

Question:
...

谢谢刘大，这段我已经读过了，不过容许我钻一下牛角尖：“假设以上发生clssnmDiskPMT警告的RAC场景共有3个voting disk，现已有一个asm-votedisk1因为I/O error或其他原因而被标记为OFFLINE，若此时再有一个votedisk也出现了问题并disk heartbeat 失败，那么节点会因为少于规定数目(2)的votedisk而引发eviction protocol，进而重启reboot。”，这里貌似没说到会发生脑裂，只是说会发生eviction，eviction和脑裂是一回事吗？因为根据这句话“在脑裂检查阶段Reconfig Manager会找出那些没有Network Heartbeat而有Disk Heartbeat的节点”，感觉脑裂只是针对Network Heartbeat有问题的情况，不知道我的理解是否有问题。

6^#

发表于 2012-4-18 14:47:53

Oracle RAC CSS提供2种后台服务包括群组管理(Group Managment简称GM)和节点监控(Node Monitor简称NM)，其中GM管理组(group)和锁(lock)服务。在集群中任意时刻总有一个节点会充当GM主控节点(master node)。集群中的其他节点串行地将GM请求发送到主控节点(master node)，而master node将集群成员变更信息广播给集群中的其他节点。组成员关系(group membership)在每次发生集群重置(cluster reconfiguration)时发生同步。每一个节点独立地诠释集群成员变化信息。

1.这里的master node是怎么选择的？和reconfig manager是否同一节点？和访问block时的master node应该不是一回事吧？
2.“其中GM管理组(group)和锁(lock)服务” 锁服务指的是LMS和LMD吗？
3.“集群中的其他节点串行地将GM请求发送到主控节点”这里的GM请求指的是什么？
4.“而master node将集群成员变更信息广播给集群中的其他节点” 发生eviction时也算集群成员变更吗？
5.“每一个节点独立地诠释集群成员变化信息”这个是什么意思，根据上面的描述集群成员的变更信息不是记录在master node吗？

[ 本帖最后由 gdpr-dba 于 2012-4-18 15:21 编辑 ]

7^#

发表于 2012-4-18 14:51:37

"eviction protocol 和脑裂是一回事吗？ "

不是，脑裂要复杂地多。

当offline 的votedisk 多于或等于 online的votedisk 时，会触发 eviction protocol ， css自行重启 reboot node

If an I/O error is reported immediately on access to the vote disk, we immediately mark the vote disk as offline so it isn't at the party anymore. So now we have (in our case) just two voting disks available. We do keep retrying access to that dead disk, and if it becomes available again and the data is uncorrupted we mark it online again. If a second vote disk suffered an I/O error in the window that the first disk was marked offline. So now we don't have quorum. Bang reboot.

As long as we have enough voting disks online, the node can survive, but when the number of offline voting disks is greater than or equal to the number of online voting disks, the Cluster Communication Service daemon will fail resulting in a reboot.

8^#

发表于 2012-4-18 14:56:45

原帖由 maclean 于 2012-4-18 14:51 发表
"eviction protocol 和脑裂是一回事吗？ "

不是，脑裂要复杂地多。

当offline 的votedisk 多于或等于 online的votedisk 时，会触发 eviction protocol ， css自行重启 reboot node

If an I/O error is reported ...

1.那么脑裂是不是只针对network heartbeat失败的情况呢？
2.假如3个voting disk有两个的坏了，那集群的所有节点岂不是会不停地自行重启？

9^#

发表于 2012-4-18 15:18:45

1.初始化阶段 — reconfig manager(由集群成员号最低的节点担任)向其他节点发送启动reconfig的信号
2.投票阶段 — 节点向reconfig manager发送该节点所了解的成员关系
3.脑裂检查阶段 — reconfig manager检查是否脑裂
4.驱逐阶段 — reconfig manager驱逐非成员节点
5.更新阶段 — reconfig manager向成员节点发送权威成员关系信息

第一步假如节点的network有问题，那它如何收到reconfig manager发送的启动reconfig的信号？
同样，第二步假如节点的network有问题，节点也无法向reconfig manager发送该节点所了解的成员关系。

10^#

发表于 2012-4-18 15:25:34

Brain Split Resolution 的最终和最基本目的是：

When interconnect breaks – keeps the largest cluster possible up, other nodes will be evicted, in 2 node cluster lowest number node remains.

当内联网络失败时，保证最大的sub cluster活下来，其他节点被驱逐，在2节点的cluster中 node number小的一个活下来。

"1.那么脑裂是不是只针对network heartbeat失败的情况呢？"

几乎是，但是实际造成network heartbeat 失败的可能不仅仅是 network interface hardware网络硬件的原因，也有可能因为主机host 的cpu使用率过高，导致 css等关键进程分配不到必要的cpu时间片，进而造成 network heartbeat 网络失败

"2.假如3个voting disk有两个的坏了，那集群的所有节点岂不是会不停地自行重启？"

在运行中的cluster 若发生3个voting disk有两个的坏了那么节点会重启，重启后css会检测可online 的votedisk，若造成votedisk offline的问题未能通过reboot 重启解决，那么将不会有有效的 Disk HB(heartbeat) ，css不会正常启动， crs也不会启动任何资源resource ，直到 votedisk 的问题被解决。

11^#

发表于 2012-4-18 15:57:34

在运行中的cluster 若发生3个voting disk有两个的坏了那么节点会重启，重启后css会检测可online 的votedisk，若造成votedisk offline的问题未能通过reboot 重启解决，那么将不会有有效的 Disk HB(heartbeat) ，css不会正常启动， crs也不会启动任何资源resource ，直到 votedisk 的问题被解决。

voting disk故障导致的重启应该是所有的节点都会重启，而不是只eviction某些节点吧？

12^#

发表于 2012-4-18 16:01:16

Question:
"voting disk故障导致的重启应该是所有的节点都会重启，而不是只eviction某些节点吧？"

Answer:
如果每个节点node 都存在这样的 offline 的votedisk 多于或等于 online的votedisk 的故障，那么相关的所有节点都会reboot 。

13^#

发表于 2012-4-18 16:02:46

原帖由 maclean 于 2012-4-18 16:01 发表
Question:
"voting disk故障导致的重启应该是所有的节点都会重启，而不是只eviction某些节点吧？"

Answer:
如果每个节点node 都存在这样的 offline 的votedisk 多于或等于 online的votedisk 的故障，那么相关的所有 ...

谢谢刘大，对RAC的节点eviction机制慢慢清晰了。