精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

當前位置:數據網絡企業動態 → 正文

Falco項目:將交換機軟硬件去耦合

責任編輯:editor005 作者:崔佰貴 |來源:企業網D1Net  2016-06-28 15:17:58 本文摘自:SDNLAB

三年前我們的數據中心的應用程序面臨著一個潛在的嚴重問題,我們沒有根據應用程序的需求對網絡基礎設施進行縮放,這些需求包括高速、高可用性以及快速部署。我們需要在網絡層更好的控制功能,但我們在實現該目標的時候面臨著障礙。

生產工程運營團隊(Production Engineering Operations team,PEO)發現很難滿足我們對應用程序的需求,尤其是網絡中的路由器和交換機由廠商控制特性并修復Bug。一年以前我們發起了一個叫做Falco的項目,專注于對網絡中的軟硬件進行解耦。Falco工作組花了11520個小時研發我們的第一款網絡交換機Pigeon,該交換機能夠兼容這種控制。Pigeon將部署在我們位于Oregon的新一代大規模數據中心。

Pigeon是一個3.2 Tbps交換平臺,可以作為leaf switch或者spine switch來使用。Pigeon是我們在交換機領域首次涉及軟件研發,我們不會冒險研發我們自己的交換機,因為我們更希望成為交換機和路由領域的專家。我們將持續支持商業廠商,并與他們在解耦模型中持續合作。

研發交換平臺的歷程

軟件工程團隊發現的問題引起了PEO團隊的注意,這兩個團隊發現數據中心的應用程序有著很高的延遲,這是一個沒有任何結論性日志記錄的很有挑戰性的問題。幾個網絡工程師為解決這個問題殫精竭慮,最終發現這是一個微爆發的問題。當短時內連續發送數據包,導致線性時間內網絡數據包緩沖區溢出堆棧,就產生了微爆發問題。這很難檢測出來,因為緩沖區位于不能完全由商用交換機廠商直接接觸的第三方商用芯片中。

當我們得出引起微爆發的原因是由應用程序的高延遲導致的,我們努力的尋找有效的方法來預測短時溢出,但我們越想解決這個問題,越難找出一個簡單且優雅的解決方案。

然后,我們嘗試從不同角度看問題。假如我們有商用芯片廠商遙測的數據會有什么效果?我們購買商用芯片的廠商不向我們提供讀取/寫入遙測數據的功能。我們解決微爆發的唯一途徑是依靠我們的交換機供應商提供解決方案,但是我們發現這種方式不能及時適應我們的快節奏的環境。

我們開始關注除了商用芯片廠商遙測數據的其他挑戰,包括:

軟件中不能及時解決的Bug

數據中心環境中不需要的交換機軟件功能,我們還必須處理與這些功能相關的Bug

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

過時的管理和日志記錄軟件,即缺乏對SNMP的依賴

高成本的擴展軟件許可和支持

我們研究了由基于廠商的交換機引起的問題,我們經常反問自身“我們理想的交換機是什么樣的?能夠實現什么程度的控制?”我們對理想的交換平臺提出了以下功能:

在任何硬件平臺都能運行我們的商用芯片

在我們應用程序服務器上的交換平臺能夠運行一些基礎設施軟件和工具,如遙測、報警、日志、安全、Kafka。

快速響應需求和變化

推進DevOps運行,這樣交換機能夠像服務器一樣運行,并且共享一個自動化操作平臺

無限的可編程選擇

功能速率

更快更好的創新周期

更好的控制軟硬件成本

當我們看到理想中的交換機,我們以單一維度的視角思考微爆發/緩沖問題,控制交換機的可編程性為我們打開了實現可編程數據中心的大門。

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

大約一年前,我們開始發展我們自己的交換平臺,以上文中提到的指導思想為原則,提出了我們自己的基礎架構,如下圖所示

我們關注的應用層使用的是基于服務器的工具也是現有Linkendln基礎設施的一部分,LinkedIn tools是一個管理配置和自動化的基礎設施自動化工具陣列。Auto-Alerts是綁定在Nurse上的檢測和報警客戶端,是一個自動修復平臺。該交換機的應用層也能支持Kafka客戶機,Kafka是一個發布/訂閱大量指標信息的管道系統,商用芯片SDK的遙測客戶機接口能夠獲得最新的緩沖數據。

