Azure资源管理器（ARM）和JSON简介

如果您是ARM和JSON的新手，并且想要了解更多信息，那么您可以参加一个演示文稿，以便开始使用。就我个人而言，我强烈建议您查看这篇内容丰富的报告。Freddy vs JSON：使用Azure资源管理器构建您的云。它只是由微软Ignite澳大利亚的詹姆斯·班南提出的。演示文稿包含了ARM模板的使用工具和结构。我希望在今年早些时候开始研究ARM和JSON的时候有过这个。转载自https://clusteringformeremortals.com/2015/11/25/getting-started-with-azure-resource-manager-arm-and-json/的许可

#Azure：SMB 3.0文件服务或高级存储中高可用性SQL Server存储配置的性能差异概述

当涉及Azure中的SQL Server存储配置时，有几个选项。如果您想知道，可以从Azure IAAS VM上的Windows Server故障转移群集 – 第1部分（存储）中获得一些好主意。它讨论了新发布的Azure文件服务，该服务可用于通过SMB 3.0托管SQL Server群集数据。请记住，Azure文件服务不支持高级存储。每个文件共享约有1,000 IOPS或60 MB / s。考虑到这些限制，Azure文件服务可能将成为IO需求最小的数据库选项。

查看我的测试结果

所以这个计划是测试一些不同的SQL Server存储配置。我配置了DS4虚拟机并附加了一些高级存储。接下来，我使用Azure File Service附加了SMB 3.0文件共享。以下是我配置SQL Server存储配置的方式。

• F： – 将三个1 TB P30高级存储磁盘添加到单个3TB池中
• G： – 一个1 TB P30高级存储磁盘（无存储池）
• Z： – Azure文件服务上的SMB 3.0文件共享

过程

当您将存储池配置为在群集中使用时请务必小心。您可以在群集启动之前创建存储池，也可以在Windows 2012 R2存储空间中使用Sql Alwayson中的Powershell脚本（如果群集已经创建）。我创建了一个简单镜像（RAID o）请注意，由于Azure存储在后端具有三重冗余，因此我并不担心冗余。

要将存储池配置为在群集中使用，您必须小心操作。您必须在创建群集之前创建存储池，或者如果已创建群集，请使用Windows 2012 R2存储空间中的Sql Alwayson中所述的Powershell脚本。为了提高性能，我创建的池是简单镜像（RAID 0）。由于后端的Azure存储具有三重冗余，因此我不担心冗余。

我应该得到单个磁盘性能的三倍，因为我在存储池中有三个磁盘位于RAID 0中。现在，如果我选择将更多磁盘添加到池中，我将享受更高的性能。一个P30磁盘给我5000 IOPS和200 MB / S。基于此，我预计我的游泳池可达到15000 IOPS和600 MB / S的吞吐量。

现在我已经将存储设置为存储了，我将Dskspd配置为在每个不同的卷上运行相同的测试。这是我用Dskspd做的参数。

Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M F： io.dat

Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M G： io.dat Diskspd.exe -b8K -d60 -h -L -o8 -t16 -r -w30 -c50M Z： io.dat

并且结果出来了

不同SQL Server存储配置的结果是相当可预测的，并在下面进行总结。

看看结果，这个特定的工作没有推动任何这些存储解决方案的理论最大值的上限。但是，延迟对此特定测试的整体性能有重大影响。该测试使用8k块混合30％写入和70％读取来模拟典型的SQL Server OLTP工作负载。

当然，你想花更多的钱，你可以期望获得更多的表现。这是相对的。

Azure中SQL Server存储配置的价格比较

截至2015年11月24日，这里显示的最佳解决方案的价格（F：）将为每月1,216美元。它承诺完全访问3 TB存储空间，并具有无限次的读/写。

第二个最佳解决方案（G：）会给你1TB的存储空间，价格为每月405美元。Azure File Share的价格为0.10美元/ GB，另外还有额外的读/写操作费用。您只收取实际使用费用。因此估算实际成本将取决于您的使用情况。在读/写操作的额外费用之前，您约占高级存储成本的25％。

与云中的其他产品一样，价格也会迅速变化，以应对市场需求。请访问https://azure.microsoft.com/en-us/pricing/details/storage/查看最新价格信息，了解最新价格信息。

概要

从这个SQL Server存储配置的编译和价格概述中，Azure文件服务确实从价格的角度看起来很诱人。此时的延迟并不能使其成为任何严重SQL Server工作负载的可行选项。相反，请查看利用高级存储并利用基于主机的复制解决方案（如SIOS DataKeeper）构建SQL Server故障转移群集实例（SQL标准版或企业版）或查看SQL Server Enterprise Edition和AlwaysOn AG。

转载https://clusteringformeremortals.com/2015/11/24/highly-available-sql-server-storage-options-in-azure-smb-3-0-file-service-or-premium-storage-一，看-AT-性能差异/

配置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门户中看到它，如下所示。

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

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

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

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

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

此时配置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 /