1.4 OpenStack的架構

在學習OpenStack的部署和運維之前，我們應當熟悉其架構和運行機制。OpenStack作為一個開源、可擴展、富有彈性的云操作系統，其架構設計主要參考了亞馬遜的AWS云計算產品，通過模塊的劃分和模塊間的功能協作，設計的基本原則如下。

（1）按照不同的功能和通用性劃分不同的項目，拆分子系統。

（2）按照邏輯計劃、規范子系統之間的通信。

（3）通過分層設計整個系統架構。

（4）不同功能子系統間提供統一的API接口。

1.4.1 OpenStack的概念架構

OpenStack的概念架構（Concept Architecture）如圖1-7所示。此圖展示了OpenStack云平臺各模塊（僅給出主要服務）協同工作的機制和流程。

OpenStack通過一組相關的服務提供一個基礎設施即服務（IaaS）的解決方案。這些服務以虛擬機為中心。虛擬機主要是由Nova、Glance、Cinder和Neutron 4個核心模塊進行交互的結果。Nova為虛擬機提供計算資源，包括vCPU、內存等。Glance為虛擬機提供鏡像服務，安裝操作傳統的運行環境。Cinder提供存儲資源，類似傳統計算機的磁盤或卷。Neutron為虛擬機提供網絡配置，以及訪問云平臺的網絡通道。

云平臺用戶（開發者與運維人員，甚至包括其他OpenStack組件）在經Keystone服務認證授權后，通過Horizon或REST API模式創建虛擬機服務。創建過程包括利用Nova服務創建虛擬機實例，虛擬機實例采用Glance提供的鏡像服務，然后使用Neutron為新建的虛擬機分配IP地址，并將其納入虛擬網絡中，之后再通過Cinder創建的卷為虛擬機掛載存儲塊。整個過程都在Ceilometer模塊的資源監控下，Cinder 產生的卷（Volume）和 Glance 提供的鏡像（Image）可以通過 Swift 的對象存儲機制進行保存。

Horizon、Ceilometer、Keystone 提供訪問、監控、身份認證（權限）功能，Swift 提供對象存儲功能，Heat實現應用系統的自動化部署，Trove用于部署和管理各種數據庫，Sahara提供大數據處理框架，而Ironic提供裸金屬云服務。

云平臺用戶通過nova-api等來與其他OpenStack服務交互，而這些OpenStack服務守護進程通過消息總線（動作）和數據庫（信息）來執行API請求。

消息隊列為所有守護進程提供一個中心的消息機制，消息的發送者和接收者相互交換任務或數據進行通信，協同完成各種云平臺功能。消息隊列將各個服務進程解耦，所有進程可以任意分布式部署，協同工作在一起。目前RabbitMQ是默認的消息隊列實現技術。

SQL 數據庫保存了云平臺大多數創建和運行時的狀態，包括可用的虛擬機實例類型，正在使用的實例、可用的網絡和項目等。理論上，OpenStack可以使用任一支持SQL-Alchemy的數據庫。

1.4.2 OpenStack的邏輯架構

要設計、部署和配置OpenStack，管理員必須理解其邏輯架構（Logical Architecture）。圖1-8所示的邏輯架構描述的是OpenStack服務各個組成部分以及各組件之間的邏輯關系（僅列出最通用的服務和組件）。

OpenStack包括若干稱為OpenStack服務的獨立組件。所有服務均可通過一個公共的身份服務進行身份驗證。除了那些需要管理權限的命令，每個服務之間均可通過公共API進行交互。

每個 OpenStack 服務又由若干組件組成，包含多個進程。所有的服務至少有一個 API 進程，用于偵聽 API 請求，對這些請求進行預處理，并將它們傳送到該服務的其他組件。除了認證服務，實際工作是由具體的進程完成的。

至于一個服務的進程之間的通信，則使用AMQP消息代理。服務的狀態存儲在數據庫中。部署和配置OpenStack云時，可以從幾種消息代理和數據庫解決方案中進行選擇，如RabbitMQ、MySQL、MariaDB和SQLite。

