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

當前位置:數(shù)據(jù)中心技術(shù)專區(qū) → 正文

數(shù)據(jù)中心網(wǎng)絡(luò)運維可視化新技術(shù)漫談

責任編輯:cres 作者:harbor |來源:企業(yè)網(wǎng)D1Net  2018-05-10 13:08:27 原創(chuàng)文章 企業(yè)網(wǎng)D1Net

網(wǎng)絡(luò)運維一直倡導(dǎo)要可視化,并且在實踐中不斷優(yōu)化,怎耐可視化的技術(shù)寥寥無幾,網(wǎng)絡(luò)技術(shù)經(jīng)過了五十年的演進變化,可視化依然要依托SNMP、鏡像這些老技術(shù)。SNMP能監(jiān)控到網(wǎng)絡(luò)的運行信息實在有限,從外部應(yīng)用發(fā)起的請求獲取網(wǎng)絡(luò)狀態(tài)信息的SNMP協(xié)議,無法實時反映網(wǎng)絡(luò)的狀態(tài)。比如:時延、轉(zhuǎn)發(fā)路徑、緩存和丟包,這些都無法通過SNMP獲知,網(wǎng)絡(luò)對運維的人員來講,就是一個黑盒子,傳統(tǒng)的監(jiān)控手段無法看透黑盒子。所以,長期以來網(wǎng)絡(luò)運維的可視化算不上真正的可視化,那些通過大屏將端口流量、設(shè)備CPU、Memory等運行狀態(tài)顯示出來只不過是可視化的一部分,網(wǎng)絡(luò)真實的運行狀態(tài)還未能顯現(xiàn)出來。最近,網(wǎng)絡(luò)可視化還真出現(xiàn)不少新技術(shù),頗為引人注目,也許是未來網(wǎng)絡(luò)運維的技術(shù)演進方向,本文接下來就詳細講講。
 
Sflow(RFC3176)
 
Sflow其實算不上新技術(shù),這幾年幾乎已經(jīng)所有的網(wǎng)絡(luò)設(shè)備都能支持。Sflow實現(xiàn)了網(wǎng)絡(luò)流量的采樣和推送,通過Sflow采集最原始的數(shù)據(jù)信息,以IP報文格式的形式發(fā)往服務(wù)器,由專門的分析工具解析,然后根據(jù)這些采集的數(shù)據(jù)進行統(tǒng)計分析。Sflow是采樣方式收集數(shù)據(jù),采樣比越高獲取的數(shù)據(jù)越真實,但采樣比越高,設(shè)備CPU壓力就越大。Sflow采樣報文是經(jīng)過網(wǎng)絡(luò)設(shè)備CPU收集,然后再發(fā)向服務(wù)器的,采集的數(shù)據(jù)太多,會對網(wǎng)絡(luò)設(shè)備CPU形成攻擊,可能影響設(shè)備的正常協(xié)議處理,影響業(yè)務(wù)。所以,要謹慎使用Sflow,即便使用也要根據(jù)設(shè)備流量大小,確認好采樣比。Sflow使用的局限性讓人想到用硬件實現(xiàn)數(shù)據(jù)采集,比如FPGA、Netstream硬件設(shè)備,這樣采集數(shù)據(jù)性能雖會有很大提升,但運維的投入成本(購入支持FPGA的板卡或Netstream硬件設(shè)備)會上去。另一方面,網(wǎng)絡(luò)設(shè)備的CPU、Memory、網(wǎng)絡(luò)擁塞和網(wǎng)絡(luò)事件的日志信息也無法通過Sflow實時傳遞出來。所以,Sflow技術(shù)一直不溫不火,并未得到絕大多數(shù)人的認可,使用時還要配合著SNMP來用,一個網(wǎng)絡(luò)中要部署多個監(jiān)控系統(tǒng),可視化看到的都是部分網(wǎng)絡(luò),并非全部。
 
gRPC(Google Remote Procedure Calls,谷歌遠程過程調(diào)用)
 
