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