常見故障 Neutron

1.Neutron的問題

openvswitch卡死導致主機所有網絡中斷

問題：L3 agent down了，所有的網絡連接不上，L3所在的物理機點的公網IP地址訪問不了

dhcpagent 服務器down了，導致所有的云主機獲取不到地址，所有云主機的公網IP訪問不到

現象：

網絡中斷，所有的公網IP地址訪問不到

排查過程：

1、查看openvswitch運行狀態

2、查看數據流量的流向：

    查看所有ovs橋

    ovs-vsctl show

    查看ovs數據流

    ovs-ofctl dump-flows br-int 出現卡住的現象，沒有任何相應，

由于ovs-vsctl show是從ovsdb取的數據，其正常顯示表示ovsdb-server進程正常運行。ovs-ofctl是與ovs-vswitchd進程通信，命令卡住應該是ovs-vswitchd進程沒有響應客戶端請求導致。

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)  //出現隧道破壞的警告

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

出現類似下面的行

|WARN|Unreasonably long 16518ms pollinterval

表明ovs-vswitchd可能因為某個線程死鎖或導致不響應。

4、查看進程卡在那一步：

 strace -p pid 

pid是指進程的ID 在這里也就是ovs-vswitchd的PID

解決辦法：

重啟openvswitch服務

使用cron 任務檢測

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 )

升級內核

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

Nentron DHCP Agent重啟和漂移時，部分虛擬機斷網

現象：

DHCP Agent重啟或漂移時，部分虛擬機斷網

問題原因：

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

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

解決方法：

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

   timeout 300;

這樣CentOS虛擬機續租的請求會持續重試5分鐘，以等待DHCP服務恢復。

調整網卡RX ring buffer長度，解決網卡丟包問題

問題：公有云平臺：compute1和compute4兩臺計算節點的存儲網絡，不能互通。

解決過程：

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

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

3.查看compute1的物理網卡，發現在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上真實物理網卡的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.懷疑是網卡上的ring buffer參數設置過小，無法處理從網卡上接受到的以太網數據幀。

6.調整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.這樣的修改，在機器reboot會回到原來的配置，建議在寫入到/etc/rc.local下

ethtool -G p6p2rx 4078

ethtool -G p7p2rx 4078

網卡驅動缺陷導致的問題

現象：網卡驅動缺陷導致offload后ping正常但TCP連接慢或斷的問題診斷與解決

常見的原因有：

1.MTU問題

確認物理服務器網卡和上聯交換機MTU是否有問題；一般硬件廠商的MTU默認是1500，當然也有例外，像Pica8的SDN交換機，MTU值在小于1512會丟包。

 2.物理網卡offload

Fuel部署時，默認開啟了物理網卡offload屬性。由于開啟了offload屬性，有可能會出現TCP或者UDP檢驗和不一致導致的丟包或重傳。

解決方法：

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

RX Checksum：

在開啟此功能后，物理網卡收到一個數據包時，網卡會代替內核協議棧計算傳輸層校驗和，并且只在校驗和正確的情況下將數據包交由內核處理，以節約系統CPU資源。

關閉此feature：ethtool -KDEVNAME rx on|off

TX Checksum：

這個是在數據包發送之前，由網卡計算校驗和；開啟此選項，內核會隨機填充TCP或UDP的檢驗和字段，正確的填充會由物理網卡來完成。

 關閉此feature：ethtool -K DEVNAME tx on|off

   持久化offload設置

可以編輯/etc/rc.local加入ethtool命令。或者利用CentOS的ifcfg-腳本。譬如要關閉eth0的tx和rx的checksum offload，可以編輯下面的文件/etc/sysconfig/ network-scripts/ ifcfg-eth0加入一行 ETHTOOL_OPTS="-Keth0 rx off;-K eth0 tx off"然后ifup eth0，設置便生效。