① 背景介紹

　　Google的網(wǎng)絡(luò )有兩種，一種是數據中心內部網(wǎng)絡(luò )，另外一種是WAN網(wǎng)，其中WAN網(wǎng)又分為兩種：一是數據中心之間的互聯(lián)網(wǎng)絡(luò )，屬于內部網(wǎng)絡(luò )（G-Scale Network），另外一種是面向Internet用戶(hù)訪(fǎng)問(wèn)的網(wǎng)絡(luò )（Internet-facing WAN 即 I-Scale Network），Google選擇使用基于SDN來(lái)改造數據中心之間互聯(lián)的G-Scale網(wǎng)絡(luò )，因為這個(gè)網(wǎng)絡(luò )相對簡(jiǎn)單，設備類(lèi)型以及功能都比較單一，而且該網(wǎng)絡(luò )的鏈路成本太高（都是長(cháng)距離傳輸光纜，甚至包括海底光纜），改造價(jià)值大。

Google的數據中心之間傳輸的數據可以分為三大類(lèi)：

1. 用戶(hù)數據備份 到遠程數據中心，以保證數據可用性和持久性。這個(gè)數據量最小，對延遲最敏感，優(yōu)先級最高。
2. 擴數據中心存儲訪(fǎng)問(wèn) 比如據算資源和存儲資源分布在不同的數據中心，進(jìn)行 MapReduce 之類(lèi)的分布式計算。
3. 大規模數據同步 以同步多個(gè)數據中心之間的狀態(tài)。這個(gè)流量最大，對延遲不敏感，優(yōu)先級最低。

　　促使Google使用SDN改造WAN網(wǎng)絡(luò )的最大原因是當前連接WAN網(wǎng)絡(luò )的鏈路帶寬利用率很低，因為現在用的是基于靜態(tài)Hash的負載均衡方式，這種方式并不是絕對均衡，會(huì )出現有的路徑負載高，有的路徑負載低的情況，為了避免很大的流量都被分發(fā)到同一個(gè)鏈路上導致對包，Google不得不使用過(guò)量鏈路，提供比實(shí)際需要多得多的帶寬，導致實(shí)際鏈路帶寬利用率只有30%左右，且仍不可避免有些鏈路會(huì )發(fā)生擁塞，而且設備必須支持很大的包緩存，成本太高。除此之外，增加網(wǎng)絡(luò )可見(jiàn)性、穩定性，簡(jiǎn)化管理，都是動(dòng)機之一。以上原因也決定了Google這個(gè)基于SDN的網(wǎng)絡(luò )，最主要的應用時(shí)流量工程（TE，Traffic Engineering）。

Google對B4網(wǎng)絡(luò )的改造方法，充分考慮了他們網(wǎng)絡(luò )的一些特性以及想用達到的主要目標，一切都是圍繞這幾個(gè)事實(shí)或者期望：

1. B4網(wǎng)絡(luò )絕大多數流量都是來(lái)自于數據中心之間的數據同步應用，這些應用希望給它們的帶寬越大越好，但是可以容忍偶爾的擁塞丟包、鏈路不通以及高延時(shí)。
2. Google數據中心的數量是有限的，這個(gè)特點(diǎn)意味著(zhù)Controller的可擴展性的壓力相對小很多。
3. Google能夠控制應用數據以及每個(gè)數據中心的邊界網(wǎng)絡(luò )，希望通過(guò)控制應用數據的優(yōu)先級和網(wǎng)絡(luò )邊緣的突發(fā)流量（Burst）來(lái)優(yōu)化路徑，緩解帶寬壓力，而不是靠無(wú)限制地增大出口帶寬。

② 具體實(shí)現

　　控制該網(wǎng)絡(luò )的系統分為三個(gè)層次：物理設備層（Switch Hardware）、局部網(wǎng)絡(luò )控制層（Site Controller）和全局控制層（global）。一個(gè)Site就是一各數據中心。第一層的硬件交換機和第二層的Controller在每個(gè)數據中心的內部出口的地方都有部署，而第三層的SDN網(wǎng)關(guān)和TE服務(wù)器則是在一個(gè)全局統一的控制地。

　　● 第一層的硬件交換機是Google自己設計的。交換機里面運行了OpenFlow協(xié)議，但是它并非僅僅使用了一般的OpenFlow交換機最常使用的ACL表，而是用了TTP（Table Typing Patterns）方式，包括ACL表、路由表、Tunnel表等。但是向上提供的是OpenFlow接口。這些交換機會(huì )把BGP/IS-IS協(xié)議報文發(fā)送到Controller供Controller處理。

