Azure自动关闭虚拟机

Azure自动关闭虚拟机

我尝试使我的Azure MSDN订阅信用延长整个月。但是通过Azure Auto Shutdown For Virtual Machines，我的神经可以承受一点点休息。我通常只是构建实验室来试用新功能或在Azure中演示SQL Server故障转移群集。很多时候我正在测试一些非常大的实例大小和大量高级存储。可以想象，运行几个GS5实例可以快速烧掉150美元。我尝试注意并在完成后关闭或销毁实例。偶尔我会因为其他业务被拉开，只能在第二天登录并看到我的信用已过期，因为我忘了关闭虚拟机。我很高兴看到现在很容易为虚拟机配置Azure自动关机。 但请记住，这只是关闭实例。如果您附加了高级存储，即使实例关闭，您仍将继续为存储付费。

在Azure中部署2节点文件服务器故障转移群集

使用SIOS DataKeeper在Azure IAAS（ARM）中部署高可用性文件服务器

在本文中，我们将详细介绍使用Azure Resource Manager在Azure的单个区域中在Azure中部署双节点文件服务器故障转移群集所需的特定步骤。我将假设您熟悉基本的Azure概念以及基本的故障转移群集概念。在本文中，我们将介绍在Azure中部署文件服务器故障转移群集的独特之处。使用DataKeeper Cluster Edition，您可以获取本地连接的存储，无论是高级存储还是标准磁盘，并在两个或多个集群节点之间同步，异步或混合或同时复制这些磁盘。此外，DataKeeper Volume资源在Windows Server故障转移群集中注册，该资源取代了物理磁盘资源。DataKeeper Volume不是像物理磁盘资源那样控制SCSI-3保留，而是控制镜像方向，确保活动节点始终是镜像源。就故障转移群集而言，它的外观，感觉和气味就像物理磁盘一样，其使用方式与物理磁盘资源的使用方式相同。

在Azure中部署双节点文件服务器故障转移群集的先决条件

• 您之前使用过Azure Portal，并且很乐意在Azure IaaS中部署虚拟机。
• 已获得SIOS DataKeeper的许可证或eval许可证

使用Azure门户部署文件服务器故障转移群集实例

要在Azure中部署双节点文件服务器故障转移群集，我们假设您拥有基于Azure资源管理器的基本虚拟网络，并且至少有一个虚拟机已启动并运行并配置为域控制器。配置虚拟网络和域后，您将配置两个新虚拟机，它们将充当群集中的两个节点。我们的环境将如下所示：DC1 – 我们的域控制器和文件共享见证SQL1和SQL2 – 我们的文件服务器群集的两个节点

配置两个群集节点（SQL1和SQL2）

使用Azure门户，我们将以完全相同的方式配置SQL1和SQL2。有多种选择可供选择，包括实例大小，存储选项等。本指南并不是在Azure中部署服务器的详尽指南，因为有一些非常好的资源，每天都有更多的资源发布。但是，在创建实例时要记住几个关键事项，尤其是在群集环境中。可用性集 – SQL1，SQL2和DC1都位于同一可用性集中非常重要。通过将它们放在相同的可用性集中，我们确保每个群集节点和文件共享见证驻留在不同的故障域和更新域中。这有助于确保在计划维护和计划外维护期间，群集将继续能够维持法定人数并避免停机。 图3 – 确保将群集节点和文件共享见证添加到同一可用性集

静态IP地址

配置每个VM后，您将需要进入设置并更改设置，以使IP地址为静态。我们不希望更改群集节点的IP地址。 图4 – 确保每个群集节点都使用静态IP

存储

就存储而言，您将需要参考Azure虚拟机中SQL Server的性能最佳实践。在任何情况下，您至少需要为每个群集节点添加至少一个额外的磁盘。DataKeeper可以使用基本磁盘，高级存储甚至是存储池中包含多个磁盘的存储池。只需确保为每个群集节点添加相同数量的存储并以相同方式对其进行配置。此外，请确保为每个虚拟机使用不同的存储帐户，以确保一个存储帐户的问题不会同时影响两个虚拟机。 图5 – 确保为每个群集节点添加额外的存储

