最近因?yàn)閷懻撐牡年P(guān)系，泡知網(wǎng)、泡萬方，發(fā)現(xiàn)了很多學(xué)術(shù)界對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)一些構(gòu)想，發(fā)現(xiàn)里面不乏天才的想法，但日常我們沉迷在各個(gè)設(shè)備廠商調(diào)制好的羹湯中無法自拔，管中窺豹不見全局，還一直呼喊著“真香”，對(duì)于網(wǎng)工來說沉溺于自己的一方小小天地不如跳出來看看外界有哪些新的技術(shù)和思想，莫聽穿林打葉聲，何妨吟嘯且徐行

當(dāng)前新的數(shù)據(jù)中心網(wǎng)絡(luò)拓?fù)渲饕譃閮深?/p>

1、以交換機(jī)為核心，網(wǎng)絡(luò)連接和路由功能由交換機(jī)完成，各個(gè)設(shè)備廠商的“羹湯”全屬于這個(gè)領(lǐng)域

2、以服務(wù)器為核心，主要互聯(lián)和路由功能放在服務(wù)器上，交換機(jī)只提供簡單縱橫制交換功能

第一類方案中包含了能引發(fā)我回憶陰影的Fat-Tree，和VL2、Helios、c-Through、OSA等等，這些方案要么采用更多數(shù)量交換機(jī)，要么融合光交換機(jī)進(jìn)行網(wǎng)絡(luò)互聯(lián)，對(duì)交換機(jī)軟件和硬件要求比較高，第二類主要有DCell、Bcube、FiConn、CamCube、MDCube等等，主要推動(dòng)者是微軟，這類方案中服務(wù)器一版會(huì)通過多網(wǎng)卡接入網(wǎng)絡(luò)，為了支持各種流量模型，會(huì)對(duì)服務(wù)器進(jìn)行硬件和軟件的升級(jí)。

除了這些網(wǎng)絡(luò)拓?fù)涞淖兓猓鋵?shí)對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)傳輸協(xié)議TCP/IP、網(wǎng)絡(luò)虛擬化、網(wǎng)絡(luò)節(jié)能機(jī)制、DCI網(wǎng)絡(luò)互聯(lián)都有很多創(chuàng)新的技術(shù)和概念涌現(xiàn)出來。

網(wǎng)絡(luò)拓?fù)?/h1>

FatTree?

FatTree? 胖樹，2008年由UCSD大學(xué)發(fā)表的論文，同時(shí)也是5年前工作中接觸的第一種交換機(jī)為中心的網(wǎng)絡(luò)拓?fù)?，?dāng)時(shí)沒有太理解，跟客戶為這事掐的火星四濺，再來一次可能結(jié)論會(huì)有所改變，同時(shí)也是這篇論文引發(fā)了學(xué)術(shù)界對(duì)數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)拓?fù)湓O(shè)計(jì)的廣泛而深刻的討論，他提出了一套組網(wǎng)設(shè)計(jì)原則來達(dá)成幾個(gè)目的

1、全網(wǎng)采用低端商用交換機(jī)來組網(wǎng)、其實(shí)就是采用1U的接入交換機(jī)，取消框式設(shè)備

2、全網(wǎng)無阻塞

3、成本節(jié)省，紙面測算的話FatTree 可以降為常規(guī)模式組網(wǎng)成本的1/4或1/5

物理拓?fù)洌ò凑?個(gè)pod設(shè)計(jì)）

FatTree 的設(shè)計(jì)原則如下

整個(gè)網(wǎng)絡(luò)包含K個(gè)POD，每個(gè)POD有K/2個(gè)Edge和K/2個(gè)Agg 交換機(jī)，他們各有K的接口，Edge使用K/2個(gè)端口下聯(lián)服務(wù)器，Agg適用K/2個(gè)端口上聯(lián)CORE交換機(jī)

Edge使用K/2個(gè)端口連接服務(wù)器，每個(gè)服務(wù)器占用一個(gè)交換端口

CORE層由K/2*K/2共計(jì)KK/4個(gè)K個(gè)端口交換機(jī)組成，分為K/2組，每組由K/2ge，第一組K/2臺(tái)CORE交換機(jī)連接各個(gè)POD中Agg交換層一號(hào)交換機(jī)，第二組K/2的CORE交換機(jī)連接各POD中Agg的二號(hào)交換機(jī)，依次類推

