簡介面向數(shù)據(jù)中心規(guī)劃、建設(shè)與運維人員的技術(shù)方案文檔聚焦傳統(tǒng)架構(gòu)擴展性差、維護成本高、資源利用率低等痛點提出以整合能力、虛擬化能力、自動化能力和綠色節(jié)能為核心的建設(shè)框架。內(nèi)容從網(wǎng)絡(luò)架構(gòu)切入介紹一體化交換、無丟棄以太網(wǎng)、性能支撐、網(wǎng)絡(luò)服務(wù)虛擬化與服務(wù)器虛擬化等關(guān)鍵技術(shù)并結(jié)合指揮學(xué)院場景給出目錄式落地參考便于讀者對照理解設(shè)計目標(biāo)如何轉(zhuǎn)化為實際部署。資源內(nèi)含1個doc文檔壓縮包約2.68MB目錄按總述、技術(shù)實現(xiàn)等章節(jié)編排結(jié)構(gòu)清晰從需求梳理到技術(shù)選型均有展開可直接用于數(shù)據(jù)中心方案設(shè)計、課程設(shè)計或項目投標(biāo)的參考模板。目前已有47人學(xué)習(xí)下載適合需要快速搭建方案框架并了解新一代數(shù)據(jù)中心技術(shù)選型的工程與教學(xué)人員。1. 數(shù)據(jù)中心建設(shè)方案為什么先把寶押在 SRv6 Policy 上一份數(shù)據(jù)中心建設(shè)方案寫到網(wǎng)絡(luò)部分最容易變成機房平面圖和設(shè)備清單但真正決定兩年后運維體驗的往往是數(shù)據(jù)中心之間那幾十條跨機房路徑怎么被管住。我在IDC和政企DCI項目里反復(fù)遇到同一個現(xiàn)象Underlay路由學(xué)得通業(yè)務(wù)卻“玄學(xué)”地繞路、丟包、抖動查到最后都是策略粒度不夠流量被默認路由帶到了不想走的鏈路上。這篇筆記圍繞一個核心結(jié)論展開數(shù)據(jù)中心的跨域流量調(diào)度需要顯式路徑能力而用 SRv6 Policy 做數(shù)據(jù)中心間 policy 是目前最值得投入的方案。它把“從A到B的流量走哪條鏈路、故障后切到哪條備選路徑”變成一段可配置、可查詢、可手動干預(yù)的策略而不是交給IGP和ECMP去猜。適合正在做數(shù)據(jù)中心間互聯(lián)規(guī)劃、被多云出口或雙活流量折騰過的網(wǎng)絡(luò)架構(gòu)師和運維工程師閱讀下面按“選型—配置—路由聯(lián)動—避坑—驗證”走一遍。2. 組網(wǎng)規(guī)劃與 policy 選型數(shù)據(jù)中心間流量為什么不能用默認路由打發(fā)2.1 數(shù)據(jù)中心間互聯(lián)的三種訴求哪種才需要引入 SRv6 Policy先說清楚這個方向值不值得做。數(shù)據(jù)中心間流量大概逃不出三種訴求同城雙活要求時延可預(yù)期兩條物理鏈路哪怕差 0.5ms數(shù)據(jù)庫同步都能看出差距兩地三中心關(guān)心主備切換能不能在秒級完成默認路由只能等IGP收斂收斂時間在故障場景下不可控多云出口則是大量前綴要按業(yè)務(wù)打不同的策略路由純靠BGP屬性堆 community 會復(fù)雜到?jīng)]人敢動。SRv6 Policy 解決的是這三類場景里的同一個痛點路徑不可編程。傳統(tǒng)組網(wǎng)里頭端設(shè)備只能看到路由表看不到“這條流量會經(jīng)過哪幾個節(jié)點”一旦某段鏈路擁塞運維沒有任何手段把它撥到另一條路上。SRv6 Policy 把整條路徑編碼成有序 SID 列表頭端設(shè)備顯式地把流量封裝進這條段列表路徑變成了一等公民可以被查、被比較、被手動切換。如果你只維護一個單機房那確實用不上但只要你的建設(shè)方案里有第二個機房、第三條專線或者對外提供跨機房帶寬SRv6 Policy 就不是錦上添花而是把流量調(diào)度從黑匣子變成可操作對象的關(guān)鍵一環(huán)。2.2 從業(yè)務(wù)訴求到 policy 形態(tài)把需求翻譯成配置參數(shù)在敲任何配置之前我會先逼著自己把業(yè)務(wù)訴求翻譯成一張參數(shù)清單。這個習(xí)慣幫我避過很多返工因為 policy 一旦上線改 endpoint 或 color 往往牽動兩個機房的防火墻策略、BFD 配置和監(jiān)控告警不是改一行配置那么簡單。下表是我在做跨數(shù)據(jù)中心互聯(lián)方案時常用的設(shè)計清單建議在實施方案評審階段就逐行確認。設(shè)計項取值示例說明Endpoint對端PE的IPv6地址Policy 要到達的目標(biāo)節(jié)點通常寫回環(huán)地址Color100把同一條 endpoint 的路徑分組不同業(yè)務(wù)用不同 colorCandidate PathPreference 100 / 200候選路徑優(yōu)先級決定哪條 SList 做優(yōu)選路徑SList 數(shù)量初始兩條單候選路徑下掛多個段列表承載主備或負載分擔(dān)SBFD間隔 100ms乘數(shù) 3帶內(nèi)雙向轉(zhuǎn)發(fā)檢測快速感知路徑故障Binding SID獨立分配 10001頭端用來封裝和索引 policy 的本地標(biāo)簽必須全局唯一回切模式手動或自動故障恢復(fù)后是否自動回到原最優(yōu)路徑現(xiàn)網(wǎng)建議先手動把這張表填完基本就知道這個方案要做到多細了。比如同城雙活業(yè)務(wù)Color 按業(yè)務(wù)線劃分每個 Color 下面掛兩條 SList一條走低時延專線一條走備用鏈路SBFD 間隔壓到 100ms故障感知后立刻切到備用 SList兩地三中心則相反候選路徑優(yōu)先級差異拉到 100 以上避免輕微抖動就來回往返。這里特別提醒一點常見做法是讓 Controller 統(tǒng)一計算和下發(fā)病程但很多現(xiàn)網(wǎng)環(huán)境的 Controller 還沒建起來。我一般會選擇先在頭端設(shè)備上手工配置 policy把路徑狀態(tài)跑穩(wěn)定之后再決定要不要接 Controller。手工配置的優(yōu)點是每條路徑的含義都清清楚楚排障時不至于對著 Controller 下發(fā)的幾十條 SList 一臉茫然。3. 數(shù)據(jù)中心間 SRv6 Policy 配置落地單 CP 多 SList 場景如何把兩條初始路徑寫進去3.1 配置骨架policy、endpoint 與候選路徑我在很多機房割接時見過完全具名的配置風(fēng)格這里先用一段貼近商用設(shè)備 CLI 的示例把骨架搭出來。不同廠商的字段名會有些差異但 SRv6 Policy 的模型是一致的照著這份配置能對照到自家設(shè)備上。segment-routing ipv6 traffic-engineer policy DC1_TO_DC2 color 100 endpoint 2001:db8:0:100::1 binding-sid 10001 candidate-path preference 100 segment-list SLIST_A segment-list SLIST_B segment-list SLIST_A index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:200::2 segment-list SLIST_B index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:300::2 sbfd enable sbfd remote-discriminator 10001這段配置表示頭端設(shè)備建立了一條名叫 DC1_TO_DC2 的 SRv6 Policy本端通過 BGP 或 IGP 學(xué)到遠端 2001:db8:0:100::1 的可達性color 100 用來標(biāo)識“這是一組同城雙活路徑”。binding-sid 10001 是本端設(shè)備給這條 policy 的本地索引后續(xù)引流和封裝都靠它。candidate-path preference 100 定義了候選路徑的優(yōu)先級preference 值越大的路徑越優(yōu)先成為活躍路徑現(xiàn)網(wǎng)建議主備路徑之間拉開一定數(shù)值差距避免兩條路徑的優(yōu)先級過于接近導(dǎo)致故障恢復(fù)時反復(fù)橫跳。3.2 單 CP 多 SList 的語義與“初始兩條 SList”的選路策略再看候選路徑下面掛著的兩條 SListSLIST_A 和 SLIST_B。這就是熱詞場景里反復(fù)出現(xiàn)的“單 CP 多 list 場景”——一個候選路徑Candidate Path下掛多個段列表Segment List初始兩條 SList 分別編碼了不同的轉(zhuǎn)發(fā)路徑。SLIST_A 經(jīng)過 2001:db8:0:200::2走的是低時延專線SLIST_B 經(jīng)過 2001:db8:0:300::2走的是帶保護的備用鏈路。兩條 SList 都掛在同一個候選路徑下意味著它們共享同一個 policy、同一個 color通過權(quán)重或主備機制決定流量怎么分配。要是把兩條 SList 拆到兩個 candidate-path 里語義就變了它們會變成兩條互相競爭選優(yōu)的獨立候選路徑preference 高的那個當(dāng)選另一個只在故障時接管。單 CP 多 SList 的好處是當(dāng)主備切換發(fā)生時policy 自身依然是 Active 狀態(tài)頭端設(shè)備不需要重新選候選人只需在內(nèi)部完成 SList 的重新優(yōu)選切換粒度更細狀態(tài)機也更干凈。初始兩條 SList 的意義就在于此一條為主、一條為輔SBFD 快速探測到 SLIST_A 的路徑斷了之后流量被切到 SLIST_B中間不需要等 IGP 重新收斂。3.3 參數(shù)怎么調(diào)SBFD、回切與 SID 校驗配置能跑通只是第一步參數(shù)不調(diào)好割接當(dāng)晚就容易翻車。我先說 SBFD它決定了設(shè)備多快能感知到 SRv6 Policy 的路徑故障。SRv6 Policy 在轉(zhuǎn)發(fā)路徑斷開時底層鏈路可能還通著尤其是光模塊故障或中間節(jié)點 CPU 異常時普通 BFD 探測不到流量會持續(xù)打到黑洞里。SBFD 是帶內(nèi)雙向轉(zhuǎn)發(fā)檢測直接復(fù)用 SRv6 數(shù)據(jù)面做探測開銷更小、發(fā)現(xiàn)故障更快。我通常會先把 SBFD 的探測間隔從默認值壓到 100ms~150ms偵測乘數(shù)保持默認 3這樣能在 300ms~450ms 內(nèi)完成故障發(fā)現(xiàn)和路徑切換。間隔再低會增加頭端和目的節(jié)點的 CPU 壓力在現(xiàn)網(wǎng)沒有特別強的低時延要求時我不建議低于 50ms。然后是回切。故障恢復(fù)后如果配置了自動回切SLIST_A 一恢復(fù)流量會自動回到原主用路徑。這個行為在雙活場景下會導(dǎo)致一次瞬斷因為回切本身是一次轉(zhuǎn)發(fā)切換狀態(tài)需要重新同步。我的習(xí)慣是第一階段全部關(guān)閉自動回切由運維確認 SList 狀態(tài)穩(wěn)定后手動回切等上線三個月、路徑質(zhì)量全部摸透后再把自動回切打開。調(diào)試期間如果覺得流量去向難判斷可以臨時把主用 SList 的 preference 調(diào)高或調(diào)低觀察流量是否跟著切換驗證完再改回來這是最直接的對照實驗。4. 大型數(shù)據(jù)中心用 BGP 承載路由時policy 怎么跟路由表聯(lián)動4.1 BGP 在數(shù)據(jù)中心里的雙重職責(zé)Underlay 通互聯(lián)Overlay 通租戶在大型數(shù)據(jù)中心使用 BGP 進行路由是當(dāng)前的主流形態(tài)但它承擔(dān)的職責(zé)要拆成兩層看。Underlay 層用 iBGP/eBGP 建立設(shè)備間的 IPv6 可達性把每個節(jié)點的 SRv6 回環(huán)地址和 SID 信息傳播到全網(wǎng)SRv6 Policy 的 endpoint 地址正是通過這層 BGP 學(xué)到的。Overlay 層則承載租戶或業(yè)務(wù)的真實路由常見做法是 EVPN-VXLAN 疊加在 IPv6 Underlay 上或者用 BGP IPv6 前綴路由直接傳遞業(yè)務(wù)流量。二者分開的原因是收斂域不同Underlay 的變化要盡快讓全網(wǎng)知道Overlay 的路由量往往大得多混在一張表里會把 Underlay 的收斂速度拖垮。數(shù)據(jù)中心間 policy 在這個體系里的位置像是給 BGP 學(xué)習(xí)到的頂層前綴加了一層“路徑偏好”。BGP 路由表只能告訴設(shè)備“下一跳是誰”SRv6 Policy 則告訴設(shè)備“去這個下一跳要走哪條顯式路徑”。兩者聯(lián)動起來流量才能既選得對路由也走得好路徑。4.2 讓 BGP 發(fā)布 SRv6 相關(guān)路由BGP-LS 與 SID 傳播先把 BGP 側(cè)的關(guān)鍵配置放出來這段配置的意義在于把 SRv6 Policy 需要的路徑信息托底。router bgp 65001 address-family ipv6 network 2001:db8:0:100::1/128 exit-address-family address-family link-state link-state segment-routing ipv6 traffic-engineer advertise dae srv6-policy exit-address-family第一段 address-family ipv6 發(fā)布的是本端設(shè)備的 SRv6 回環(huán)地址保證全網(wǎng) BGP 都能學(xué)到對端 PE 的可達性第二段是 BGP-LS 地址族它負責(zé)把本端 SRv6 Policy 的 TEATraffic Engineering Attributes信息上送給 Controller 或鄰居設(shè)備。這里的邏輯要理解清楚SRv6 Policy 是頭端本地的轉(zhuǎn)發(fā)狀態(tài)BGP-LS 上報它是為了讓 Controller 能收集全網(wǎng) policy 狀態(tài)并據(jù)此計算跨數(shù)據(jù)中心的優(yōu)化路徑。如果只是手工配置 policy 不上報 BGP-LSpolicy 也能工作只是少了全網(wǎng)視角的調(diào)度能力。4.3 引流與過濾哪些流量走 policy哪些流量必須繞過路由和 policy 都通了最后的問題是“流量怎么走進 policy”。常見做法是引流路由把匹配特定下一跳或特定 color 的 BGP 路由顯式綁定到 policy 上。動作一般分兩類一類是按下一跳引流所有去往 endpoint 地址的流量都自動走對應(yīng) policy另一類是按業(yè)務(wù)前綴引流比如只讓 10.1.0.0/16 這條業(yè)務(wù)段的流量走 policy其余流量繼續(xù)查普通路由表。過慮同樣重要語音、視頻會議這類交互性強的流量我會故意繞過 policy讓它們直接走 Underlay 原生路徑避免 SRv6 隧道封裝帶來的額外時延抖動。在大型數(shù)據(jù)中心用 BGP 進行路由聯(lián)動時最容易被忽略的一個點是把 BGP 下一條與 policy endpoint 做一致性校驗。很多排障現(xiàn)場出現(xiàn)“policy 是 Active 的但業(yè)務(wù)流量沒走它”的怪象追下去就是引流條件沒匹配上BGP 路由的下一跳是環(huán)回地址的 IPv4 形式而 policy endpoint 用的是 IPv6 地址兩者對不上流量自然走不進 policy。記住一個口訣先看路由表下一跳再看 policy endpoint最后看引流規(guī)則三者一致流量才會進隧道。5. SRv6 Policy 落地避坑5 個高頻坑的現(xiàn)象、根因與解法5.1 主路徑閃斷后切不回來業(yè)務(wù)長時間懸在備路上現(xiàn)象SBFD 檢測到主路徑故障流量成功切到備用 SList。主路徑幾分鐘后恢復(fù)policy 狀態(tài)也顯示 Active但流量一直不回切業(yè)務(wù)持續(xù)走在次優(yōu)路徑上。原因多半是關(guān)閉了自動回切但沒有配置手動回切路徑或者手動回切時目標(biāo) SList 的 SBFD 狀態(tài)還沒完全恢復(fù)設(shè)備判定它不滿足回切條件。另一種可能是主備路徑的 preference 差值沒有拉開設(shè)備在閾值邊界反復(fù)比較導(dǎo)致回切判斷失敗。解決配置回切前加一條前置校驗確認目標(biāo) SList 連續(xù)三個探測周期無丟包再執(zhí)行把主備 preference 差值保持在 50 以上。割接前在維護窗口里實際演練一次“手動關(guān)主路徑→觀察切換→恢復(fù)主路徑→手動回切”這一步省不掉。5.2 policy 顯示 Active業(yè)務(wù)流量卻完全不進隧道現(xiàn)象policy 狀態(tài)正常SBFD 也在 UP 狀態(tài)但抓包看到業(yè)務(wù)流量還是裸路由轉(zhuǎn)發(fā)完全沒有 SRv6 頭封裝。原因引流規(guī)則沒有真正命中業(yè)務(wù)前綴或者 BGP 路由的下一跳與 policy endpoint 不匹配。這種問題隱蔽在路由表里光看 policy 狀態(tài)根本發(fā)現(xiàn)不了我把它叫作“黑匣子式陷阱”。解決按三條線排查。先查 BGP 路由表里業(yè)務(wù)前綴的下一跳地址確認和 endpoint 一致再查引流策略的匹配順序看是否有更靠前的 deny 規(guī)則把流量放過了最后在頭端設(shè)備上用 packet-tracer 模擬一條業(yè)務(wù)報文看它實際匹配到的是 policy 還是普通路由。5.3 單 CP 多 SList 場景下第二條 SList 永遠只在配置里“存在”現(xiàn)象單候選路徑下配置了兩條 SListSLIST_A 和 SLIST_B 都寫在配置里但設(shè)備一直只用 SLIST_A 轉(zhuǎn)發(fā)SLIST_B 連 SBFD 都不建立。原因單 CP 多 SList 的語義不等于裸的負載分擔(dān)。如果兩條 SList 沒有配置 weights 或 loadshare 參數(shù)設(shè)備默認只選擇 preference 最高的那條 SList 作為活躍路徑另一條只在活躍路徑故障后才啟用平時完全是冷備狀態(tài)。解決想讓兩條 SList 同時承載流量需要為每條 SList 配置轉(zhuǎn)發(fā)權(quán)重比如權(quán)重 1:1 就是均分。想讓一條為主、一條為輔則不配權(quán)重保持現(xiàn)在的冷備邏輯。設(shè)計階段把這個語義定清楚別等到流量分布和預(yù)期不符才開始猜。5.4 新增一條 SList 導(dǎo)致全網(wǎng) policy 抖動現(xiàn)象在某個數(shù)據(jù)中心間 policy 里新增了一條 SList結(jié)果不只是這條 policy相鄰機房的幾條 policy 也相繼報錯控制平面日志里全是 SID 異常告警。原因SRv6 的 Locator 和 SID 在規(guī)劃時沒有嚴格區(qū)分新加的 SList 里用了和其他 policy 重疊的 Binding SID 或節(jié)點 SID頭端設(shè)備索引 policy 時發(fā)生了沖突。解決給每個數(shù)據(jù)中心規(guī)劃獨立的 SRv6 Locator 段Binding SID 使用專門保留的區(qū)間在新增 SList 前用命令查一下目標(biāo) SID 已經(jīng)被哪些 policy 占用。這個坑在多個 controller 同時下發(fā)時最常出現(xiàn)人工配置時反而容易注意到。5.5 Underlay ECMP 與 Policy 疊加時延抖動呈鋸齒狀現(xiàn)象業(yè)務(wù)流量明明走了 policy但時延曲線一抖一抖的沒有規(guī)律像是在兩條鏈路之間隨機跳。網(wǎng)絡(luò)團隊查了兩天最后發(fā)現(xiàn) Underlay 的等價多路徑一直開著。原因Policy 顯式指定了一條 SList但這條 SList 里的某些節(jié)點之間仍存在 ECMP 等價路徑流量在隧道里被 ECMP 二次打散導(dǎo)致同一條業(yè)務(wù)流的兩個報文可能走不同物理路徑時延當(dāng)然只能跳動。解決兩個方向。要么把 policy 的 SList 寫得更深把每一跳都改成顯式 SID徹底掉 ECMP 的陰影要么把該段鏈路的 ECMP 收斂為單路徑。一般我會傾向后者因為顯式逐跳 SID 會吃不少 SID 資源。判斷標(biāo)準(zhǔn)很簡單抖動段的物理路徑是否只有兩條如果是直接收斂 ECMP 見效最快。6. 割接前把結(jié)論一條條驗證進去查路徑、看 BFD、再回切6.1 三張命令表把狀態(tài)釘死進入維護窗口前我習(xí)慣先做一輪靜態(tài)體檢。以下三條命令對應(yīng)三張表policy 總表看路徑狀態(tài)BFD 表看故障探測流量統(tǒng)計表看實際轉(zhuǎn)發(fā)情況。display segment-routing ipv6 traffic-engineer policy name DC1_TO_DC2 display srv6-policy sbfd brief display segment-routing ipv6 traffic-engineer statistics第一條看 policy 是否 Active、當(dāng)前活躍的 SList 是哪條第二條看 SBFD 的探測間隔和狀態(tài)間隔在不在預(yù)設(shè)值第三條看走 policy 的報文計數(shù)是否持續(xù)增長。這三張表要連續(xù)觀察十分鐘確認計數(shù)單調(diào)增長而不是原地抖動。6.2 割接驗證步驟手動故障注入與回切拿到穩(wěn)定基線后再做一次故障注入演練。第一輪手工把主用 SList 的 preference 調(diào)低觀察流量是否在幾個探測周期內(nèi)切到備用 SList統(tǒng)計切換耗時第二輪恢復(fù)主用 SList 的 preference確認回切正常第三輪模擬中間節(jié)點宕機觀察 SBFD 在指定間隔內(nèi)是否完成故障上報。這套流程做完policy 的可靠性才算真正立在數(shù)據(jù)上而不是立在“配置看著沒什么問題”的直覺上?；厍袆幼魅绻鞘謩拥奈乙话銜鸦厍忻顚懺谶\維腳本里而不是現(xiàn)切現(xiàn)場敲敲錯一個字段在割接窗口里沒有任何后悔藥。SRv6 Policy 在數(shù)據(jù)中心間的建設(shè)方案里不是銀彈它解決的是路徑可控問題解決不了帶寬不足和鏈路質(zhì)量問題。我踩過的教訓(xùn)是方案里給 policy 預(yù)留的狀態(tài)監(jiān)控點位越多上線后半夜的電話就越少。希望幫到你。本文還有配套的精品資源點擊獲取