当前位置:

OFweek云计算网

云应用

正文

深度解码超实用的OpenStack Heat

导读: Orchestration 可以理解为自动化部署、配置(provisioning and deployment)。除了资源的部署之外,还有一方面是server上应用软件的安装配置。当需要部署多个节点的时候,节点之间的依赖关系,部署顺序和配置都可以交给heat来管理。

Heat 是由AWS的EC2 Cloud Formation 演化而来,是openstack中负责Orchestration的service, 用于openstack 中资源的编排,它通过将OpenStack中的资源(resource)以模版(template)的形式组织起来。例如我们可以将一组资源,比如虚拟机实例的启动、IP绑定、软件部署等写在一个template里面,heat 通过读取配置文件来完成模版规定的动作:创建虚拟机,associate floatingip,deploy application 等等。Heat 将从这个template中创建出来的一组资源称之为“资源栈”(stack)。当对这一组资源进行操作时,只需要对stack进行操作,所以heat很适合批量资源的创建和销毁,它将一系列繁琐的人工操作自动化了起来。

Orchestration 可以理解为自动化部署、配置(provisioning and deployment)。除了资源的部署之外,还有一方面是server上应用软件的安装配置。当需要部署多个节点的时候,节点之间的依赖关系,部署顺序和配置都可以交给heat来管理。

除此之外, heat 还可以和open stack的监控(telemetry)服务Ceilometer一起实现自动伸缩,所以我们可以在heat的模版中定义一个scaling group作为一个资源。

本文将对以上内容做一个简单的介绍。

什么是Heat?

Heat向开发人员和系统管理员提供了一种简便地创建和管理一批相关的OpenStack资源的方法,并通过有序且可预测的方式对其进行资源配置和更新。用户可以使用Heat的示例模板或自己创建模板来描述OpenStack资源以及应用程序运行时所需的任何相关依赖项或运行时参数。

当设置完成后,可通过按授权控制、可预测的方式修改和更新OpenStack资源。用户可以通过OpenStack管理控制台、Heat命令行工具或 API对模板及其相关的资源集进行设置和更新。

为什么需要heat

?更快更有效的管理OpenStack的资源

云平台系统在相对比较稳定的情况下,管理成本逐渐变成首要的解决问题。云上自动化能力是一个云平台的刚需,可以有效降低维护难度。

OpenStack原生提供命令行和Horizon 来供用户管理资源。然而命令行和在浏览器中的点击,费时费力,不利于用户使用Openstack 来进行大批量的管理以支撑IT 应用。如下图所示,openstack中有众多的资源,对应了很多繁琐的操作。

深度解码超实用的OpenStack Heat

Heat 在这种情况下应运而生. 如下图所示,我们可以将一些零散的资源操作都定义在heat的模版中,通过一个创建stack的操作,就能创建出我们要的资源。Heat 采用模板方式来设计或者定义编排。为方便用户使用,Heat 还提供了大量的模板例子,使用户能够方便地得到想要的编排。

深度解码超实用的OpenStack Heat

更小的研发成本

引入Heat,对于不了解OpenStack的研发者来说,可以更快的接入现有的业务系统。开发者更关心的是授权认证和对虚拟资源的增删改,而对于底层的状态并不用太多了解。

术语

1. stack

Stack概念来源于AWS,是OpenStack中用来管理一组资源的基本单位。一个stack往往对应一个应用程序。Stack管理的是resource,而resource是个抽象的概念,它可以是虚拟机,可以是网络等。

Stack就是在单个模板中定义的实例化资源的集合,是Heat管理应用程序的逻辑单元。

2. template

heat的template描述了所用的所有组件资源以及组件资源之间的关系。heat模版是heat的核心。

2.1 resource

资源是底层服务的抽象,CPU、memory、disk、网络等都可以看作是资源。一个stack可以拥有很多资源。资源和资源之间会存在依赖关系。Heat在创建栈的时候会自动解析依赖关系,按顺序创建资源。在heat的template中,resources用于模板中资源的声明,在HOT模板中,应该至少有一个资源的定义,否则在实例化模板时将不会做任何事情。

