SIOS SANless clusters High-availability Machine Learning monitoring
我每周都会与用户进行交流，将关键业务工作负载转移到Azure。我经常问的第一个问题是他们是使用Azure服务管理（经典）还是Azure资源管理器（ARM）。
我通常推荐ARM。 这是一种新的做事方式，所有新功能都在为ARM开发。不过，还有一些与ARM不兼容的东西。随着时间的推移，这些不支持的功能列表越来越小。同时，最好知道现有的文档似乎定期更新，列出了所有功能以及它们是否受ARM支持。 https://azure.microsoft.com/en-us/documentation/articles/resource-manager-supported-services/
这是一个体面的名单，但它不完整。我只在应用程序服务环境页面的此页面上发现应用程序服务环境不受支持。
我使用以下工具来帮助我解决SQL Server故障转移群集实例连接问题的疑难解答。特别是那些讨厌的Azure ILB连接问题。每当我找到一个新工具时，我都会尝试更新这篇文章。
第一个工具是一个简单的测试，用于验证SQL群集IP是否正在侦听它应该侦听的端口。在这种情况下，SQL群集IP地址是10.0.0.201。但它使用的是端口1433的默认实例。这里是帮助你快速识别活动节点是否在该端口上侦听的命令。在我们的情况下，一切看起来很正常
C： Users dave.SIOS> netstat -na |找到“1433”
TCP 10.0.0.4:49584 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49592 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49593 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49595 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.201:1433 0.0.0.0:0听
ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49592 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49593 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49595 ESTABLISHED
一旦我确定SQL正在监听正确的端口，我使用PSPING尝试远程连接到端口。
PSPing是Microsoft提供的PSTools软件包的一部分。我通常下载该工具并将PSPing直接放在我的System32文件夹中，这样我就可以随时使用它而无需更改目录。现在，假设从ILB，集群和防火墙的角度来看，所有配置都是正确的，那么您应该能够从被动服务器ping SQL集群IP地址和端口1433。你会得到下面显示的结果…
C： Users dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01 - PsPing - ping，延迟，带宽测量工具
Copyright（C）2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP连接到10.0.0.201:1433：
5次迭代（热身1）连接测试：
连接到10.0.0.201:1433（热身）：6.99ms
连接到10.0.0.201:1433：0.78ms
连接到10.0.0.201:1433：0.96ms
连接到10.0.0.201:1433：0.68ms
连接到10.0.0.201:1433：0.89ms
如果事情没有正确配置，您可能会看到与以下类似的结果...
C： Users dave.SIOS> psping 10.0.0.201:1433
TCP连接到10.0.0.102:1433：
5次迭代（热身1）连接测试：
连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。连接到10.0.0.102:1433（热身）：由于超时期限过期，此操作返回。如果PSPing连接，但您的应用程序连接出现问题，则可能需要深入一点。我见过像Great Plains这样的应用程序也想连接到445端口。如果您的应用程序无法连接，但PSPing可以很好地连接到1433。然后，您可能需要执行网络跟踪并查看应用程序尝试连接的其他端口。最后一步是为这些端口添加负载平衡规则。
计划使用命名实例？您需要确保锁定TCP服务以使用静态端口。同时，您还需要确保向负载平衡器添加规则，以重定向SQL浏览器服务的UDP 1434。否则，您将无法连接到您的命名实例。
打开TCP端口1433和59999应该涵盖所有需要的手动步骤。但是，在解决连接问题时，我通常关闭Windows防火墙以消除防火墙，将其视为问题的可能原因。别忘了。Azure还有一个称为网络安全组的防火墙。如果有人将其从可能阻止流量的默认设置改变。
尝试ping SQL集群名称。它应该解析为SQL Server群集iP地址。尽管我已经看到过几次，但与SQL群集网络名称关联的DNS A记录神奇地从DNS中消失。如果是这种情况，请继续阅读 – 在SQL中将SQL Custer名称和IP地址作为A记录进行读取。
在SQL配置管理器中，您应该看到列出的SQL群集IP地址和端口1433。如果碰巧你安装了一个命名实例，你当然需要进入这里并将端口锁定到一个特定的端口，并使你的负载平衡规则反映该端口。由于Azure ILB仅限于每个AG的ILB限制，所以实际上我没有看到使用命名实例的有效理由。让自己更容易，只使用SQL的默认实例。（更新：截至2016年10月，每个ILB可以有多个IP地址，因此您可以在群集中安装多个SQL实例。）
转载自群集成为凡人的许可。
我使用以下工具来帮助我解决SQL Server故障转移群集实例连接问题的疑难解答。特别是那些讨厌的Azure ILB连接问题。每当我找到一个新工具时，我都会尝试更新这篇文章。
第一个工具是一个简单的测试，用于验证SQL群集IP是否正在侦听它应该侦听的端口。在这种情况下，SQL群集IP地址是10.0.0.201。但它使用的是端口1433的默认实例。
这里是帮助你快速识别活动节点是否在该端口上侦听的命令。在我们的情况下，一切看起来很正常
C： Users dave.SIOS> netstat -na |找到“1433”
TCP 10.0.0.4:49584 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49592 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49593 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.4:49595 10.0.0.201:1433 ESTABLISHED
TCP 10.0.0.201:1433 0.0.0.0:0听
ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49592 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49593 ESTABLISHED
TCP 10.0.0.201:1433 10.0.0.4:49595 ESTABLISHED
一旦我确定SQL正在监听正确的端口，我使用PSPING尝试远程连接到端口。
PSPing是Microsoft提供的PSTools软件包的一部分。我通常下载该工具并将PSPing直接放在我的System32文件夹中，这样我就可以随时使用它而无需更改目录。
现在，假设从ILB，集群和防火墙的角度来看，所有配置都是正确的，那么您应该能够从被动服务器ping SQL集群IP地址和端口1433。你会得到下面显示的结果…
C： Users dave.SIOS> psping 10.0.0.201:1433
PsPing v2.01 - PsPing - ping，延迟，带宽测量工具
Copyright（C）2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP连接到10.0.0.201:1433：
5次迭代（热身1）连接测试：
连接到10.0.0.201:1433（热身）：6.99ms
连接到10.0.0.201:1433：0.78ms
连接到10.0.0.201:1433：0.96ms
连接到10.0.0.201:1433：0.68ms
连接到10.0.0.201:1433：0.89ms
如果事情没有正确配置，您可能会看到与以下类似的结果...
C： Users dave.SIOS> psping 10.0.0.201:1433
TCP连接到10.0.0.102:1433：
5次迭代（热身1）连接测试：
连接到10.0.0.102:1433（预热）：
由于超时期限到期，此操作返回。
连接到10.0.0.102:1433（预热）：
由于超时期限到期，此操作返回。
连接到10.0.0.102:1433（预热）：
由于超时期限到期，此操作返回。
连接到10.0.0.102:1433（预热）：
由于超时期限到期，此操作返回。
连接到10.0.0.102:1433（预热）：
由于超时期限到期，此操作返回。
如果PSPing连接，但您的应用程序连接出现问题，则可能需要深入一点。我见过像Great Plains这样的应用程序也想连接到445端口。如果您的应用程序无法连接，但PSPing可以很好地连接到1433。然后，您可能需要执行网络跟踪并查看应用程序尝试连接的其他端口。最后一步是为这些端口添加负载平衡规则。
计划使用命名实例？您需要确保锁定TCP服务以使用静态端口。 同时，您还需要确保向负载平衡器添加规则，以重定向SQL浏览器服务的UDP 1434。否则，您将无法连接到您的命名实例。
打开TCP端口1433和59999应该涵盖所有需要的手动步骤。但是，在解决连接问题时，我通常关闭Windows防火墙以消除防火墙，将其视为问题的可能原因。别忘了。Azure还有一个称为网络安全组的防火墙。如果有人将其从可能阻止流量的默认设置改变。
尝试ping SQL集群名称。它应该解析为SQL Server群集iP地址。尽管我已经看到过几次，但与SQL群集网络名称关联的DNS A记录神奇地从DNS中消失。如果是这种情况，请继续阅读 – 在SQL中将SQL Custer名称和IP地址作为A记录进行读取。
在SQL配置管理器中，您应该看到列出的SQL群集IP地址和端口1433。如果碰巧你安装了一个命名实例，你当然需要进入这里并将端口锁定到一个特定的端口，并使你的负载平衡规则反映该端口。由于Azure ILB仅限于每个AG的ILB限制，所以实际上我没有看到使用命名实例的有效理由。让自己更容易，只使用SQL的默认实例。（更新：截至2016年10月，每个ILB可以有多个IP地址，因此您可以在群集中安装多个SQL实例。）
经过Clustering For Mere Mortals的许可转载。
在之前的文章中，我详细介绍了如何在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
该原始文章的其余部分是相同的，但我刚刚在这里复制它以方便使用…
现在创建了ILB，我们应该在资源组的Azure门户中看到它。见下面的图片。
剩下的配置也可以通过PowerShell完成，但我将在我的示例中使用GUI。
如果您想使用PowerShell，您可以通过查看本文来拼凑脚本。 不幸的是，这篇文章迷惑了我。我会在一天之内弄清楚它的存在并尝试以用户友好的格式记录它。到目前为止，我认为GUI对于下一步很好。
跟随下面的屏幕截图。如果您迷路了，请按照Azure门户顶部的导航提示找出我们的位置。
我们不想启用会话持久性，但我们希望启用浮动IP（直接服务器返回）。我已将空闲超时设置为默认设置。您可能需要考虑将其提高到最大值。原因是每次连接断开并需要重新建立时，我都会看到一些应用程序，如SAP日志错误消息。
在我最初的测试中，即使完成了上述所有步骤，仍然无法连接到SQL资源名称。在将我的头靠在墙上几个小时后，我发现由于某种原因，SQL群集名称资源未在DNS中注册。我不确定这是怎么发生的或者它是否会一致发生，但是如果连接时遇到问题，我肯定会检查DNS，并将SQL集群名称和IP地址添加为新的A记录（如果它尚未存在）。
当然，别忘了Windows防火墙。您必须为1433和59999制定例外规定，或者关闭它直到您像我一样正确配置所有设置。您可能想要利用Azure网络安全组而不是本地Windows防火墙，以获得跨所有Azure资源的更加统一的体验。
祝你好运，让我知道你是如何做出的。
转到此处，了解SIOS如何帮助全球各地的公司创建SQL Server故障转移群集。
经过Clustering For Mere Mortals的许可转载。
我将前往纳什维尔分享有关部署高可用性SQL服务器的信息。在那里，有一些我等不及赶上的东西 – 技术和音乐。当我在那里的时候，我当然希望我能在The Station Inn有一些很好的音乐。
1月16日将成为学习和交流的好日子。与我的#SQLPass家族聊天并加入我的会话。对于那些热衷于在Azure中部署SQL Server的人来说，这个长时间的会话非常适合。
正如我们已经知道的那样，Windows Azure是部署SQL Server的优秀IaaS平台。即使在Microsoft管理基础架构时，也需要规划高可用性和灾难恢复。在本次会议中，了解如何利用Azure故障域，升级域和内部负载均衡器来确保Azure云中SQL Server部署的高可用性。您将了解到Azure Classic和Azure Resource Manager之间的区别。同时，它将如何影响您的SQL Server可用性。虽然Microsoft Azure提供了99.95％的SLA，但请确保您的SQL Server部署符合要求。此外，此会话最适合那些有意移动或已将SQL Server实例移至Azure的人员。顺便说一下，本次会议的参与者应具有SQL Server AlwaysOn故障转移群集以及可用性组的基本知识。但是，如果你不这样做，不要担心，因为你应该能够通过一点练习和实验快速赶上。
转载自https://clusteringformeremortals.com/2015/12/21/sqlsatnash-deploying-highly-available-sql-server-in-azure-session-at-sql-saturday-nashville-jan-16th/