數(shù)據(jù)中心網(wǎng)絡(luò)性能：新應(yīng)用下的新需求

    隨著機(jī)器學(xué)習(xí)，大數(shù)據(jù)，云計(jì)算和NFV不斷完善，數(shù)據(jù)中心網(wǎng)絡(luò)性能也隨之發(fā)展。亞馬遜，谷歌，百度和騰訊等大型云服務(wù)提供商已更新提供IT服務(wù)的方式，使之功能更強(qiáng)大，速度更敏捷，靈活性更高。這敲響了傳統(tǒng)運(yùn)營(yíng)商的警鐘，AT&T技術(shù)與運(yùn)營(yíng)首席策略官John Donovan 表示，AT＆T致力于成為“世界上最具侵略性的IT公司”。OTT產(chǎn)品在業(yè)界的應(yīng)用已變得普遍，應(yīng)用和服務(wù)開發(fā)都需要?jiǎng)?chuàng)新完善。

    他表示：“廠商正在逐漸成為競(jìng)爭(zhēng)對(duì)手，過去的競(jìng)爭(zhēng)對(duì)手變?yōu)殚_源開發(fā)等領(lǐng)域的合作伙伴。整個(gè)行業(yè)的工作方式正在發(fā)生變化。我們?cè)跇?biāo)準(zhǔn)機(jī)構(gòu)這個(gè)平臺(tái)上共同管理，交流意見解決問題、制作產(chǎn)品。每個(gè)參與者都要在規(guī)則內(nèi)，在競(jìng)爭(zhēng)中合作。”

    基于了未來發(fā)展和競(jìng)爭(zhēng)現(xiàn)狀，諸如AT＆T這樣的運(yùn)營(yíng)商已經(jīng)擁抱NFV和分布式計(jì)算，以支持應(yīng)用交付、機(jī)器學(xué)習(xí)和大數(shù)據(jù)分析來管理基礎(chǔ)設(shè)施。這些演變需要在數(shù)據(jù)中心不斷發(fā)展的前提下實(shí)現(xiàn)，以確保大型數(shù)據(jù)集和IO密集型工作負(fù)載的性能。

    普通于云計(jì)算的企業(yè)工作負(fù)載是計(jì)算密集型的，但不一定是IO密集型。因此，使用NFV和云計(jì)算的通信應(yīng)用程序需要更高要求的網(wǎng)絡(luò)結(jié)構(gòu)。運(yùn)用NFV的運(yùn)營(yíng)商，需要收集大量在網(wǎng)絡(luò)的虛擬和物理層的實(shí)時(shí)數(shù)據(jù)。

    Global Data首席分析師Peter Jarich解釋說：“我們致力于實(shí)現(xiàn)可以查找任何字節(jié)，操作，捕獲，重寫;通過網(wǎng)絡(luò)端到端的每個(gè)數(shù)據(jù)包進(jìn)行時(shí)間戳，對(duì)交換機(jī)中的緩沖進(jìn)行連續(xù)的實(shí)時(shí)監(jiān)控。”

    性能杠桿：帶寬速度

    隨著對(duì)海量數(shù)據(jù)傳輸和網(wǎng)絡(luò)瞬間數(shù)據(jù)傳輸?shù)难芯恐饾u深入，我們發(fā)現(xiàn)影響系統(tǒng)性能的原因有兩個(gè)：原始吞吐量和延遲。

    為了解決原始吞吐量的問題，大容量服務(wù)器正在重新定義數(shù)據(jù)中心內(nèi)的架構(gòu)和經(jīng)濟(jì)模型。我們對(duì)提高服務(wù)器速度進(jìn)行投資，使之從10Gb / s提高到25Gb / s以上，提高組織帶寬和消息速率升。跟10Gb / s的相比25Gb / s的帶寬提高2.5倍，成本在1.3X到1.5X之間。

    Gartner數(shù)據(jù)中心融合和數(shù)據(jù)中心實(shí)踐副總裁兼分析師Joe Skorupa表示“從經(jīng)濟(jì)角度來看，此舉意義重大，現(xiàn)行的25 Gb / s和50 Gb / s服務(wù)架構(gòu)將轉(zhuǎn)換為50 Gb / s和100 Gb / s的網(wǎng)絡(luò)連接，與此同時(shí)光網(wǎng)絡(luò)成本也在下降 。40Gb / s連接需要四條10 Gb / s的通道，今天的50Gb / s連接由25b / s鏈路即可，速度的提升意味著價(jià)格下降，因?yàn)榻粨Q機(jī)端口和光纖成本都會(huì)下降。“

    在數(shù)據(jù)中心互連方面，容量是影響性能的重要因素。例如，移動(dòng)邊緣計(jì)算正在成為趨勢(shì)，因?yàn)檫\(yùn)營(yíng)商希望使用機(jī)器學(xué)習(xí)和人工智能來管理具有更多分布式節(jié)點(diǎn)的網(wǎng)絡(luò)。

    Jarich指出：“過去，每?jī)砂賯€(gè)基站都有一個(gè)EPC節(jié)點(diǎn)，所以在美國(guó)傳統(tǒng)的分組核心中將有十幾個(gè)站點(diǎn)?，F(xiàn)在，您可能有成千上萬的站點(diǎn)，因?yàn)橛脩粜枰嗟膸拰⑵滏溄拥胶诵?。如果我們要在?shù)據(jù)中心的網(wǎng)絡(luò)邊緣實(shí)施大量的分析和控制，那么我們必須快速提升分析速度和控制的靈活度。”

    降低延遲的架構(gòu)

    考慮到延遲的因素，內(nèi)部數(shù)據(jù)中心拓?fù)湟苍谧兓?，老式的三層設(shè)計(jì)被leaf-spine的設(shè)計(jì)所取代，這種設(shè)計(jì)方式專門用于大數(shù)據(jù)行業(yè)，如不斷發(fā)展的電信數(shù)據(jù)中心。傳統(tǒng)的三層模式由核心路由器，聚合路由器和接入交換機(jī)組成，通過冗余路徑互連。但一般只有一個(gè)主要路由，只有在主要路由中斷的情況下才啟動(dòng)備份路徑。

    下一代配置中設(shè)有兩層leaf-spine。leaf層由連接到服務(wù)器，防火墻，負(fù)載平衡器和邊緣路由器等設(shè)備的接入交換機(jī)組成。spine層由執(zhí)行路由的骨干交換機(jī)組成。每個(gè)leaf交換機(jī)與每個(gè)spine交換機(jī)互連，構(gòu)成網(wǎng)格拓?fù)?，這意味著所有設(shè)備的距離包含了信息傳播所需的可預(yù)測(cè)的延遲量。動(dòng)態(tài)路由根據(jù)網(wǎng)絡(luò)變化確定和調(diào)整最佳路徑。

    Skorupa說：“此舉顯著降低成本的同時(shí)提供了大量的橫截面帶寬，傳輸大量數(shù)據(jù)不成問題。我們相信很快也可以50 Gb / s服務(wù)器中得到應(yīng)用。”

    即使是在傳輸少量數(shù)據(jù)時(shí)，高速連接也十分重要。Skorupa解釋說：“當(dāng)您的工作負(fù)載傳遞少量延遲敏感的數(shù)據(jù)時(shí)，從10 Gb / s轉(zhuǎn)為25 Gb / s就有了用武之地。 網(wǎng)絡(luò)延遲可能只占用了百分之五的時(shí)間，但是在10Gb / s連接線纜需要2.5％乃至更長(zhǎng)的時(shí)間，轉(zhuǎn)換為25 Gb / s意味著從一個(gè)節(jié)點(diǎn)到另一個(gè)節(jié)點(diǎn)的所需時(shí)間的縮短。所有的這些都使得這些新應(yīng)用程序更加易于運(yùn)轉(zhuǎn)。”

    從vSwitch卸載（offload）

    影響分布式和虛擬化應(yīng)用程序延遲的另一個(gè)問題是虛擬交換機(jī)（vSwitch）的性能不足。

   Skorupa表示：“當(dāng)您查看廣域網(wǎng)優(yōu)化和虛擬防火墻等服務(wù)時(shí)，推出了大量的開放源代碼，這是vSwitch的一個(gè)性能問題。我們可以通過將一些交換功能遷移到網(wǎng)卡（NIC）中，或者購(gòu)買更多的服務(wù)器，但這會(huì)對(duì)NFV的投資回報(bào)率產(chǎn)生負(fù)面影響。

    offload的策略減輕了CPU的工作量。通過移動(dòng)到支持高級(jí)內(nèi)核旁路技術(shù)的技術(shù)棧實(shí)現(xiàn)最低延遲并顯著提高數(shù)據(jù)傳輸速率。

    消息加速軟件等輔助技術(shù)有助于實(shí)現(xiàn)這一點(diǎn)，它可以降低總體延遲并最小化CPU工作負(fù)載來提高應(yīng)用程序的性能。此外，數(shù)據(jù)平面開發(fā)套件（DPDK）提供了一個(gè)可編程架構(gòu)，能夠優(yōu)化應(yīng)用程序與NIC通信的數(shù)據(jù)路徑。與此同時(shí)，它能夠更快地處理數(shù)據(jù)包，這對(duì)處理大量以太網(wǎng)數(shù)據(jù)包處理或高消息速率的應(yīng)用程序（如虛擬化網(wǎng)絡(luò)功能）尤為有益。

    Jarich表示：“運(yùn)營(yíng)商越來越樂于擁抱云計(jì)算，尤其是當(dāng)他們搭建5G網(wǎng)絡(luò)并具有較大工作量時(shí)。移動(dòng)分布式計(jì)算的可帶來更低的延遲，回程節(jié)省，更高的可管理性，因此深受運(yùn)營(yíng)商青睞。”

    原文鏈接：https://www.sdxcentral.com/articles/analysis/data-center-networking-performance/2017/05/