首先需要在前端节点上安装OpenNebula，具体的方法可以参见《Ubuntu 12.04 Server安装配置OpenNebula 3.8》这篇文章。

为了简单期间，我们使用前段节点所提供的NFS服务作为ESXi节点的存储设备。在创建NFS服务的时候需要export两个目录：

$ sudo vi /etc/exports
/var/lib/one/datastores/0 *(rw,sync,no_subtree_check,root_squash,anonuid=10000,anongid=10000)
/var/lib/one/datastores/1 *(rw,sync,no_subtree_check,root_squash,anonuid=10000,anongid=10000)

然后需要在前端节点上安装libvirt，并且使得其支持VMWare。

sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder ruby libgnutls-dev libdevmapper-dev libcurl4-gnutls-dev python-dev libnl-dev libapparmor-dev libpciaccess-dev

编辑/etc/libvirt/libvirtd.conf配置libvirt，将操作权限授予给cloud组：

unix_sock_group = “cloud”

编辑/etc/libvirt/qemu.conf配置libvirt，设置VNC：

vnc_listen = “0.0.0.0″

重启libvirt：

sudo service libvirt-bin restart
sudo chown oneadmin:cloud /var/run/libvirt/libvirt-sock

Ubuntu自带的libvirt不提供对VMWare的支持。我们需要手工编译安装libvirt 1.05，并设置为支持VMWare。

wget http://libvirt.org/sources/libvirt-1.0.5.tar.gz
tar xvzf libvirt-1.05.tar.gz 
cd libvirt-1.05
./configure --with-esx --with-apparmor --sysconfdir=/etc --libdir=/usr/lib --sbindir=/usr/sbin --datarootdir=/usr/share --localstatedir=/var --libexecdir=/usr/lib/libvirt
make
sudo make install

sudo cp -a examples/apparmor/usr.* /etc/apparmor.d/
sudo cp -a examples/apparmor/TEMPLATE /etc/apparmor.d/libvirt/ 
sudo cp -a examples/apparmor/libvirt-qemu /etc/apparmor.d/abstractions/ 
sudo cp /usr/local/bin/virsh /usr/bin/virsh 
sudo /etc/init.d/apparmor restart

export PERL_LWP_SSL_VERIFY_HOSTNAME=0

测试一下是否能够通过libvirt访问ESXi节点（在下面这个命令中，esxi01是ESXi节点的主机名）：

virsh -c esx://esxi01/?no_verify=1 --readonly nodeinfo

如果没有以外的话，你应该可以看到类似于下面的信息：

oneadmin@opennebula:~/libvirt-0.9.10$ virsh -c esx://esxi01/?no_verify=1 --readonly nodeinfo
Enter username for esxi01 [root]: 
Enter root's password for esxi01: 
CPU model:           Intel Core i5-3330S CPU @ 2.70G
CPU(s):              4
CPU frequency:       2693 MHz
CPU socket(s):       1
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         8283168 kB

从VMWare网站下载VMware-vSphere-CLI-5.0.0-615831.x86_64.tar.gz，按照如下步骤安装：

sudo apt-get install libxml-libxml-perl libclass-methodmaker-perl libcrypt-ssleay-perl curl libdata-uuid-libuuid-perl perl-doc uuid libuuid-perl
tar zxvf VMware-vSphere-CLI-5.0.0-615831.x86_64.tar.gz
cd vmware-vsphere-cli-distrib
perl Makefile.PL 
make

sudo perl -MCPAN -e shell

install Bundle::CPAN

编辑文件vmware-install.pl，修改下面这几行

      if ( !( $ftpproxy && $httpproxy)) {
         uninstall_file($gInstallerMainDB);
         exit 1;
      }

修改后的内容为：

      if ( !( $ftpproxy && $httpproxy)) {
#         uninstall_file($gInstallerMainDB);
#         exit 1;
      }

然后执行安装程序：

sudo ./vmware-install.pl 

安装完成后，测试一下是否可以访问ESXi主机：

esxcfg-nics -l --server esxi01 --username root

修改etc/oned.conf，取消下面这些配置的注释：

IM_MAD = [
      name       = "im_vmware",
      executable = "one_im_sh",
      arguments  = "-c -t 15 -r 0 vmware" ]

VM_MAD = [
    name       = "vmm_vmware",
    executable = "one_vmm_sh",
    arguments  = "-t 15 -r 0 vmware -s sh",
    default    = "vmm_exec/vmm_exec_vmware.conf",
    type       = "vmware" ]

修改etc/vmwarerc，提供访问ESXi节点的用户名和密码：

# Username and password of the VMware hypervisor
:username: "root"
:password: "Password"

编辑etc/vmm_exec/vmm_exec_vmware.conf，注释掉下面这一行：

#DISK = [ DRIVER = file ]

然后重新启动OpenNebula服务：

one stop
one start

［2］ESXi节点的配置

在ESXi节点上启用SSH服务，通过vSphere Client在ESXi节点上创建用户oneadmin和用户组cloud，其用户ID和用户组ID都设置为10000（与前端节点一致）。将oneadmin用户添加到root用户组，允许oneadmin用户通过SSH访问ESXi节点，并给oneadmin用户分配管理员（Administrator）权限。

通过vSphere Client将前端节点所提供的两个NFS服务分别挂载为0 和1 两个数据存储（datastore）。

用root用户登录到ESXi节点，创建目录/etc/ssh/keys-oneadmin，并将前端节点上/srv/cloud/one/.ssh/id_rsa.pub文件拷贝成为ESXi节点上的/etc/ssh/keys-oneadmin/authorized_keys，然后将该文件的所有者设置为oneadmin用户。

# cd /etc/ssh
# chown -R oneadmin keys-oneadmin

修改ESXi节点上的防火墙配置文件/etc/vmware/firewall/service.xml，在文件末尾添加VNC配置：

<!-- VNC -->
  <service id="0033">
    <id>VNC</id>
    <rule id='0000'>
        <direction>outbound</direction>
        <protocol>tcp</protocol>
        <porttype>dst</porttype>
        <port>
           <begin>5800</begin>
           <end>5999</end>
        </port>
     </rule>
     <rule id='0001'>
        <direction>inbound</direction>
        <protocol>tcp</protocol>
        <porttype>dst</porttype>
        <port>
           <begin>5800</begin>
           <end>5999</end>
        </port>
     </rule>
     <enabled>true</enabled>
     <required>false</required>
  </service>

重新启动防火墙：

# /sbin/esxcli network firewall refresh
# /sbin/esxcli network firewall ruleset list

在前端节点上运行下面这个命令，测试一下是否可以通过OpenNebula访问ESXi节点。如果配置成功的话，可以看到该节点的CPU和内存等信息。

/srv/cloud/one/var/remotes/im/run_probes vmware 0 esxi01

通过SunStone管理门户添加ESXi节点，其虚拟化平台和监控组件都设置为VMWare即可。

本文是对《CY12-Q4 OpenStack, OpenNebula，Eucalyptus，CloudStack社区活跃度比较》一文的补充和更新。对本文内容感兴趣的读者，可以通过电子邮件或者新浪微博（@qyjohn_）与我联系。

本文同时发布了一个英文版本，可以参见CY13-Q1 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack这个帖子。

需要说明的是，这个社区活跃度比较项目起源于CY11-Q4，此篇报告是到目前为止已经发布的第六个季度性的报告。尽管作者于2012年10月成为Eucalyptus公司的员工，但是本文中所表达之观点完全是作者本人的观点，而非作者所在公司的观点。还需要指出的是，作者所在的公司完全同意作者以独立的视角继续此项目。

本文的目的是通过论坛和邮件列表的原始数据对OpenStack、OpenNebula、Eucalyptus和CloudStack项目的社区活跃度进 行分析和比较。主要的原始数据是自2009年来这四个项目的官方论坛和邮件列表每个月所产生的讨论主题数、帖子数、以及参与讨论的总人数（邮件地址或者用 户账号）。为了获取这些数据，我写了一个Java程 序自动地从这四个项目的网站下载了所有的论坛和邮件列表信息，并且从这些信息中分析提取出我所需要的数据。程序提取的数据被导入MySQL数据库中以便进 行统计分析，统计分析的结果通过LibreOffice生成分析图表。

需要说明的是，Eucalyptus项目在今年2 月份将原来的社区邮件列表切换为基于Google group的新的邮件列表。这样的切换通常会给邮件列表的流量带来一定的影响。此外，从CY13-Q1开始，我们将CloudStack项目的users-cn邮件列表添加到我们的数据源当中。这个邮件列表目前占CloudStack相关流量的3～5%左右。未来我们还将会根据需要为此项分析添加新的数据源。

