SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 产品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 服务器集群简单化
  • 成功案例
  • 联系我们
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

修复SQL Server Alwayson故障转移群集实例中的Azure ILB连接

6月 19, 2018 by Jason Aw Leave a Comment

在SQL Server故障转移实例群集连接中排查Azure ILB连接问题

在SQL Server故障转移实例群集连接中排查Azure ILB连接问题

我使用以下工具来帮助我解决SQL Server故障转移群集实例连接问题的疑难解答。特别是那些讨厌的Azure ILB连接问题。每当我找到一个新工具时,我都会尝试更新这篇文章。

NETSTAT

第一个工具是一个简单的测试,用于验证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

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。否则,您将无法连接到您的命名实例。

FIREWALL

打开TCP端口1433和59999应该涵盖所有需要的手动步骤。但是,在解决连接问题时,我通常关闭Windows防火墙以消除防火墙,将其视为问题的可能原因。别忘了。Azure还有一个称为网络安全组的防火墙。如果有人将其从可能阻止流量的默认设置改变。

姓名解析

尝试ping SQL集群名称。它应该解析为SQL Server群集iP地址。尽管我已经看到过几次,但与SQL群集网络名称关联的DNS A记录神奇地从DNS中消失。如果是这种情况,请继续阅读 – 在SQL中将SQL Custer名称和IP地址作为A记录进行读取。

SQL配置管理器

在SQL配置管理器中,您应该看到列出的SQL群集IP地址和端口1433。如果碰巧你安装了一个命名实例,你当然需要进入这里并将端口锁定到一个特定的端口,并使你的负载平衡规则反映该端口。由于Azure ILB仅限于每个AG的ILB限制,所以实际上我没有看到使用命名实例的有效理由。让自己更容易,只使用SQL的默认实例。(更新:截至2016年10月,每个ILB可以有多个IP地址,因此您可以在群集中安装多个SQL实例。)

 

经过Clustering For Mere Mortals的许可转载。

Filed Under: 服务器集群简单化

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

6月 15, 2018 by Jason Aw Leave a Comment

在ARM中配置#AZURE ILB对于SQL Server故障转移群集实例或AG使用AZURE Powershell 1.0

在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门户中看到它。见下面的图片。

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

剩下的配置也可以通过PowerShell完成,但我将在我的示例中使用GUI。

如果您想使用PowerShell,您可以通过查看本文来拼凑脚本。 不幸的是,这篇文章迷惑了我。我会在一天之内弄清楚它的存在并尝试以用户友好的格式记录它。到目前为止,我认为GUI对于下一步很好。

让我们开始吧

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

第一步

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

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

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

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

下一步

  • 导航到“负载平衡规则”选项卡并添加新规则。给规则一个明智的名字(SQL1433或其他)。 选择TCP协议端口1433(假设您正在使用SQL Server的默认实例)。为后端端口选择1433。对于后端池,我们将选择我们之前创建的后端池(BE)。 对于探测器,我们也将选择我们之前创建的探测器。

我们不想启用会话持久性,但我们希望启用浮动IP(直接服务器返回)。我已将空闲超时设置为默认设置。您可能需要考虑将其提高到最大值。原因是每次连接断开并需要重新建立时,我都会看到一些应用程序,如SAP日志错误消息。

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

  • 此时配置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的许可转载。

Filed Under: 服务器集群简单化

在Azure中部署高可用性SQL Server时加入我的会话

3月 31, 2018 by Jason Aw Leave a Comment

@Sqlsatnash在#Azure Session中部署高可用SQL Server在SQL周六纳什维尔,1月16日

我将前往纳什维尔分享有关部署高可用性SQL服务器的信息。在那里,有一些我等不及赶上的东西 – 技术和音乐。当我在那里的时候,我当然希望我能在The Station Inn有一些很好的音乐。

在Azure中部署高可用性SQL Server时参加我的会话

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/

Filed Under: 服务器集群简单化

您必须知道Azure资源管理器的优势

3月 31, 2018 by Jason Aw Leave a Comment

Azure资源管理器的优势和Azure中高度可用的SQL Server部署

Azure资源管理器(ARM)是使用Microsoft Azure IaaS的最新和最好的方式。Azure资源管理器的优点很多 – 模板部署,分组,简化计费等等。这种新模式有望实现新功能和更多互动。

抓住网络研讨会

Microsoft云和数据中心管理MVP大卫伯明翰将介绍ARM并仔细研究如何利用ARM在云中启用高可用性和可扩展的SQL Server部署。注册参加这个网络研讨会… https://www.mssqltips.com/webcastSignupPage.asp?id=480&src=sios

转载自https://clusteringformeremortals.com/2015/12/15/key-benefits-of-working-with-azure-resource-manager-and-highly-available-sql-server-deployments-in-azure/

Filed Under: 服务器集群简单化 Tagged With: SQL Server部署, 大卫伯明翰

Azure资源管理器和高可用性SQL Server网络研讨会

3月 31, 2018 by Jason Aw Leave a Comment

想知道如何利用ARM实现高度可用和可扩展的SQL Server部署?

那么,如果你的答案是肯定的,那么我为你提供了一个很好的建议。特别是,如果您有兴趣了解为什么Azure资源管理器(ARM)是使用Microsoft Azure IaaS的最新和最简单的方法,那么在12月15日发生的网络研讨会对您来说非常适合。与ARM合作非常好。首先,有模板部署,分组,简化计费等等。你必须为自己尝试一些这些新功能,以及与这种新模式不同的新互动方式。

请参阅Azure资源管理器可以执行的操作

加入Microsoft云和数据中心管理MVP大卫伯明翰,他介绍ARM。仔细研究如何使用ARM的强大功能在云中部署高可用性和可扩展的SQL Server部署。

时间:12月15日

时间:美国东部时间下午1:00 /太平洋标准时间10:00

在这里注册 – https://www.mssqltips.com/webcastSignupPage.asp?id=480&src=sios

转载https://clusteringformeremortals.com/2015/11/16/azure-resource-manager-and-highly-available-sql-server-webinar-sqltips/的许可

Filed Under: 服务器集群简单化

  • « Previous Page
  • 1
  • …
  • 77
  • 78
  • 79
  • 80
  • 81
  • …
  • 100
  • Next Page »

最近的帖子

  • 在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项
  • 我的服务器是一次性的吗?高可用性软件如何融入云最佳实践
  • 灾难频发世界的数据恢复策略
  • DataKeeper 和棒球:灾难恢复的战略举措
  • SQL Server 停机风险预算

最热门的帖子

加入我们的邮件列表

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in