为相同站点服务的具有相同负载的两个盒子往往会减慢并停止响应 ping。缓慢(或间歇性)的 ping 导致我们的负载均衡器认为服务器处于脱机状态并禁用它们。还有第三台服务器具有相同的内容,没有问题,所以我相当有信心这不是网站。
操作系统是 Windows Server 2008。配置有点特殊:因为我们在 Direct Server Return 模式下使用梭子鱼网络负载平衡器,所以我们不得不配置许多环回适配器,这些适配器“伪造”了此处描述的 IP 。物理适配器已根据 2008 年要求启用转发设置,以使环回适配器正常工作。
症状:
- 当它发生时,ping 通常要么超时,要么丢包。
- 修复似乎是以下一项或多项:
- 通过远程桌面登录。
- 清除 dns 缓存或 arp 缓存(不确定哪个)。
- 重新启动。
- 在上述一项或多项操作之后,服务器似乎可以正常运行大约 4 小时,然后再次运行。
问题:
这有哪些可能的原因?我应该如何诊断?我没有排除任何可能。切换配置,域/dns 服务器,欢迎所有想法。
可悲的是,我对良好的网络管理知之甚少,所以也欢迎显而易见的答案。
编辑:
回答提出的一些问题。
我已经联系了梭子鱼,他们似乎认为问题与网络有关。我想我同意这一点。
IP 分配给物理接口,而不是在服务器之间共享。Ping 是在同一子网内完成的。
当其他两个出现故障并且没有太大问题时,第三个框处理所有站点负载,但有时它也有问题。我还没有找到那个模式。
今天晚上,我和另一个(更有经验的)网络人员坐下来查看一些域和服务器配置。他发现的其中一件事是域控制器上的 dns 设置错误。它们被配置为使用外部 dns 服务器作为备用服务器,而不是其他 DC。我们将它们切换为相互引用 dns,并添加到 dns 服务的转发。我们还从所有 Web 服务器中删除了外部 dns 引用。
编辑2:
使用 Wireshark,我能够在一段停机时间内检查 ICMP 流量。我开始这个测试是因为我无法从框 1 访问框 2 上的共享文件夹。
测试:
- 开始在框 2 上捕获流量。
- 观察到框 2 正在查看并回复来自梭子鱼负载均衡器的 ping。
- 登录到框 1 并 ping 框 2。
- 观察到框 2 看到但没有回复框 1 的 ping。
- 观察到框 2 看到但在框 1 的第一次 ping 之后的 100 秒内没有回复来自 LB 的 ping。
因此,不知何故,两个盒子之间的流量导致盒子 2 在 ICMP 上崩溃了一段时间。
我应该注意到,框 1 在整个测试过程中运行良好,但没有看到来自框 2 的任何请求。在从框 2 ping 框 1 时,框 2 上的 Wireshark 显示来自源的消息“无法访问目标(通信管理过滤)” IP我不认识。
您是否需要使用 ICMP ping 进行服务器测试?大多数负载均衡器都支持 HTTP 请求,这通常是一个更好的主意,因为您的 Web 服务器可能会在您的网卡仍在运行时关闭。
我会先与梭子鱼网络核实。这可能是一个已知问题。我们有一个类似的问题,原来是我们的 Cisco 负载均衡器。固件更新解决了这个问题。
第三台服务器是否处于负载状态,还是以另一种方式与其他两台服务器不同?
在不了解更多信息的情况下,我建议将Wireshark安装到这些服务器上,同时 ping 它们并查看 ICMP 活动。我(可能毫无根据)的怀疑是这些服务器遇到 ARP 问题并发送回响应数据包,你只是永远不会得到它们。
使用 Wireshark,将您的过滤器设置为“arp 或 icmp”,看看它会带来什么。您还应该快速查看您的系统事件日志 - 那里可能有一些明显的东西可以缩短任何进一步的猜测。
如果您不熟悉 arp,它是用于将第 3 层 (IP) 地址转换为第 2 层 (MAC) 地址的协议。这必须正确发生,否则包含第 3 层数据包的第 2 层帧将永远不会被发送,或者将到达错误的目的地。
最后,其他发布者的双工/速度建议是可靠的最佳实践,尽管我怀疑它们是这里的根本原因。请注意,在千兆以太网中,您不再需要担心自动协商会受到影响。
编辑
您所做的 DNS 更改肯定是个好主意,但我很难想象会导致 ICMP 超时的场景。可能该应用程序阻止了数千个 DNS 查询并消耗了太多资源以至于无法响应 ICMP?
无论如何,如果这不能解决问题,数据包跟踪应该显示更多正在发生的事情。
我发现有帮助的一件事是确保服务器上的 NIC 和它所连接的交换机上的端口都设置为相同的速度和双工设置。我遇到了“自动协商”无法很好协商的问题,这开始导致端口和 NIC 出现很多错误。
尝试手动将接口设置为速度,并尽可能避免使用自动协商。
将服务器上的网络驱动程序更新到硬件供应商提供的最新版本。我发现这有时可以解决奇怪的网络问题。
进行管理过滤的源 IP 是什么?这很可能是问题的根源,我怀疑它是负载均衡器内部的