????????說在前面刻恭，博客上有很多人已經(jīng)寫了關于B4的文章，所以我也在懷疑要不要再次重復寫一遍缓升。昨天聽了華為的HDC.Cloud開發(fā)者大會學校分會場，回答了問題獎勵了一本《鯤鵬處理器架構與編程》蕴轨，會上華為的技術專家在講華為自研的輕量級容器引擎iSula時就說：“Docker已經(jīng)流行很多年了，并且功能也非常強大了骇吭，但是華為為什么還要自研橙弱，是否是重復造輪子呢？” 我本來想這應該也是華為布局的一部分吧，避免遭到更多的制裁而無法繼續(xù)相應業(yè)務棘脐，但是華為技術專家的回答是“需求驅動”斜筐，因為iSula不僅能夠啟動更快，更節(jié)省內(nèi)存空間蛀缝，還能適應IOT顷链、邊緣計算等多場景。我也想說的是屈梁，我的方向不是計算機網(wǎng)絡的嗤练，這個很多也借鑒了網(wǎng)上的內(nèi)容，畢竟論文內(nèi)容講的就是那些在讶，就像iSula也完全兼容Dockefile的語法煞抬，我寫也是為了讓自己了解的更多一些，才疏學淺构哺，共同學習革答，爭取每周分享一到兩篇內(nèi)容，歡迎批評指正曙强，謝謝残拐。
論文名：B4: Experience with a Globally-Deployed Software Defifined WAN
一、B4網(wǎng)絡介紹
Google的數(shù)據(jù)中心之間傳輸?shù)臄?shù)據(jù)可以分為三大類：
? ? ? ? ? ? 1碟嘴、用戶數(shù)據(jù)遠程數(shù)據(jù)中心備份溪食，如郵件、文檔臀防、音視頻文件等眠菇；
? ? ? ? ? ? 2、跨數(shù)據(jù)中心的分布式存儲訪問袱衷，例如計算資源和存儲資源分布在不同的數(shù)據(jù)中心捎废；
? ? ? ? ? ? 3、大規(guī)模的跨數(shù)據(jù)中心的數(shù)據(jù)同步致燥。
????????這三大類從前往后數(shù)據(jù)量依次變大登疗，對延時的敏感度依次降低，優(yōu)先級依次變低嫌蚤。這些都是B4網(wǎng)絡改造中涉及到的流量工程（TE辐益，Traffic Engineering）部分所要考慮的因素。最為關鍵的是B4之前的WAN的鏈路帶寬利用率只有30%-40%脱吱，而為了保證高可靠性智政，對每個字節(jié)數(shù)據(jù)都是平等對待，沒有面對流量激增較好的負載均衡措施箱蝠，依靠的是付出昂貴的代價來增加2-3倍帶寬和高端的路由設備续捂。同時數(shù)據(jù)鏈路上的轉發(fā)失敗信息全部被屏蔽垦垂，使得應用程序無法得到消息，也沒有相關中央設備對路由線路重新規(guī)劃，而只是依靠競爭策略來不斷搶占數(shù)據(jù)通路。
????????因此Google就提出了基于SDN和OpenFlow的B4網(wǎng)絡为居，來相應地解決彈性帶寬需求、到達適中的站點數(shù)量页慷、有能力處理終端應用和網(wǎng)絡問題，并且不至于太高的成本胁附。還有就是可以讓新的協(xié)議在網(wǎng)絡設備中快速迭代酒繁、簡化測試環(huán)境、有中央TE服務器來規(guī)劃容量和路由策略汉嗽、網(wǎng)絡中心簡化管理欲逃。
下面來介紹B4的架構，如圖1. B4架構[1]饼暑。
????谷歌對于B4網(wǎng)絡系統(tǒng)的設計可分類三個層次：全局控制層(global)稳析，局部網(wǎng)絡控制層（site controllers）和物理設備層（switch hardware）。
1. 全局控制層（global）
????????全局的TE Server通過SDN Gateway從各個數(shù)據(jù)中心（Site A弓叛、Site B彰居、Site C）的控制器收集并掌握個站點的鏈路信息。TE Server獲取各站點鏈路信息后撰筷，根據(jù)SDN Gateway上報的拓撲和鏈路情況以及bandwidth情況陈惰，計算出最優(yōu)路徑（即每個流映射到對應的tunnel）和需要分配對應的帶寬，把這些信息通過SDN Gateway下發(fā)到站點的Controller毕籽，再由OFC（OpenFlow Controller）下發(fā)到OpenFlow交換機（OFA Switch）的TE轉發(fā)表（ACL）中進行轉發(fā)抬闯，這些ACL轉發(fā)表項優(yōu)先級高于LPM路由表。如下圖2.关筒，選擇器（selector）就選擇了ACL Table中的Multiple table index =0溶握，entries=2這個表項。
2. 局部網(wǎng)絡控制層（site controllers）
????????每個數(shù)據(jù)中心（stie）有一組controller用來控制該數(shù)據(jù)中心WAN網(wǎng)的交換機蒸播，一個controller可以控制多臺交換機睡榆，而一個交換機也可以連接到多個controller，因此需要Paxos算法來進行master選舉袍榆，作為處于工作狀態(tài)的主用controller胀屿。在Controller中，RAP（Routing Application Proxy）作為SDN應用與Quagga（三層路由協(xié)議棧包雀，支持多路由協(xié)議）通信宿崭。Controller收到交換機送上來的路由協(xié)議報文和鏈路狀態(tài)變化通知時，把自己管理的信息通過RAP傳遞給Quagga協(xié)議棧才写，Quagga計算出路由方案后在controller中保留一份劳曹，放在RIB中奴愉，同時下發(fā)到交換機中，如下圖3.?集成路由和OpenFlow控制[1]铁孵。
????????站點controller中的TE Agent作用是與全局Gateway通信，每個OpenFlow交換機的鏈路狀態(tài)信息都會通過TE Agent發(fā)送到全局Gateway中房资，全局Gateway匯總后蜕劝，發(fā)送給TE Server進行路徑和帶寬信息計算。
3. 物理設備層（switch hardware）
????????B4網(wǎng)絡中轰异，數(shù)據(jù)中心內(nèi)部的路由器運行eBGP路由協(xié)議岖沛，與他數(shù)據(jù)中心WAN里面的設備之間運行iBGP路由協(xié)議。
????????B4網(wǎng)絡中的物理交換機運行OpenFlow協(xié)議搭独。OpenFlow協(xié)議用來描述OFC和OpenFlow交換機之間交互信息的接口標準婴削。參考圖3. 集成路由和OpenFlow控制。圖4. 交換機實體及其物理拓撲[1]牙肝，谷歌強大的一點可能就是它研究東西只要能做到最好那怕自己重新設計一個交換機唉俗，下圖應該是谷歌設計的采用經(jīng)典CLOS架構的Saturn交換機。
二配椭、B4網(wǎng)絡的效果
????????谷歌針對TE算法中最大可用路徑數(shù)和分流量化大小進行了實驗虫溜。如下圖5. TE全局吞吐量的提升比例[1]，(a)中設置的分流量化大小是1/64時股缸，最大路徑在增長到4條之后TE全局吞吐量便無明顯增長衡楞，谷歌實際的網(wǎng)絡中就采用4條路徑作為TE算法參數(shù)。在(b)中最大路徑數(shù)設置為4時敦姻，分流的量化越大效果越好瘾境。添加更多路徑和使用更細粒度的流量分割都為TE提供了更多的靈活性，但它會消耗額外的硬件資源镰惦，實際應用是1/4的分流量化大小迷守。
????????在使用集中式TE后，B4的網(wǎng)絡鏈路利用率（如圖6.(a)所示）在一天的變化都是接近100%的陨献，比傳統(tǒng)的WAN的30%-40%有了大幅度的提高盒犹。
????????圖6.(b)中紅線表示高優(yōu)先級與低優(yōu)先級的數(shù)據(jù)包的比例，藍色部分帶“*”線段表示高優(yōu)先級的丟包率眨业，綠色“+”表示低優(yōu)先級的丟包率急膀。可以看出高優(yōu)先級的丟包率在全天24小時內(nèi)幾乎都為0龄捡，這樣就可以滿足對延遲較高的應用的要求卓嫂。
????????如圖7. 鏈路的利用率[1]，可以看出B4的整體負載平衡方案還是非常不錯的聘殖。對于至少75%的站點到站點的邊緣鏈路晨雳，各鏈路利用率的最大值:最小值為1.05(即最佳值為5%)行瑞，最大值:最小值為2.0。但問題就在這餐禁，B4網(wǎng)絡在沒有故障的時候血久，邊緣網(wǎng)絡中鏈路的最大利用率與最小利用率比例為1.05，但在發(fā)生故障的時候上升為2.0帮非，說明負載均衡方案可以進一步提升氧吐，論文也提到這個也是正在進行研究的主題。
三末盔、B4網(wǎng)絡的改進和展望
????????本篇文章發(fā)表較早筑舅，所以在后續(xù)谷歌2018年發(fā)表的“B4 and after: ...”一文中有了更多的改進，但是了解B4網(wǎng)絡還是先從它的發(fā)展起源開始了解更好陨舱。不過B4網(wǎng)絡的改進和展望會提到2018年發(fā)表的文章談及的一些需要改進的點翠拣。
從控制平面到數(shù)據(jù)平面的協(xié)議數(shù)據(jù)包橋接的瓶頸和硬件編程的開銷；
B4網(wǎng)絡的架構不能推廣到所有SDNs或者所有WANs游盲；
在發(fā)生故障時采取更加有效的負載均衡策略误墓。在B4網(wǎng)絡沒有故障時，邊緣網(wǎng)絡鏈路的最大利用率與最小利用率比例為1.05背桐，而當發(fā)生故障時优烧，比例上升為2。說明負載均衡策略還有優(yōu)化空間链峭。
References：
[1]Jain S , ?Kumar A , ?Mandal S , et al. B4: Experience with a Globally-Deployed Software Defined WAN[C]// Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM. ACM, 2013:3-14.
