ARM中的Azure ILB对于SQL Server故障转移群集实例

在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的许可转载。

高服务级别的高可用性群集解决方案

使用高可用性群集解决方案改进订购流程

日本隐形眼镜协会有一个在线订购系统，全年接受经销商向制造商和代理商的订单。SCSK有限公司（以下简称SCSK）管理该系统。他们增加了SCSK的基础设施云服务“USiZE共享模型”，开业率为99.99％。与此同时，他们还包括LifeKeeper，以确保云和DataKeeper中的高占用率，以构建高可用性群集解决方案的运营基础架构。借助这些软件，团队不仅可以检测硬件和虚拟机以及应用程序中的异常情况。即使遇到危机，他们也建立了一套快速恢复和继续提供服务的体系。

隐形眼镜订购平台，为云端提供24小时365天服务

高服务级别的高可用性群集解决方案

使用高可用性群集解决方案改进订购流程

日本隐形眼镜协会有一个在线订购系统，全年接受经销商向制造商和代理商的订单。SCSK有限公司（以下简称SCSK）管理该系统。他们增加了SCSK的基础设施云服务“USiZE共享模型”，开业率为99.99％。与此同时，他们还包括LifeKeeper，以确保云和DataKeeper中的高占用率，以构建高可用性群集解决方案的运营基础架构。 借助这些软件，团队不仅可以检测硬件和虚拟机以及应用程序中的异常情况。 即使遇到危机，他们也建立了一套快速恢复和继续提供服务的体系。

隐形眼镜订购平台，为云端提供24小时365天服务

SANLess集群解决方案可确保可用性和性能

在使用本地磁盘的操作环境中确保高可用性和性能

MT Eye利用SIOS DataKeeper和Windows Server故障转移群集实现了SANLess群集解决方案

MT Eye提供与日常生活密切相关的各种内容服务，包括“music.jp”和“Lunarna”。共享存储对于支持他们的操作至关重要。但是，每个站点都有不同的存储要求。由于共享存储只提供一种设置，问题很快就会浮现出来。该公司切换到基于每个站点本地磁盘的操作系统。在这种新环境下，该公司旨在确保与不需要共享存储的集群解决方案相同的可用性。

从共享存储切换到使用本地磁盘SANLess集群解决方案

MT Eye主要从事内容分发服务，使日常生活愉快和方便。他们的产品从娱乐到生活方式信息和医疗保健。共享存储已被定位为支持各种服务操作的IT基础架构的中心。通过从共享存储中分配每个站点所需的数量，公司享有经济高效的运营。然而，多年来，运营体制的问题逐渐兴起。MT Eye被迫做出重大决定，因为其运营共享存储不再有任何维护服务。基础系统部门的Hiroyuki Okawa解释说，即使他们购买了新的共享存储，他们当前的IT系统也不能保证运行良好。另外，他们冒着可能导致某些网站运营成本高的风险。因此，山。Eye加强为每个站点操作本地磁盘。不幸的是，这也没有被证明是一帆风顺的。即使它是本地磁盘，也必须保持与共享存储相同的可用性级别，并且必须维护性能级别。

WSFC和DataKeeper结合始终保证高可用性

在寻找解决方案时，MT Eye首先专注于使用Microsoft SQL Server的功能之一Always On availability组。它在多个站点之间镜像数据库，并在发生故障时自动进行故障切换。为了使用Always On可用性组，必须将Microsoft SQL Server从标准版升级到企业版。要做到这一点会导致成本大幅增加。他们发现他们可以拥有使用Windows Server标准故障转移群集功能和SIOS DataKeeper的SANLess群集解决方案。大川强调通过这种方式，他们可以继续将Microsoft SQL Server作为标准版。但同时，请确保与Always On可用性组具有相同的可用性。知道集成了LifeKeeper和DataKeeper的集群配置已经存在于另一个基于Linux系统的系统上，这也很棒。基础设施系统部门的Tomioka Tetsuhei仍然不确定。为了缓解他的不确定性，该公司借鉴了SIOS的DataKeeper验证许可证进行测试。他们汇集了一个接近实际操作的集群配置，并在2016年2月至3月期间重复进行了详细的性能验证。与使用共享存储的传统系统配置相比，性能也有所下降。他补充说，根据系统要求，他们可以在同步和异步复制模式之间进行选择，这是非常有益的。

节省数据中心和基础设施运营成本

