基于REST架构风格的云物理服务器部署机制

陈 衡，董小社

（西安交通大学计算机科学与技术系 西安 710049）

1 引言

云计算的概念在20世纪90年代被首次提出，但云计算开始受到产业界和学术界的重视，并逐渐被各行各业所接受是在 2005年 IT产业界的巨头 Amazon、Google、IBM和微软分别推出了各自的云计算产品之后。全球云计算市场快速平稳增长，2013年全球云计算服务市场约为1317亿美元，年增长率为18%，据预测，未来几年仍将保持15%以上的增长率[1]。使用公用云计算服务，企业或科研机构不需要一次性购买大量的软硬件基础设施，也不需要配备专门的服务器维护人员，而是通过按月付费的方式支付服务费，大幅度地节省了投入成本，并且能够根据业务的需要随时增减订购的云计算服务，从而使用户可以更加关注自己的主要业务，而不是基础设施的建设和维护。

用户根据各个应用的特点和需求租用一定数量的云主机，完成应用的安装部署。虽然用户不知道租用的云主机的具体位置，但可以通过基于浏览器的用户管理面板实现对云主机的完全控制，例如开机、关机、重新启动、重新安装操作系统等，如同使用用户自己购买搭建的物理服务器一样方便易用。这种使用模式可以满足绝大多数用户的应用需求，但是还有相当数量的应用无法在云主机上正常运行，典型的应用有:高性能计算、需要直接访问不可虚拟化的计算机硬件的应用、在云主机上运行效率非常低的数据库应用、在多个服务器上快速部署另一种云计算平台等[2]。云计算服务提供商若要满足以上应用的需求，则需要向这类用户提供一定数量的物理服务器，并允许用户像使用云主机那样对这些云物理服务器拥有完全控制权。从用户角度看，云物理服务器应具有以下特性:

·远程电源管理，云物理服务器可以基于网络实现物理开机、关机和重新启动；

·基于网络的操作系统和软件的自动安装，可以安装常用的操作系统的不同发行版本，也可以使用用户自定义的镜像系统进行安装；

·云物理服务器和云主机有相似的管理中心控制面板。

2 服务器管理

在介绍用户如何通过基于浏览器的用户管理面板对云物理服务器实施管理前，有必要介绍一下数据中心的管理员是如何对服务器进行管理的，这里仅介绍操作系统的安装方法。按照技术发展的时间顺序，服务器操作系统的安装方法可以分为两大类，具体介绍如下。

（1）光盘安装

系统光盘获取通常有两种方法:服务器自带和刻录从官网下载的安装光盘镜像。管理员将服务器设置为从光盘启动，在将安装光盘放入服务器光驱后，重新启动服务器，按照屏幕提示，完成操作系统的安装。这种安装方式最为简单、直接，但由于需要管理员手动安装，当服务器的数量稍多时，安装工作量就变得很大。

（2）网络安装

管理员分别配置DHCP、TFTP、HTTP服务器以及自动安装脚本，并将需要安装的服务器设置为网络启动。服务器启动后，首先从DHCP服务器获得TFTP服务器和自己的IP地址，然后从TFTP服务器获取内核启动程序和配置文件，最后根据配置文件内容从HTTP服务器下载相应的软件包完成系统安装。采用网络安装方式的效率很高，在无人值守的模式下，可以同时安装上百台服务器，但是这种安装方式对系统管理员的水平要求较高，并且还需在操作系统安装前和安装后分别进入BIOS，对服务器的启动模式进行设置。

为了进一步提高服务器操作系统安装的效率，简化安装前对DHCP、TFTP、HTTP等服务器的配置，同时降低对系统管理员的水平要求，在开源软件领域出现了若干款优秀的操作系统自动化安装管理工具，其中以Cobbler[3]最为简单、易用，因此本文选择Cobbler作为云物理服务器部署的核心工具软件。相对于传统的网络安装方式，Cobbler的特点如下:

·提供云物理服务器的启动模式支持，只需在BIOS中将云物理服务器的启动模式设置为网络启动优先，之后Cobbler可以根据用户指令控制服务器在网络启动和本地启动之间进行正确的选择；

