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

當前位置:虛擬化行業動態 → 正文

SDN 前行?踏步?!

責任編輯:editor004 |來源:企業網D1Net  2014-03-04 16:23:34 本文摘自:51CTO

03月04日 綜合消息:

先講一個冷笑話,我心目中的SDN交換機:

在我心目中,SDN交換機是這樣的:

一個機框,

插上接口卡,可以做高性能數據交換;

插上控制卡,可以做網絡層路由轉發;

插上業務卡,可以做應用層流量管理、負載均衡、網絡控制、用戶管理、VPN……

多插業務卡,可以變成刀片服務器提升應用處理能力;

多插硬盤,可以變成網絡存儲;

多個機框之間可以采用全網狀、fabric互聯;

全網統一集中式管理。

但總覺得這個東西很早我就見過,一回頭,我看到了——機柜!

也談SDN

軟件定義網絡(Software Defined Network, SDN)這個概念在近期被炒的很火爆,但是很長一段時間內,并沒有引發我的過多關注。原因很簡單,大家都很閑嗎?可以有事沒事就對網絡流量節構進行修改? 況且自打Windows時代開始,系統編程再也不是一個獨行俠可以解決的問題。沒有一個研發團隊的支持,網絡流量的系統管理控制就會成為天方夜譚!開源軟 件是好,可是依靠一兩個未經廣泛驗證的開源軟件就可以解決用戶網絡應用管理的諸多問題嗎?恐怕沒有一個網絡管理員敢把賭注壓在這個上面。

然而去年對下一代防火墻的研究測試,給于了我新的啟發。實際上下一代防火墻并未采用過多的全新技術,直白的說它就是一個應用流量控制與IPS、傳統 防火墻的高性能統一集合體。但卻在短時間內迅速獲得了廣大用戶的認同,得到了飛速的發展。為什么會出現這種情況?究其原因有兩點:網絡應用的安全與管理。 了解網絡中應用是否安全并對其進行可靠的管理這兩點正是目前網絡用戶所迫切需要的。切中這兩個關鍵點,即可解決目前網絡用戶所需要解決的主要問題,自然也 就可以快速獲得廣大用戶對產品的認同。

既然下一代防火墻就可以解決用戶的網絡應用問題,那為什么還要談SDN?這就要從下一代防火墻與生具來無法解決的問題談起。下一代防火墻無論性能如 何提升,目前為止它都是一款網關類的安全產品。而目前,大規模(大型企業或電信級)的網絡用戶希望在網絡的核心層同樣實現這樣的功能。在保障網絡核心安全 的同時,通過核心層的管理可以更有效的對網絡應用流量進行控制。出于這種原因,我又把目光重新轉向了SDN。

要解決核心層的網絡應用流量安全及管理控制問題最終還得需要SDN。OpenFlow雖然實現了基于數據流的路徑轉發,但基畢竟還僅是基于網絡層進 行處理,無法在應用層上對數據流的內容進行過多的分析判斷。要想實現應用層的網絡安全管控,還得要看SDN的!再通過去年對路由、交換類產品新技術的了 解,于是我構想出了文章最初冷笑話中的SDN交換機……

有人會問,SDN功能實現主要是依靠SDN控制器,而對交換機的SDN功能進行研究是否是本末倒置?對于這一點我個人是從這個角度來考慮的:SDN 控制器無論是做為一個功能模塊集成于交換機內部,還是做為一個獨立硬件產品放置于交換機之外,均需要對整網的應用流量進行管理與控制。SDN控制器的整體 性能取決于交換機SDN功能的處理能力。因此對交換機SDN功能的評估,也就從本質上反映出了SDN控制器的管理控制能力。

SDN 前行?踏步?!

如何對產品進行評估,測試無疑是最有效的方法。于是春節前我做了一個小功課,向各大廠商征詢了一下廠商各自對交換機SDN功能的測試方法。由于離放 假時間比較近,并未收取到所有廠商的回復。然而,從目前收集到的結果來看,讓我不由得感到一些失望。大部份廠商給予的回復是基于OpenFlow技術規范 要求進行測試,并留有API接口……

