基於跳數,時延,頻寬的最短/優路徑和負載均衡
基於跳數的最短路徑轉發
基於跳數的最短路徑轉發是最簡單的最優路徑轉發應用。我們通過network_awareness應用來實現網路拓撲資源的感知並計算最短路徑。首先控制器通過下發LLDP報文來獲取網路鏈路資訊,然後再利用網路資訊,生成網路拓撲圖。網路感知應用使用networkx的有向圖資料結構儲存拓撲資訊,使用networkx提供的shortestsimplepaths函式來計算最短路徑。shortest_simple_paths函式支援在圖上找出源交換機到目的交換機的K條最短路徑,其函式引數資訊如下
shortest_simple_paths(G, source, target, weight=None)
在給定圖G,源交換機source,目的交換機target以及鏈路權重型別weight的情況下,會返回一個路徑生成器。通過K次呼叫生成器可以生成K條最短路徑。
獲得最短路徑之後,shortest_forwarding應用將完成流表下發等工作,實現基於跳數的最短路徑轉發應用。
基於時延的最優路徑轉發
基於時延的最優路徑轉發應用原理和基於跳數的最短路徑轉發應用類似,只是鏈路權重型別變成了時延。關於計算鏈路時延的原理,讀者可以閱讀Ryu:網路時延探測應用。NetworkDelayDetector是一個網路時延探測應用,其在獲取到鏈路時延之後,將時延資料儲存到Networkx的圖資料結構中,以供其他模組使用。
通過設定鏈路權重引數,Shortest_forwarding應用可以基於時延資料計算最優的轉發路徑。
基於頻寬的最優路徑轉發/負載均衡
基於頻寬的最優路徑相比以上兩種應用相對要複雜一些。為了降低計算複雜度,我們採用先計算基於跳數的K條最短路徑,再從中選取可用頻寬最大的那條路徑最為最優解。鏈路可用頻寬的資料由nework_monitor應用提供。該應用週期地獲取鏈路的剩餘頻寬,並將頻寬資料儲存到networkx的圖結構中,提供給其他模組使用。此外,network_monitor模組還實現了基於鏈路可用頻寬的最優轉發路徑的計算,為其他模組提供最優路徑資訊。
通過設定鏈路權重引數,Shortest_forwarding應用可以基於頻寬資料計算最優的轉發路徑。本質上,network_monitor基於當前流量,為新資料流選擇最佳轉發路徑,也是一種網路流量負載均衡的實現,只是其排程演算法相對簡單。
使用方法
為解析權重和最短K路徑的引數,還需要在Ryu中註冊全域性的啟動引數。註冊引數的方法十分簡單,只需要在Ryu頂級目錄下的flags.py檔案中新增如下的程式碼即可:
CONF.register_cli_opts([
# k_shortest_forwarding
cfg.IntOpt('k-paths', default=1, help='number for k shortest paths'),
cfg.StrOpt('weight', default='hop',
help='type of computing shortest path.')])
完成以上修改後,將Github倉庫中的程式碼下載到本地,然後放置到Ryu目錄下合適的位置,比如Ryu/app目錄下。
最後還需要重新安裝Ryu:進入到ryu/的根目錄,執行setup.py檔案,並新增install引數。
sudo python setup.py install
重新安裝完成之後,啟動shortest_forwarding應用,並新增observe-links,鏈路權重和最短路徑條數等重要引數,示例如下:
ryu-manager ryu/app/network_awareness/shortest_forwarding --observe-links --k-paths=2 --weight=bw
啟動Ryu之後,啟動任意的SDN網路,如Mininet模擬的網路,並連線到Ryu控制器。最後可以在Mininet輸入框中輸入pingall進行測試。
sudo mn --controller=remote --topo=tree,3,3 --mac
為了方便使用,讀者可以通過修改setting.py中的資訊來修改應用的重要引數,比如獲取鏈路資訊的週期,是否列印網路資訊等等。setting資訊具體如下所示:
DISCOVERY_PERIOD = 10
MONITOR_PERIOD = 10
DELAY_DETECTING_PERIOD = 10
TOSHOW = True
MAX_CAPACITY = 281474976710655L
讀者可以通過修改對應的週期數值,來修改對應模組獲取資訊的週期,其單位為秒。TOSHOW是一個布林值,用於設定是否在終端列印網路資訊。MAX_CAPACITY值為鏈路最大可用頻寬值,可根據實際情況進行修改。
相關文章
- 網路應用優化——時延與頻寬優化
- windows第七層負載均衡 基於IIS的ARR負載均衡詳解Windows負載
- windows伺服器第四層負載均衡_基於NLB負載均衡詳解Windows伺服器負載
- Docker Swarm :gRPC 基於 DNS 的負載均衡DockerSwarmRPCDNS負載
- mosn基於延遲負載均衡演算法 -- 走得更快,期待走得更穩負載演算法
- nginx部署基於http負載均衡器NginxHTTP負載
- TKE基於彈性網路卡直連Pod的網路負載均衡負載
- HUAWEI防火牆雙出口據鏈路頻寬負載分擔防火牆負載
- 解密負載均衡技術和負載均衡演算法解密負載演算法
- Curve 基於 Raft 的寫時延優化Raft優化
- 【知識分享】四層負載均衡和七層負載均衡負載
- 基於開源Tars的動態負載均衡實踐負載
- 基於Nginx的軟體負載均衡實現解讀Nginx負載
- 代理和負載均衡概述負載
- 負載均衡基礎知識負載
- Web直播系列4——ffmpeg實時推流+nginx負載均衡降低直播延時_1WebNginx負載
- 負載均衡和動態負載均衡分別是什麼?-VeCloud負載Cloud
- 基於gRPC的註冊發現與負載均衡的原理和實戰RPC負載
- 【故障公告】疑似未知知名搜尋引擎蜘蛛來襲,一臺負載均衡頻寬跑滿負載
- 基於滴滴雲部署 HAProxy 實現 7 層和 4 層負載均衡負載
- 淺析基於雲的DNS管理與負載均衡技術DNS負載
- 基於 LVS 的 AAA 負載均衡架構實踐負載架構
- 負載均衡負載
- 負載均衡是什麼?怎麼理解負載均衡的部署方式和工作原理負載
- APACHE做負載均衡時出錯Apache負載
- dubbo叢集和負載均衡負載
- gRPC負載均衡(客戶端負載均衡)RPC負載客戶端
- gRPC負載均衡(自定義負載均衡策略)RPC負載
- 負載均衡的迷惑負載
- 基於滴滴雲DC2+Nginx搭建負載均衡方案Nginx負載
- 基於軟體實現網站負載均衡(1) (轉)網站負載
- 關於高度均衡和頻率均衡的直方圖直方圖
- 【Tony 老師】基於 Maxscale 實現讀寫分離和負載均衡負載
- 關於負載均衡的簡單總結負載
- CDN和負載均衡的基本瞭解負載
- 微服務架構 | 4.1 基於 Ribbon 的負載均衡詳解微服務架構負載
- 關於用Java做叢集和負載均衡的問題Java負載
- 基於 CentOS 7 + Nginx + Tomcat 的負載均衡伺服器的搭建CentOSNginxTomcat負載伺服器