创建群集

假设已按上述方式配置了两个群集节点（SQL1和SQL2）并将其添加到现有域中，我们就可以创建群集了。在创建群集之前，需要启用一些功能。这些功能是.Net Framework 3.5和故障转移群集。需要在两个群集节点上启用这些功能。您还需要启用FIle服务器角色。 图6 – 在两个群集节点上启用.Net Framework 3.5和故障转移群集功能以及文件服务器一旦启用了该角色和这些功能，您就可以构建群集了。我要向您展示的大多数步骤都可以通过PowerShell和GUI执行。但是，我将建议您在第一步中使用PowerShell创建群集。如果您选择使用故障转移群集管理器GUI来创建群集，您会发现群集正在发出重复的IP地址。

要注意的细节

在不详细介绍的情况下，您会发现Azure VM必须使用DHCP。通过在Azure门户中创建VM时指定“静态IP”，我们所做的就是创建一种DHCP预留。它不完全是DHCP保留，因为真正的DHCP保留会从DHCP池中删除该IP地址。相反，在Azure门户中指定静态IP只是意味着如果VM请求它时该IP地址仍然可用，Azure将向其发出该IP。但是，如果您的VM处于脱机状态且另一台主机在同一子网中联机，则可能会发出相同的IP地址。Azure实施DHCP的方式还有另一个奇怪的副作用。在主机使用DHCP（必须使用DHCP）时使用Windows Server Failover Cluster GUI创建群集时，无法指定群集IP地址。相反，它依靠DHCP来获取地址。奇怪的是，DHCP将发出重复的IP地址，通常与请求新IP地址的主机具有相同的IP地址。群集通常会完成，但您可能会遇到一些奇怪的错误，您可能需要从其他节点运行Windows Server Failover Cluster GUI才能运行它。一旦运行它，您将需要将群集IP地址更改为网络上当前未使用的地址。

避免混乱

只需通过Powershell创建集群并指定集群IP地址作为PowerShell命令的一部分来创建集群，就可以避免这种混乱。您可以使用New-Cluster命令创建集群，如下所示：

New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.0.0.101 -NoStorage

群集创建完成后，您还需要运行以下命令来运行群集验证：

测试群集

图7 – 集群创建的输出和集群验证命令

创建文件共享见证

由于没有共享存储，因此您需要在与两个群集节点相同的可用性集中的另一台服务器上创建文件共享见证。通过将其置于相同的可用性集中，您可以确保在任何给定时间仅从您的法定人数中失去一票。如果您不确定如何创建文件共享见证，可以查看本文http://www.howtonetworking.com/server/cluster12.htm。在我的演示中，我将文件共享见证放在域控制器上。我已经在https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-上发布了对群集仲裁的详尽解释。在窗口服务器-2012-R2 /

安装DataKeeper

创建集群后，就可以安装DataKeeper了。在创建初始群集后安装DataKeeper非常重要，这样可以向群集注册自定义群集资源类型。如果在创建群集之前安装了DataKeeper，则只需再次运行安装并执行修复安装。 图8 – 创建集群后安装DataKeeper在安装过程中，您可以使用所有默认选项。 您使用的服务帐户必须是域帐户，并且位于群集中每个节点上的本地管理员组中。 图9 – 服务帐户必须是每个节点上Local Admins组中的域帐户一旦在每个节点上安装DataKeeper并获得许可，您将需要重新启动服务器。

创建DataKeeper卷资源

要创建DataKeeper Volume Resource，您需要启动DataKeeper UI并连接到这两个服务器。 连接到SQL1连接到SQL2连接到每个服务器后，您就可以创建DataKeeper卷了。右键单击Jobs并选择“Create Job”为作业命名和描述。 选择源服务器，IP和卷。IP地址是复制流量是否会传播。 选择目标服务器。 选择你的选择。对于两个VM位于同一地理区域的目的，我们将选择同步复制。对于更长距离的复制，您将需要使用异步并启用一些压缩。 通过在上次弹出窗口中单击“是”，您将在故障转移群集中的可用存储中注册新的DataKeeper卷资源。您将在可用存储中看到新的DataKeeper卷资源。