網(wǎng)絡(luò)運維在可視化上的窘態(tài)引起了互聯(lián)網(wǎng)技術(shù)人員的注意,谷歌發(fā)布了一個開源的RPC框架,RPC定義了客戶端和服務(wù)端進行通信的數(shù)據(jù)結(jié)構(gòu),服務(wù)端提供的服務(wù)等,然后編譯生成相應(yīng)的代碼供客戶端和服務(wù)端使用,gRPC是RPC框架正式的實現(xiàn)版本,在2015年初開源的通信框架。gRPC采用了protocol buffer來做數(shù)據(jù)的序列化與反序列化,用http 2作為數(shù)據(jù)傳輸協(xié)議,性能更優(yōu)。在網(wǎng)絡(luò)設(shè)備上集成gRPC應(yīng)用,網(wǎng)絡(luò)設(shè)備就相當于gRPC客戶端角色,監(jiān)控服務(wù)器相當于gRPC服務(wù)器角色,網(wǎng)絡(luò)設(shè)備主動向監(jiān)控服務(wù)器發(fā)起gRPC通道建立和連接。gRPC可以靈活定義數(shù)據(jù)格式和數(shù)據(jù)推送的閾值,從而實現(xiàn)網(wǎng)絡(luò)設(shè)備自身運行狀態(tài)的主動推送數(shù)據(jù)能力,實現(xiàn)周期性推送網(wǎng)絡(luò)設(shè)備豐富的運行狀態(tài),尤其當發(fā)生緩存不足導(dǎo)致的丟包時,也會實時通知給監(jiān)控服務(wù)器,實現(xiàn)網(wǎng)絡(luò)運行數(shù)據(jù)的可視化。表1列舉了gRPC與傳統(tǒng)可視化技術(shù)的對比:
 
 
 
顯然,gRPC具有響應(yīng)速度快,實時性高,采集數(shù)據(jù)全面的優(yōu)點。
 
INT(In-band Network Telemetry帶內(nèi)網(wǎng)絡(luò)遙測)
 
INT是由Barefoot、Arista、Dell、Intel和VMWARE共同提出的技術(shù)。INT是被設(shè)計用來收集和報告網(wǎng)絡(luò)狀態(tài)的一個框架,它通過數(shù)據(jù)平面實現(xiàn),不需要控制平面的干涉,F(xiàn)acebook根據(jù)這個協(xié)議和相應(yīng)廠商的網(wǎng)絡(luò)設(shè)備設(shè)計了一套系統(tǒng),未來可能會開源。INT的思想是在第一跳的網(wǎng)絡(luò)設(shè)備上收到相應(yīng)報文,對其進行封裝特定報文,然后扔給下一跳,直到最后一跳網(wǎng)絡(luò)設(shè)備,每一跳網(wǎng)絡(luò)設(shè)備都會收集相應(yīng)的信息,封在報文里面。最后,在最后一跳網(wǎng)絡(luò)設(shè)備剝離報文里面收集到的信息,然后把原始報文扔給服務(wù)器,收集到的網(wǎng)絡(luò)設(shè)備信息扔給監(jiān)控端處理。這樣即不影響正常業(yè)務(wù)轉(zhuǎn)發(fā),又能收集到經(jīng)過網(wǎng)絡(luò)設(shè)備的信息,在黑盒不知道網(wǎng)絡(luò)拓撲的情況下還能探測出網(wǎng)絡(luò)拓撲。初步協(xié)議給定的有:交換機ID、入端口信息、入端口時間戳、出端口ID、出端口時間戳、出端口鏈路利用率,緩存信息。INT是一個類似OAM的協(xié)議,INT根據(jù)沿路設(shè)備的信息,就能夠知道報文怎么走的,哪里有性能瓶頸,解決了網(wǎng)絡(luò)轉(zhuǎn)發(fā)路徑和轉(zhuǎn)發(fā)時延不可見的問題。要注意的是:“INT推薦在數(shù)據(jù)面處理,不推薦控制面處理以體現(xiàn)真實情況。”利用INT技術(shù)能很快定位網(wǎng)絡(luò)丟包和延遲問題,通過軟件打標記是無法實現(xiàn)INT的高效處理的,必須需要網(wǎng)絡(luò)設(shè)備硬件支持。
 