·提供服务器远程电源管理支持；

·支持常见的 Linux发行版本，如 Redhat、Centos、Fedora、Suse、Debian 等；

·支持命令行和Web界面管理，同时还提供了API，方便二次开发。

系统管理员通过Cobbler对物理服务器进行安装的典型网络拓扑如图1所示。对于待安装的服务器，系统管理员首先要设置其电源管理，包括IP地址、用户名和密码等。接下来，系统管理员通过命令行或Web界面在Cobbler服务器上对distro对象、profile对象、system对象等进行配置。简单的说，distro对象对应的是Linux发行版本，profile对象对应的是如何安装某个distro对象或发行版本，system对象对应的是待安装服务器，主要包括电源管理、网络设置（两块网卡）以及采用哪个profile对象安装操作系统。然后，系统管理员通过命令行或Web界面使待安装服务器基于网络启动模式重新启动。待安装服务器重启后，与Cobbler服务器上的DHCP、TFTP、HTTP服务进行交互，最终完成操作系统的安装。

图1 Cobbler典型网络拓扑

3 基于REST架构风格的云物理服务器部署机制设计

虽然Cobbler同时提供了命令行接口和Web界面，但是无法直接将Cobbler的Web界面集成到云主机用户管理面板，为了使云物理服务器和云主机拥有相似的用户管理面板，需要对Cobbler服务器进行二次开发，并提供可供Web服务器调用的API。目前有3种主流的Web服务实现方案，分别是 XML-RPC（remote procedure call，远程过程调用）协议、SOAP（simple object access protocol，简单对象访问协议）和 REST（representational state transfer，表征状态转移）。由于XML-RPC只能使用有限的数据类型种类和一些简单的数据结构，已逐渐被SOAP取代。参考文献[4～6]对SOAP和REST网络带宽使用率、时延以及处理时间做了详细的对比分析，分析结果表明REST的性能明显优于SOAP，因此，高效可伸缩的轻量级REST架构风格更加适用于Web服务实现。

REST架构风格是2000年Roy Fielding博士在他的博士论文[7]中首次提出的，描绘了开发基于互联网的分布式软件的松耦合架构。REST架构风格包含了两个重要概念:资源的定位和资源的操作。资源的定位可以通过HTTP实现，基于HTTP，资源的操作主要有创建、读取、更新和删除，这 4个操作对应的动作分别由 post、get、update和delete表示。正是由于REST架构将资源的定位和操作进行了分离，研究人员可以很容易实现可扩展、可移植以及松耦合的基于Web的分布式软件。参考文献[8]基于REST架构风格实现了符合Web 2.0标准的图书列表服务，参考文献[9]将REST的“资源”概念与空间信息“数据”共享结合起来，设计了基于REST的空间信息服务互操作规范。参考文献[10]将传感节点等嵌入式设备和感知数据看作资源，采用REST将异构系统模块组合，设计了一个基于REST架构风格的物联网服务平台。参考文献[11]通过REST接口实现了第三方软件和Clever平台的集成，用户可以通过第三方软件访问和使用Clever平台的各种资源。参考文献[12]对存储空间提供商DropBox、Box等提供的有限免费空间，使用开放的REST接口，将多个不同的有限空间整合为一个较大的网络存储空间，并将该空间与免费的私有云集成在一起。参考文献[13]利用REST架构风格为云计算的应用提供了访问关系型数据和NoSQL数据的统一REST接口，降低了云计算应用开发者访问不同数据类型接口的负担。

基于REST架构风格的云物理服务器部署的网络拓扑如图2所示，Web服务器和Cobbler服务器分别位于不同的服务器上，其中REST客户端和Web服务器安装在一台服务器上，REST服务端、Cobbler服务封装和Cobbler服务器安装在另外一台服务器上。该架构的工作流程大致是用户通过基于浏览器的用户管理面板发送对某个云物理服务器进行操作的指令，Web服务器在收到用户的请求后，调用 REST客户端对应的 API，该 API通过 HTTP访问REST服务端，REST服务端根据HTTP指向的对象以及相应的动作调用Cobbler服务封装，Cobbler服务封装直接调用Cobbler提供的API或命令行完成用户指定的操作。具体的实现可以分为3部分:用户浏览器和Web服务器之间采用AJAX技术；REST客户端和REST服务端基于REST架构风格；Cobbler服务封装对Cobbler服务器提供的API和命令行进行了二次开发。