此外，我们发布CY12-Q2分析报告之后，有些读者指出来自incubator-cloudstack-dev邮件列表的数据可能有些问题。这个邮件列表里包含了一些由JIRA自动生成的邮件内容。在CY12-Q3的分析中，我们设置了一个过滤器，自动地排除了所有标题中含有”[jira]“标识符的信息。需要指出的是，我们注意到越来越多的技术讨论发生在JIRA系统当中。但是，我们暂时还是决定将来自JIRA的消息排除在此项分析之外。

图1 和图2分别是如上所述四个项目每个月所产生的讨论主题数和帖子数。可以看出：

(1) 与OpenStack和CloudStack相关的讨论数量远大于与Eucalyptus和OpenNebula相关的讨论数量；

(2) 在过去六个月中，与Eucalyptus相关的讨论数量在逐步攀升。虽然其讨论规模还远远小于与OpenStack和CloudStack相关的讨论规模，但是已经超过Eucalyptus本身的历史最高水平。

通常来讲，一个讨论主题得到的回复数越多，表明该主题的讨论越深入。一个论坛或者邮件列表如果只有主帖而没有回复，说明这个社区的参与程度很低。因此，平 均意义上的“讨论帖子数/讨论主题数”则反映了一个社区的参与程度，这里我们暂且称之为参与度（Participation Ratio）。

长期以来，OpenStack项目的参与度远高于其他三个项目的参与度。但是在过去十二个月中，CloudStack与Eucalyptus项目的参与度正在稳步增长，OpenStack项目的参与度正在逐步下降。目前CloudStack和Eucalyptus项目的参与度最高，接近于4；OpenStack与OpenNebula项目的参与度次之，接近于3。

图4 所示为这四个项目每个月参与论坛或者邮件列表讨论的总人数。可以看出，CloudStack与OpenStack的活跃用户数量要远大于OpenNebula和Eucalyptus。在过去六个月中，CloudStack, Eucalyptus和OpenStack项目的活跃用户数量都有不同程度的攀升。

值得一提的是，虽然CloudStack的活跃用户数量稍微小于OpenStack，这两个项目的主题和帖子数量是基本相当的。换句话说，CloudStack的用户在社区中比OpenStack的用户更加活跃。

累计社区人口（简称社区人口）指的是曾经通过论坛或者邮件列表参与过讨论的用户和开发者总数。（不包括在论坛或者邮件列表中注册但是从未公开参与讨论的社 区成员。）这些人或多或少地使用过相关产品，但是并不代表他们目前还是活跃用户。图5 所示为这四个项目的社区人口增长趋势。可以看出，OpenStack与Eucalyptus项目的社区人口遥遥领先，CloudStack与OpenNebula项目的社区人口相对较低。

在CY12-Q3报告中，我们提出了社区人口数据可能存在重复计数的问题。在CY12-Q4报告中，我们采取了进一步的措施以消除重复计数。可以认为，尽管重复计数的现象依然存在，但是已经降低到对分析结果不产生明显的影响的程度。

图6 所示为这四个项目每个月新增加的社区人口数量。在过去三个月中，CloudStack与OpenStack的社区人口增长速度基本相当。

与CloudStack和OpenStack向比较，Eucalyptus和OpenNebula的社区人口增长较为缓慢。

图7 是图4 与图6的重新组合。其中，实线部分表示的是每个月参与论坛或者邮件列表讨论的人数，虚线部分表示的是每个月新加入论坛或者邮件列表的人数。

OpenStack与OpenNebula项目的新增人口占当月活跃用户的30%左右，CloudStack与Eucalyptus项目大概是50%。如 果不考虑社区人口的规模的话，可以认为OpenStack与OpenNebula项目的粘性大于CloudStack与Eucalyptus项目。

图8 所示分别是本文所述四个项目的社区人口，过去一个季度的活跃用户数量，以及过去一个月的活跃用户数量。可以看出：

(1) OpenStack的社区人口最多，然后是Eucalyptus、CloudStack、OpenNebula；

(2) 在过去一个季度中，OpenStack的活跃人口最多，然后是CloudStack、Eucalyptus、OpenNebula；

(3) 在过去一个月份中，OpenStack的活跃人口最多，然后是CloudStack、Eucalyptus、OpenNebula。

在CY12-Q3分析中，我们首次提出了“社区活跃度指数”这样一个参数。这个参数是如下几个参数的某种组合：

(1) 当月帖子总数，代表相关讨论的规模；

(2) 当月参与度，代表每个问题获得的回帖数量；

(3) 当季活跃用户，代表从社区获得帮助的可能性（长期）；

(4) 当月活跃用户，代表从社区获得帮助的可能性（短期）。

在这个分析中，我们选择如上各个社区的平均值作为参考数据，并将每个社区的数据与参考数据进行比较。我们将每个社区各个参数与平均值的比值之和称为“社区活跃度指数”。可以认为，社区活跃度指数最高的项目，是最活跃的项目。

从图9 中可以看出，目前OpenStack项目的“社区活跃度指数”最高（以明显的优势领先），然后是CloudStack、Eucalyptus、 OpenNebula。

如上所述“社区活跃度指数”的概念还非常原始，还有很大的优化空间。它有点在于用量化分析的方法取代了传统的感性分析，例如“我认为”、“我相信”、“我猜测”等等。在未来的报告中，我们将基于这个概念每个季度发布一次OpenStack、OpenNebula、 Eucalyptus、CloudStack项目的“社区活跃度指数”排名。当然，我们也会在必要的时候对相关算法进行调整，例如增加或者删除某些参数，或者是调整某些参数的权重。

曾经有多位读者建议我们基于Git活动对各个主流的开源IaaS项目的开发情况进行分析。我们注意到CloudStack、Eucalyptus、OpenNebula以及OpenStack项目都将代码托管在github.com上。因此，我们基于来自github.com的数据对这几个项目的开发情况进行了一些简单的分析。需要指出的是，对于OpenStack项目来说，其数据源包括了托管在github.com上的Cinder、Glance、Horizon、Keystone、Nova、Quantum和Swift子项目。

图10所示分别是本文所述四个项目每个月向github.com提交代码（commit操作）的次数。总体来看，OpenStack项目提交代码的频率较高，平均每个月提交代码1000次左右，活动最为密集的的一个月达到了2000次之多。OpenNebula项目提交代码的频率较低，平均每个月提交代码200次左右。CloudStack和Eucalyptus两个项目提交代码的频率在同一水平线上，但是Eucalyptus项目存在较大的波动情况，具有比较明显的批量更新的特征。

图11所示分别是OpenStack项目中各个子项目目每个月向github.com提交代码（commit操作）的次数。总体来看，Nova子项目提交代码的频率较高，是其他几个子项目的三倍左右。值得注意的是，尽管各个子项目提交代码的频率各不相同，但是其时程曲线基本上是一致的，波峰和波谷基本上出现在相同的时间。这个现象表明尽管OpenStack项目中各个子项目相对独立，但是具有相同或者相似的开发计划和开发进度。可以认为，OpenStack项目在子项目的管理和协调方面是做得比较好的。

图12所示分别是本文所述四个项目每个月向github.com提交代码（commit操作）的人数。总体来看，OpenStack项目提交代码的人数远远超过其他三个项目，并且一直保持迅猛增长的势头。CloudStack项目提交代码的人数也有所增长，但是其增长速度较为缓慢。Eucalyptus项目和OpenNebula项目提交代码的人数相对较少，并且在过去六个月当中基本上没有增长。

图13所示分别是OpenStack项目中各个子项目每个月向github.com提交代码（commit操作）的人数。总体来看，Nova子项目提交代码的人数较多，是其他几个子项目的三倍左右。

人们通常通过代码贡献者所使用的电子邮件地址来识别其所在的机构。尽管这种方式存在较大的缺陷（例如有一些机构鼓励雇员以个人的名义向开源项目贡献代码），但是还是可以从某种程度上揭示不同机构对某个开源项目的贡献力度。图14所示分别是每个月向本文所述四个项目提交代码（commit操作）的邮件地址所属域名数量。总体来看，OpenStack项目提交代码的域名数量远远超过其他三个项目，并且一直保持迅猛增长的势头。CloudStack项目提交代码的域名数量也有所增长，但是其增长速度较为缓慢。Eucalyptus项目和OpenNebula项目提交代码的域名数量相对较少，并且在过去六个月当中基本上没有增长。

