《OpenStack实战指南》—— 1.9 OpenStack非核心项目介绍-阿里云开发者社区

开发者社区> 华章出版社> 正文
登录阅读全文

《OpenStack实战指南》—— 1.9 OpenStack非核心项目介绍

简介:

本节书摘来自华章出版社《OpenStack实战指南》一 书中的第1章,第1.9节,作者:黄 凯 毛伟杰 顾骏杰 ,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.9 OpenStack非核心项目介绍

1.9.1 Ironic项目介绍

Ironic为OpenStack的孵化项目之一,如果说OpenStack Nova管理的是虚拟机的生命周期,那么Ironic就是为了管理物理机的生命周期。它提供了一系列管理物理机的API接口,可以对“裸”操作系统的物理机进行管理,从物理机上架安装操作系统到物理机下架维修。我们可以像管理虚拟机一样地管理物理机,创建一个nova-compute物理节点不再需要人工部署,只需告诉Ironic,然后自动化地从镜像模板中加载操作系统到nova-compute安装完成即可。OpenStack管理虚拟机已经非常成熟,通过Nova我们可以快速自动化地创建虚拟机。但是在这之前需要搭建物理环境,需要人工地管理多台设备,OpenStack并没有提供物理环境的管理,我们依然需要解决这些基础环境的搭建问题,由此Ironic应运而生,解决物理机的添加、删除、电源管理、操作系统部署等问题。Ironic让OpenStack不仅停留在软件层面解决云计算问题。供应商可以对应自己的服务器开发Ironic插件。到目前为止,Ironic还处于实验阶段,它的目标是成为物理机管理的成熟解决方案。
提到Ironic项目,就不得不说Nova项目中的baremetal驱动。baremetal是Nova中的后端驱动,它与libvirt驱动、XenAPI驱动、VMware驱动一样,只不过它用来管理没有虚拟化的硬件,主要通过PXE和IPMI进行控制管理。这是一个可插拔式的插件,有了它,配置和管理服务器的硬件就可以使用Heat或salt-cloud来完成。baremetal并不能直接使用,还需要额外的环境准备,如要预先配置IPMI、配置DHCP服务、开启PXE等。Grizzy版本中已经含有baremetal驱动,但这仍然是实验性质。
在Nova中,baremetal的概念最早是由USC/ISI和NTT-Docomo提出的。USC/ISI是研究超算的教育机构,而NTT-Docomo是一家日本公司。物理机与虚拟机管理有许多类似的地方,但又有一些差异。最早设想为通过Nova统一管理,但在开发中,物理机与虚拟机的差异导致baremetal不得不从Nova中剥离,因为:
baremetal驱动有自己的数据库,在Nova一个项目中有两套数据库不合适。
物理机和虚拟机存储的数据信息不同,将两个有差异的实体放在同一个API中获取信息,在设计和使用上都比较别扭。
物理机和虚拟机的操作有差异,如discovery、hardware RAID configuration、firmware updates、burn-in等操作。物理机和虚拟机不能简单同质化。
社区经过讨论,决定将baremetal从Nova中剥离出来,命名为Ironic,主要用来实现对物理机的裸机管理。
下面来了解一下baremetal和Ironic在执行创建时的区别。
下面是通过PXE部署硬件物理机的步骤,如图1-26所示。
screenshot

1)通过“nova boot”命令创建物理机,nova-api组件处理命令并将创建消息发送到消息队列中。
2)nova-scheduler接收到消息队列中的消息,判断是否为baremetal节点,如果是,则将调度后的主机节点信息及创建消息放入消息队列。
3)nova-compute监听消息队列发现创建消息并处理,调用baremetal驱动,通过实现spawn()方法来调用创建。
4)nova-compute查询baremetal数据库,获取节点信息。
5)Neutron负责设置网络相关信息。
6)nova-compute开始从Glance获取镜像。
7)nova-compute激活bootloader。
8)通过IPMI开启物理机电源。
9)通过PXE加载bootloader,暴露iSCSI,通过nova-baremetal-deploy-helper将镜像中的信息写入服务器。
10)重新启动服务器,加载操作系统。
11)更新数据库中物理机的信息状态。
12)更新Nova中的instance状态信息。
Ironic的部署流程与baremetal类似,如图1-27所示。
screenshot

1)通过nova boot命令创建物理机,nova-api组件处理命令,并将创建消息发送到消息队列中。
2)nova-scheduler接收到消息队列中的消息,判断是否为baremetal节点,如果是,则将调度后的主机节点信息及创建消息放入消息队列。
3)nova-compute监听消息队列发现创建消息并处理,调用baremetal驱动,通过实现spawn()方法来调用创建。
4)nova-compute通过Ironic API获取硬件注册信息。
5)Neutron负责设置网络相关信息。
6)nova-compute开始从Glance获取镜像。
7)nova-compute通过Ironic API发送部署请求。
8)Ironic API与Ironic Conductor组件交互并激活bootloader。
9)通过IPMI开启物理机电源。
10)通过PXE加载bootloader,暴露iSCSI,通过nova-baremetal-deploy-helper将镜像中的信息写入服务器。
11)重新启动服务器,加载操作系统。
可以看到,Ironic对于硬件的异构问题主要是通过多个后端驱动的结合来解决的,如图1-28所示。
screenshot