图2 基于REST架构风格的云物理服务器部署网络拓扑示意

3.1 REST客户端和服务端的设计

REST客户端和服务端的设计架构如图3所示。REST客户端由API模块和REST构造模块两部分构成，Web应用通过对这些API的调用实现对Cobbler服务器的操作和管理。REST构造模块将各种API调用请求构造为符合REST架构风格的资源表示和操作，相应的位于REST服务端中的REST解析模块将各种资源表示和操作解析为特定的API，并调用位于Cobbler服务封装模块中相应的API。在对Cobbler服务器进行深入研究和分析后，REST客户端和服务端至少应该实现以下功能。

·Cobbler服务器的核心对象 distro、profile、system和kickstart脚本等的管理，包括增加、删除、更新、列表和读取操作，相应的API分别由distro对象管理、profile对象管理、system对象管理和 kickstart脚本管理模块提供。

·电源管理，包括云物理服务器的开机、关机、重新启动，其中重新启动操作需要区分网络启动和本地启动，相应的API由服务器电源管理模块提供。

·服务器运行状态监测，与电源管理中的开机、关机和重新启动操作相对应，需要提供各个操作执行后服务器的实时状态，相应的API由服务器状态监控模块提供。

图3 REST客户端和服务端设计架构

REST客户端中4个核心对象管理的API见表1。以list_为前缀的API列出系统中已经存在的所有实例对象的名字。以get_为前缀的API以一个实例对象的名字为参数，返回该实例的详细数据。以add_为前缀的API以一个JSON数据结构为参数，将参数中指定的实例对象添加到Cobbler服务器中。以remove_为前缀的API以一个实例对象的名字为参数，从Cobbler服务器中删除该实例对象。以update_为前缀的API以一个JSON数据结构为参数，用参数中指定的实例对象的新数据内容对该实例对象进行更新。

表1 核心对象的管理API

服务器电源管理的API分别是power_on、power_off和power_reboot，这3个API都以要操作的云物理服务器的编号（system对象的实例名字）为参数，分别表示对该物理服务器进行开机、关机和重新启动操作，其中重新启动API还需要提供第二个参数，用来指明是网络启动还是本地启动。服务器运行状态监测的API为monitor_status，参数是云物理服务器的编号，返回结果包括两个数据:用户之前发送的电源管理指令和现在服务器的状态，详细情况见表2。

表2 云物理服务器电源管理状态

以上所有REST客户端API具有相似的实现，以get_distro为例，REST客户端API的伪代码实现如下所示。

第（3）行首先获得 Cobbler服务器的地址，第（5）行根据distro对象的实例名字name构造该distro对象的唯一资源标识，第（7）行使用HTTP的get操作获得该对象的详细数据，第（8）行将执行结果以JSON格式返回给用户。

当REST服务器端接收到来自REST客户端的请求后，根据用户HTTP请求中指定的资源对象，调用相应的功能模块进行处理。该功能模块的处理流程通常是首先获得用户对该资源对象要求的操作，然后从HTTP请求中读取从用户端以JSON格式传送的数据，最后调用Cobbler服务封装模块对应的功能接口，并以JSON格式返回执行结果。

3.2 Cobbler服务封装的设计

Cobbler服务器提供了3种人机交互方式，分别是命令行、API和Web界面，基于REST架构风格的Cobbler服务封装模块则是向Web服务器或第三方应用提供的另外一种操作方式，这种操作方式是在对Cobbler服务器进行二次开发的基础上实现的，同时也必须保证操作结果与Cobbler服务器提供的Web界面、API和命令行管理的一致性。图4给出了Cobbler服务封装模块的设计架构。

图4 Cobbler服务封装模块设计架构