图15所示分别是OpenStack项目中各个子项目每个月向github.com提交代码（commit操作）的域名数量。总体来看，Nova子项目提交代码的域名数量较多，是其他几个子项目的三倍左右。

下面这个表格以电子邮件所属域名的形式列出了在CY13-Q1期间向CloudStack、Eucalyptus、OpenNebula和OpenStack项目贡献代码次数最多的机构（以及贡献代码次数的百分比）。可以看出，Eucalyptus和OpenNebula属于以单一机构为主导的开源项目，而CloudStack和OpenStack属于由多家机构共同合作的开源项目。对于CloudStack项目来说，来自Citrix的影响非常明显，直接来自citrix.com和cloud.com的邮件地址占了45%。对于OpenStack项目来说，由于来自review.openstack.org的贡献是由一个代码评审系统使用一个帐号（jenkins@review.openstack.org）自动发布的，我们无法评估Rackspace对该项目的影响程度。值得注意的是，在FY13-Q1期间来自redhat.com的贡献占了9%，而来自ibm.com（linux.vnet.ibm.com和us.ibm.com）的贡献占了7%，可以认为Rackspace对OpenStack项目的控制程度正在逐步减弱。

下面这个表格以电子邮件所属域名的形式列出了在CY13-Q1期间向OpenStack项目各个子项目贡献代码最多的机构（以及贡献代码次数的百分比）。

与本文相关的PDF版本幻灯片可以从这里下载。如果您需要重新分发本文内容，敬请您保留相关作者信息。

This article is an update version of my previous article CY12-Q4 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack. Readers who are intested in further discussions please contact me via email at the above-mentioned address.

A Chinese version of this article is published at the same time, which can be found at CY13-Q1 OpenStack, OpenNebula, Eucalyptus, CloudStack社区活跃度比较.

It should be noted that this community analysis project was initiated in CY11-Q4, and this particular report is the 6th quarterly report being published since. Although the author became an employee of Eucalyptus Systems Inc in October 2012, the opinion presented in this report belongs strictly to the author rather than the employer of the author. It should also be noted that the employer of the author completely agreed that the author could continue this project with an independent perspective.

The objective of this article is to compare the OpenStack, OpenNebula, Eucalytpus and CloudStack user and developer communities, base on the communications between community members in the form of mailing lists or pubic forum discussions. The data being discussed include the total number of topics (threads), messages (posts), and participants (unique email addresses or registered members). To obtain the above-mentioned data, a Java program was written to retrieve all the forum posts and mailing list messages into a MySQL database for further processing. The analysis results were presented in the form of graphs generated by LibreOffice.

It should be noted that the Eucalyptus project moved from the original community mailing lists to a Google group based mailing list in mid February. Such changes will usually bring some impact on the traffic to the mailing list. Also, starting from CY13-Q1 we are adding the users-cn mailing list for the CloudStack project into this analysis. This mailing list currently represents 3~5% of the CloudStack mailing list traffic. We will add other data source into this analysis in the future when such data source is big enough to produce an impact.

Also, when the CY12-Q2 report was published, some people questioned the inclusion of the incubator-cloudstack-dev mailing list. This particular mailing list contains a lot of messages that are automatically generated by JIRA. In CY12-Q3, we set up a filter to reject all messages with identifier “[jira]” in the subject. It should be noted that there are increasing level of technical discussions happened in the JIRA activities. However, at this point we still decided to filter out messages from JIRA.

Figure 1 and 2 represent the monthly number of topics (threads) and posts (messages). It can be seen that

(1) the volume of OpenStack and CloudStack related discussions is much higher than that of Eucalyptus and OpenNebula; and

(2) during the past 6 months, Eucalyptus related discussions are growing. Although the volume of Eucalyptus related discussions is still smaller than OpenStack and CloudStack, it has exceeded the peak created by itself three years ago.

Generally speaking, the number of replies to a specific topic represents the attention being received, and the depth of discussion for that particular topic. When the number of master posts (the original post that started a particular topic) is more than the number of replies, it is safe to conclude that the participation of the forum or mailing list is very low. Therefore, the ratio between “the number of  posts” and “the number of topics” represents the participation rate of an online community. In this study we call this ratio the Participatin Ratio.

In the past the OpenStack project had a much higher participation ratio than the others. However, during the past 6 months, the participation ratio of CloudStack and Eucalyptus are growing steadily, while the participation ratio of OpenStack is decreasing gradually. Currently CloudStack and Eucalyptus have the highest participation ratios, which are close to 4. OpenStack and OpenNebula have relatively low participation ratios, which are close to 3.

Figure 4 shows the number of monthly participants of the four projects being discussed. It can be seen that the active participants of CloudStack and OpenStack are much higher than OpenNebula and Eucalyptus. During the past 6 months, the number of active participants for CloudStack, Eucalyptus and OpenStack are growing at various degrees.

It should be noted that although the number of active participants of CloudStack is somewhat less than OpenStack, but the volume of discussion (in terms of monthly number of threads and messages) of the two projects are on the same level. This indicates that the active members in the CloudStack club are talking more than those in the OpenStack club (on average).

Accumulated Community Population refers to the total number of users and developers who have participated in forum or mailing list discussions. (This number does not include those who have registered into discussion forums or mailing lists but have never participated in any open discussions.) These are people who have tested or used a specific product for a while, but not necessary currently an active user.

In our CY12-Q3 report, we raised the problem of possible duplicated population counting due to the membership overlap in forums and mailing lists, and carried some measurements to eliminate duplications. Starting from our CY12-Q4 report, further measurements were taken to de-duplication. It is safe to say that some degree of duplication still exists, but does not have a significant impact on the analysis results.

Figure 6 shows the monthly population growth of the four projects being discussed. During the past 3 months, the populations of OpenStack and CloudStack are growing at about the same pace.

The populations of Eucalyptus and OpenNebula are growing at relatively slow paces, as compared to that of CloudStack and OpenStack.

Figure 7 is a combination of Figure 4 and Figure 6. The solid lines represent the monthly participants, while the dash lines represent the monthly new members.

For OpenStack and OpenNebula, around 30% of their monthly participants are new members.  For CloudStack and Eucalyptus, around 50% of their monthly participants are new members. This indicates OpenStack and OpenNebula communities are more “sticky” than CloudStack and Eucalyptus communities.

Figure 8 shows the total community population, active participants of the past quarter, and active participants of the past month, of the four projects being discussed. It can be seen that

(1) OpenStack has the largest total population, followed by Eucalyptus, CloudStack, and OpenNebula;

(2) OpenStack has the largest active population during the past quarter, followed by CloudStack, Eucalyptus, and OpenNebula;

(3) OpenStack has the largest active population during the past month, followed by CloudStack, Eucalyptus, and OpenNebula.

In our CY12-Q3 report, we invented the concept of “Community Activeness Index”. This magic number should be the combination of the following parameters:

(1) monthly messages, which represents the volume of the discussions;

(2) participation ratio, which represents the average number of answers to a question;

(3) active population of the past quarter, which represents the possibility to get help from community in the long term; and

(4) active population of the past month, which represents the possibility to get help from the community in the short term.

In this analysis, we choose the average values of these parameters as the reference data set, and compare the corresponding parameters of each community with the reference data set. Then we call the sum of the relative values of a community the “community activeness index” of the community. Now we can say the project with the highest “community activeness index” is THE most active project in this area.

As can be seen from Figure 9, OpenStack is currently THE most active project (with obvious advantage), followed by CloudStack, Eucalyptus, and OpenNebula.

The above-mentioned concept of “community activeness index” is still very primitive, with a lot of space to optimize. However, it is an attempt to replace the old-fashion “I think”, “I believe” and “I guess” practices with quantative analysis. In our future community analysis, we will continue to use this concept to provide a quarterly ranking for OpenStack, OpenNebula, Eucalyptus, and CloudStack. Improvements to the algorithm (such as adding/removing parameters or changing the weight of different parameters) will be make when necessary.

We are seeing increasing number of suggestions to analyze the git activities of these open source IaaS projects. We also noticed that all of these four projects host their source code on github.com. So, in this CY13-Q1 report, we try to do some basic analysis base on the data from github.com. It should be noted that for the OpenStack project, the data source includes the Cinder, Glance, Horizon, Keystone, Nova, Quantum and Swift sub-projects hosted on github.com.