OpenFlow并不是不好,技術規范的制定解決了不同品牌交換機在虛擬網絡架構下的數據流互通問題,同時也可以完成虛擬機全網遷移的功能,協助用 戶更好的進行云計算應用的實施。從云計算的角度來講,OpenFlow確實是現在虛擬化網絡的穩固基石,為虛機遷移提供了一個可靠的解決方案。然而用戶在 網絡應用中,并非僅有云計算這一種網絡應用需求,SDN其它網絡應用管控功能全是未知,更無法了解到其SDN功能是否可以滿足用戶應用管控的實際需求。這 樣的產品是否可以放心選擇,實在是令我難以判斷。

難道SDN就是在云計算的臺階上原地踏步嗎?如果真是那樣SDN也就不會引發我的過多關注了。我的SDN功能暢想啟蒙于兩個廠商:思科與迪普。思科 給我的啟迪是在2013年初的一次6500交換機測試里,6500雖然是一款老機型,但思科為其提供了一個當時最新可以實現Nexus所有功能的引擎。在 當時,那款引擎上已經提供了對網絡應用進行深度內容分析的API接口,再利用思科的與UCS結合的網絡應用管理軟件即可實現基于網絡應用的流量管理功能。 當時,我就開始有一種交換機將與下一代防火墻相融合的初步設想。在去年年中,迪普發布那個不知應該叫交換機還是其他什么的可以基于應用進行負載均衡、特征 分析具備強大應用層處理能力的DPX19000時,在我心目中對交換機的定義已經混亂了。當我把思維重新整理清楚后,我心目中的SDN交換機也就隨之誕生 了。同時我也堅定的認為,這將是網絡核心交換產品未來的發展方向。

產品?功能?指標?評估?

產品

目標明確了,那么在現在交換機廠商中,是否可以通過已有的產品對其功能進行實現呢?可能通過什么樣的交換產品來實現這個目標,SDN是否僅能存在于核心交換產品中,架頂式產品是否也可也完成同樣的任務?但在交換產品廠商已有的公開發布產品中很難獲取相關信息。

博科到是明確表標了在其現有的博科的MLXe系列交換路由器和Brocade NetIron CES和CER邊緣平臺上優先進行了OpenFlow開發,但相關SDN功能性的指標還不是十分明確。

在迪普的網站上到是可以了解到DPX19000的各類技術指標,但其并未明確表明這是一款SDN交換產品,而是以“新一代去級業務核心平臺”來為其產品命名……

由于存在著這些疑問,下一步我們還需要再進一步對廠商的SDN交換產品進行更深入的逐一了解。

功能

用戶關注SDN交換機是為了獲得更好的應用體驗,而更好的應用體驗需要在應用功能上進地實現,那么SDN交換目前及將來可以帶來什么樣的新功能呢?我們在下面試著來總結一下。

1、網絡功能

SDN交換機的網絡功能基本上可以通過OpenFlow相關標準協議來進行實現。目前可提供功能主要有以下幾項:

(1)大流量網絡數據傳輸

當前遵循OpenFlow協議標準的不同廠商SDN交換機之間可以做到數據流的互聯互通。為高性能網絡數據傳輸提供了相關的技術保障。

(2)用戶認證、流量管理、 VPN

由于OpenFlow是基于數據流的路徑轉發,先天帶有了用戶認證、流量管理方面的技術優勢。再通過MPLS等加密隧道進行數據傳輸,可以很方便的實現虛擬機遷移、BYOD接入控制等多方面的網絡數據傳輸管理工作。

2、應用功能

上述SDN交換設備的網絡功能在幾年前的云計算網絡產品中就已經可以實現,OpenFlow只不過是通過一個統一的技術規范來使各廠商產品之間數據 流可以進行互聯互通。然而這種互通還僅限于數據層面,在控制層面,不同廠商網絡產品間統一進行管理目前尚未得以實現。因此如果用戶采用不同廠商SDN網絡 交換產品,在集中管理控制上還存在相當多的問題。這也是用戶不敢貿然采用SDN技術的原因之一。況且,即便不采用SDN技術,在各廠商的網絡解決方案中, 也有對相關功能的全面解決方法。無非是以后需要統一采用同一廠商的網絡核心及接入設備而已。因此,如果SDN交換設備的產品功能僅能提供基于網絡層相關功 能,那SDN的發展,前景堪憂。

因此SDN交換設備要相獲得大多用戶的認同,勢必需要向網絡應用功能方向進行發展。然而目前所獲得的SDN應用功能還僅限一句空洞的“可以向第三方提供API接口”。這讓人不由得產生一種想住七層的房子,但開發商告訴你只能建到三層,剩下你只能私搭自建的郁悶感。