从图4中可以看到，为了实现对Cobbler服务器的封装，Cobbler服务封装模块设计了两种封装模式，分别是基于API的封装和基于命令行的封装。基于API的封装直接调用Cobbler服务器提供的Python API，而基于命令行的封装则是模仿用户在终端命令行上的操作。提供两种截然不同的封装方式的原因是若直接调用Cobbler服务器提供的API所做的写操作，包括增加、删除和更新操作，通过Cobbler的Web界面或者命令行都不可见，会出现明显的不同步问题。查阅资料后，决定对于Cobbler服务器的只读操作采用基于API的封装模式，确保获得各种对象的详细信息，而对于Cobbler服务器的写操作，采用基于命令行的封装模式。

在接收到REST服务端的调用请求后，Cobbler服务封装模块首先会开启一个新进程，然后再在新进程中根据需要调用基于API封装或基于命令行封装的操作。在每次调用Cobbler服务封装模块都首先开启一个新进程是为了解决基于命令行封装的写操作和基于API的读操作的实时同步问题。具体表现为基于命令行封装操作向Cobbler服务器中增加的对象，通过基于API封装的读操作无法定位该对象，出现这个问题的原因是通过API调用看到的始终是REST服务端启动时Cobbler服务器的状态，而不是Cobbler服务器的实时状态。

为了解决基于命令行或API调用无法获得Cobbler服务器实时状态的问题，根据对问题的分析，在每一次基于命令行或API调用前，在Cobbler服务封装进程内再启动一个新的进程来执行该调用，调用完成后，关闭这个专门的调用进程。这个方案可以确保在基于命令行或API调用前获得Cobbler服务器的实时数据，从而完成Cobbler服务封装对Cobbler服务器的二次开发，实现基于REST架构风格的Web应用对Cobbler服务器的管理和操作。

与REST客户端提供的管理Cobbler服务器的核心API类似，Cobbler服务封装模块分别为这些API提供了具体的实现，具体是为Cobbler服务器的distro对象、profile对象、system对象和kickstart对象等提供了列表、读取、增加、删除、更新操作；为云物理服务器的电源管理提供了开机、关机、重新启动操作；同时也提供了服务器状态监测操作。鉴于这些操作具有相似的实现框架，下面以增加一个distro对象来说明Cobbler服务封装对Cobbler服务器的二次开发流程，伪代码实现如下。

伪代码的第（3）行检查参数URL指向的ISO镜像文件是否已经下载到本地，如果尚未下载，则在第（5）行调用wget工具从用户指定的URL进行下载。第 （6）行调用mount命令将本地的ISO镜像文件加载到mount_dir目录下，第（7）行将Cobbler服务器增加distro对象的命令行指令以数组形式表示，并将该数组以参数形式传递给第（9）行，再启动一个新进程执行Cobbler的命令行指令，第（10）行调用umount命令卸载第（6）行加载的ISO镜像文件。由于Cobbler在增加distro对象时会在用户指定的对象名称（参数name）后自动添加一个表示服务器体系结构的字符串，第（11）行通过查询Cobbler服务器的distro对象列表，获得新增加的distro对象的最终的名称，并将该名称在第（12）行返回给调用函数。第（7）～（9）行给出了如何基于Cobbler的命令行对Cobbler服务器进行操作，基于Cobbler的API调用具有类似的过程，首先通过调用BootAPI()获得Cobbler的句柄实例，然后根据操作的对象和动作调用相应的API，最后得到API调用的执行结果，需要特别说明的是基于API的调用也必须在新开启的进程中执行。

3.3 浏览器客户端设计

在对Cobbler服务器进行管理时，有一部分操作是比较费时的，如电源管理的开机、关机、重新启动，其中的网络重新启动由于涉及操作系统的重新安装，需要的时间则更长，另外使用用户指定的网络ISO镜像向Cobbler系统中增加distro对象也比较费时。用户对云物理服务器的管理是基于浏览器的管理面板，当用户发出了某个操作指令后，管理面板应该能及时向用户反馈当前操作的执行情况，尤其是对于哪些耗时较长的操作。为实现这个目标，在浏览器端采用了基于AJAX的异步数据传输技术，基本的原理是用户在管理面板上执行一个操作，然后用户的这个操作通过AJAX技术传递给Web服务器，由Web服务器上的应用完成用户指定的任务，而在浏览器端，当用户发出操作指令后，持续采用AJAX技术向Web服务器查询操作的进展情况，直至完成了用户的操作指令或出现错误，并将实时的任务完成进度反馈给用户。