Figure 10 shows the monthly number of commit operations for these four projects. Generally speaking, the commit frequency of the OpenStack project is much higher than the others, with an average number of 1000 commits per month (and a peak value of 2000 commits in mid 2011). The commit frequency of the OpenNebula project is relatively small, with an average of 200 commits per month. The commit frequencies of CloudStack and Eucalyptus are similar, but there is significant fluctuation for the Eucalyptus project, which seems to be a typical batch-commit behavior.

Figure 11 shows the monthly number of commit operations for the sub-projects of OpenStack. Generally speaking, the commit frequency of the Nova sub-project is about 3 times as high as the other sub-projects. It should be noted that although the commit frequency of these sub-projects are different, but they exhibit similar time-series curves, and their highs and lows occur at the same period of time. This indicates that although these sub-projects are relatively independent, but they work around the same development plan and the same release schedule. This is an indicator that the OpenStack project is well organized in terms of sub-project management.

Figure 12 shows the monthly number of contributors (identified by unique github.com accounts) for these projects. Generally speaking, the number of OpenStack contributors is much higher than the other three projects, and is growing rapidly. The number of CloudStack contributors also exhibits some growth, but the growth is relatively slow. The number of Eucalyptus and OpenNebula contributors is relatively small, and does not exhibit any growth during the past 6 months.

Figure 13 shows the monthly number of contributors (identified by unique github.com accounts) for the sub-projects of OpenStack. It can be seen that the number of Nova contributors is about 3 times as big as the other sub-projects.

People usually try to identify the institute to which a contributor belongs to by his/her email address. It is true that such method is defect in nature (different institutes have different policies regarding contributing to open source projects, some institutes even encourage their employees to contribute to open source projects with their personal account), but still this parameter can be used to show the contributions of certain institutes to certain open source projects. Figure 14 shows the monthly number of unique institutes (identified by the domain name of the contributor’s email address) contributing to these projects. We can see that the number of contributing institutes for OpenStack is much larger than the other three projects, and is growing rapidly. The number of contributing institutes for CloudStack is also growing, but at a relatively slow pace. The number of contributing institutes to Eucalyptus and OpenStack is relatively small, and does not exhibit any growth during the past 6 months.

Figure 15 shows the monthly number of contributing institutes to the sub-projects of OpenStack. It can be seen that the number of contributing institutes for Nova is about 3 times as big as the other sub-projects.

The following table lists those institutes that make the most contributions to these projects during CY13-Q1, according to the number of commit operations on github.com, along with the percentage of their commit operations. It can be seen that both Eucalyptus and OpenNebula are open source projects dominated by a single institute, while CloudStack and OpenStack are open source projects contributed by multiple institutes. For the CloudStack projects, influence from Citrix is quite obvious, over 45% of github.com commits come from accounts belonging to citrix.com and cloud.com. For the OpenStack project, it is not that easy to determine the influence of Rackspace, because the majority of the commits come from a code review system (review.openstack.org) with a single github.com account (jenkins@review.openstack.org). However, we noticed that during CY13-Q1 redhat.com contributed 9% of the commits, while ibm.com (linux.vnet.ibm.com and us.ibm.com combined) contributed 7% of the commits. It is safe to say that the influence of Rackspace on the OpenStack project is gradually decreasing.

The following table lists those institutes that make the most contributions to the sub-projects of OpenStack during CY13-Q1, along with the percentage of their commit operations.

For your convienience, a PDF version of this presentation can be downloaded from here. Please kindly keep the author information if you want to redistribute the content.

安装完操作系统之后，安装必要的软件：

$ sudo apt-get install chkconfig lvm2 iscsitarget iscsitarget-dkms

创建物理卷/dev/sda2：

$ sudo pvcreate /dev/sda2

在物理卷/dev/sda2上创建一个volume group：

$ sudo vgcreate -s 32M vg_target00 /dev/sda2

看一下刚才创建的volume group:

$ sudo vgdisplay

--- Volume group ---
VG Name vg_target00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 419.19 GiB
PE Size 32.00 MiB
Total PE 13414
Alloc PE / Size 0 / 0
Free PE / Size 13414 / 419.19 GiB
VG UUID vZplQx-DRjE-Kd4k-tr4e-RV6m-nIr2-k7SEvt

在如上volume group中创建一个逻辑卷lv_target00：

$ sudo lvcreate -L 50G -n lv_target00 vg_target00

看一下刚才创建的逻辑卷：

$ sudo lvdisplay

--- Logical volume ---
LV Name /dev/vg_target00/lv_target00
VG Name vg_target00
LV UUID gD9RO2-xAqr-3u5c-mM1H-O3l8-E3ra-XRT9QT
LV Write Access read/write
LV Status available
# open 0
LV Size 50.00 GiB
Current LE 1600
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0

修改文件/etc/default/iscsitarget，启用iSCSI Target服务：

ISCSITARGET_ENABLE=true

修改文件/etc/iet/ietd.conf，配置iSCSI Target服务的参数（这里假定使用iSCSI Target服务的机器IP为192.168.100.104）：

Target iqn.2013-03.world.server:target0
Lun 0 Path=/dev/mapper/vg_target00-lv_target00,Type=blockio
initiator-address 192.168.100.104
incominguser test_user test_pass

重启一下iscsitarget服务：

$ sudo service iscsitarget restart

将iscsitarget服务设置为开机后自动启动：

$ sudo chkconfig iscsitarget on

看一下刚刚启动的iscsitarget服务：

$ sudo ietadm --op show --tid=1

Wthreads=8
Type=0
QueuedCommands=32
NOPInterval=0
NOPTimeout=0

到这里为止，iSCSI Target服务就已经配置完毕了。接下来我们在需要挂载iSCSI Target的机器（也称为iSCSI Initiator）上做一些配置：

$ sudo apt-get install open-iscsi

修改配置文件/etc/iscsi/iscsid.conf：

# line 39: uncomment
node.session.auth.authmethod = CHAP

# line 43,44: uncomment and set username and password which set on iSCSI Target
node.session.auth.username = test_user
node.session.auth.password = test_pass

使用下面这个命令发现iSCSI Target服务（这里假定提供iSCSI Target服务的机器IP为192.168.100.5）：

$ sudo iscsiadm -m discovery -t sendtargets -p 192.168.100.5 
192.168.100.5:3260,1 iqn.2013-03.world.server:target0

使用下面这个命令确认iSCSI Target服务的具体信息：

$ sudo iscsiadm -m node -o show

使用下面这个命令登陆到iSCSI Target服务：

$ sudo iscsiadm -m node --login

使用下面这个命令确认登录session的情况：

$ sudo iscsiadm -m session -o show

这个时候你应该能够通过/proc/partitions看到多出来一个分区（sdb）：

$ more /proc/partitions

major minor  #blocks  name

  11        0    1048575 sr0
   8        0    8388608 sda
   8        1     248832 sda1
   8        2          1 sda2
   8        5    8136704 sda5
 252        0    7581696 dm-0
 252        1     520192 dm-1
   8       16   52428800 sdb

也可以使用fdisk命令查看分区情况，应该可以看到/dev/sdb的相关信息：

$ sudo fdisk -l

Disk /dev/sdb: 53.7 GB, 53687091200 bytes
64 heads, 32 sectors/track, 51200 cylinders, total 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

这个时候就可以正常地格式化、挂载、和使用/dev/sdb了。

如果不打算继续使用这个分区了，可以从iSCSI Target退出服务：

$ sudo iscsiadm -m node --logout

首先从github上下载PHP-AWS类库：

git clone https://github.com/tylerhall/php-aws/

进入php-aws目录，修改class.ec2.php文件，主要是设定身份认证信息和EC2端点。在这里我使用的是桉树社区云（Eucalyptus Community Cloud，ECC）服务的帐号进行测试。

var $_key = “EC2_ACCESS_KEY”;
var $_secret = “EC2_SECRET_KEY”;
var $_server = “http://eucalyptus.ecc.eucalyptus.com:8773/services/Eucalyptus”;

下面这段程序，列出所有可用的映像：

require_once(“class.ec2.php”);
$ec2 = new EC2();
$images = $ec2->getImages();
foreach ($images as $image_id=>$image)
{
$image_location = $image["location"];
print_r($image_id . ” ” . $image_location . “\n”);
}

下面这段程序，启动一个虚拟机实例（需要将emi-XXXXXXXX替换成实际的EMI名称）：

$ec2->runInstances(“emi-575A398B”, 1, 1, “key_name”);

下面这段程序，列出所有虚拟机实例：

$instances = $ec2->getInstances();
foreach ($instances as $instance_id=>$instance)
{
$image_id = $instance["imageId"];
$state = $instance["state"];
$dns = $instance["dns"];
print_r($instance_id . ” ” . $image_id . ” ” . $state . ” ” . $dns . “\n”);
}