K個(gè)POD，每個(gè)POD有K/2個(gè)Edge交換機(jī)，每個(gè)Edge有K/2端口，服務(wù)器總數(shù)為K*K/2*K/2=KKK/4

K取值4的話，服務(wù)器總數(shù)為16臺(tái)

常規(guī)K取值48的話，服務(wù)器為27648臺(tái)

FatTree的路由設(shè)計(jì)更加有意思，論文中叫兩階段路由算法，首先要說明的是如果使用論文中的算法是需要對(duì)交換機(jī)硬軟件進(jìn)行修改的，這種兩階段路由算法和交換設(shè)備及服務(wù)器的IP地址強(qiáng)相關(guān)，首先就是IP地址的編制，這里依然按照K=4來設(shè)計(jì)，規(guī)則如下

1、POD中交換機(jī)IP為10.pod.switch.1，pod對(duì)應(yīng)POD編號(hào)，switch為交換機(jī)所在POD編號(hào)（Edge從0開始由左至右到k/2-1，Agg從k/2至k-1）

2、CORE交換機(jī)IP為10.k.j.i ，k為POD數(shù)量，j為交換機(jī)在Core層所屬組編號(hào)，i為交換機(jī)在該組中序號(hào)

3、服務(wù)器IP為10.pod.switch.ID，ID為服務(wù)器所在Edge交換機(jī)序號(hào)，交換機(jī)已經(jīng)占用.1，所以從2開始由左至右到k/2+1

設(shè)計(jì)完成后交換機(jī)和服務(wù)器的IP地址會(huì)如下分配

對(duì)于Edge交換機(jī)（以10.2.0.1為例）第一階段匹配10.2.0.2和10.2.0.3的32位地址，匹配則轉(zhuǎn)發(fā)，沒有匹配（既匹配0.0.0.0/0）則根據(jù)目的地址后8位，也就是ID號(hào)，選擇對(duì)應(yīng)到Agg的鏈路，如目標(biāo)地址為x.x.x.2則選擇到10.2.2.1的鏈路，目標(biāo)地址為x.x.x.3則選擇到10.2.3.1的鏈路

對(duì)于Agg交換機(jī)（以10.2.2.1為例）第一階段匹配本POD中網(wǎng)段10.2.0.0/24和10.2.1.0/24，匹配成功直接轉(zhuǎn)發(fā)對(duì)應(yīng)Edge，沒有匹配（既匹配0.0.0.0/0）則根據(jù)目的地址后8位，也就是ID號(hào)確定對(duì)應(yīng)到Core的鏈路，如目標(biāo)地址為x.x.x.2則選擇到10.4.1.1的鏈路，目標(biāo)地址為x.x.x.3則選擇到10.4.1.2的鏈路

對(duì)于Core交換機(jī)，只有一個(gè)階段匹配，只要根據(jù)可能的POD網(wǎng)段進(jìn)行即可，這里是10.0.0.0/16~10.3.0.0/16對(duì)應(yīng)0、1、2、3四個(gè)口進(jìn)行轉(zhuǎn)發(fā)

容錯(cuò)方面論文提到了BFD來防止鏈路和節(jié)點(diǎn)故障，同時(shí)還有流量分類和調(diào)度的策略，這里就不展開了，因?yàn)檫@種兩階段路由算法要對(duì)交換機(jī)硬件進(jìn)行修改，適應(yīng)對(duì)IP后8位ID進(jìn)行匹配，現(xiàn)實(shí)中沒有看到實(shí)際案例，但是我們可以設(shè)想一下這種簡單的轉(zhuǎn)發(fā)規(guī)則再加上固定端口的低端交換機(jī)，對(duì)于轉(zhuǎn)發(fā)效率以及成本的壓縮將是極為可觀的。尤其這種IP地址規(guī)則的設(shè)計(jì)配合路由轉(zhuǎn)發(fā)，思路簡直清奇。但是仔細(xì)想想，這種按照特定規(guī)則的IP編制，把每個(gè)二層限制在同一個(gè)Edge交換機(jī)下，注定了虛擬機(jī)是沒有辦法跨Edge來遷移的，只從這點(diǎn)上來看注定它只能存在于論文之中，但是順著這個(gè)思路開個(gè)腦洞，還有什么能夠編制呢？就是MAC地址，如果再配上集中式控制那就更好了，于是就有了一種新的一種路由方式PortLand，后續(xù)我們單獨(dú)說。

