接下來我會給大家分享一下我們的應(yīng)用場景，以及在實施部署的時候我們遇到的困難和挑戰(zhàn)，在實踐的過程中走過的一些坑。

所以針對這個問題我們最終選擇了比較折中的方案，首先我們采用VRF來做業(yè)務(wù)類型區(qū)分，directadmin漢化 虛擬主機，其次，SR隧道我們依然保存，但是僅僅是做SR標簽轉(zhuǎn)換，不再重新生成隧道，我們靜態(tài)配置點到點的隧道。通過控制器向VRF注入BGP的路由，還是采用改變下一跳的方式，將數(shù)據(jù)引入到相應(yīng)的SR隧道中，從而實現(xiàn)基于業(yè)務(wù)類型的流量調(diào)度。

在未來我們計劃將路由器的VRF功能和引流的功能遷移到NFV網(wǎng)關(guān)上。在百度，所有的南北向流量都會經(jīng)過自研的NFV網(wǎng)關(guān)，那么我們就可以在NFV網(wǎng)關(guān)設(shè)備上基于流進行SR頭部封裝，實現(xiàn)基于服務(wù)的出口調(diào)度。中間的網(wǎng)絡(luò)設(shè)備只做SR標簽轉(zhuǎn)發(fā)，不再做復(fù)雜的引流工作。

Route feed模塊采集設(shè)備路由變化信息；Flow Analysis分析流量大小，這里不緊緊是分析端口級流量，需要詳細分析每個路由前綴的流量；Limits Computer主要采集物理網(wǎng)絡(luò)的硬件參數(shù)，比如網(wǎng)絡(luò)帶寬空閑量、網(wǎng)絡(luò)跳數(shù)、時延等。分析平臺會把三種數(shù)據(jù)做綜合分析，去除干擾數(shù)據(jù)，將有效數(shù)據(jù)傳輸給決策層。決策層根據(jù)現(xiàn)網(wǎng)的情況，和來自controller的輸入，做出調(diào)度方案，同時將調(diào)度方案發(fā)送給路徑計算模塊。路徑計算模塊根據(jù)決策層傳遞的調(diào)度方案，計算出流量路徑，并通過bgp injector注入到設(shè)備。

我們有這么多的出口，有成本昂貴的transit出口，有成本相對便宜的對等peer。怎么才能讓質(zhì)量敏感類服務(wù)走時延最低、丟包最少的出口，讓成本敏感類服務(wù)，走成本最低的出口？要解決這個問題，我們可能要做一個比較復(fù)雜的系統(tǒng)。我們發(fā)現(xiàn)看起來要解決一個簡單的問題，可能要付出很大的代價，至少在這個系統(tǒng)里需要做三個基礎(chǔ)模塊。一個是AAA，就是權(quán)限管理模塊，需要做一些權(quán)限認證；另外要一個是DB數(shù)據(jù)庫，用于存儲網(wǎng)絡(luò)拓撲、配置數(shù)據(jù)；最后一個是log日志分析組件。

除此之外，還有一個非常致命的缺陷，就是策略變更時效性低。

首先是我們的需求，百度網(wǎng)絡(luò)大概分成三個圈，最里面的一圈是數(shù)據(jù)中心，大量的服務(wù)器部署在這些數(shù)據(jù)中心里。中間綠色點和黃色點的一圈是外網(wǎng)骨干網(wǎng)，這張網(wǎng)將各個數(shù)據(jù)中心的外網(wǎng)出口連接起來，同時和運營商互聯(lián)，這是百度服務(wù)器和互聯(lián)網(wǎng)用戶通信的出口。最外面一圈是訪問百度的互聯(lián)網(wǎng)用戶。

最終我們采用這種方式在海外網(wǎng)絡(luò)做了部署，這種方式顯著的優(yōu)勢就是對網(wǎng)絡(luò)設(shè)備的要求降低了，不需要動態(tài)修改設(shè)備配置，對設(shè)備廠商的南向接口依賴降低。但是它依然還是存在著一個很嚴重的缺陷，就是傳統(tǒng)MPLS-TE面臨的問題，需要建立點到點的隧道，每個設(shè)備的每個VRF都要跟其它所有設(shè)備建立隧道，如果有n個設(shè)備，每個設(shè)備有2個VRF，就需要建立2（n-1）個隧道。大量的隧道維護額外增加了運維人員的工作。

