这次遇到的问题很有意思，按常理来说，群集的价值就在于高可用，就在于当一个节点出现故障时，自动将服务切换到另一台可以正常工作的节点上。。但这次我遇上的却正好相反，一次典型的节点故障，没有触发资源的切换，反而导致整个群集失效。。
先来看一下这次故障的处理过程，很快，也很简单。。
最初现象：
SQL数据库服务发现不可用，业务系统中断
初步排查情况：
检查后发现群集资源处于脱机状态，SQL群集资源无法启动，日志中存在大量群集失败的记录
同时，服务器巡检发现A节点（主节点）服务器的一个网口灯处于熄灭状态。所以赶紧将其接到第三网口上
系统检查的工作发现系统日志中记录了某一时间点A节点服务器的两个网口同时发生中断的信息。随后出现群集相关的失败信息。
再次检查服务器网络适配器，两个网口状态正常
但在群集管理器中，心跳线网络仍然显示为失败状态
使用ping命令测试，也无法通过心跳线网络ping通对方
启动群集验证工具，报告中也显示很多网络状态相关报错
错误恢复：
综合以上各方面的情况，最后认为是A节点服务器的网卡控制器坏掉，连带两个网口均出现故障。
所以，我们将另外一条网线（其实就是心跳线）切换到服务器的第四网口上。
群集状态立即恢复了。
经最终确认，SQL服务状态恢复，业务状态也得以恢复。
经过以上的排错过程，问题是解决了。但我们仍然心存疑虑，甚至是忧虑。因为这是一次典型节点故障，而高可用变成了不可用。
所以在此之后，有花了很大的精力去调查这个事情。最终，还是得到了一些答案。。
对于整个问题的分析如下：
在故障之前，群集资源运行在节点A上面
到某个时间点的同一时间，节点A上的public和private两个网络接口同时断开。同时，节点B上也发现private接口中断。此时，为发生故障的第一时间。
在故障发生之后，节点B由于网络断开先是从群集中被移除，这时群集服务终止，之后它开始尝试重起群集服务，单是由于通信仍故障，及仲裁资源仍在节点A上面，节点B无法启动群集服务。
节点A故障之后，我们很快将数据接口的网线进行了切换，但仅恢复了数据链路的状态，其实心跳线链路仍然处于故障状态之中。并且，群集服务还是处于活的状态，所以它一直保持了对仲裁盘和资源盘的控制。这一点就是本次事故的关键所在！
也正是这个原因，所以导致节点B发起的接管请求，都被拒绝了。导致群集资源在第一时间无法切换到节点B上。
而这时节点A的网络故障依旧存在，无法在DNS上进行注册资源名称，所以虽然群集服务是活的，但是用于SQL的群集资源却无法正常提供服务。
并且这时又由于心跳线的故障，所以节点A发现无法继续提供服务，并尝试在第二时间进行群集切换时，却找不到可用的群集节点B。而节点B也无法联系到群集节点A和总裁磁盘，也就无法加入到群集环境中。
然后以上状态一直持续到我们将节点A的心跳线恢复正常之后，才得以恢复。
解决办法：
通过这次故障，我们可以发现，实际上是有两个时间点可以进行群集资源的切换。。但由于种种情况，在这两次时间点都没有成功的抓住机会。
那么先来看一下第一个时间点。
第一个时间点的核心问题其实就在于节点A发生故障以后，没有将资源进行释放，它认为自己是主节点，仅仅是网络故障而已，所以继续控制群集资源。这样就导致实际故障的节点控制资源不放，而实际正常的节点无法请求到资源。
这里要解释一点，理论上的正常情况下，比如节点A突然掉电了，那么这个时候共享存储实际上已经脱离节点A的控制。所以这时候，节点B可以很轻松的将其接管过来。而如果节点A与共享存储之间的链接正常，并且群集服务正在控制共享存储的话，节点B在这种情况下是无法接管过来的。
对于这样的一种机制，我们发现，它跟Windows 2003的时候是截然相反的。在Win03时代，无论发生何种故障，主节点马上释放共享存储，然后进行仲裁。
咨询了微软官方人士，得到的答复是说，Win03时代的这种机制，会造成群集资源的过度切换，或者叫频繁切换。。所以在Windows 2008里，群集资源的切换，多了一个评估过程，简单说就是只有当一定严重程度的问题发生，或者自身进行一些检测确定它确实无法继续工作时才会促发资源的切换。。
对于这一点，或者这个时间点上的事情，看来我们是无能为力了。。
再来看一下第二个时间点
第二个时间点上，节点A发现无法进行资源的DNS注册，群集服务确实无法正常启动。这时它才开始去找另外的群集节点，结果这时心跳线是故障状态，所以无法与节点B进行通讯，当然也就找不到节点B了。
那么在这种情况下，唯一能够起到预防作用的办法就是，尽可能多的增加心跳线的对数。并且最好不要插在同一个控制器所属的网口上。
也只有这个办法才能够预防类似以上情况的故障再次发生。。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
