DB SERVER服務(wù)器網(wǎng)卡不穩(wěn)定的原因什么

DB SERVER服務(wù)器網(wǎng)卡不穩(wěn)定的原因什么，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

    DB SERVER服務(wù)器在壓測(cè)中發(fā)現(xiàn)網(wǎng)卡很不穩(wěn)定，壓力測(cè)試剛剛進(jìn)行十幾分鐘后，服務(wù)器反應(yīng)就變得非常慢，PING的時(shí)候經(jīng)常丟包而且SSH連接也時(shí)斷時(shí)續(xù)。剛開(kāi)始以為是高并發(fā)時(shí)導(dǎo)致的db server無(wú)響應(yīng)，可以看了一下CPU、內(nèi)存和硬盤(pán)IO，發(fā)現(xiàn)都沒(méi)有達(dá)到較高值，甚至比我們的預(yù)警值低很多，而且監(jiān)測(cè)也表明DB服務(wù)器剩余資源很充裕！真是比較奇怪，那么引起網(wǎng)卡不穩(wěn)定的原因到底是什么呢？  
向相關(guān)工程師了解了一下情況，知道這臺(tái)DB服務(wù)器是雙機(jī)熱備中的一臺(tái)服務(wù)器，前幾天剛做的2組千兆網(wǎng)卡綁定。據(jù)工程師說(shuō)綁定前也做過(guò)壓測(cè)，沒(méi)有出現(xiàn)這樣的問(wèn)題。難道是綁定設(shè)置的哪個(gè)環(huán)節(jié)出問(wèn)題了？于是決定從千兆網(wǎng)卡綁定進(jìn)行詳細(xì)檢查。  
故障現(xiàn)象圖示:  
   
 
一、 檢查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  
 
分析：很標(biāo)準(zhǔn)的配置，沒(méi)有什么問(wèn)題。在這里注意不要指定單個(gè)網(wǎng)卡的IP 地址、子網(wǎng)掩碼或網(wǎng)卡 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.  
(注:臨時(shí)設(shè)置網(wǎng)卡的千兆全雙工可以這樣

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  
主要目的是使系統(tǒng)在啟動(dòng)時(shí)加載bonding模塊，對(duì)外虛擬網(wǎng)絡(luò)接口設(shè)備為 bond0、bond1  
另外miimon是用來(lái)進(jìn)行鏈路監(jiān)測(cè)的。 比如:miimon=100，那么系統(tǒng)每100ms監(jiān)測(cè)一次鏈路連接狀態(tài)，如果有一條線路不通就轉(zhuǎn)入另一條線路;mode的值表示工作模式，他共有0，1,2,3四種模式，常用的為0,1兩種。  
　　mode=0表示load balancing (round-robin)為負(fù)載均衡方式，兩塊網(wǎng)卡都工作。  
　　mode=1表示fault-tolerance (active-backup)提供冗余功能，工作方式是主備的工作方式,也就是說(shuō)默認(rèn)情況下只有一塊網(wǎng)卡工作,另一塊做備份.

　　注意：bonding只能提供鏈路監(jiān)測(cè)，即從主機(jī)到交換機(jī)的鏈路是否接通。如果只是交換機(jī)對(duì)外的鏈路down掉了，而交換機(jī)本身并沒(méi)有故障，那么bonding會(huì)認(rèn)為鏈路沒(méi)有問(wèn)題而繼續(xù)使用。  
        這部分的配置也沒(méi)有問(wèn)題。  
　    到這里似乎還沒(méi)看到問(wèn)題的所在，不過(guò)還有一個(gè)地方是大家容易忽視的，那就是rc.local文件，為了讓網(wǎng)卡綁定在每次啟動(dòng)后都能立即生效，我們通常會(huì)設(shè)置 rc.local.所以我們還應(yīng)檢查一下這個(gè)文件。  
 
四、檢查rc.local文件  
# cat  /etc/rc.d/rc.local  
touch /var/lock/subsys/local  
ifenslave bond0 eth0 eth2  
ifenslave bond1 eth3 eth4　  

分析：這樣的設(shè)置方便開(kāi)機(jī)啟動(dòng)時(shí)，自動(dòng)載入配置?！　?  
注意：這里是把 eth0和 eth2放到bond0里，eth3和 eth4放到bond1里。如果大家仔細(xì)回想的話，會(huì)發(fā)現(xiàn)在第二步檢查當(dāng)中是eth0和 eth3綁定為BOND0， eth2和 eth4綁定為BOND1的?？磥?lái)問(wèn)題的罪魁禍?zhǔn)拙驮谶@里，那么這樣配置錯(cuò)了，會(huì)造成什么現(xiàn)象呢？  
 
首先回顧一下網(wǎng)卡綁定的原理。我們知道，在正常情況下，ethernet網(wǎng)卡只接收目的mac地址是自身mac的ether幀，對(duì)于別的數(shù)據(jù)幀都過(guò)濾掉，以減輕驅(qū)動(dòng)程序——也就是軟件的負(fù)擔(dān)。但是ethernet網(wǎng)卡也支持另外一種被稱(chēng)為promisc的模式，可以接收網(wǎng)絡(luò)上所有的幀，很多系統(tǒng)程序如：sniffer、tcpdump，都運(yùn)行在這個(gè)模式下。Bonding網(wǎng)卡綁定也運(yùn)行在這個(gè)模式下，而且修改了驅(qū)動(dòng)程序中的mac地址，將兩塊網(wǎng)卡的mac地址改成相同，可以接收特定mac的數(shù)據(jù)幀。然后把相應(yīng)的數(shù)據(jù)幀傳送給bond驅(qū)動(dòng)程序處理。  
 
那么在我們檢查的這個(gè)rc.local文件中，由于系統(tǒng)工程師的粗心把網(wǎng)卡綁定配置錯(cuò)了，這樣一個(gè)細(xì)微的配置錯(cuò)誤就會(huì)造成一個(gè)IP地址對(duì)應(yīng)兩個(gè)不同的MAC地址，顯然會(huì)造成網(wǎng)絡(luò)的延遲和不穩(wěn)定，這跟ARP***比較像。當(dāng)有多個(gè)不同MAC對(duì)應(yīng)同樣的IP，網(wǎng)絡(luò)里面各機(jī)器包括路由器對(duì)應(yīng)這個(gè)IP的ARP會(huì)不停的變，包不是丟了就是發(fā)到錯(cuò)誤的MAC了。  

我們可以檢查一下各網(wǎng)卡的ＭＡＣ來(lái)確認(rèn)一下。  
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的ＭＡＣ是一樣的。  
 
針對(duì)問(wèn)題原因，立即修改rc.local這個(gè)文件，改回正確的配置。  
ifenslave bond0 eth0 eth3  
ifenslave bond1 eth2 eth4　

然后重啟服務(wù)器，再進(jìn)行壓測(cè)，發(fā)現(xiàn)果然一切正常了。    

Linux雙網(wǎng)卡的綁定是一個(gè)比較具體的操作工作，在配置當(dāng)中我們不僅要熟悉了解它的原理，更要在部署實(shí)施時(shí)仔細(xì)認(rèn)真，一個(gè)疏忽就會(huì)造成網(wǎng)絡(luò)的不穩(wěn)定和節(jié)點(diǎn)的癱瘓。    

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