多站点群集中的SQL Server Management Studio

在设置多站点群集（不同子网中的节点）时，您会发现默认情况下，群集将为其网络名称启用RegisterAllProvidersIP群集资源。这导致在SQL群集名称资源的DNS中有两个条目。每个群集IP地址一个。如果在连接字符串中使用可选的MultiSubnetFailover = True参数，则客户端将同时尝试两个IP地址。之后，它将连接到响应的第一台服务器。对于SQL Server Management Studio，在其他连接参数下添加该设置。

转载自https://clusteringformeremortals.com/2015/03/24/sql-server-management-studio-in-a-multi-site-cluster/的许可

多站点群集中的SQL Server Management Studio

在设置多站点群集（不同子网中的节点）时，您会发现默认情况下，群集将为其网络名称启用RegisterAllProvidersIP群集资源。这导致在SQL群集名称资源的DNS中有两个条目。每个群集IP地址一个。如果在连接字符串中使用可选的MultiSubnetFailover = True参数，则客户端将同时尝试两个IP地址。之后，它将连接到响应的第一台服务器。对于SQL Server Management Studio在多站点群集中，在其他“连接参数”下添加该设置。

转载自https://clusteringformeremortals.com/2015/03/24/sql-server-management-studio-in-a-multi-site-cluster/的许可

为什么要在Azure云中构建SQL Server故障转移群集实例？

Twitterverse今天发生了一场有趣的讨论。基本上，有人问过“有没有人在Azure中设置SQL服务器故障转移群集实例？”随后的对话涉及一些很好的尊重SQL Server专家。它导致了下面的问题：“为什么你要在云中构建SQL Server AlwaysOn故障转移群集实例？”

这个问题可以通过两种方式解释：“为什么需要云中的高可用性”或“为什么不使用AlwaysOn可用性组而不是故障转移群集实例？”

我们一次解决每个问题。

问题1 – 为什么您需要Azure云中的高可用性？

• 您可能认为，仅仅因为您在Azure中托管了SQL Server实例，而您的正常运行时间SLA为99.95％。如果你认为那样，你会错的。为了充分利用99.95％的SLA，您必须在可用性集中至少运行两个SQL实例。在运行一个SQL实例的情况下，您绝对可以预计，在维护期间，停机时间最短。但是，你也容易受到计划外的失败。
• 两个SQL Server实例通常不能进行负载平衡。 你必须实现某种机制来保持服务器的同步。 为确保如果其中一台服务器出现问题，另一台服务器将能够继续为这些请求提供服务。高可用性解决方案，如AlwaysOn可用性组，AlwaysOn故障切换群集实例，甚至是不赞成使用的数据库镜像都可以为该场景中的SQL Server提供高可用性。日志传送和事务复制等其他解决方案可以帮助保持服务器之间的数据同步。但它们通常不被视为高可用性解决方案，并不能确保SQL Server的可用性。
• Microsoft偶尔需要在Azure上执行维护操作，这可能会导致整个升级域以及该升级域中运行的所有实例。你什么时候都没有发言权。所以，你需要有一个机制来确保如果他们不得不关闭你的主要SQL Server实例，你可以期望你的辅助SQL Server实例将接管工作量而不会错过任何节拍。上面提到的所有高可用性解决方案都可以确保在Microsoft正在对主服务器的升级域进行维护的情况下继续运行。Microsoft一次只能在单个升级域上进行维护。这可以确保您的辅助服务器仍然处于联机状态，假设您将两者都放在同一个可用性集中。
• 如果您希望在生产SQL Server上进行性能维护，您会做什么？也许你想安装一个Service Pack或其他修补程序？如果没有辅助服务器进行故障转移，则必须安排计划停机时间。任何高可用性解决方案的主要优势之一是可以执行滚动升级，从而将计划停机时间的影响降到最低。

问题2 – 为什么不使用AlwaysOn可用性组而不是故障转移群集实例？

• 存钱！SQL Server AlwaysOn可用性组需要SQL Server的企业版。为什么不省钱并部署SQL Server Standard Edition并构建一个简单的双节点故障转移群集实例？除非您因为其他原因需要使用企业版，否则这是毫无疑问的。
• 保护ENTIRE SQL Server实例。AlwaysOn可用性组仅保护用户定义的数据库;您无法保护系统和MSDB数据库。如果您构建SQL Server故障转移群集实例，则需要保护ENTIRE实例，包括System和MSDB数据库。
• 简化管理。在Azure中，您仅限于客户端侦听器。这将您限制为只有一个可用性组。相比之下，使用故障转移群集实例只需一个客户端监听器，因此没有限制。
• 工作者线程用尽。通过AlwaysOn AG，您必须密切关注可用的工作线程。可用的工作线程限制了AlwaysOn AG可以保护的数据库数量。相比之下，使用DataKeeper块级复制的AlwaysOn故障切换群集不会为您添加的每个数据库消耗更多的资源。这意味着您可以进行扩展以保护数百个数据库，而不会增加与AlwaysOn AG相关的额外开销。
• 分发事务支持。AlwaysOn AG不支持分布式事务（DTC）。如果您的应用程序需要DTC支持，您将不得不查看AlwaysOn故障转移群集实例。
• 支持其他复制技术。如果您打算在AlwaysOn AG保护的两个数据库之间设置对等复制，您可以将其忽略。事实上，一旦部署AlwaysOn可用性组，您必须注意许多限制。AlwaysOn FCI没有任何限制。

结论

了解上述知识后，这个问题不应该是真正的问题：“为什么我需要在构建AlwaysOn故障转移群集实例的更健壮，更经济的解决方案时，在云中实施AlwaysOn AG？”

如果您有兴趣在Azure中构建AlwaysOn故障转移群集实例，请查看我的博客文章分步：如何在Microsoft Azure中配置SQL Server故障转移群集实例（FCI）#SQLServer #Azure #SANLess

经https://clusteringformeremortals.com/2015/03/05/why-would-you-want-to-build-a-sqlserver-failover-cluster-instance-in-the-azure-cloud/许可转载

群集101：配置Windows群集仲裁 – 您需要了解的内容

如果你错过了，我会举行群集法定人数的深度网络研讨会。在30分钟内，我会详细介绍关于法定人数的所有信息，从节点多数人到Cloud Witness以及其间的所有内容。如果您有关于法定人数的其他问题，请将其作为对本文的评论。我会很乐意提供帮助。