故障转移群集客户端访问点只响应所有者节点上的Ping

背景

我们在安装了SQL Server的Azure上运行两个虚拟机(Windows Server 2012 R2),并将其设置为可用性组。 当然,我们还有另一台虚拟机作为专用DC。 这些都是通过一个虚拟networking连接的。 这个设置对我们来说工作得很好,而且我能够从本地的物理机器上连接到SQL,没有任何问题,但是在帐户上达到了支出限制,并且取消了所有的设置。 我们删除了限制,并且我再次分配了所有使用相同VHD的服务器,所有设置(大概)都已恢复,但是我不能再访问SQL Server。

名称定义

为了最好地解释这一点,我们将调用两个节点SQL1和SQL2,可用性组SQL-AG,可用性组侦听器SQL-Listener以及这些都正在运行的Cloud Service(通过设置适当的端点)SQL-CloudService。 SQL1是故障转移群集angular色的所有者(并且一致地具有主副本angular色),SQL2是次要angular色。

脚本

我能够将RDP安装到两台服务器上,并使用SQL1中的SSMS连接到SQL-Listener,并查看SQL-AG仪表板,该仪表板可以将所有事情报告为健康并同步。

在SQL2上,我无法连接到SQL-Listener。 我也无法从本地机器连接到SQL-CloudService,这也是以前的工作。 两个系统都返回错误,

无法连接到SQL-Listener。

与SQL Serverbuild立连接时发生networking相关或特定于实例的错误。 服务器未find或无法访问。 validation实例名称是否正确,并将SQL Serverconfiguration为允许远程连接。 (提供程序:命名pipe道提供程序,错误:40 – 无法打开连接到SQL Server)(Microsoft SQL Server,错误:53)

找不到networkingpath

当我继续SQL1并通过SSMS连接时,我可以告诉SQL-AG故障转移到SQL2。 它成功地做到了。 但是,这样做之后,我不再能够从SQL1连接到SQL-Listener,但是我是从SQL2连接的。

长话短说,我只能从标有副本angular色的系统中将SSMS连接到可用性组侦听器。

真正的问题

我并不需要能够完成所有这些工作,但是我确实需要能够通过互联网从本地计算机获取SQL Server,而且我认为这些问题是由相同的潜在问题引起的因为他们给出相同的错误信息。

我find的东西

毫不奇怪,给出了错误信息和情况,但是我不能ping通SQL-Listener,除非它在我启动ping的机器上运行。 当SQL1被标记为Primary时,我可以在没有SQL1问题的情况下ping它,但是当我尝试从SQL2尝试时,它成功地使用DNS查找IP,但是回来时显示“Reply from [SQL2's IP]:Destination host unreachable”。 当我对SQL-AG进行故障转移时,另一方面也会出现同样的问题。 但是,我总是能够从SQL2 ping SQL1,反之亦然。 因此,我倾向于认为它是一个故障转移群集问题,而不是一个SQL问题。 因此,这个问题的标题。

我也发现防火墙似乎没有任何改动。 这是一致的,我想说,ping的问题,但在防火墙上的监视显示没有任何远程机器(我的本地或非拥有的虚拟机)在SQL Server的尝试。

可以从我已经说过的东西中推论出来,但似乎值得指出的是,即使通过Cloud Service,我也无法通过端口1433来接触防火墙。我不完全确定这是为什么,因为直接服务器之间的路由,我想,应该直接推送到服务器。 因此,我期望在日志中的一个项目代表这个,但是有很多项目,没有一个是。

毫不奇怪,由于ping问题,我也可以在所有者节点上本地访问报告服务器URL(类似于http://sql-listener/ReportServer ),但不能从另一个远程访问。

如果指定计算机的名称(SQL1或SQL2,与SQL-Listener相比),则可以从另一个SQL Server连接到另一个SQL Server。 无论如何,这对我来说都是陌生的,我似乎无法通过Cloud Service。 我认为这意味着它正在倾听它应该在哪里,并且我从来不必告诉Azure指向SQL-Listener,我不希望有任何改变。 所以也许我只是读错了整个情况。

我采取的故障排除步骤

  • 重新启动涉及的所有机器
  • 确保所有的IP都是静态的,我们期望它们是什么
  • 确保防火墙设置正确
  • closures每个SQL服务器(在Azure上,这会取消分配虚拟机,因此比重新启动要严重得多)并重新启动它们。
  • 删除并重新创build故障转移群集angular色的客户端访问点(并使用它,可用性组监听器)
  • 重新创build了Cloud Service端点(尽pipe这看起来不再有任何帮助,因为之前我知道服务器之间存在问题)
  • 尝试连接到IP地址显式声明的服务器(“tcp:[SQL-Listener's IP]”)。 这返回与networking相关/实例特定的错误,说:“连接尝试失败,因为连接方在一段时间后没有正确响应,或build立连接失败,因为连接的主机未能响应。

我有过的想法

  • 这可能是与子网有关吗? 他们确实似乎是在同一个,但我可以想象,造成这样的一些奇怪的问题。
  • 有没有人知道Azure在closures运行超出支出限制的服务器时所做的一切? 是否有一个设置在某个地方被改变,我没有注意到?

所以,事实certificate,这是一个非常愚蠢的错误。 我忘记了设置可用性组以使用Azure所需的所有步骤,如此处所述。

由于云服务的解除分配改变了其IP,因此SQL-Listener正在监听错误的IP地址。 我曾考虑过这个问题,并通过删除和重新创build听众来解决这个问题,但是我完全忽略了我首先亲自执行的设置听众的所有步骤。 因此,在与Microsoft支持人员通话一小时后,我们终于完成了一切设置。 现在全部备份和工作。