如此看來FatTree 是典型的Scale-out模式，但是由于一般交換機(jī)端口通常為48口，如果繼續(xù)增加端口數(shù)量，會(huì)導(dǎo)致成本的非線性增加，底層Edge交換機(jī)故障時(shí)，難以保障服務(wù)質(zhì)量，還有這種拓?fù)湓诖髷?shù)據(jù)的mapreduce模型中無法支持one-to-all和all-to-all模式。

把腦洞開的稍微小一些，我們能否用通用商業(yè)交換機(jī)+通用路由來做出來一種FatTree變種拓?fù)?，來達(dá)到成本節(jié)省的目的呢，答案一定是確切的，目前能看到阿里已經(jīng)使用固定48口交換機(jī)搭建自己的變種FatTree拓?fù)淞恕?/p>

以交換機(jī)為中心的網(wǎng)絡(luò)拓?fù)淙鏥L2、Helios不再多說，目前看到最好的就是我們熟知的spine-leaf結(jié)構(gòu)，它沒有設(shè)計(jì)成1:1收斂比，而且如果使用super層的clos架構(gòu)，也可以支撐幾萬臺(tái)或者百萬臺(tái)的服務(wù)器規(guī)模，但是FaTtree依靠網(wǎng)絡(luò)拓?fù)淙∠袅丝蚴胶诵慕粨Q機(jī)，在一定規(guī)模的數(shù)據(jù)中心對(duì)于壓低成本是非常有效的

DCell

聊完交換機(jī)為核心的拓?fù)湓O(shè)計(jì)后，再來看看服務(wù)器為核心的拓?fù)洌瑯舆@些DCell、Bcube、FiConn、CamCube、MDCube等，不會(huì)全講，會(huì)拿DCell來舉例子，因?yàn)樗彩?008年由微軟亞洲研究院主導(dǎo)，幾乎和FatTree同時(shí)提出，開創(chuàng)了一個(gè)全新的思路，隨后的年份里直到今天一直有各種改進(jìn)版本的拓?fù)涑霈F(xiàn)

這種服務(wù)器為核心的拓?fù)?，主?dǎo)思想是在服務(wù)器上增加網(wǎng)卡，服務(wù)器上要有路由轉(zhuǎn)發(fā)邏輯來中轉(zhuǎn)流量數(shù)據(jù)包，并且采用遞推方式進(jìn)行組網(wǎng)。

DCell的基本單元是DCell0，DCell0中服務(wù)器互聯(lián)由一臺(tái)T個(gè)端口的mini交換機(jī)完成，跨DCell的流量要通過服務(wù)器網(wǎng)卡互聯(lián)進(jìn)行繞轉(zhuǎn)。通過一定數(shù)量的Dcell0組成一個(gè)DCell1，按照一定約束條件進(jìn)行遞推，組成DCell2以及DCellk

上圖例中是一個(gè)DCell1的拓?fù)洌?個(gè)Dcell0，每臺(tái)服務(wù)器2個(gè)端口，除連接自己區(qū)域的mini交換機(jī)外，另一個(gè)端口會(huì)依次連接其他DCell0中的服務(wù)器，來組成全互聯(lián)的結(jié)構(gòu)，最終有20臺(tái)服務(wù)器組成DCell1，所有服務(wù)器按照（m，n）坐標(biāo)進(jìn)行唯一標(biāo)識(shí)，m相同的時(shí)候直接通過moni交換機(jī)交互，當(dāng)m不同時(shí)經(jīng)由mini交換機(jī)中繼到互聯(lián)服務(wù)器，例子中紅色線為4.0服務(wù)器訪問1.3服務(wù)器的訪問路徑。

DCell組網(wǎng)規(guī)則及遞歸約束條件如下：

DCellk中包含DCellk-1的數(shù)量為GK