2.2 parameters

heat模板中的参数,定义在创建或更新stack时可以传递哪些参数来定制模板。

2.3 parameter_groups

用于指定如何对输入参数进行分组,以及提供参数的顺序。

?2.4 outputs

heat模板中的顶级key,定义实例化后stack将返回的数据。

模版中包括七个部分:heat_template_version、description、parameter_groups、parameters、resources、outputs、conditions。除了heat_template_version和resources,其它都是可选部分。

Heat架构

Heat 是openstack 中上层的一个服务,如下图所示:

深度解码超实用的OpenStack Heat

它位于其它基础组件的上层,可以将其它组件的资源以模版的形式组织起来, 如下图:

深度解码超实用的OpenStack Heat

Heat 由以下组件组成:

- Heat-api:实现openstack天然支持的REST API。该组件通过把API请求经由AMQP传送给Heat engine 来处理API请求。

- Heat-api-cfn:提供兼容AWSCloudFormation的API,同时也会把API请求通过AMQP转发给Heat engine。

- Heat-engine: heat-engine是heat中的核心模块,处理主要的逻辑业务。此模块提供heat最主要的功能,执行模板内容,最终完成应用系统的创建和部署,并把执行结果返回给API调用者。当heat engine 拿到请求后,会把请求解析为各种类型的资源,每种资源都对应OpenStack 其它的服务客户端,然后通过发送REST 的请求给其它服务。通过如此的解析和协作,最终完成请求的处理。

- heatclient:CLI通过与heat-api通信,来调用API实现相关功能。终端开发者可以直接使用编排REST API。

- heat-cfntools:独立于heat组件的一个的工具,需要单独下载。这个工具用来完成虚拟机实例内部的操作配置任务。在创建虚拟机镜像时,需要在镜像中安装heat-cfntools工具。

Heat 中各个组件调用逻辑如下图所示:

深度解码超实用的OpenStack Heat

Heat client 接受输入命令,参数和模板,处理信息后转为REST API,请求发送到heat-api服务。Heat API服务接受请求,读入模板信息,处理后利用rpc请求发送给heat-engine。heat-engine解析template数据,调用各种资源插件,然后各种资源插件通过openstack的clients发送指令给OpenStack服务。

Heat使用

5.1 对基础架构的编排

对于不同的资源,Heat 都提供了对应的资源类型。比如对于VM,Heat 提供了OS::Nova::Server。OS::Nova::Server 有一些参数,比如key、image、flavor 等,这些参数可以直接指定,可以由客户在创建Stack 时提供,也可以由上下文其它的参数获得。创建一个VM的部分模板如下:

resources:

server:

type: OS::Nova::Server

properties:

key_name: { get_param: key_name }

image: { get_param: image }

flavor: { get_param: flavor }

user_data: |

#!/bin/bash

echo “10.10.10.10 testvm”>> /etc/hosts

在上面创建VM 的例子中,我们选择从输入参数获得OS::Nova::Server 所需的值。其中利用user_data 做了一些简单的配置。

5.2 对软件配置和部署的编排

Heat提供了多种资源类型来支持对于软件配置和部署的编排,如下所列:

OS::Heat::CloudConfig:VM 引导程序启动时的配置,由OS::Nova::Server 引用

OS::Heat::SoftwareConfig:描述软件配置

OS::Heat::SoftwareDeployment:执行软件部署

OS::Heat::SoftwareDeploymentGroup:对一组VM 执行软件部署

OS::Heat::SoftwareComponent:针对软件的不同生命周期部分,对应描述软件配置

OS::Heat::StructuredConfig:和OS::Heat::SoftwareConfig 类似,但是用Map 来表述配置

OS::Heat::StructuredDeployment:执行OS::Heat::StructuredConfig 对应的配置

OS::Heat::StructuredDeploymentsGroup:对一组VM 执行OS::Heat::StructuredConfig 对应的配置

其中最常用的是OS::Heat::SoftwareConfig 和OS::Heat::SoftwareDeployment。

OS::Heat::SoftwareConfig

下面是OS::Heat::SoftwareConfig 的用法,它指定了配置细节。