创建文件服务器群集资源

要创建文件服务器群集资源，我们将再次使用Powershell而不是故障转移群集接口。原因在于，再次因为虚拟机配置为使用DHCP，基于GUI的向导不会提示我们输入群集IP地址，而是发出重复的IP地址。为避免这种情况，我们将使用简单的powershell命令创建FIle Server群集资源并指定IP地址

Add-ClusterFileServerRole -Storage“DataKeeper Volume E” 
-Name FS2 -StaticAddress 10.0.0.201

记下您在此处指定的IP地址。它必须是网络上唯一的IP地址。我们稍后在创建内部负载均衡器时将使用相同的IP地址。

创建内部负载均衡器

以下是Azure中的故障转移群集与传统基础结构的不同之处。Azure网络堆栈不支持免费ARPS。 客户端无法直接连接到群集IP地址。相反，客户端连接到内部负载平衡器并重定向到活动群集节点。我们需要做的是创建一个内部负载均衡器。这可以通过Azure门户完成，如下所示。首先，创建一个新的Load Balancer如果您的客户端通过公共Internet连接，您可以使用公共负载均衡器，但假设您的客户端位于同一个vNet中，我们将创建一个内部负载均衡器。需要注意的重要一点是，虚拟网络与群集节点所在的网络相同。此外，您指定的专用IP地址将与用于创建SQL群集资源的地址完全相同。 创建内部负载均衡器（ILB）后，您需要对其进行编辑。我们要做的第一件事就是添加一个后端池。通过此过程，您将选择SQL Cluster VM所在的可用性集。但是，当您选择要添加到后端池的实际VM时，请确保不要选择文件共享见证。我们不希望将SQL流量重定向到您的文件共享见证。 接下来我们要做的就是添加一个Probe。我们添加的探针将探测端口59999。此探针确定群集中哪个节点处于活动状态。 最后，我们需要一个负载平衡规则来重定向SMB流量，TCP端口445。在下面的屏幕截图中需要注意的重要事项是直接服务器返回已启用。确保你做出改变。

修复文件服务器IP资源

几乎可以在Azure中部署2节点文件服务器故障转移群集！配置的最后一步是在其中一个群集节点上运行以下PowerShell脚本。这将允许群集IP地址响应ILB探测并确保群集IP地址和ILB之间不存在IP地址冲突。请注意;您需要编辑此脚本以适合您的环境。子网掩码设置为255.255.255.255，这不是错误，保持原样。这将创建一个特定于主机的路由，以避免与ILB发生IP地址冲突。

＃定义变量
$ ClusterNetworkName =“” 
＃群集网络名称 
（在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名称）
$ IPResourceName =“” 
#IP地址资源名称 
$ ILBIP =“” 
＃内部负载均衡器的IP地址（ILB）
导入模块FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName | SET-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”;
网络= $ ClusterNetworkName; EnableDHCP时= 0}
＃如果您使用的是Windows Server 2008 R2，请使用以下命令： 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
子网掩码= 255.255.255.255

创建文件共享

您会发现在故障转移群集管理器中使用文件共享向导不起作用。相反，您只需在活动节点上的Windows资源管理器中创建文件共享。故障转移群集会自动获取这些共享并将其放入群集中。请注意，此配置不支持文件共享的“连续可用性”选项。

结论

您已设法在Azure中部署双节点文件服务器故障转移群集。  如果您有任何问题，请通过Twitter @daveberm联系我，我很乐意提供帮助。如果您需要DataKeeper评估密钥，请填写http://us.sios.com/clustersyourway/cta/14-day-trial上的表格，SIOS将发送一份发送给您的评估密钥。经Clusteringformeremortals.com许可转载

