联 系 我 们
售前咨询
售后咨询
微信关注:星环科技服务号
更多联系方式 >
9.3.1 网络异常
更新时间:11/3/2023, 9:06:53 AM

当发生网络故障或通信质量较差时,网络连接可能会导致数据库连接中断或 SQL 执行变得异常缓慢,导致无法访问数据库服务和资源,本文介绍如何排查和解决网络故障。

确认故障表现

在排查网络故障之前,需要先确认故障的表现和范围,例如首先确认范围是单个客户端还是所有客户端;而对于数据库而言,网络故障可能呈现为下述表象:

表 5.1.1:故障表现说明
故障表现 说明

连接超时

客户端尝试连接 ArgoDB 数据库时,无法建立连接,一段时间后会超时,无法正常建立连接。

无法访问数据库

客户端无法访问 ArgoDB 数据库,提示连接超时或连接失败,例如提示:“Could not open connection to” 或 “Connection refused”。

SQL 请求处理超时/失败

客户端发送 SQL 查询请求到服务器后,查询花费的时间超过了预设的时间,客户端会认为查询请求已经超时,例如执行建表语句时,提示执行超时:

Can not create table: create table ...... timeout (state=08S01,code=20604)
复制

SQL 查询异常缓慢

由于网络延迟或连接问题,数据库服务器可能会出现性能下降,处理查询请求的时间上升明显。

确认网络拓扑

在故障网络故障时,首先需要明确客户端和数据库集群之间的网络拓扑,包括路由器、交换机等网络设备的位置和连接方式。以 3 节点的集群为例,假设我们的架构如下:

network architecture
图 5.1.1:网络架构

从上述网络架构可看到,客户端的请求需要经过交换机、路由器、防火墙等网络设备,才能和集群中的数据库通信,那么在进行排查时,我们需要逐级排查,帮助我们确认通信故障发生的具体范围,通常包含下述流程:

  • 检查客户端网络

  • 检查网络设备状态和日志

  • 检查防火墙规则是否拦截了请求

  • 检查数据库集群网络语运行状态

检查网络连接和端口
  1. 检查客户端与集群的网络设置是否正确,包括 IP 地址、子网掩码、网关、DNS 等。

  2. 验证客户端是否能够 ping 通集群中任意一个节点的 IP 地址,以确认客户端与集群之间是否存在网络连通性问题。

    如果无法 ping 通,可能的原因如下:

    • 客户端网络链路故障

    • 网络路由设置不正确

    • 防火墙设备或集群上的防火墙设置不正确,可检查集群上 iptables 设置。

  3. 在正常 ping 通集群的情况下,我们可以检查客户端是否能够通过 telnet 命令访问集群的服务端口。

    例如我们要访问 ArgoDB 数据库,需要通过 Quark 服务进行连接,默认采用的端口是 10000,假设 Quark 所属节点的 IP 地址是 172.16.20.100,那么命令及正常返回结果如下,证明网络可正常通信。

    telnet 172.16.20.100 10000
    
    Trying 172.16.20.100...
    Connected to 172.16.20.100.
    Escape character is '^]'.
    复制

    如果无法访问服务端口,可能的原因如下:

    • 防火墙设备或集群上的防火墙设置不正确

    • 服务未正常启动,可登录 Transwarp Manager 平台确认。

    • 服务端口发生变更,可登录 Transwarp Manager 平台确认。

  4. 如果客户端通过节点的主机名访问集群中的服务, 为保障正常连接,您需要修改本地 hosts 文件,将 Quark 服务的 IP 地 址与主机名进行关联。以 Windows 平台为例,该文件的路径为 C:\Windows\System32\drivers\etc\hosts

  5. 检查网络通信质量,例如是否存在网络延迟、丢包等问题,从而更快地发现和解决网络问题,常用的工具有:

    • ping:用于测试网络是否连通以及网络的延迟情况,可通过发送 ICMP 报文来检测目标主机的可达性和网络质量。

    • traceroute:用于诊断网络故障,可显示从本地主机到目标主机的路径以及每个节点的延迟情况。

    • mtr:结合了 ping 和 traceroute 的功能,可以连续地对目标主机进行 ping 操作,并输出每个节点的延迟情况,便于查找网络问题的根源。

      接下来,我们以 mtr 命令为例演示,在使用前,您需要执行命令 yum install -y mtr 安装该工具,您可以从客户端向集群进行正向链路测试,也可以从进行反向链路测试。

      # 测试目标为 172.16.20.100,指定发送数量为 100
      mtr 172.16.20.100 -c 100
      
      # 结果示例如下
                                   My traceroute  [v0.85]
      idc1 (0.0.0.0)                                       Thu Apr  6 16:54:53 2023
      Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                           Packets               Pings
       Host                              Loss%   Snt   Last   Avg  Best  Wrst StDev
       1. 172.16.8.254                   0.0%   100    0.8   0.8   0.7   1.4   0.0
       2. 172.16.20.100                   0.0%   100    0.2   0.4   0.2   5.4   0.8
      复制
  6. 如果上述排查都没有发现问题,可在客户端和集群上安装安装抓包工具,例如通过 Wireshark 或 tcpdump,进行网络抓包分析,以定位请求的转发与流向是否存在问题。

