使用编排工具OpenStack Heat来自动扩展您的应用程序（第1部分）
使用编排工具OpenStack Heat来自动扩展您的应用程序（第1部分）
缩放 - 这是大家都重视的事情。
当谈到有关云编排的话题时（现在所有的酷孩子都在做这个），当没有人是派对扫兴者也没人突然插嘴打断别人说“是的，但你能够自动收缩我的应用程序吗？”时，你最好全程参与这个话题别离开哪怕十分钟。
实际上，我自己就是那些派对扫兴者。你不能怪我们; 从云计算出现以来，扩展大型应用拓扑变得更加可行，因为现在您可以在几分钟内通过API提供任何类型的资源。
但是，水平缩放是并将永远是一个非常重要的问题。首先，你试图扩展的应用程序必须意识到，它可能会被缩放，而不是依赖于任何可能按比例改变的状态。
Cloudify能使OpenStack Orchestration变得轻松。现在得到它。
以Web服务器实例为例，为了能够扩展，它不能存储与后续请求相关的会话细节，因为这些请求可能由其他实例处理。只有满足这个要求，我们才能开始谈论其他更“通用”的挑战：
- 应当衡量什么样的指标以及如何衡量。
- 如何触发缩放过程。
- 如何建立流程本身。
在这篇文章中，我将会讨论这些方面，我们将看到如何在OpenStack云环境中解决这个问题。
通过Heat在OpenStack上进行缩放
OpenStack Heat是为OpenStack Cloud设计的应用程序编排引擎。它集成在OpenStack发行版中，可以通过CLI或通过Horizon GUI使用。Heat使用称为HOT（Heat Orchestration Template）的专有模板语言来定义应用拓扑。
本节假定Heat的基本知识。如果您没有碰到这方面的知识，可以查看下面的链接，以帮助您了解它的全部内容：
在Heat自动缩放需要三种主要类型的帮助：
OS :: Heat :: AutoScalingGroup
AutoScalingGroup是一个资源类型，用于封装我们想要缩放的资源，以及与缩放过程相关的一些属性。
ScalingPolicy是一种资源类型，用于定义缩放过程在缩放资源上的效果。
Alarm是一种资源类型，用于定义ScalingPolicy应在哪些条件下触发。
一个例子会帮助我们变得更加清晰地理解，所以让我们继续吧。
我们的用例将自动扩展一个连接了静态和共享MariaDB实例的Wordpress服务器。
以下是全自动缩放示例的摘录。
这是MariaDB服务器的定义：
db:
type: OS::Nova::Server
properties:
user_data:
str_replace:
template: |
#!/bin/bash -v
yum -y install mariadb mariadb-server
systemctl enable mariadb.service
systemctl start mariadb.service
…<more installation stuff…>我们可以看到，它只是一个OS :: Nova :: Server类型的资源，具有用于通过yum安装MariaDB的user_data属性。
现在我们来看看自动缩放部分如何发挥作用。
任何自动缩放过程实现应该总能回答三个基本问题：
- 扩展哪种资源？
- 缩放过程有什么作用？
- 什么时候应该触发缩放过程？
Q1：哪种资源
asg:
type: OS::Heat::AutoScalingGroup
properties:
min_size: 1
max_size: 3
resource:
type: OS::Nova::Server properties:
user_data:
str_replace:
template: |
#!/bin/bash -v
yum -y install httpd wordpress
systemctl enable httpd.service
systemctl start httpd.service
setsebool -P httpd_can_network_connect_db=1
…<more installation stuff…>这是一个OS :: Heat :: AutoScalingGroup类型的资源，它定义了我们想要扩展安装httpd的 OS :: Nova :: Server类型的资源，并将Wordpress应用程序部署到它上面。请注意，缩放资源可以在缩放组之外定义，然后使用get_resource内部函数进行引用。
Q2：什么作用
web_server_scaleup_policy:
type: OS::Heat::ScalingPolicy
properties:
auto_scaling_group_id: {get_resource: asg}
adjustment_type: change_in_capacity
scaling_adjustment: 1这是一个OS :: Heat :: ScalingPolicy类型的资源。让我们仔细看看它的属性
- auto_scaling_group_id：
- 这就是我们如何将这个政策与一个特定的扩展组相联系，这个扩展组反过来定义了资源的规模。
- adjustment_type:
- 这表明我们将会创建一个相对于当前容量的变化。其他选项可以是“exact_capacity”或“percent_change_in_capacity”。
- scaling_adjustment：
- 这真的是整个问题，每次触发这个策略时，我们都要添加一个Wordpress实例。
Q3：什么时候
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
threshold: 50
alarm_actions:
- {get_attr: [web_server_scaleup_policy, alarm_url]}
matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}}我们看到这个Alarm是OS :: Ceilometer :: Alarm类型的一个资源，它基本定义了Heat引擎：
一旦Wordpress服务器上的平均CPU大于50％至少1分钟，就触发web_server_scaleup_policy
好吧，我们花了一段时间，但我们通过定义一个具有自动扩展功能的HOT模板来完成。对于我们刚刚看到的例子，现在我们来处理这篇文章的开头提到的扩展方面：
度量
我们看到，度量测量是通过Ceilometer完成的，Ceilometer是一个集成到OpenStack中的内置监控和计量系统。它提供了各种OpenStack资源的各种指标。在当前的例子中，我们使用cpu_util指标来检查Wordpress服务器的CPU利用率。有很多不同的指标可供选择，从Compute实例到LBaaS。
但是，有一些东西缺失了。在很多情况下，我们真正感兴趣的是应用程序/中间件的具体指标。也就是说，我想让我的Wordpress服务器在有太多的请求触及当前端点时进行扩展。这种类型的信息绝不会通过Ceilometer暴露出来，这当然是有道理的，因为它不知道在正在跟踪的服务器上部署了什么。好消息是从技术上讲，您可以通过用户定义数据API（User Defined Data API）将自定义指标推送到Ceilometer。在实践中，这是一个不重要的工程工作，需要用户完成。理想情况下，如果您可以配置哪些自定义指标将通过模板推送到Ceilometer，并且在服务器上具有实际执行工作的内置组件，那就太好了。
触发
一旦警报阈值被破坏，缩放过程就会自动触发。Heat还提供了一个webhook，用于使用附加到策略本身的alarm_url属性显式触发扩展策略。
处理
到目前为止，我们还没有真正讨论扩展过程实际上做了什么，也就是说，它只是创建一个新的资源实例，就是这样吗？它是什么样子的？它在哪里定义？
这并非偶然，只是因为所有这些信息对用户是隐藏的，因此根据定义，相同的过程将适用于任何类型的资源。例如，如果我想扩展MariaDB实例，我会只简单地引用AutoScalingGroup中的资源，而不是内联的资源。
但是，如果扩展数据库实例对我的系统具有不同的管理影响，那么扩展Web Server实例会怎样？有时您可能希望能够在启动新实例之前执行某些操作。也许有些服务水平协议(SLA)问题需要使用第三方端点来执行。实际上，这个方面并不是专门与自动缩放相关的。相同的论点可以应用到堆栈的创建，删除，更新...以及，你已看到我的观点。
好吧，我认为这是一个很重要的工作，并且它在OpenStack环境中提供了很多关于自动缩放的工作，但这只是其中的一部分。在我的下一篇文章中，我想将这个过程与基于TOSCA的流程进行比较，该流程与任何其他云，甚至与OpenStack的混合云环境都是相关的。还会有更多内容。