沒想到吧，因為數據中心“胡亂選址”，誕生了一門獨立的網絡功課。

這就是DCI，Data Center Interconnect，數據中心互聯，你可以認為這是大廠自建的城域/廣域網，谷歌的B4網絡是這領域的祖師爺。

先為數據中心胡亂選址背鍋，實在背不動了才會進行數據中心園區規劃、再進行DCI網絡優化。

這種規律在老生代、中生代、新生代的大廠里循環，無一幸免。

01 /猥瑣發育，別浪

最開始，每個廠都還很小，誰也不知道能不能活到明天，更沒有專業的網工，本著少花錢的原則開始↓

①從租一個機位開始
②分散在不同機柜的多個機位
③需要租1整個機柜了
④分散在多列的機柜
⑤重復以上的循環，依次到1整列機柜、1整個模塊包間、1整層、1整樓、1整個園區
⑥通常不到1整層的時候，園區就沒空地兒了，業務再增長得去別的園區租機柜了，而且交付周期非常短，不然關鍵業務促銷沒支持好，全公司都得歇菜
⑦這時候通常會有背景不一的網工不到10人，就會采取最簡單粗暴的方式（專線、裸纖都有可能，取決于交付時效）把2個園區連起來
⑧再接下來是3個園區、4個園區…

最終就會可能變成下面這個樣子，所謂的規律就沒什么規律，也可能只是符合這個城市數據中心產業的分布規律。

02 /拓撲規范化

再往后發展，就會變成拓撲學中著名的N2問題。

從成本角度考慮又不可能完全是N2，所以為了避免園區太多了之后，互聯太多、太亂，網工們首先想到的是找2個POP點作為所有園區的中轉互聯。

所有園區都需要和2個POP點機房互聯，同時可以保留園區之間的直聯，園區直聯通常在這種架構中叫“直通車”。

如上圖，所需的連接有14條，可以如果熟悉拓撲規律，會很清楚這種Mesh組網的復雜度是O(N2)。

N表示園區和POP點的總數，所以如果縮小N，就可以大幅縮減需要租用的互聯鏈路。

最直接的方案是，挑2個長期合作的核心園區承擔POP功能，例如下圖中的C和E↓

這個方案只需要9條連接，比原方案減少了5條。

POP功能和園區合并也是降成本的趨勢產物。

在此基礎上就可以做出跨Region互聯的方案，如國內典型的華南-華東-華北三地域格局——

這基本上就是大廠覆蓋全國的“紅-綠”雙平面環網全國性質骨干網的雛形了。

在這個基礎上，每個Region內園區除了和POP互聯外，還可以按需組建直通車鏈路：

1、減少POP園區的負擔
2、降低業務耦合園區之間的時延，保障業務性能

直通車鏈路的起源主要來自于業務部署，而非網絡規劃：

1、剛開始一個新業務在犄角旮旯猥瑣發育，哪里有資源就部署在哪里，典型的朱元璋一只碗開局
2、這個業務猥瑣成功了，日活爆了，但原來那個園區資源不夠擴了，擴到其它園區，通過POP園區中轉
3、業務跨這2個園區的redis等時延和抖動敏感的流量太大了，跨POP時延又高、又經常被別的園區流量占用帶寬，老要擴容
4、那就給這2個園區建個直通車鏈路，帶寬專用、時延降低

03 /數通組網

?園區內與DCN的銜接

如下圖，通常DCI在園區內與DCN有2種銜接方式：垂直模式和平行模式。

垂直模式比較好理解，DCI設備在拓撲上位于園區核心的上一層，要求DCI設備與園區核心Full-Mesh連接。

平行模式中，DCI設備和園區核心屬于同一層級，也可以認為是一部分特殊的園區核心。

DCI設備與園區核心不互聯，DCI設備專門用于跨園區互聯，園區核心專用于集群間的高帶寬互聯。

這兩種種模式有各自的優缺點，適合不同的運營模式，如果沒有什么特別的訴求。

一般的網絡團隊都會選擇垂直模式，比較好理解，運營也容易適應。

如果有如下精細化運營的需求，那么水平模式就會被考慮：