截至2017年3月，MT Eye已完成向“Life Ranger Navi”（生活信息服务）和“Lunarna”等网站的SANLess集群解决方案过渡。他们计划完成公司网站上最大的“music.jp”的过渡。随着完成，最终有可能提供与每个站点的不同要求对应的存储资源，例如强调性能和容量。如果该公司完全消除了共享存储的使用，他们可以节省建立数据中心。这也意味着他们可以一起从机架上移除SAN交换机等网络设备。此外，SANLess集群解决方案还可以迁移到主要的公有云环境，如Amazon Web Service和Microsoft Azure。可以说，MT Eye基础设施获得了前所未有的灵活性，并可以响应各个站点的需求。要了解更多关于SIOS产品的信息，请点击这里
要了解SIOS如何帮助MT Eye实现SANless群集解决方案，请点击此处

SANLess集群解决方案可确保可用性和性能

在使用本地磁盘的操作环境中确保高可用性和性能

MT Eye利用SIOS DataKeeper和Windows Server故障转移群集实现了SANLess群集解决方案

MT Eye提供与日常生活密切相关的各种内容服务，包括“music.jp”和“Lunarna”。 共享存储对于支持他们的操作至关重要。 但是，每个站点都有不同的存储要求。由于共享存储只提供一种设置，问题很快就会浮现出来。

该公司切换到基于每个站点本地磁盘的操作系统。 在这种新环境下，该公司旨在确保与不需要共享存储的集群解决方案相同的可用性。

从共享存储切换到使用本地磁盘SANLess集群解决方案

MT Eye主要从事内容分发服务，使日常生活愉快和方便。他们的产品从娱乐到生活方式信息和医疗保健。

共享存储已被定位为支持各种服务操作的IT基础架构的中心。 通过从共享存储中分配每个站点所需的数量，公司享有经济高效的运营。

然而，多年来，运营体制的问题逐渐兴起。MT Eye被迫做出重大决定，因为其运营共享存储不再有任何维护服务。 基础系统部门的Hiroyuki Okawa解释说，即使他们购买了新的共享存储，他们当前的IT系统也不能保证运行良好。另外，他们冒着可能导致某些网站运营成本高的风险。 因此，山。Eye加强为每个站点操作本地磁盘。不幸的是，这也没有被证明是一帆风顺的。即使它是本地磁盘，也必须保持与共享存储相同的可用性级别，并且必须维护性能级别。

WSFC和DataKeeper结合始终保证高可用性

在寻找解决方案时，MT Eye首先专注于使用Microsoft SQL Server的功能之一Always On availability组。 它在多个站点之间镜像数据库，并在发生故障时自动进行故障切换。为了使用Always On可用性组，必须将Microsoft SQL Server从标准版升级到企业版。要做到这一点会导致成本大幅增加。

他们发现他们可以拥有使用Windows Server标准故障转移群集功能和SIOS DataKeeper的SANLess群集解决方案。大川强调通过这种方式，他们可以继续将Microsoft SQL Server作为标准版。 但同时，请确保与Always On可用性组具有相同的可用性。知道集成了LifeKeeper和DataKeeper的集群配置已经存在于另一个基于Linux系统的系统上，这也很棒。

基础设施系统部门的Tomioka Tetsuhei仍然不确定。为了缓解他的不确定性，该公司借鉴了SIOS的DataKeeper验证许可证进行测试。他们汇集了一个接近实际操作的集群配置，并在2016年2月至3月期间重复进行了详细的性能验证。与使用共享存储的传统系统配置相比，性能也有所下降。 他补充说，根据系统要求，他们可以在同步和异步复制模式之间进行选择，这是非常有益的。

节省数据中心和基础设施运营成本

截至2017年3月，MT Eye已完成向“Life Ranger Navi”（生活信息服务）和“Lunarna”等网站的SANLess集群解决方案过渡。他们计划完成公司网站上最大的“music.jp”的过渡。随着完成，最终有可能提供与每个站点的不同要求对应的存储资源，例如强调性能和容量。

如果该公司完全消除了共享存储的使用，他们可以节省建立数据中心。这也意味着他们可以一起从机架上移除SAN交换机等网络设备。此外，SANLess集群解决方案还可以迁移到主要的公有云环境，如Amazon Web Service和Microsoft Azure。 可以说，MT Eye基础设施获得了前所未有的灵活性，并可以响应各个站点的需求。

要了解有关SIOS产品的更多信息，请访问此处
要了解SIOS如何帮助MT Eye实现SANless Cluster Solution，请转到此处