一 openstack由來

openstack最早由美國國家航空航天局NASA研發(fā)的Nova和Rackspace研發(fā)的swift組成。后來以apache許可證授權(quán),旨在為公共及私有云平臺(tái)建設(shè)。openstack主要用來為企業(yè)內(nèi)部實(shí)現(xiàn)類似于Amazon EC2和S3的云基礎(chǔ)架構(gòu)服務(wù)（Iaas）.每6個(gè)月更新一次，基本與ubuntu同步，命名是以A-Z作為首字母來的。

二 openstack項(xiàng)目與組件（服務(wù)名是項(xiàng)目名的別名）

核心項(xiàng)目3個(gè)

1.控制臺(tái)

服務(wù)名：Dashboard

項(xiàng)目名：Horizon

功能：web方式管理云平臺(tái)，建云主機(jī)，分配網(wǎng)絡(luò)，配安全組，加云盤

2.計(jì)算

服務(wù)名：計(jì)算

項(xiàng)目名：Nova

功能：負(fù)責(zé)響應(yīng)虛擬機(jī)創(chuàng)建請求、調(diào)度、銷毀云主機(jī)

3.網(wǎng)絡(luò)

服務(wù)名：網(wǎng)絡(luò)

項(xiàng)目名：Neutron

功能：實(shí)現(xiàn)SDN（軟件定義網(wǎng)絡(luò)），提供一整套API,用戶可以基于該API實(shí)現(xiàn)自己定義專屬網(wǎng)絡(luò)，不同廠商可以基于此API提供自己的產(chǎn)品實(shí)現(xiàn)

存儲(chǔ)項(xiàng)目2個(gè)

1.對象存儲(chǔ)

服務(wù)名：對象存儲(chǔ)

項(xiàng)目名：Swift

功能：REST風(fēng)格的接口和扁平的數(shù)據(jù)組織結(jié)構(gòu)。RESTFUL HTTP API來保存和訪問任意非結(jié)構(gòu)化數(shù)據(jù)，ring環(huán)的方式實(shí)現(xiàn)數(shù)據(jù)自動(dòng)復(fù)制和高度可以擴(kuò)展架構(gòu)，保證數(shù)據(jù)的高度容錯(cuò)和可靠性

2.塊存儲(chǔ)

服務(wù)名：塊存儲(chǔ)

項(xiàng)目名：Cinder

功能：提供持久化塊存儲(chǔ)，即為云主機(jī)提供附加云盤。

共享服務(wù)項(xiàng)目3個(gè)

1.認(rèn)證服務(wù)

服務(wù)名：認(rèn)證服務(wù)

項(xiàng)目名：Keystone

功能：為訪問openstack各組件提供認(rèn)證和授權(quán)功能，認(rèn)證通過后，提供一個(gè)服務(wù)列表（存放你有權(quán)訪問的服務(wù)），可以通過該列表訪問各個(gè)組件。

2.鏡像服務(wù)

服務(wù)名：鏡像服務(wù)

項(xiàng)目名：Glance

功能：為云主機(jī)安裝操作系統(tǒng)提供不同的鏡像選擇

3.計(jì)費(fèi)服務(wù)

服務(wù)名：計(jì)費(fèi)服務(wù)

項(xiàng)目名：Ceilometer

功能：收集云平臺(tái)資源使用數(shù)據(jù)，用來計(jì)費(fèi)或者性能監(jiān)控

高層服務(wù)項(xiàng)目1個(gè)

1.編排服務(wù)

服務(wù)名：編排服務(wù)

項(xiàng)目名：Heat

功能：自動(dòng)化部署應(yīng)用，自動(dòng)化管理應(yīng)用的整個(gè)生命周期.主要用于Paas

三 openstack各組件詳解及運(yùn)行流程

各組件邏輯關(guān)系圖：

openstack新建云主機(jī)流程圖:

虛擬機(jī)啟動(dòng)過程如下：

界面或命令行通過RESTful API向keystone獲取認(rèn)證信息。

