发生在阿里云 SLB 4 层的一次故障记录

阿里云 SLB 与 ECS 之间发生故事。环境如下：

SLB api-node: 该 SLB 后端接着 10 台节点服务器

SLB sql-node: 该 SLB 后端接着 2 台节点服务器

问题描述：

访问 web 站点发现，连续点击几次页面就会有一次请求时间很长 30s 。

这个 30s 是超过了 php.ini 中 max_execution_time = 30 该参数的设置最大值，最终请求失败，返回 400 。

分析故障现象应该是有一台 api-node 有问题，当请求被轮询到该节点时，请求失败。

通过监控服务器观看，各个 api-node 负载都均衡，无法直观的发现是哪台服务器故障。

(如果有每台 api-node 的访问日志，做了日志分析，可以通过统计图直观的反应出来)

最终写脚本拿问题URL去循环请求每台 api-node ，发现了这台问题服务器。

通过开发人员调试代码，发现问题为该节点连接数据库故障。具体情况如下：

1、该 ECS 请求三四次数据库的SLB就会出现连接超时。( 直接使用 mysql 命令连接 )

2、该 ECS 单独去请求数据库SLB后端的服务器，没有任何问题。

通过上面的测试，排除服务器环境、代码、数据库服务器的问题。最终问题定位在数据库的SLB上。

由于是做 mysql 的负载均衡，使用的是 TCP 协议的 4 层负载均衡。

向阿里云发起工单，提交问题，经过一系列排查，最终阿里云给出故障原因及解决方法如下：

"这是由于您使用的slb 4层tcp 协议,由于slb 的一些底层架构原因引起的,这个问题我们也已经向后端反馈过了;
只要客户端ecs 的内网ip 和 slb 后端的ecs 内网ip 有在一个路由段的，就会出现这个问题;
建议您可以手工删除slb 后端ecs 重复的路由条目,或者将您的slb 配置修改成7层http 协议"

解决方法：

1、登录问题 ECS 查看路由表

shell > route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
159.110.44.0     0.0.0.0         255.255.252.0   U     0      0        0 eth1
110.27.240.0     0.0.0.0         255.255.252.0   U     0      0        0 eth0
169.254.0.0      0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0      0.0.0.0         255.255.0.0     U     1003   0        0 eth1
172.16.0.0      110.27.243.247   255.240.0.0     UG    0      0        0 eth0
100.64.0.0      110.27.243.247   255.192.0.0     UG    0      0        0 eth0
10.0.0.0        110.27.243.247   255.0.0.0       UG    0      0        0 eth0
0.0.0.0         159.110.47.247   0.0.0.0         UG    0      0        0 eth1

2、登录数据库 SLB 后端 ECS 查看路由表 ( 与问题 ECS 内网同一网段的服务器 )

shell > route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
59.110.20.0     0.0.0.0         255.255.252.0   U     0      0        0 eth1
110.27.240.0    0.0.0.0         255.255.252.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
172.16.0.0      110.27.243.247  255.240.0.0     UG    0      0        0 eth0
100.64.0.0      110.27.243.247  255.192.0.0     UG    0      0        0 eth0
10.0.0.0        110.27.243.247  255.0.0.0       UG    0      0        0 eth0
0.0.0.0         159.110.23.247  0.0.0.0         UG    0      0        0 eth1

3、删除这台数据库服务器内网地址与问题 ECS 重复的路由 (只删数据库服务器这台就可以)

shell > route del -net 110.27.240.0 netmask 255.255.252.0 dev eth0

shell > route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
159.110.20.0     0.0.0.0         255.255.252.0   U     0      0        0 eth1
169.254.0.0      0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0      0.0.0.0         255.255.0.0     U     1003   0        0 eth1
172.16.0.0      110.27.243.247   255.240.0.0     UG    0      0        0 eth0
100.64.0.0      110.27.243.247   255.192.0.0     UG    0      0        0 eth0
10.0.0.0        110.27.243.247   255.0.0.0       UG    0      0        0 eth0
0.0.0.0         159.110.23.247   0.0.0.0         UG    0      0        0 eth1

# 经测试，问题解决。最终关闭工单提示，实际处理时长：6小时2分钟

# 记录：确保以后新买的需要访问数据库 SLB 的 ECS 不与数据库 SLB 后端的 ECS 在同一内网段，如果在，删除数据库 SLB 后端 ECS 重复路由。