【转】OpenStack Heat总结之：Icehouse中通过Heat+Ceilometer实现Autoscaling

http://www.iyunv.com/thread-24495-1-1.html

在I版本中,Heat中添加了对于AutoScaling资源的支持，github上也提供了对应的AutoScaling的模板(https://github.com/openstack/hea ... ot/autoscaling.yaml),同时也支持使用ceilometer的alarm来触发Scaling Policy,但是在实践的过程中可能会碰到一些问题，本文就该特性以及问题做一个简单的总结

AutoScaling定义的流程

• 首先定义一个Auto Scaling Group，该Group 定义了可以持有资源的类型以及的最大、最小资源数
  
• 根据需求定义Alarm的触发条件，例如当CPU利用率在一分钟内平均值超过50%时触发警报，支持的的指标可以通过ceilometer meter-list命令查询
• 针对某个具体的Alarm，定义Policy,例如CPU利用率长时间偏高时，就在AutoScalingGroup中重新初始化一个相同实例,该Policy需要与 步骤一  中定义的Group绑定
  
• 为了更好的提高资源利用率，在定义自动收缩机制的同时可以定义负载均衡（Neutron LBAAS）。
  

定义AutoScaling的过程中涉及到的资源如下图：

AutoScaling的工作流程

• Ceilometer通过获取实例的监控参数，发现实例的某项指标出现异常，且符合已经定义的Alarm触发规则
  
• 触发Policy.在生成Policy和Alarm时，Alarm会设置其alarm_actions属性，该属性的值可以理解为调用特定Policy服务的URL,此时该URL被调用
  
• Policy被调用，根据配置，决定增加还是减少实例
  

工作流程大概如下：

AutoScaing实战为了简单，下载https://github.com/openstack/hea ... ot/autoscaling.yaml，以此为基础进行调整
模板文件没什么好说，用到了HOT模板的一些资源。主要说下在创建的过程中碰到的问题

• 该模板中的Alarm创建出来后，查看alarm 列表可以发现Continues属性都是false（ 如果查看明细该属性对应的是repeat_actions属性）该属性的为false代表alarm_action只会被执行一次，所以为了达到更好的演示效果，需要将其修改为True
  
• 为了达到演示的效果，可以将Alarm的Period设置的短一点，比如说10s
• 如果Alarm的状态长时间为insufficent_data,说明ceilometer长时间没有采集到监控指标的数据，为了达到更好的演示效果可以调整/etc/ceilometer/pipeline.yaml文件中采集指标的间隔。默认的间隔是600秒，可以将其设置为小于CoolDown或是Alarm Period   的时间
• 对于执行的过程，主要可以参考heat-engine.log, heat-api-cfn.log, alarm-evaluator.log等日志
• 当前的版本执行过程中有以下错误产生，可以参考https://review.openstack.org/#/c/92887/进行解决
  
  2014-08-0105:38:08.410 3834 ERROR heat.engine.service[req-96a84baa-6b6f-4a4e-a2f3-90c0a02612e7 None] Unable to retrieve stack40e7560e-848e-4d78-bac0-8eb4f26ac22f for periodic task
• 
  
  

下图为相关的资源列表

下图为Alarm的列表

下图为某个Alarm的history

IceHouse中的alarm是一个监控特定指标的对象。alarm的状态包括：
1、OK。表示指标正常
2、ALARM。表示指标异常。如果连续几个周期都处于ALARM状态，那么就会触发一个或多个policy，进而触发scaling group的扩缩。
3、INSUFFICIENT_DATA。表示数据不可用。出现这个状态主要是因为 缺少监控指标的数据,处于这个状态的Alarm也不会被触发。如果为了测试目的，可以通过修改/etc/ceilometer/pipeline.yaml文件中的interval参数来调整收集数据的间隔