1.Neutron的問題

openvswitch卡死導(dǎo)致主機(jī)所有網(wǎng)絡(luò)中斷

問題：L3 agent down了，所有的網(wǎng)絡(luò)連接不上，L3所在的物理機(jī)點的公網(wǎng)IP地址訪問不了

鄰水網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)于2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

dhcpagent 服務(wù)器down了，導(dǎo)致所有的云主機(jī)獲取不到地址，所有云主機(jī)的公網(wǎng)IP訪問不到

現(xiàn)象：

網(wǎng)絡(luò)中斷，所有的公網(wǎng)IP地址訪問不到

排查過程：

1、查看openvswitch運行狀態(tài)

2、查看數(shù)據(jù)流量的流向：

   查看所有ovs橋

    ovs-vsctl show

   查看ovs數(shù)據(jù)流

    ovs-ofctl dump-flows br-int 出現(xiàn)卡住的現(xiàn)象，沒有任何相應(yīng)，

由于ovs-vsctl show是從ovsdb取的數(shù)據(jù)，其正常顯示表示ovsdb-server進(jìn)程正常運行。ovs-ofctl是與ovs-vswitchd進(jìn)程通信，命令卡住應(yīng)該是ovs-vswitchd進(jìn)程沒有響應(yīng)客戶端請求導(dǎo)致。

3、查看日志

vim /var/log/openvswitch/ovsdb-server.log 日志

WARN|unix: send error: Broken pipe

2015-09-07T19:43:59.058Z|00010|reconnect|WARN|unix:connection dropped (Broken pipe) //出現(xiàn)隧道破壞的警告

查看/var/log/openvswitch/ovsdb-server.log

出現(xiàn)類似下面的行

|WARN|Unreasonably long 16518ms pollinterval

表明ovs-vswitchd可能因為某個線程死鎖或?qū)е虏豁憫?yīng)。

4、查看進(jìn)程卡在那一步：

 strace -p pid

pid是指進(jìn)程的ID 在這里也就是ovs-vswitchd的PID

解決辦法：

重啟openvswitch服務(wù)

使用cron 任務(wù)檢測

cat /etc/cron.d/monitor_vswitchd

* * * * * root timeout -s SIGKILL 2sovs-ofctl show br-mgmt || (date>>/var/log/mon_openvswitch.log;serviceopenvswitch restart >>  /var/log/mon_openvswitch.log 2>&1 )

升級內(nèi)核

長期來說還是不要用cron來做，而是升級內(nèi)核比較好。升級到2.6.32-504.16.2.el6.x86_64后問題解決。

Nentron DHCP Agent重啟和漂移時，部分虛擬機(jī)斷網(wǎng)

現(xiàn)象：

DHCP Agent重啟或漂移時，部分虛擬機(jī)斷網(wǎng)

問題原因：

在虛擬交換機(jī)比較多時，qdhcp的netns也比較多。漂移或者重啟Neutron DHCP agent后，需要重建這些資源，時間會比較長，有時長達(dá)3-5分鐘。如果在這個周期里正好有虛擬機(jī)需要續(xù)租，向DHCP服務(wù)器發(fā)送的請求就沒有響應(yīng)，最后超時續(xù)租失敗，就算DHCP服務(wù)回復(fù)后，也不會重新嘗試獲取IP地址。這時進(jìn)入虛擬機(jī)命令行，ifup一下eth0就好了。

對于CentOS，我們建議修改dhclient的配置文件，調(diào)長續(xù)租失敗時重試的超時時間，以等待DHCP服務(wù)器的恢復(fù)。

解決方法：

修改配置文件/etc/dhcp/dhclient.conf

  timeout 300;

這樣CentOS虛擬機(jī)續(xù)租的請求會持續(xù)重試5分鐘，以等待DHCP服務(wù)恢復(fù)。

調(diào)整網(wǎng)卡RX ring buffer長度，解決網(wǎng)卡丟包問題

問題：公有云平臺：compute1和compute4兩臺計算節(jié)點的存儲網(wǎng)絡(luò)，不能互通。

解決過程：

1.compute1節(jié)點ping compute4節(jié)點，在compute1和compute4兩臺節(jié)點上使用tcpdump抓包發(fā)現(xiàn)，compute4上有ICMP request和ICMP reply。但compute1節(jié)點并沒有接收到ICMP reply消息，并且有xxxpackets dropped by interface的提示。

2.登錄到pica8交換機(jī)，檢查兩臺機(jī)器的物理連接和鏈路層連接，正常。

3.查看compute1的物理網(wǎng)卡，發(fā)現(xiàn)在RX上有大量的丟包：

[root@compute1 ~]# ifconfig bond2