但這并不能阻擋我對SDN網絡應用功能的期望。于是我依據現有網絡產品可提供的網絡應用處理功能試著羅列了一下

(1)網絡應用可視化

網絡應用分析,這是目前用戶關注的熱點,只有知道網絡中具體在跑那些應用,才可以有針對性的去進行進一步管理。

(2)應用流量管理

應用分析后自然需要進行管理,這自然也是SDN今后必然需要提供的一項功能

(3)深度文件內容分析

無論何種企業在網絡應用中,網絡安全問題始終在對用戶進行著困擾。深度文件內容分析不但可以做為網絡安全防泄密的最后一道防線,還可以協助用戶更好的實現網絡安全等級保護。因此,此項工作在未來SDN網絡應用中也將必不可少。

(4)網絡應用安全

這項功能實際上是從深度文件內容分析引申出來的,在可以進行文件內容深度分析后,自然可以通過一系統數據對比,將IPS、AV等網絡安全功能也加載進去,但這種功能確實可以由第三方安全廠商來提供,沒有十分的必要讓網絡廠商再親力親為了。

在這里,我不由得想起了華為在13年中發布的AR G3企業應用路由器,這款產品通過華為提供的OSP開放業務平臺,為用戶提供集成多種業務和應用的開放式一體化解決方案。AR G3就好像一個智能手機一樣,提供一套開放的系統平臺,用戶需要什么應用,就可以自行在上面添加。從而滿足用戶在語音、安全、管理和網絡優化等方面的不同 需求。我想未來的SDN交換系統可能也會采用同樣的架構,提供相應的軟、硬件系統平臺,讓用戶自由選擇所需的應用功能,自行搭建可以滿足自身應用需求的應 用網絡系統。就好像建好了七層的毛坯房后,讓用戶自己選擇如何去裝修,而不是讓用戶自己去建房子了。

指標與評估

光有功能是不行的,我們還需要理智的對產品去進行分析與判斷。判斷問題要講方法明需求。OpenFlow的相關技術規范,可以令我們了解交換機在網 絡層數據轉發的處理性能。然而在我設想的SDN交換機中,還有許多網絡應用功能,這是需要對網絡應用流量處理性能進行了解的。這是OpenFlow測試所 不能提供的。如何解決這個問題。恐怕還是需要借鑒目前已相對成熟的網絡應用性能測試指標。那么哪些指標需要我們去進行關注呢?下面我試著羅列了一下:

基本性能指標:吞吐量、時延

雖然OpenFlow實現了基于數據流的路徑轉發,但其基礎的網絡傳輸性能還是要靠吞吐量和時延去進行判定

但是在去年的下一代防火墻測試中,發現了一個問題,那就是在吞吐量測試中,64Byte的小包吞吐量是否需要達到100%?得益于流量分析及應用可 視化技術的發展,我們現在可以清晰的對網絡中流量數據進行分析,在分析過程中我們發現64Byte的小數據包在網絡數據傳輸中所占比例基本上未達到1%, 不同網絡應用模式下的平均數據包長度在600Byte-700Byte之間(不同網絡應用平均數據包大小會有差異),也就是說在吞吐量性能在64Byte 可以達到線速的情況下,實際應用中有90%的處理性能是被空置的。這就產生了一個問題,我們需不需要因為這“1%(64Byte線速吞吐量)”而浪費那 90%的處理性能?這個問題希望在后面的測試評估中再進一步進行一下分析。

可以提一下的是,為了避免性能浪費,在去年下一代防火墻性能測試中我們設置一個網絡性能的及格線:64Byte吞吐量10%、512Byte吞吐量 90%、1518吞吐量100%。由于SDN交換機是基于數據流進行數據轉發,必然會在數據包中加一些識別標記,這樣可能在吞吐量測試中會無法達到 100%的傳輸速率,這時吞吐量應如何統計?這個問題我想還需要在下一步的實際測試中再進一步研究一下。

OpenFlow性能測試指標:

OpenFlow的性能測試指標目前常見的有OpenFlow協議握手(兼容性:例如OpenDaylight、Floodlight、NOX 等)、流表下發、報文傳輸、流表容量功能驗證等幾種,雖然上述指標可以在基本性能指標的吞吐量、時延中也能得以體現,但利用最大流表進行相關 OpenFlow的滿流量測試,我們可以更好的對有關交換機OpenFlow數據傳輸時的性能進行分析。

