学习Linux服务器故障排查实用指南
时间:2016-05-29 04:52 来源:linux.it.net.cn 作者:IT
由于造成网络问题的因素多种多样，因此网络故障排查技能就成了每位服务器或网络服务负责人必不可少的重要素质。Linux为我们提供了大量网络故障排查工具，在本文中，我们将讨论一些常见的网络问题，并介绍如何利用某些Linux工具追踪意外状况发生的根本原因。
问题：服务器A无法与服务器B通信
可能大家在实际工作中最常见的网络故障就是一台服务器无法与另一台网络上的服务器进行通信。本小节将通过实例讲解具体处理办法。在实例中，一台名为dev1的服务器无法访问另一台名为web1的服务器中的网络服务(端口80)。导致这一现象的原因相当繁杂，因此我们需要一步步测试操作活动，进而通过排除法找到故障的根源。
一般说来，在对这样的问题进行故障排查时，大家可能会跳过某些初始步骤(例如检查链接等)，因为接下来的某些测试环节能起到同样的诊断作用。举例来说，如果我们测试并确认DNS能够正常工作，那么就证明我们的主机是能够与本地网络进行通信的。但在本次实例解析中，我们将本着谨慎的态度执行每一个步骤，借以理解各个级别的不同测试方式。
问题出在客户机还是服务器端?
大家可以利用一项快速测试缩小造成故障的范围，即通过同一网络中的另一台主机尝试访问对应服务器。在本实例中，我们姑且将另一台与dev1同处一套网络环境下的服务器命名为dev2，并尝试通过它访问web1。如果dev2也不能正常访问web1，那么显然问题很可能出在web1或者是dev1、dev2及web1之间的网络身上。如果dev2能够正常访问web1，那么我们就可以断定dev1出问题的机率较大。首先，我们假设dev2能够访问web1，因此我们开始将故障排查的重点放在dev1这边。
线缆插好了吗?
故障排查的第一步要在客户机上进行。大家首先要确认自己客户机的网络连接没有问题。要做到这一点，我们可以使用ethtool程序(通过ethtool工具包安装)对链接(即以太网设备与网络构成物理连接)情况加以检测。如果大家无法确定自己使用的是哪个端口，那么请运行/sbin/ifconfig命令将所有可用的网络端口及其设定列出。我们假设自己的以太网设备在eth0端口上，那么：
$ sudo ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pg
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes
在最后一行中，大家可以看到检测结果显示链接设置为“yes”，所以dev1已经与网络构成物理连接。如果这项检测的结果为“no”，那么我们需要亲自检查dev1的网络连接，并将线缆插实到位。在确定物理连接没有问题之后，执行下面的步骤。
注意：ethtool绝不仅仅是一款用于检测链接状况的工具，它还能够诊断并纠正双工问题。当Linux服务器与网络连通时，通常会与网络自动协商以获取传输速度信息以及该网络是否支持全双工。在本实例中，传输速度经ethtool检测为100Mb/秒，且该网络支持全双工机制。如果大家发现主机的网络传输速度缓慢，那么速度及双工设定是首先需要关注的重点。如前文所示运行ethtool，若大家发现双工被设定为一半，则运行以下命令：
$ sudo ethtool -s eth0 autoneg off duplex full
意思是利用自己的以太网设备代替eth0。
端口正常吗?
一旦确认了服务器与网络之间物理连接的完好性，接下来就是判断主机上的网络端口是否配置正确。在这方面，最好的检查方式就是运行ifconfig命令并将端口作为参数后缀。因此要测试eth0的设置，大家应该运行以下内容：
$ sudo ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:17:42:1f:18:be
inet addr:10.1.1.7 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::217:42ff:fe1f:18be/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:229 (229.0 B) TX bytes:2178 (2.1 KB)
Interrupt:10
在上述输出结果中，第二行可能最值得我们关注，因为其内容是解释我们的主机已经被配置了一套IP地址(10.1.1.7)与子网掩码(255.255.255.0)。现在，大家需要确认这样的设置结果是否正确。如果端口未受配置，请尝试运行sudo ifup eth0，然后再次运行ifconfig重新检查端口是否出现。如果设置错误或端口未出现，则检查/etc/network/interfaces路径(Debian系统)或/etc/-sysconfig/-network_scripts/ifcfg-路径(红帽系统)。在这些文件中，大家可以修正网络设置中存在的所有错误。现在如果主机通过DHCP获得自身IP，我们则需要将故障排查转移到DHCP主机处，找出为什么我们没有正确获得IP租用周期。
问题出在本地网络中吗?
排除了端口出现的问题之后，接下来我们就该检查默认网关是否被设置及我们能否对其进行访问。route命令将显示出我们当前的路由表，包括默认网关：
$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.1.1.0 * 255.255.255.0 U 0 0 0 eth0
default 10.1.1.1 0.0.0.0 UG 100 0 0 eth0
以上内容中值得关注的在于最后一行，也就是default那段内容。在这里，大家可以看到主机网关为10.1.1.1.请注意，由于我们在route命令后添加了-n选项，所以命令不会尝试将这些IP地址解析为实际主机名称。这种方式能让命令的运行更迅速，但更重要的是，我们不希望故障排查工作受到任何潜在DNS错误的影响。如果大家没有在这里看到经过配置的默认网关，而我们想要检查的主机处于另一子网之下(例如web1为10.1.2.5)，那么问题很可能就出在这里。要将其解决，大家一定要确保网关设置要么处于Debian系统的/etc/network/interfaces路径下、要么是在红帽系统的/etc/-sysconfig/network_scripts/ifcfg-路径下;如果IP是由DHCP所分配，则确保网关在DHCP服务器中被正确设置。在Debian系统中，我们运行如下命令进行端口重置：
$ sudo service networking restart
而在红帽系统中我们需要运行如下命令进行端口重置：
$ sudo service network restart
请大家注意，即使是如此基本的操作命令在不同的系统发行版中也存在着差异。
一旦确认网关配置完成，我们可以利用ping命令来确认与网关的通信效果：
$ ping -c 5 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=3.13 ms
64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=1.43 ms
64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=1.79 ms
64 bytes from 10.1.1.1: icmp_seq=5 ttl=64 time=1.50 ms
--- 10.1.1.1 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4020ms
rtt min/avg/max/mdev = 1.436/1.966/3.132/0.686 ms
(责任编辑：IT)
由于造成网络问题的因素多种多样，因此网络故障排查技能就成了每位服务器或网络服务负责人必不可少的重要素质。Linux为我们提供了大量网络故障排查工具，在本文中，我们将讨论一些常见的网络问题，并介绍如何利用某些Linux工具追踪意外状况发生的根本原因。 问题：服务器A无法与服务器B通信 可能大家在实际工作中最常见的网络故障就是一台服务器无法与另一台网络上的服务器进行通信。本小节将通过实例讲解具体处理办法。在实例中，一台名为dev1的服务器无法访问另一台名为web1的服务器中的网络服务(端口80)。导致这一现象的原因相当繁杂，因此我们需要一步步测试操作活动，进而通过排除法找到故障的根源。 一般说来，在对这样的问题进行故障排查时，大家可能会跳过某些初始步骤(例如检查链接等)，因为接下来的某些测试环节能起到同样的诊断作用。举例来说，如果我们测试并确认DNS能够正常工作，那么就证明我们的主机是能够与本地网络进行通信的。但在本次实例解析中，我们将本着谨慎的态度执行每一个步骤，借以理解各个级别的不同测试方式。 问题出在客户机还是服务器端? 大家可以利用一项快速测试缩小造成故障的范围，即通过同一网络中的另一台主机尝试访问对应服务器。在本实例中，我们姑且将另一台与dev1同处一套网络环境下的服务器命名为dev2，并尝试通过它访问web1。如果dev2也不能正常访问web1，那么显然问题很可能出在web1或者是dev1、dev2及web1之间的网络身上。如果dev2能够正常访问web1，那么我们就可以断定dev1出问题的机率较大。首先，我们假设dev2能够访问web1，因此我们开始将故障排查的重点放在dev1这边。 线缆插好了吗? 故障排查的第一步要在客户机上进行。大家首先要确认自己客户机的网络连接没有问题。要做到这一点，我们可以使用ethtool程序(通过ethtool工具包安装)对链接(即以太网设备与网络构成物理连接)情况加以检测。如果大家无法确定自己使用的是哪个端口，那么请运行/sbin/ifconfig命令将所有可用的网络端口及其设定列出。我们假设自己的以太网设备在eth0端口上，那么： $ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pg Wake-on: d Current message level: 0x000000ff (255) Link detected: yes 在最后一行中，大家可以看到检测结果显示链接设置为“yes”，所以dev1已经与网络构成物理连接。如果这项检测的结果为“no”，那么我们需要亲自检查dev1的网络连接，并将线缆插实到位。在确定物理连接没有问题之后，执行下面的步骤。 注意：ethtool绝不仅仅是一款用于检测链接状况的工具，它还能够诊断并纠正双工问题。当Linux服务器与网络连通时，通常会与网络自动协商以获取传输速度信息以及该网络是否支持全双工。在本实例中，传输速度经ethtool检测为100Mb/秒，且该网络支持全双工机制。如果大家发现主机的网络传输速度缓慢，那么速度及双工设定是首先需要关注的重点。如前文所示运行ethtool，若大家发现双工被设定为一半，则运行以下命令： $ sudo ethtool -s eth0 autoneg off duplex full 意思是利用自己的以太网设备代替eth0。 端口正常吗? 一旦确认了服务器与网络之间物理连接的完好性，接下来就是判断主机上的网络端口是否配置正确。在这方面，最好的检查方式就是运行ifconfig命令并将端口作为参数后缀。因此要测试eth0的设置，大家应该运行以下内容： $ sudo ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:17:42:1f:18:be inet addr:10.1.1.7 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::217:42ff:fe1f:18be/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:229 (229.0 B) TX bytes:2178 (2.1 KB) Interrupt:10
在上述输出结果中，第二行可能最值得我们关注，因为其内容是解释我们的主机已经被配置了一套IP地址(10.1.1.7)与子网掩码(255.255.255.0)。现在，大家需要确认这样的设置结果是否正确。如果端口未受配置，请尝试运行sudo ifup eth0，然后再次运行ifconfig重新检查端口是否出现。如果设置错误或端口未出现，则检查/etc/network/interfaces路径(Debian系统)或/etc/-sysconfig/-network_scripts/ifcfg- 问题出在本地网络中吗? 排除了端口出现的问题之后，接下来我们就该检查默认网关是否被设置及我们能否对其进行访问。route命令将显示出我们当前的路由表，包括默认网关： $ sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.1.1.0 * 255.255.255.0 U 0 0 0 eth0 default 10.1.1.1 0.0.0.0 UG 100 0 0 eth0
以上内容中值得关注的在于最后一行，也就是default那段内容。在这里，大家可以看到主机网关为10.1.1.1.请注意，由于我们在route命令后添加了-n选项，所以命令不会尝试将这些IP地址解析为实际主机名称。这种方式能让命令的运行更迅速，但更重要的是，我们不希望故障排查工作受到任何潜在DNS错误的影响。如果大家没有在这里看到经过配置的默认网关，而我们想要检查的主机处于另一子网之下(例如web1为10.1.2.5)，那么问题很可能就出在这里。要将其解决，大家一定要确保网关设置要么处于Debian系统的/etc/network/interfaces路径下、要么是在红帽系统的/etc/-sysconfig/network_scripts/ifcfg- $ sudo service networking restart 而在红帽系统中我们需要运行如下命令进行端口重置： $ sudo service network restart 请大家注意，即使是如此基本的操作命令在不同的系统发行版中也存在着差异。 一旦确认网关配置完成，我们可以利用ping命令来确认与网关的通信效果： $ ping -c 5 10.1.1.1 PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=3.13 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=1.43 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=64 time=1.79 ms 64 bytes from 10.1.1.1: icmp_seq=5 ttl=64 time=1.50 ms --- 10.1.1.1 ping statistics --- 5 packets transmitted, 4 received, 20% packet loss, time 4020ms rtt min/avg/max/mdev = 1.436/1.966/3.132/0.686 ms (责任编辑：IT) |