resources:

install_db_sofwareconfig

type: OS::Heat::SoftwareConfig

properties:

group: script

outputs:

- name: result

config: |

#!/bin/bash -v

yum -y install mariadb mariadb-server httpd wordpress

touch /var/log/mariadb/mariadb.log

chown mysql.mysql /var/log/mariadb/mariadb.log

systemctl start mariadb.service

OS::Heat::SoftwareDeployment

下面是OS::Heat::SoftwareDeployment 的用法,它指定了在哪台服务器上做哪项配置。另外SofwareDeployment 也指定了以何种信号传输类型来和Heat 进行通信。

sw_deployment:

type: OS::Heat::SoftwareDeployment

properties:

config: { get_resource: install_db_sofwareconfig }

server: { get_resource: server }

signal_transport: HEAT_SIGNAL

OS::Heat::SoftwareConfig 和OS::Heat::SoftwareDeployment 执行流程

OS::Heat::SoftwareConfig和OS::Heat::SoftwareDeployment协同工作,需要一系列Heat工具的自持。这些工具都是OpenStack的子项目。

首先,os-collect-config调用Heat API拿到对应VM的metadata。当metadata更新完毕后os-refresh-config开始工作了,它主要是运行下面目录所包含的脚本:

/opt/stack/os-config-refresh/pre-configure.d

/opt/stack/os-config-refresh/configure.d

/opt/stack/os-config-refresh/post-configure.d

/opt/stack/os-config-refresh/migration.d

/opt/stack/os-config-refresh/error.d

每个文件夹都应对了软件不同的阶段,比如预先配置阶段、配置阶段、后配置阶段和迁移阶段。如果任一阶段的脚本执行出现问题,它会运行error.d目录里的错误处理脚本。os-refresh-config 在配置阶段会调用一定预先定义的工具,比如heat-config,这样就触发了heat-config的应用,调用完heat-config后,又会调用os-apply-config。存在在heat-config或者os-apply-config里的都是一些脚本,也叫钩子。Heat对于各种不同的工具提供了不同的钩子脚本。用户也可以自己定义这样的脚本。

等一切调用完成无误后,heat-config-notify 会被调用,它用来发信号给Heat,告诉这个软件部署的工作已经完成。当Heat 收到heat-config-notify 发来的信号后,它会把OS::Heat::SoftwareConfig 对应资源的状态改为Complete。如果有任何错误发生,就会改为CREATE_FAILED 状态。

OS::Heat::SoftwareConfig 和OS::Heat::SoftwareDeployment 执行流程如下:

深度解码超实用的OpenStack Heat

Heat  AutoScalling

基础架构的自动伸缩是一个很高级的功能。Heat提供自动伸缩组OS::Heat::AutoScalingGroup 和伸缩策略OS::Heat::ScalingPolicy,结合基于Ceilometer 的OS::Ceilometer::Alarm 实现了可以根据各种条件,比如负载,进行资源自动伸缩的功能。

Heat 自动伸缩的流程图如下:

深度解码超实用的OpenStack Heat

定义自动伸缩组如下:

auto_scale_group:

type: OS::Heat::AutoScalingGroup

properties:

min_size: 1

max_size: 4

定义伸缩规则如下:

server_scaleup_policy:

type: OS::Heat::ScalingPolicy

properties:

adjustment_type: change_in_capacity

auto_scaling_group_id: {get_resource: auto_scale_group}

cooldown: 60

scaling_adjustment: 1

定义警报如下:

cpu_alarm_high:

type: OS::Ceilometer::Alarm

properties:

description: Scale-up if the average CPU > 50% for 1 minute

meter_name: cpu_util

statistic: avg

period: 60

evaluation_periods: 1

threshold: 50

alarm_actions:

- {get_attr: [server_scaleup_policy,alarm_url]}

matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}}

comparison_operator: gt

互动区

* 你对以上内容有什么看法?你最关注云计算哪个趋势?如果你还有想了解的技术话题,欢迎留言分享。

启迪云-高级网络工程师 邸小丽

声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

我来说两句

(共0条评论,0人参与)

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号