1、數(shù)據(jù)中心流量趨勢
在移動互聯(lián)網(wǎng)時代以前，人們上網(wǎng)接入帶寬也就是幾十到幾百 K，上網(wǎng)的主要目的是瀏覽網(wǎng)頁、聊 QQ、聽音樂，信息的流向主要是下行，規(guī)模不大，數(shù)據(jù)中心流量主要是南北向的流量；但是隨著移動互聯(lián)網(wǎng)的到來，智能手機的普及，4K 視頻、微信、視頻、語音、AR/VR等互聯(lián)網(wǎng)應(yīng)用等對網(wǎng)絡(luò)帶寬都帶來了巨大的增長，信息的流向不在是以下行為主了，上行和下行都在變大，數(shù)據(jù)中心除了南北向流量外，東西向流量也在同步增長；
下圖是 cisco 對未來數(shù)據(jù)中心流量的預(yù)測，預(yù)測到2021年全球數(shù)據(jù)中心流量年增長25%，Google 的數(shù)據(jù)中心流量從2008年到2014年增長了50倍，百度近幾年數(shù)據(jù)中心流量的年增長比例也在50%以上；
數(shù)據(jù)中心流量組成中，數(shù)據(jù)中心內(nèi)流量占比高達(dá)71.5%，在數(shù)據(jù)中心間占比13.6%，數(shù)據(jù)中心到用戶的流量占比只有14.9%；這么高的內(nèi)部流量占比，需要一個強有力的數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)才能支撐。
2、數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)演進
數(shù)據(jù)中心網(wǎng)絡(luò)在演進過程中有很多種架構(gòu)，以 Four-Post 和 Clos最為常見，以下是 Facebook 公開的兩種網(wǎng)絡(luò)架構(gòu)。
此架構(gòu)由4臺 CSW 交換機組成一個網(wǎng)絡(luò)集群Cluster，在 Cluster 內(nèi)每臺 RSW（即 TOR） 交換機有4條鏈路上行至 CSW，網(wǎng)絡(luò) Cluster 間通過 FC 交換機互聯(lián)；該架構(gòu)，通過復(fù)制 Cluster可以滿足大規(guī)模服務(wù)器組網(wǎng)的需求，但該網(wǎng)絡(luò)在某些方面有些不足，如
1）在冗余度上，單臺 CSW 故障流量損失25%；單臺 FC 故障Cluster 間流量損失25%；
2）Cluster 集群規(guī)模由 CSW 設(shè)備端口容量決定；
3）該架構(gòu)收斂比較高；
4）CSW 設(shè)備一般是大型框式設(shè)備，供應(yīng)商少，CAPEX 和 OPEX高；
5）核心設(shè)備軟件問題和定制化開發(fā)難度大；
CLOS Fabric
此架構(gòu)由三個層級的交換機組成，分別是 Spine SW、Edge SW、RSW。每4臺 ESW 和48臺 RSW 組成1個 Server Pod，每 RSW 有4條鏈路上聯(lián) ESW，每臺 ESW 上聯(lián)一個 Spine 平面；該架構(gòu)，通過復(fù)制 Server Pod 來擴展網(wǎng)絡(luò) Cluster 集群規(guī)模，集群擴展很靈活，可支持的服務(wù)器規(guī)模大，設(shè)備和鏈路的冗余度也大，可靠性高，且網(wǎng)絡(luò)Cluster 集群內(nèi)無收斂比，網(wǎng)絡(luò)吞吐能力高，但在管理運維方面復(fù)雜度高，需要部署 SDN 等自動化的管理運維手段。
百度數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)；下圖是百度在2017年以前的數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)，架構(gòu)和上述 Four-Post 相同，該架構(gòu)的特點如下：
1）網(wǎng)絡(luò)Cluster集群的截面帶寬（BBW）有100X Tbps；
2）TOR 層級有3：1的收斂比；
3）網(wǎng)絡(luò)可靠性，單臺Leaf設(shè)備故障 影響一個 POD 的25%流量；單臺 Spine 交換機故障，影響整個網(wǎng)絡(luò)集群1/8的流量；
4）CLOS 內(nèi)部互聯(lián)鏈路多，運維監(jiān)控是個挑戰(zhàn)；
下圖是百度現(xiàn)在的 CLOS 架構(gòu)；架構(gòu)同 Facebook 的 Clos 架構(gòu)類同，但Leaf 節(jié)點、Spine 節(jié)點仍采用大型的商用框式交換機，后續(xù)會使用自研交換機替代。這個架構(gòu)特點如下：
由上述網(wǎng)絡(luò)架構(gòu)演進可見，不管是Four-Post 架構(gòu)還是 Clos架構(gòu)，在數(shù)據(jù)中心內(nèi)，網(wǎng)絡(luò)設(shè)備和光互聯(lián)鏈路的數(shù)量非常多，如何有效的進行網(wǎng)絡(luò)和鏈路的運維是我們面臨的巨大挑戰(zhàn)。
數(shù)據(jù)中心光互聯(lián)網(wǎng)絡(luò)運維實踐
首先，數(shù)據(jù)中心光互聯(lián)網(wǎng)絡(luò)運維都有哪些挑戰(zhàn)：
1）光互聯(lián)覆蓋范圍廣；1Xm ~100X Km；
2）光互聯(lián)鏈路數(shù)量和類型很多；在100m 上，有 OM3/OM4，模塊有 SR4、ESR4；500m 距離，有單模光纖，PSM4、CWDM4模塊；2KM 的數(shù)據(jù)中心園區(qū)場景，有單模光纜、CWDM4、LR4光模塊；數(shù)據(jù)中心間，隨著距離的增長也有不同的技術(shù)應(yīng)用，LR4、10G DWDM 彩光、200G OTN 等；
3）難以用一種監(jiān)控手段覆蓋所有的技術(shù)類別，存在多種監(jiān)控系統(tǒng)和平臺，運維效率低。
然后，百度針對這些不同互聯(lián)場景的運維實踐，如下：
1）設(shè)備或模塊故障，采用 基于設(shè)備SYSLOG 日志分析的運維監(jiān)控方法，針對設(shè)備上報的日志來及時監(jiān)控運行狀態(tài)；
2）針對鏈路類的故障，采用自動化 ping 程序來監(jiān)控鏈路狀態(tài)，同時部署了多個路由協(xié)議探針做鏈路級故障的分析和判斷；
3）針對鏈路的誤碼和丟包等質(zhì)量問題，部署了2套網(wǎng)絡(luò)質(zhì)量監(jiān)控系統(tǒng)來監(jiān)控，一套是部署在網(wǎng)絡(luò)核心 IC層級的天網(wǎng) 監(jiān)控系統(tǒng)，實時監(jiān)測鏈路的誤碼和丟包情況；另一套是業(yè)務(wù)部門在服務(wù)器上部署的 Net-radar 系統(tǒng)，實時感知網(wǎng)絡(luò)質(zhì)量異常；
最后，SDN 的部署，整合了上述傳統(tǒng)網(wǎng)絡(luò)監(jiān)控工具，基于 SDN/IBN 的思想構(gòu)建了智能管控編排中心，下圖是框圖：
SDN系統(tǒng)實時采集網(wǎng)絡(luò)設(shè)備各種配置和狀態(tài)數(shù)據(jù)；包括單不限于，資產(chǎn)、配置、拓?fù)洹⒘髁俊⑷罩镜龋?/span>
整個系統(tǒng)是個閉環(huán)系統(tǒng)，當(dāng)監(jiān)測到網(wǎng)絡(luò)異常時，根據(jù)不同的策略進行業(yè)務(wù)編排，下發(fā)控制命令，故障隔離，編排處理流程策略；自動或轉(zhuǎn)人工處理；在處理過程中，自動校驗檢測、自動恢復(fù)上線和流量調(diào)度；全程都是現(xiàn)場的人和機器人交互，提高溝通效率；
4、從運維角度對數(shù)據(jù)中心光互聯(lián)網(wǎng)絡(luò)的技術(shù)需求
1）我們希望設(shè)備商、模塊商、系統(tǒng)商，更加開放，讓用戶擁有自主權(quán)，可在內(nèi)部編寫 APP 或 AGENT，自定義管理控制功能及接口，提取或主動上報各類運行數(shù)據(jù)，加速數(shù)據(jù)中心網(wǎng)絡(luò)運維自動化進程；
2）我們希望 IP 和光能夠進一步融合（軟件或硬件層面），便于 SDN 統(tǒng)一管控，為業(yè)務(wù)提供多層次的控制策略。
189-0300-8674（林經(jīng)理）