DCellk中包含服務(wù)器為Tk個(gè)，每臺(tái)服務(wù)器k+1塊網(wǎng)卡，則有

GK=Tk-1+1

TK=Gk-1 ? Tk-1

設(shè)DCell0中有4臺(tái)服務(wù)器

DCell1 中有5個(gè)DCell0 （G1=5）

Tk1=20臺(tái)服務(wù)器（T1=20）

DCell2 中有21個(gè)DCell1 （G2=21）

Tk2=420臺(tái)服務(wù)器（T2=420）

DCell3 中有421個(gè)DCell2 （G3=421）

Tk3=176820臺(tái)服務(wù)器（T3=176820）

…

Tk6=3260000臺(tái)服務(wù)器

經(jīng)過測算DCell3中每臺(tái)服務(wù)器的網(wǎng)卡數(shù)量為4，就能組建出包含17萬臺(tái)服務(wù)器的數(shù)據(jù)中心，同樣DCell的缺點(diǎn)和優(yōu)點(diǎn)一樣耀眼，這種遞歸后指數(shù)增長的網(wǎng)卡需求量，在每臺(tái)服務(wù)器上可能并不多，但是全量計(jì)算的話就太過于驚人了，雖然對(duì)比FatTree又再一次降低交換機(jī)的采購成本，但是天量的網(wǎng)卡可以想象對(duì)于運(yùn)維的壓力，還有關(guān)鍵的問題時(shí)高層次DCell間通信占用低層次DCell網(wǎng)卡帶寬必然導(dǎo)致低層次DCell經(jīng)常擁塞。最后還有一個(gè)實(shí)施的問題，天量的不同位置網(wǎng)卡布線對(duì)于施工的準(zhǔn)確度以及未知的長度都是一個(gè)巨大的挑戰(zhàn)。

DCell提出后，隨后針對(duì)網(wǎng)卡數(shù)量、帶寬搶占等一系列問題演化出來一批新的網(wǎng)絡(luò)拓?fù)?，思路無外乎兩個(gè)方向，一個(gè)是增加交換機(jī)數(shù)量減少單服務(wù)網(wǎng)卡數(shù)量，趨同于spine-leaf體系，但是它一直保持了服務(wù)器多網(wǎng)卡的思路。另一種是極端一些，干脆消滅所有交換機(jī)，但是固定單服務(wù)器網(wǎng)卡數(shù)量，按照矩陣形式組建純服務(wù)器互聯(lián)結(jié)構(gòu)，感興趣的同學(xué)可以繼續(xù)探索。

路由框架

數(shù)據(jù)中心的路由框架涵蓋范圍和領(lǐng)域非常多，很多論文都選擇其中的一個(gè)點(diǎn)進(jìn)行討論，比如源地址路由、流量調(diào)度、收斂、組播等等，不計(jì)劃每個(gè)展開，也沒有太大意義。但是針對(duì)之前FatTree的兩階段路由有一個(gè)更新的路由框架設(shè)計(jì)PortLand，它解決了兩段路由中虛擬機(jī)無法遷移的問題，它的關(guān)鍵技術(shù)有以下幾點(diǎn)

1、對(duì)于FatTree這種高度規(guī)范化的拓?fù)?，PortLand設(shè)計(jì)為采用層次化MAC編址來支持大二層，這種路由框架中，除了虛擬機(jī)/物理機(jī)實(shí)際的MAC外（AMAC），還都擁有一個(gè)PortLand規(guī)范的偽MAC（PMAC），網(wǎng)絡(luò)中的轉(zhuǎn)發(fā)機(jī)制和PMAC強(qiáng)相關(guān)，PMAC的編址規(guī)則為

pod.position.port.vmid

pod (2字節(jié)) 代表虛擬機(jī)/服務(wù)器所在POD號(hào)，position（1字節(jié)）虛擬機(jī)/服務(wù)器所在Edge交換機(jī)在POD中編號(hào)，port（1字節(jié)）虛擬機(jī)/服務(wù)器連接Edge交換機(jī)端口的本地編號(hào)，vmid（2字節(jié)）服務(wù)器在Edge下掛以太網(wǎng)交換機(jī)編號(hào)，如果只有一臺(tái)物理機(jī)vmid只能為1