keystone通過用戶請求認(rèn)證信息，并生成auth-token返回給對應(yīng)的認(rèn)證請求。

界面或命令行通過RESTful API向nova-api發(fā)送一個(gè)boot instance的請求（攜帶auth-token）。

nova-api接受請求后向keystone發(fā)送認(rèn)證請求，查看token是否為有效用戶和token。

keystone驗(yàn)證token是否有效，如有效則返回有效的認(rèn)證和對應(yīng)的角色（注：有些操作需要有角色權(quán)限才能操作）。

通過認(rèn)證后nova-api和數(shù)據(jù)庫通訊。

初始化新建虛擬機(jī)的數(shù)據(jù)庫記錄。

nova-api通過rpc.call向nova-scheduler請求是否有創(chuàng)建虛擬機(jī)的資源(Host ID)。

nova-scheduler進(jìn)程偵聽消息隊(duì)列，獲取nova-api的請求。

nova-scheduler通過查詢nova數(shù)據(jù)庫中計(jì)算資源的情況，并通過調(diào)度算法計(jì)算符合虛擬機(jī)創(chuàng)建需要的主機(jī)。

對于有符合虛擬機(jī)創(chuàng)建的主機(jī)，nova-scheduler更新數(shù)據(jù)庫中虛擬機(jī)對應(yīng)的物理主機(jī)信息。

nova-scheduler通過rpc.cast向nova-compute發(fā)送對應(yīng)的創(chuàng)建虛擬機(jī)請求的消息。

nova-compute會(huì)從對應(yīng)的消息隊(duì)列中獲取創(chuàng)建虛擬機(jī)請求的消息。

nova-compute通過rpc.call向nova-conductor請求獲取虛擬機(jī)消息。（Flavor）

nova-conductor從消息隊(duì)隊(duì)列中拿到nova-compute請求消息。

nova-conductor根據(jù)消息查詢虛擬機(jī)對應(yīng)的信息。

nova-conductor從數(shù)據(jù)庫中獲得虛擬機(jī)對應(yīng)信息。

nova-conductor把虛擬機(jī)信息通過消息的方式發(fā)送到消息隊(duì)列中。

nova-compute從對應(yīng)的消息隊(duì)列中獲取虛擬機(jī)信息消息。

nova-compute通過keystone的RESTfull API拿到認(rèn)證的token，并通過HTTP請求glance-api獲取創(chuàng)建虛擬機(jī)所需要鏡像。

glance-api向keystone認(rèn)證token是否有效，并返回驗(yàn)證結(jié)果。

token驗(yàn)證通過，nova-compute獲得虛擬機(jī)鏡像信息(URL)。

nova-compute通過keystone的RESTfull API拿到認(rèn)證k的token，并通過HTTP請求neutron-server獲取創(chuàng)建虛擬機(jī)所需要的網(wǎng)絡(luò)信息。

neutron-server向keystone認(rèn)證token是否有效，并返回驗(yàn)證結(jié)果。

token驗(yàn)證通過，nova-compute獲得虛擬機(jī)網(wǎng)絡(luò)信息。

nova-compute通過keystone的RESTfull API拿到認(rèn)證的token，并通過HTTP請求cinder-api獲取創(chuàng)建虛擬機(jī)所需要的持久化存儲(chǔ)信息。

cinder-api向keystone認(rèn)證token是否有效，并返回驗(yàn)證結(jié)果。

token驗(yàn)證通過，nova-compute獲得虛擬機(jī)持久化存儲(chǔ)信息。

nova-compute根據(jù)instance的信息調(diào)用配置的虛擬化驅(qū)動(dòng)來創(chuàng)建虛擬機(jī)。

下面我們就圍繞上圖流程展開。

1.keystone

User：指使用Openstack service的用戶，可以是人、服務(wù)、系統(tǒng)，但凡使用了Openstack service的對象都可以稱為User。

