☰

Hyper V 上的 SQL 群集 - 群集内的群集是否有好处

tag-icon • tag-icon sql-server-2008 windows-server-2008-r2 cluster
Hyper V 上的 SQL 群集 - 群集内的群集是否有好处

这是一个重新问题我之前问过——在一位顾问向部门其他团队提出想法后，整个问题又被提出，因此我正在寻找更详细的答案。

我们打算在多个物理刀片上设置一个多实例 SQL 集群，该集群将在每个 SQL 实例上运行各种不同的系统。一般情况下，每个 VM 主机上都会运行一个虚拟 SQL 实例。同样，在一般操作中，每个 VM 主机都将在专用的底层刀片上运行。该设置应该为我们提供很大的灵活性，可以维护任何单个 VM 或底层刀片，并且所有 SQL 实例都可以根据需要进行故障转移。

我原来的计划是这样做：

  1. 在每个刀片上安装 2008 R2
  2. 将 Hyper V 添加到每个刀片
  3. 在每个刀片上安装一个 2008 R2 VM
  4. 在虚拟机内 - 创建故障转移群集，然后安装 SQL Server 群集。

顾问建议我们采取以下做法：

  1. 在每个刀片上安装 2008 R2
  2. 将 Hyper V 添加到每个刀片
  3. 在每个刀片上安装一个 2008 R2 VM
  4. 在将托管所有虚拟机的主机上创建一个集群。
  5. 在虚拟机内 - 创建故障转移群集，然后安装 SQL Server 群集。

最大的不同是增加了第 4 步，我们将所有客户虚拟机也集群化。理由是，这进一步改善了维护，因为我们在 SQL 集群和物理硬件之间没有任何联系。理论上，我们可以在主机周围实时迁移客户虚拟机，而不会对 SQL 集群产生任何影响，因此对于日常维护物理刀片，我们可以不间断地移动 SQL 集群，也不需要故障转移。

这听起来是个不错的主意，但我在互联网上没有看到有人说他们已经这样做了并且效果很好。我实际上可以在不影响其中托管的 SQL 群集的情况下对客户机进行实时迁移吗？

有没有人有过这种设置的经验，不管是好的还是坏的？是否有一些我没有考虑到的利弊？

我理解镜像也是一个值得考虑的宝贵选择 - 在这种情况下，我们倾向于集群，因为它将处理每个实例的全部内容，并且我们拥有大量数据库。一些数据库用于笨重的第三方系统，这些系统甚至可能无法很好地与镜像配合使用（我对集群的理解是故障转移对客户端完全透明）。

谢谢。

答案1

如果这些刀片完全用于运行 SQL Server，那为什么还要费心进行虚拟化呢？

为什么不简单地在每个服务器上安装 Windows Server 和 SQL Server，并相应地设置集群，而没有额外的虚拟化开销？

答案2

听起来很复杂。

我必须权衡您的解决方案的“复杂性”与标准物理集群 SQL 服务器实现的可靠性和相对简单性。

所有数据库都是任务关键型的吗？根据我的经验，通常不是，所以我倾向于将最重要的数据库托管在具有完全弹性的服务器上，其余数据库（通常占很大比例）托管在简单的 SQL 服务器上。

这使你能够集中精力保持最重要的系统的正常运行，而不是试图“同时处理所有事情”。

所有服务器都需要定期进行例行维护。考虑到安全补丁的规律性、严重性和重要性，我们已经不再试图维持理论上的 5 个 9 的正常运行时间（用户喜欢，但实际上并不需要），而是采取更现实的做法：“我们将确保服务器安全可靠 - 但将有短暂的强制性维护窗口，以便我们能够正确修补服务器。”

答案3

在列出的选项中，我会选择 #2，但我不会集群 SQL（步骤 5），因为它会增加一层复杂性，而你不会从中获得太多好处。Hyper-V 集群已经允许您在任一主机上运行该 VM，因此您可以应对硬件故障。

我假设您计划对 SQL 日志和数据库卷使用固定大小的 VHD。

我完全理解其他人关于完全跳过 Hyper-V 并仅将 2 个刀片用作普通 SQL 集群的评论 - 这肯定是传统方法。但是，虚拟化工作负载的灵活性优势对于维护、升级和硬件故障而言是巨大的。虚拟机的可移植性非常吸引人。

但请注意，此解决方案的价值还取决于您的环境。如果您没有其他 Hyper-V 服务器，并且您的员工对 Hyper-V 不太熟悉，那么虚拟化您最关键的工作负载之一可能不是一个好主意。但是，如果您像许多 IT 商店一样，开始虚拟化不太重要的服务器，已经建立了一些主机，并且拥有可靠运行 Hyper-V 的技能和程序，那么将重点扩展到更关键的工作负载是完全合理的。就我个人而言，我宁愿在主机级别而不是 SQL 级别管理集群，我认为我们会看到越来越多地这样做，尽管它还不那么常见。

最后，您关于在 Hyper-V 上运行 SQL 的问题是：是的，实时迁移可以很好地与 SQL 配合使用，并且不会注意到 - 并且 - SQL db 镜像很棒，但是是的，它并未得到普遍支持，因此并不适合每种情况。

答案4

我认为您的顾问说得对。我和他的想法完全一样，我希望在我当前的环境中实现。2 个物理硬件，每个硬件都运行 Hyper-V，并安装 2x W2k8。

  1. 在第一个物理主机上安装 2 个虚拟机。
  2. 在 VM1 上安装 SQL，并将镜像或群集到 VM2，在 O/S 级别设置容错功能，以便故障转移到复制环境。
  3. 在第二台物理服务器和故障转移群集 Hyper-V 上安装 W2k8。

这为您的 SQL 环境提供了完整的故障转移群集和完整的 H/A。

也许我的想法很愚蠢？

相关内容