下面这段程序，销毁一个虚拟机实例（需要将i-XXXXXXXX替换成实际的实例名称）：
 
$ec2->terminateInstances(“i-0DF73F93″);

// 首先导入必要的类库
import java.util.*;
import com.amazonaws.*;
import com.amazonaws.auth.*;
import com.amazonaws.services.ec2.*;
import com.amazonaws.services.ec2.model.*;

// 定义一个类
public class AwsConsoleApp
{

// 必要的登录信息
// 如果要用来测试AWS公有云服务，需要使用AWS的帐号信息
// 如果要用来测试Eucalyptus私有云服务，可以从eucarc文件中找到这些帐号信息
static String EC2_ACCESS_KEY=”THIS_IS_AN_EC2_ACCESS_KEY”;
static String EC2_SECRET_KEY=”THIS_IS_AN_EC2_SECRET_KEY”;
// 这个信息也可以从eucarc文件中找到，
static String EC2_END_POINT =”http://eucalyptus.ecc.eucalyptus.com:8773/services/Eucalyptus”;
static AmazonEC2 ec2;

// 创建一个AWSCredentials类的实例，包含登录信息
// 设定访问AWS（Eucalyptus）云的端点
private static void init() throws Exception
{
AWSCredentials myCredential = new BasicAWSCredentials(EC2_ACCESS_KEY, EC2_SECRET_KEY);
ec2 = new AmazonEC2Client(myCredential);
ec2.setEndpoint(EC2_END_POINT);
}

// 测试方法
public static void main(String[] args) throws Exception
{
// 初始化登录信息和访问端点
init();

// 获得所有的可用域列表
try
{
DescribeAvailabilityZonesResult availabilityZonesResult = ec2.describeAvailabilityZones();
List zones = availabilityZonesResult.getAvailabilityZones();
System.out.println(“You have access to ” + zones.size() + ” availability zones.”);
for(AvailabilityZone zone : zones)
{
System.out.println(” ” + zone.getZoneName());
}
} catch (AmazonServiceException ase)
{
System.out.println(“Caught Exception: ” + ase.getMessage());
}

// 获得所有的映像列表
try
{
DescribeImagesResult imagesResult = ec2.describeImages();
List images = imagesResult.getImages();
System.out.println(“You have access to ” + images.size() + ” images.”);
for(Image image : images)
{
System.out.println(” ” + image.getImageId() + ” ” + image.getImageType() + ” ” + image.getName());
}
} catch (AmazonServiceException ase)
{
System.out.println(“Caught Exception: ” + ase.getMessage());
}

// 创建两个虚拟机实例
try
{
RunInstancesRequest runInstancesRequest = new RunInstancesRequest()
.withInstanceType(“m1.small”)
.withImageId(“emi-575A398B”)
.withMinCount(1)
.withMaxCount(2)
.withKeyName(“name_of_your_key”)
;
RunInstancesResult runInstances = ec2.runInstances(runInstancesRequest);
} catch (AmazonServiceException ase)
{
System.out.println(“Caught Exception: ” + ase.getMessage());
}

// 获得所有的虚拟机列表
try
{
DescribeInstancesResult describeInstancesResult = ec2.describeInstances();
List reservations = describeInstancesResult.getReservations();
System.out.println(“You have ” + reservations.size() + ” reservations.”);
for (Reservation reservation : reservations)
{
System.out.println(” ” + reservation.getReservationId());
List instances = reservation.getInstances();
for (Instance instance : instances)
{
System.out.println(” ” + instance.getInstanceId() + ” ” + instance.getInstanceType() + ” ” + instance.getPrivateIpAddress() + ” ” + instance.getPublicIpAddress() + ” key: ” + instance.getKeyName() + ” ” + instance.getState().getName());
}
}
} catch (AmazonServiceException ase)
{
System.out.println(“Caught Exception: ” + ase.getMessage());
}

// 杀死一个虚拟机实例
try
{
List instancesToTerminate = new ArrayList();
instancesToTerminate.add(“ID_of_the_Instance”);
TerminateInstancesRequest term = new TerminateInstancesRequest();
term.setInstanceIds(instancesToTerminate);
ec2.terminateInstances(term);
} catch (AmazonServiceException ase)
{
System.out.println(“Caught Exception: ” + ase.getMessage());
}

}
}

但是，理想与现实之间总是存在差距的。Eucalyptus以AWS为原型不断地完善自身所提供的功能，而AWS也在不断地对现有的服务进行改进。在目前这个阶段，Eucalyptus还无法100%地实现AWS所提供的各种功能和特性。举个例子来说，一个基于最新版本的AWS SDK for Java的应用，直接用来管理一个基于Eucalyptus的私有云，可能还是会遇到一些意想不到的问题。因此，Eucalyptus公司对AWS SDK for Java打了一些补丁。使用打了Eucalyptus补丁的AWS SDK for Java之后，原有的应用无需进行任何修改即可同时用来管理基于AWS的公有云以及基于Eucalyptus的私有云。这听起来好像很复杂，但是操作起来很简单 － 你只需要下载一个我们打了补丁的JAR文件，用其替代掉原来的JAR文件即可。

如果你从来没有使用过AWS SDK for Java，你需要做一些入门的功呢。具体的教程可以从这里获得。这篇博客文章假定您已经按转配置好AWS SDK for Java，并且能够成功地运行其中的一些演示程序。接下来您需要做的是从下面这个链接下载Eucalyptus公司打过补丁的AWS SDK for Java，并用这个新的JAR文件替换掉原来的JAR文件。

http://jeevanullas.in/tmp/aws-java-sdk-1.3.26.jar

下面这段简单的Java代码，演示了如何通过AWS SDK for Java来对基于Eucalyptus的私有云进行操作。这里我使用了我在Eucalyptus社区云服务（Eucalyptus Community Cloud）中的个人帐号进行测试。

/*
* 导入必要的类库
*/

import java.util.HashSet;
import java.util.List;
import java.util.Set;
import com.amazonaws.AmazonClientException;
import com.amazonaws.AmazonServiceException;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.ec2.AmazonEC2;
import com.amazonaws.services.ec2.AmazonEC2Client;
import com.amazonaws.services.ec2.model.DescribeAvailabilityZonesResult;
import com.amazonaws.services.ec2.model.DescribeInstancesResult;
import com.amazonaws.services.ec2.model.Instance;
import com.amazonaws.services.ec2.model.Reservation;

public class AwsConsoleApp
{

// 必要的登录信息
// 如果要用来测试AWS公有云服务，需要使用AWS的帐号信息
// 如果要用来测试Eucalyptus私有云服务，可以从eucarc文件中找到这些帐号信息
static String EC2_ACCESS_KEY=”THIS_IS_AN_EC2_ACCESS_KEY”;
static String EC2_SECRET_KEY=”THIS_IS_AN_EC2_SECRET_KEY”;
// 这个信息也可以从eucarc文件中找到，
static String EC2_END_POINT =”http://eucalyptus.ecc.eucalyptus.com:8773/services/Eucalyptus”;
static AmazonEC2 ec2;

// 创建一个AWSCredentials类的实例，包含登录信息
// 设定访问AWS（Eucalyptus）云的端点
private static void init() throws Exception
{
AWSCredentials myCredential = new BasicAWSCredentials(EC2_ACCESS_KEY, EC2_SECRET_KEY);
ec2 = new AmazonEC2Client(myCredential);
ec2.setEndpoint(EC2_END_POINT);
}

// 测试方法
public static void main(String[] args) throws Exception
{
// 初始化登录信息和访问端点
init();

try
{
// 获得所有的可用域列表
DescribeAvailabilityZonesResult availabilityZonesResult = ec2.describeAvailabilityZones();
System.out.println(“You have access to ” + availabilityZonesResult.getAvailabilityZones().size() +
” Availability Zones.”);
// 获得所有的虚拟机列表
DescribeInstancesResult describeInstancesRequest = ec2.describeInstances();
List<Reservation> reservations = describeInstancesRequest.getReservations();
Set<Instance> instances = new HashSet<Instance>();

for (Reservation reservation : reservations)
{
instances.addAll(reservation.getInstances());
}

System.out.println(“You have ” + instances.size() + ” Amazon EC2 instance(s) running.”);
} catch (AmazonServiceException ase) {
System.out.println(“Caught Exception: ” + ase.getMessage());
System.out.println(“Reponse Status Code: ” + ase.getStatusCode());
System.out.println(“Error Code: ” + ase.getErrorCode());
System.out.println(“Request ID: ” + ase.getRequestId());
}

}
}

