1. 談?wù)凮penstack的發(fā)展歷史

OpenStack是一個面向IaaS層的云管理平臺開源項目，用于實現(xiàn)公有云和私有云的部署及管理。最開始Openstack只有兩個組件，分別為提供計算服務(wù)的Nova項目以及提供對象存儲服務(wù)的Swift，其中Nova不僅提供虛擬機(jī)服務(wù)，還包含了網(wǎng)絡(luò)服務(wù)、塊存儲服務(wù)、鏡像服務(wù)以及裸機(jī)管理服務(wù)。之后隨著項目的不斷發(fā)展，從Nova中拆分成多個獨(dú)立的項目各自提供不同的服務(wù)，如拆分為Cinder項目提供塊存儲服務(wù)，拆分為Glance項目，提供鏡像服務(wù)，nova-network則是neutron的前身，裸機(jī)管理也從Nova中分離出來為Ironic項目。最開始容器服務(wù)也是由Nova提供支持的，作為Nova的driver之一來實現(xiàn)，而后遷移到Heat，到現(xiàn)在已經(jīng)分離成獨(dú)立的項目Magnum，后來Magnum主要提供容器編排服務(wù)，單純的容器服務(wù)由Zun項目負(fù)責(zé)。最開始Openstack并沒有認(rèn)證功能，從E版開始才加入認(rèn)證服務(wù)Keystone，至此Openstack 6個核心服務(wù)才終于聚齊了。

• Keystone 認(rèn)證服務(wù)。
• Glance 鏡像服務(wù)。
• Nova 計算服務(wù)。
• Cinder 塊存儲服務(wù)。
• Neutorn 網(wǎng)絡(luò)服務(wù)。
• Swift 對象存儲服務(wù)。

E版之后，在這些核心服務(wù)之上，又不斷涌現(xiàn)新的服務(wù)，如面板服務(wù)Horizon、服務(wù)編排服務(wù)Heat、數(shù)據(jù)庫服務(wù)Trove、文件共享服務(wù)Manila、大數(shù)據(jù)服務(wù)Sahara以及前面提到的Magnum等，這些服務(wù)幾乎都依賴于以上的核心服務(wù)。比如Sahara大數(shù)據(jù)服務(wù)會先調(diào)用Heat模板服務(wù)，Heat又會調(diào)用Nova創(chuàng)建虛擬機(jī)，調(diào)用Glance獲取鏡像，調(diào)用Cinder創(chuàng)建數(shù)據(jù)卷，調(diào)用Neutron創(chuàng)建網(wǎng)絡(luò)等。還有一些項目圍繞Openstack部署的項目，比如Puppet-openstack、Kolla、TripleO、Fuel等項目。

截至現(xiàn)在(2016年11月27日)，Openstack已經(jīng)走過了6年半的歲月，***發(fā)布的版本為第14個版本，代號為Newton，Ocata版已經(jīng)處在快速開發(fā)中。

Openstack服務(wù)越來越多、越來越復(fù)雜，并且不斷變化發(fā)展。以Nova為例，從最開始使用nova-conductor代理數(shù)據(jù)庫訪問增強(qiáng)安全性，引入objects對象模型來支持對象版本控制，現(xiàn)在正在開發(fā)Cell項目來支持大規(guī)模的集群部署以及將要分離的Nova-EC2項目，截至到現(xiàn)在Nova包含nova-api、nova-conductor、nova-scheduler、nova-compute、nova-cell、nova-console等十多個組件。這么龐大的分布式系統(tǒng)需要深刻理解其工作原理，理清它們的交互關(guān)系非常不容易，尤其對于新手來說。

2.工欲善其事,必先利其器

由于Openstack使用python語言開發(fā)，而python是動態(tài)類型語言，參數(shù)類型不容易從代碼中看出，因此首先需要部署一個allinone的Openstack開發(fā)測試環(huán)境，建議使用RDO部署：Packstack quickstart，當(dāng)然樂于折騰使用devstack也是沒有問題的。