用戶訪問OpenStack有多種方法，可以通過由Horizon儀表板服務實現的基于Web的用戶界面，也可以通過命令行客戶端，或者通過瀏覽器插件或curl發送API請求。對于應用程序來說，可以使用多種軟件開發工具包（Software Development Kit,SDK）。所有這些訪問方法最終都要將REST API調用發送給各種不同的OpenStack服務。

在實際的部署方案中，各個組件可以部署到不同的物理節點上。OpenStack本身是一個分布式系統，不僅各個服務可以分布部署，服務中的組件也可以分布部署。這種分布式特性讓OpenStack具備極大的靈活性、伸縮性和高可用性。當然，從另一個角度來看，這一特性也使OpenStack比一般系統復雜，學習難度也更大。

1.4.3 OpenStack組件之間的通信關系

OpenStack組件之間的通信關系，可分為以下4種類型。

1.基于AMQP

基于AMQP（Advanced Message Queuing Protocol，高級消息隊列協議）進行的通信，主要是每個項目內部各個組件之間的通信，如 Nova 的 nova-compute 與 nova-scheduler 之間，Cinder 的cinder-scheduler 和cinder-volume之間。

雖然通過AMQP進行通信的大部分組件屬于同一個項目，但是并不要求它們都安裝在同一個節點上，這就大大方便了系統的水平（橫向）擴展。管理員可以對其中的各個組件分別按照其負載進行水平擴展，使用不同數量的主機節點承載這些服務。

2.基于SQL的通信

通過數據庫連接實現的通信大多用于各個項目內部，也不要求數據庫和項目中的其他組件安裝在同一節點上，可以分開安裝，也可以專門部署數據庫服務器，通過基于SQL的連接進行通信。

3.基于HTTP進行通信

通過各項目的API建立的通信關系基本都屬于這一類，這些API都是RESTful Web API。最常見的就是通過Horizon儀表板或者命令行接口對各組件進行操作時產生的這種通信，然后就是各組件通過 Keystone 對用戶身份進行認證時使用的這種通信。還有一些基于 HTTP 進行通信的情形，如nova-compute在獲取鏡像時對Glance API的調用、Swift數據的讀寫等。

4.通過Native API實現通信

這是OpenStack各組件和第三方軟硬件之間的通信方式。例如，Cinder與存儲后端之間的通信， Neutron的代理（即插件）與網絡設備之間的通信，都需要調用第三方的設備或第三方軟件的API，這些API被稱為Native API，這些通信是基于第三方API的。

1.4.4 OpenStack的物理架構

OpenStack是分布式系統，必須從邏輯架構映射到具體的物理架構，將各個項目和組件以一定的方式安裝到實際的服務器節點，部署到實際的存儲設備上，并通過網絡將它們連接起來，這就是OpenStack的物理部署架構。

OpenStack的部署分為單節點部署和多節點部署兩種類型。單節點部署就是將所有的服務和組件都放在一個物理節點上，通常是用于學習、驗證、測試或者開發。多節點部署就是將服務和組件分別部署在不同的物理節點上。一個典型的多節點部署如圖1-9所示。常見的節點類型有控制節點（Control Node）、計算節點（Compute Node）、存儲節點（Storage Node）和網絡節點（Network Node），下面分別介紹這些節點類型。

1.控制節點

控制節點又稱管理節點，安裝并運行各種OpenStack控制服務，負責管理、節制其余節點，執行虛擬機建立、遷移、網絡分配、存儲分配等任務。OpenStack的大部分服務都是運行在控制節點上，通常包括以下服務。

（1）支持服務（Supporting Service）

? 數據庫服務器，如SQL數據庫。

? 消息隊列服務，如RabbitMQ。

? 網絡時間協議（Network Time Protocol,NTP）服務。

（2）基礎服務

運行Keystone認證服務、Glance鏡像服務、Nova計算服務的管理組件、Neutron網絡服務的管理組件、多種網絡代理（Networking agent）和Horizon儀表板。

（3）擴展服務

運行Cinder塊存儲服務、Swift對象存儲服務、Trove數據庫服務、Heat編排服務和Ceilometer計量服務的部分組件。這對于控制節點來說是可選的。

控制節點一般只需要一個網絡端口用于通信和管理各個節點。

2.計算節點