Project(Tenant)：可以理解為一個(gè)人、或服務(wù)所擁有的資源集合。在一個(gè)Project(Tenant)中可以包含多個(gè)User，每一個(gè)User都會(huì)根據(jù)權(quán)限的劃分來使用Project(Tenant)中的資源。比如通過Nova創(chuàng)建虛擬機(jī)時(shí)要指定到某個(gè)Project中，在Cinder創(chuàng)建卷也要指定到某個(gè)Project中。User訪問Project的資源前，必須要與該P(yáng)roject關(guān)聯(lián)，并且指定User在Project下的Role。

Role：用于劃分權(quán)限。可以通過給User指定Role，使User獲得Role對應(yīng)的操作權(quán)限。Keystone返回給User的Token包含了Role列表，被訪問的Services會(huì)判斷訪問它的User和User提供的Token中所包含的Role。系統(tǒng)默認(rèn)使用管理Role admin和成員Role _member_ 。

Policy：OpenStack對User的驗(yàn)證除了OpenStack的身份驗(yàn)證以外，還需要鑒別User對某個(gè)Service是否有訪問權(quán)限。Policy機(jī)制就是用來控制User對Tenant中資源(包括Services)的操作權(quán)限。對于Keystone service來說，Policy就是一個(gè)JSON文件，默認(rèn)是/etc/keystone/policy.json。通過配置這個(gè)文件，Keystone Service實(shí)現(xiàn)了對User基于Role的權(quán)限管理。

Token：是一個(gè)字符串表示，作為訪問資源的令牌。Token包含了在指定范圍和有效時(shí)間內(nèi)可以被訪問的資源。EG. 在Nova中一個(gè)tenant可以是一些虛擬機(jī)，在Swift和Glance中一個(gè)tenant可以是一些鏡像存儲(chǔ)，在Network中一個(gè)tenant可以是一些網(wǎng)絡(luò)資源。Token一般被User持有。

Credentials：用于確認(rèn)用戶身份的憑證

Authentication：確定用戶身份的過程

Service：Openstack service，即Openstack中運(yùn)行的組件服務(wù)。

Endpoint：一個(gè)可以通過網(wǎng)絡(luò)來訪問和定位某個(gè)Openstack service的地址，通常是一個(gè)URL。比如，當(dāng)Nova需要訪問Glance服務(wù)去獲取image 時(shí)，Nova通過訪問Keystone拿到Glance的endpoint，然后通過訪問該endpoint去獲取Glance服務(wù)。我們可以通過Endpoint的region屬性去定義多個(gè)region。Endpoint 該使用對象分為三類：

admin url –> 給admin用戶使用，Post：35357

internal url –> OpenStack內(nèi)部服務(wù)使用來跟別的服務(wù)通信，Port：5000

public url –> 其它用戶可以訪問的地址，Post：5000

創(chuàng)建完service后創(chuàng)建API EndPoint. 在openstack中，每一個(gè)service都有三種end points. Admin, public, internal。 Admin是用作管理用途的，如它能夠修改user/tenant(project)。 public 是讓客戶調(diào)用的，比如可以部署在外網(wǎng)上讓客戶可以管理自己的云。internal是openstack內(nèi)部調(diào)用的。三種endpoints 在網(wǎng)絡(luò)上開放的權(quán)限一般也不同。Admin通常只能對內(nèi)網(wǎng)開放，public通?？梢詫ν饩W(wǎng)開放internal通常只能對安裝有openstack對服務(wù)的機(jī)器開放。

V3新增

Tenant 重命名為 Project

添加了 Domain 的概念

添加了 Group 的概念

詳細(xì)流程：

用戶alice登錄keystone系統(tǒng)（password或者token的方式），獲取一個(gè)臨時(shí)的token和catalog服務(wù)目錄（v3版本登錄時(shí)，如果沒有指定scope，project或者domain，獲取的臨時(shí)token沒有任何權(quán)限，不能查詢project或者catalog）。

alice通過臨時(shí)token獲取自己的所有的project列表。

