传统故障转移集群与可用性组

Question

我正在研究可用性组，看看我是否可以从它们中受益，但我很难理解我是否可以。

今天，我们正在运行一个具有大约 150 个数据库的传统故障转移集群。它是许多不同的东西的集合，在很多情况下几乎不使用，但我们不能因为一百万种不同的原因把它扔掉。但长时间的停机是不可接受的。环境看起来像这样：

• 没有一个数据库对业务至关重要（但 DB 的数量使其变得至关重要）
• 数据库范围从 10 MB 到 10 GB
• 平均 30.000 次逻辑读取/秒，低于 1 次物理读取/秒
• CPU 使用率低（低于 20%）
• 两个数据中心的两台物理服务器
• 存储在两个 VMAX 10k 上，每个中心一个，通过 VPLEX 分布共享卷，因此失去一个中心不会影响存储的正常运行时间
• 无需报告或任何异常
• 大多数DB都是简单模式，每晚全备份，企业接受每晚备份作为还原点没有问题
• 少数数据库运行完整模式并具有 30 分钟的事务备份

当时选择此解决方案的原因是许可和管理原因。我们想减少所有单个 SQL Server 的使用，除了花钱之外什么都不做。我们已经从环境中删除了大约 60 个 SQL Server 安装。

但是现在有人在谈论我们将来应该如何处理这个问题，硬件更换将在一年内到来。

问题是，正如我之前所说的，如果我们可以从更改中受益，我无法完全理解，也许改为在虚拟机上运行可用性组？

所以我的问题是：

考虑到这些因素，您认为最好的解决方案是什么？

Answer 1

考虑到这些因素，您认为最好的解决方案是什么？

AlwaysON 旨在满足业务正常运行时间和可用性的要求，您可以将数据丢失和停机时间降至最低。它需要适当的规划和实施。

根据您的问题，数据库似乎不是那么关键的业务( business have no problem accepting the nightly backup as restore point)。

根据您提供的信息，您的企业将能够使用 Log Shipping 作为 DR 解决方案来生存。

好处是您不必担心 Windows 集群和与AlwaysON相关的其他复杂性，如 DNS、Windows 故障转移集群等。检查先决条件和要求。

Logshipping已经过充分测试，是您从 SQL Server 获得的所有 DR 技术中最成熟的。您可以根据需要调整事务日志备份、复制和还原的频率。