DBSERVER服务器网卡不稳定的原因什么
DB SERVER服务器网卡不稳定的原因什么,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
我们提供的服务有:网站制作、成都网站制作、微信公众号开发、网站优化、网站认证、永善ssl等。为数千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务,是有科学管理、有技术的永善网站制作公司
DB SERVER服务器在压测中发现网卡很不稳定,压力测试刚刚进行十几分钟后,服务器反应就变得非常慢,PING的时候经常丢包而且SSH连接也时断时续。刚开始以为是高并发时导致的db server无响应,可以看了一下CPU、内存和硬盘IO,发现都没有达到较高值,甚至比我们的预警值低很多,而且监测也表明DB服务器剩余资源很充裕!真是比较奇怪,那么引起网卡不稳定的原因到底是什么呢?
向相关工程师了解了一下情况,知道这台DB服务器是双机热备中的一台服务器,前几天刚做的2组千兆网卡绑定。据工程师说绑定前也做过压测,没有出现这样的问题。难道是绑定设置的哪个环节出问题了?于是决定从千兆网卡绑定进行详细检查。
故障现象图示:
一、 检查ifcfg-bond0和ifcfg-bond1文件
#cat /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.58.11.11
NETMASK=255.255.255.0
GATEWAY=10.58.121.254
USERCTL=no
#cat /etc/sysconfig/network-scripts/ifcfg-bond1
DEVICE=bond1
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.10.10.18
NETMASK=255.255.255.0
GATEWAY=10.58.121.254
USERCTL=no
分析:很标准的配置,没有什么问题。在这里注意不要指定单个网卡的IP 地址、子网掩码或网卡 ID。将上述信息指定到虚拟适配器(bonding)中即可。
二、检查ifcfg-eth0、ifcfg-eth2、ifcfg-eth3、ifcfg-eth4文件
#cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
USERCTL=no
ETHTOOL_OPTS="speed 1000 duplex full autoneg on"
#cat /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
ONBOOT=yes
BOOTPROTO=none
MASTER=bond1
SLAVE=yes
USERCTL=no
ETHTOOL_OPTS="speed 1000 duplex full autoneg on"
#cat /etc/sysconfig/network-scripts/ifcfg-eth3
DEVICE=eth3
ONBOOT=yes
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
USERCTL=no
ETHTOOL_OPTS="speed 1000 duplex full autoneg on"
#cat /etc/sysconfig/network-scripts/ifcfg-eth4
DEVICE=eth4
ONBOOT=yes
BOOTPROTO=none
MASTER=bond1
SLAVE=yes
USERCTL=no
ETHTOOL_OPTS="speed 1000 duplex full autoneg on"
分析:从配置文件上看是eth0和 eth3绑定为BOND0, eth2和 eth4绑定为BOND1.
(注:临时设置网卡的千兆全双工可以这样
ethtool -s eth0 speed 1000 duplex full autoneg on
ethtool -s eth2 speed 1000 duplex full autoneg on)
三、 检查modprobe.conf配置文件
# cat /etc/modprobe.conf
alias eth0 bnx2
alias eth2 bnx2
alias eth3 bnx2
alias eth4 bnx2
alias scsi_hostadapter megaraid_sas
alias scsi_hostadapter1 ata_piix
alias scsi_hostadapter2 lpfc
alias bond0 bonding
options bond0 miimon=100 mode=0
alias bond1 bonding
options bond1 miimon=100 mode=1
###BEGINPP
include /etc/modprobe.conf.pp
###ENDPP
分析:从此文件看加入
alias bond0 bonding
options bond0 miimon=100 mode=0
alias bond1 bonding
options bond1 miimon=100 mode=1
主要目的是使系统在启动时加载bonding模块,对外虚拟网络接口设备为 bond0、bond1
另外miimon是用来进行链路监测的。 比如:miimon=100,那么系统每100ms监测一次链路连接状态,如果有一条线路不通就转入另一条线路;mode的值表示工作模式,他共有0,1,2,3四种模式,常用的为0,1两种。
mode=0表示load balancing (round-robin)为负载均衡方式,两块网卡都工作。
mode=1表示fault-tolerance (active-backup)提供冗余功能,工作方式是主备的工作方式,也就是说默认情况下只有一块网卡工作,另一块做备份.
注意:bonding只能提供链路监测,即从主机到交换机的链路是否接通。如果只是交换机对外的链路down掉了,而交换机本身并没有故障,那么bonding会认为链路没有问题而继续使用。
这部分的配置也没有问题。
到这里似乎还没看到问题的所在,不过还有一个地方是大家容易忽视的,那就是rc.local文件,为了让网卡绑定在每次启动后都能立即生效,我们通常会设置 rc.local.所以我们还应检查一下这个文件。
四、检查rc.local文件
# cat /etc/rc.d/rc.local
touch /var/lock/subsys/local
ifenslave bond0 eth0 eth2
ifenslave bond1 eth3 eth4
分析:这样的设置方便开机启动时,自动载入配置。
注意:这里是把 eth0和 eth2放到bond0里,eth3和 eth4放到bond1里。如果大家仔细回想的话,会发现在第二步检查当中是eth0和 eth3绑定为BOND0, eth2和 eth4绑定为BOND1的。看来问题的罪魁祸首就在这里,那么这样配置错了,会造成什么现象呢?
首先回顾一下网卡绑定的原理。我们知道,在正常情况下,ethernet网卡只接收目的mac地址是自身mac的ether帧,对于别的数据帧都过滤掉,以减轻驱动程序——也就是软件的负担。但是ethernet网卡也支持另外一种被称为promisc的模式,可以接收网络上所有的帧,很多系统程序如:sniffer、tcpdump,都运行在这个模式下。Bonding网卡绑定也运行在这个模式下,而且修改了驱动程序中的mac地址,将两块网卡的mac地址改成相同,可以接收特定mac的数据帧。然后把相应的数据帧传送给bond驱动程序处理。
那么在我们检查的这个rc.local文件中,由于系统工程师的粗心把网卡绑定配置错了,这样一个细微的配置错误就会造成一个IP地址对应两个不同的MAC地址,显然会造成网络的延迟和不稳定,这跟ARP***比较像。当有多个不同MAC对应同样的IP,网络里面各机器包括路由器对应这个IP的ARP会不停的变,包不是丢了就是发到错误的MAC了。
我们可以检查一下各网卡的MAC来确认一下。
eth0 Link encap:Ethernet
HWaddr D4:AE:52:7F:D1:74
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:358839038 errors:0 dropped:0 overruns:0 frame:0
TX packets:445740732 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:84060158481 (78.2 GiB) TX bytes:324117093205 (301.8 GiB)
Interrupt:178 Memory:c6000000-c6012800
eth2 Link encap:Ethernet
HWaddr D4:AE:52:7F:D1:76
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1319022534 errors:0 dropped:0 overruns:0 frame:0
TX packets:827575644 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:402801656790 (375.1 GiB) TX bytes:249765452577 (232.6 GiB)
Interrupt:186 Memory:c8000000-c8012800
eth3 Link encap:Ethernet
HWaddr D4:AE:52:7F:D1:74
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:368142910 errors:0 dropped:0 overruns:0 frame:0
TX packets:445816695 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88487806059 (82.4 GiB) TX bytes:324236716714 (301.9 GiB)
Interrupt:194 Memory:ca000000-ca012800
eth4 Link encap:Ethernet
HWaddr D4:AE:52:7F:D1:76
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1311065414 errors:0 dropped:0 overruns:0 frame:0
TX packets:827581593 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:400383501186 (372.8 GiB) TX bytes:249850192137 (232.6 GiB)
Interrupt:202 Memory:cc000000-cc012800
可以看到eth0和eth3的MAC是一样的,eth2和eth4的MAC是一样的。
针对问题原因,立即修改rc.local这个文件,改回正确的配置。
ifenslave bond0 eth0 eth3
ifenslave bond1 eth2 eth4
然后重启服务器,再进行压测,发现果然一切正常了。
Linux双网卡的绑定是一个比较具体的操作工作,在配置当中我们不仅要熟悉了解它的原理,更要在部署实施时仔细认真,一个疏忽就会造成网络的不稳定和节点的瘫痪。
看完上述内容,你们掌握DB SERVER服务器网卡不稳定的原因什么的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注创新互联行业资讯频道,感谢各位的阅读!
分享标题:DBSERVER服务器网卡不稳定的原因什么
分享路径:http://azwzsj.com/article/jcpogj.html