高可用性Server

Question

我们目前在一个Win 2012专用服务器上运行一个asp.net应用程序，其中包含SQL2014Express的本地副本。

我们希望添加第二个web服务器，并将它们放在一个北草坪会议大楼集群中。但是如何处理SQL..。该网站严重依赖SQL数据库(读和写)

我对SQL复制、可用性组、日志传送等的形式有些模糊的熟悉，并且阅读了许多关于StackExchange的相同主题的文章，但我仍然有一些问题。

该网站只有中等流量，但房委会和RPO仍然是非常重要的。我宁愿有一些停机时间，而不是松散的1行SQL数据，尽管迁移到这个设置的全部目的是减少停机的可能性。

使用Enterprise的解决方案是理想的，Standard很好，但我不想升级到solution。

( A)关于在IIS服务器上保留SQL，我有哪些选项/建议。我宁愿在2+ web服务器上跨SQL，然后只为SQL添加额外的服务器。( B) SQL 2016中是否有任何新特性将对此有所帮助？

虽然我知道这不是DBA的问题，但我还是会问的。是否有办法强迫asp.net同时写入所有可用的SQL数据库，但可以从它们中的任何一个读取？(就像Windows北草坪会议大楼对所有服务器使用相同的IP一样，向SQL发布更新/插入会将更新/插入写入所有服务器，但是查询只会使用响应的第一台服务器的结果？

谢谢大家！

Answer 1

使用Enterprise的解决方案是理想的，Standard很好，但我不想升级到solution。

如果你想直接从盒子里拿出来，那就很难找到了。然而，2016年确实带来了标准版可用性组。2016年之前的标准版确实有镜像功能。此外，如果您使用asp.net并使用会话状态数据库，可能还需要考虑其他问题(比如不镜像或将其放入AG中，因为数据是不稳定的，不值得/不需要保存)。

( A)关于在IIS服务器上保留SQL，我有哪些选项/建议。我宁愿在2+ web服务器上跨SQL，然后只为SQL添加额外的服务器。

扩展的最佳实践是将SQL放在自己的服务器上。如果太贵的话，就可以把它和你的web服务放在同一台服务器上.这会带来一些风险(安全性、性能、正常运行时间)。

( B) SQL 2016中是否有任何新特性将对此有所帮助？

是和不。是的，基本可用性组是可用的，但老实说，我不认为它适合您的情况。实际上，我并不认为可用性组一般适合您所描述的内容。

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

不幸的是，除了复制之外，Server中没有任何东西可以打开。在这种情况下，您可以拥有对等的功能，但这是企业版的特性，所以我们必须扔掉它。合并复制是可能的，但老实说，这是一个非常可怕的野兽，我不希望任何人。

考虑到你给定的资源和内部能力(不是粗鲁的意思)，我想说的是，这些都是需要进一步调查的项目，以确定哪种情况最适合你(因为你是最好的人，因为你了解环境)。

1.在Azure

中托管

我想要完全透明，我为微软工作。尽管如此，将应用程序转换为Azure可能是成本效益最高的，RPO/RTO也是最有效的。

为什么？在您当前的环境中，有一些关键的资源限制可能会使您难以实现您正在寻找的与成本和人员资源相平衡的正常运行时间。在Azure中，可以有多个数据库副本，您可以向上/向下(弹性) web主机。这将为您提供您想要的RPO/RTO，而不必知道任何Server部件并通过可单击的GUI对其进行配置。这可以按成本控制和使用按比例增加/降低。

最大的胜利是你得到了RPO/RTO，而不需要购买硬件或软件。

2. Server镜像

镜像不需要Windows集群，也不需要其他一些先决条件，比如可用性组。它通常更容易设置，而且是直接的。它至少需要标准版，而且很可能每个Server实例都需要许可成本，这取决于几个方面。

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

设计的灵活性要小得多，但满足RPO/RTO目标，并且需要最少的管理维护(Azure除外)。这是一种不受欢迎的(阅读，删除)技术，但在2014年之前，它应该能让你通过主流支持，而且可能会有其他解决方案。

3. Server集群实例

如果您已经熟悉Windows集群，那么这应该满足RPO/RTO的要求，也是更容易实现的方法之一。如果您不熟悉它，那么我可能会远离SQL，或者让一个承包商来设置它(如果您选择这个路径)。

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

4.日志传送

这不是一个很好的适合，但做你想做的大部分，不交付的RPO/RTO，但确实满足成本要求。它也非常容易设置，并且至少需要标准版。

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

Aaron有一个预算做这件事的好职位，同时有“可读的辅助服务器”