SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Date: 3月 16, 2018

配置SQL Server Alwayson内部负载均衡器在Azure资源管理器（ARM）部署模型中的客户端监听器#Sqlpass

采用两种部署模式进行选择

在本文中我们将要讨论的是在资源管理器部署模型上配置SQL Server Alwayson内部负载平衡器。

如果您不知道，Azure有两种部署模型：资源管理器（ARM）和经典部署。经典部署是做事的“老”方式，ARM是做事的新方式。如Azure文章理解资源管理器部署和经典部署中所述，使用ARM有许多好处。然而，我最喜欢的ARM新功能之一是能够为每个可用性集合提供三个故障域，而不仅仅是使用Classic部署模型获得的两个故障域。这是SQL Server High Availability的关键功能。

资源管理器部署模型

通过三个故障域，可以确保双节点群集中的每个群集节点和文件共享见证全部驻留在不同的故障域中。这消除了单个故障域的故障可能会影响集群中多个法定人数投票的可能性。

经典部署模型

在具有两个故障域的Classic Deployment模型中，只能将两个群集节点放入可用性集中。为了获得最大可用性，您确实需要将文件共享见证放在不同的地理位置。无法保证它不会像其中一个群集节点一样处于相同的故障域，并且如果将它保存在同一地理位置。这意味着单个故障域的失败可能会影响3个法定票数中的2个。它会降低你的整个群集。ARM的三个故障域消除了这种可能性。

Azure资源管理器

由于仅在ARM中引入新的Azure功能，因此ARM无疑是最佳选择。但是，文档很轻，有些功能还没有完成。  包括诸如ExpressRoute的文档化支持等。这些问题几乎每天都会好起来。 但是，早期采用者真的必须加倍努力，直到Azure赶上。另一个问题是您不能混用Classic和ARM部署。因此，如果您使用Classic部署开始走下坡路，那么基本上您将不得不从资源管理器开始实施切换。如果你现在可以忍受一点痛苦，它会帮助你明年避免更大的头痛。特别是，当你发现你想要一些仅在ARM中可用的新功能时。

获得高可用性SQL Server

我希望这篇文章能够帮助您至少了解ARM部署的一个方面 – 部署高可用性的SQL Server。正如我在前面的文章中所记录的，在Azure“Classic”中部署AlwaysOn可用性组和AlwaysOn故障转移群集实例需要使用Azure负载平衡器（内部或外部）进行客户端重定向。在Classic Azure中配置并不是直截了当的。但是已经很好地记录下来，任何熟悉Azure，故障转移群集，SQL Server和PowerShell的管理员都可以使其运行。

配置ILB并更新SQL群集IP资源

使用ARM部署模型的AlwaysOn可用性组和AlwaysOn故障转移群集实例仍需要使用Azure负载均衡器进行客户端重定向。但是，创建和配置负载平衡器的步骤完全不同。 截至今天，它也没有被完全记录得很好。

在本文中，我将重点介绍配置SQL Server AlwaysOn内部负载均衡器和更新SQL群集IP资源所需的步骤。在下一篇文章中，我将逐步介绍整个流程，从创建vNet到安装SQL并创建集群。

开始了

在我们开始之前，我做了以下假设，你已经完成了以下工作：

  • 使用ARM创建一个vNet
  • 预置的3个基于ARM的虚拟机（DC，SQL1，SQL2）
  • 将DC，SQL1和SQL2放入相同的可用性集和资源组中
  • 使用SQL1和SQL2创建一个集群，并使用DC作为文件共享见证
  • 使用SIOS DataKeeper Cluster Edition创建AlwaysOn可用性组或AlwaysOn故障转移群集实例。无论哪种情况，您都会收到一个客户端监听器，它由一个名称资源和IP资源组成。AlwaysOn AG和故障转移群集实例的配置直到创建负载均衡器的点与在Azure Classic部署模型中完全相同。它被记录在网络上的许多地方，包括我自己的博客文章

快速提示

既然您拥有完全配置好的AlwaysOn AG或故障转移群集实例，那么您可能注意到无法从除当前承载SQL群集名称资源的节点之外的任何服务器连接群集名称。我被告知这是因为Azure网络不支持无偿ARPS。因此，客户端不能直接与群集IP地址通信。相反，客户端需要与ILB进行通信，ILB会将流量重定向到主动节点。因此第1步是创建ILB。到目前为止，这无法通过Azure门户完成，因此我们将使用以下Azure PowerShell命令。

[1/6/2016 Update – The directions below assume you are using Azure PowerShell pre-version 1. The script if you are using Azure PowerShell Version 1 or later is detailed in my blog post here.]

Switch-AzureMode -Name AzureResourceManager

Select-AzureSubscription -SubscriptionName“MSDN Azure”
＃名称，无论您用于创建vNet和VM的订阅

＃使用与您的部署相关的值来声明您的变量

$ ResourceGroupName ='SIOS-EAST-RG'
＃资源组部署SQL节点的名称

$ FrontEndConfigurationName ='FE'
＃无论你喜欢什么，都可以拨打

$ BackendConfiguratioName ='BE'
＃无论你喜欢什么，都可以拨打

$ LoadBalancerName ='ILB'
＃为内部本地余额对象提供一个名称

