OpenNebula架構分析（源碼）

聲明：

本博客歡迎轉發，但請保留原作者信息!內容系本人學習、研究和總結，如有雷同，實屬榮幸！

原文地址：http://blog.csdn.net/gtt116/article/details/9070487

前言

OpenStack使用的語言是python，比他年長的2歲的OpenNebula就顯得比較奇葩，使用的是C語言和Ruby，shell，多種語言混雜而成。

關於兩者的優劣在此不做討論，但我個人認爲OpenStack的發展偏向公有云，而OpenNebula的設計初衷就是私有云，這可以從兩個產品的設計上看出來。

OpenStack的功能基本是仿照AWS，也就是按照公有云的思路來設計接口和功能。比如虛擬機的host信息對用戶透明，調度算法對用戶透明，調度過程對用戶透明。

而OpenNebula則不同，所有關於虛擬機的任何信息一開始就設計在接口上了。所以在OpenNebula中，可以看到虛擬機詳細的創建過程，調度過程，操作日誌，因爲OpenNebula就是爲了數據中心虛擬化（私有云）而來的，而這些關鍵信息對於數據中心的管理至關重要。

OpenStack中關於虛擬機的很多信息並不能通過調用接口來獲取，比如說調度的歷史，虛擬機的遷移的歷史記錄，在數據庫中也沒有完整的記錄，目前只能從系統日誌中“挖”出來。她其實完全有能力提供這些信息，只是兩個產品的使用場景不同，導致了給用戶感覺的不同。因爲對於公有云用戶不關心這些事情，也就註定了OpenStack一開始不會花太多精力在這些方面。這些功能應該歸爲系統運維功能，就是常說的管理員功能。對於OpenStack只有基本功能完善了，普通用戶滿意了，纔會將更多的精力放在系統運維上。不過從launchpad的BP上來開，未來OpenStack的發展會慢慢的向更強運維性發展。

回到正題，本文主要講述OpenNebula的代碼結構和物理部署結構。對OpenNebula中某個功能的具體實現沒有詳細的描述，點到爲止，旨在拋磚引玉，爲初看OpenNebula代碼的同學提供方便。

注：本文基於OpenNebula4.0進行分析，其他版本可能會些許不同。

OpenNebula Web UI的試用錄像：

優酷 較模糊。

水管高清無碼。

物理架構

OpenNebula不像OpenStack有一堆服務，每個宿主機上要運行一堆進程。Nebula的開發原則就是輕量，簡單。

所以除了在控制節點運行幾個接受用戶請求的服務外，在計算節點不需要運行任何服務，只要OpenNebula可以通過ssh連到計算節點即可。

如下圖所示，OpenNebula就是控制節點，在此節點上運行着OpenNebula和OpenNebula-sunstone。前者主要負責處理XML-RPC請求，XML-RPC和REST API類似。後者就是Dashboard，Web UI。 綠色的框就是計算節點，計算節點裏運行着虛擬機。 控制節點和計算節點通過ssh進行通信，如此的好處是極度的簡單和輕量，基本上計算機點沒有浪費任何的資源在OpenNebula服務中，這和OpenStack相比差異很大。另外，劣勢也很明顯，導致了項目代碼的混亂和不好維護。因爲所有對虛擬機的操作最終都轉化爲ssh，virsh這樣的命名，導致很難寫單元測試，並且代碼可讀性也因此受影響。

主要進程

簡要介紹OpenNebula由哪些主要服務進程。OpenNebula簡稱爲ONE，所以很多進程都是one*打頭的。

• oned：OpenNebula的core服務，監聽2633端口，處理XML-RPC請求。另外它會創建如下子進程，這些進程各司其職：

• •  one_vmm_exec.rb： VirtualMachine Manager，負責管理虛擬機。
  •  one_im_exec.rb：Imformation Manager，管理和管理虛擬機和宿主機的狀態信息。
  •  one_tm.rb：TransferManager。
  •  one_hm.rb:  HookManager。
  •  one_datastore.rb:  數據存儲，類似於Openstack的實例存儲和卷。 
  •  one_auth_mad.rb:  驗證模塊。

• mm_sched: 負責調度虛擬機。
• sunstone-server.rb：OpenNebula的dashboard。
  