在Eucalyptus 3.3中，将会进一步增强Eucalyptus与AWS之间的兼容性。在AWS SDK for Java这方面，您可以通过如下两个链接了解我们正在做的工作。

https://github.com/eucalyptus/architecture/wiki/aws_java_sdk-3.3-design
https://github.com/eucalyptus/architecture/wiki/aws_java_sdk-3.3-spec

通过Google查找了一下，有一个叫做UNetbooin的工具，可以将ISO转录成可启动U盘。这个工具有Windows、Linux和Mac几个不同的版本，可以通过下面这个链接下载：

http://unetbootin.sourceforge.net/

我在Mac上下载并运行UNetbooin这个工具，选择下载到的ISO文件（faststart-3.2.1.iso），并从设备列表中选择正确的U盘，点击OK按钮将ISO文件转录到U盘上（如下图所示）。大概过了两三分钟时间，就完成了转录。完成转录之后，还需要将ISO文件（faststart-3.2.1.iso）拷贝到U盘的根目录。

将U盘插到上网本上，设置上网本从U盘启动。呀呀，Missing Operating System！启动不来。

Google了一下关键字，发现需要通过fdisk程序激活U盘的引导分区。将U盘插回到Mac上，进行如下设置（假设你的U盘是/dev/disk2，如果你不知道你的U盘是啥的话，可以通过diskutil list查看）：

fdisk -e /dev/rdisk2

f 1

write

exit

将U盘插到上网本上，启动成功，一路安装成功。

特别需要说明的是，本人的博客文章仅仅代表个人观点，而不代表本人所在公司的观点。

（1）如何评价中国IaaS市场的整体发展？

目前国内的公有云市场的不可知与不可控因素比较多。从服务提供商的维度看，传统IDC服务提供商、大型互联网企业、以及小型创业公司同场竞技，似乎是百花齐放百家争鸣的一片大好局面；从具体产品的维度看，大部分所谓“云计算”产品基本上还停留在国外五年前的虚拟主机这个层次，而忽视用户体验已经成为整个行业的共同特征；从服务质量的维度看，大部分服务提供商没有为产品提供SLA保障，整个行业普遍缺乏质量评估与质量控制体系。在整个行业成熟度较低的情况下，部分规模较大的服务提供商已经开始通过价格战抢占市场。这样的短视行为使得公有云市场在短时间内沦落为红海，公有云服务沦落为物廉价美的代名词，也导致公众普遍认为使用公有云服务存在较大的风险。

相比之下，国内的私有云市场显得相对成熟。大型互联网企业基本上都有自己的私有云规划，部分先行者已经完成私有云的实施。更重要的是，地方政府和传统行业的IT部门纷纷表示出对云计算的兴趣，开始评估实施云计算所需要的投入以及可能的收益。在过去两年间，国内市场上涌现出大量在国外开源软件的基础上简单地改头换面后形成的自有品牌云管理平台，其目标客户基本上都是地方政府和传统行业的IT部门。可以比较乐观地认为，国内的私有云市场已经开始进入了收割期。

对于公有云市场来说，主要的困难在于解决用户的信任问题。经过多年的市场培育，现在很多用户已经逐渐接受了公有云服务的概念，并且愿意使用Amazon或者Linode等等国外云主机服务，但是对使用国内云主机服务心存疑虑。在过去两年间，阿里云和盛大云都发生过云主机宕机以及用户数据丢失的事故，使得原本就很突出用户信任的问题雪上加霜。除此之外，由于国家政策以及运营商之间恶性竞争等等原因，数据中心之间的互联互通问题非常突出。这使得公有云服务降级为通过物廉价美的VPS替代价格昂贵的主机租赁业务，无法承载大型互联网应用的压力，更无法成为培育新型应用和新型业务模式的温床。

对于私有云市场来说，最大的困难则在于降低客户的期望值。特别是在非IT行业，云计算的推广基本上是销售先行吹牛，技术跟进善后。这样造成的结果就是客户认为云计算几乎是无所不能的，就像前几年被神化的ERP一样，云计算俨然已经成了解决企业IT问题的新万金油。需要强调的是，云计算不是一种新的IT技术，而是一种新的IT模式。这种新的IT模式要求用户以新的方式来使用IT资源，譬如说应用程序需要考虑虚拟机的性能特性，需要从架构层面支持横向扩展，甚至是逐步具备“云觉知”的能力。如果客户仅仅是打算把历史遗留应用迁移到云平台上的话，可能不能够充分发挥云计算的优势，甚至是得到完全相反的效果。

（2）如何看待国际IaaS服务提供商进军中国市场？

亚马逊和微软的云服务进入中国，对本土IaaS服务提供商而言仅仅具有参考作用。在技术层面上，本土研发团队应该早就对亚马逊和微软的云服务有所了解，没有在其产品中提供与亚马逊和微软类似的功能应该是出于市场方面的考虑。在市场层面上，国外大企业或者由于法律和道德方面的双重制约而不具备与国内企业进行正面竞争的能力（例如搜索领域的谷歌），或者只能够在牺牲服务水准的前提下与国内企业进行竞争（例如电商领域的卓越亚马逊）。可以认为，亚马逊和微软的云服务在国内也许可以落地，但是其发展前景并不乐观。整体来说，中国的电信市场是一个保护性非常强的市场，这一点给国外厂商所带来的不便要远大于给本土厂商所带来的不便。对于本土IaaS服务提供商而言，不存在所谓时间窗口的问题，只有国际巨头什么时候黯然离场或者是沦落为本土厂商的问题。

（3）如何看待IaaS服务提供商的混合交付能力？

从现阶段的情况来看，国内大部分公有云产品基本上还停留在国外五年前的虚拟主机这个层次，尚不具备提供混合交付的能力。从技术层面来考虑，提供混合交付能力需要服务提供商支持一系列类似于AWS API的编程接口，目前大部分国内厂商都具备实现这些编程接口的能力。从市场层面来考虑，提供混合交付能力意味着用户能够在公有云和私有云之间进行切换，也意味着用户能够在不同的公有云之间进行切换。换句话说，提供混合交付能力意味着存在用户流失的风险，规模较大的服务提供商一般不会主动拓展这方面的能力，但是处于起步阶段的创业企业有可能会将此作为吸引用户的重要特性。

（4）如何看待企业内部私有IaaS服务？

Eucalyptus公司在中国的业务主要帮助企业规划和建设自己的私有云。我们的客户主要集中在政府、教育、制造、流通等行业。我们的客户对于披露与自身相关的信息存在一定的顾虑，因此我们无法提供与客户或者项目相关的信息。

通常来讲，传统行业的私有云客户不仅仅是为了整合服务器资源而部署IaaS。他们在弹性负载均衡、自动横向扩展等等方面的需求超过一般人的想象。要满足这方面的需求，往往意味着需要对现有应用进行改造，或者是将应用部署在PaaS之上。前面我们已经说过，不同的客户对IaaS有不同的期望值，部署IaaS之后的使用情况也不尽相同。

（5）如何看待IaaS领域开源与闭源多种解决方案群雄并起的局面？

竞争促进创新，多家厂商之间的竞争必然会给用户带来实惠，譬如更低的价格和更好的功能。目前云计算市场依然在持续发展之中，远远还没有达到成熟的程度。可以预见，未来这个领域的竞争还有越来越激烈。

关于闭源技术与开源技术之间的竞争，我在去年10月的博客文章《虚拟化、云计算、开放源代码及其他》中曾经有过专门的论述。我们今天所处的商业环境，与上个世纪80年代自由软件运动（Free Software Movement）刚刚兴起的时候已经有了很大不同。自1998年NetScape第一次提出开放源代码（Open Source）这个术语起，开放源代码就已经成为一种新的软件研发、推广与销售模式，而不是与商业软件相对立的替代品了。开放源代码作为一种新的商业模式，并不比传统的闭源模式具有更高的道德水准。同样，在解决工程问题的时候，客户所看重的往往是解决方案的性价比而不是道德水准。

关于开源项目的盈利问题，Marten Mickos（Eucalyptus的CEO）在担任MySQL公司CEO期间曾指出：“如果要在开源软件上取得成功，那么你需要服务于：（A）愿意花费时间来省钱的人；和（B）愿意花钱来节约时间的人。”在中国的商业环境中，IT公司（或者说互联网公司）通常是愿意花费时间来省钱的，而非IT公司（或者说传统行业）通常是愿意花钱来节约时间的。需要指出的是，中国的非IT公司往往不在乎软件是否开源，但是非常注重开源软件的可定制性。