SDN應用處理性能:

雖然目前SDN交換機還沒有提供十分詳盡的應用層處理功能,只是提供了相關的API接口,但沒有應用處理能力進行支持的話,SDN交換產品也就會僅局限于為云計算應用提供支持,這樣SDN交換的應用范圍也會隨之急劇變小。

要想對SDN交換機應用處理性能進行評估,還要對SDN控制器的應用處理性能進行測試。這里,不妨借鑒一下網絡應用處理的性能指標:新建連接速率、并發連接數以及應用層吞吐量(應用流量)這三個指標。

有關這三個性能指標,在去年的下一代防火墻測試中,我們也進行了一下研究,并試驗著也劃出一個及格線,這里也來簡單介紹一下:

新建連接:每兆帶寬、每IP、每秒8個連接

并發連接:每兆帶寬、每IP、200連接

應用流量:64KB、512KB、1024KB文件大小下,帶寬的95%

簡單說明一下:這個及格線的標準實際上定的并不低,通過以往應用性能統計我們可以了解,在實際應用中,用戶實際用到的新建連接速率平均下來,也就在 每兆帶寬每秒4個連接左右。而并發連接,每個用戶同時用到的連接數不會超過100個連接。而應用流量,如果用戶的網絡流量使用率在70%以上,用戶首先想 到的就是網絡擴容了。因此,這個及格線已經為用戶網絡發生異常留下了一定的冗余空間。當然如果碰到12306春運時的網絡應用狀態,這個及格線可能就會不 夠了……

關鍵字:SDN報文傳輸

本文摘自:51CTO

x SDN 前行?踏步?! 掃一掃
分享本文到朋友圈
當前位置:虛擬化行業動態 → 正文

SDN 前行?踏步?!

責任編輯:editor004 |來源:企業網D1Net  2014-03-04 16:23:34 本文摘自:51CTO

03月04日 綜合消息:

先講一個冷笑話,我心目中的SDN交換機:

在我心目中,SDN交換機是這樣的:

一個機框,

插上接口卡,可以做高性能數據交換;

插上控制卡,可以做網絡層路由轉發;

插上業務卡,可以做應用層流量管理、負載均衡、網絡控制、用戶管理、VPN……

多插業務卡,可以變成刀片服務器提升應用處理能力;

多插硬盤,可以變成網絡存儲;

多個機框之間可以采用全網狀、fabric互聯;

全網統一集中式管理。

但總覺得這個東西很早我就見過,一回頭,我看到了——機柜!

也談SDN

軟件定義網絡(Software Defined Network, SDN)這個概念在近期被炒的很火爆,但是很長一段時間內,并沒有引發我的過多關注。原因很簡單,大家都很閑嗎?可以有事沒事就對網絡流量節構進行修改? 況且自打Windows時代開始,系統編程再也不是一個獨行俠可以解決的問題。沒有一個研發團隊的支持,網絡流量的系統管理控制就會成為天方夜譚!開源軟 件是好,可是依靠一兩個未經廣泛驗證的開源軟件就可以解決用戶網絡應用管理的諸多問題嗎?恐怕沒有一個網絡管理員敢把賭注壓在這個上面。

然而去年對下一代防火墻的研究測試,給于了我新的啟發。實際上下一代防火墻并未采用過多的全新技術,直白的說它就是一個應用流量控制與IPS、傳統 防火墻的高性能統一集合體。但卻在短時間內迅速獲得了廣大用戶的認同,得到了飛速的發展。為什么會出現這種情況?究其原因有兩點:網絡應用的安全與管理。 了解網絡中應用是否安全并對其進行可靠的管理這兩點正是目前網絡用戶所迫切需要的。切中這兩個關鍵點,即可解決目前網絡用戶所需要解決的主要問題,自然也 就可以快速獲得廣大用戶對產品的認同。

既然下一代防火墻就可以解決用戶的網絡應用問題,那為什么還要談SDN?這就要從下一代防火墻與生具來無法解決的問題談起。下一代防火墻無論性能如 何提升,目前為止它都是一款網關類的安全產品。而目前,大規模(大型企業或電信級)的網絡用戶希望在網絡的核心層同樣實現這樣的功能。在保障網絡核心安全 的同時,通過核心層的管理可以更有效的對網絡應用流量進行控制。出于這種原因,我又把目光重新轉向了SDN。