計算節點是實際運行虛擬機的節點，主要負責虛擬機的運行，為用戶創建并運行虛擬機，為虛擬機分配網絡。通常包括以下服務。

（1）基礎服務

Nova計算服務的Hypervisor（虛擬機管理器）組件，提供虛擬機的創建、運行、遷移、快照等各種圍繞虛擬機的服務，并提供API與控制節點對接，由控制節點下發任務。默認計算服務使用的Hypervisor是KVM。

網絡插件代理，用于將虛擬機實例連接到虛擬網絡中，通過安全組為虛擬機提供防火墻服務。

（2）擴展服務

Ceilometer計量服務代理，提供計算節點的監控代理，將虛擬機的情況反饋給控制節點。

虛擬機可以部署多個計算節點，一個計算節點至少需要兩個網絡端口，一個與控制節點進行通信，受控制節點統一調配；另一個與網絡節點及存儲節點進行通信。

3.存儲節點

存儲節點負責對虛擬機的外部存儲進行管理等，即為計算節點的虛擬機提供持久化卷服務。這種節點存儲需要的數據，包括磁盤鏡像、虛擬機持久性卷。存儲節點包含Cinder和Swift等服務，可根據需要安裝共享文件服務。

塊存儲和對象存儲可以部署在同一個存儲節點上，也可以分別部署塊存儲節點和對象存儲節點。不論采用哪種方式，都可以部署多個存儲節點。

最簡單的網絡連接存儲節點只需要一個網絡接口，直接使用管理網絡在計算節點和存儲節點之間進行通信。而在生產環境中，存儲節點最少需要兩個網絡接口，一個連接管理網絡，與控制節點進行通信，接受控制節點下發的任務，受控制節點統一調配；另一個專門的存儲網絡（數據網絡），與計算節點和網絡節點進行通信，完成控制節點下發的各類數據傳輸任務。

4.網絡節點

網絡節點可實現網關和路由的功能，它主要負責外部網絡與內部網絡之間的通信，并將虛擬機連接到外部網絡。網絡節點僅包含Neutron服務，Neutron負責管理私有網段與公有網段的通信，以及管理虛擬機網絡之間的通信拓撲，管理虛擬機上的防火墻等。

網絡節點通常需要3個網絡端口，分別用來與控制節點進行通信、與除控制節點外的計算節點和存儲節點之間的通信、外部的虛擬機與相應網絡之間的通信。

網絡節點根據虛擬網絡選項來決定要部署的服務和組件，它有兩種選擇，一種是提供者網絡（Provider Networks，又譯為供應商網絡），另一種是自服務網絡（Self-service Networks），這兩種網絡所需的組件如圖1-10所示。

（1）提供者網絡

選擇提供者網絡選項，將以最簡單的方式部署 OpenStack 網絡服務，它使用基本的二層（網橋/交換機）服務和虛擬局域網（Virtual Local Area Network,VLAN）分段。它實質上是將虛擬網絡橋接到物理網絡，并依靠物理網絡基礎設施提供的三層（路由）服務。另外，還需一個動態主機配置協議（Dynamic Host Configuration Protocal,DHCP）服務為虛擬機實例提供IP地址信息。

OpenStack用戶需要了解底層網絡基礎設施的更多信息來創建虛擬網絡，以精確匹配基礎設施。

提示

提供者網絡不支持自服務（私有）網絡、三層路由服務，以及像 LBaaS（負載平衡服務）和FWaaS（防火墻服務）這樣的高級服務。如果要使用這些特性，應選擇自服務網絡選項。

（2）自服務網絡

選擇自服務網絡選項，會在提供者網絡的基礎上增加三層（路由）服務，這樣才能夠使用像VXLAN這樣的覆蓋分段方法。它實質上是通過NAT將虛擬網絡路由到物理網絡。另外，該選項將提供像LBaaS和FWaaS這樣的高級服務。

OpenStack無須了解數據網絡的底層基礎設施即可創建虛擬網絡。如果配置相應的二層插件，這也會包括VLAN。

在提供者網絡架構中，所有實例均可直接連接到提供者網絡。在自服務（私有）網絡架構中，實例可以連接到自服務或提供者網絡。自服務網絡可以完全在OpenStack環境中或者通過外部網絡使用NAT方式提供某種級別的外部網絡訪問。

