什么是雲計算
概念
雲計算是一種基於互聯網的計算方式，通過這種方式，共享的軟硬件資源和信息，可以按需求提供給計算機和其他設備。用戶不需要了解”雲“中的基礎設施細節，不必具有相應的專業知識，也無需直接控制。雲計算描述了一種基於互聯網的新的IT服務增加、使用和交付模式。
我們舉一個例子來理解雲計算，雲計算中的”雲“可以理解為天上的雲，天上的雲可以變成雨水降落到地上，落到地上的水蒸發后又變成雲彩。這樣就形成了一個循環。
這里的雨水表示計算資源，比如虛擬機、存儲、網絡等等。
雲變水的過程表示獲取資源的過程。
水變雲的過程表示資源回收的過程。
雲計算就像雲水的循環過程一樣，按需分配，循環利用。
為什么需要雲計算
雲計算的本質是希望解決資源利用率、計算能力不足和成本的問題。
- 有效解決硬件單點故障的問題
- 單點故障會造成服務的中斷，要解決單點故障，需要為每個硬件准備備用硬件，不但增加了硬件購置成本，部署與維護成本也大。
- 按需增減資源
這里的資源指的是硬件、帶寬等。自己管理服務器會面臨一個很頭疼的問題，
- 增加服務的時候，需要購買服務器，購買服務器需要時間；使用雲服務器的時候，可隨時增加素驅動的結果：需求拉動和技術推動。業務需求的拉動，希望解決業務應用的問題，雲計算本質上是希望解決資源利用率、計算能力不足和成本的問題。技術發展的推動，使得雲計算具備了技術上的可行性，技術的發展推動了IT創新的商業價值。雲計算的出現也有其必然性。
- 減少服務的時候，需要把購置的服務器取下，服務器會退還給廠商或者閑置下來，而雲服務器不用的時候，直接不續費就好了（比如說阿里雲）
- 在未使用雲服務器之前，加入我們需要一台低配置的服務器運行一個服務，服務器需要空間存放，每年的耗電量也不小，因此都是使用一台服務器運行多個服務來降低服務器的購買和維護成本；而使用雲服務器之后，需要什么樣的配置，直接購買即可，對服務器的職責進行分離，減少各個服務之間的互相影響，效率更高。
- 在托管服務器的時候，我們需要購買帶寬，一般在與ISP服務商簽訂合同之前需要確定帶寬大小，當后期發現購買的帶寬過多或者過少的時候，是無法減小或增加帶寬的； 使用雲服務器之后，可以靈活的增減帶寬，可以隨時對帶寬進行增減。舉個例子，對類似於淘寶的電商網站，假設每年只有雙11和雙12期間需要大量帶寬，其他時間網站流量很小，這個時候使用雲服務器就可以針對雙11和雙12增加帶寬，其他時間只要保持一般的流量就可以了。
- 更好的費用支付方式
- 一般在IDC托管服務器的時候，合同都是以年為單位簽訂合同，一次支付一個季度的費用； 而使用雲服務器， 可以支付更短時間內的費用，像阿里雲可以按照月為單位進行支付， 或者按照使用量來購買，比如按照網絡流量支付費用。
- BGP解決南北線路問題
- 寬帶市場一直有”南電信北聯通“的問題（即中國聯通的根基在北方市場、中國電信的根基在南方市場），所以我們需要考慮南北互通的問題，即路由問題。比如說，南方的聯通用戶，在訪問上海電信機房的服務器的時候，先要繞路到聯通的北京總出口（假設在北京），再回到上海。雖然使用光纖的速度很快，但是當聯通的總出口出現瓶頸，無法負擔巨大的網絡流量時，聯通的用戶訪問電信網絡的服務器就會變慢。BGP就解決了南北互通時的繞路問題，優化了線路。
雲計算服務模式
雲計算有三種模式：
- IaaS：基礎設施即服務——消費者使用“基礎計算資源”，如處理能力、存儲空間、網絡組件或中間件。消費者能掌控操作系統、存儲空間、已部署的應用程序及網絡組件（如防火牆、負載平衡器等），但並不掌控雲基礎架構。例如：Amazon AWS、Rackspace。
- PasS：平台即服務——消費者使用主機操作應用程序。消費者掌控運作應用程序的環境（也擁有主機部分掌控權），但並不掌控操作系統、硬件或運作的網絡基礎架構。平台通常是應用程序基礎架構。例如：Google App Engine。
- SaaS： 軟件即服務——消費者使用應用程序，但並不掌控操作系統、硬件或運作的網絡基礎架構。是一種服務觀念的基礎，軟件服務供應商，以租賃的概念提供客戶服務，而非購買，比較常見的模式是提供一組賬號密碼。例如：Microsoft CRM與Salesforce.com。
雲計算應用
- 公有雲 —— 公用雲服務可通過網絡及第三方服務供應者，開放給客戶使用，“公用”一詞並不一定代表“免費”，但也可能代表免費或相當廉價，公用雲並不表示用戶數據可供任何人查看，公用雲供應者通常會對用戶實施使用訪問控制機制，公用雲作為解決方案，既有彈性，又具備成本效益。
- 私有雲 —— 私有雲具備許多公用雲環境的優點，例如彈性、適合提供服務，兩者差別在於私有雲服務中，數據與程序皆在組織內管理，且與公用雲服務不同，不會受到網絡帶寬、安全疑慮、法規限制影響；此外，私有雲服務讓供應者及用戶更能掌控雲基礎架構、改善安全與彈性，因為用戶與網絡都受到特殊限制。
- 雲物聯 —— “物聯網就是物物相連的互聯網”。這有兩層意思：第一，物聯網的核心和基礎仍然是互聯網，是在互聯網基礎上的延伸和擴展的網絡；第二，其用戶端延伸和擴展到了任何物品與物品之間，進行信息交換和通信。
- 雲存儲 —— 雲存儲是在雲計算(cloud computing)概念上延伸和發展出來的一個新的概念，是指通過集群應用、網格技術或分布式文件系統等功能，將網絡中大量各種不同類型的存儲設備通過應用軟件集合起來協同工作，共同對外提供數據存儲和業務訪問功能的一個系統。 當雲計算系統運算和處理的核心是大量數據的存儲和管理時，雲計算系統中就需要配置大量的存儲設備，那么雲計算系統就轉變成為一個雲存儲系統，所以雲存儲是一個以數據存儲和管理為核心的雲計算系統。
- 雲游戲 —— 雲游戲是以雲計算為基礎的游戲方式，在雲游戲的運行模式下，所有游戲都在服務器端運行，並將渲染完畢后的游戲畫面壓縮后通過網絡傳送給用戶。在客戶端，用戶的游戲設備不需要任何高端處理器和顯卡，只需要基本的視頻解壓能力就可以了。
- 雲安全 —— 雲安全(Cloud Security)是一個從“雲計算”演變而來的新名詞。雲安全的策略構想是：使用者越多，每個使用者就越安全，因為如此龐大的用戶群，足以覆蓋互聯網的每個角落，只要某個網站被掛馬或某個新木馬病毒出現，就會立刻被截獲。 “雲安全”通過網狀的大量客戶端對網絡中軟件行為的異常監測，獲取互聯網中木馬、惡意程序的最新信息，推送到Server端進行自動分析和處理，再把病毒和木馬的解決方案分發到每一個客戶端。
- 混合雲 —— 混合雲結合公用雲及私有雲，這個模式中，用戶通常將非企業關鍵信息外包，並在公用雲上處理，但同時掌控企業關鍵服務及數據。
OpenStack
OpenStack 簡介
OpenStack是一個由NASA（美國國家航空航天局）和Rackspace合作研發並發起的，以Apache許可證授權的自由軟件和開放源代碼項目。作為一個開源的雲計算管理平台項目，旨在為公共及私有雲的建設與管理提供軟件的開源項目，幫助服務商和企業內部實現類似於 Amazon EC2 和 S3 的雲基礎架構服務(Infrastructure as a Service, IaaS)。
OpenStack項目及組件
- 控制台
服務名：Dashboard
項目名：Horzon
功能：提供一個Web前端控制台,以此來展示OpenStack的功能. - 計算
服務名：計算（Compute）
項目名：Nova
功能：一套控制器，用於為單個用戶或使用群組管理虛擬機實例的整個生命周期，根據用戶需求來提供虛擬服務。負責虛擬機創建、開機、關機、掛起、暫停、調整、遷移、重啟、銷毀等操作，配置CPU、內存等信息規格。 - 網絡
服務名：網絡&地址管理（Network）
項目名：Neutron
功能：提供雲計算的網絡虛擬化技術，為OpenStack其他服務提供網絡連接服務。為用戶提供接口，可以定義Network、Subnet、Router，配置DHCP、DNS、負載均衡、L3服務，網絡支持GRE、VLAN。插件架構支持許多主流的網絡廠家和技術，如OpenvSwitch。 - 對象存儲
服務名：對象存儲（Object Storage）
項目名：Swift
功能：一套用於在大規模可擴展系統中通過內置冗余及高容錯機制實現對象存儲的系統，允許進行存儲或者檢索文件。可為Glance提供鏡像存儲，為Cinder提供卷備份服務。 - 塊存儲
服務名：塊存儲 (Block Storage)
項目名：Cinder
功能：為運行實例提供穩定的數據塊存儲服務，它的插件驅動架構有利於塊設備的創建和管理，如創建卷、刪除卷，在實例上掛載和卸載卷。 - 認證服務
服務名：認證服務（Identity Service）
項目名：Keystone
功能：為OpenStack其他服務提供身份驗證、服務規則和服務令牌的功能，管理Domains、Projects、Users、Groups、Roles。 - 鏡像服務
服務名：鏡像服務（Image Service）
項目名：Glance
功能：一套虛擬機鏡像查找及檢索系統，支持多種虛擬機鏡像格式（AKI、AMI、ARI、ISO、QCOW2、Raw、VDI、VHD、VMDK），有創建上傳鏡像、刪除鏡像、編輯鏡像基本信息的功能。 - 計費服務
服務名：計費(Metering)
項目名：Ceilometer
功能：能把OpenStack內部發生的幾乎所有的事件都收集起來，然后為計費和監控以及其它服務提供數據支撐。 - 編排服務
服務名：部署編排 (Orchestration)
項目名：Heat
功能：提供了一種通過模板定義的協同部署方式，實現雲基礎設施軟件運行環境（計算、存儲和網絡資源）的自動化部署。 - 數據庫服務
服務名：數據庫服務（Database Service）
項目名：Trove
功能：為用戶在OpenStack的環境提供可擴展和可靠的關系和非關系數據庫引擎服務。
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的信息調用配置的虛擬化驅動來創建虛擬機。
keystone 組件
- keystone 中的概念
- User —— 使用 OpenStack Service 的的對象被稱為用戶，這里的用戶可以是人、服務、系統。
- Role —— 用來划分權限。給User指定Role的過程，就是給User指定權限的過程。可以簡單理解為公司內部職位和職員的關系。公司職員在不同的崗位有不同的權限。在OpenStack中，Keystone返回給User的Token中包含了Role列表，被訪問的Service會判斷訪問它的User和User提供的Token中的Role。系統默認使用 Role 是 admin(管理) 和 _member_(成員) 。
- Project （Tenant）—— 可以理解為一個人或者服務所擁有的資源集合。一個Project中可以包含多個User， 每一個User都可以根據分配的權限來使用Project中的資源。比如使用Nova創建的虛擬機要被指定到某個Project中，Cinder創建的卷也要指定到某個Project中，User訪問Project中的資源前，需要先與Project關聯，並指定User在Project中的Role。
- Policy —— Openstack對User的驗證除了身份驗證，還需要鑒別 User 對某個Service是否有訪問權限。Policy用來定義什么角色對應什么權限。對Keystone來說，Policy其實是一個JSON文件，默認是 /etc/keystone/policy.json 。通過Policy，Keystone實現了對User的權限管理。
- Token —— 令牌，使用一個字符串表示。Token中包含了在指定的范圍和指定的時間內可以被訪問的資源。Token一般被用戶持有。
- Credentials —— 用於確認用戶身份的憑證。
- Authentication —— 確定用戶身份的過程。
- Service —— 指Openstack中運行的組件服務。
- EndPoint —— 一個可以通過網絡來訪問和定位某個OpenStack Service的地址，通常表現為一個URL。EndPoint 分三種：
- Admin Url —— 供admin用戶使用，Port：35357
- Internal Url —— OpenStack 內部服務使用，Port： 5000
- Public Url —— 供其他用戶使用，Port： 5000
需要注意的是，雖然這里分了三種 URL， 在使用 EndPoint 訪問的時候，用戶的權限是和URL無關的，用戶的權限只和 Role 有關，和用戶訪問哪一個URL無關。
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 社區
openstack組件間通過調用各組件api提供的rest接口來實現通信，組件內通信則基於rpc(遠程過程調用)機制，而rpc機制是基於AMQP模型實現的。
從rpc使用的角度出發，nova，neutron，和cinder的流程是相似的，我們以cinder為例闡述rpc機制。
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 廣播信息無返回結果
nova-api 接收rest請求
nova-scheduler 負責調度
nova-compute 負責調用虛擬化驅動，建立虛擬機等
nova-conductor 幫助nova-compute 訪問數據庫，並將查詢結果返回給nova-compute
Neutron
在網絡這一塊，OpenStack經歷了由nova-network（早期）到Quantum（F版本）再到Neutron（H版本）的演進過程。
流程圖：
neutron-server 接到請求 --> 將請求發送到MQ --> neotron-plugins 得到請求 --> 發送請求到MQ --> neotron-agent 建立網絡設備。
neutron包含組件及功能介紹：
neutron-server ：對外提供rest api，接收請求 並將請求分發到不同的 neutron-plugin 上。
neutron-plugin ： 處理 Neutron Server 發來的請求，維護 OpenStack 邏輯網絡的狀態， 並調用 Agent 處理請求。每個廠商基於Openstack開發了模擬自己硬件的軟件，這個軟件就是plugin。 在早期，每個廠商開發各自的plugin，功能也是各自實現，有大量的代碼是重復的；另外，不同的廠商有不同的開發標准，導致程序的兼容性很差。針對這種情況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原生支持。其中：
- Network ： 代表一個隔離的二層網段，是為創建他的租戶而保留的一個廣播域。Subnet 和 Port 始終被分配給某個特定的network。 Network 的類型包括Flat、Vlan、VxLan、Gre等等
- Subnet：代表一個IPv4/v6的CIDR地址池，以及與其相關的配置，如網關、DNS等等，該 Subnet 中的 VM 實例隨后會自動繼承該配置。Subnet 必須關聯一個 Network。
- Port：代表虛擬交換機上的一個虛擬交換端口。VM 的網卡連接 VIF 連接Port后，就會擁有 MAC 地址和 IP 地址，Port 的 IP 地址是從Subnet 地址池中分配的。
- Service-plugin ： 即為除core-plugin以外其它的plugin，包括l3 router、firewall、loadbalancer、VPN、metering等等，主要實現L3-L7的網絡服務。這些plugin要操作的資源比較豐富，對這些資源進行操作的REST API被neutron-server看作Extension API，需要廠家自行進行擴展。
neutron-agent ： 處理 Plugin 的請求，負責在 network provider 上真正實現各種網絡功能。和 plugin 是一一對應的關系，
在架構設計上， Neutron沿用了OpenStack完全分布式的思想，各組件之間通過消息機制進行通信，使得Neutron中各個組件甚至各個進程都可以運行在任意的節點上，如前面的流程圖所示。這種微內核的架構使得開發者可以集中精力在網絡業務的實現上。目前Neutron提供了眾多的插件與驅動，基本上可以滿足各種部署的需要，如果這些還難以支撐實際所需的環境，則可以方便地在Neutron的框架下擴展插件或驅動。
Neutron對Quantum的插件機制進行了優化，將各個廠商L2插件中獨立的數據庫實現提取出來，作為公共的ML2插件存儲租戶的業務需求，使得廠商可以專注於L2設備驅動的實現，而ML2作為總控可以協調多廠商L2設備共同運行”。在Quantum中，廠家都是開發各自的Service-plugin，不能兼容而且開發重復度很高，於是在Neutron中就為設計了ML2機制，使得各廠家的L2插件完全變成了可插拔的，方便了L2中network資源擴展與使用。
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的工作。
（注意，以前廠商開發的L2 plugin跟ML2都存在於neutron/plugins目錄下，而可插拔的ML2設備驅動則存在於neutron/plugins/ml2/drivers目錄下）
控制端的實現 —— 從neutron-server的啟動開始說起。neutron-server時，主要就干了兩件事，第一是啟動wsgi服務器監聽Neutron REST API，第二是啟動rpc服務，用於core plugin與agent間的通信，兩類服務作為綠色線程並發運行。從SDN的角度來看，wsgi負責Neutron的北向接口，而Neutron的南向通信機制主要依賴於rpc來實現（當然，不同廠家的plugin可能有其它的南向通信機制）。
- 北向方面，Neutron的wsgi通過Paste工具進行模板化部署，它接收Neutron REST API的業務請求，然后通過APIRouter將其分發給對應的plugin。
- Neutron內部，plugin與數據庫交互，獲取業務的全局參數，然后通過rpc機制將操作與參數傳給設備上的Agent（某些plugin和ML2 Mechanism Driver通過別的方式與Agent通信，比如REST API、NETCONF等）。
- RPC機制就可以理解為Neutron的南向通信機制，Neutron的RPC實現基於AMPQ模型，plugins和agents之間通常采用“發布——訂閱”模式傳遞消息，agents收到相應plugins的***NotifyApi后，會回調設備本地的***CallBack來操作設備，完成業務的底層部署。
設備端的實現 —— 控制端neutron-server通過wsgi接收北向REST API請求，neutron-plugin通過rpc與設備端進行南向通信。設備端agent則向上通過rpc與控制端進行通信，向下則直接在本地對網絡設備進行配置。
OSI七層：
| 層 | 數據單元 | 典型設備 | 功能 |
|---|---|---|---|
| 應用層 | 數據 | 計算機：應用程序 | 直接和應用程序連接並提供常見的網絡應用服務 |
| 表示層 | 數據 | 計算機：編碼方式 | 將數據按照網絡能理解的方案進行格式化 |
| 會話層 | 數據 | 計算機：建立會話 | 負責在網絡中的兩節點之間建立、維持和終止通信 |
| 傳輸層 | 數據段 | 計算機：進程和端口 | 提供端到端的交換數據的機制，檢查分組編號與次序 |
| 網絡層 | 數據包 | 網絡：路由器 | 將網絡地址轉化為對應的物理地址，並且決定如何將數據從發送方傳到接收方 |
| 數據鏈路層 | 數據幀 | 網絡：交換機、網橋 | 控制物理層和網絡層之間的通訊 |
| 物理層 | 比特 | 網絡：集線器、網線 | 產生並檢測電壓，以便發送和接收攜帶數據的信號，提供為建立、維護和拆除物理鏈路所需要的機械的、電氣的、功能的和規程的特性 |
應用層：就是應用軟件使用的協議，如郵箱使用的POP3，SMTP、遠程登錄使用的Telnet、獲取IP地址的DHCP、域名解析的DNS、網頁瀏覽的http協議等；這部分協議主要是規定應用軟件如何去進行通信的。
表示層：決定數據的展現（編碼）形式，如同一部電影可以采樣、量化、編碼為RMVB、AVI，一張圖片能夠是JPEG、BMP、PNG等。
會話層：為兩端通信實體建立連接（會話），中間有認證鑒權以及檢查點記錄（供會話意外中斷的時候可以繼續，類似斷點續傳）。
傳輸層：將一個數據/文件斬件分成很多小段，標記順序以被對端接收后可以按順序重組數據，另外標記該應用程序使用的端口號及提供QOS。（不同的應用程序使用不同計算機的端口號，同樣的應用程序需要使用一樣的端口號才能正常通信）
網絡層：路由選路，選擇本次通信使用的協議（http、ftp等），指定路由策略及訪問控制策略。（IP地址在這一層）
數據鏈路層：根據端口與MAC地址，做分組（VLAN）隔離、端口安全、訪問控制。（MAC地址在這一層）處理VLAN內的數據幀轉發，跨VLAN間的訪問，需要上升到網絡層。
物理層：將數據最終編碼為用0、1表示的比特流，然后傳輸。
網絡模式
根據創建網絡的用戶的權限，Neutron network 可以分為：
-
Provider network：管理員創建的和物理網絡有直接映射關系的虛擬網絡。
-
Tenant network：租戶普通用戶創建的網絡，物理網絡對創建者透明，其配置由 Neutorn 根據管理員在系統中的配置決定
根據網絡的類型，Neutron network 可以分為：Local、Flat / Flat Dhcp 、VLan 、Gre 、VxLan
1. Local —— 所有的組件全部安裝在一台機器上，多用於測試環境。
2. Flat / Flat Dhcp —— Flat模型最為簡單，所有的虛擬機共用一個私有IP網段，IP地址在虛擬機啟動時完成注入，虛擬機間的通信直接通過HyperVisor中的網橋轉發，公網流量在該網段的網關上進行NAT（Nova-network實現為開啟nova-network主機內核的iptables，Neutron實現為網絡節點上的l3-agent）。Flat DHCP模型與Flat區別在於網橋中開啟了DHCP進程，虛擬機通過DHCP消息獲得IP地址（Nova-network實現為nova-network主機中的dnsmaq，Neutron實現為網絡節點上的dhcp-agent）。
優點：結構簡單，穩定
缺點：全部租戶都在一個水平面上，租戶之間沒有隔離，因為全部租戶都在一個子網內，當大規模部署后，其廣播風暴將會是不小的負面因素。
3. VLan
LAN 表示 Local Area Network，本地局域網，通常使用 Hub 和 Switch 來連接LAN 中的計算機。一般來說，當你將兩台計算機連入同一個 Hub 或者 Switch 時，它們就在同一個 LAN 中。同樣地，你連接兩個 Switch 的話，它們也在一個 LAN 中。一個 LAN 表示一個廣播域，它的意思是，LAN 中的所有成員都會收到 LAN 中一個成員發出的廣播包。可見，LAN 的邊界在路由器或者類似的3層設備。
VLAN 表示 Virutal LAN。一個帶有 VLAN 功能的switch 能夠同時處於多個 LAN 中。最簡單地說，VLAN 是一種將一個交換機分成多個交換機的一種方法。比方說，你有兩組機器，group A 和 B，你想配置成組 A 中的機器可以相互訪問，B 中的機器也可以相互訪問，但是A組中的機器不能訪問B組中的機器。你可以使用兩個交換機，兩個組分別接到一個交換機。如果你只有一個交換機，你可以使用 VLAN 達到同樣的效果。你在交換機上分配配置連接組A和B的機器的端口為 VLAN access ports。這個交換機就會只在同一個 VLAN 的端口之間轉發包。
帶 VLAN 的交換機的端口分為兩類：
-
- Access port：這些端口被打上了 VLAN Tag。離開交換機的 Access port 進入計算機的以太幀中沒有 VLAN Tag，這意味着連接到 access ports 的機器不會覺察到 VLAN 的存在。離開計算機進入這些端口的數據幀被打上了 VLAN Tag。
- Trunk port： 有多個交換機時，組A中的部分機器連接到 switch 1，另一部分機器連接到 switch 2。要使得這些機器能夠相互訪問，你需要連接兩台交換機。 要避免使用一根電纜連接每個 VLAN 的兩個端口，我們可以在每個交換機上配置一個 VLAN trunk port。Trunk port 發出和收到的數據包都帶有 VLAN header，該 header 表明了該數據包屬於那個 VLAN。因此，只需要分別連接兩個交換機的一個 trunk port 就可以轉發所有的數據包了。通常來講，只使用 trunk port 連接兩個交換機，而不是用來連接機器和交換機，因為機器不想看到它們收到的數據包帶有 VLAN Header。
一個計算節點上的網絡實例
它反映的網絡配置如下：
- Neutron 使用 Open vSiwtch —— OVS。
- 一台物理服務器，網卡 eth1 接入物理交換機，預先配置了網橋 br-eth1。
- 創建了兩個 neutron VLAN network，分別使用 VLAN ID 101 和 102。
- 該服務器上運行三個虛機，虛機1 和 2 分別有一個網卡接入 network 1；虛機2 和 3 分別有一個網卡接入 network 2.
Neutron 在該計算節點上做的事情：
- 創建了 OVS Integration bridge br-int。它的四個 Access 端口中，兩個打上了內部 Tag 1，連接接入 network 1 的兩個網卡；另兩個端口的 VLAN Tag 為 2。
- 創建了一對 patch port，連接 br-int 和 br-eth1。
- 設置 br-int 中的 flow rules。對從 access ports 進入的數據幀，加上相應的 VLAN Tag，轉發到 patch port；從 patch port 進入的數據幀，將 VLAN ID 101 修改為 1, 102 修改為 2，再轉發到相應的 Access ports。
- 設置 br-eth1 中的 flow rules。從 patch port 進入的數據幀，將內部 VLAN ID 1 修改為 101，內部 VLAN ID 2 修改為 102，再從 eth1 端口發出。對從 eth1 進入的數據幀做相反的處理。
優點：租戶有隔離
缺點： 1. VLAN 使用 12-bit 的 VLAN ID，所以 VLAN 的第一個不足之處就是它最多只支持 4096 個 VLAN 網絡（當然這還要除去幾個預留的），對於大型數據中心的來說，這個數量是遠遠不夠的。
2. VLAN 是基於 L2 的，所以很難跨越 L2 的邊界，在很大程度上限制了網絡的靈活性。
- 3. VLAN 操作需手工介入較多，這對於管理成千上萬台機器的管理員來說是難以接受的。
更多具體內容參考：
http://www.cnblogs.com/sammyliu/p/4626419.html
gre與vxlan請參考
http://www.cnblogs.com/sammyliu/p/4622563.html
http://www.cnblogs.com/xingyun/p/4620727.html