SQL Server 2016支持分布式事务

SQL Server 2016支持使用AlwaysOn可用性组的分布式事务

SQL Server 2016对具有Always On Availability Groups的分布式事务的支持听​​起来非常有前景。 他们确实在这方面做了一些改进，但尚未完全支持。分发事务源示例 – 可用性组中的SQL Server 2016 DTC支持[/ caption]仅在事务处理时支持SQL Server 2016支持分布式事务分布在多个SQL Server实例中。如果事务在同一SQL Server实例中的不同数据库之间分发，则不支持它。因此，在上图中，如果数据库位于不同的SQL实例上，它将起作用。但是，如果数据库驻留在更可能的同一实例上，则不会。如果在同一SQL Server实例中的不同数据库之间需要分布式事务支持并且需要高可用性，则仍必须使用传统的SQL Server Always On Failover Cluster或使用DataKeeper的SANLess Cluster。经Clusteringformeremortals.com许可转载

如何更改现有Azure VM的可用性集

更改现有Azure VM的可用性集

2016年6月21日 – 更新。自从我发布这篇文章以来，一位可靠的消息来源告诉我，有一个更新的PowerShell脚本可以更可靠地更改现有Azure VM的可用性集。我还没有尝试过。但我相信来源和Microsoft Premiere Support指导他阅读本文。https://gallery.technet.microsoft.com/Azure-RM-Availability-Set-39e19d01我有点惊讶地发现，在创建虚拟机后，更改VM所在的可用性集并不容易。Azure门户没有将现有VM添加到可用性集的机制。幸运的是，我偶然发现了这个巨大的资源。设置Azure资源管理器VM可用性集通过利用该文章中可供下载的PowerShell脚本，我能够将两个现有VM添加到我创建的内容中。最后，我可以更改现有Azure VM的可用性集 – 真正的救命！

在Azure资源管理器中部署SQL Server故障转移群集

在Azure Resource Manager中部署Microsoft SQL Server 2014故障转移群集

在本文中，我们将详细介绍在Azure Resource Manager中部署SQL Server故障转移群集所需的特定步骤。我将假设您熟悉基本的Azure概念以及基本的SQL Server故障转移群集概念。使用Azure资源管理器在Azure的单个区域中部署双节点SQL Server故障转移群集并不是一门火箭科学。我将在本文中关注的是在Azure Resource Manager中部署SQL Server故障转移群集的独特性。如果您仍在使用Azure Classic并且需要在Classic中部署SQL Server故障转移群集，请阅读我的文章“STEP-BY-STEP：如何在MICROSOFT AZURE IAAS中配置SQL SERVER FAILOVER群集实例（FCI）#SQLSERVER #AZURE＃ SANLESS“在开始之前，让我们熟悉Azure虚拟机中SQL Server的Windows Azure文章，高可用性和灾难恢复。在该文章中概述了所有HA选项。这包括AlwaysOn AG，数据库镜像，日志传送，备份和还原以及最终故障转移群集实例。假设由于与SQL Server企业版相关的成本或缺乏功能而忽略了其他选项，我们将重点关注最终选项 – SQL Server AlwaysOn故障转移群集实例（FCI）。当您阅读该文章时，很明显Azure中缺少群集感知共享存储是部署SQL Server故障转移群集的障碍。但是，该文章中描述了一些替代方案。我们将专注于使用SIOS DataKeeper，以提供要在群集中使用的存储。图1 Microsoft对SQL Server故障转移群集的支持策略https://azure.microsoft.com/en-us/documentation/articles/virtual-machines– windows-classic-sql-dr / [/ caption]使用DataKeeper Cluster Edition，您可以获取本地连接的存储，无论是Premium还是标准磁盘，并在两个磁盘之间同步，异步或混合或同时复制这些磁盘或更多群集节点。此外，DataKeeper Volume资源在Windows Server故障转移群集中注册，该资源取代了物理磁盘资源。DataKeeper Volume不是像物理磁盘资源那样控制SCSI-3保留，而是控制镜像方向，确保活动节点始终是镜像源。就SQL Server和故障转移群集而言，它的外观，感觉和气味就像物理磁盘一样，其使用方式与物理磁盘资源的使用方式相同。