其次需要安裝科學(xué)的代碼閱讀工具，圖形界面使用pycharm沒有問題，不過通常在虛擬機(jī)中是沒有圖形界面的，***vim，需要簡單的配置使其支持代碼跳轉(zhuǎn)和代碼搜索，可以參考我的vim配置GitHub - int32bit/dotfiles: A set of vim, zsh, git, and tmux configuration files。

掌握python的調(diào)試技巧，推薦pdb、ipdb、ptpdb，其中ptpdb***用，不過需要手動安裝。打斷點前需要注意代碼執(zhí)行時屬于哪個服務(wù)組件，nova-api的代碼，你跑去nova-compute里打斷點肯定沒用。另外需要注意打了斷點后的服務(wù)必須在前端運(yùn)行，不能在后臺運(yùn)行，比如我們在nova/compute/manager.py中打了斷點，我們需要kill掉后臺進(jìn)程：

systemctl stop openstack-nova-compute 

然后直接在終端運(yùn)行nova-compute即可。

su -c 'nova-compute' nova 

3 .教你閱讀的正確姿勢

學(xué)習(xí)Openstack的***步驟是:

• 看文檔
• 部署allineone
• 使用之
• 折騰之、怒斥之
• 部署多節(jié)點
• 深度使用、深度吐槽
• 閱讀源碼
• 混社區(qū)，參與社區(qū)開發(fā)

閱讀源碼的首要問題就是就要對代碼的結(jié)構(gòu)了然于胸，需要強(qiáng)調(diào)的是，Openstack項目的目錄結(jié)構(gòu)并不是根據(jù)組件劃分的，而是根據(jù)功能劃分的，以Nova為例，compute目錄并不是一定在nova-compute節(jié)點上運(yùn)行的代碼，而主要是和compute相關(guān)(虛擬機(jī)操作相關(guān))的功能實現(xiàn)，同樣的，scheduler目錄代碼并不全在scheduler服務(wù)節(jié)點運(yùn)行，但主要是和調(diào)度相關(guān)的代碼。好在目錄結(jié)構(gòu)并不是完全混亂的，它是有規(guī)律的。

通常一個服務(wù)的目錄都會包含api.py、rpcapi.py、manager.py，這個三個是最重要的模塊。

• api.py： 通常是供其它組件調(diào)用的庫。換句話說，該模塊通常并不會由本模塊調(diào)用。比如compute目錄的api.py，通常由nova-api服務(wù)的controller調(diào)用。
• rpcapi.py：這個是RPC請求的封裝，或者說是RPC實現(xiàn)的client端，該模塊封裝了RPC請求調(diào)用。
• manager.py： 這個才是真正服務(wù)的功能實現(xiàn)，也是RPC的服務(wù)端，即處理RPC請求的入口，實現(xiàn)的方法通常和rpcapi實現(xiàn)的方法對應(yīng)。

前面提到Openstack項目的目錄結(jié)構(gòu)是按照功能劃分的，而不是服務(wù)組件，因此并不是所有的目錄都能有對應(yīng)的組件。仍以Nova為例:

• cmd：這是服務(wù)的啟動腳本，即所有服務(wù)的main函數(shù)?？捶?wù)怎么初始化，就從這里開始。
• db: 封裝數(shù)據(jù)庫訪問，目前支持的driver為sqlalchemy。
• conf：Nova的配置項聲明都在這里。
• locale: 本地化處理。
• image: 封裝Glance調(diào)用接口。
• network: 封裝網(wǎng)絡(luò)服務(wù)接口，根據(jù)配置不同，可能調(diào)用nova-network或者neutron。
• volume: 封裝數(shù)據(jù)卷訪問接口，通常是Cinder的client封裝。
• virt: 這是所有支持的hypervisor驅(qū)動，主流的如libvirt、xen等。
• objects: 對象模型，封裝了所有實體對象的CURD操作，相對以前直接調(diào)用db的model更安全，并且支持版本控制。
• policies： policy校驗實現(xiàn)。
• tests: 單元測試和功能測試代碼。