alice選定一個(gè)project，然后指定project重新登錄，獲取一個(gè)正式的token，同時(shí)獲得服務(wù)列表的endpoint，用戶選定一個(gè)endpoint，在HTTP消息頭中攜帶token，然后發(fā)送請求（如果用戶知道project name或者project id可以直接第3步登錄）。

消息到達(dá)endpoint之后，由服務(wù)端（nova）的keystone中間件（pipeline中的filter：authtoken）向keystone發(fā)送一個(gè)驗(yàn)證token的請求。（token類型：uuid需要在keystone驗(yàn)證token，pki類型的token本身是包含用戶詳細(xì)信息的加密串，可以在服務(wù)端完成驗(yàn)證）

keystone驗(yàn)證token成功之后，將token對應(yīng)用戶的詳細(xì)信息，例如：role，username，userid等，返回給服務(wù)端（nova）。

服務(wù)端（nova）完成請求，例如：創(chuàng)建虛擬機(jī)。

服務(wù)端返回請求結(jié)果給alice。

2.glance

v1

v2

3.nova與cinder

nova主要組成:

nova-api

nova-scheduler

nova-compute

nova-conductor

cinder主要組成:

cinder-api

cinder-scheduler

cinder-volume

cinder各組件功能：

Cinder-api 是 cinder 服務(wù)的 endpoint，提供 rest 接口，負(fù)責(zé)處理 client 請求，并將 RPC 請求發(fā)送至 cinder-scheduler 組件。

Cinder-scheduler 負(fù)責(zé) cinder 請求調(diào)度，其核心部分就是 scheduler_driver, 作為 scheduler manager 的 driver，負(fù)責(zé) cinder-volume 具體的調(diào)度處理，發(fā)送 cinder RPC 請求到選擇的 cinder-volume。

Cinder-volume 負(fù)責(zé)具體的 volume 請求處理，由不同后端存儲(chǔ)提供 volume 存儲(chǔ)空間。目前各大存儲(chǔ)廠商已經(jīng)積極地將存儲(chǔ)產(chǎn)品的 driver 貢獻(xiàn)到 cinder 社區(qū)

cinder架構(gòu)圖：

openstack組件間通信:調(diào)用各組件api提供的rest接口，組件內(nèi)通信:基于rpc(遠(yuǎn)程過程調(diào)用)機(jī)制，而rpc機(jī)制是基于AMQP模型實(shí)現(xiàn)的

從rpc使用的角度出發(fā)，nova，neutron，和cinder的流程是相似的，我們以cinder為例闡述rpc機(jī)制