在Azure资源管理器中部署SQL Server故障转移群集的先决条件

• 您之前使用过Azure Portal，并且很乐意在Azure IaaS中部署虚拟机。
• 已获得SIOS DataKeeper的许可证或eval许可证
• 熟悉SQL Server AlwaysOn故障转移群集实例。如果没有，请查看此处的文档https://msdn.microsoft.com/en-us/library/ms189134.aspx

简单的方法来做概念验证

如果您熟悉Azure资源管理器，您就会发现其中一项重要的新功能是能够使用部署模板快速部署由相互关联的Azure资源组成的应用程序。其中许多模板都是由Microsoft开发的，并且可以在Github上的社区中以“快速入门模板”的形式获得。社区成员也可以自由扩展模板或在GitHub上发布自己的模板。SIOS Technology发布的一个名为“带有SIOS DataKeeper Azure部署模板的SQL Server 2014 AlwaysOn故障转移群集实例”的模板完全自动化了将2节点SQL Server FCI部署到新的Active Directory域的过程。要部署此模板，只需单击模板中的“部署到Azure”按钮即可。图2-访问https://github.com/SIOSDataKeeper/SIOSDataKeeper-SQL-Cluster以快速配置双节点SQL群集[/ caption]

使用Azure门户部署SQL Server故障转移群集实例

虽然自动Azure部署模板是一种快速简便的方法，可以快速获得双节点SQL Server FCI，但存在一些限制。首先，它使用SQL Server的180天评估版本，因此除非升级SQL eval许可证，否则不能在生产中使用它。此外，它构建了一个全新的AD域，因此如果要与现有域集成，则必须手动构建它。要在Azure中构建一个双节点SQL Server故障转移群集实例，我们假设您有一个基于Azure资源管理器（而不是Azure Classic）的基本虚拟网络，并且您至少有一个虚拟机已启动并运行并配置为域控制器。配置虚拟网络和域后，您将配置两个新虚拟机，它们将充当群集中的两个节点。我们的环境将如下所示：DC1 – 我们的域控制器和文件共享见证SQL1和SQL2 – 我们的SQL Server群集的两个节点

配置群集节点（SQL1和SQL2）

使用Azure门户，我们将以完全相同的方式配置SQL1和SQL2。有多种选择可供选择，包括实例大小，存储选项等。本指南并不是在Azure中部署SQL Server的详尽指南，因为有一些非常好的资源，每天都有更多的资源发布。但是，在创建实例时要记住几个关键事项，尤其是在群集环境中。可用性集 – SQL1，SQL2和DC1都位于同一可用性集中非常重要。通过将它们放在相同的可用性集中，我们确保每个群集节点和文件共享见证驻留在不同的故障域和更新域中。这有助于确保在计划维护和计划外维护期间，群集将继续能够维持法定人数并避免停机。图3 – 确保将两个群集节点和文件共享见证添加到同一个可用性集[/ caption]

静态IP地址

配置每个VM后，您将需要进入设置并更改设置，以使IP地址为静态。我们不希望更改群集节点的IP地址。图4 – 确保每个群集节点都使用静态IP [/ caption]

存储

就存储而言，您将需要参考Azure虚拟机中SQL Server的性能最佳实践。在任何情况下，您至少需要为每个群集节点添加至少一个额外的磁盘。DataKeeper可以使用基本磁盘，高级存储甚至是存储池中包含多个磁盘的存储池。只需确保为每个群集节点添加相同数量的存储并以相同方式对其进行配置。图5 – 确保为每个群集节点添加额外的存储空间[/ caption]

创建群集