图1-28中的接口介绍如下。
Deploy Interface:实现把镜像部署到物理机中。
Power Interface:实现对物理机电源的管理。
Console Interface:实现通过硬件直接得到物理机Console(控制台)。
Vendor Interface:厂商自定义行为。
因为Ironic项目结构与大部分的OpenStack结构类似,所以是标准的OpenStack项目。目前,由于项目时间较短,因此并不是很成熟,但是从Ironic想解决的问题以及社区的支持来看,Ironic有希望在未来的几个版本内成为核心项目。
Ironic的安装
下面介绍一下Ironic的安装流程。
1)通过git clone获取最新的DevStack。获取链接地址为:

git://github.com/openstack-dev/devstack.git

2)进入devstack目录修改localrc文件,添加如下内容:


 # Enable Ironic API and Ironic Conductor
 enable_service ir-api
 enable_service ir-cond
 
 # 使用Neutron代替nova-network,Ironic只支持Neutron
 disable_service n-net
 enable_service q-svc
 enable_service q-agt
 enable_service q-dhcp
 enable_service q-l3
 enable_service q-meta
 enable_service neutron
 enable_service q-lbaas
 
 #按需要替换password
 ADMIN_PASSWORD=password
 MYSQL_PASSWORD=password
 RABBIT_PASSWORD=password
 SERVICE_PASSWORD=password

3)运行stack.sh脚本。命令如下:
./stack.sh
接下来就是等待Ironic安装完成了。Ironic API地址为http://:6385

1.9.2 Tempest项目介绍

Tempest为OpenStack的功能测试、集成测试项目,它被设计为可在各种不同项目中使用。在OpenStack核心项目中的单元测试代码中经常可以看到它的身影,在一些孵化项目中也会使用Tempest去测试。它可以验证代码的正确性,已经成为OpenStack项目中不可或缺的组成部分。
Tempest框架主要基于unittest2和nose来实现,它通过调用OpenStack API来测试功能,响应验证。测试的主要风格是按照pyunit来确定的,同时使用了testtools和testresources等多个测试工具库,可以说相当强大。
使用Tempest测试一个OpenStack环境,先要在各个OpenStack项目的配置文件中设置Tempest,在etc/文件夹下有一个tempest.conf.sample供参考使用。设置完成后,就可以直接通过“nosetests tempest”命令运行所有测试案例,也可以指定执行某个测试类库中的测试用例。
Tempest主要用于以下几个测试:
API测试
命令行测试
复杂场景测试
压力测试
第三方API测试
每一项都对应Tempest中的一个目录,每个目录中包含不同类型的测试。README.rst中记录着每个目录的作用,以及良好的测试示例及测试规则。
Tempest目录结构如下:
1)api:API的测试集。
2)cli:OpenStack的命令行工具测试集。
3)common:一些公共的工具类和函数。
4)scenario:对OpenStack的常用场景进行测试,包括基本的启动虚拟机、挂载volume和网络配置等。
5)services:Tempest实现的OpenStack API Client,主要是避免官方Client中含有Bug。
6)stress:压力测试集,利用多进程(multiprocessing)同时对OpenStack发起请求进行测试。
7)thirdparty:EC2等第三方兼容API测试集。
8)whitebox:白盒测试集。
1.?API测试
API测试是验证OpenStack的API。它不应该利用现有的OpenStack Python客户端实现,而是应该使用Tempest组件来实现。同时测试XML和JSON格式的请求。脱离官方客户端,可以让我们传递无效或非法的JSON和XML请求来查看这些请求结果,以验证API的健壮性。API测试应由项目开发者自己来完成,比如对项目进行功能性测试,或者使用某些单元测试框架。
2.?命令行测试
命令行测试使用OpenStack的命令行与OpenStack中的项目组件进行交互。命令行测试中,单元测试是有点困难的,因为不像服务器测试,它没有实现访问服务器的代码。Tempest运行于一个部署好的OpenStack环境,这样就合乎逻辑了,可以在服务器上直接执行命令行。
3.?复杂场景测试
复杂场景测试是通过各种复杂的OpenStack调用流程来测试OpenStack功能。它由一系列经典场景组成,需要多个OpenStack项目支持来完成这一系列测试。场景测试可以使用OpenStack Python客户端。
4.?压力测试
压力测试主要设计为测试OpenStack在高工作负载中运行时会出现什么问题。多种工具可以帮助检测OpenStack在高负载时出现的问题,如追溯日志。
5.?第三方API测试
许多OpenStack项目支持第三方API,如Nova支持EC2的API。Tempest验证第三方API,必须独立于OpenStack正常的测试流程。第三方API测试应该独立于OpenStack本身的逻辑。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接