網(wǎng)絡(luò)運維的可視化還有很長的路要走,sflow、gRPC、INT等都是可視化具體實現(xiàn)技術(shù),尤其gRPC和INT技術(shù)還沒有得到廣泛使用,現(xiàn)有數(shù)據(jù)中心的絕大部分設(shè)備還無法支持這種新技術(shù),網(wǎng)絡(luò)設(shè)備的更新?lián)Q代需要數(shù)年時間,所以這些新技術(shù)只有在新建的數(shù)據(jù)中心網(wǎng)絡(luò)中才能有機會出現(xiàn),能支持INT功能的網(wǎng)絡(luò)設(shè)備必然具有芯片自編程能力,這對網(wǎng)絡(luò)設(shè)備提出了更高要求。除了以上介紹的這三種可視化技術(shù),還有微軟在2015年提出的Pingmesh技術(shù),以及依然是微軟在2015年提出的Everflow技術(shù),還有Netsight(具體采用的Openflow協(xié)議)、ATPG、Planck等等,這些都是這兩年出現(xiàn)的可視化技術(shù),雖然沒有g(shù)RPC、INT影響力大,但技術(shù)也在不斷完善中,未來也不好說哪些技術(shù)一定能勝出,哪些技術(shù)會直接淘汰,去讓時間證明一切吧。
 
版權(quán)聲明:本文為企業(yè)網(wǎng)D1Net原創(chuàng),轉(zhuǎn)載需注明出處為:企業(yè)網(wǎng)D1Net,如果不注明出處,企業(yè)網(wǎng)D1Net將保留追究其法律責任的權(quán)利。

關(guān)鍵字:數(shù)據(jù)中心

原創(chuàng)文章 企業(yè)網(wǎng)D1Net

x 數(shù)據(jù)中心網(wǎng)絡(luò)運維可視化新技術(shù)漫談 掃一掃
分享本文到朋友圈
當前位置:數(shù)據(jù)中心技術(shù)專區(qū) → 正文

數(shù)據(jù)中心網(wǎng)絡(luò)運維可視化新技術(shù)漫談

責任編輯:cres 作者:harbor |來源:企業(yè)網(wǎng)D1Net  2018-05-10 13:08:27 原創(chuàng)文章 企業(yè)網(wǎng)D1Net

網(wǎng)絡(luò)運維一直倡導(dǎo)要可視化,并且在實踐中不斷優(yōu)化,怎耐可視化的技術(shù)寥寥無幾,網(wǎng)絡(luò)技術(shù)經(jīng)過了五十年的演進變化,可視化依然要依托SNMP、鏡像這些老技術(shù)。SNMP能監(jiān)控到網(wǎng)絡(luò)的運行信息實在有限,從外部應(yīng)用發(fā)起的請求獲取網(wǎng)絡(luò)狀態(tài)信息的SNMP協(xié)議,無法實時反映網(wǎng)絡(luò)的狀態(tài)。比如:時延、轉(zhuǎn)發(fā)路徑、緩存和丟包,這些都無法通過SNMP獲知,網(wǎng)絡(luò)對運維的人員來講,就是一個黑盒子,傳統(tǒng)的監(jiān)控手段無法看透黑盒子。所以,長期以來網(wǎng)絡(luò)運維的可視化算不上真正的可視化,那些通過大屏將端口流量、設(shè)備CPU、Memory等運行狀態(tài)顯示出來只不過是可視化的一部分,網(wǎng)絡(luò)真實的運行狀態(tài)還未能顯現(xiàn)出來。最近,網(wǎng)絡(luò)可視化還真出現(xiàn)不少新技術(shù),頗為引人注目,也許是未來網(wǎng)絡(luò)運維的技術(shù)演進方向,本文接下來就詳細講講。
 
Sflow(RFC3176)
 
