DB SERVER服務器網卡不穩定的原因什么

DB SERVER服務器網卡不穩定的原因什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

    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了。  

我們可以檢查一下各網卡的ＭＡＣ來確認一下。  
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的ＭＡＣ是一樣的，eth2和eth4的ＭＡＣ是一樣的。  
 
針對問題原因，立即修改rc.local這個文件，改回正確的配置。  
ifenslave bond0 eth0 eth3  
ifenslave bond1 eth2 eth4　

然后重啟服務器，再進行壓測，發現果然一切正常了。    

Linux雙網卡的綁定是一個比較具體的操作工作，在配置當中我們不僅要熟悉了解它的原理，更要在部署實施時仔細認真，一個疏忽就會造成網絡的不穩定和節點的癱瘓。    

看完上述內容，你們掌握DB SERVER服務器網卡不穩定的原因什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！