一种基于Xen的云基础设施管理平台构建方法

宋 勇，蔡志平

(1.湖南民族职业学院，湖南岳阳 414000；2.国防科技大学计算机学院，湖南长沙 410073)

1 研究背景

伴随着以智能化制造为主要特征的工业4.0时代来临，历经近十年高速发展的云计算技术正在全球范围内掀起大数据应用的浪潮[1]。作为云计算的技术基石，虚拟化技术不断丰富着云计算的内涵，并衍生出多样化的架构和理念。由于云计算本质上是一种基于基础设施共享的租赁服务，用户通过按需付费的形式，获取高效的云计算服务，因此，基础设施即服务(IAAS)被业界公认为最具发展前景的云计算服务[2]。

OpenStack是一款应用广泛的IAAS开源管理工具[3]，其核心代码由NASA和Rackspace共同捐献，支持市面主流虚拟机平台的管理，如VMWare、Xen、KVM等。距2010年7月OpenStack发布第一个版本Austin到今天，已经有6年多的时间，伴随它蓬勃发展的同时，也暴露了诸多亟待解决的问题，例如：OpenStack尚缺少完善的多租户理念，权限和角色模型还不成熟,缺少可信验证等安全业务功能等。

针对上述存在的问题，本文从软件架构的角度对OpenStack内部组件特性和管理平台实现进行了分析与探索，利用XenServer提供的大规模、成熟的API免费接口搭建多“租户”的、可审计、安全可信的虚拟化云计算平台，并在此虚拟化环境中通过部署多节点的OpenStack服务器来构建IAAS管理平台，并以IOZONE进行了云服务实际性能的测试。本文的研究工作可为虚拟化环境下IAAS平台的构建和研究提供有益借鉴。

2 基于Xen的云计算平台构建

2.1 XenServer的API

当前，虚拟化平台产品的竞争主要集中在VMWare、Windows Server Hyper-V和Citrix XenServer之间[4]。其中，XenServer的免费版本对开发者提供了免费的API接口，开发者可以通过调用API开放接口来实现云计算中资源动态调整、弹性计算、高可用、应用的快速部署等高级功能[5]。

2.2 XenServer CPU池的异构管理

在实际的配置过程中，由于Resource Pool的配置通常存在不同的时序，服务器主机之间的CPU易形成异构关系[6]，需要对各主机的CPU进行异构管理，其基本配置过程如下：①确认主机的CPU类型，并通过xe host-cpu-info命令获取各主机的CPU Feature值；②将上一步骤中获取的CPU Feature 值逐一进行AND运算操作，获取下一运算环节中所需的Common Mask值；③逐一对所有的XenServer Host使用命令xe host-set-cpu-features features=*(*是Common Mask值)设置好CPU Feature的Common Mask值，重启主机后生效；④最后将已经修改好CPU Feature的XenServer Host加入到同一个Pool池中。

当XenServer Host退出Resource Pool后，许可服务器的注册信息会随着本地存储格式化而被清空，因此，异构管理需要重新注册上述信息。

2.3 平台安全性设计

为了确保云平台的可信性，需对开源XenSever进行可信化设计，其中一个主要的手段便是引入虚拟机监视器机制，将其内核精简为可信域，作为云平台运行的安全支撑基础。在此基础上，再定义一个用于系统可信服务管理的安全域，为高可信级别的用户、服务和应用提供运行规则，同时创建多个计算节点虚拟机实例域，为普通用户、服务和应用提供运行规则。对于上述域，制定如下运行规则：(i)安全域与可信域之间仅支持单向通信，即只允许可信域读取安全域写到计算节点虚拟机实例中某个固定区域的数据，反之则不行；(ii)计算节点虚拟机实例域中，应用程序通过标准的系统调用接口请求系统的内核服务，并通过可信域中的虚拟化引擎访问系统资源。可信服务运行规则的流程如图1所示。

图1 平台可信性运行规则流程图

图1中，应用程序通过定制的API接口请求计算节点虚拟机实例域中系统的内核服务，经过验证后，系统内核发现是可信服务的系统调用，便按照运行规则(ii)将该请求转发给可信域；可信域按照运行规则(i)将该定制的请求单向发给系统安全域的定制安全内核，经过验证后，定制安全内核通知可信服务，并存储在计算节点虚拟机实例域中指定位置，等待计算节点虚拟机实例域中的应用程序读取。

为了证明上述设计的安全性，需要从两方面的威胁来评估：一方面源自系统安全域的攻击；另一方面源自计算节点虚拟机实例域的攻击。在证明前首先进行下述定义：

sys表示系统，vss表示安全域，vcs表示计算节点虚拟机实例域，vsm表示虚拟机监视器，P(T)代表程序T可能造成破坏的概率。

