新集群测试 - 最佳实践

Question

我们已经完成了 4 节点 SQL Server 2005 集群的设置。我们使用 Windows 2008 R2 作为底层操作系统。

我们正在寻找关于我们可以执行的一组测试的建议来测试 SQL 实例的故障转移？

Answer 1

甚至不接近全面，但我会从以下开始： 1. 为您的主/活动节点上的公共 ip 接口拉出以太网电缆。确认故障转移。2. 拉出活动节点的 SAN 光纤电缆。确认故障转移。3. 拉动活动节点的电源线。确认故障转移。

这些代表了 MS Clustering 将首先补偿的主要故障类型......

我想我会在玩这些游戏时将我的真实/生产数据库分离或离线。*

Answer 2

Thomas 在对该问题的评论中提供的链接是一些要测试的场景的良好资源。Bob 还提供了一些很好的测试，其中许多都包含在链接的博客文章中。

我想说，除了要检查的那些很棒的“什么”列表之外，您还想查看各种应用程序场景来测试故障转移。我已经看到很多集群被构建，然后从服务器团队/DBA 团队方面进行测试 - 但应用程序团队从未参与其中。

在故障转移期间，您的应用程序会发生什么情况？现在它看起来真的很像应用程序的重新启动（实际上，这就是故障转移的含义。节点 A 上的服务停止运行。节点 B 上的服务运行停止。当 SQL 关闭并重新启动时，SQL 会执行它的操作或当它崩溃并重新启动时..数据库在重启的另一侧经历恢复，连接全部断开，等等）所以测试似乎毫无意义，但最好看看什么样的过程用户将体验并了解应用程序所有者和服务台人员等在发生故障转移时需要执行的流程。

你应该问这样的问题：

1. 数据库重启后是否有需要重置或重启的组件？
2. 在维护窗口期间，您是否必须遵循非常具体的 SQL Server 关闭/重启操作顺序？这可能看起来像是应用程序或中间件服务器首先关闭，然后是数据库。在集群故障转移中，您首先让数据库停机。这对您和您的公司意味着什么？
3. 您的第三方软件包供应商是否支持在集群上安装？他们应该，并没有太大的不同，但他们可能有在故障转移期间要考虑的事情的指导。
4. 您的应用是否会自动尝试重新连接一定次数？如果没有，他们可以吗？在您的集群环境中考虑这可能是一件好事，以节省重新连接的时间并在故障转移后恢复工作。

当您执行其中一些测试时，让您的应用程序运行（不是实时生产......），用户或测试脚本在故障转移期间执行工作。发生了什么？看到有什么需要注意的吗？