2、虛擬機(jī)/服務(wù)器的編址搞定后，Edge、Aggregate、Core的編址呢，于是PortLand設(shè)計(jì)了一套拓?fù)浒l(fā)現(xiàn)機(jī)制LDP（location discovery protocol），要求交換機(jī)在各個(gè)端口上發(fā)送LDP報(bào)文LDM（location

discovery message）識(shí)別自己所處位置，LDM消息包含switch_id（交換機(jī)自身mac，與PMAC無關(guān)）pod（交換機(jī)所屬pod號(hào)）pos（交換機(jī)在pod中的編號(hào)）level（Edge為0、Agg為1、Core為2）dir（上聯(lián)為1，下聯(lián)為-1），最開始的時(shí)候Edge角色會(huì)發(fā)現(xiàn)連接服務(wù)器的端口是沒有LDM的，它就知道自己是Edge，Agg和Core角色依次收到LDM后會(huì)計(jì)算并確定出自己的leve和dir等信息。

3、設(shè)計(jì)一個(gè)fabric manager的集中PortLand控制器，它負(fù)責(zé)回答Edge交換機(jī)pod號(hào)和ARP解析，當(dāng)Edge交換機(jī)學(xué)習(xí)到一個(gè)AMAC時(shí)，會(huì)計(jì)算一個(gè)PMAC，并把IP/AMAC/PMAC對(duì)應(yīng)關(guān)系發(fā)送給fabric manager，后續(xù)有虛擬機(jī)/服務(wù)器請求此IP的ARP時(shí)，會(huì)回復(fù)PMAC地址給它，并使用這個(gè)PMAC進(jìn)行通信。

4、由于PMAC的編址和pod、pos、level等信息關(guān)聯(lián)，而所有交換機(jī)在LDM的交互過程中知曉了全網(wǎng)的交換機(jī)pod、pos、level、dir等信息，當(dāng)數(shù)據(jù)包在網(wǎng)絡(luò)中傳播的時(shí)候，途徑交換機(jī)根據(jù)PMAC進(jìn)行解析可得到pod、pos這些信息，根據(jù)這些信息即可進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)，數(shù)據(jù)包到達(dá)Edge后，Edge交換機(jī)會(huì)把PMAC改寫為AMAC，因?yàn)樗侵榔鋵?duì)應(yīng)關(guān)系的。當(dāng)虛擬機(jī)遷移后，由fabric manager來進(jìn)行AMAC和PMAC對(duì)應(yīng)更新和通知Edge交換機(jī)即可，論文中依靠虛擬機(jī)的免費(fèi)ARP來觸發(fā)，這點(diǎn)在實(shí)際情況中執(zhí)行的效率要打一個(gè)問號(hào)。

不可否認(rèn)，PortLand的一些設(shè)計(jì)思路非常巧妙，這種MAC地址重寫非常有特色。規(guī)則設(shè)計(jì)中把更多的含義賦給PMAC，并且通過LDP機(jī)制設(shè)計(jì)為全網(wǎng)根據(jù)PMAC即可進(jìn)行轉(zhuǎn)發(fā)，再加上集中的控制平面fabric manager，已經(jīng)及其類似我們熟悉的SDN。但是它對(duì)于轉(zhuǎn)發(fā)芯片的要求可以看出要求比較低，但是所有的轉(zhuǎn)發(fā)規(guī)則會(huì)改變，這需要業(yè)內(nèi)對(duì)于芯片和軟件的全部修改，是否能夠成功也看市場驅(qū)動(dòng)力吧，畢竟市場不全是技術(shù)驅(qū)動(dòng)的。

數(shù)據(jù)中心技術(shù)趨勢

除了我們熟悉的拓?fù)浜吐酚煽蚣芊矫?，?shù)據(jù)中心還有很多比較有意思的趨勢在發(fā)生，挑幾個(gè)有意思的

數(shù)據(jù)中心無線通訊

