轉自：https://www.cnblogs.com/pythonxiaohu/p/5861409.html
目錄：
為何選擇雲端計算/雲端計算之前遇到的問題
什麼是雲端計算
雲服務模式
雲應用形式
傳統應用與雲感知應用
openstack及其相關元件介紹
flat/vlan/gre/vxlan介紹
分散式儲存ceph介紹
openstack mitaka三節點部署實戰
一：為何選擇雲端計算/雲端計算之前遇到的問題
一、有效解決硬體單點故障問題
單點故障是指某個硬體的故障造成網站某個服務的中斷。要真正解決這個問題，需要為每個硬體準備冗餘，這不僅大大增加了硬體購置成本，而且部署與維護成本也不容小視。
而云計算平臺是基於伺服器叢集，從設計之初就考慮了單點故障問題，並在建設時有效地解決了這個問題。如果一家雲服務商出現單點故障問題，就如同存在銀行的錢丟了。
二、按需增/減硬體資源
自己託管伺服器，增/減硬體一直是頭疼的問題。
1. 增加伺服器的時候，購買伺服器需要時間，而且這個時間自己無法控制。而使用雲伺服器，隨時可以增加伺服器——垂手可得。
2. 減伺服器只能從機房拉回辦公室，無法再把伺服器退給廠商，購置伺服器的成本就浪費了。而使用雲伺服器，如果下個月不用，不續費就行了（針對阿里雲按月購買的情況）——想用就用，想扔就扔。
3. 不能按需增加滿足基本需求的伺服器配置。假如我們現在需要一臺低配置的伺服器用Linux跑快取服務，如果為之單獨購買一臺便宜的低配置的伺服器很不合算，因為這臺伺服器僅僅一年的電費就至少要3000元左右。所以只能儘量減少伺服器數量，提高單臺伺服器的配置，在讓一臺伺服器跑更多東西。而使用雲伺服器，需要什麼樣的配置就買什麼樣的配置，讓各個伺服器的職責更單一，互相之間的影響更小——職責分明，效率更高。
三、BGP線路解決南北互通問題
南北互通問題是南方電信與北方聯通線路之間的互通問題，這個問題困擾我們多年，之前用過雙線機房，解決的也不是很好。目前只有BGP線路才能有效解決這個問題，而擁有真正的BGP線路的機房不是很多，成本也非常高。而我準備使用的阿里雲用的就是BGP線路，這也是吸引我們的主要地方之一。
究竟什麼是南北互通問題？基於我們的理解簡體描述一下，不對之處歡迎指出。南北互通問題實際就是路由問題。假設我們的伺服器放在上海電信的機房，上海一位聯通的使用者訪問我們的伺服器，要先繞到聯通的北京總出口（假設總出口在北京），然後再繞回上海。實際上這位聯通使用者可以通過上海的線路直接到達我們的伺服器，不用繞這麼遠，但上海電信的機房無法告知聯通的路由器走近路過來，只能按照聯通路由器設定好的路由走。本來即使走北京繞一下也沒有大的影響，畢竟是光的速度，但是由於大多數聯通的使用者訪問電信網路都這麼繞著走，聯通的總出口成為了瓶頸，總出口流量太大時，聯通的使用者訪問電信的網路速度就會慢。BGP線路也沒什麼神奇之處，只是它能決定走什麼路由過來，不繞遠路，問題自然解決了。它有這樣的特權，就不僅能解決南北互通的問題，而且能解決其他網路的互通問題，比如教育網。因為有許可權決定路由，就可以優化路由，哪條路堵，我就換條路。
四、按需增/減頻寬
頻寬是主要成本，託管伺服器時，與ISP服務商籤一年合同之前就要確定頻寬。用了一段時間之後，你發現頻寬買多了，想減一些是不允許的。中途要臨時增加頻寬一段時間也是不行的，要買就買一年（這是根據我們接觸過的ISP服務商）。所以，一般都會多買一些頻寬，留一些餘量。
使用雲伺服器可以靈活地增減頻寬，不會浪費頻寬，即使買少了也不用擔心，隨時可以增加。雖然各個雲服務商會有一定的限制，比如在阿里雲一次至少要購買1個月的頻寬，但比自己託管伺服器靈活很多，同樣的頻寬條件，會節省不少成本，尤其是頻寬需求在一年中變化比較大的網站。
五、更有吸引力的費用支付方式
在IDC機房託管伺服器一般是籤一年合同，一次支付一個季度的費用。
而使用雲服務，一次可以支付更短時間的費用，比如阿里雲可以一次只支付一個月的費用，節約了流動資金。
從總體上考慮，差不多的成本，卻擁有更多的記憶體、更多的CPU、更多的硬碟空間、更優質的頻寬線路，更重要的是可以隨時按需擴充套件計算資源。
二：什麼是雲端計算（資源和服務的互動方式）
一、概念分解：
雲：雲端計算中的雲,代表迴圈利用的意思(雲多了變成雨，落到地面，雲減少，水蒸發到空中，雲增加)。
計算：雲端計算中的計算,代表計算資源，涵蓋虛機、儲存、網路等。
雲端計算：代表計算資源向雲水迴圈一樣，按需分配，迴圈利用。
附：企業資料中心部署在雲端計算分散式平臺上,類似於從原來單臺發電機轉向電廠集中供電模式,它意味著訪問計算機和儲存系統也可以作為一種商品流通,就像煤氣、水電一樣，取用方便，費用低廉，只不過它是通過網際網路傳輸的,雲就是網際網路的一種比喻
二、雲端計算分類：
狹義：IT基礎設施的互動和使用模式，通過網路以按需，易擴充套件的方式獲取資源
廣義：服務（IT基礎設施、軟體等）的互動和使用模式，通過網路以按需、易擴充套件的方式獲取資源。
三：雲服務模式
一、IaaS：基礎設施即服務
使用者通過網路獲取虛機、儲存、網路，然後使用者根據自己的需求操作獲取的資源。 典型應用：亞馬遜AWS等
二、PaaS：平臺即服務
將軟體研發平臺作為一種服務， 如Eclipse/Java程式設計平臺，服務商提供程式設計介面/執行平臺等。典型應用：Google AppEngine、Force.com、微軟Azure等
三、SaaS：軟體即服務
將軟體作為一種服務通過網路提供給使用者，如web的電子郵件、HR系統、訂單管理系統、客戶關係系統等。使用者無需購買軟體，而是向提供商租用基於web的軟體，來管理企業經營活動。典型應用：Google Doc、Saleforce.com、Oracle CRM On Demand、Office Live Workspace等
四：雲應用形式
一.私有云
將基礎設施與軟硬體資源構建於防火牆內，基於iaas構建私有云平臺供企業內部使用，開源元件有：openstack（最為出色），cloudstack等
二.雲端儲存
雲端儲存系統是一個以資料儲存和管理為核心的雲端計算系統
三.雲遊戲
遊戲執行雲平臺服務端，雲平臺將遊戲畫面解壓縮後傳給使用者，使用者端無需高配置處理器和顯示卡，只需要基本的視訊解壓縮能力即可。
四.雲物聯
基於雲平臺實現物物相連的網際網路。
五.雲安全
通過網狀的大量客戶端檢測網路中軟體的異常,獲取木馬，惡意程式的最新資訊，推送到雲平臺服務端自動分析和處理，再把解決方案傳送給每一個客戶端。雲平臺使用者越多，越安全。
六.公有云
雲平臺對外開放，主要以Iaas和Paas為主，較為成熟的是Iaas，如阿里雲，騰訊雲，青雲，ucloud，首都線上等
七.混合雲
公有云和私有云的結合，即對企業內部又對企業外部，例如AWS
五：傳統應用與雲感知應用
一、傳統應用
傳統應用像養寵物，寵物病了要細心呵護
每個應用都是獨特的、專門的
專門的伺服器、硬體和軟體保證可靠性
資源不夠，增加cpu、記憶體、磁碟
專門的技術支援
二、雲感知應用
雲感知應用像養牛，牛生病了，你需要一頭新的牛
應用跑在一個或多個虛擬機器裡
資源不夠，增加新的虛擬機器
應用掛起，重啟或建立新的虛擬機器
六：openstack與及其相關元件介紹
一、openstack由來
openstack最早由美國國家航空航天局NASA研發的Nova和Rackspace研發的swift組成。後來以apache許可證授權,旨在為公共及私有云平臺建設。openstack主要用來為企業內部實現類似於Amazon EC2和S3的雲基礎架構服務（Iaas）.每6個月更新一次，基本與ubuntu同步，命名是以A-Z作為首字母來的。
二、openstack專案與元件（服務名是專案名的別名）
核心專案3個
1.控制檯
服務名：Dashboard
專案名：Horizon
功能：web方式管理雲平臺，建雲主機，分配網路，配安全組，加雲盤
2.計算
服務名：計算
專案名：Nova
nbsp; 功能：負責響應虛擬機器建立請求、排程、銷燬雲主機
3.網路
服務名：網路
專案名：Neutron
功能：實現SDN（軟體定義網路），提供一整套API,使用者可以基於該API實現自己定義專屬網路，不同廠商可以基於此API提供自己的產品實現
儲存專案2個
1.物件儲存
服務名：物件儲存
專案名：Swift
功能：REST風格的介面和扁平的資料組織結構。RESTFUL HTTP API來儲存和訪問任意非結構化資料，ring環的方式實現資料自動複製和高度可以擴充套件架構，保證資料的高度容錯和可靠性
2.塊儲存
服務名：塊儲存
專案名：Cinder
功能：提供持久化塊儲存，即為雲主機提供附加雲盤。
共享服務專案3個
1.認證服務
服務名：認證服務
專案名：Keystone
功能：為訪問openstack各元件提供認證和授權功能，認證通過後，提供一個服務列表（存放你有權訪問的服務），可以通過該列表訪問各個元件。
2.映象服務
服務名：映象服務
專案名：Glance
功能：為雲主機安裝作業系統提供不同的映象選擇
3.計費服務
服務名：計費服務
專案名：Ceilometer
功能：收集雲平臺資源使用資料，用來計費或者效能監控
高層服務專案1個
1.編排服務
服務名：編排服務
專案名：Heat
功能：自動化部署應用，自動化管理應用的整個生命週期.主要用於Paas
三、openstack各元件詳解及執行流程
各元件邏輯關係圖：
openstack新建雲主機流程圖:
虛擬機器啟動過程如下：
介面或命令列通過RESTful API向keystone獲取認證資訊。
keystone通過使用者請求認證資訊，並生成auth-token返回給對應的認證請求。
介面或命令列通過RESTful API向nova-api傳送一個boot instance的請求（攜帶auth-token）。
nova-api接受請求後向keystone傳送認證請求，檢視token是否為有效使用者和token。
keystone驗證token是否有效，如有效則返回有效的認證和對應的角色（注：有些操作需要有角色許可權才能操作）。
通過認證後nova-api和資料庫通訊。
初始化新建虛擬機器的資料庫記錄。
nova-api通過rpc.call向nova-scheduler請求是否有建立虛擬機器的資源(Host ID)。
nova-scheduler程式偵聽訊息佇列，獲取nova-api的請求。
nova-scheduler通過查詢nova資料庫中計算資源的情況，並通過排程演算法計算符合虛擬機器建立需要的主機。
對於有符合虛擬機器建立的主機，nova-scheduler更新資料庫中虛擬機器對應的物理主機資訊。
nova-scheduler通過rpc.cast向nova-compute傳送對應的建立虛擬機器請求的訊息。
nova-compute會從對應的訊息佇列中獲取建立虛擬機器請求的訊息。
nova-compute通過rpc.call向nova-conductor請求獲取虛擬機器訊息。（Flavor）
nova-conductor從訊息隊佇列中拿到nova-compute請求訊息。
nova-conductor根據訊息查詢虛擬機器對應的資訊。
nova-conductor從資料庫中獲得虛擬機器對應資訊。
nova-conductor把虛擬機器資訊通過訊息的方式傳送到訊息佇列中。
nova-compute從對應的訊息佇列中獲取虛擬機器資訊訊息。
nova-compute通過keystone的RESTfull API拿到認證的token，並通過HTTP請求glance-api獲取建立虛擬機器所需要映象。
glance-api向keystone認證token是否有效，並返回驗證結果。
token驗證通過，nova-compute獲得虛擬機器映象資訊(URL)。
nova-compute通過keystone的RESTfull API拿到認證k的token，並通過HTTP請求neutron-server獲取建立虛擬機器所需要的網路資訊。
neutron-server向keystone認證token是否有效，並返回驗證結果。
token驗證通過，nova-compute獲得虛擬機器網路資訊。
nova-compute通過keystone的RESTfull API拿到認證的token，並通過HTTP請求cinder-api獲取建立虛擬機器所需要的持久化儲存資訊。
cinder-api向keystone認證token是否有效，並返回驗證結果。
token驗證通過，nova-compute獲得虛擬機器持久化儲存資訊。
nova-compute根據instance的資訊呼叫配置的虛擬化驅動來建立虛擬機器。
下面我們就圍繞上圖流程展開
1.keystone
User：指使用Openstack service的使用者，可以是人、服務、系統，但凡使用了Openstack service的物件都可以稱為User。
Project(Tenant)：可以理解為一個人、或服務所擁有的
Role：用於劃分許可權。可以通過給User指定Role，使User獲得Role對應的操作許可權。Keystone返回給User的Token包含了Role列表，被訪問的Services會判斷訪問它的User和User提供的Token中所包含的Role。系統預設使用管理Role admin和成員Role _member_ 。
Policy：OpenStack對User的驗證除了OpenStack的身份驗證以外，還需要鑑別User對某個Service是否有訪問許可權。Policy機制就是用來控制User對Tenant中資源(包括Services)的操作許可權。對於Keystone service來說，Policy就是一個JSON檔案，預設是/etc/keystone/policy.json。通過配置這個檔案，Keystone Service實現了對User基於Role的許可權管理。
Token：是一個字串表示，作為訪問資源的令牌。Token包含了在
Credentials：用於確認使用者身份的憑證
Authentication：確定使用者身份的過程
Service：Openstack service，即Openstack中執行的元件服務。
Endpoint：一個可以通過網路來訪問和定位某個Openstack service的地址，通常是一個URL。比如，當Nova需要訪問Glance服務去獲取image 時，Nova通過訪問Keystone拿到Glance的endpoint，然後通過訪問該endpoint去獲取Glance服務。我們可以通過Endpoint的region屬性去定義多個region。Endpoint 該使用物件分為三類：
admin url –> 給admin使用者使用，Post：35357
internal url –> OpenStack內部服務使用來跟別的服務通訊，Port：5000
public url –> 其它使用者可以訪問的地址，Post：5000
建立完service後建立API EndPoint. 在openstack中，每一個service都有三種end points. Admin, public, internal。 Admin是用作管理用途的，如它能夠修改user/tenant(project)。 public 是讓客戶呼叫的，比如可以部署在外網上讓客戶可以管理自己的雲。internal是openstack內部呼叫的。三種endpoints 在網路上開放的許可權一般也不同。Admin通常只能對內網開放，public通常可以對外網開放internal通常只能對安裝有openstack對服務的機器開放。
V3新增
Tenant 重新命名為 Project
新增了 Domain 的概念
新增了 Group 的概念
使用者alice登入keystone系統（password或者token的方式），獲取一個臨時的token和catalog服務目錄（v3版本登入時，如果沒有指定scope，project或者domain，獲取的臨時token沒有任何許可權，不能查詢project或者catalog）。
alice通過臨時token獲取自己的所有的project列表。
alice選定一個project，然後指定project重新登入，獲取一個正式的token，同時獲得服務列表的endpoint，使用者選定一個endpoint，在HTTP訊息頭中攜帶token，然後傳送請求（如果使用者知道project name或者project id可以直接第3步登入）。
訊息到達endpoint之後，由服務端（nova）的keystone中介軟體（pipeline中的filter：authtoken）向keystone傳送一個驗證token的請求。（token型別：uuid需要在keystone驗證token，pki型別的token本身是包含使用者詳細資訊的加密串，可以在服務端完成驗證）
keystone驗證token成功之後，將token對應使用者的詳細資訊，例如：role，username，userid等，返回給服務端（nova）。
服務端（nova）完成請求，例如：建立虛擬機器。
服務端返回請求結果給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 服務的 endpoint，提供 rest 介面，負責處理 client 請求，並將 RPC 請求傳送至 cinder-scheduler 元件。
Cinder-scheduler 負責 cinder 請求排程，其核心部分就是 scheduler_driver, 作為 scheduler manager 的 driver，負責 cinder-volume 具體的排程處理，傳送 cinder RPC 請求到選擇的 cinder-volume。
Cinder-volume 負責具體的 volume 請求處理，由不同後端儲存提供 volume 儲存空間。目前各大儲存廠商已經積極地將儲存產品的 driver 貢獻到 cinder 社群
cinder架構圖：
openstack元件間通訊:呼叫各元件api提供的rest介面，元件內通訊:基於rpc(遠端過程呼叫)機制，而rpc機制是基於AMQP模型實現的
從rpc使用的角度出發，nova，neutron，和cinder的流程是相似的，我們以cinder為例闡述rpc機制
(參考連結：https://www.ibm.com/developerworks/cn/cloud/library/1403_renmm_opestackrpc/)
Openstack 元件內部的 RPC（Remote Producer Call）機制的實現是基於 AMQP(Advanced Message Queuing Protocol)作為通訊模型，從而滿足元件內部的鬆耦合性。AMQP 是用於非同步訊息通訊的訊息中介軟體協議，AMQP 模型有四個重要的角色:
Exchange：根據 Routing key 轉發訊息到對應的 Message Queue 中
Routing key：用於 Exchange 判斷哪些訊息需要傳送對應的 Message Queue
Publisher：訊息傳送者，將訊息傳送的 Exchange 並指明 Routing Key，以便 Message Queue 可以正確的收到訊息
Consumer：訊息接受者，從 Message Queue 獲取訊息
訊息釋出者 Publisher 將 Message 傳送給 Exchange 並且說明 Routing Key。Exchange 負責根據 Message 的 Routing Key 進行路由，將 Message 正確地轉發給相應的 Message Queue。監聽在 Message Queue 上的 Consumer 將會從 Queue 中讀取訊息。
Routing Key 是 Exchange 轉發資訊的依據，因此每個訊息都有一個 Routing Key 表明可以接受訊息的目的地址，而每個 Message Queue 都可以通過將自己想要接收的 Routing Key 告訴 Exchange 進行 binding，這樣 Exchange 就可以將訊息正確地轉發給相應的 Message Queue。
Publisher可以分為4類：
Direct Publisher傳送點對點的訊息；
Topic Publisher採用“釋出——訂閱”模式傳送訊息；
Fanout Publisher傳送廣播訊息的傳送；
Notify Publisher同Topic Publisher，傳送 Notification 相關的訊息。
Exchange可以分為3類：
1.Direct Exchange根據Routing Key進行精確匹配，只有對應的 Message Queue 會接受到訊息；
2.Topic Exchange根據Routing Key進行模式匹配，只要符合模式匹配的Message Queue都會收到訊息；
3.Fanout Exchange將訊息轉發給所有繫結的Message Queue。
AMQP訊息模型
RPC 傳送請求
Client 端傳送 RPC 請求由 publisher 傳送訊息並宣告訊息地址，consumer 接收訊息並進行訊息處理，如果需要訊息應答則返回處理請求的結果訊息。
OpenStack RPC 模組提供了 rpc.call，rpc.cast, rpc.fanout_cast 三種 RPC 呼叫方法，傳送和接收 RPC 請求。
1.rpc.call 傳送 RPC 請求並返回請求處理結果，請求處理流程如圖 5 所示，由 Topic Publisher 傳送訊息，Topic Exchange 根據訊息地址進行訊息轉發至對應的 Message Queue 中，Topic Consumer 監聽 Message Queue，發現需要處理的訊息則進行訊息處理，並由 Direct Publisher 將請求處理結果訊息，請求傳送方建立 Direct Consumer 監聽訊息的返回結果
2.rpc.cast 傳送 RPC 請求無返回，請求處理流程如圖 6 所示，與 rpc.call 不同之處在於，不需要請求處理結果的返回，因此沒有 Direct Publisher 和 Direct Consumer 處理。
3.rpc.fanout_cast 用於傳送 RPC 廣播資訊無返回結果
4.neutron
neutron包含元件：
neutron-server
neutron-plugin
neutron-agent
neutron各元件功能介紹：
1.Neutron-server可以理解為一個專門用來接收Neutron REST API呼叫的伺服器，然後負責將不同的rest api分發到不同的neutron-plugin上。
2.Neutron-plugin可以理解為不同網路功能實現的入口，各個廠商可以開發自己的plugin。Neutron-plugin接收neutron-server分發過來的REST API，向neutron database完成一些資訊的註冊，然後將具體要執行的業務操作和引數通知給自身對應的neutron agent。
3.Neutron-agent可以直觀地理解為neutron-plugin在裝置上的代理，接收相應的neutron-plugin通知的業務操作和引數，並轉換為具體的裝置級操作，以指導裝置的動作。當裝置本地發生問題時，neutron-agent會將情況通知給neutron-plugin。
4.Neutron database，顧名思義就是Neutron的資料庫，一些業務相關的引數都存在這裡。
5.Network provider，即為實際執行功能的網路裝置，一般為虛擬交換機（OVS或者Linux Bridge）。
neutron-plugin分為core-plugin和service-plugin兩類。
Core-plugin，Neutron中即為ML2（Modular Layer 2），負責管理L2的網路連線。ML2中主要包括network、subnet、port三類核心資源，對三類資源進行操作的REST API被neutron-server看作Core API，由Neutron原生支援。其中：
Service-plugin，即為除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要實現L3-L7的網路服務。這些plugin要操作的資源比較豐富，對這些資源進行操作的REST API被neutron-server看作Extension API，需要廠家自行進行擴充套件。
“Neutron對Quantum的外掛機制進行了優化，將各個廠商L2外掛中獨立的資料庫實現提取出來，作為公共的ML2外掛儲存租戶的業務需求，使得廠商可以專注於L2裝置驅動的實現，而ML2作為總控可以協調多廠商L2裝置共同執行”。在Quantum中，廠家都是開發各自的Service-plugin，不能相容而且開發重複度很高，於是在Neutron中就為設計了ML2機制，使得各廠家的L2外掛完全變成了可插拔的，方便了L2中network資源擴充套件與使用。
（注意，以前廠商開發的L2 plugin跟ML2都存在於neutron/plugins目錄下，而可插拔的ML2裝置驅動則存在於neutron/plugins/ml2/drivers目錄下）
ML2作為L2的總控，其實現包括Type和Mechanism兩部分，每部分又分為Manager和Driver。Type指的是L2網路的型別（如Flat、VLAN、VxLAN等），與廠家實現無關。Mechanism則是各個廠家自己裝置機制的實現，如下圖所示。當然有ML2，對應的就可以有ML3，不過在Neutron中L3的實現只負責路由的功能，傳統路由器中的其他功能（如Firewalls、LB、VPN）都被獨立出來實現了，因此暫時還沒有看到對ML3的實際需求。
一般而言，neutron-server和各neutron-plugin部署在控制節點或者網路節點上，而neutron agent則部署在網路節點上和計算節點上。我們先來分析控制端neutron-server和neutron-plugin的工作，然後再分析裝置端neutron-agent的工作。
neutron新進展(dragon flow):
https://www.ustack.com/blog/neutron-dragonflow/
網路模式介紹：
根據建立網路的使用者的許可權，Neutron network 可以分為：
Provider network：管理員建立的和物理網路有直接對映關係的虛擬網路。
Tenant network：租戶普通使用者建立的網路，物理網路對建立者透明，其配置由 Neutorn 根據管理員在系統中的配置決定。
根據網路的型別，Neutron network 可以分為：
VLAN network（虛擬區域網） ：基於物理 VLAN 網路實現的虛擬網路。共享同一個物理網路的多個 VLAN 網路是相互隔離的，甚至可以使用重疊的 IP 地址空間。每個支援 VLAN network 的物理網路可以被視為一個分離的 VLAN trunk，它使用一組獨佔的 VLAN ID。有效的 VLAN ID 範圍是 1 到 4094。
Flat network：基於不使用 VLAN 的物理網路實現的虛擬網路。每個物理網路最多隻能實現一個虛擬網路。
local network（本地網路）：一個只允許在本伺服器內通訊的虛擬網路，不知道跨伺服器的通訊。主要用於單節點上測試。
GRE network （通用路由封裝網路）：一個使用 GRE 封裝網路包的虛擬網路。GRE 封裝的資料包基於 IP 路由表來進行路由，因此 GRE network 不和具體的物理網路繫結。
VXLAN network（虛擬可擴充套件網路）：基於 VXLAN 實現的虛擬網路。同 GRE network 一樣， VXLAN network 中 IP 包的路由也基於 IP 路由表，也不和具體的物理網路繫結。
注：在AWS中，該概念對應 VPC 概念。AWS 對 VPC 的數目有一定的限制，比如每個賬戶在每個 region 上預設最多隻能建立 5 個VPC，通過特別的要求最多可以建立 100 個。
1.vlan
2.gre與vxlan請參考
http://www.cnblogs.com/sammyliu/p/4622563.html
gre網路
gre與vxlan區別
關於gre和vxlan二次封裝資料包的MTU問題
VXLAN 模式下虛擬機器中的 mtu 最大值為1450，也就是隻能小於1450，大於這個值會導致 openvswitch 傳輸分片，進而導致虛擬機器中資料包資料重傳，從而導致網路效能下降。GRE 模式下虛擬機器 mtu 最大為1462。
計算方法如下：
vxlan mtu = 1450 = 1500 – 20(ip頭) – 8(udp頭) – 8(vxlan頭) – 14(乙太網頭)
gre mtu = 1462 = 1500 – 20(ip頭) – 4(gre頭) – 14(乙太網頭)
可以配置 Neutron DHCP 元件，讓虛擬機器自動配置 mtu，
#/etc/neutron/dhcp_agent.ini
[DEFAULT]
dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf#/etc/neutron/dnsmasq-neutron.conf
dhcp-option-force=26,1450或1462複製程式碼重啟 DHCP Agent，讓虛擬機器重新獲取 IP，然後使用 ifconfig 檢視是否正確配置 mtu。