沒想到吧，因為數據中心「胡亂選址」，誕生了一門獨立的網路功課。
這就是dci，data center interconnect，數據中心互聯，你可以認為這是大廠自建的城域/廣域網，谷歌的b4網路是這領域的祖師爺。
先為數據中心胡亂選址背鍋，實在背不動了才會進行數據中心園區規劃、再進行dci網路優化。
這種規律在老生代、中生代、新生代的大廠里循環，無一倖免。
01 /猥瑣發育，別浪
最開始，每個廠都還很小，誰也不知道能不能活到明天，更沒有專業的網工，本著少花錢的原則開始↓
①從租一個機位開始
②分散在不同機櫃的多個機位
③需要租1整個機櫃了
④分散在多列的機櫃
⑤重複以上的循環，依次到1整列機櫃、1整個模塊包間、1整層、1整樓、1整個園區
⑥通常不到1整層的時候，園區就沒空地兒了，業務再增長得去別的園區租機櫃了，而且交付周期非常短，不然關鍵業務促銷沒支持好，全公司都得歇菜
⑦這時候通常會有背景不一的網工不到10人，就會採取最簡單粗暴的方式（專線、裸纖都有可能，取決於交付時效）把2個園區連起來
⑧再接下來是3個園區、4個園區…
最終就會可能變成下面這個樣子，所謂的規律就沒什麼規律，也可能只是符合這個城市數據中心產業的分布規律。
02 /拓撲規範化
再往後發展，就會變成拓撲學中著名的n²問題。
從成本角度考慮又不可能完全是n²，所以為了避免園區太多了之後，互聯太多、太亂，網工們首先想到的是找2個pop點作為所有園區的中轉互聯。
所有園區都需要和2個pop點機房互聯，同時可以保留園區之間的直聯，園區直聯通常在這種架構中叫「直通車」。
如上圖，所需的連接有14條，可以如果熟悉拓撲規律，會很清楚這種mesh組網的複雜度是o(n²)。
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就聊這麼多吧，祝大家拉縴愉快，搬磚絲滑。