(參考鏈接：https://www.ibm.com/developerworks/cn/cloud/library/1403_renmm_opestackrpc/)

Openstack 組件內(nèi)部的 RPC（Remote Producer Call）機(jī)制的實(shí)現(xiàn)是基于 AMQP(Advanced Message Queuing Protocol)作為通訊模型，從而滿足組件內(nèi)部的松耦合性。AMQP 是用于異步消息通訊的消息中間件協(xié)議，AMQP 模型有四個(gè)重要的角色:

Exchange：根據(jù) Routing key 轉(zhuǎn)發(fā)消息到對應(yīng)的 Message Queue 中

Routing key：用于 Exchange 判斷哪些消息需要發(fā)送對應(yīng)的 Message Queue

Publisher：消息發(fā)送者，將消息發(fā)送的 Exchange 并指明 Routing Key，以便 Message Queue 可以正確的收到消息

Consumer：消息接受者，從 Message Queue 獲取消息

消息發(fā)布者 Publisher 將 Message 發(fā)送給 Exchange 并且說明 Routing Key。Exchange 負(fù)責(zé)根據(jù) Message 的 Routing Key 進(jìn)行路由，將 Message 正確地轉(zhuǎn)發(fā)給相應(yīng)的 Message Queue。監(jiān)聽在 Message Queue 上的 Consumer 將會(huì)從 Queue 中讀取消息。

Routing Key 是 Exchange 轉(zhuǎn)發(fā)信息的依據(jù)，因此每個(gè)消息都有一個(gè) Routing Key 表明可以接受消息的目的地址，而每個(gè) Message Queue 都可以通過將自己想要接收的 Routing Key 告訴 Exchange 進(jìn)行 binding，這樣 Exchange 就可以將消息正確地轉(zhuǎn)發(fā)給相應(yīng)的 Message Queue。

Publisher可以分為4類：

Direct Publisher發(fā)送點(diǎn)對點(diǎn)的消息；

Topic Publisher采用“發(fā)布——訂閱”模式發(fā)送消息；

Fanout Publisher發(fā)送廣播消息的發(fā)送；

Notify Publisher同Topic Publisher，發(fā)送 Notification 相關(guān)的消息。

Exchange可以分為3類：

Direct Exchange根據(jù)Routing Key進(jìn)行精確匹配，只有對應(yīng)的 Message Queue 會(huì)接受到消息；

Topic Exchange根據(jù)Routing Key進(jìn)行模式匹配，只要符合模式匹配的Message Queue都會(huì)收到消息；

Fanout Exchange將消息轉(zhuǎn)發(fā)給所有綁定的Message Queue。

AMQP消息模型

RPC 發(fā)送請求

Client 端發(fā)送 RPC 請求由 publisher 發(fā)送消息并聲明消息地址，consumer 接收消息并進(jìn)行消息處理，如果需要消息應(yīng)答則返回處理請求的結(jié)果消息。

OpenStack RPC 模塊提供了 rpc.call，rpc.cast, rpc.fanout_cast 三種 RPC 調(diào)用方法，發(fā)送和接收 RPC 請求。

rpc.call 發(fā)送 RPC 請求并返回請求處理結(jié)果，請求處理流程如圖 5 所示，由 Topic Publisher 發(fā)送消息，Topic Exchange 根據(jù)消息地址進(jìn)行消息轉(zhuǎn)發(fā)至對應(yīng)的 Message Queue 中，Topic Consumer 監(jiān)聽 Message Queue，發(fā)現(xiàn)需要處理的消息則進(jìn)行消息處理，并由 Direct Publisher 將請求處理結(jié)果消息，請求發(fā)送方創(chuàng)建 Direct Consumer 監(jiān)聽消息的返回結(jié)果

rpc.cast 發(fā)送 RPC 請求無返回，請求處理流程如圖 6 所示，與 rpc.call 不同之處在于，不需要請求處理結(jié)果的返回，因此沒有 Direct Publisher 和 Direct Consumer 處理。

rpc.fanout_cast 用于發(fā)送 RPC 廣播信息無返回結(jié)果

neutron

neutron包含組件：

neutron-server

neutron-plugin

neutron-agent

neutron各組件功能介紹：

Neutron-server可以理解為一個(gè)專門用來接收Neutron REST API調(diào)用的服務(wù)器，然后負(fù)責(zé)將不同的rest api分發(fā)到不同的neutron-plugin上。

Neutron-plugin可以理解為不同網(wǎng)絡(luò)功能實(shí)現(xiàn)的入口，各個(gè)廠商可以開發(fā)自己的plugin。Neutron-plugin接收neutron-server分發(fā)過來的REST API，向neutron database完成一些信息的注冊，然后將具體要執(zhí)行的業(yè)務(wù)操作和參數(shù)通知給自身對應(yīng)的neutron agent。

Neutron-agent可以直觀地理解為neutron-plugin在設(shè)備上的代理，接收相應(yīng)的neutron-plugin通知的業(yè)務(wù)操作和參數(shù)，并轉(zhuǎn)換為具體的設(shè)備級(jí)操作，以指導(dǎo)設(shè)備的動(dòng)作。當(dāng)設(shè)備本地發(fā)生問題時(shí)，neutron-agent會(huì)將情況通知給neutron-plugin。

Neutron database，顧名思義就是Neutron的數(shù)據(jù)庫，一些業(yè)務(wù)相關(guān)的參數(shù)都存在這里。

Network provider，即為實(shí)際執(zhí)行功能的網(wǎng)絡(luò)設(shè)備，一般為虛擬交換機(jī)（OVS或者Linux Bridge）。

neutron-plugin分為core-plugin和service-plugin兩類。

Core-plugin，Neutron中即為ML2（Modular Layer 2），負(fù)責(zé)管理L2的網(wǎng)絡(luò)連接。ML2中主要包括network、subnet、port三類核心資源，對三類資源進(jìn)行操作的REST API被neutron-server看作Core API，由Neutron原生支持。其中：

Service-plugin，即為除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要實(shí)現(xiàn)L3-L7的網(wǎng)絡(luò)服務(wù)。這些plugin要操作的資源比較豐富，對這些資源進(jìn)行操作的REST API被neutron-server看作Extension API，需要廠家自行進(jìn)行擴(kuò)展。

“Neutron對Quantum的插件機(jī)制進(jìn)行了優(yōu)化，將各個(gè)廠商L2插件中獨(dú)立的數(shù)據(jù)庫實(shí)現(xiàn)提取出來，作為公共的ML2插件存儲(chǔ)租戶的業(yè)務(wù)需求，使得廠商可以專注于L2設(shè)備驅(qū)動(dòng)的實(shí)現(xiàn)，而ML2作為總控可以協(xié)調(diào)多廠商L2設(shè)備共同運(yùn)行”。在Quantum中，廠家都是開發(fā)各自的Service-plugin，不能兼容而且開發(fā)重復(fù)度很高，于是在Neutron中就為設(shè)計(jì)了ML2機(jī)制，使得各廠家的L2插件完全變成了可插拔的，方便了L2中network資源擴(kuò)展與使用。

（注意，以前廠商開發(fā)的L2 plugin跟ML2都存在于neutron/plugins目錄下，而可插拔的ML2設(shè)備驅(qū)動(dòng)則存在于neutron/plugins/ml2/drivers目錄下）

ML2作為L2的總控，其實(shí)現(xiàn)包括Type和Mechanism兩部分，每部分又分為Manager和Driver。Type指的是L2網(wǎng)絡(luò)的類型（如Flat、VLAN、VxLAN等），與廠家實(shí)現(xiàn)無關(guān)。Mechanism則是各個(gè)廠家自己設(shè)備機(jī)制的實(shí)現(xiàn)，如下圖所示。當(dāng)然有ML2，對應(yīng)的就可以有ML3，不過在Neutron中L3的實(shí)現(xiàn)只負(fù)責(zé)路由的功能，傳統(tǒng)路由器中的其他功能（如Firewalls、LB、VPN）都被獨(dú)立出來實(shí)現(xiàn)了，因此暫時(shí)還沒有看到對ML3的實(shí)際需求。

一般而言，neutron-server和各neutron-plugin部署在控制節(jié)點(diǎn)或者網(wǎng)絡(luò)節(jié)點(diǎn)上，而neutron agent則部署在網(wǎng)絡(luò)節(jié)點(diǎn)上和計(jì)算節(jié)點(diǎn)上。我們先來分析控制端neutron-server和neutron-plugin的工作，然后再分析設(shè)備端neutron-agent的工作。

neutron新進(jìn)展(dragon flow):

https://www.ustack.com/blog/neutron-dragonflow/

網(wǎng)絡(luò)模式介紹：

根據(jù)創(chuàng)建網(wǎng)絡(luò)的用戶的權(quán)限，Neutron network 可以分為：

Provider network：管理員創(chuàng)建的和物理網(wǎng)絡(luò)有直接映射關(guān)系的虛擬網(wǎng)絡(luò)。

Tenant network：租戶普通用戶創(chuàng)建的網(wǎng)絡(luò)，物理網(wǎng)絡(luò)對創(chuàng)建者透明，其配置由 Neutorn 根據(jù)管理員在系統(tǒng)中的配置決定。

根據(jù)網(wǎng)絡(luò)的類型，Neutron network 可以分為：

VLANnetwork（虛擬局域網(wǎng)）：基于物理 VLAN 網(wǎng)絡(luò)實(shí)現(xiàn)的虛擬網(wǎng)絡(luò)。共享同一個(gè)物理網(wǎng)絡(luò)的多個(gè) VLAN 網(wǎng)絡(luò)是相互隔離的，甚至可以使用重疊的 IP 地址空間。每個(gè)支持 VLAN network 的物理網(wǎng)絡(luò)可以被視為一個(gè)分離的 VLAN trunk，它使用一組獨(dú)占的 VLAN ID。有效的 VLAN ID 范圍是 1 到 4094。

Flat network：基于不使用 VLAN 的物理網(wǎng)絡(luò)實(shí)現(xiàn)的虛擬網(wǎng)絡(luò)。每個(gè)物理網(wǎng)絡(luò)最多只能實(shí)現(xiàn)一個(gè)虛擬網(wǎng)絡(luò)。

local network（本地網(wǎng)絡(luò)）：一個(gè)只允許在本服務(wù)器內(nèi)通信的虛擬網(wǎng)絡(luò)，不知道跨服務(wù)器的通信。主要用于單節(jié)點(diǎn)上測試。

GRE network （通用路由封裝網(wǎng)絡(luò)）：一個(gè)使用 GRE 封裝網(wǎng)絡(luò)包的虛擬網(wǎng)絡(luò)。GRE 封裝的數(shù)據(jù)包基于 IP 路由表來進(jìn)行路由，因此 GRE network 不和具體的物理網(wǎng)絡(luò)綁定。

VXLAN network（虛擬可擴(kuò)展網(wǎng)絡(luò)）：基于 VXLAN 實(shí)現(xiàn)的虛擬網(wǎng)絡(luò)。同 GRE network 一樣， VXLAN network 中 IP 包的路由也基于 IP 路由表，也不和具體的物理網(wǎng)絡(luò)綁定。

注：在AWS中，該概念對應(yīng) VPC 概念。AWS 對 VPC 的數(shù)目有一定的限制，比如每個(gè)賬戶在每個(gè) region 上默認(rèn)最多只能創(chuàng)建 5 個(gè)VPC，通過特別的要求最多可以創(chuàng)建 100 個(gè)。

1.vlan

2.gre與vxlan請參考

http://www.cnblogs.com/sammyliu/p/4622563.html

http://www.cnblogs.com/xingyun/p/4620727.html

gre網(wǎng)絡(luò)

gre與vxlan區(qū)別

關(guān)于gre和vxlan二次封裝數(shù)據(jù)包的MTU問題

VXLAN 模式下虛擬機(jī)中的 mtu 最大值為1450，也就是只能小于1450，大于這個(gè)值會(huì)導(dǎo)致 openvswitch 傳輸分片，進(jìn)而導(dǎo)致虛擬機(jī)中數(shù)據(jù)包數(shù)據(jù)重傳，從而導(dǎo)致網(wǎng)絡(luò)性能下降。GRE 模式下虛擬機(jī) mtu 最大為1462。

計(jì)算方法如下：

vxlan mtu = 1450 = 1500 – 20(ip頭) – 8(udp頭) – 8(vxlan頭) – 14(以太網(wǎng)頭)

gre mtu = 1462 = 1500 – 20(ip頭) – 4(gre頭) – 14(以太網(wǎng)頭)

可以配置 Neutron DHCP 組件，讓虛擬機(jī)自動(dòng)配置 mtu，

#/etc/neutron/dhcp_agent.ini[DEFAULT]dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf#/etc/neutron/dnsmasq-neutron.confdhcp-option-force=26,1450或1462

重啟 DHCP Agent，讓虛擬機(jī)重新獲取 IP，然后使用 ifconfig 查看是否正確配置 mtu。