基于HTTP的工作原理，为了能够获得用户任务执行的进展情况，需要将相关的操作和数据保存在Web服务器上的数据库中。以电源管理的重新启动为例，假设云物理服务器已正常启动，此时用户发出了重新启动的指令，那么用户希望在管理面板上看到服务器重新启动的情况，典型的状态为:正在关机、正在重新启动、重新启动完毕。为了获得云物理服务器的实时状态，Web服务器需要通过REST架构从Cobbler服务器上获得云物理服务器的状态，Cobbler服务器可以通过调用ping命令直接获得云物理服务器的状态:可连接和不可连接。

Web服务器根据用户的操作、云物理服务器之前的状态和实时的ping连接情况进行分析，可以得到云物理服务器的实时状态。仍以重新启动为例，图5给出了重新启动执行时云物理服务器的状态变迁示意，其中Y表示物理服务器可连接，N表示不可连接。在用户发出重新启动指令后，将重新启动的操作和服务器的状态“正在关机”写入数据库，然后基于REST架构获得该物理服务器的连接状态。如果是可连接，则该服务器仍然是“正在关机”的状态；如果是不可连接，则表明服务器已经完成了关机，该服务器的状态变成了“正在开始重新启动”，此时需要更新数据库中的服务器状态。在服务器状态变为 “正在重新启动”后，若通过REST架构获得的服务器的状态为 “不可连接”，表明服务器仍在进行重新启动，当连接状态变成“可连接”后，服务器完成了重新启动，这时需要将数据库状态更新为重新启动完毕。

图5 物理服务器重新启动的状态变迁示意

基于浏览器的用户管理面板在用户发出重新启动操作等指令后，通过对位于Web服务器上的数据库相关记录进行查询，将正在管理的云物理服务器的实时状态反馈给用户，采用这种方案后，用户对云物理服务器的操作需要根据数据库中的相关记录来决定，可以减少用户的误操作，并提高云物理服务器的工作效率。例如，用户发出了重新启动的指令，在指令未完成之前，用户再次向同一台服务器发出相同的指令，根据数据库中服务器的状态判断，可以直接忽略该指令，不影响服务器之前的重新启动过程，在用户的管理面板看到的服务器的实时状态仍然是第一次重新启动指令的执行情况。

3.4 测试验证

在完成了基于REST架构的云物理服务器部署机制的设计和实现后，按照图2所示的网络拓扑，对本文所实现的部署机制进行了测试，其中Web服务器一台，Cobbler服务器一台，云物理服务器8台。测试环境采用的服务器均为IBM iDataPlex dx 360 M2，具体配置参数见表3，其中服务器配置了2块网卡和一个IPMI，2块网卡分别用于内部网络和外部网络，IPMI主要用来实现远程电源管理。

在对云物理服务器进行部署前，首先要对这些物理服务器进行必要的配置，包括distro对象、profile对象、system对象和kickstart对象，在完成这些对象的配置后，可以开始对指定的云物理服务器进行操作。图6给出了云物理服务器核心对象配置的界面。

表3 测试服务器配置参数

图6 云物理服务器核心对象配置的界面

如图6所示，云物理服务器部署测试时使用的ISO镜像为CentOS 6.5和Ubuntu 13.04，分别测试了开机、关机、重新启动、网络重新启动，具体测试数据见表4。需要说明的是，表4中测试时间是通过ping命令根据服务器的可连接和不可连接状态得来的，由于测试时ping命令的时间间隔为6 s，所以各个测试结果与实际的执行时间存在最多6 s的误差。Cobbler服务器通过IPMI对云物理服务器进行电源管理，因此关机操作具有相同的时间，重新启动操作是由关机、1 s的时延和开机3个操作组合完成的，完成时间等于开机时间加上关机时间，而1 s的时延相对于6 s的误差而言，没有体现出来。网络重新启动需要重新安装操作系统，相对来说耗时非常长，主要原因是服务器的硬盘大小为3 TB，在安装时自动安装脚本的缺省配置是对整个硬盘重新分区并格式化，因此有将近70%的时间在格式化硬盘，仅有30%的时间用于操作系统安装，后期会对自动安装脚本的缺省配置进行适当修改，尽量避免不必要的重新格式化整个硬盘的时间。

