三年前我們的數(shù)據(jù)中心的應(yīng)用程序面臨著一個(gè)潛在的嚴(yán)重問題，我們沒有根據(jù)應(yīng)用程序的需求對網(wǎng)絡(luò)基礎(chǔ)設(shè)施進(jìn)行縮放，這些需求包括高速、高可用性以及快速部署。我們需要在網(wǎng)絡(luò)層更好的控制功能，但我們在實(shí)現(xiàn)該目標(biāo)的時(shí)候面臨著障礙。

生產(chǎn)工程運(yùn)營團(tuán)隊(duì)（Production Engineering Operations team，PEO）發(fā)現(xiàn)很難滿足我們對應(yīng)用程序的需求，尤其是網(wǎng)絡(luò)中的路由器和交換機(jī)由廠商控制特性并修復(fù)Bug。一年以前我們發(fā)起了一個(gè)叫做Falco的項(xiàng)目，專注于對網(wǎng)絡(luò)中的軟硬件進(jìn)行解耦。Falco工作組花了11520個(gè)小時(shí)研發(fā)我們的第一款網(wǎng)絡(luò)交換機(jī)Pigeon，該交換機(jī)能夠兼容這種控制。Pigeon將部署在我們位于Oregon的新一代大規(guī)模數(shù)據(jù)中心。

Pigeon是一個(gè)3.2 Tbps交換平臺，可以作為leaf switch或者spine switch來使用。Pigeon是我們在交換機(jī)領(lǐng)域首次涉及軟件研發(fā)，我們不會冒險(xiǎn)研發(fā)我們自己的交換機(jī)，因?yàn)槲覀兏Ｍ蔀榻粨Q機(jī)和路由領(lǐng)域的專家。我們將持續(xù)支持商業(yè)廠商，并與他們在解耦模型中持續(xù)合作。

研發(fā)交換平臺的歷程

軟件工程團(tuán)隊(duì)發(fā)現(xiàn)的問題引起了PEO團(tuán)隊(duì)的注意，這兩個(gè)團(tuán)隊(duì)發(fā)現(xiàn)數(shù)據(jù)中心的應(yīng)用程序有著很高的延遲，這是一個(gè)沒有任何結(jié)論性日志記錄的很有挑戰(zhàn)性的問題。幾個(gè)網(wǎng)絡(luò)工程師為解決這個(gè)問題殫精竭慮，最終發(fā)現(xiàn)這是一個(gè)微爆發(fā)的問題。當(dāng)短時(shí)內(nèi)連續(xù)發(fā)送數(shù)據(jù)包，導(dǎo)致線性時(shí)間內(nèi)網(wǎng)絡(luò)數(shù)據(jù)包緩沖區(qū)溢出堆棧，就產(chǎn)生了微爆發(fā)問題。這很難檢測出來，因?yàn)榫彌_區(qū)位于不能完全由商用交換機(jī)廠商直接接觸的第三方商用芯片中。

當(dāng)我們得出引起微爆發(fā)的原因是由應(yīng)用程序的高延遲導(dǎo)致的，我們努力的尋找有效的方法來預(yù)測短時(shí)溢出，但我們越想解決這個(gè)問題，越難找出一個(gè)簡單且優(yōu)雅的解決方案。

然后，我們嘗試從不同角度看問題。假如我們有商用芯片廠商遙測的數(shù)據(jù)會有什么效果？我們購買商用芯片的廠商不向我們提供讀取/寫入遙測數(shù)據(jù)的功能。我們解決微爆發(fā)的唯一途徑是依靠我們的交換機(jī)供應(yīng)商提供解決方案，但是我們發(fā)現(xiàn)這種方式不能及時(shí)適應(yīng)我們的快節(jié)奏的環(huán)境。

我們開始關(guān)注除了商用芯片廠商遙測數(shù)據(jù)的其他挑戰(zhàn)，包括：

軟件中不能及時(shí)解決的Bug

數(shù)據(jù)中心環(huán)境中不需要的交換機(jī)軟件功能，我們還必須處理與這些功能相關(guān)的Bug

缺乏基于Linux平臺的自動化工具，如Chef/Puppet/CFEngine

過時(shí)的管理和日志記錄軟件，即缺乏對SNMP的依賴

高成本的擴(kuò)展軟件許可和支持