要解決核心層的網絡應用流量安全及管理控制問題最終還得需要SDN。OpenFlow雖然實現了基于數據流的路徑轉發,但基畢竟還僅是基于網絡層進 行處理,無法在應用層上對數據流的內容進行過多的分析判斷。要想實現應用層的網絡安全管控,還得要看SDN的!再通過去年對路由、交換類產品新技術的了 解,于是我構想出了文章最初冷笑話中的SDN交換機……

有人會問,SDN功能實現主要是依靠SDN控制器,而對交換機的SDN功能進行研究是否是本末倒置?對于這一點我個人是從這個角度來考慮的:SDN 控制器無論是做為一個功能模塊集成于交換機內部,還是做為一個獨立硬件產品放置于交換機之外,均需要對整網的應用流量進行管理與控制。SDN控制器的整體 性能取決于交換機SDN功能的處理能力。因此對交換機SDN功能的評估,也就從本質上反映出了SDN控制器的管理控制能力。

SDN 前行?踏步?!

如何對產品進行評估,測試無疑是最有效的方法。于是春節前我做了一個小功課,向各大廠商征詢了一下廠商各自對交換機SDN功能的測試方法。由于離放 假時間比較近,并未收取到所有廠商的回復。然而,從目前收集到的結果來看,讓我不由得感到一些失望。大部份廠商給予的回復是基于OpenFlow技術規范 要求進行測試,并留有API接口……

OpenFlow并不是不好,技術規范的制定解決了不同品牌交換機在虛擬網絡架構下的數據流互通問題,同時也可以完成虛擬機全網遷移的功能,協助用 戶更好的進行云計算應用的實施。從云計算的角度來講,OpenFlow確實是現在虛擬化網絡的穩固基石,為虛機遷移提供了一個可靠的解決方案。然而用戶在 網絡應用中,并非僅有云計算這一種網絡應用需求,SDN其它網絡應用管控功能全是未知,更無法了解到其SDN功能是否可以滿足用戶應用管控的實際需求。這 樣的產品是否可以放心選擇,實在是令我難以判斷。

難道SDN就是在云計算的臺階上原地踏步嗎?如果真是那樣SDN也就不會引發我的過多關注了。我的SDN功能暢想啟蒙于兩個廠商:思科與迪普。思科 給我的啟迪是在2013年初的一次6500交換機測試里,6500雖然是一款老機型,但思科為其提供了一個當時最新可以實現Nexus所有功能的引擎。在 當時,那款引擎上已經提供了對網絡應用進行深度內容分析的API接口,再利用思科的與UCS結合的網絡應用管理軟件即可實現基于網絡應用的流量管理功能。 當時,我就開始有一種交換機將與下一代防火墻相融合的初步設想。在去年年中,迪普發布那個不知應該叫交換機還是其他什么的可以基于應用進行負載均衡、特征 分析具備強大應用層處理能力的DPX19000時,在我心目中對交換機的定義已經混亂了。當我把思維重新整理清楚后,我心目中的SDN交換機也就隨之誕生 了。同時我也堅定的認為,這將是網絡核心交換產品未來的發展方向。

產品?功能?指標?評估?

產品

目標明確了,那么在現在交換機廠商中,是否可以通過已有的產品對其功能進行實現呢?可能通過什么樣的交換產品來實現這個目標,SDN是否僅能存在于核心交換產品中,架頂式產品是否也可也完成同樣的任務?但在交換產品廠商已有的公開發布產品中很難獲取相關信息。

博科到是明確表標了在其現有的博科的MLXe系列交換路由器和Brocade NetIron CES和CER邊緣平臺上優先進行了OpenFlow開發,但相關SDN功能性的指標還不是十分明確。

在迪普的網站上到是可以了解到DPX19000的各類技術指標,但其并未明確表明這是一款SDN交換產品,而是以“新一代去級業務核心平臺”來為其產品命名……

由于存在著這些疑問,下一步我們還需要再進一步對廠商的SDN交換產品進行更深入的逐一了解。

功能