　　● 第二層最為復雜，該層在每個(gè)數據中心出口并不是只有一臺服務(wù)器，而是有一個(gè)服務(wù)器集群，每個(gè)服務(wù)器上都運行一個(gè)Controller，Google用的Controller是基于分布式的Onix Controller來(lái)改造的。一臺交換機可以連接到多個(gè)Controller，但是只有其中一個(gè)處于工作狀態(tài)（Master），一個(gè)控制器控制多臺交換機，一個(gè)名叫Paxos的程序用來(lái)進(jìn)行leader選舉（即選舉Master）。

　　在Controller之上運行著(zhù)兩個(gè)應用：RAP，TE Agent。

　　RAP即Routing Application Proxy的意思，負責OFA和OFC之間的互聯(lián)，作為SDN應用跟Quagga通信。Quagga是一個(gè)開(kāi)源的三層路由協(xié)議棧，支持很多路由協(xié)議，Google使用了BGP和IS-IS。數據中心內部的路由器間運行eBGP，跟其它數據中心WAN中的設備間運行iBGP。Onix Controller收到下面交換機送上來(lái)的路由協(xié)議報文以及鏈路狀態(tài)變化通知的時(shí)候，自己并不處理，而是通過(guò)RAP把它送給Quagga協(xié)議棧。Controller會(huì )把它所管理的所有交換機的端口信息都通過(guò)RAP告訴Quagga，Quagga協(xié)議棧慣例了所有這些端口。Quagga協(xié)議計算出來(lái)的路由會(huì )在Controller里面保留一份（放在一個(gè)叫NIB的數據庫里面，即Network Information Base，類(lèi)似于傳統路由中的RIB），同時(shí)會(huì )下發(fā)給交換機，路由的下一跳可以是ECMP，即有多個(gè)等價(jià)下一跳，通過(guò)Hash選擇一個(gè)出口。這是最標準的路由傳統路由轉發(fā)。

　　Quagga 路由協(xié)議棧中的 RIB 保存著(zhù)路由規則，如發(fā)往某個(gè)子網(wǎng)的包要從某兩個(gè)端口選一個(gè)出去。數據中心網(wǎng)絡(luò )中一個(gè) packet 一般會(huì )有多條路線(xiàn)可走，一方面提高冗余度，一方面充分利用帶寬，常用的協(xié)議是 Equal Cost Multiple Path (ECMP)，即如果有多條最短路，就從其中隨機選一條走。在OFC中，RIB被分解為 Flows和 Groups。要理解這個(gè)拆分的必要性，先要理解網(wǎng)絡(luò )交換設備是怎樣工作的?，F代網(wǎng)絡(luò )交換設備的核心是 match-action table。Match 部分就是 Content Addressable Memory (CAM)，所有條目可以并行地匹配，匹配結果經(jīng)過(guò) Mux 選出優(yōu)先級最高的一條；Action 則是對數據包進(jìn)行的動(dòng)作，比如修改包頭、減少 TTL、送到哪個(gè)端口、丟棄數據包。在 OFC 中，Flows 對應著(zhù) Match 部分，匹配得出 Action 規則編號；Groups 對應著(zhù) Action 部分，采用交換機中現有的 ECMP Hash 支持，隨機選擇一個(gè)出口。

　　TE Agent，負責跟全局的Gateway通信，每個(gè)OpenFlow交換機的鏈路狀態(tài)（包括帶寬信息）會(huì )通過(guò)TE Agent發(fā)送給全局的Gateway，Gateway匯總后送給TE Server進(jìn)行路徑計算。

　　● 第三層中，全局的TE服務(wù)器通過(guò)SDN Gateway從各個(gè)數據中心的控制器收集鏈路信息，從而掌握路徑信息，這些路徑被以IP-In-IP Tunnel的方式創(chuàng )建而不是TE最經(jīng)常使用的MPLS Tunnel，通過(guò)Gateway到Onix Controller，最終下發(fā)到交換機中。當一個(gè)新業(yè)務(wù)數據要開(kāi)始傳輸的時(shí)候，應用程序會(huì )評估該應用所需要耗用的帶寬，為它選擇一條最優(yōu)路徑（比如負載最輕的但非最短路徑即不丟包但時(shí)延大），然后把這個(gè)應用對應的流通過(guò)Controller下發(fā)到交換機，從而整體上使鏈路帶寬利用率到達最優(yōu)。