一 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類：

Direct Exchange根據Routing Key進行精確匹配，只有對應的 Message Queue 會接受到消息；

Topic Exchange根據Routing Key進行模式匹配，只要符合模式匹配的Message Queue都會收到消息；

Fanout Exchange將消息轉發給所有綁定的Message Queue。

AMQP消息模型

RPC 發送請求

Client 端發送 RPC 請求由 publisher 發送消息并聲明消息地址，consumer 接收消息并進行消息處理，如果需要消息應答則返回處理請求的結果消息。

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

rpc.call 發送 RPC 請求并返回請求處理結果，請求處理流程如圖 5 所示，由 Topic Publisher 發送消息，Topic Exchange 根據消息地址進行消息轉發至對應的 Message Queue 中，Topic Consumer 監聽 Message Queue，發現需要處理的消息則進行消息處理，并由 Direct Publisher 將請求處理結果消息，請求發送方創建 Direct Consumer 監聽消息的返回結果

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

rpc.fanout_cast 用于發送 RPC 廣播信息無返回結果

neutron

neutron包含組件：

neutron-server

neutron-plugin

neutron-agent

neutron各組件功能介紹：

Neutron-server可以理解為一個專門用來接收Neutron REST API調用的服務器，然后負責將不同的rest api分發到不同的neutron-plugin上。

Neutron-plugin可以理解為不同網絡功能實現的入口，各個廠商可以開發自己的plugin。Neutron-plugin接收neutron-server分發過來的REST API，向neutron database完成一些信息的注冊，然后將具體要執行的業務操作和參數通知給自身對應的neutron agent。

Neutron-agent可以直觀地理解為neutron-plugin在設備上的代理，接收相應的neutron-plugin通知的業務操作和參數，并轉換為具體的設備級操作，以指導設備的動作。當設備本地發生問題時，neutron-agent會將情況通知給neutron-plugin。

Neutron database，顧名思義就是Neutron的數據庫，一些業務相關的參數都存在這里。

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 可以分為：

VLANnetwork（虛擬局域網）：基于物理 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.confdhcp-option-force=26,1450或1462

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