虛擬化技術在數據中心是個時髦詞兒，有橫向虛擬化、縱向虛擬化、一虛多虛擬化、NVO3虛擬化等等。今天重點跟大家聊聊橫向虛擬化，以華為CloudEngine 12800系列為例，讓朋友們了解一下此技術的由來和發展史，深入淺出地介紹下各種橫向虛擬化技術的特點、以及各種場景下的選擇策略。
橫向虛擬化集群由來
在數據中心網絡發展初期，沒有專門的數據中心交換機，那咋辦?先拿園區交換機頂著，使用最傳統的VRRP+STP，湊合著用吧，就是下面這張經典的園區網絡。
這個網絡模型，透著濃濃的經典、可靠的園區味道。可時間久了，問題就來了：
◆流量越來越大，STP阻斷導致鏈路利用率低;
◆非最短路徑轉發，樹根存在帶寬瓶頸，轉發時延大;
◆VRRP單活網關，備節點設備閒置;
◆STP網絡規模受限，收斂性能較差;
◆管理節點多，邏輯拓撲複雜，維護麻煩。
這些問題帶來橫向虛擬化的訴求，框式交換機集群率先登場。
堆疊
典型的框式交換機堆疊，有CISCO的VSS(Virtual Switch System)、華為的CSS(Cluster Switch System)、H3C的IRF(Intelligent Resilient Framework)。VSS、CSS、IRF在本質上都是堆疊，只是穿了不同的馬甲而已，當然各廠家也發展出一些差異，這是後話。
堆疊技術，本質上就是合併，管理平面、控制平面、轉發平面的全面合併。堆疊系統的主控板，管理兩臺物理設備的所有線卡和網板，變成一個邏輯的大交換機。
但需要注意，堆疊目的不僅僅是為了變大，從網絡角度看一下邏輯拓撲，一下變得「高富帥」!
「高富帥」的主要表現：
◆幾乎兩倍交換能力的超級節點;
◆二三層轉發流量完全負載分擔，充分利用所有鏈路;
◆邏輯單節點，業務支持全面，網絡方案設計簡單;
◆通過部署跨框link-agg，支持物理節點的故障保護;
◆網元二合一，有利於網絡管理和維護。
還有零零碎碎的好處也不少：
◆最短路徑轉發，時延低;
◆相對傳統STP，可以組建更大的二層網絡;
◆link-agg的收斂性能，網絡故障收斂塊。
在堆疊系統中，堆疊鏈路的帶寬相對於業務埠，帶寬總是不夠的。這就要求轉發的業務流量儘量避免經過堆疊鏈路，這就是所謂的流量本地優先轉發。
如上圖所示，華為數據中心交換機堆疊系統，對三層ECMP、鏈路捆綁支持本地優先。本地優先轉發節省了堆疊鏈路帶寬，同時也達到減少轉發時延的目的。
除了上述通用的堆疊技術，華為CloudEngine 12800系列數據中心高端交換機，還針對堆疊的可靠性，做了重大的體質性的優化。
堆疊的優化
可靠性優化(轉控分離的堆疊)
轉控分離的堆疊，也稱為帶外堆疊，這個優化主要目的是高可靠性。
業界大部分框式交換機的堆疊，堆疊成員間的控制通道和轉發通道都使用一個通道。華為的CloudEngine 12800系列數據中心交換機***性的開發了轉控分離的堆疊系統。這裡的「轉」指的是業務數據轉發通道;「控」指的是控制消息(也稱為「信令」)通道。
傳統的框式堆疊系統，業務數據通道和控制消息通道都使用相同的物理通道，即堆疊鏈路。如下圖所示：
這種堆疊系統，控制消息和數據混合在一起運行，如果堆疊通道的數據通信量大，則可能導致控制消息受到衝擊而丟失，進而影響控制面的可靠性。嚴格來說，這種設計沒有滿足「數據、控制、管理平面分離」的設計要求。此外，堆疊系統的建立，依賴線卡的啟動，導致軟體複雜度的提高，以及影響堆疊的啟動速度。
轉控分離的堆疊系統，採用如下所示架構：
該硬體堆疊架構帶來一系列可靠性的提升：
◆控制消息通道和業務數據通道物理隔離，保證業務數據不影響控制消息;
◆三重的雙主故障防護，包括堆疊管理鏈路(4路)、堆疊轉發鏈路(至少2路)、業務埠/管理埠DAD;
◆堆疊系統建立，不再依賴線卡的啟動，無軟體時序依賴，簡化軟體實現，而簡單意味著可靠;
◆堆疊系統建立，不再等待線卡/網板的啟動，縮短堆疊系統建立時間;
◆控制消息通道路徑短，故障點少，時延低。
堆疊改良的局限性
堆疊系統帶來了前述系列的好處，但慢慢的，令人不爽的問題也逐漸暴露出來，這是由堆疊原理本質決定的。
如上圖所示，兩臺交換機通過管理平面、控制平面、數據平面的緊耦合，形成邏輯上的一臺交換機。這導致了如下三個風險或者問題。
◆整系統級可靠性風險
對於普通的故障，堆疊系統可通過鏈路切換、主備板切換、 框切換等完成故障保護。但是由於整個系統的兩臺物理switch在軟體(管理平面、控制平面)是緊耦合的，這就增大軟體故障從一臺switch擴散到另一臺Switch的可能性。一旦出現這種類型的故障，將導致整個堆疊系統的故障，影響堆疊系統接入的所有業務。
◆版本升級的業務中斷時間長
由於堆疊本身承擔了業務保護功能，因此當堆疊系統升級時，不能像VRRP的成員節點升級時由另外一個節點進行流量保護，中斷時間比較長。
對此，各廠商開發出了兩框RoundRobin和ISSU的升級方式，這些升級方式縮短了升級時的業務中斷時間，但並不解決下面所說的升級風險，甚至因為技術複雜度、軟體工程複雜度的提升，放大了升級風險。
◆整系統升級風險
設備軟體版本升級，即使採用最傳統、簡單的升級方式，也是一個帶風險的網絡操作。設備升級失敗將導致該設備所帶業務失效，這種情況下，要採用包括回退在內的一切手段儘快恢復業務。
堆疊系統由於成員交換機間的緊耦合，只能是兩臺設備一起升級，升級失敗將導致堆疊系統下所有業務網絡中斷。而堆疊系統，在接入層往往承擔伺服器雙歸保護接入的角色、或者在匯聚承擔高可靠性網關的角色，這意味著升級失敗很可能導致整個業務的癱瘓。
Link-agg虛擬化(M-LAG)
橫向虛擬化，從需求角度是為了滿足接入層、匯聚層的二層跨設備冗餘、匯聚層L3網關的跨設備冗餘。那是否還有其他技術，支持橫向虛擬化，又沒有堆疊的哪些問題?
答案當然是有，華為CloudEngine系列數據中心交換機的M-LAG(Multichassis Link Aggregation Group)就支持這樣的虛擬化技術。該技術只在兩臺設備的link-agg層面實現二層虛擬化，兩臺成員設備的管理和控制平面是獨立的。
註：維基百科稱此技術為MC-LAG(Multi-Chassis Link Aggregation Group)，CISCO稱之為vPC(Virtual Port-Channel)。下文都採用維基百科的術語，即簡寫為MC-LAG。
MC-LAG，支持的跨設備鏈路捆綁組網，支持Dual-Active的L3GW。在接入側，從對端設備視角、伺服器視角看，MC-LAG與堆疊類似。
但是，從三層網絡角度看，MC-LAG的兩個成員節點擁有自己獨立的IP位址，兩個節點有自己獨立的管理和控制平面。從架構角度看，MC-LAG的兩個成員設備僅存在數據面的耦合，以及協議面的輕量級耦合：
MC-LAG的架構，決定了此技術方案不存在堆疊難解決的三個問題：
那麼，說了MC-LAG的這麼多好處，是不是就沒有缺點了?當然不是，寸有所長，尺有所短。***一節比較堆疊與MC-LAG的優缺點，以及場景選擇建議。
堆疊和MC-LAG的對比和選擇建議
根據上面的對比表格，堆疊和MC-LAG各有優缺點。總的來說，對於網絡設計/維護人員，堆疊勝在管理維護簡單，MC-LAG勝在可靠性和低升級風險。
在數據中心網絡方案設計時，需要權衡考慮，有如下策略可以選擇：
◆策略一：匯聚層優先考慮可靠性、升級方便性，選擇M-LAG;接入層因為設備量大，優先考慮業務部署和維護方便性，選擇堆疊。
◆策略二：優先考慮可靠性、升級低風險，匯聚和接入都使用M-LAG。
◆策略三：優先考慮業務部署和維護方便性，匯聚和接入都使用堆疊。
【責任編輯：
藍雨淚TEL：（010）68476606】