我基本上认同Ignacio M. LIorente的观点，就是不同的云管理平台适用于不同的客户需求以及不同的应用场景，并不存在一个能够通吃所有应用场景的云管理平台。出于同样的道理，Eucalyptus也有自己所擅长的应用场景，以及自己所不擅长的应用场景。作为Eucalyptus的员工，我自然希望各行各业的用户都使用Eucalyptus来搭建他们的私有云。但是为了能够充分发挥Eucalyptus的潜力，我建议所有潜在的客户首先了解一下Eucalyptus是什么（或者不是什么），Eucalyptus能做什么（或者不能做什么），以及应该如何规划、实施、使用基于Eucalyptus的私有云。

Eucalyptus是（不是）什么？

Eucalyptus是一个开放源代码的、与AWS高度兼容的云管理平台。以AWS为参考原型的各种云管理平台（例如OpenStack）都在某种程度上兼容AWS API，但是只有Eucalyptus将忠诚地兼容AWS API上升到企业战略与核心竞争力的层面。忠诚地兼容AWS API意味着客户能够在私有云环境中继续使用各种现有的与AWS API相兼容的工具、脚本和映像（AMI），能够在基于Eucalyptus的私有云和AWS公有云之间迁移负载和数据，或者是将基于Eucalyptus的私有云作为开发测试环境但是将AWS公有云作为生产环境。

根据Ignacio M. LIorente的云管理平台四象限图，VMWare vCloud和AWS分别代表了数据中心虚拟化和按需获取计算资源的两种典型的应用场景。以数据中心虚拟化为应用场景的云管理平台通常采取自下而上的架构设计，旨在解决数据中心的复杂度问题；以按需获取计算资源为应用场景的云管理平台通常采取自上而下的架构设计，旨在通过简单高效的接口提供计算资源。设计理念上的差异，决定了一个云管理平台很难同时具备VMWare vCloud和AWS的种种特性。Eucalyptus与AWS的高度兼容性决定了Eucalyptus不是VMWare vCloud或者VMWare vCenter的替代品。Eucalyptus和VMWare试图解决的是不同的问题，适用于不同的应用场景，因此具有不同的功能和特性。常常有用户将Eucalyptus和VMWare vCloud或者是VMWare vCenter进行功能或者特性对比。他们没有意识到Eucalyptus和VMWare vCloud或者是VMWare vCenter完全不是同一类型的软件，是没有办法直接进行功能或者特性对比的。

值得一提的是，Eucalyptus是一个开放源代码的产品，但是桉树公司并不为特定客户提供提供软件定制化服务。经常有一些潜在的客户问我们是否可以为其提供定制的版本。的确，作为一个开源项目的主要开发者，桉树公司具备为特定客户提供特定版本的能力，但是桉树公司通常不会这么做。为特定客户提供定制化版本意味着要对产品进行修改，也意味着使用定制版本的用户在升级到Eucalyptus后续版本时可能会遇到不可预知的风险。尽管在短期内定制化版本可能为客户解决了某些问题，但是从长期来看它所带来的问题要大于它所解决的问题。（Eucalyptus是一个开源项目，如果客户愿意并且具备相应的开发能力的话，当然也可以自己对Eucalyptus进行定制化。但是，用户自己对Eucalyptus进行定制化同样也会遇到升级的问题。）

Eucalyptus能（不能）做什么？

目前Eucalyptus的最新发行版本是3.2.1，它能够很好地用作开发测试环境，或者是用来支撑各种可扩展的Web服务。这两个应用场景的共同特点是大量地使用非持久性虚拟机实例（Ephemeral Instance），以及使用弹性块存储（EBS）来保存持久性数据。尽管Eucalyptus也支持从弹性块存储启动（Boot from EBS, BfEBS）的持久性虚拟机实例，但是由于架构设计方面的原因，在一个集群中存在大量BfEBS实例时整个集群的性能会有所下降。一个集群中BfEBS实例的数量越大，集群的性能恶化就越严重。因此，我们不建议客户在Eucalyptus上运行大量BfEBS实例。

Eucalyptus也不能很好地支持各种磁盘IO密集型应用，例如需要高速读写磁盘的数据库应用。严格地说，这不是Eucalyptus自身的问题，而是底层虚拟化技术的问题。目前各种虚拟化技术 － 例如VMWare ESX、Xen、KVM等等 － 已经较好地解决了CPU和内存的性能损失问题，但是在磁盘IO方面还是存在一定的性能损失。因此，我们不建议客户在虚拟机上运行各种磁盘IO密集型应用，包括负载较重的数据库应用。

在VMWare vCenter里面，系统管理员可以根据应用特征为应用定制网络参数。在Eucalyptus里面，如果系统管理员希望具备同样的能力，恐怕他很快就要失望了。为了以简单高效的途径提供计算资源，Eucalyptus尽可能自动化地管理整个私有云的网络配置，留给系统管理员自由发挥的空间不大。

Eucalyptus的硬件拓扑

接下来我们介绍几个典型的硬件拓扑结构，以帮助各位读者深入了解适合Eucalyptus的应用场景。在这些拓扑结构图中有一些缩写，含义如下：

CLC － 云控制器（Cloud Controller），Eucalyptus中的前端组件

Walrus － Eucalyptus中类似于Amazon S3的对象存储服务

CC － 集群控制器（Cluster Controller），管理一个Eucalyptus集群

SC － 存储控制器（Storage Controller），为一个Eucalyptus提供弹性块存储（EBS）服务

NC － 计算节点（Node Controller）

GE － 千兆网

10 GE － 万兆网

FC － 光纤通道

SAN － SAN存储

上面这个拓扑图展示的是一个只有一个计算集群的小型Euclayptus私有云。在这个私有云中，所有服务器都连接到一台千兆网交换机上，其中CLC和Walrus共同部署在同一台物理服务器上，CC和SC共同部署在同一台物理服务器上，SAN存储通过光纤通道连接到Walrus和SC服务器。如果为了进一步降低成本，SAN存储设备也可以替换成DAS存储设备。

在这样一种拓扑结构下，Eucalyptus使用开源的iSCSI TGT驱动提供EBS服务。大量的实践表明，开源的iSCSI TGT驱动存在稳定性问题，在存储压力比较大的情况下会莫名其妙的崩溃掉。（这个问题不仅仅在Eucalyptus中存在，在所有使用开源的iSCSI TGT驱动的应用中都会发生。）EBS服务存在稳定性问题，意味着处于运行状态的虚拟机可能会突然访问不到挂载的弹性块存储设备，也意味着从弹性块存储启动的BfEBS实例会突然崩溃。这样的拓扑结构部署在对数据持久性要求不高的开发测试环境中的问题不是很大，但是我们不建议客户在对数据持久性要求较高的生产环境中使用。

除了EBS的稳定性问题之外，这个拓扑结构的瓶颈在于SC与整个计算集群之间的连接是一个千兆网。整个计算集群访问EBS服务的吞吐量受到千兆网带宽的限制，有效吞吐量大概在100 MB/s左右。假设每个EBS实例所造成的平均压力为2 MB/s，一个计算集群能够同时支持40到50个EBS实例。假设每个EBS实例所造成的平均压力为4 MB/s，一个计算集群只能够同时支持20到25个EBS实例。需要指出的是，4 MB/s相当于一个质量中等的U盘（USB 2.0）的吞吐能力，其性能远远不及老式笔记本电脑中常用的7200转SATA硬盘，而2 MB/s更是一个性能非常低下的极端情况了。如果客户希望在这样一种拓扑结构下大量使用EBS服务，建议将SC通过万兆网连接到交换机。（现在很多接入交换机都带2～4个万兆接口了，这样的改造成本不大。）经过这个简单改造之后，EBS服务的有效吞吐量一下子增长了10倍，基本可以消除由于带宽限制所带来的性能瓶颈。

在生产环境中，我们建议客户使用基于IP SAN的存储设备来提供EBS服务。上面这个拓扑图展示的是一个可用于生产环境的Euclayptus私有云。在这个私有云中，所有Eucalyptus前端组件（CLC、Walrus、CC、SC）都部署到独立的物理服务器上，所有可能有大流量的组件（IP SAN、Walrus、CC、SC）都通过万兆网连接到私有云。目前Eucalyptus支持EMC、EqualLogic、NetApp等多个厂商的IP SAN设备，在这种拓扑结构下Eucalyptus使用官方支持的iSCSI驱动EBS服务，其稳定性和可靠性与开源的iSCSI TGT相比都有大幅度的提高。