Pigeon的產品化之路

我們在LinkedIn發布了canary版本的軟件,通過代碼改變少量的主機。canary測試的目標是確保由代碼引起的變化都能在現實工作環境中生效,在基礎設施中也不會產生變化。經過3個月的實驗室測試,我們在孤立的環境中生產,并且把部署了canary的交換機在生產環境中測試。

該交換機的架構是基于最新的Tomahawk 3.2 Tbps 32X100G商用芯片。

  未來的工作

我們將持續推進Falco項目的發展,我們對廠商支持的交換平臺ONIE感興趣,將接入他們的ASIC和商用芯片,借此我們可以在他們的硬件平臺上運行我們的應用軟件平臺。交換抽象接口(SAI)也是我們發展的規劃之一。

后記

Pigeon是基于LinkedIn的PEO工作組開展的Falco項目,特別感謝Shawn Zandi,Saikrishna Kotha,James Ling,Sujatha Madhavan,Navneet Nigori,Yuval Bachar以及項目經理Vish Shetty,Fabio Parodi。

注:編譯類僅出于傳遞更多信息之目的,系SDNLAB對海外相關站點最新信息的翻譯稿,僅供參考,不代表證實其描述或贊同其觀點,投資者據此操作,風險自擔;翻譯質量問題請指正。

關鍵字:去耦合Falco

本文摘自:SDNLAB

x Falco項目:將交換機軟硬件去耦合 掃一掃
分享本文到朋友圈
當前位置:數據網絡企業動態 → 正文

Falco項目:將交換機軟硬件去耦合

責任編輯:editor005 作者:崔佰貴 |來源:企業網D1Net  2016-06-28 15:17:58 本文摘自:SDNLAB

三年前我們的數據中心的應用程序面臨著一個潛在的嚴重問題,我們沒有根據應用程序的需求對網絡基礎設施進行縮放,這些需求包括高速、高可用性以及快速部署。我們需要在網絡層更好的控制功能,但我們在實現該目標的時候面臨著障礙。

生產工程運營團隊(Production Engineering Operations team,PEO)發現很難滿足我們對應用程序的需求,尤其是網絡中的路由器和交換機由廠商控制特性并修復Bug。一年以前我們發起了一個叫做Falco的項目,專注于對網絡中的軟硬件進行解耦。Falco工作組花了11520個小時研發我們的第一款網絡交換機Pigeon,該交換機能夠兼容這種控制。Pigeon將部署在我們位于Oregon的新一代大規模數據中心。

Pigeon是一個3.2 Tbps交換平臺,可以作為leaf switch或者spine switch來使用。Pigeon是我們在交換機領域首次涉及軟件研發,我們不會冒險研發我們自己的交換機,因為我們更希望成為交換機和路由領域的專家。我們將持續支持商業廠商,并與他們在解耦模型中持續合作。

研發交換平臺的歷程

軟件工程團隊發現的問題引起了PEO團隊的注意,這兩個團隊發現數據中心的應用程序有著很高的延遲,這是一個沒有任何結論性日志記錄的很有挑戰性的問題。幾個網絡工程師為解決這個問題殫精竭慮,最終發現這是一個微爆發的問題。當短時內連續發送數據包,導致線性時間內網絡數據包緩沖區溢出堆棧,就產生了微爆發問題。這很難檢測出來,因為緩沖區位于不能完全由商用交換機廠商直接接觸的第三方商用芯片中。

當我們得出引起微爆發的原因是由應用程序的高延遲導致的,我們努力的尋找有效的方法來預測短時溢出,但我們越想解決這個問題,越難找出一個簡單且優雅的解決方案。

然后,我們嘗試從不同角度看問題。假如我們有商用芯片廠商遙測的數據會有什么效果?我們購買商用芯片的廠商不向我們提供讀取/寫入遙測數據的功能。我們解決微爆發的唯一途徑是依靠我們的交換機供應商提供解決方案,但是我們發現這種方式不能及時適應我們的快節奏的環境。