目前數(shù)據(jù)中心都是以太網(wǎng)有線網(wǎng)絡(luò)，大量的高突發(fā)和高負(fù)載各個(gè)路由設(shè)架構(gòu)都會(huì)涉及，但是如果使用無線是不是也能解決呢，于是極高頻技術(shù)在數(shù)據(jù)中心也有了一定的研究（這里特指60GHZ無線），其吞吐可達(dá)4Gbps，通過特殊物理環(huán)境、波束成形、有向天線等技術(shù)使60GHZ部署在數(shù)據(jù)中心中，目前研究法相集中在無線調(diào)度和覆蓋中，技術(shù)方案為Flyways，它通過合理的機(jī)柜擺放及無線節(jié)點(diǎn)空間排布來形成有效的整體系統(tǒng)，使用定向天線和波束成形技術(shù)提高連接速率等等新的技術(shù)，甚至還有一些論文提出了全無線數(shù)據(jù)中心，這樣對(duì)數(shù)據(jù)中心的建設(shè)費(fèi)用降低是非常有助力的。

數(shù)據(jù)中心傳輸協(xié)議

數(shù)據(jù)中心目前應(yīng)用的還是TCP，而TCP在特定場景下一定會(huì)遇到性能急劇下降的TCP incast現(xiàn)象，TCP的擁塞避免和慢啟動(dòng)會(huì)造成當(dāng)一條鏈路擁塞時(shí)其承載的多個(gè)TCP流可能會(huì)同時(shí)觸發(fā)TCP慢啟動(dòng)，但隨著所有的TCP流流量增加后又會(huì)迅速達(dá)到擁塞而再次觸發(fā)，造成網(wǎng)絡(luò)中有時(shí)間流量很大，有時(shí)間流量又很小。如何來解決

數(shù)據(jù)中心還有很多應(yīng)用有典型的組通信模式，比如分布式存儲(chǔ)、軟件升級(jí)等等，這種情況下組播是不是可以應(yīng)用進(jìn)來，但是組播在數(shù)據(jù)中心會(huì)不會(huì)水土不服，如何解決

還有就是數(shù)據(jù)中心的多路徑，可否從TCP層面進(jìn)行解決，讓一條TCP流負(fù)載在不同的鏈路上，而不是在設(shè)備上依靠哈希五元組來對(duì)每一條流進(jìn)行特定鏈路分配

對(duì)于TCPincast，一般通過減少RTO值使之匹配RTT，用隨機(jī)的超時(shí)時(shí)間來重啟動(dòng)TCP傳輸。還有一種時(shí)設(shè)計(jì)新的控制算法來避免，甚至有方案拋棄TCP使用UDP來進(jìn)行數(shù)據(jù)傳輸。

對(duì)于組播，數(shù)據(jù)中心的組播主要有將應(yīng)用映射為網(wǎng)絡(luò)層組播和單播的MCMD和Bloom Filter這種解決組播可擴(kuò)展性的方案

對(duì)于多路徑，提出多徑TCP（MPTCP），在源端將數(shù)據(jù)拆分成諾干部分，并在同一對(duì)源和目的之間建立多個(gè)TCP連接進(jìn)行傳輸，MPTCP對(duì)比傳統(tǒng)TCP區(qū)別主要有

1、MPTCP建立階段，要求服務(wù)器端向客戶端返回服務(wù)器所有的地址信息

2、不同自流的源/目的可以相同，也可以不同，各個(gè)子流維護(hù)各自的序列號(hào)和滑動(dòng)窗口，多個(gè)子流到達(dá)目的后，由接收端進(jìn)行組裝

3、MPTCP采用AIMD機(jī)制維護(hù)擁塞窗口，但各個(gè)子流的擁塞窗口增加與所有子流擁塞窗口的總和相關(guān)

還有部分針對(duì)TCP的優(yōu)化，如D3協(xié)議，D3是針對(duì)數(shù)據(jù)中心的實(shí)時(shí)應(yīng)用，通過分析數(shù)據(jù)流的大小和完成時(shí)間來分配傳輸速率，并且在網(wǎng)絡(luò)資源緊張的時(shí)候可以主動(dòng)斷開某些預(yù)計(jì)無法完成傳輸?shù)臄?shù)據(jù)流，從而保證更多的數(shù)據(jù)流能按時(shí)完成。

數(shù)據(jù)中心節(jié)能機(jī)制