$ Location ='eastus2'
＃输入SQL虚拟机的数据中心位置

$ subname ='PUBLIC'
＃提供放置SQL节点的子网名称

$ ILBIP = '10 .0.0.201'
＃为监听器或负载均衡器提供IP地址

$ subnet = Get-AzureVirtualNetwork -ResourceGroupName $ ResourceGroupName |
Get-AzureVirtualNetworkSubnetConfig -name $ subname

$ FEConfig = New-AzureLoadBalancerFrontendIpConfig 
-Name $ FrontEndConfigurationName -PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id

$ BackendConfig = New-AzureLoadBalancerBackendAddressPoolConfig 
-Name $ BackendConfiguratioName

＃创建ILB
New-AzureLoadBalancer -Name $ LoadBalancerName -ResourceGroupName 
$ ResourceGroupName -Location $ Location
-FrontendIpConfiguration $ FEConfig -BackendAddressPool $ BackendConfig

ILB被创建

如果我们列出资源组中的所有对象，我们应该在Azure门户中看到它，如下所示。

SQL Server Alwayson内部负载平衡器

我确信其余的配置也可以通过PowerShell完成。但我将在我的示例中使用GUI。如果您想使用PowerShell，您可以通过查看使用Azure资源管理器开始配置内部负载平衡器的文章，将脚本拼凑在一起。 老实说那篇文章让我很头疼。我会在一天之内弄清楚它的存在并尝试以用户友好的格式记录它。 现在我认为GUI对于接下来的步骤是很好的。

跟随下面的屏幕截图。如果您迷路了，请按照Azure门户顶部的导航提示找出我们的位置。

点击后台池设置标签。 选择后端池来更新可用性集和虚拟机。保存您的更改。

SQL Server Alwayson内部负载平衡器
通过单击探针选项卡上的添加来配置负载平衡器的探针。为探测器命名并将其配置为使用TCP端口59999。我已将探测间隔和不健康阈值设置为默认设置。这意味着ILB在故障切换后从被激活节点列表中移除被动节点需要10秒钟的时间。这也意味着您的客户可能需要长达10秒才能重定向到新的活动节点。一定要保存您的更改。
SQL Server Alwayson内部负载平衡器

导航到“负载平衡规则”选项卡并添加新规则。给规则一个明智的名字（SQL1433或其他）。选择TCP协议端口1433（假设您正在使用SQL Server的默认实例）。为后端端口选择1433。对于后端池，我们将选择我们之前创建的后端池（BE）。接下来，对于探针，我们将选择我们之前创建的探针。我们不想启用会话持久性，但我们希望启用浮动IP（直接服务器返回）。我已将空闲超时设置为默认设置。但是你可能想考虑将其增加到最大值。每次连接断开并需要重新建立时，我都会看到一些应用程序，例如SAP日志错误消息。

SQL Server Alwayson内部负载平衡器

此时配置ILB。只有最后一步需要进行。我们需要更新SQL IP群集资源，就像我们在Classic部署模型中所用的一样。为此，您只需在其中一个群集节点上运行以下PowerShell脚本。并注意，SubnetMask =“255.255.255.255”不是一个错误。无论您的实际子网掩码是什么，都使用32位掩码。

＃此脚本应在主群集节点上运行 
内部负载均衡器已创建
＃定义变量

$ ClusterNetworkName =“群集网络1”
＃群集网络名称

$ IPResourceName =“SQL IP地址1（SQLCluster1）”
＃IP地址资源名称

$ CloudServiceIP =“10.0.0.201”
＃内部负载平衡器的IP地址

导入模块故障转移群集

＃如果您使用的是Windows 2012或更高版本，
使用Get-Cluster Resource命令。
如果您使用的是Windows 2008 R2，
使用已注释掉的cluster res命令。

Get-ClusterResource $ IPResourceName
Set-ClusterParameter -Multiple @ {“Address”=“$ CloudServiceIP”;
“ProbePort”= “59999”;子网掩码= “255.255.255.255”;
“网络”= “$ ClusterNetworkName”; “OverrideAddressMatch”= 1; “EnableDHCP时”= 0}

#cluster res $ IPResourceName / priv enabledhcp = 0 
overrideaddressmatch = 1 address = $ CloudServiceIP probeport = 59999 
子网掩码= 255.255.255.255

最后一个注释

在我最初的测试中，即使完成了上述所有步骤，我仍然无法连接到SQL资源名称。在将我的头靠在墙上几个小时后，我发现由于某种原因，SQL群集名称资源未在DNS中注册。我不确定这是怎么发生的，或者是否会一直发生。 如果您在连接时遇到问题，我一定会检查DNS。另外，如果SQL集群名称和IP地址不在那里，则将其添加为新的记录。

当然，别忘了Windows防火墙。您必须为1433和59999制定例外规定，或者关闭它直到您像我一样正确配置所有设置。您可能想要利用Azure网络安全组而不是本地Windows防火墙，以获得跨所有Azure资源的更加统一的体验。

祝你好运，让我知道你的经验如何配置SQL Server AlwaysOn内部负载平衡器与资源管理器。

转载https://clusteringformeremortals.com/2015/10/29/configuring-the-sql-server-alwayson-ilb-for-the-client-listener-in-azure-resource-manager-arm-deployment-模型sqlpass /