1、控制初建成本，不想一次性把園區核心和DCI矩陣全建滿，而是根據實際水位擴容矩陣中的平面
2、精準容量運營，平行方式可以精確區分南北向流量和東西向流量的水位，以實現精準流量擴容，而避免大水漫灌
3、減少層級，縮小幾us的轉發時延，不過和DCI傳輸距離（每10公里增加100us RTT時延）而言，這點減少微不足道

通常只有到了極致追求成本的情況（具備把成本優勢轉化為市場優勢的能力）下，才會考慮這么極端的操作。

同樣的，也必須具備這種極致的網絡運營能力。

?跨園區的協議選擇

Region內，由于連接是由業務需求轉化，相對DCN沒什么規律。

因此都收斂為互聯網最初的樣子，那就把每個園區當作一個組織↓

1、園區和園區之間通過EBGP方式互相交換路由
2、經過POP園區或別的園區的路徑就相當于通過別的組織中轉路由

這樣的好處，可以天然利用EBGP簡潔的路由策略控制互訪的主用路徑和確定性備用路徑。

在跨Region場景，這時就會學習運營商的骨干網設計：SIS+帶RR的IBGP再疊加各種SDN混合的流量工程。

這么干的目的是↓

1、骨干網作為一個整體提供的是統一的跨域數據帶寬服務，所以可以視為1個IBGP域
2、由于拓撲的復雜性，ISIS相比OSPF具有更簡化的LSDB數據結構、天然的雙棧能力可以具備更好的復雜拓撲適應性，簡單來說OSPF在ISIS面前更像是個玩具，根本上不了嚴肅運營場景的臺面
3、通過流量工程可以對不同DSCP值的流量進行靈活的水位控制。

a類通常不給業務使用，所以水位控制主要在b類型流量上，閾值會控制在線路帶寬的40%，突破40%就需要考慮擴容了。

剩下的60%帶寬其中大部分會給c類流量作為quota，閑置帶寬就可以被d類流量隨意使用。

不同類型流量的收費策略可以用天差地別來形容，不然所有業務就都會說自己非常重要得用b類，這種收費服務模型會倒逼業務區分流量，避免預算浪費。

a.協議流量最高優先級，占比極低
b.業務流量高優，確保SPF+承諾帶寬轉發（擁塞場景中，也優先保障轉發)通常給實時同步類業務
c. 業務流量次高優，承諾帶寬轉發（不確保SPF，擁塞場景中會被繞行），通常給非實時在線同步業務
d.業務流量默認，不承諾帶寬轉發（在擁塞場景中，會被優先丟棄），通常給離線類型業務

這種策略可以讓網絡團隊充分提升昂貴的骨干帶寬利用率，在上級領導那里獲得源源不斷的點贊。

具體流量工程的方式就不多介紹了，就是老一輩的MPLS TE、中生代SR-TE、新生代SRv6，并且加上SDN作輔助全局調度。

評價方式還是看能不能在保障關鍵業務b類流量的前提下充分讓c、d類流量提高鏈路帶寬利用率。

這都是被Google B4 90%以上利用率卷起來的游戲。

?一個常被忽視的關鍵點：穩定性

前面說的這好那好都是一切都正常的情況下，DCI不管是城域還是骨干都依賴光傳輸OTN網絡。

光傳輸的SLA是50ms保護，50ms對許多敏感的內存數據庫應用來說是一定會有感知的。

同時DCI設備數通協議互聯會經過許多2層和1層設備，無法在協議層快速感知到中間鏈路的異常。

這就需要在每條物理鏈路上疊加BFD，以實現快速探測端到端異常，而傳統的BFD工作在3層，無法遍歷每一條物理鏈路，這就需要進行相應的協議改造。

由于探測的靈敏性取決于探測頻率，高頻BFD會嚴重占用主控CPU資源，端口一多就更讓CPU吃不消，所以硬件級BFD都是DCI的低開銷特性。

很多時候，我看到以太網上層壘這么多復雜的特性，就忍不住要發點感慨↓

為啥以太網的鏈路層協議在HPN里啥都能改，可到了DCI場景，不能加個像SDH網絡那樣具備物理層連接可靠性的探測協議呢？

那就不需要什么BFD了，芯片廠商直接把這部分錢給賺了。

好了，關于DCI就聊這么多吧，祝大家拉纖愉快，搬磚絲滑。