假设已按上述方式配置了两个群集节点（SQL1和SQL2）并将其添加到现有域中，我们就可以创建群集了。在创建群集之前，需要启用一些功能。这些功能是.Net Framework 3.5和故障转移群集。需要在两个群集节点上启用这些功能。图6 – 在两个群集节点上启用.Net Framework 3.5和故障转移群集功能[/ caption]一旦启用了这些功能，您就可以构建您的集群。我要向您展示的大多数步骤都可以通过PowerShell和GUI执行。但是，我将建议您在第一步中使用PowerShell创建群集。如果您选择使用故障转移群集管理器GUI来创建群集，您会发现群集正在发出重复的IP地址。在不详细介绍的情况下，您会发现Azure VM必须使用DHCP。通过在Azure门户中创建VM时指定“静态IP”，我们所做的就是创建一种DHCP预留。它不完全是DHCP保留，因为真正的DHCP保留会从DHCP池中删除该IP地址。相反，在Azure门户中指定静态IP只是意味着如果在VM请求它时该IP地址仍然可用，Azure将向其发出该IP。但是，如果您的VM处于脱机状态且另一台主机在同一子网中联机，则可能会发出相同的IP地址。Azure实施DHCP的方式还有另一个奇怪的副作用。在主机使用DHCP（必须使用DHCP）时使用Windows Server Failover Cluster GUI创建群集时，无法指定群集IP地址。相反，它依靠DHCP来获取地址。奇怪的是，DHCP将发出重复的IP地址，通常与请求新IP地址的主机具有相同的IP地址。群集通常会完成，但您可能会遇到一些奇怪的错误，您可能需要从其他节点运行Windows Server Failover Cluster GUI才能运行它。一旦运行它，您将需要将群集IP地址更改为网络上当前未使用的地址。只需通过Powershell创建集群并指定集群IP地址作为PowerShell命令的一部分来创建集群，就可以避免这种混乱。您可以使用New-Cluster命令创建集群，如下所示：

New-Cluster -Name cluster1 -Node sql1，sql2 -StaticAddress 10.0.0.101 -NoStorage

群集创建完成后，您还需要运行以下命令来运行群集验证：

测试群集

图7 – 集群创建的输出和集群验证命令[/ caption]

创建文件共享见证

由于没有共享存储，因此您需要在与两个群集节点相同的可用性集中的另一台服务器上创建文件共享见证。通过将其置于相同的可用性集中，您可以确保在任何给定时间仅从您的法定人数中失去一票。如果您不确定如何创建文件共享见证，可以查看本文http://www.howtonetworking.com/server/cluster12.htm。在我的演示中，我将文件共享见证放在域控制器上。我已经在https://blogs.msdn.microsoft.com/microsoft_press/2014/04/28/from-the-mvps-understanding-the-windows-server-failover-cluster-quorum-上发布了对群集仲裁的详尽解释。在窗口服务器-2012-R2 /在

安装DataKeeper

创建集群后，就可以安装DataKeeper了。在创建初始群集后安装DataKeeper非常重要，这样可以向群集注册自定义群集资源类型。如果在创建群集之前安装了DataKeeper，则只需再次运行安装并执行修复安装。图8 – 创建集群后安装DataKeeper [/ caption]在安装过程中，您可以使用所有默认选项。 您使用的服务帐户必须是域帐户，并且位于群集中每个节点上的本地管理员组中。图9 – 服务帐户必须是每个节点上Local Admins组中的域帐户[/ caption]一旦安装DataKeeper并获得许可您将需要重新启动服务器的每个节点。

创建DataKeeper卷资源

要创建DataKeeper Volume Resource，您需要启动DataKeeper UI并连接到这两个服务器。 连接到SQL1连接到SQL2连接到每个服务器后，您就可以创建DataKeeper卷了。右键单击Jobs并选择“Create Job”为作业命名和描述。 选择源服务器，IP和卷。IP地址是复制流量是否会传播。 选择目标服务器。 选择你的选择。对于两个VM位于同一地理区域的目的，我们将选择同步复制。对于更长距离的复制，您将需要使用异步并启用一些压缩。 通过在上次弹出窗口中单击“是”，您将在故障转移群集中的可用存储中注册新的DataKeeper卷资源。 您将在可用存储中看到新的DataKeeper卷资源。  

