不一樣的軟件定義廣域網——實測 Citrix SD-WAN

    雖然以前是Citrix ERM的軟件SE，×××的現實情況和對職業的焦慮卻促使我盡可能的去了解更多的產品，比如XenMobile、比如XenServer、比如Octoblu、比如NetScaler、比如SD-WAN。

    很有意思的一點是，直到我離開Citrix，我才第一次自己接觸到SD-WAN并做了一次PoC。相對NetScaler而言，我覺得SD-WAN是比較好上手的（我已經忘了OSPF和BGP，也不太記得Spanning Tree，不過我想真需要的時候，看一天就能搞定吧），并且也確實解決用戶的剛需，所以，這個產品真的值得去推廣。

    當然，作為我的風格，沒測試過的東西，我不會告訴你有多好。做短期的銷售可能不喜歡，做長期的銷售可能更認可。對我來說，一個項目下來，客戶和你成了哥們，你花的任何付出都是值得的。嗯，就是這么傻~

    好了，書歸正傳，最近測了一下SD-WAN。就和之前跟用戶介紹PVS一樣，終于拿到了第一手的數據來驗證。在這篇隨筆里，就對測試里我最關心的幾點做一些淺薄的介紹。

    這次測試，部署了一對SD-WAN設備，使用SD-WAN控制臺和SDWAN管理中心進行配置和監控。兩個站點各自使用了一根專線和兩根互聯網線路。限于篇幅，我就把我覺得比較有特點的測試貼出來吧。

   數據復傳，可靠穩定。可以在多條線路上同時傳輸重要的數據，先到先取。

   通過這種方式，能夠把帶寬足夠，但是可靠性和穩定性不足的幾條線路，變成可靠和穩定的虛擬線路。

    優選傳輸，帶寬復合。SDWAN自帶線路質量檢測，按照QoS使用最好的線路傳輸最高優先級的數據。同時幾條線路的帶寬可以無縫疊加，不需要人為把流量通過路由或者其他方式分在不同線路上。這意味著流量可以按照質量自動在線路間進行調控，并且充分使用所有可用帶寬，杜絕了備份線路的浪費，以及人工切換帶來的影響。

    我們用了iperf來模擬流量壓力。單個進程貌似只會使用大約50M的流量，所以同時啟用了多個，直到消耗的流量遠遠超過單條線路的容量，接近所有線路容量之和。

    實際測試中也發現，互聯網線路質量有時會超過專線質量，表現出的現象是更多的流量選擇了互聯網線路進行傳輸。

    會話持續，業務不斷。以往售前的時候，會和用戶介紹Citrix SDWAN與別家不同的地方。不管是策略路由切換還是其他的方案，在線路故障進行切換的時候，現有的網絡連接肯定會斷開的。而Citrix的SDWAN由于對數據包做了重新封裝，使用面向無連接的UDP來傳輸，由設備來負責數據包的完整性，因此不需要重新建立TCP連接。

    測試時，我們逐條斷開線路，同時持續測試數據連接。直到剩下最后一條線路，數據連接一直保持未受影響。

    流量壓縮優化這部分我就懶得寫了，不止一家可以做。我想指出的就是對于中小規模部署，可以把這兩部分通過一臺設備搞定。畢竟分支機構可沒太多地方堆疊一堆設備，“省一U，是一U”。

    為了測試穩定可靠性，干脆把專線禁用了，只用互聯網線路跑業務。結果看來也沒啥問題…為了說明性能，我特意截了幾張圖：

    圖中最上面的黑色線條，就是下面幾種不同顏色線條代表的線路帶寬的集合。也是最終虛擬鏈路使用的帶寬。

   SDWAN的使用能夠優化線路的時延。由于在多條線路中選擇最佳的線路傳輸，所以最終數據連接的時延變成了最小值；由于減少了TCP傳輸的重傳和傳輸窗口調整，實際的時延低于各線路的最小值。

    使用的互聯網線路出現過較大的丟包，雖然持續時間不長，但也足夠影響網絡質量了。正是這種情況，導致大多數用戶選擇了相對穩定的專線，即使專線是那么的昂貴。通過SDWAN重新對數據包進行封裝之后，僅僅丟掉的數據包而不是一次傳輸的所有數據包進行重傳，所以也大幅減輕了線路丟包帶來的惡劣影響。

   對于線路抖動，往往會影響傳輸質量，看上去雖然不如時延、丟包那么厲害，但是帶來的窗口調整等同樣非常影響帶寬的有效使用。SDWAN的作用，減輕了抖動的影響，虛擬鏈路的抖動線條也就這樣隱藏在多條線路的抖動線條之下了。

    把原來專線的重任，交給兩條不靠譜的互聯網線路，也真是難為它倆了。所以即使以SDWAN自己的線路質量評估，互聯網線路在忙時也出現了很多Bad的評價。但是最終，兩條線路聚合的虛擬鏈接，卻在Good的水平上，連續成了一條黑線。

    SDWAN對線路的節省，對質量的提升，也就這么簡單直觀的表現出來了。

    數據中心到分支機構、數據中心到云、這云到其他云、國內云到國際云，都可以用它。

    長大了，鄉愁就像一對SD-WAN，我在這頭，你們在那頭，跨越萬水千山，卻永遠連綿不斷。