即使如此，我们依然不建议客户在Eucalyptus上运行大量从弹性块存储启动的BfEBS实例。Eucalyptus的设计初衷是鼓励用户尽可能多地使用非持久性虚拟机实例，在这种情况下虚拟机磁盘映像被存储在计算节点上，虚拟机内部的磁盘IO不会对私有云的网络造成压力，运行在不同计算节点上的虚拟机基本上不会互相影响。由于从弹性块存储启动的虚拟机实例是持久性实例，需要频繁地与存储设备进行交互，对网络带宽的压力是很大的。因此，我们对客户的一般性建议是：（1）尽可能使用非持久性虚拟机实例；（2）在必须使用BfEBS实例的情况下，尽可能将操作系统盘做得比较小，例如10 GB；（3）将操作系统盘与数据存储盘分离，也就是首先启动一个尺寸较小的BfEBS实例，然后挂载一个尺寸较大的EBS卷用于存储持久性数据。

上面这个拓扑结构可以进一步加以改造，将存储网与业务网分离。这样存储流量就不会对业务流量造成影响，对私有云各个组件的健康监控也可以在存储网上进行。

当一个计算集群的容量达到极限的时候，可以往私有云中增加新的计算集群进行扩容，就形成了上面这个拓扑结构。

Eucalyptus的使用建议

前面我们已经说过，不同的云管理平台有不同的设计理念，适用于不同的应用场景。有些潜在的客户认为只要投资买了X硬件按照Y拓扑安装好Z软件就可以应付一切类型的应用，这种期望基本上是不切实际的。类似于AWS的云计算更多地是一种新的管理和分配计算资源的理念，而不是一种新的技术。使用类似于AWS的云计算服务要求用户了解一些基本的概念，并且通常需要对应用做一些修改才能够达到最佳的效果。我们给Eucalyptus客户提供的一般性建议包括：

（1）尽可能使用非持久性虚拟机实例；

（2）当必须使用BfEBS实例时，尽可能缩小磁盘映像的尺寸；

（3）使用EBS卷保存持久性数据，并且将操作系统盘和数据存储盘分离；

（4）不要在虚拟机上运行磁盘IO密集型应用；

（5）不要对虚拟机进行纵向扩展，要通过横向扩展提高应用的处理能力；

（6）通过负载均衡实现应用的高可用性；

（7）避免虚拟机级别的在线迁移，当物理服务器需要进行维护时，使用Eucalyptus的维护模式。

如上图所示，我们建议用户将同一个应用部署到多个计算集群上。

当一个计算集群发生失效的时候，应用依然是可用的，但是其处理能力降低了。

对于有计划的系统维护，可以先将应用的负载迁移到不需要进行维护的计算集群上，然后对处于空闲状态的计算集群进行维护。这样既保证了应用的可用性，又保证了应用的处理能力。

需要说明的是，上面我们所提到的“负载迁移”并不是指将一个处于运行状态的虚拟机从一个计算集群动态迁移到另外一个计算集群，而是在另外一个计算集群中基于同样的EMI创建一个新的虚拟机实例，并通过负载均衡设置将应用的负载重定向到新的虚拟机实例。到目前为止，Eucalyptus并不提供VM级别的动态迁移（类似于VMWare vMotion）的功能。对于类似于AWS的云服务来说，最终用户与底层的基础设施是通过多个层次的抽象措施彻底隔离的。对于最终用户来说，他所看到的计算资源只有自己的虚拟机。至于他的虚拟机运行在什么样的物理服务器上以及该服务器上的负载情况，最终用户应该是一无所知的。因此，提供虚拟机级别的在线迁移功能，其实质是违反了通过抽象措施将最终用户与基础设施进行隔离的原则。

在Eucalyptus 3.3中即将提供一个称为维护模式的功能，允许系统管理员将某个计算集群中的特定物理服务器标志为维护状态。这时系统就会自动地将指定物理服务器上的所有虚拟机实例迁移到同一计算集群中的其他物理服务器上。这个功能允许系统管理员对计算集群中的特定物理服务器进行维护，同时又不必清空该计算集群中的所有负载。

当应用的负载上升时，通过横向扩展提升应用的处理能力。

在Eucalyptus 3.3中即将提供的实例监控（Monitoring）、弹性负载均衡（Elastic Load Balancing，ELB）、自动扩展（Auto Scaling，AS）功能，会使得应用的横向扩展更加容易。简单地说，实例监控功能允许用户对自己的虚拟机实例进行监控，监控对象包括虚拟机实例的CPU、内存、磁盘IO、网络IO等等；自动扩展功能允许用户设定一些简单的触发参数，并在监控参数达到触发参数要求的时候自动地创建或者是销毁虚拟机实例；弹性负载均衡功能则负责修改与应用相关的负载均衡策略，自动地添加新创建的虚拟机实例或者是移除旧的虚拟机实例。

综上所述，可以得到我们向客户所建议的一般性的应用架构设计。可以看出，这个架构设计与我们所熟悉的Web应用架构基本上是一致的。一个典型的Web应用，可能仅仅需要进行少量的改动（如果应用在设计之初就充分考虑到横向扩展的话，甚至是完全不需要改动），就可以充分利用Eucalyptus私有云的种种特性。

除此之外，在弹性块存储EBS服务的使用方面，建议各位感兴趣的用户读一读Why EBS was a bad idea这篇文章。尽管我并非完全同意文章中的观点，但是作者的许多观察和思考是值得云管理员和应用开发者深入思考的。

Eucalyptus的容量规划

现在各位读者已经大致了解了Eucalyptus是（不是）什么，能（不能）做什么，以及应该如何使用基于Eucalyptus的私有云。如果您觉得上面这些描述与您的应用场景相符合，并希望使用Eucalyptus来搭建您的私有云的话，我们建议您在动手之前做一些简单的容量规划。容量规划的基本方法，是将可预见的负载与物理资源进行映射，以确保私有云的容量能够承载应用和业务所带来的压力。一般来说，需要进行考察的参数包括CPU（物理核心数量）、内存、网络（吞吐量）、存储（吞吐量和IOPS）。

对于CPU和内存来说，可以通过标准化的VM产品类型（VM Types）进行简单的换算，其结果可以表达为特定的硬件设备可以支撑多少个某个类型的虚拟机实例。

对于网络来说，往往需要对即将运行在私有云上的应用的网络行为进行采样，获取其真实的流量特征，并在此基础上与私有云的网络配置进行对比。

对于存储来说，一个集群的容量往往受限于IOPS而不是吞吐量。上个月Eucalyptus公司的联合创始人之一Graziano Obertelli写了一篇题为Will My Internet Be Faster的博客文章，用较长的篇幅讨论了如何基于IOPS进行容量规划的问题。我将Graziano Obertelli的博客文章翻译为《我的网络会变得更快吗？》，可供参考。

服务等级协议

经常有客户问我们：“用了Eucalyptus之后，是不是就可以保证我的云主机不会宕机了呢？”坦率地说，不仅Eucalyptus不能，其他的云管理平台也不能。

宕机时间，或者说不宕机时间，是数据中心领域的一个奇妙参数，通常被称为服务等级协议（Service Level Agreement，SLA）。服务等级协议是服务合同的一部分，通常用年度不宕机时间百分比（Annual Uptime Percentage）来表示。很显然，根据年度不宕机时间百分比，可以计算出一年内允许宕机的总时间。常见的SLA条款包括99%（一年可以宕机3.65天，也就是87.6小时），99.9%（一年可以宕机8.8小时），99.99%（一年可以宕机53分钟）。Linode的SLA条款为99.9％（一年可以宕机8.8小时），AWS的SLA条款为99.95％（一年可以宕机4.4小时），阿里云的SLA条款为99.9%（一年可以宕机8.8小时），而盛大云则没有任何关于SLA的承诺。通常来说，更高的SLA条款意味这更高的硬件、软件和人力资源投入。到目前为止，尚未出现能够保障100% SLA条款的产品和技术。

其他

成功地运用云计算，需要硬件与拓扑、软件架构、应用场景、容量规划、服务等级协议等等多个方面的准备。我们在前面已经说过，类似于AWS的云计算更多地是一种新的管理和分配计算资源的理念，而不是一种新的技术。使用类似于AWS的云计算服务要求用户了解一些基本的概念，并且通常需要对应用做一些修改才能够达到最佳的效果。成功的云计算要求服务提供商和服务使用者都要为云计算做好准备。如果你只是想延用老的方式来使用云计算，基本上很难获得成功。