安装第一个群集节点

您现在可以安装第一个节点了。群集安装将像您构建的任何其他SQL群集一样继续。我没有复制每一个屏幕截图，只是为了引导你一路走来。 您会看到DataKeeper Volume Resource被识别为可用磁盘资源，就像它是共享磁盘一样。 记下您在此处选择的IP地址。它必须是网络上唯一的IP地址。我们稍后在创建内部负载均衡器时将使用相同的IP地址。

添加第二个节点

第一个节点成功安装后，您将使用“将节点添加到SQL Server故障转移群集”选项在第二个节点上开始安装。再一次，安装非常简单，只需使用标准的最佳实践，就像使用任何其他SQL群集安装一样。

创建内部负载均衡器

以下是Azure中的故障转移群集与传统基础结构的不同之处。Azure网络堆栈不支持免费ARPS，因此客户端无法直接连接到群集IP地址。相反，客户端连接到内部负载平衡器并重定向到活动群集节点。我们需要做的是创建一个内部负载均衡器。这可以通过Azure门户完成，如下所示。首先，创建一个新的Load Balancer如果您的客户端通过公共Internet连接，您可以使用公共负载均衡器。但假设您的客户端位于同一个vNet中，我们将创建一个内部负载均衡器。需要注意的重要一点是，虚拟网络与群集节点所在的网络相同。此外，您指定的专用IP地址将与用于创建SQL群集资源的地址完全相同。 创建内部负载均衡器（ILB）后，您需要对其进行编辑。我们要做的第一件事就是添加一个后端池。通过此过程，您将选择SQL Cluster VM所在的可用性集。但是，当您选择要添加到后端池的实际VM时，请确保不要选择文件共享见证。我们不希望将SQL流量重定向到您的文件共享见证。 接下来我们要做的就是添加一个Probe。我们添加的探针将探测端口59999。此探针确定群集中哪个节点处于活动状态。 最后，我们需要一个负载平衡规则来重定向SQL Server流量。在我们的示例中，我们使用了一个使用端口1433的SQL默认实例。您可能还希望根据应用程序要求添加1434或其他规则。在下面的屏幕截图中需要注意的重要事项是直接服务器返回已启用。确保你做出改变。

修复SQL Server IP资源

在Azure资源管理器中部署SQL Server故障转移群集的最后一步。 在其中一个群集节点上运行以下PowerShell脚本。这将允许群集IP地址响应ILB探测并确保群集IP地址和ILB之间不存在IP地址冲突。请注意;您需要编辑此脚本以适合您的环境。子网掩码设置为255.255.255.255，这不是错误，保持原样。这将创建一个特定于主机的路由，以避免与ILB发生IP地址冲突。

＃定义变量
$ ClusterNetworkName =“” 
＃群集网络名称 
（在更高版本的Windows Server 2012上使用Get-ClusterNetwork查找名称）
$ IPResourceName =“” 
#IP地址资源名称 
$ ILBIP =“” 
＃内部负载均衡器的IP地址（ILB）
导入模块FailoverClusters
＃如果您使用的是Windows Server 2012或更高版本：
Get-ClusterResource $ IPResourceName | SET-ClusterParameter 
-Multiple @ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“255.255.255.255”;
网络= $ ClusterNetworkName; EnableDHCP时= 0}
＃如果您使用的是Windows Server 2008 R2，请使用以下命令： 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
子网掩码= 255.255.255.255

结论

您现在应该具有正常运行的SQL Server故障转移群集实例。面临在Azure资源管理器中部署SQL Server故障转移群集的问题？在Twitter @daveberm上联系我，我很乐意提供帮助。如果您需要DataKeeper评估密钥，请填写http://us.sios.com/clustersyourway/cta/14-day-trial上的表格，SIOS将发送一封发送给您的评估密钥。