這的數(shù)據(jù)中心節(jié)能不會(huì)談風(fēng)火水電以及液冷等等技術(shù)，從網(wǎng)絡(luò)拓?fù)涞慕嵌日勂?，我們所有?shù)據(jù)中心拓?fù)浯罱ǖ倪^程中，主要針對(duì)傳統(tǒng)樹形拓?fù)涮岢隽撕芏唷案贿B接”的拓?fù)?，來保證峰值的時(shí)候網(wǎng)絡(luò)流量的保持性，但是同時(shí)也帶來了不在峰值條件下能耗的增加，同時(shí)我們也知道數(shù)據(jù)中心流量多數(shù)情況下遠(yuǎn)低于其峰值設(shè)計(jì)，學(xué)術(shù)界針對(duì)這塊設(shè)計(jì)了不少有腦洞的技術(shù)，主要分為兩類，一類時(shí)降低硬件設(shè)備能耗，第二類時(shí)設(shè)計(jì)新型路由機(jī)制來降低能耗。

硬件能耗的降低主要從設(shè)備休眠和速率調(diào)整兩個(gè)方面來實(shí)現(xiàn)，其難點(diǎn)主要時(shí)定時(shí)機(jī)制及喚醒速度的問題，當(dāng)遇到突發(fā)流量交換機(jī)能否快速喚醒，人們通過緩存和定時(shí)器組合的方式進(jìn)行。

節(jié)能路由機(jī)制，也是一個(gè)非常有特點(diǎn)的技術(shù)，核心思想是通過合理的選擇路由，只使用一部分網(wǎng)絡(luò)設(shè)備來承載流量，沒有承載流量的設(shè)備進(jìn)行休眠或者關(guān)閉。Elastic Tree提出了一種全網(wǎng)范圍的能耗優(yōu)化機(jī)制，它通過不斷的檢測數(shù)據(jù)中心流量狀況，在保障可用性的前提下實(shí)時(shí)調(diào)整鏈路和網(wǎng)絡(luò)設(shè)備狀態(tài)，Elastic Tree探討了bin-packer的貪心算法、最優(yōu)化算法和拓?fù)涓兄膯l(fā)算法來實(shí)現(xiàn)節(jié)能的效果。

何妨吟嘯且徐行

通過以上可以看到數(shù)據(jù)中心發(fā)展非常多樣化，驅(qū)動(dòng)這些技術(shù)發(fā)展的根本性力量就是成本，人們希望用最低的成本達(dá)成最優(yōu)的數(shù)據(jù)中心效能，同時(shí)內(nèi)部拓?fù)浞桨傅难芯恳呀?jīng)慢慢成熟，目前設(shè)備廠商的羹湯可以說就是市場化選擇的產(chǎn)物，但是數(shù)據(jù)中心網(wǎng)絡(luò)傳輸協(xié)議、虛擬化、節(jié)能機(jī)制、SDN、服務(wù)鏈等方向的研究方興未艾，尤其是應(yīng)用定制的傳輸協(xié)議、虛擬網(wǎng)絡(luò)帶寬保障機(jī)制等等，這些學(xué)術(shù)方面的研究并不僅僅是紙上談兵，對(duì)于我知道的一些信息來說，國內(nèi)的阿里在它的數(shù)據(jù)中心網(wǎng)絡(luò)拓?fù)渲性缫呀?jīng)應(yīng)用了FatTree的變種拓?fù)?，思科也把?shù)據(jù)中心內(nèi)部TCP重傳的技術(shù)應(yīng)用在自己的芯片中，稱其為CONGA。

坦白來說，網(wǎng)絡(luò)從來都不是數(shù)據(jù)中心和云計(jì)算的核心，可能未來也不會(huì)是，計(jì)算資源的形態(tài)之爭才是主戰(zhàn)場，但是網(wǎng)絡(luò)恰恰是數(shù)據(jù)中心的一個(gè)難點(diǎn)，傳統(tǒng)廠商、學(xué)術(shù)界、大廠都集中在此領(lǐng)域展開競爭，創(chuàng)新也層出不窮，希望能拓展我們的技術(shù)視野，能對(duì)我們有一些啟發(fā)，莫聽穿林打葉聲、何妨吟嘯且徐行~