虚拟环境下SQL Cluster 资源挂掉

Question

sqlvsphere网卡故障数据库

Answer 1

应为在物理机上已经稳定运行了2年了。我们2008/2012集群都是一个文档统一出来的配置，从来没错过。所以排除了集群配置问题。P2V的人告诉，他是原样转到虚拟机上的，验收的时候也没有问题。奇就奇怪在我们上月还转过一个sharepoint的 2008R2集群也没有问题，也是那个P2V的外包的人干的。现在在排查网络IP是否冲突（估计可能性很小），毕竟大部分时间那个集群都是好的。现在唯一知道的是系统繁忙的时候会断，且早上，中午，下午各发生了一次，所以没有规律。贴上来，就是看看有没有人遇到过类似的错误。

Answer 2

还有个猜测是，２个actrive 节点(A, B) ,没有发生故障转移，B节点完,好，上面部署的数据库一点没有事。很明显B节点的心跳还在。而A节点数据库实例重起，整个集群看不到A节点，报了些network failed的错误。既然看不到node A, 那么猜测和排查nbound network on Node A, 和两个节点上的虚拟网卡。另外现在在对比sharepoint cluster sql P2V文档和这个问题集群的　P2V文档。　P2V的人虽然说没有变化，可是P2V本身就是个巨变，谁知道vSphere 有什么鬼设置。

Answer 3

还有个猜测是，２个actrive 节点(A, B) ,没有发生故障转移，B节点完,好，上面部署的数据库一点没有事。很明显B节点的心跳还在。而A节点数据库实例重起，整个集群看不到A节点，报了些network failed的错误。既然看不到node A, 那么猜测和排查nbound network on Node A, 和两个节点上的虚拟网卡。另外现在在对比sharepoint cluster sql P2V文档和这个问题集群的　P2V文档。　P2V的人虽然说没有变化，可是P2V本身就是个巨变，谁知道vSphere 有什么鬼设置。这个就高端了 没玩过。

Answer 4

还有个猜测是，２个actrive 节点(A, B) ,没有发生故障转移，B节点完,好，上面部署的数据库一点没有事。很明显B节点的心跳还在。而A节点数据库实例重起，整个集群看不到A节点，报了些network failed的错误。既然看不到node A, 那么猜测和排查nbound network on Node A, 和两个节点上的虚拟网卡。另外现在在对比sharepoint cluster sql P2V文档和这个问题集群的　P2V文档。　P2V的人虽然说没有变化，可是P2V本身就是个巨变，谁知道vSphere 有什么鬼设置。这个就高端了 没玩过。hehe，现在当DBA苦啊，什么都要知道点，虚拟环境，SAN, 网络负载均衡，云存储，七八九的脚本语言。头都开始大了。最苦的是，现在流行数据库资源整合，把很多小的应用整合到共享集群上，给性能排查带来了巨大的困难。

Answer 5

我去。你们公司DBA是真正能学习到东西的。有机会求介绍过去学点东西。

Answer 6

更新下现状： 我目前通过cluster log 分析问题： 如何获取cluster log : http://blogs.msdn.com/b/clustering/archive/2008/09/24/8962934.aspxcluster log /g /copy:"d:\logs"

Answer 7

目前有两个SQL Cluster 环境， 它们 从物理服务器转向 VMWare环境后不同程度的开始冗机。且症状完全不同。（1） 第一个环境是Biztalk 的SQL cluster
仲裁盘丢失，造成集群服务宕掉。事件ID : 1177. 参考微软文档http://technet.microsoft.com/en-us/library/cc773498(v=ws.10).aspx。临时解决方法是 （1） 收集 cluster log ---> (2)关闭所有节点服务器，重起节点服务器。在观察cluster log的时候要注意一点，发现 log 的时间是UTC 时间，根服务器的本地时间不一致 。所以我的事件时间是下午2pm, 但cluster log 的时间发生在3pm UTC + 1小时event 1177
The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
（2） 第2个环境是另外一个的SQL cluster
很不幸 ,事发后我们重建了集群，造成过去的集群日志被截断。我们不能深入研究问题。只能等下次问题再发生。 这里的教训是： 事发后，要第一时间收集集群日志。教训2： 如果集群在服务器重起后online了，千万别去跑集群验证。这么做会把所有的资源再次offline.待更新 .......

Answer 8

发现问题:  改变虚拟网卡后,虚拟网卡的软件却没有更新.造成大量的数据包丢失,造成SQL Cluster 在某一个短暂时间内认为私有网,共有网的网路断掉. Node A由于获得少数票,而停了自己的cluster 服务. 很快网络好了,node A重新参与,自己起来了.