bond2    Link encap:Ethernet HWaddr00:0A:F7:5D:4A:E2

         inet addr:172.16.3.51 Bcast:172.16.3.255 Mask:255.255.255.0

         inet6 addr: fe80::20a:f7ff:fe5d:4ae2/64 Scope:Link

         UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1

         RX packets:5974542045 errors:8394 dropped:1892018 overruns:8394frame:0

         TX packets:30430136566 errors:0 dropped:0 overruns:0 carrier:0

         collisions:0 txqueuelen:0

         RX bytes:5387974623010 (4.9 TiB) TX bytes:28489033161925 (25.9 TiB)

4.使用ethtool --show-ring 或者ethtool -g 命令查看bond2上真實物理網(wǎng)卡的RX/TX ringbuffer：

[root@compute1 ~]# ethtool --show-ring p6p2

Ring parameters for p6p2:

Pre-set maximums:

RX:    4078

RX Mini:   0

RX Jumbo:  0

TX:    4078

Current hardware settings:

RX:    453

RX Mini:   0

RX Jumbo:  0

TX:    4078

5.懷疑是網(wǎng)卡上的ring buffer參數(shù)設(shè)置過小，無法處理從網(wǎng)卡上接受到的以太網(wǎng)數(shù)據(jù)幀。

6.調(diào)整RX ring buffer的大小，通過ethtool--set-ring或者ethtoo -G

root@compute1 ~]# ethtool --set-ring p6p2rx 4078

Cannot set device ring parameters:Input/output error

[root@compute1 ~]# ethtool --show-ring p6p2

Ring parameters for p6p2:

Pre-set maximums:

RX:    4078

RX Mini:   0

RX Jumbo:  0

TX:    4078

Current hardware settings:

RX:    4078

RX Mini:   0

RX Jumbo:  0

TX:    4078

7.這樣的修改，在機(jī)器reboot會回到原來的配置，建議在寫入到/etc/rc.local下

ethtool -G p6p2rx 4078

ethtool -G p7p2rx 4078

網(wǎng)卡驅(qū)動缺陷導(dǎo)致的問題

現(xiàn)象：網(wǎng)卡驅(qū)動缺陷導(dǎo)致offload后ping正常但TCP連接慢或斷的問題診斷與解決

常見的原因有：

1.MTU問題

確認(rèn)物理服務(wù)器網(wǎng)卡和上聯(lián)交換機(jī)MTU是否有問題；一般硬件廠商的MTU默認(rèn)是1500，當(dāng)然也有例外，像Pica8的SDN交換機(jī)，MTU值在小于1512會丟包。

 2.物理網(wǎng)卡offload

Fuel部署時，默認(rèn)開啟了物理網(wǎng)卡offload屬性。由于開啟了offload屬性，有可能會出現(xiàn)TCP或者UDP檢驗和不一致導(dǎo)致的丟包或重傳。

解決方法：

TCP校驗和會確保整個報文在傳輸過程中不會發(fā)生變化，如果校驗和不一致，TCP會丟棄這個報文或者觸發(fā)超時重傳。TCP的校驗和是必須的，UDP的校驗和是非必須的。此時，建議將rx和tx關(guān)閉。

RX Checksum：

在開啟此功能后，物理網(wǎng)卡收到一個數(shù)據(jù)包時，網(wǎng)卡會代替內(nèi)核協(xié)議棧計算傳輸層校驗和，并且只在校驗和正確的情況下將數(shù)據(jù)包交由內(nèi)核處理，以節(jié)約系統(tǒng)CPU資源。

關(guān)閉此feature：ethtool -KDEVNAME rx on|off

TX Checksum：

這個是在數(shù)據(jù)包發(fā)送之前，由網(wǎng)卡計算校驗和；開啟此選項，內(nèi)核會隨機(jī)填充TCP或UDP的檢驗和字段，正確的填充會由物理網(wǎng)卡來完成。

 關(guān)閉此feature：ethtool -K DEVNAME tx on|off

  持久化offload設(shè)置

可以編輯/etc/rc.local加入ethtool命令?；蛘呃肅entOS的ifcfg-腳本。譬如要關(guān)閉eth0的tx和rx的checksum offload，可以編輯下面的文件/etc/sysconfig/ network-scripts/ ifcfg-eth0加入一行 ETHTOOL_OPTS="-Keth0 rx off;-K eth0 tx off"然后ifup eth0，設(shè)置便生效。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

本文名稱：常見故障Neutron-創(chuàng)新互聯(lián)
鏈接分享：http://jinyejixie.com/article46/decehg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計、ChatGPT、做網(wǎng)站、網(wǎng)站建設(shè)、軟件開發(fā)、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)