目錄：
爲何選擇雲計算/雲計算之前遇到的問題
什麼是雲計算
雲服務模式
雲應用形式
傳統應用與雲感知應用
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
功能：負責響應虛擬機創建請求、調度、銷燬雲主機
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)：可以理解爲一個人、或服務所擁有的 資源集合 。在一個Project(Tenant)中可以包含多個User，每一個User都會根據權限的劃分來使用Project(Tenant)中的資源。比如通過Nova創建虛擬機時要指定到某個Project中，在Cinder創建卷也要指定到某個Project中。User訪問Project的資源前，必須要與該Project關聯，並且指定User在Project下的Role。
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包含了在 指定範圍和有效時間內 可以被訪問的資源。EG. 在Nova中一個tenant可以是一些虛擬機，在Swift和Glance中一個tenant可以是一些鏡像存儲，在Network中一個tenant可以是一些網絡資源。Token一般被User持有。
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、***、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、***）都被獨立出來實現了，因此暫時還沒有看到對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
http://www.cnblogs.com/xingyun/p/4620727.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。