雙層VLAN

我在加拿大不列顛哥倫比亞省的基隆拿創建了一套新的OpenStack系統。整個部署過程是全自動的：Cobbler負責在硬件上部署OS，OS被引導后，Puppet接手剩下的事情。我已經在實踐中運行這套部署方案很多次了，就理所應當地認為沒有任何問題。

在基隆拿的***一天，我在酒店里參加電話會議。實際上，我正在新部署出來的云系統里面隨便玩著。我啟動了一個虛擬機實例，并登錄進去。一切看起來都很正常。閑著無聊，我運行了一下ps aux命令，突然整個虛擬機實例就鎖住了。

我認為這是一個偶發事件，因此我停止了這個實例，并啟動了一個新的。這時，電話會議結束了，我需要去數據中心走一趟。

在數據中心，我完成了一些收尾的工作，這時想起了那個實例鎖住的的事情。于是我登錄到新的實例，并再一次運行ps aux。它工作正常。唷。我決定再運行一次。它又鎖住了。搞什么啊!

在重現了這個問題幾次之后，我得出一個不幸的結論，那就是這套云系統其實真的有問題。更糟的是，我在基隆拿的出差就要結束了，我必須回到卡爾加里去。

我應該從哪里開始排查像這樣的故障呢?一個虛擬機實例因為一個命令就隨機地鎖住了。是鏡像的問題嗎?不——所有鏡像都有這個問題。 是計算節點的問題嗎? 不——所有節點都有這個問題。實例真的鎖住了嗎?不!因為新的SSH連接很正常!

我們去尋求幫助，一個網絡工程師說可能是MTU的問題。太棒了!MTU!終于有進展了!MTU是什么?它為什么會出問題?

MTU是***傳輸單元(maximum transmission unit)的英文縮寫。它規定了網卡接收的每一個數據包字節的***值。如果兩個網卡上的MTU設置不一樣，過來的字節就會被卡住，奇怪的事情就會發生 ——比方說會話隨機被鎖住。

并非所有的數據包都有1500 B這么大。通過SSH運行ls命令可能只會創建一個小于1500 B的數據包。但是，運行的命令如果有很大的輸出，比方說ps aux命令，就需要多個1500 B的數據包。

好的，那么MTU的問題是從哪兒跑出來的?為什么我們在其他的任一部署中沒有遇到過這個問題?這次的情況有啥新變化嗎?好吧，新的數據中心，新的上行鏈路，新的交換機，新的交換機型號，新的服務器，***次使用這個型號的服務器……所以，基本上所有東西都是新的。太棒了。我們在各個地方都要調大了MTU：交換機，計算節點的網卡，實例的虛擬網卡，甚至使數據中心為我們的上行鏈路接口都調大了MTU。一些修改起作用了，一些卻沒用。可是這條排障的方向似乎不對，我們沒必要在這些地方調整MTU。

作為***一根救命稻草，我們的網絡管理員(Alvaro)和我坐在一起，旁邊有四個終端窗口、一根鉛筆和一張紙。在其中一個窗口中，我們運行ping。在第二個窗口中，我們在云控制器上運行tcpdump。在第三個窗口，我們在計算節點上運行tcpdump。然后第四個窗口中，我們在實例上運行tcpdump。介紹一些背景：我們這個云是多節點而不是多主機設置。

一個云控制器作為所有計算節點的網關。VlanManager用來配置網絡。這意味著，云控制器和所有計算節點在每一個OpenStack的項目中都使用一個不同的VLAN。我們使用了ping的-s選項來修改數據包的大小。我們觀察到有時這個包可以完整地返回，有時它發出去了卻沒法回來，而有時它會隨機地停下來。我們修改tcpdump來顯示數據包的十六進制轉儲，并不停地修改ping的組合：外部、控制器、計算節點和虛擬機實例。

最終，Alvaro發現了一個問題。當一個數據包從外面到達云控制器的時候，它不應該配有一個VLAN。我們確認了這點。當數據包從云控制器發往計算節點時，只有當目的地是一個虛擬機實例時，它才會攜帶一個VLAN。這也是對的。當ping應答從實例發出時，它應該在一個VLAN里面。確實如此。當它返回到控制器，然后發送到互聯網上時，它不應該再帶有一個VLAN。不對。噢，看起來好像是這個包的VLAN部分沒有被移除掉。

那是說不通的。

帶著這個想法，我在計算節點上隨機地敲了一些命令：

$ ip a… 
 
10: vlan100@vlan20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br100 state UP 
 
… 

“嘿，Alvaro，你能在一個VLAN上運行一個VLAN嗎?”

“如果你這么做，就會給數據包增加額外4個字節。”

那么這就全說通了：

grep vlan_interface /etc/nova/nova.conf 
 
vlan_interface=vlan20 

在nova.conf中，vlan_interface指定了OpenStack要在哪個網卡上掛VLAN。正確的設置本應該是：vlan_interface=bond0。

這也就是服務器捆綁后的網卡。

vlan20是數據中心分配給我們用于公網訪問的VLAN。它是一個正確的VLAN，也和bond0相連。

結果我錯誤地把OpenStack配置成了將所有的租戶VLAN與vlan20而不是bond0相連，所以這就在一個VLAN上又疊加了另一個VLAN。結果每個包增加了額外的4 B，導致發出的是一個1504 B的包，這當然會出問題，因為我們網卡有1500 B的限制啊!

這個設置一修復，一切都好了。

注：本文是錢永超翻譯的《openstack運維指南》部分節選，請支持作者，購買正版圖書。