本文選題：Neutron流量瓶頸 + OpenStack　； 參考：《北京工業(yè)大學(xué)》2015年碩士論文

【摘要】：隨著云計算時代的來臨,基于基礎(chǔ)設(shè)施服務(wù)的云計算管理平臺受到了廣泛的關(guān)注,而開源云平臺OpenStack的產(chǎn)生與快速發(fā)展也正是得益于此。從最初的Austin版本到現(xiàn)在的最新版本Kilo,十一個版本迭代也只用了五年時間,本文在研究過程中一直保持對最新版本的關(guān)注,所做研究也是基于最新版本展開的。本文主要是針對OpenStack中的網(wǎng)絡(luò)組件展開研究的,早期OpenStack的網(wǎng)絡(luò)結(jié)構(gòu)是Nova-Network,但Nova-Network結(jié)構(gòu)設(shè)計比較簡單,只能滿足于小規(guī)模二層網(wǎng)絡(luò)的簡單需求。隨著網(wǎng)絡(luò)規(guī)模的不斷擴(kuò)大和網(wǎng)絡(luò)即服務(wù)概念的提出,OpenStack社區(qū)提出了Neutron網(wǎng)絡(luò)模型,用戶可以使用Neutron提供的API,然后根據(jù)自己的需求自定義網(wǎng)絡(luò)拓?fù)�、VPN、Firewall等高級網(wǎng)絡(luò)服務(wù)。OpenStack的Neutron網(wǎng)絡(luò)雖然實現(xiàn)了網(wǎng)絡(luò)服務(wù),也滿足了廣義上的軟件定義網(wǎng)絡(luò),但該模型仍然有以下的缺點:一、在該模型中,網(wǎng)絡(luò)節(jié)點起著中樞作用,負(fù)責(zé)判斷所有流量的路徑走向,所以這種設(shè)計有著很大的單點問題和流量瓶頸問題。二、該網(wǎng)絡(luò)模型中的數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備采用的是開源虛擬交換機(jī),但是該虛擬網(wǎng)絡(luò)設(shè)備的控制層和轉(zhuǎn)發(fā)層沒有剝離,其路由路徑的產(chǎn)生都是基于自協(xié)商的,所以其流量的可控性不足。本文針對上述Neutron網(wǎng)絡(luò)中的不足所做的具體工作內(nèi)容分為以下三部分:一、針對當(dāng)前Neutron網(wǎng)絡(luò)中的流量瓶頸問題,提出了基于分布式虛擬路由的設(shè)計,即在每個計算節(jié)點上增加一個虛擬路由進(jìn)程,該路由主要負(fù)責(zé)判斷該計算節(jié)點中的數(shù)據(jù)轉(zhuǎn)發(fā)路徑,如果是東西流量,則直接將該數(shù)據(jù)包發(fā)送到目的計算節(jié)點。如果是南北流量,則統(tǒng)一將該數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)節(jié)點。二、針對當(dāng)前Neutron網(wǎng)絡(luò)的流量不可控性,引入了OpenFlow流量模型,使用OpenFlow控制器集中控制Neutron網(wǎng)絡(luò)的流表生成和走向,同時針對當(dāng)前OpenFlow協(xié)議不能支持Neutron網(wǎng)絡(luò)三層路由的缺點,在當(dāng)前OpenFlow協(xié)議基礎(chǔ)上增加ARP和ICMP的動作處理函數(shù),使OpenFlow協(xié)議能處理ARP和ICMP包的請求和回復(fù),從而能使OpenFlow控制器能正�？刂芅eutron網(wǎng)絡(luò)的三層流量。三、最后本文進(jìn)行了實際OpenStack仿真部署,針對Neutron流量的瓶頸問題和可控性都進(jìn)行了實驗測試,實驗表明基于分布式虛擬路由的Neutron網(wǎng)絡(luò)在不同類型帶寬流量上較傳統(tǒng)Neutron網(wǎng)絡(luò)有較大提升。
[Abstract]:With the advent of cloud computing era, cloud computing management platform based on infrastructure services has received extensive attention, and the emergence and rapid development of open source cloud platform OpenStack is also benefited from this. From the initial version of Austin to the latest version of the current version, eleven versions of the iteration only took five years. In the research process, this paper has been keeping the attention to the latest version, and the research is also based on the latest version. This paper mainly focuses on the research of network components in OpenStack. The network structure of early OpenStack was Nova-Network, but the Nova-Network structure design was relatively simple, which can only satisfy the simple requirement of small-scale two-layer network. With the continuous expansion of the network scale and the introduction of the concept of network as a service, the Open Stack community put forward the Neutron network model. Users can use the API provided by Neutron, and then customize the Neutron network of advanced network services, such as VPN Firewall and OpenStack, according to their own needs. Although they realize the network services, they can also satisfy the software definition network in the broad sense. However, the model still has the following disadvantages: first, in this model, network nodes play a central role in judging the path direction of all traffic, so this design has a large single point problem and traffic bottleneck problem. Second, the data forwarding device in the network model uses open source virtual switch, but the control layer and forwarding layer of the virtual network device are not stripped, and the generation of routing path is based on self-negotiation. So the flow of the lack of controllability. The specific work content of this paper is divided into the following three parts: first, aiming at the traffic bottleneck problem in the current Neutron network, a design based on distributed virtual routing is proposed. In other words, a virtual routing process is added to each computing node, which is mainly responsible for judging the data forwarding path in the computing node. If it is east-west traffic, the packet is sent directly to the destination node. If the traffic is north-south, then the data will be sent to the network node. Secondly, aiming at the uncontrollability of current Neutron network traffic, the OpenFlow traffic model is introduced, and the flow table generation and direction of Neutron network are centrally controlled by OpenFlow controller. At the same time, the current OpenFlow protocol can not support the three-layer routing in Neutron network. Based on the current OpenFlow protocol, the action processing functions of ARP and ICMP are added, so that the OpenFlow protocol can handle the request and reply of ARP and ICMP packets, so that the OpenFlow controller can control the three-layer flow of Neutron network normally. Finally, the actual OpenStack simulation deployment is carried out in this paper. The bottleneck problem and controllability of Neutron traffic are tested experimentally. The experimental results show that the Neutron network based on distributed virtual routing is better than the traditional Neutron network in different types of bandwidth traffic.
【學(xué)位授予單位】：北京工業(yè)大學(xué)
【學(xué)位級別】：碩士
【學(xué)位授予年份】：2015
【分類號】：TP393.06
，

本文編號：1891854