根據(jù)進(jìn)程閱讀源碼并不是什么好的實踐，因為光理解服務(wù)如何初始化、如何通信、如何發(fā)送心跳等就不容易，各種高級封裝太復(fù)雜了。而我認(rèn)為比較好的閱讀源碼方式是追蹤一個任務(wù)的執(zhí)行過程，比如追蹤啟動一臺虛擬機(jī)的整個流程。

不管任何操作，一定是先從API開始的，RESTFul API是Openstack服務(wù)的唯一入口，也就是說，閱讀源碼就從api開始。而api組件也是根據(jù)實體劃分的，不同的實體對應(yīng)不同的controller，比如servers、flavors、keypairs等，controller通常對應(yīng)有如下方法:

• index: 獲取資源列表，一般對應(yīng)RESTFul API的URL為“GET /resources”，如獲取虛擬機(jī)的列表API為“GET /servers”。
• get: 獲取一個資源，比如返回一個虛擬機(jī)的詳細(xì)信息API為”GET /servers/uuid“。
• create: 創(chuàng)建一個新的資源，通常對應(yīng)為POST請求。比如創(chuàng)建一臺虛擬機(jī)為 “POST /servers”, 當(dāng)然POST的數(shù)據(jù)為虛擬機(jī)信息。
• delete: 刪除指定資源，通常對應(yīng)DELETE請求，比如刪除一臺虛擬機(jī)為“DELETE/servers/uuid”。
• update: 更新資源信息，通常對應(yīng)為PUT請求，比如更新虛擬機(jī)資源為”PUT /servers/uuid，body為虛擬機(jī)數(shù)據(jù)。

了解了代碼結(jié)構(gòu)，找到了入口，再配合智能跳轉(zhuǎn)，閱讀源碼勢必事半功倍。如果有不明白的地方，隨時可以加上斷點單步調(diào)試。

4.案例分析

接下來以創(chuàng)建虛擬機(jī)為例，根據(jù)組件劃分，一步步分析整個工作流程以及操作序列。請再次回顧下api.py、rpcapi.py、manager.py以及api下的controller結(jié)構(gòu)，否則閱讀到后面會越來越迷糊。

S1 nova-api

入口為nova/api/openstack/compute/servers.py的create方法，該方法檢查了一堆參數(shù)以及policy后，調(diào)用compute_api的create方法，這里的compute_api即前面說的nova/compute/api.py模塊的API。

compute_api會創(chuàng)建數(shù)據(jù)庫記錄、檢查參數(shù)等，然后調(diào)用compute_task_api的build_instances方法，compute_task_api即conductor的api.py。

conductor的api并沒有執(zhí)行什么操作，直接調(diào)用了conductor_compute_rpcapi的build_instances方法，該方法即時conductor RPC調(diào)用api，即nova/conductor/rpcapi.py模塊，該方法除了一堆的版本檢查，剩下的就是對RPC調(diào)用的封裝，代碼只有兩行:

cctxt = self.client.prepare(version=version)  
cctxt.cast(context, 'build_instances', **kw) 

其中cast表示異步調(diào)用，build_instances是遠(yuǎn)程調(diào)用的方法，kw是傳遞的參數(shù)。參數(shù)是字典類型，沒有復(fù)雜對象結(jié)構(gòu)，因此不需要特別的序列化操作。

截至到現(xiàn)在，雖然目錄由api->compute->conductor，但仍在nova-api進(jìn)程中運(yùn)行，直到cast方法執(zhí)行，該方法由于是異步調(diào)用，因此nova-api不會等待遠(yuǎn)程方法調(diào)用結(jié)果，直接返回結(jié)束。