检查防火墙设置

当客户端无法连接到 ArgoDB 时,由于防火墙设置可能阻止某些流量通过,当客户端可以 ping 通集群中的机器,但通过 telnet 测试服务端口不通时,可检测防火墙的相关设置。

下述步骤主要介绍集群的防火墙设置检测,关于防火墙设备的检查可联系网络管理员进行排查。

  1. 登录集群中的节点,执行 systemctl status firewalld 命令查看防火墙的状态。如下述返回信息所示,防火墙未启用,那么它不会对集群网络通信产生影响。

    # 检查防火墙状态
    systemctl status firewalld
    
    # 返回示例,状态为未启用
    ● firewalld.service - firewalld - dynamic firewall daemon
       Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:firewalld(1)
    复制
  2. 检查防火墙规则,使用 firewall-cmd --list-all 命令查看当前防火墙规则,需要检查防火墙规则是否允许相关服务所需的端口和协议通过,示例如下:

    # 检查防火墙规则
    firewall-cmd --list-all
    
    # 返回示例,防火墙未开启
    FirewallD is not running
    复制
  3. 检查 iptables 规则,使用 iptables -nL 命令查看 iptables 规则。iptables 规则可能会影响到集群的网络通信,需要检查 iptables 规则是否允许集群所需的端口和协议通过,示例如下:

    # 查看 iptables 规则
    iptables -nL
    
    # 返回示例
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    KUBE-FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    KUBE-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    KUBE-FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0
    
    Chain KUBE-FIREWALL (2 references)
    target     prot opt source               destination
    DROP       all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes firewall for dropping marked packets */ mark match 0x8000/0x8000
    
    Chain KUBE-FORWARD (1 references)
    target     prot opt source               destination
    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            /* kubernetes forwarding rules */ mark match 0x4000/0x4000
    ACCEPT     all  --  10.224.0.0/16        0.0.0.0/0            /* kubernetes forwarding conntrack pod source rule */ ctstate RELATED,ESTABLISHED
    ACCEPT     all  --  0.0.0.0/0            10.224.0.0/16        /* kubernetes forwarding conntrack pod destination rule */ ctstate RELATED,ESTABLISHED
    复制

    上述示例中,只有 被标记了 0x8000/0x8000 的数据包都会被直接丢弃,而默认的 INPUT、FORWARD 和 OUTPUT 链都是允许,即默认接受所有进出该主机的流量。

  4. 检查网络流量,例如使用 tcpdump 或者 Wireshark 工具抓取网络流量,检查是否有集群所需的网络流量被防火墙或者 iptables 规则拦截。

    在使用 tcpdump 前,您需要执行命令 yum install -y tcpdump 安装该工具,使用示例如下:

    # 在 enp4s0f0 网卡上监听来自  172.18.124.29 的数据包,并存储为 dump.pcap 文件
    tcpdump -i enp4s0f0 src 172.18.124.29   -w ./dump.pcap
    
    # 输出如下,表示开始监听并抓取数据包
    tcpdump: listening on enp4s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
    
    # 完成抓取后,按 CTRL + C 停止抓取动作,输出示例如下:
    ^C6 packets captured
    6 packets received by filter
    0 packets dropped by kernel
    复制

    更多用法介绍,见 tcpdump 官方文档

  5. 完成数据包抓取后,您可以将其下载下来,通过电脑上的 Wireshark 软件打开并分析。

    如下图所示,客户端无法连接上 ArgoDB 数据库,通过抓包可以看到 172.18.124.29(客户端) 向 172.18.20.1(服务端) 发起了 6 次 TCP 建立连接的请求,但是服务端均没有响应,证明网络流量是正常到达的,此时需要检查服务端对应的 Quark 服务是否正常运行。

    wireshark demo
    图 5.1.2:Wireshark 分析示例