本系统被攻破的概率是源自系统安全域攻击与计算节点虚拟机实例域攻击所造成的破坏概率之和，记为：

P(T)=P(Tvss)+P(Tvcs).

(1)

其中，P(Tvss)是源自安全域攻击可能造成破坏的概率，可以表示为：

(2)

其中，Pott(t1)指包含其它威胁的代码可能破坏的概率。

在(1)式中，P(Tvcs)是指源自计算节点虚拟机实例域攻击可能造成破坏的概率，可以表示为：

(3)

传统的虚拟机系统，被破坏的概率P′(T)主要由包含威胁的代码Tm与包含BUG的代码Ts所造成破坏的概率构成，可以表示为：

(4)

由于虚拟机监视器的源代码数量远远小于传统虚拟机系统的源代码数量，因此下述公式成立。

(5)

由(5)式可以得出，本平台的系统安全性优于传统的虚拟机平台。

3 OpenStack多节点部署

OpenStack主要部署形式可以划分为控制型和计算型两种类型，控制型节点运行nova-network组件，计算型节点运行nova-compute组件[7]。典型的OpenStack分布式多节点部署方式如图2所示。

图2 多节点IAAS平台拓扑图

图2中控制节点运行了包括nova-api、nova-network、keystone、nova-scheduler等多个组件，用于管理计算型节点。计算型节点与hypervisor交互，负责管理虚拟机实例的状态及其他用户元数据和参数。图2中还包括GlanceISO镜像库和数据库(MySQL)节点。本文采用OpenStack官网推荐的All-in-ONE配置模式，进行多节点的部署。该模式将所有组件都配置运行在一台物理机上，通过FlatDHCP方式动态分配各虚拟机实例的IP地址，如图3所示。

在实际的配置过程中，通常将内部的组件运行在不同的虚拟机实例中，如图4所示。图中domain0是物理机安装XenServer后自动产生的高权限虚拟机，可直接同虚拟化层的hypervisor交互。通过Xencenter客户端可以在XenServer上管理虚拟机实例，但是对物理机高权限的配置则需要使用xe命令行工具。由于仅需要一台物理机，因此只用一块物理网卡eth0即可，eth0用于外部通信。

图4 基于XenServer的All-in-ONE多节点配置模式

在XenServer上部署OpenStack之前，需要创建一个VLAN网络，专门用于类似图2中各虚拟机实例的交互，为避免混淆，需要区分此处提到的虚拟机是指计算节点生成的虚拟机，而在All-in-ONE配置模式中，是指XenServer上虚拟机中的虚拟机，后者仅出现在开发、测试、调试的场景中，在真实的生产环境下是不会出现的。

安装配置好nova-controller-node，控制节点会启动nova-api、nova-network、nova-scheduler、glance-api、glance-registry等服务，其中nova相关服务会注册到数据库的service表中。nova客户端用户通过命令行“nova-manage service list”可查看当前nova服务的状态。类似地，安装配置好nova-compute-node，计算节点会启动nova-compute服务，同时根据配置文件中的nova-url通知nova-controller-node，并注册到数据库的compute_nodes表中。所有部署成功之后，可以通过命令行或Harizon操作OpenStack云平台，其基本的操作流程描述如下：①创建租户和租户内的用户，并赋予管理员admin权限；②用户上传虚拟机镜像image；③启动image创建虚拟机实例；④向虚拟机实例注入元数据。

4 性能测试

测试采用的工具软件是IOZONE3.0。测试分两个阶段进行，每个阶段各针对一种典型的云计算应用场景进行性能测试。

4.1 容错性能测试

图5 测试拓扑图

用于测试的环境包括1个标准机柜，装配有4台机架式服务器，其中2台是OpenStack管理服务器，3台是存储服务器，采用N+1冗余方式进行数据保护。用作计算服务节点的塔式服务器有6台，各服务器的操作系统均为Red Hat Enterprise Linux5(64bits)，另外，用户可以根据需要增设认证服务器。OpenStack管理服务器组成1个Pool，以Pool连接到存储节点的1个卷中。WS-C2960S交换机用于OpenStack和XenServer的通信，同时也是管理存储的网络设备，以便OpenStack能够控制XenServer工作。测试虚拟机实例由OpenStack创建，用户设定虚拟机模板，然后分别在scheduler、networking、spawning和active阶段，nova控制模块完成寻找计算节点、分配固定IP、启动虚拟机、注入用户元数据等动作，在active状态下，代表虚拟机成功创建并启动。测试环境的拓扑结构如图5所示。

