高可用性 SQL Server

Question

我们目前有一个在 Win 2012 专用服务器上运行的 asp.net 应用程序，带有 SQL 2014 Express 的本地副本。

我们希望添加第二个 Web 服务器并将它们放在 NLB 集群中。但是如何处理 SQL... 该网站严重依赖 SQL 数据库（读取和写入）

我隐约熟悉 SQL 复制、可用性组、日志传送等的形式，并且已经阅读了 StackExchange 上关于同一主题的很多帖子，但我仍然有一些问题。

该站点只有中等流量，但 HA 和 RPO 仍然非常重要。我宁愿有一些停机时间，而不是松散的 1 行 SQL 数据，尽管迁移到此设置的重点是减少停机的机会。

一个适用于 SQL Express 的解决方案将是理想的，SQL Standard 很好，但我不想升级到 SQL Enterprise。

A) 关于在 IIS 服务器上保留 SQL，我有什么选择/建议。我宁愿将 SQL 跨越 2 个以上的 Web 服务器，然后只为 SQL 添加额外的服务器。B) SQL 2016 中是否有任何新功能可以帮助解决这个问题？

虽然我知道这不完全是 DBA 的问题，但我还是会问。有没有办法强制 asp.net 同时写入所有可用的 SQL 数据库，但可以从其中任何一个读取？（有点像 Windows NLB 对所有服务器使用相同的 IP，将更新/插入发布到 SQL IP 会将其写入所有服务器，但查询只会使用第一台回答的服务器的结果？

谢谢你们！

Answer 1

一个适用于 SQL Express 的解决方案将是理想的，SQL Standard 很好，但我不想升级到 SQL Enterprise。

如果您想要直接开箱即用的东西，那将很难找到。但是，2016 年确实带来了标准版可用性组。2016年之前的标准版确实有镜像。此外，如果您正在使用 asp.net 并使用会话状态数据库，则可能还有其他注意事项（例如不进行镜像或将其放入 AG，因为数据是易变的且不值得/不需要保留）。

A) 关于在 IIS 服务器上保留 SQL，我有什么选择/建议。我宁愿将 SQL 跨越 2 个以上的 Web 服务器，然后只为 SQL 添加额外的服务器。

扩展的最佳实践是将 SQL 放在它自己的服务器上。如果这太贵了，可以将它与您的 Web 服务放在同一台服务器上……这会带来一些风险（安全性、性能、正常运行时间）。

B) SQL 2016 中是否有任何新功能可以帮助解决这个问题？

是和否。是的，基本可用性组可用，但老实说，我认为它不适合您的情况。我实际上不相信可用性组总体上非常适合您所描述的内容。

虽然我知道这不完全是 DBA 的问题，但我还是会问。有没有办法强制 asp.net 同时写入所有可用的 SQL 数据库，但可以从其中任何一个读取？

不幸的是，除了复制之外，SQL Server 内部没有任何东西是开箱即用的。在这种情况下，您可以使用点对点，但同样是企业版功能，因此我们必须将其丢弃。合并复制是可能的，但老实说，这是一个非常可怕的野兽，我不希望任何人。

考虑到您给定的资源和内部能力（无意粗鲁），我会说这些是需要进一步调查的项目，以了解哪些最适合您的情况（因为您是做出该决定的最佳人选环境）。

1. 在 Azure 中托管

我想要完全透明，我为Microsoft工作。话虽如此，将应用程序转换到 Azure可能是最具成本效益和 RPO/RTO 效率的方式。

为什么？您当前的环境中存在一些关键的资源限制，这可能会使您难以在成本和人力资源之间实现您所寻求的正常运行时间。在 Azure 中，可以有多个数据库副本，您可以启动/停止（弹性）Web 主机。这为您提供了所需的 RPO/RTO，而无需了解任何SQL Server 部件并通过可单击的 GUI 对其进行配置。这可以按成本控制和使用进行放大/缩小。

最大的胜利是您获得了 RPO/RTO，而不必购买硬件或软件。

2. SQL Server 镜像

镜像不需要 Windows 群集或许多其他先决条件（如可用性组）。它通常更容易设置并且很简单。它至少需要标准版，而且每个 SQL Server 实例很可能需要许可成本，具体取决于一些因素。

镜像允许单个数据库故障转移，并且见证服务器可以与 SQL Server Express Edition 一起使用。此外，.NET 应用程序能够在连接字符串中设置故障转移伙伴服务器，以帮助实现更透明的故障转移方案。镜像不需要像可用性组那样的侦听器或客户端访问点，因此使用 IP 负载平衡解决方案进行健康检查并自动指向正确的主机非常容易。这不允许多主场景，仍然只有一个“主”服务器，然后将更新单个伙伴服务器。

这在设计上不太灵活，但符合 RPO/RTO 目标并且需要最少的管理维护（Azure 除外）。这是一项已弃用（读取、删除）的技术，但应该可以让您通过直到 2014 年脱离主流支持并且可能有其他解决方案。

3. SQL Server 集群实例

如果您已经熟悉 Windows 集群，这应该满足 RPO/RTO 要求并且是更简单的实现之一。如果您不熟悉它，那么我可能会远离 SQL FCI 或让承包商进来设置它（如果您选择这条路线）。

FCI 仅保存数据库的一份副本，并且确实需要共享存储才能实现。还有 Windows 群集要求。但是，它确实提供了透明的故障转移，并且可以与标准版一起使用。至少需要两台服务器才能提供高可用性。

4. 日志传送

这不是一个很好的选择，但可以满足您的大部分需求，不提供 RPO/RTO，但确实满足成本要求。它也非常容易设置，并且至少需要标准版。

这基本上是通过 SQL Server 代理进行日志备份，将它们复制到所有实例都可以看到的位置，然后辅助服务器定期检查该位置并恢复最新的日志备份。之后的一切都是完全手动的。不过，同样，它可以与 CNAME 或 IP 负载平衡器一起使用，使事情变得更加无缝。它仍然需要大量的管理工作来进行故障转移，然后设置反向日志传送以保持所有其他辅助服务器同步。

Aaron Bertrand 有一篇很好的帖子，在预算上做到了这一点，同时拥有“可读的辅助服务器”