雙層VLAN

我在加拿大不列顛哥倫比亞省的基隆拿創(chuàng)建了一套新的OpenStack系統(tǒng)。整個部署過程是全自動的：Cobbler負責(zé)在硬件上部署OS，OS被引導(dǎo)后，Puppet接手剩下的事情。我已經(jīng)在實踐中運行這套部署方案很多次了，就理所應(yīng)當?shù)卣J為沒有任何問題。

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

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

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

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

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

我們?nèi)で髱椭?，一個網(wǎng)絡(luò)工程師說可能是MTU的問題。太棒了!MTU!終于有進展了!MTU是什么?它為什么會出問題?

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

并非所有的數(shù)據(jù)包都有1500 B這么大。通過SSH運行l(wèi)s命令可能只會創(chuàng)建一個小于1500 B的數(shù)據(jù)包。但是，運行的命令如果有很大的輸出，比方說ps aux命令，就需要多個1500 B的數(shù)據(jù)包。

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

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

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

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

那是說不通的。

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

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

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

“如果你這么做，就會給數(shù)據(jù)包增加額外4個字節(jié)。”

那么這就全說通了：

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

在nova.conf中，vlan_interface指定了OpenStack要在哪個網(wǎng)卡上掛VLAN。正確的設(shè)置本應(yīng)該是：vlan_interface=bond0。

這也就是服務(wù)器捆綁后的網(wǎng)卡。

vlan20是數(shù)據(jù)中心分配給我們用于公網(wǎng)訪問的VLAN。它是一個正確的VLAN，也和bond0相連。

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

這個設(shè)置一修復(fù)，一切都好了。

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