從進程名就可以看出很多是有ruby寫的，還有一部分是有C++寫的。官方的說法是c++佔39%，Ruby佔23%，Javascript佔20%，shell script佔5%，其他的13%。

代碼組織結構

在OpenNebula中，核心架構都是通過c++實現的，具體到業務時才使用Ruby，Shell這樣的語言，還是體現其指導原則：“輕量，簡單”。下面將具體介紹哪些是核心架構，哪些部分是業務邏輯，並且之處源碼中比較有價值的地方。

使用c++的部分用的是scons這個構建工具，高級版的make（http://www.scons.org/），他得“MakeFile”文件名叫：SConstruct。

OpenNebula的源碼地址：git://git.opennebula.org/one.git

源碼目錄如下：

├── install.sh
├── LICENSE
├── NOTICE
├── README.md
├── SConstruct
├── share
└── src  主要源碼

下面將分析上文提到的幾個服務進程的源碼。

oned

OpenNebula的core入口點，處理XML-RPC請求，監聽2633端口。

src/nebula/oned.cc 入口代碼。

src/nebula/Nebula.cc 核心代碼。在此文件中最關鍵的是start()方法，就是在此方法中啓動了各種ruby子進程，具體內容不贅述了。

在這串代碼中比較讓人疑惑的是，找不到用來解析XML-RPC請求的入口函數，或是任何和XML-RPC相關的註冊代碼。經過痛苦摸索後發現，XML-RPC被封裝在rm（RequestManager）代碼中，也就是在src/rm/RequestManager.cc文件中。

下面是代碼example：

RequestManager：register_xml_methods()

/* VM related methods  */
RequestManagerRegistry.addMethod("one.vm.deploy", vm_deploy);
RequestManagerRegistry.addMethod("one.vm.action", vm_action);
RequestManagerRegistry.addMethod("one.vm.migrate", vm_migrate); 

到此，XML-RPC請求註冊完畢，按照這個思路，大家就可以比較順利的閱讀代碼了。

one_*m.rb

上文提到過核心架構和具體實現。在OpenNebula中，每一個資源的管理都有對應的Manager，例如虛擬機的管理叫VirtualMachineManager(vmm)，虛擬網絡的管理叫VirtualNetworkManager（vnm)。

OpenNebula將每一個子功能都劃分到不同的目錄下，所以讀者可以找到src下的vmm，vnm等。同時還會發現類似vmm_mad，vnm_mad的目錄。這兩種目錄就對應着架構和具體實現，即前者(vmm)是架構相關的，後者(vmm_mad)是實現相關的。

在vmm中用c++定義了各個接口，以及調用方法，在vmm_mad中根據不同的策略有不同的實現。而選擇哪個實現是在oned.conf配置文件中定義的。

例如：oned.conf中關於vmm_mad的配置如下：

VM_MAD = [
 name = 'vmm_kvm'
 executable = 'one_vmm_exec'
 arguments = '-t 15 -r 0 kvm'
 default = 'vmm_exec/vmm_exec_kvm.conf'
 type = 'kvm'
]

可以看到`executable`指向的是one_vmm_exec，這個文件是ruby的可執行文件。這樣如果OpenNebula管理另外一種虛擬化技術，只要編寫對應的*_mad即可，並且OpenNebula的這種設計完全脫離了程序語言，理論上任何程序語言都可以擴展OpenNebula。

這些設計處處體現着OpenNebula輕量，簡單的思路。由於框架級別的改動很少，爲了獲得高效率，使用c++；在擴展性上，提供了任何語言都能夠擴展的接口，並默認提供了ruby的實現。

CLI

除了服務端，one的源碼中還自帶了CLI的源代碼。這裏也做簡要分析。

位於：one/src/cli 

裏面有很多Ruby寫的可執行文件，具體實現在此不贅述。

API 接口

源碼中提供了Java和Ruby的接口，就是對XML-RPC請求進行了封裝，

位於：src/oca/ruby和src/oca/java

總結

縱觀OpenNebula和OpenStack，兩者各有特點，個有所長也各有特點。“簡單輕量”是OpenNebula給人最深的印象，同時對於數據中心虛擬化的功能也較細緻和完善，值得OpenStack學習。

OpenNebula主頁

OpenNebula4.0從源碼編譯

OpenNebula XML-RPC API Reference