從個人的角度談談本次GNTC大會的收穫

2021-09-08 19:46:12 字數 4249 閱讀 2329

從本次大會的主題演講來看,目前sdn、nfv的最前沿已經不再像五年前持觀望態度以及**,各大運營商、各大廠商已經將sdn、nfv具體應用到了實體的網路部署。

本次大會緊密圍繞三個主題:sdn、nfv、雲計算。

無論是各大運營商的中心骨幹網路架構抑或是廠商的具體落地解決方案,都離不開這三大前沿的核心技術,分享了無數的架構圖,以及無數的廠商意見。

對於我而言,最能吸引我的演講主要有以下幾個:

1.王景頗:新華三的新網路視角與探索

4.趙慧玲:網路重構及其挑戰

5.p4 workshop

(1)運營商全面進入流量運營時代,流量 + 雲服務 > 語音收入

-> 要求運營商 更低成本、高效率策略

(2)萬物互聯 -> 個人需求定製化,差異化服務 -> 靈活多變的服務能力

兩個背景 + 技術不斷發展 + 從整個網路發展的角度進行考量 + rt、ct不斷融合,開源和標準不斷交織 -> 網路重構,打造新的網路生態圈

最終目的:網路的發展適配業務的發展。

運營商 -> 側重運營 -> 側重網路資源排程、業務資源編排

目的:1.協同編排 2.資源隨選有效 3.自動化、按需(差異性服務) 4.靈活 5.敏捷

未來發展:網路發展適配業務發展

1.採用廉價的硬體和x86伺服器實現虛擬化

2.雲資料中心化,一體化編排資源

3.功能重構、資源池化,以適配業務發展

發展中的三大基本要求:

1.高效率運營

2.低成本運維

3.靈活的業務提供

大資料高效運營 + 自動化運維排程 -> 實現全域性資源的統一協調

因此各大運營商提出了基於sdn、nfv技術的網路架構、雲資料中心的轉型:中國電信、中國聯通,中國移動 etc.

在運營這塊,我們面臨網路資源和業務資源的編排,網路資源涉及到整個oss的演進,涉及到我們將來是不是能夠進行全網資源配置的快速根據業務需求的資源配置。在業務層面,如果你做整個業務資源的編排的話,實際上我們要做業務屬性的抽象,同時要做到端到端業務跨域編排。所以,這樣的一些挑戰實際上需要我們整個產業鏈各個環節的共同努力,來推動整體產業向前發展。

目前技術層面的挑戰,需要未來解決:

sdn -> 開放性、opensource + 控制器

nfv -> 多維解耦,提公升效能

從發展i層(infrastructure)到發展o層(orchestrator)業務編排器,如open-o -> 以實現靈活的業務編排排程

角度:產業界對於應用及業務細化的解決方案,側重於應用角度。

1.在應用層面,是否有動力推動新技術的發展?

從業務維度看網路的驅動力,業務層面是不是能給我帶來價值,這是我最重要的乙個思考。實際上就是說從應用來講,是不是有動力推動新技術、新網路在it建設中的乙個使用和發展。

驅動力:傳統網路無法解決的問題、無法適配業務發展 -> 基於sdn、nfv等網路技術革新網路架構,業務推動技術發展

2.網路解決方案中的軟體趨勢路線圖

軟體的趨勢路線圖,新華三在新網路裡面是軟硬結合的,也有一種觀點是純軟體的。在這裡,大家有不同的觀點、不同的看法。作為乙個業務決策者,我怎麼去思考這個問題?也是提出了乙個問題,比如在運營商,它的技術實力非常強,它會自己規劃出乙個趨勢路線圖,還有一些比如作為企業網、園區網,有一些技術實力差一些的,或者沒有對於整網的業務規劃能力,它又怎麼思考未來的技術趨勢?

3.開放性的標準化和後續相容的問題

以sdn為例,不同的組織有不同的標準,其實沒有完全統一,最後這個問題更多的是留給學術界、產業界,包括在座各位共同思考的乙個問題,如何標準統一,如何給客戶帶來價值。

角度一:三大生態

1.接入端。

在新網路生態不是乙個廠家能夠完成的,一定是多個廠家不同的接入終端,包括移動的接入,包括物聯網的接入,在接入級要形成乙個生態圈。

2.網路連線層:it、ct融合類的生態。

3.核心的業務驅動網路中樞,新網路統一控制器的聯盟。

角度2:三大陣營

1.使用者(以三大運營商為代表)

2.廠商(以h3c為代表)

3.學術界(中科院為代表)

通過三個陣營,使用者、廠商、組織共建新的it產業聯盟,依託全產業資源架構,推動形成資源中介軟體,南北向協議標準,打造開放合作共贏的新生態圈。這是從學術界、產業界以及使用者三個維度打造新的生態圈。