5.節點的組合

OpenStack是一個松散耦合系統，具有彈性的設計和部署，上述節點可以根據需要進行整合。

可以從控制節點中分出一個專門的API節點，API節點去除Neutron服務之外的管理控制服務（如Nova、Glance、KeyStone等）。API節點又可以與網絡節點合二為一。

數據庫服務器和消息隊列協議可以部署在控制節點（或 API 節點）上，也可以運行于網絡節點上。Glance、Keystone、Cinder服務可以在API節點上運行，也可以在網絡節點上運行，還可以在控制節點上運行。既可以創建單獨的認證節點來運行Keystone服務，還可以創建單獨的鏡像節點來運行Glance服務。

提示

cinder-api與cinder-scheduler需要在同一節點上運行，共用同一配置文件；nova-api、nova-scheduler、nova-novncproxy服務應在同一節點上運行，共用相同的配置文件。

存儲節點可以合并到某個計算節點上。

nova-compute與Neutron（openswitch、neutron-openvswitch-agent）服務必須在一個節點上運行，否則虛擬機實例無法獲得網絡分配。

1.4.5 OpenStack的物理網絡類型

OpenStack的物理部署就是將承載不同服務的物理節點通過物理網絡進行連接，從而使各個服務在云平臺上協同工作。這里所講的是主機節點之間的物理網絡連接，而不是OpenStack網絡服務中的虛擬網絡。OpenStack環境中的物理網絡配置往往包括以下類型。

1.公共網絡（Pulic Network）

公共網絡通常使用由電信運營商提供的公共IP地址。

2.外部網絡（External Network）

數據中心 Intranet用于為虛擬機分配浮動的 IP地址，讓 Internet用戶能夠訪問該網絡上的 IP地址。

3.管理網絡（Management Network）

管理網絡提供OpenStack各個組件之間的內部通信，以及API訪問端點（Endpoint）。為安全考慮，該網絡必須限制在數據中心內，也就是說，IP 地址通常只能在數據中心內部訪問。這是一個單獨的網絡，確保系統管理和監控訪問域虛擬機網絡分離，以防止來自用戶虛擬機網絡的監聽和攻擊，保證云平臺的安全性。

4.API網絡

API網絡用于為用戶提供OpenStack API。實際上這不是一個單獨的網絡，而是包含在外部和內部網絡中。API的端點（Endpoint）包括公共URL（Uniform Resource Locator，統一資源定位符）和內部URL，前者包含的是外部網絡的IP 地址，后者包含的是管理網絡的IP地址。為簡單起見，提供給內外網絡訪問的API的公共URL和內部URL相同，而只給內部網絡訪問的API使用內部URL。

5.數據網絡（Data Network）

數據網絡可以細分為以下網絡類型。

（1）項目（租戶）網絡（Tenant Network）：又稱虛擬機（Virtual Machine,VM）網絡，提供虛擬機在計算節點之間，以及計算節點和網絡節點之間的通信。同樣這也是數據中心的內部網絡。

（2）存儲訪問網絡（Storage Access Network）：訪問存儲的網絡。

（3）存儲后端網絡（Storage Backend Network）：如Ceph和Swift集群用于后端數據復制的網絡。

它們可以合為一種，也可以從性能方面考慮分離出一種或幾種作為單獨的網絡。

6.硬件管理網絡

除了以上網絡類型，往往還有各種功能網絡，包括IPMI網絡、PXE網絡、監控網絡等，這些可以稱為硬件管理網絡。大型數據中心通常會建立單獨的硬件管理網絡。

上述網絡，除公共網絡和外部網絡之外，都可以統稱為OpenStack內部網絡。這些網絡類型可以根據需要靈活組配。管理網絡與硬件管理網絡可以合并為一個管理網絡；API網絡與外部網絡也可以合二為一，通常這兩個網絡都是為外部用戶提供服務的；管理網絡與存儲網絡也可以合并到一起，因為管理網絡流量很少；外部網絡、API網絡和數據網絡也可以合并，以減少路由器物理設備，降低網絡的復雜度；當然也可以將所有網絡類型合并成一個網絡，用于OpenStack的原型驗證或開發測試。