我們開始關注除了商用芯片廠商遙測數據的其他挑戰,包括:

軟件中不能及時解決的Bug

數據中心環境中不需要的交換機軟件功能,我們還必須處理與這些功能相關的Bug

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

過時的管理和日志記錄軟件,即缺乏對SNMP的依賴

高成本的擴展軟件許可和支持

我們研究了由基于廠商的交換機引起的問題,我們經常反問自身“我們理想的交換機是什么樣的?能夠實現什么程度的控制?”我們對理想的交換平臺提出了以下功能:

在任何硬件平臺都能運行我們的商用芯片

在我們應用程序服務器上的交換平臺能夠運行一些基礎設施軟件和工具,如遙測、報警、日志、安全、Kafka。

快速響應需求和變化

推進DevOps運行,這樣交換機能夠像服務器一樣運行,并且共享一個自動化操作平臺

無限的可編程選擇

功能速率

更快更好的創新周期

更好的控制軟硬件成本

當我們看到理想中的交換機,我們以單一維度的視角思考微爆發/緩沖問題,控制交換機的可編程性為我們打開了實現可編程數據中心的大門。

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

大約一年前,我們開始發展我們自己的交換平臺,以上文中提到的指導思想為原則,提出了我們自己的基礎架構,如下圖所示

我們關注的應用層使用的是基于服務器的工具也是現有Linkendln基礎設施的一部分,LinkedIn tools是一個管理配置和自動化的基礎設施自動化工具陣列。Auto-Alerts是綁定在Nurse上的檢測和報警客戶端,是一個自動修復平臺。該交換機的應用層也能支持Kafka客戶機,Kafka是一個發布/訂閱大量指標信息的管道系統,商用芯片SDK的遙測客戶機接口能夠獲得最新的緩沖數據。

Pigeon的產品化之路

我們在LinkedIn發布了canary版本的軟件,通過代碼改變少量的主機。canary測試的目標是確保由代碼引起的變化都能在現實工作環境中生效,在基礎設施中也不會產生變化。經過3個月的實驗室測試,我們在孤立的環境中生產,并且把部署了canary的交換機在生產環境中測試。

該交換機的架構是基于最新的Tomahawk 3.2 Tbps 32X100G商用芯片。

  未來的工作

我們將持續推進Falco項目的發展,我們對廠商支持的交換平臺ONIE感興趣,將接入他們的ASIC和商用芯片,借此我們可以在他們的硬件平臺上運行我們的應用軟件平臺。交換抽象接口(SAI)也是我們發展的規劃之一。

后記

Pigeon是基于LinkedIn的PEO工作組開展的Falco項目,特別感謝Shawn Zandi,Saikrishna Kotha,James Ling,Sujatha Madhavan,Navneet Nigori,Yuval Bachar以及項目經理Vish Shetty,Fabio Parodi。

注:編譯類僅出于傳遞更多信息之目的,系SDNLAB對海外相關站點最新信息的翻譯稿,僅供參考,不代表證實其描述或贊同其觀點,投資者據此操作,風險自擔;翻譯質量問題請指正。

關鍵字:去耦合Falco

本文摘自:SDNLAB

電子周刊
回到頂部

關于我們聯系我們版權聲明隱私條款廣告服務友情鏈接投稿中心招賢納士

企業網版權所有 ©2010-2024 京ICP備09108050號-6 京公網安備 11010502049343號

^
  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 宝清县| 浦北县| 泰兴市| 黔西县| 阿瓦提县| 长丰县| 普宁市| 武汉市| 莱州市| 永泰县| 临西县| 钟山县| 灵璧县| 汉中市| 宁津县| 广南县| 铁岭县| 平阴县| 呼和浩特市| 申扎县| 平阳县| 湘乡市| 永靖县| 凤山市| 五台县| 集安市| 普兰店市| 新蔡县| 寿宁县| 石狮市| 永兴县| 许昌市| 晋州市| 巴马| 民乐县| 丹江口市| 奎屯市| 西贡区| 乌审旗| 宝清县| 冀州市|