Sflow其實算不上新技術(shù),這幾年幾乎已經(jīng)所有的網(wǎng)絡(luò)設(shè)備都能支持。Sflow實現(xiàn)了網(wǎng)絡(luò)流量的采樣和推送,通過Sflow采集最原始的數(shù)據(jù)信息,以IP報文格式的形式發(fā)往服務(wù)器,由專門的分析工具解析,然后根據(jù)這些采集的數(shù)據(jù)進行統(tǒng)計分析。Sflow是采樣方式收集數(shù)據(jù),采樣比越高獲取的數(shù)據(jù)越真實,但采樣比越高,設(shè)備CPU壓力就越大。Sflow采樣報文是經(jīng)過網(wǎng)絡(luò)設(shè)備CPU收集,然后再發(fā)向服務(wù)器的,采集的數(shù)據(jù)太多,會對網(wǎng)絡(luò)設(shè)備CPU形成攻擊,可能影響設(shè)備的正常協(xié)議處理,影響業(yè)務(wù)。所以,要謹慎使用Sflow,即便使用也要根據(jù)設(shè)備流量大小,確認好采樣比。Sflow使用的局限性讓人想到用硬件實現(xiàn)數(shù)據(jù)采集,比如FPGA、Netstream硬件設(shè)備,這樣采集數(shù)據(jù)性能雖會有很大提升,但運維的投入成本(購入支持FPGA的板卡或Netstream硬件設(shè)備)會上去。另一方面,網(wǎng)絡(luò)設(shè)備的CPU、Memory、網(wǎng)絡(luò)擁塞和網(wǎng)絡(luò)事件的日志信息也無法通過Sflow實時傳遞出來。所以,Sflow技術(shù)一直不溫不火,并未得到絕大多數(shù)人的認可,使用時還要配合著SNMP來用,一個網(wǎng)絡(luò)中要部署多個監(jiān)控系統(tǒng),可視化看到的都是部分網(wǎng)絡(luò),并非全部。
 
gRPC(Google Remote Procedure Calls,谷歌遠程過程調(diào)用)
 
網(wǎng)絡(luò)運維在可視化上的窘態(tài)引起了互聯(lián)網(wǎng)技術(shù)人員的注意,谷歌發(fā)布了一個開源的RPC框架,RPC定義了客戶端和服務(wù)端進行通信的數(shù)據(jù)結(jié)構(gòu),服務(wù)端提供的服務(wù)等,然后編譯生成相應(yīng)的代碼供客戶端和服務(wù)端使用,gRPC是RPC框架正式的實現(xiàn)版本,在2015年初開源的通信框架。gRPC采用了protocol buffer來做數(shù)據(jù)的序列化與反序列化,用http 2作為數(shù)據(jù)傳輸協(xié)議,性能更優(yōu)。在網(wǎng)絡(luò)設(shè)備上集成gRPC應(yīng)用,網(wǎng)絡(luò)設(shè)備就相當于gRPC客戶端角色,監(jiān)控服務(wù)器相當于gRPC服務(wù)器角色,網(wǎng)絡(luò)設(shè)備主動向監(jiān)控服務(wù)器發(fā)起gRPC通道建立和連接。gRPC可以靈活定義數(shù)據(jù)格式和數(shù)據(jù)推送的閾值,從而實現(xiàn)網(wǎng)絡(luò)設(shè)備自身運行狀態(tài)的主動推送數(shù)據(jù)能力,實現(xiàn)周期性推送網(wǎng)絡(luò)設(shè)備豐富的運行狀態(tài),尤其當發(fā)生緩存不足導(dǎo)致的丟包時,也會實時通知給監(jiān)控服務(wù)器,實現(xiàn)網(wǎng)絡(luò)運行數(shù)據(jù)的可視化。表1列舉了gRPC與傳統(tǒng)可視化技術(shù)的對比:
 
 
 
顯然,gRPC具有響應(yīng)速度快,實時性高,采集數(shù)據(jù)全面的優(yōu)點。
 
INT(In-band Network Telemetry帶內(nèi)網(wǎng)絡(luò)遙測)
 
