OpenStack —— 計算服務Nova(四)
一、Nova介紹
Nova是OpenStack Compute的代號，是OpenStack的重要組成部分，也是IaaS的重要組成部分，它負責維護和管理OpenStack的計算資源，虛擬機生命周期管理也就是通過Nova來實現的。
Nova是無共享、基於消息的架構，所以的Nova組件都可以在多臺服務器上分布式運行，這就意味著大多數組件與組件之間的通信都需要消息隊列，在G版之前，Nova所有組件都會與數據庫通信，這樣的集中數據庫訪問在小規模環境下是個不錯的選擇，但對大集群來說則會產生安全問題，每個節點都具有數據庫訪問權限，一旦一臺服務器被攻破，這個雲環境將完全暴露在外，在G版之後，nova-compute所有數據操作均通過消息隊列交由nova-conductor來寫入或讀取數據庫，這樣就避免了直接訪問數據庫，提高了安全性，也更加靈活。
二、Nova主要組件
Nova由很多子服務組成，同時我們也知道OpenStack是一個分布式系統，對於Nova這些服務會部署在兩類節點上，計算節點和控制節點，計算節點上安裝了Hypervisor，上面運行虛擬機，只有nova-compute需要放在計算節點上，其他子服務則是放在控制節點上的。
1、nova-api
nova-api服務作為Nova組件對外的唯一窗口，接收和響應用戶的API請求，當客戶需要執行虛機相關的操作，能且只能向nova-api發送REST API請求，這裏的客戶包括終端用戶、命令行和openstack其他組件。
nova-api服務支持OpenStack Compute API，Amazon EC2 API，還有一個Admin API用於用戶進行一些管理操作。
2、nova-api-metadata
nova-api-metadata主要接收虛擬機的元數據請求，通常在帶有nova-network的多主機模式下才會使用。
3、nova-compute
nova-compute在計算節點上運行，它是一個工作進程(worker deamon)，通過hypervisor APIs來創建或者關閉虛擬機實例，這個過程相當的復雜，總的來說，它從隊列服務接收消息之後，然後啟動虛擬機並在數據庫中更新狀態。
nova-compute的功能可以分為兩類，一定時向OpenStack報告計算節點的狀態，二實現instance生命周期的管理。
4、nova-placement-api
主要追蹤每個提供者的庫存和使用量情況，比如追蹤計算節點的資源，存儲池的使用情況以及IP的分配情況等等。
5、nova-scheduler
如果有多個實體都能夠完成任務，那麽通常會有一個scheduler負責從這些實體中挑選出一個最合適的來執行操作，nova-scheduler就是處理隊列中的請求，然後會根據計算節點當時的資源使用情況選擇一個最合適的計算節點來運行虛機，會通過消息中間件rabbitMQ向選定的計算節點發出launch instance的命令。
調度服務就好比是一個開發團隊中的項目經理，當接到新的開發任務時，項目經理會評估任務的難度，考察團隊成員目前的工作負荷和技能水平，然後將任務分配給最合適的開發人員。
6、nova-conductor
nova-compute需要獲取和更新數據庫中instance的信息，但nova-compute並不會直接訪問數據庫，而是通過nova-conductor實現數據的訪問。在巨大的集群中，nova-conductor可以水平擴展，但是不要部署在計算節點上。
如此設計的好處是讓集群更高的系統安全性和更好的系統伸縮性。
7、nova-cert
一個Nova的證書服務，提供 x509 證書支持，用於兼容AWS。
8、nova-consoleauth
負責對訪問虛機控制臺請親提供Token認證。
9、nova-novncproxy
提供基於Web瀏覽器的VNC訪問。
10、nova-spicehtml5proxy
提供基於HTML5瀏覽器的SPICE訪問。
11、nova-xvpvncproxy
提供基於Java客戶端的VNC訪問。
12、The queue
在前面我們了解到Nova包含眾多的子服務，這些子服務之間需要相互協調和通信，為解耦各個子服務，Nova通過Message Queue作為子服務的信息中轉站，所以在架構圖上我們看到了子服務之間沒有直接的連線，它們都通過Message Queue聯系。
13、SQL database
Nova會存放一些雲平臺的狀態數據在數據庫中，比如可用虛擬機類型、虛擬機是否使用中、網絡的使用狀態以及項目等。
三、Nova各組件如何協調工作
客戶（可以是OpenStack最終用戶，也可以是其他程序）向API（nova-api）發送請求：“幫我創建一個虛機”；
API對請求做一些必要處理後，向Messaging（RabbitMQ）發送了一條消息：“讓Scheduler創建一個虛機”；
Scheduler（nova-scheduler）從Messaging獲取到API發給它的消息，然後執行調度算法，從若幹計算節點中選出節點 A ；
Scheduler向Messaging發送了一條消息：“在計算節點 A 上創建這個虛機”
計算節點 A 的Compute（nova-compute）從Messaging中獲取到Scheduler發給它的消息，然後在本節點的Hypervisor上啟動虛機；
在虛機創建的過程中，Compute如果需要查詢或更新數據庫信息，會通過Messaging向Conductor（nova-conductor）發送消息，Conductor負責數據庫訪問。
四、Nova支持的Hypervisor
nova-compute運行在計算節點上，通過插件形式對Hypervisor進行管理，當前的版本(Ocata)，對各種主流的虛擬化平臺都提供了支持，典型地通過XenAPI/vCenter API/Libvirt等所提供的插件接口執行虛擬機的創建、終止、遷移等生命周期管理。
五、nova-cell
從G版開始，Nova為了增加橫向擴展以及分布式、大規模(地理位置級別)部署能力，同時又不增加數據庫和消息中間件的復雜度，引入了cell概念。
cell的功能允許我們以更加靈活的分布式的方式實現對OpenStack Compute雲的縮放，而不需要更加復雜的技術，只需數據庫和消息隊列等。它的目的是支持更大規模的部署。
當啟用了這個功能的時候，OpenStack Compute雲中的主機會被分組，稱作cell。cell的結構是樹的形式。top-level級別的cell中的主機運行一個nova-api服務，但是可以沒有nova-compute服務。每一個子cell應該運行常規OpenStack雲計算中所有nova-*類型的服務，除了nova-api服務。我們可以把一個cell樹結構看成一個正常的OpenStack Compute部署，因為在這個樹中的每個cell中都有自己的數據庫服務和消息隊列服務。
nova-cells服務處理cell之間的通信，並選擇一個cell用於建立新的實例。這個服務將會被每個cell所需要的。cell之間的通信是可插拔的，目前cell之間的通信只是通過RPC服務來實現的。
采用cell服務實現了cell的調度和主機節點的調度是相互分離的。nova-cells服務首先會選擇一個cell（目前實現的是隨機選擇，將來會添加過濾/權重功能，還可以基於廣播獲取的capacity/capabilities等參數）。一旦合適的cell被選擇，且建立新的實例的請求到達了這個cell的nova-cells服務之上，這個cell將會發送建立新的實例的請求到這個cell的主機調度器。
cell的特征：
目的是支持更大規模的部署； cell的結構是樹的形式； top-level級別的cell（API cell）中的主機運行nova-api服務，可以沒有nova-compute服務，不感知底層物理主機以及虛擬化； 子cell無nova-api服務； 每一個子cell應該運行常規OpenStack雲計算中所有nova-*類型的服務，除了nova-api服務； 樹中的每個cell中都有自己的數據庫服務和消息隊列服務； 從設計上來講cell之間的通信是可插拔的，也就是未來會支持多種消息通信框架，目前cell之間的通信只是通過RPC服務來實現的； 采用cell服務實現了cell的調度和主機節點的調度是相互分離的； 在建立新的實例時，nova-cells服務選擇cell，目前實現的是隨機選擇，將來會添加過濾/權重功能，還可以基於廣播獲取的capacity/capabilities等參數； 在默認的情況下cell功能是禁用的。
上圖是三個cell級聯的情況，其中API Cell收到請求後，通過nova-cell提供的調度算法，通過消息隊列將消息轉發到Child Cell節點，在Child Cell節點做與API Cell同樣的工作，選擇一個Grandchild Cell並繼續轉發，在Grandchild節點上做真正的主機調度工作，選擇主機創建虛擬機。
上面的情況下，Grandchild Cell需要將自己連接的資源信息定時上報給Child Cell以提供調度功能使用，同樣ChildCell也要自己知道的資源信息上報給API Cell使用，這樣，每層調度時只需拿自己掌握的資源信息即可，實現每層解耦。
本文出自 “運維點滴記錄” 博客，請務必保留此出處http://wzlinux.blog.51cto.com/8021085/1962230
OpenStack —— 計算服務Nova(四)