S2 nova-conductor

由于是向nova-conductor發(fā)起的RPC調(diào)用，而前面說了接收端肯定是manager.py，因此進(jìn)程跳到nova-conductor服務(wù)，入口為nova/conductor/manager.py的build_instances方法。

該方法首先調(diào)用了_schedule_instances方法，該方法調(diào)用了scheduler_client的select_destinations方法，scheduler_client和compute_api以及compute_task_api都是一樣對服務(wù)的client調(diào)用(即api.py)，不過scheduler沒有api.py，而是有個單獨(dú)的client目錄，實現(xiàn)在client目錄的__init__.py模塊，這里僅僅是調(diào)用query.py下SchedulerQueryClient的select_destinations實現(xiàn)，然后又很直接的調(diào)用了scheduler_rpcapi的select_destinations方法，終于又到了RPC調(diào)用環(huán)節(jié)。

毫無疑問，RPC封裝同樣是在scheduler的rpcapi中實現(xiàn)。該方法RPC調(diào)用代碼如下:

return cctxt.call(ctxt, 'select_destinations', **msg_args) 

注意這里調(diào)用的call方法，即同步調(diào)用，此時nova-conductor并不會退出，而是堵塞等待直到nova-scheduler返回。

S3 nova-scheduler

同理找到scheduler的manager.py模塊的select_destinations方法，該方法會調(diào)用driver對應(yīng)的方法，這里的driver其實就是調(diào)度算法實現(xiàn)，由配置文件決定，通常用的比較多的就是filter_scheduler，對應(yīng)filter_scheduler.py模塊，該模塊首先通過host_manager拿到所有的計算節(jié)點信息，然后通過filters過濾掉不滿足條件的計算節(jié)點，剩下的節(jié)點通過weigh方法計算權(quán)值，***選擇權(quán)值高的作為候選計算節(jié)點返回。nova-scheduler進(jìn)程結(jié)束。

S4 nova-condutor

回到scheduler/manager.py的build_instances方法，nova-conductor等待nova-scheduler返回后，拿到調(diào)度的計算節(jié)點列表，然后調(diào)用了compute_rpcapi的build_and_run_instance方法?？吹絰xxrpc立即想到對應(yīng)的代碼位置，位于compute/rpcapi模塊，該方法向nova-compute發(fā)起RPC請求:

cctxt.cast(ctxt, 'build_and_run_instance', ...) 

可見發(fā)起的是異步RPC，因此nova-conductor結(jié)束，緊接著終于輪到nova-compute登場了。

S5 nova-compute

到了nova-compute服務(wù)，入口為compute/manager.py，找到build_and_run_instance方法，該方法調(diào)用了driver的spawn方法，這里的driver就是各種hypervisor的實現(xiàn)，所有實現(xiàn)的driver都在virt目錄下，入口為driver.py，比如libvirt driver實現(xiàn)對應(yīng)為virt/libvirt/driver.py，找到spawn方法，該方法拉取鏡像創(chuàng)建根磁盤、生成xml文件、define domain，啟動domain等。***虛擬機(jī)完成創(chuàng)建。nova-compute服務(wù)結(jié)束。

一張圖總結(jié)以上是創(chuàng)建虛擬機(jī)的各個服務(wù)的交互過程以及調(diào)用關(guān)系，需要注意的是，所有的數(shù)據(jù)庫操作，比如instance.save()以及update操作，如果配置use_local為false，則會向nova-conductor發(fā)起RPC調(diào)用，由nova-conductor代理完成數(shù)據(jù)庫更新，而不是由nova-compute直接訪問數(shù)據(jù)庫，這里的RPC調(diào)用過程在以上的分析中省略了。

整個流程用一張圖表示為:

【本文是51CTO專欄作者“付廣平”的原創(chuàng)文章，如需轉(zhuǎn)載請通過51CTO獲得聯(lián)系】

戳這里，看該作者更多好文