表4 云物理服务器部署时间

最后对云物理服务器的并行部署进行了测试，在用户管理面板中同时选定8个服务器，发送网络重新启动指令，依据Cobbler服务封装ping命令的可连接状态判定，8个服务器同时进行了关机、开机和操作系统安装流程。

4 结束语

本文介绍了一种基于REST架构风格的云物理服务器部署机制，通过对Cobbler服务器进行二次开发，使用户可以通过基于浏览器的管理面板对云物理服务器进行管理和操作，满足了用户在云计算机环境下对物理服务器进行管理的需求，同时采用与云主机管理相似的管理面板和流程，简化了用户的学习曲线，使用户更加关注于自己的研究领域，提高了工作效率。接下来的研究内容是如何让用户通过管理面板对自动安装脚本进行管理，能够在操作系统安装完成后自动安装并配置用户指定的应用软件，从而真正实现云物理服务器的一键部署。

1 工业和信息化部电信研究院.云计算白皮书,2014 China Academy of Telecommunication Research of the Ministry of Industry and Information Technology.Cloud Computing White Paper,2014

2 Baremetal.https://wiki.openstack.org/wiki/Baremetal,2014

3 Cobbler.http://www.cobblerd.org,2014

4 Gavin M, Denis G. A comparison of soap and rest implementations of a service based interaction independence middle ware framework. Proceedings of the 2009 Winter Simulation Conference,Austin,TX,USA,2009:1423～1431

5 Snehal M,Puja P.Web services based on SOAP and REST principles.International Journal of Scientific and Research Publications,2013,3(5)

6 王姜，余萍，曹春等.开放网络环境下的程序设计:从RPC到REST.计算机工程与应用,2013,49(17):30～37 Wang J,Yu P,Cao C,et al.View of software design in open network environment:from RPC to REST.Computer Engineering and Applications,2013,49(17):30～37

7 Roy F.Architectural styles and the design of network-based software architectures (doctor dissertation). University of California,Irvine,2000

8 戴亚娥,俞成海,尧飘海等.基于REST架构风格的Web 2.0实现.计算机系统应用,2009,29(7)Dai Y E,Yu C H,Yao P H,et al.Implementation of Web 2.0 based on REST-style architecture. Computer Systems&Applications,2009,29(7)

9 李波,丁仙峰,伊文英等.基于REST的空间信息服务互操作协议的研究.计算机科学,2012,39(6A)Li B,Ding X F,Yi W Y,et al.Research on geospatial information service interoperability protocol based on REST.Computer Science,2012,39(6A)

10 程冬梅,瑞聪,刘燕等.基于REST架构风格的物联网服务平台研发.计算机工程与应用,2012,48(14)Cheng D M,Rui C,Liu Y,et al.Research and development of internet of things service platform based on REST style architecture.Computer Engineering and Applications,2012,48(14)

11 Antonio C,Francesco T,Massimo V,et al.Integration of clever clouds with third party software systems through a REST Web service interface.Proceedings of the 2012 IEEE Symposium on Computers and Communications (ISCC),Cappadocia,Turkey,2012:827～832

12 Raul G,Marc S A,Pedro G L.Cloud-as-a-gift:effectively exploiting personal cloud free accounts via REST API.Proceedings of the IEEE 6th International Conference on Cloud Computing,Santa Clara,CAL,USA,2013:621～628

13 Rami S,Sami B,Bruno D.ODBAPI:a unified REST API for relational and NoSQL data stores.Proceeding sof IEEE International Congress on Big Data,Anchorage,AK,USA,2014:653～660