到某个时间点的同一时间，节点A上的public和private两个网络接口同时断开。同时，节点B上也发现private接口中断。此时，为发生故障的第一时间。

在故障发生之后，节点B由于网络断开先是从群集中被移除，这时群集服务终止，之后它开始尝试重起群集服务，单是由于通信仍故障，及仲裁资源仍在节点A上面，节点B无法启动群集服务。

飞鸽传书 - 原因

节点A故障之后，我们很快将数据接口的网线进行了切换，但仅恢复了数据链路的状态，其实心跳线链路仍然处于故障状态之中。并且，群集服务还是处于活的状态，所以它一直保持了对仲裁盘和资源盘的控制。这一点就是本次事故的关键所在！

也正是这个原因，所以导致节点B发起的接管请求，都被拒绝了。导致群集资源在第一时间无法切换到节点B上。

而这时节点A的网络故障依旧存在，无法在DNS上进行注册资源名称，所以虽然群集服务是活的，但是用于SQL的群集资源却无法正常提供服务。

并且这时又由于心跳线的故障，所以节点A发现无法继续提供服务，并尝试在第二时间进行群集切换时，却找不到可用的群集节点B。而节点B也无法联系到群集节点A和总裁磁盘，也就无法加入到群集环境中。

然后以上状态一直持续到我们将节点A的心跳线恢复正常之后，才得以恢复。

飞鸽传书 解决办法：

通过这次故障，我们可以发现，实际上是有两个时间点可以进行群集资源的切换。。但由于种种情况，在这两次时间点都没有成功的抓住机会。