排查案例

故障现象:重启了某个节点的机器后,无法连接 ArgoDB 数据库,提示:“connection refused”。

scan complete in 15ms
Connecting to jdbc:transwarp2://172.16.20.100:10000/demodata
Error: java.sql.SQLException: Could not open connection to jdbc:transwarp2://172.16.20.100:10000/demodata: java.net.ConnectException: Connection refused (Connection refused) (state=,code=0)
Error: java.sql.SQLException: Could not open connection to jdbc:transwarp2://172.16.20.100:10000/demodata: java.net.ConnectException: Connection refused (Connection refused) (state=,code=0)
复制

排查过程

基于我们前面介绍的排查流程,本次故障的排查过程如下:

  1. 首先我们我们确认故障范围,得知是所有客户端都连接不上。

  2. 确认网络集群的网络环境,得知提供 Quark Server 服务的节点拥有 2 个网卡,一个用于管理,一个用于业务数据转发。

  3. 从客户端分别 ping 这两个网卡的 IP 地址,发现用于业务数据转发的 IP 地址无法通信。

    # 执行 ping 命令
    ping 172.16.20.100
    
    # 返回结果显示无法通信
    PING 172.16.20.100 (172.16.20.100): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    Request timeout for icmp_seq 2
    Request timeout for icmp_seq 3
    复制
  4. 从客户端执行 traceroute 命令,查看网络故障发生的节点,帮助我们缩小排查范围。

    # 执行 traceroute 命令
    traceroute 172.16.20.100
    
    # 返回结果
    traceroute to 172.16.20.100 (172.16.20.100), 64 hops max, 52 byte packets
     1  192.168.10.1 (192.168.10.1)  9.576 ms  5.032 ms  8.567 ms
     2  172.16.20.1 (172.16.20.1)  6.111 ms  4.815 ms  7.682 ms
     3  * * *
     4  * * *
     5  * * *
     6  * * *
    复制

    基于上述返回结果,我们可以判断数据包经过了 2 个网关,但是后一个网关(172.16.20.1)无法将数据正常传送到服务器。

  5. 由于该服务还有一个用于管理的网卡可正常通信,我们登录上该服务,通过 ifconfig 命令 查看网卡运行状态,输出信息如下:

    可以看到 enp4s0f1 网卡虽然是 UP 状态,但是没有 IP 地址信息。

    enp4s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 172.18.20.3  netmask 255.255.252.0  broadcast 172.18.23.255
            inet6 fe80::b747:e54c:cf93:ff55  prefixlen 64  scopeid 0x20<link>
            ether ac:1f:6b:37:49:38  txqueuelen 1000  (Ethernet)
            RX packets 2682112  bytes 161023100 (153.5 MiB)
            RX errors 0  dropped 22  overruns 0  frame 0
            TX packets 2846308  bytes 210321704 (200.5 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device memory 0xc7420000-c743ffff
    
    enp4s0f1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
            ether ac:1f:6b:37:49:39  txqueuelen 1000  (Ethernet)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
            device memory 0xc7400000-c741ffff
    复制
  6. 执行命令:vim /etc/sysconfig/network-scripts/ifcfg-enp4s0f0 查看网卡配置信息。

    配置信息中,ONBOOT 的值设置为 no,即系统启动后不激活网卡,我们将其修改为 yes

  7. 完成修改并保存后,执行命令:service network restart 重启网络服务,网络通信已恢复正常。

  8. 登录 Transwarp Manager 查看所有服务是否正常,如果有因网络故障发生异常的服务,可将其重启以恢复。

    完成排查后,客户端可正常连接至 ArgoDB 数据库。