我們研究了由基于廠商的交換機(jī)引起的問題，我們經(jīng)常反問自身“我們理想的交換機(jī)是什么樣的？能夠?qū)崿F(xiàn)什么程度的控制？”我們對理想的交換平臺提出了以下功能：

在任何硬件平臺都能運(yùn)行我們的商用芯片

在我們應(yīng)用程序服務(wù)器上的交換平臺能夠運(yùn)行一些基礎(chǔ)設(shè)施軟件和工具，如遙測、報(bào)警、日志、安全、Kafka。

快速響應(yīng)需求和變化

推進(jìn)DevOps運(yùn)行，這樣交換機(jī)能夠像服務(wù)器一樣運(yùn)行，并且共享一個(gè)自動化操作平臺

無限的可編程選擇

功能速率

更快更好的創(chuàng)新周期

更好的控制軟硬件成本

當(dāng)我們看到理想中的交換機(jī)，我們以單一維度的視角思考微爆發(fā)/緩沖問題，控制交換機(jī)的可編程性為我們打開了實(shí)現(xiàn)可編程數(shù)據(jù)中心的大門。

在過去的兩年中，我們一直在觀察硬件和軟件領(lǐng)域崩潰的現(xiàn)象，傳統(tǒng)設(shè)備制造商（ODM）市場向任何購買其交換機(jī)的人開放其硬件，不再是著名的交換機(jī)廠商主導(dǎo)市場。這也意味著用戶可以直接與多個(gè)芯片廠商合作，并且能完全訪問芯片編程（如Trident，Trident II，Tomahawk）。

大約一年前，我們開始發(fā)展我們自己的交換平臺，以上文中提到的指導(dǎo)思想為原則，提出了我們自己的基礎(chǔ)架構(gòu)，如下圖所示

我們關(guān)注的應(yīng)用層使用的是基于服務(wù)器的工具也是現(xiàn)有Linkendln基礎(chǔ)設(shè)施的一部分，LinkedIn tools是一個(gè)管理配置和自動化的基礎(chǔ)設(shè)施自動化工具陣列。Auto-Alerts是綁定在Nurse上的檢測和報(bào)警客戶端，是一個(gè)自動修復(fù)平臺。該交換機(jī)的應(yīng)用層也能支持Kafka客戶機(jī)，Kafka是一個(gè)發(fā)布/訂閱大量指標(biāo)信息的管道系統(tǒng)，商用芯片SDK的遙測客戶機(jī)接口能夠獲得最新的緩沖數(shù)據(jù)。

Pigeon的產(chǎn)品化之路

我們在LinkedIn發(fā)布了canary版本的軟件，通過代碼改變少量的主機(jī)。canary測試的目標(biāo)是確保由代碼引起的變化都能在現(xiàn)實(shí)工作環(huán)境中生效，在基礎(chǔ)設(shè)施中也不會產(chǎn)生變化。經(jīng)過3個(gè)月的實(shí)驗(yàn)室測試，我們在孤立的環(huán)境中生產(chǎn)，并且把部署了canary的交換機(jī)在生產(chǎn)環(huán)境中測試。

該交換機(jī)的架構(gòu)是基于最新的Tomahawk 3.2 Tbps 32X100G商用芯片。

　　未來的工作

我們將持續(xù)推進(jìn)Falco項(xiàng)目的發(fā)展，我們對廠商支持的交換平臺ONIE感興趣，將接入他們的ASIC和商用芯片，借此我們可以在他們的硬件平臺上運(yùn)行我們的應(yīng)用軟件平臺。交換抽象接口（SAI）也是我們發(fā)展的規(guī)劃之一。

后記

Pigeon是基于LinkedIn的PEO工作組開展的Falco項(xiàng)目，特別感謝Shawn Zandi，Saikrishna Kotha，James Ling，Sujatha Madhavan，Navneet Nigori，Yuval Bachar以及項(xiàng)目經(jīng)理Vish Shetty，F(xiàn)abio Parodi。

注：編譯類僅出于傳遞更多信息之目的，系SDNLAB對海外相關(guān)站點(diǎn)最新信息的翻譯稿，僅供參考，不代表證實(shí)其描述或贊同其觀點(diǎn)，投資者據(jù)此操作，風(fēng)險(xiǎn)自擔(dān)；翻譯質(zhì)量問題請指正。