Date: 6月 15, 2018
在ARM中配置#AZURE ILB对于SQL Server故障转移群集实例或AG使用AZURE Powershell 1.0
在之前的文章中,我详细介绍了如何在ARM中为SQL Server故障转移群集或AG资源配置Azure ILB。该文章的方向是在Azure PowerShell 1.0的GA之前编写的。由于Azure PowerShell 1.0的可用性,创建ILB的主要脚本需要略有不同。文章的其余部分仍然准确。但是,如果您使用的是Azure PowerShell 1.0或更高版本,则在该文章中描述的创建ILB的脚本应如下所示。
#替换下面列出的变量的值 $ ResourceGroupName ='SIOS-EAST'#资源组部署SQL节点的名称 $ FrontEndConfigurationName ='FEEAST'#您可以为此参数提供任何名称。 $ BackendConfiguratioName ='BEEAST'#您可以为此参数提供任何名称。 $ LoadBalancerName ='ILBEAST'#为内部本地余额对象提供一个名称 $ Location ='eastus2'#输入SQL Deployements的数据中心位置 $ subname ='public'#提供放置SQL节点的子网名称 $ ILBIP = '10 .0.0.201'#为监听器或负载均衡器提供IP地址 $ subnet = Get-AzureRMVirtualNetwork -ResourceGroupName $ ResourceGroupName | Get-AzureRMVirtualNetworkSubnetConfig -name $ subname $ FEConfig = New-AzureRMLoadBalancerFrontendIpConfig -Name $ FrontEndConfigurationName -PrivateIpAddress $ ILBIP -SubnetId $ subnet.Id $ BackendConfig =新AzureRMLoadBalancerBackendAddressPoolConfig -Name $ BackendConfiguratioName New-AzureRMLoadBalancer -Name $ LoadBalancerName -ResourceGroupName $ ResourceGroupName -Location $ Location -FrontendIpConfiguration $ FEConfig -BackendAddressPool $ BackendConfig
该原始文章的其余部分是相同的,但我刚刚在这里复制它以方便使用…
使用GUI
现在创建了ILB,我们应该在资源组的Azure门户中看到它。见下面的图片。
剩下的配置也可以通过PowerShell完成,但我将在我的示例中使用GUI。
如果您想使用PowerShell,您可以通过查看本文来拼凑脚本。 不幸的是,这篇文章迷惑了我。我会在一天之内弄清楚它的存在并尝试以用户友好的格式记录它。到目前为止,我认为GUI对于下一步很好。
让我们开始吧
跟随下面的屏幕截图。如果您迷路了,请按照Azure门户顶部的导航提示找出我们的位置。
第一步
- 点击后台池设置标签。选择后端池来更新可用性集和虚拟机。保存您的更改。
- 通过单击探针选项卡上的添加来配置负载平衡器的探针。为该探测器命名并将其配置为使用TCP端口59999。我已将探测间隔和不健康阈值设置为默认设置。这意味着ILB在故障切换后从被激活节点列表中移除被动节点需要10秒钟的时间。您的客户可能需要长达10秒才能重定向到新的活动节点。一定要保存您的更改。
下一步
- 导航到“负载平衡规则”选项卡并添加新规则。给规则一个明智的名字(SQL1433或其他)。 选择TCP协议端口1433(假设您正在使用SQL Server的默认实例)。为后端端口选择1433。对于后端池,我们将选择我们之前创建的后端池(BE)。 对于探测器,我们也将选择我们之前创建的探测器。
我们不想启用会话持久性,但我们希望启用浮动IP(直接服务器返回)。我已将空闲超时设置为默认设置。您可能需要考虑将其提高到最大值。原因是每次连接断开并需要重新建立时,我都会看到一些应用程序,如SAP日志错误消息。
- 此时配置ILB。 SQL Server故障转移群集只需要执行一个最后步骤。我们需要更新SQL IP群集资源,就像我们在Classic部署模型中所用的一样。为此,您只需在其中一个群集节点上运行以下PowerShell脚本。请注意,SubnetMask =“255.255.255.255”不是一个错误。 无论您的实际子网掩码是什么,都使用32位掩码。
最后一个注释
在我最初的测试中,即使完成了上述所有步骤,仍然无法连接到SQL资源名称。在将我的头靠在墙上几个小时后,我发现由于某种原因,SQL群集名称资源未在DNS中注册。我不确定这是怎么发生的或者它是否会一致发生,但是如果连接时遇到问题,我肯定会检查DNS,并将SQL集群名称和IP地址添加为新的A记录(如果它尚未存在)。
当然,别忘了Windows防火墙。您必须为1433和59999制定例外规定,或者关闭它直到您像我一样正确配置所有设置。您可能想要利用Azure网络安全组而不是本地Windows防火墙,以获得跨所有Azure资源的更加统一的体验。
祝你好运,让我知道你是如何做出的。
转到此处,了解SIOS如何帮助全球各地的公司创建SQL Server故障转移群集。
经过Clustering For Mere Mortals的许可转载。