對於我個人而言,本次大會的最重要的便是在p4 workshop,很榮幸和p4主席kim changhoon合了影~(唯一較為遺憾的是沒有拿到p4的t-shirt)。

首先介紹fpga的提出者賽靈思對於p4的思考:王立峰:賽靈思fpga上的p4

在編譯的時候,我才告訴編譯器要實現的細節。比如,網路頻寬是多少,是1g,還是200g;或者需要延遲多少;設計是針對資源優化,還是針對可程式設計性進行優化。···通過賽靈思的載入檔案載入到fpga,同時通過firmware更新生成乙個完整的邏輯。

在p4提出以後,賽靈思公司將p4和sdnet相結合:p4語言 -> 前端編譯器hilr -> 高階中間表示 -> 賽靈思公司提供的高階中間表示 -> sdnet -> 底層fpga.

此外,賽靈思公司對目前如何將p4應用到不同specific target的應用場景中進行了說明:

p4有乙個重要的概念,它的語法和它的架構是可以分離的。這是p4.org寫的p4的標準架構、標準語法,也有它自己的庫。同時,各個target開發者也會提供自己平台相關的特有架構的表示,平台也有自己的庫。在這種情況下,作為在目標平台上的p4使用者,首先會做一些架構級別的選擇,哪些部分是從p4.org通用的架構。他也會考慮一部分架構沒有被p4.org覆蓋,他會用平台相關的特性來進行編寫;同時,他在寫p4程式的時候,會呼叫標準的p4的庫,也可能會使用與平台相關的自定義的功能;同時,作為開發者,他可能也有自己的用p4語言寫的庫。這些庫可能是跨平台的,也可能是針對某些特定平台有特定優化的。通過這三種的結合,再經過編譯器,就會生成api和和對應的**平台**。

同時,還有其他一些模組,因為p4只定義了中間的部分,邊上的資料是怎麼進來的、怎麼出去,它有一些和平台相關的,是100g的乙太網口,還是10g的乙太網口,這是完全不一樣的。還可能需要端到端的延遲處理能力,它是毫秒級別,還是納秒級別,處理也是不一樣的。也就是我用乙個通用的結構來表示這個東西存在,在具體的例項中還有一些很細節的部分。比如,輸入、輸出、乙太網的mac、su***ce的配置,這些可能是固定的,你不會考慮太多的現場可程式設計性的部分是與你的target平台相關的,這些部分是要根據平台來進行處理的。這些部分就屬於p4.org定義之外的東西,但你在實現當中可以考慮。

也就是說,大體的架構可以採用p4.org提供的common model,但是在架構細節中,比如一些庫,埠處理速度等平台特定的東西和細節,是平台相關的,就可以結合平台的東西來做。這也體現了p4語言的平台無關性。

kim changhoon講了p4具體的sample,乙個dc內部cluster的互通:

跑了乙個dc的sample,執行大流量,發現有乙個hash polarizations雜湊極化的問題,再通過p4來解決這個問題。

關於資料中心內部hash極化:【鵝廠網事】資料中心網路中的hash問題研究

以及int(in‐band network telemetry),對於int之前不是特別了解,在kim介紹之後才深刻體會到這個功能的強大之處。

繼續前行!繼續加油!

2016/12/10

從運維角度談談故障定位 未完

一般剛畢業不久的會回答 我們有監控 看日誌等之類的答案。工作幾年的人會回答 從網路,機器,資源等方面排查有沒有問題,如果沒有問題,再看看日誌,找開發核對。也有人回答這個是開發的問題,我們運維還沒有精確到業務層面。運維人員進行故障定位時,遇到主要問題 1 業務掌握深入程度有限。不像某個應用的開發那樣,...

從記憶體布局角度談談值型別和引用型別!

深入理解值型別和引用型別,這是.net開發人員取得長期成功的關鍵,下面從記憶體布局角度詳細給大家說明一下值型別和引用型別 值型別的記憶體結構 引用型別的記憶體結構 引用型別的例項比值型別的例項多了兩個附加的字段,syncblockindex和rtti 執行時型別資訊 指標,指向乙個方法表結構,所以描...

換個角度談談學習的過程

學東西這事絕對是件功夫活,也絕對是條漫長路,因為當你決定踏上一條求學之路時,你可能對其充滿了朦朧的嚮往,而當你已經上路一段日子後,你可能又會感到到處都是自己不知道的東東,頂著頭皮再走一段日子,你可能會感到稍微有了一點點自信的安慰,因為你已經對一些基本的東東有了理解,以前很多的高深的東東也開始慢慢褪去...