左邊向上的箭頭是采集設(shè)備信息，向上傳給上面的分析模塊，根據(jù)分析結(jié)果我們做一些策略往下推。

這個方法看起來非常完美了，那么實際實施中有什么問題嗎？首先，擺在我們面前的第一個問題是如何動態(tài)操作多廠商設(shè)備？我們遵循了google的open config標準，基于YANG模型對網(wǎng)絡(luò)設(shè)備進行配置。然而，各個設(shè)備廠商對YANG模型支持力度參差不齊，大量時間花費在溝通上，開發(fā)進展緩慢。此外，各廠商對SR-TE引流方式技術(shù)也不完全相同，比如cisco采用SR-POLICY、華為采用QPPB，這導(dǎo)致網(wǎng)絡(luò)配置邏輯上存在一定差異，從而給配置模塊引入較大難度。

今天我重點要給大家講的是網(wǎng)絡(luò)設(shè)備上流量調(diào)度的實施方案，回到最原始的需求，選擇出口的問題。在沒有SR技術(shù)之前，控制器和所有網(wǎng)絡(luò)設(shè)備建立一個IBGP會話，通過這個控制器下發(fā)BGP路由。將期望調(diào)度的目標前綴的下一跳修改成你想調(diào)度到的出口的網(wǎng)絡(luò)設(shè)備，從而將流量調(diào)度到該出口。然而，這個方法并不能解決我們的問題，因為基于前綴的調(diào)度，將質(zhì)量敏感類業(yè)務(wù)和成本敏感類業(yè)務(wù)都調(diào)度到了這個出口，但這個出口可能質(zhì)量很好、成本很高，我們滿足了質(zhì)量敏感類業(yè)務(wù)的需求，卻不能滿足成本敏感類業(yè)務(wù)的需求；相反有些出口成本比較低、質(zhì)量比較差，能滿足成本敏感類業(yè)務(wù)需求，不能滿足質(zhì)量敏感類業(yè)務(wù)的需求。可見傳統(tǒng)的基于BGP路由調(diào)度的方法，不能同時滿足兩類業(yè)務(wù)的需求。

我們2016年就接觸了相關(guān)的SR技術(shù)，憑著一腔工程師對新技術(shù)的熱情開始學(xué)習(xí)，2017年的時候我們靜下心來開始思考，用SR技術(shù)能給我們帶來什么，能幫助我們解決哪些問題。2017年下半年和一些設(shè)備廠商開始聯(lián)合研發(fā)，2018年上半年我們做了測試，并在海外做了小批量的部署。

這是我的分享，謝謝。

數(shù)據(jù)中心的業(yè)務(wù)，我們分為兩類。一類是對質(zhì)量特別敏感的，比如搜索、自動駕駛類服務(wù)；另一類是對成本比較敏感的，比如網(wǎng)盤、視頻類服務(wù)。

以下為百度網(wǎng)絡(luò)架構(gòu)師劉小軍的演講實錄：

這個時候正好出現(xiàn)了SR相關(guān)技術(shù)，2017年的時候我們對SR寄予了特別大的希望來解決這個問題。SR怎么解決呢？對成本類、質(zhì)量類服務(wù)通過dscp標簽的方式分別做一個標記，先進行分類；在出口選擇的時候，我們?yōu)槊恳粋€出口設(shè)定了一個Community值，以此標記出口。當想調(diào)度某個前綴的流量到某個特定的出口時，將該前綴打上該出口的bgp community值即可。這樣我們就可以同時match dscp和community，將流量注入到SR隧道中，通過SR隧道將特定業(yè)務(wù)類型的數(shù)據(jù)傳輸?shù)竭m合該業(yè)務(wù)的出口。