INT是由Barefoot、Arista、Dell、Intel和VMWARE共同提出的技術(shù)。INT是被設(shè)計用來收集和報告網(wǎng)絡(luò)狀態(tài)的一個框架,它通過數(shù)據(jù)平面實現(xiàn),不需要控制平面的干涉,F(xiàn)acebook根據(jù)這個協(xié)議和相應(yīng)廠商的網(wǎng)絡(luò)設(shè)備設(shè)計了一套系統(tǒng),未來可能會開源。INT的思想是在第一跳的網(wǎng)絡(luò)設(shè)備上收到相應(yīng)報文,對其進行封裝特定報文,然后扔給下一跳,直到最后一跳網(wǎng)絡(luò)設(shè)備,每一跳網(wǎng)絡(luò)設(shè)備都會收集相應(yīng)的信息,封在報文里面。最后,在最后一跳網(wǎng)絡(luò)設(shè)備剝離報文里面收集到的信息,然后把原始報文扔給服務(wù)器,收集到的網(wǎng)絡(luò)設(shè)備信息扔給監(jiān)控端處理。這樣即不影響正常業(yè)務(wù)轉(zhuǎn)發(fā),又能收集到經(jīng)過網(wǎng)絡(luò)設(shè)備的信息,在黑盒不知道網(wǎng)絡(luò)拓撲的情況下還能探測出網(wǎng)絡(luò)拓撲。初步協(xié)議給定的有:交換機ID、入端口信息、入端口時間戳、出端口ID、出端口時間戳、出端口鏈路利用率,緩存信息。INT是一個類似OAM的協(xié)議,INT根據(jù)沿路設(shè)備的信息,就能夠知道報文怎么走的,哪里有性能瓶頸,解決了網(wǎng)絡(luò)轉(zhuǎn)發(fā)路徑和轉(zhuǎn)發(fā)時延不可見的問題。要注意的是:“INT推薦在數(shù)據(jù)面處理,不推薦控制面處理以體現(xiàn)真實情況。”利用INT技術(shù)能很快定位網(wǎng)絡(luò)丟包和延遲問題,通過軟件打標記是無法實現(xiàn)INT的高效處理的,必須需要網(wǎng)絡(luò)設(shè)備硬件支持。
 
網(wǎng)絡(luò)運維的可視化還有很長的路要走,sflow、gRPC、INT等都是可視化具體實現(xiàn)技術(shù),尤其gRPC和INT技術(shù)還沒有得到廣泛使用,現(xiàn)有數(shù)據(jù)中心的絕大部分設(shè)備還無法支持這種新技術(shù),網(wǎng)絡(luò)設(shè)備的更新?lián)Q代需要數(shù)年時間,所以這些新技術(shù)只有在新建的數(shù)據(jù)中心網(wǎng)絡(luò)中才能有機會出現(xiàn),能支持INT功能的網(wǎng)絡(luò)設(shè)備必然具有芯片自編程能力,這對網(wǎng)絡(luò)設(shè)備提出了更高要求。除了以上介紹的這三種可視化技術(shù),還有微軟在2015年提出的Pingmesh技術(shù),以及依然是微軟在2015年提出的Everflow技術(shù),還有Netsight(具體采用的Openflow協(xié)議)、ATPG、Planck等等,這些都是這兩年出現(xiàn)的可視化技術(shù),雖然沒有g(shù)RPC、INT影響力大,但技術(shù)也在不斷完善中,未來也不好說哪些技術(shù)一定能勝出,哪些技術(shù)會直接淘汰,去讓時間證明一切吧。
 
版權(quán)聲明:本文為企業(yè)網(wǎng)D1Net原創(chuàng),轉(zhuǎn)載需注明出處為:企業(yè)網(wǎng)D1Net,如果不注明出處,企業(yè)網(wǎng)D1Net將保留追究其法律責任的權(quán)利。

關(guān)鍵字:數(shù)據(jù)中心

原創(chuàng)文章 企業(yè)網(wǎng)D1Net

電子周刊
回到頂部

關(guān)于我們聯(lián)系我們版權(quán)聲明隱私條款廣告服務(wù)友情鏈接投稿中心招賢納士

企業(yè)網(wǎng)版權(quán)所有 ©2010-2024 京ICP備09108050號-6 京公網(wǎng)安備 11010502049343號

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

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 中方县| 淳安县| 湄潭县| 磐安县| 泗水县| 银川市| 定兴县| 左云县| 图木舒克市| 孝昌县| 朝阳市| 宜兰县| 华坪县| 天台县| 永寿县| 聊城市| 安泽县| 松滋市| 通海县| 清徐县| 固镇县| 东明县| 凤凰县| 巴南区| 筠连县| 会泽县| 宣威市| 壤塘县| 邓州市| 大连市| 怀仁县| 新干县| 如东县| 江城| 来宾市| 东乡县| 龙陵县| 杭锦旗| 京山县| 晴隆县| 女性|