用戶關注SDN交換機是為了獲得更好的應用體驗,而更好的應用體驗需要在應用功能上進地實現,那么SDN交換目前及將來可以帶來什么樣的新功能呢?我們在下面試著來總結一下。

1、網絡功能

SDN交換機的網絡功能基本上可以通過OpenFlow相關標準協議來進行實現。目前可提供功能主要有以下幾項:

(1)大流量網絡數據傳輸

當前遵循OpenFlow協議標準的不同廠商SDN交換機之間可以做到數據流的互聯互通。為高性能網絡數據傳輸提供了相關的技術保障。

(2)用戶認證、流量管理、 VPN

由于OpenFlow是基于數據流的路徑轉發,先天帶有了用戶認證、流量管理方面的技術優勢。再通過MPLS等加密隧道進行數據傳輸,可以很方便的實現虛擬機遷移、BYOD接入控制等多方面的網絡數據傳輸管理工作。

2、應用功能

上述SDN交換設備的網絡功能在幾年前的云計算網絡產品中就已經可以實現,OpenFlow只不過是通過一個統一的技術規范來使各廠商產品之間數據 流可以進行互聯互通。然而這種互通還僅限于數據層面,在控制層面,不同廠商網絡產品間統一進行管理目前尚未得以實現。因此如果用戶采用不同廠商SDN網絡 交換產品,在集中管理控制上還存在相當多的問題。這也是用戶不敢貿然采用SDN技術的原因之一。況且,即便不采用SDN技術,在各廠商的網絡解決方案中, 也有對相關功能的全面解決方法。無非是以后需要統一采用同一廠商的網絡核心及接入設備而已。因此,如果SDN交換設備的產品功能僅能提供基于網絡層相關功 能,那SDN的發展,前景堪憂。

因此SDN交換設備要相獲得大多用戶的認同,勢必需要向網絡應用功能方向進行發展。然而目前所獲得的SDN應用功能還僅限一句空洞的“可以向第三方提供API接口”。這讓人不由得產生一種想住七層的房子,但開發商告訴你只能建到三層,剩下你只能私搭自建的郁悶感。

但這并不能阻擋我對SDN網絡應用功能的期望。于是我依據現有網絡產品可提供的網絡應用處理功能試著羅列了一下

(1)網絡應用可視化

網絡應用分析,這是目前用戶關注的熱點,只有知道網絡中具體在跑那些應用,才可以有針對性的去進行進一步管理。

(2)應用流量管理

應用分析后自然需要進行管理,這自然也是SDN今后必然需要提供的一項功能

(3)深度文件內容分析

無論何種企業在網絡應用中,網絡安全問題始終在對用戶進行著困擾。深度文件內容分析不但可以做為網絡安全防泄密的最后一道防線,還可以協助用戶更好的實現網絡安全等級保護。因此,此項工作在未來SDN網絡應用中也將必不可少。

(4)網絡應用安全

這項功能實際上是從深度文件內容分析引申出來的,在可以進行文件內容深度分析后,自然可以通過一系統數據對比,將IPS、AV等網絡安全功能也加載進去,但這種功能確實可以由第三方安全廠商來提供,沒有十分的必要讓網絡廠商再親力親為了。

在這里,我不由得想起了華為在13年中發布的AR G3企業應用路由器,這款產品通過華為提供的OSP開放業務平臺,為用戶提供集成多種業務和應用的開放式一體化解決方案。AR G3就好像一個智能手機一樣,提供一套開放的系統平臺,用戶需要什么應用,就可以自行在上面添加。從而滿足用戶在語音、安全、管理和網絡優化等方面的不同 需求。我想未來的SDN交換系統可能也會采用同樣的架構,提供相應的軟、硬件系統平臺,讓用戶自由選擇所需的應用功能,自行搭建可以滿足自身應用需求的應 用網絡系統。就好像建好了七層的毛坯房后,讓用戶自己選擇如何去裝修,而不是讓用戶自己去建房子了。

指標與評估

光有功能是不行的,我們還需要理智的對產品去進行分析與判斷。判斷問題要講方法明需求。OpenFlow的相關技術規范,可以令我們了解交換機在網 絡層數據轉發的處理性能。然而在我設想的SDN交換機中,還有許多網絡應用功能,這是需要對網絡應用流量處理性能進行了解的。這是OpenFlow測試所 不能提供的。如何解決這個問題。恐怕還是需要借鑒目前已相對成熟的網絡應用性能測試指標。那么哪些指標需要我們去進行關注呢?下面我試著羅列了一下:

基本性能指標:吞吐量、時延

雖然OpenFlow實現了基于數據流的路徑轉發,但其基礎的網絡傳輸性能還是要靠吞吐量和時延去進行判定

但是在去年的下一代防火墻測試中,發現了一個問題,那就是在吞吐量測試中,64Byte的小包吞吐量是否需要達到100%?得益于流量分析及應用可 視化技術的發展,我們現在可以清晰的對網絡中流量數據進行分析,在分析過程中我們發現64Byte的小數據包在網絡數據傳輸中所占比例基本上未達到1%, 不同網絡應用模式下的平均數據包長度在600Byte-700Byte之間(不同網絡應用平均數據包大小會有差異),也就是說在吞吐量性能在64Byte 可以達到線速的情況下,實際應用中有90%的處理性能是被空置的。這就產生了一個問題,我們需不需要因為這“1%(64Byte線速吞吐量)”而浪費那 90%的處理性能?這個問題希望在后面的測試評估中再進一步進行一下分析。

可以提一下的是,為了避免性能浪費,在去年下一代防火墻性能測試中我們設置一個網絡性能的及格線:64Byte吞吐量10%、512Byte吞吐量 90%、1518吞吐量100%。由于SDN交換機是基于數據流進行數據轉發,必然會在數據包中加一些識別標記,這樣可能在吞吐量測試中會無法達到 100%的傳輸速率,這時吞吐量應如何統計?這個問題我想還需要在下一步的實際測試中再進一步研究一下。

OpenFlow性能測試指標:

OpenFlow的性能測試指標目前常見的有OpenFlow協議握手(兼容性:例如OpenDaylight、Floodlight、NOX 等)、流表下發、報文傳輸、流表容量功能驗證等幾種,雖然上述指標可以在基本性能指標的吞吐量、時延中也能得以體現,但利用最大流表進行相關 OpenFlow的滿流量測試,我們可以更好的對有關交換機OpenFlow數據傳輸時的性能進行分析。

SDN應用處理性能:

雖然目前SDN交換機還沒有提供十分詳盡的應用層處理功能,只是提供了相關的API接口,但沒有應用處理能力進行支持的話,SDN交換產品也就會僅局限于為云計算應用提供支持,這樣SDN交換的應用范圍也會隨之急劇變小。

要想對SDN交換機應用處理性能進行評估,還要對SDN控制器的應用處理性能進行測試。這里,不妨借鑒一下網絡應用處理的性能指標:新建連接速率、并發連接數以及應用層吞吐量(應用流量)這三個指標。

有關這三個性能指標,在去年的下一代防火墻測試中,我們也進行了一下研究,并試驗著也劃出一個及格線,這里也來簡單介紹一下:

新建連接:每兆帶寬、每IP、每秒8個連接

并發連接:每兆帶寬、每IP、200連接

應用流量:64KB、512KB、1024KB文件大小下,帶寬的95%

簡單說明一下:這個及格線的標準實際上定的并不低,通過以往應用性能統計我們可以了解,在實際應用中,用戶實際用到的新建連接速率平均下來,也就在 每兆帶寬每秒4個連接左右。而并發連接,每個用戶同時用到的連接數不會超過100個連接。而應用流量,如果用戶的網絡流量使用率在70%以上,用戶首先想 到的就是網絡擴容了。因此,這個及格線已經為用戶網絡發生異常留下了一定的冗余空間。當然如果碰到12306春運時的網絡應用狀態,這個及格線可能就會不 夠了……

關鍵字:SDN報文傳輸

本文摘自:51CTO

電子周刊
回到頂部

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

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

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

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 灌云县| 花莲县| 淮阳县| 德格县| 永寿县| 鸡东县| 青州市| 皋兰县| 扎兰屯市| 山丹县| 镶黄旗| 武鸣县| 米林县| 日喀则市| 盖州市| 土默特右旗| 新郑市| 龙岩市| 桦南县| 巴马| 天水市| 博乐市| 汤阴县| 杨浦区| 共和县| 顺义区| 阿城市| 漳平市| 福州市| 泗水县| 石狮市| 延寿县| 淳安县| 宝应县| 津南区| 屯昌县| 通道| 博兴县| 深水埗区| 五莲县| 万盛区|