常見故障Neutron

1.Neutron的問題

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

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

10多年的可克達(dá)拉網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整可克達(dá)拉建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)公司從事“可克達(dá)拉網(wǎng)站設(shè)計(jì)”,“可克達(dá)拉網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

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

現(xiàn)象：

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

排查過程：

1、查看openvswitch運(yùn)行狀態(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)程正常運(yù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可能因?yàn)槟硞€(gè)線程死鎖或?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重啟和漂移時(shí)，部分虛擬機(jī)斷網(wǎng)

現(xiàn)象：

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

問題原因：

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

對于CentOS，我們建議修改dhclient的配置文件，調(diào)長續(xù)租失敗時(shí)重試的超時(shí)時(shí)間，以等待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兩臺計(jì)算節(jié)點(diǎn)的存儲網(wǎng)絡(luò)，不能互通。

解決過程：

1.compute1節(jié)點(diǎn)ping compute4節(jié)點(diǎn)，在compute1和compute4兩臺節(jié)點(diǎn)上使用tcpdump抓包發(fā)現(xiàn)，compute4上有ICMP request和ICMP reply。但compute1節(jié)點(diǎn)并沒有接收到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上真實(shí)物理網(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òng)缺陷導(dǎo)致的問題

現(xiàn)象：網(wǎng)卡驅(qū)動(dòng)缺陷導(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部署時(shí)，默認(rèn)開啟了物理網(wǎng)卡offload屬性。由于開啟了offload屬性，有可能會出現(xiàn)TCP或者UDP檢驗(yàn)和不一致導(dǎo)致的丟包或重傳。

解決方法：

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

RX Checksum：

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

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

TX Checksum：

這個(gè)是在數(shù)據(jù)包發(fā)送之前，由網(wǎng)卡計(jì)算校驗(yàn)和；開啟此選項(xiàng)，內(nèi)核會隨機(jī)填充TCP或UDP的檢驗(yàn)和字段，正確的填充會由物理網(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è)置便生效。

 

當(dāng)前標(biāo)題：常見故障Neutron
當(dāng)前地址：http://muchs.cn/article30/ghjepo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、服務(wù)器托管、外貿(mào)建站、網(wǎng)站營銷、App設(shè)計(jì)、定制網(wǎng)站

廣告

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