给上述设备加电，待系统自检和初始化完成后，存储节点设备挂载妥当，输出标准的NFS服务。此时随机关闭云平台中任一台存储节点电源，验证系统的数据是否完整，文件系统是否能够正常访问。参与测试的每个节点有一个静态IP，每个静态IP会对应若干FlatDHCP IP，这些FlatDHCP IP用于客户端的IP地址分配，当某个节点的电源被关闭后，FlatDHCP IP会自动捆绑到其他节点，NFS服务并没有中断，当前业务仍然保持连接，无需重新连接。为确保平台的容错能力，实验中需要调整计算节点的数量，来对比IOZONE聚合带宽的波动，相关的测试参数如下：IOZONE-Recb rec.xls-t 3-r 16K-s 8G-i 0-+m./nodelist.natp-C。

随机关闭节点电源后，测试结果显示，IOZON测试时指定的临时文件呈现持续增大趋势，该节点上的FlatDHCP IP随机转移，重新将掉电节点加电后，IOZONE的操作没有受到任何影响，数据完整，文件系统可以正常访问，并且FlatDHCP IP通过平衡后又转移回当前节点。测试完成后获得的IOZONE聚合带宽数据如表1所示。

表1 IOZONE聚合带宽数据

从表1可以看出，不同计算节点带来的影响是IOZONE的聚合带宽受到影响，这是由于容错操作的后台恢复工作需要占用较多的CPU资源而导致的。需要指出的是，此处数据容错测试性是针对节点的，而不是磁盘级别，即在N+1的容错模式下，一个存储节点中只要有1块硬盘没有出现问题，即使其它N块硬盘出现了问题，也可以保证数据不丢失。这表明基于Xen的OpenStack多节点部署IAAS云平台具有非常健壮的容错性，可以为应用层提供良好的数据容错服务。

4.2 读写性能测试

读写性能测试采用随机基准测试模式，基准测试参数包括读写两类，用于测试的数据块包括0.5KB、4KB、16KB和32KB四个类型，初始并发数为500线程，测试频率为每基准测试1分钟。由于服务器cache的影响，如果测试文件太小，测试的结果将会极为优异。因此，为了规避测试数据的奇异值，获得接近真实应用场景的测试数据，测试时需要创建大于swap规模的分区并挂载，并关闭cache，同时在压力测试工具Tsung逐步加大存储节点压力的情况下，使用IOZONE按照以下两种测试顺序获取基准文件读写参数：①顺序存储、100%读；②50%顺序、50%随机存储、50%读、50%写。两轮测试结果如表2和表3所示。

表2 顺序存储和100%读的测试参数

表3 50%顺序、50%随机存储和50%读、50%写的测试参数

以上两种顺序的测试结果表明，节点越多在带宽利用率、平均I/O响应时间和IOPS指标上的提升越明显。另外，相对于较小的数据块，数据块越大，IOPS指标提升越明显，最大增幅超过300%。但是与NFS存储提供的带宽相比较，带宽利用率仍然较低，潜在提升空间较大，建议在预算充裕的前提下，适当增加分布式节点的数量，充分利用存储带宽，为云平台的应用层提供更好的基础设施支撑。

图6 IOPS测试结果

接下来在所有主机上创建50个左右的虚拟机实例，留一台挂载在存储不同卷中的虚拟机实例暂时闲置，其余使用dd命令进行高强度的写操作：

#dd if=/dev/zero of=/tmp/file.imgbs=1M count=99999999

然后用webbench增加测试压力，用高并发流量访问空闲虚拟机的某个大于swap的大文件，测试结果如图6所示。

从图6可以看出，在压力流量较小的情况下，存储的I/O性能达到了一个比较好的峰值，在增加的流量达到总吞吐量80%的时候，即341.2MB/s时，IOPS平均值为6000，未出现明显衰减，处在一个相对稳定的状态，IOPS的性能测试达到了预期目标。

5 结语

未来最有发展前景的云计算服务模式是基础设施即服务(IAAS)[8]。简单、冗余、可扩展的架构设计保证了OpenStack用于IAAS基础管理服务的优越性。本文在研究了OpenStack及其基础云平台XenServer的特征和相关开源技术的基础上，针对基于Xen技术的OpenStack IAAS平台进行了基础云平台构建实现、CPU池异构管理、可信安全服务设计以及多节点部署等研究工作。文件基准读写性能的测试数据显示，在继承了开源Xen和OpenStack优势的同时，本文研究构建的IAAS平台能够有效提高云平台的安全性，并且具有良好的容错能力和稳定的并发读写能力。在云计算蓬勃开展的形势下，随着Xen开源社区和OpenStack的不断完善，基于Xen技术的OpenStack云基础设施管理平台将得到更广泛的应用。