Heat Ha介绍

问题导读
1、什么是Heat Ha ？
2、怎么通过配置模板实现Heat的HA？
3、关于HA，有哪些后续思考？





记得还在去年的时候，大家讨论OpenStack总离不了这样的一个问题：“OpenStack为什么不支持虚拟机的HA？”
当时也很奇怪，对于HA这样一个很基本的可靠性特性有缺失，又怎么在实际场景中使用OpenStack呢？
当时社区讨论的结果是：“由OpenStack上层组件实现HA，OpenStack核心模块仅提供基本的操作。”
那么这个所谓的上层组件指的是谁呢？就是Heat。如今Heat已经是OpenStack的核心模块，也就是说OpenStack已经具备的HA的能力。

超出期望

以前我们总是说虚拟机HA，似乎所有的功能都是围绕着虚拟机设计，已虚拟机为核心。但是从Heat的文档里来看，Heat认为虚拟机之上的服务（Service）才是最终要的，对于Heat HA的设计，也扩展到了服务的层面，可以实现三个层次的HA：

• service
• instance
• stack
  

例如：当虚拟机上的数据库进程down了，首先通过重启数据库进程尝试解决，如果解决不了，重启或者重建虚拟机，如果还是解决不了，重建整个stack。从这一点上来看Heat HA的功能要比单纯的虚拟机HA的功能强大很多。


实现

Heat的HA特性是OpenStack多模块配合实现的，其中涉及到Nova，Ceilometer，Heat-cfn-api，Heat-cloudwatch，Heat-cfntools等。
»Heat-cfntools
Heat-cfntools包括了一些和Heat配合使用的小工具，它们运行在虚拟机内部，在制作虚拟机镜像的时候，需要将cfntools打包到镜像当中，Heat的开发者文档中，介绍了将cfntools打包进镜像中的方法。这里
Heat的HA功能就是用到了cfn-push-stats对虚拟机或者服务的状态进行上报。

• cfn-init -> 配置虚拟机，简化user_data脚本
• cfn-hub -> 定期检测instance metadata是否有变化，根据变化触发用户定义的hooks
• cfn-signal -> 发送执行命令成功或失败的信号
• cfn-push-stats -> 上报服务或虚拟机状态
• cfn-get-metadata -> 获取instance metadata
  

有兴趣的同学可以直接git clone一份cfn-tools的代码看看。
https://github.com/openstack/heat-cfntools.git

»Heat-template
我们从Heat的HA模板入手，来分析一下怎么通过配置模板实现Heat的HA。
以github上的Heat模板WordPress_Single_Instance_With_IHA.template为例。

...
"WebServerRestartPolicy" : {
  "Type" : "OS::Heat::HARestarter",
  "Properties" : {
    "InstanceId" : { "Ref" : "WikiDatabase" }
  }
},
"HeartbeatFailureAlarm": {
 "Type": "AWS::CloudWatch::Alarm",
 "DependsOn" : "WaitCondition",
 "Properties": {
    "AlarmDescription": "Restart the WikiDatabase if we miss a heartbeat",
    "MetricName": "Heartbeat",
    "Namespace": "system/linux",
    "Statistic": "SampleCount",
    "Period": "60",
    "EvaluationPeriods": "1",
    "Threshold": "1",
    "AlarmActions": [ { "Ref": "WebServerRestartPolicy" } ],
    "ComparisonOperator": "LessThanThreshold"
  }
},
"WikiDatabase": {
  "Type": "AWS::EC2::Instance",
  "Metadata" : {

...

"/tmp/cfn-hup-crontab.txt" : {
"content" : { "Fn::Join" : ["", [
"MAIL=""\n",
"\n",
"* * * * * /opt/aws/bin/cfn-hup -f\n",
"* * * * * /opt/aws/bin/cfn-push-stats ",
" --watch ", { "Ref" : "HeartbeatFailureAlarm" },
" --heartbeat\n"
]]},
"mode"    : "000600",
"owner"   : "root",
"group"   : "root"
},
复制代码

我们先来看/tmp/cfn-hup-crontab.txt，其实就是一个crontab的配置文件，在boot instance WikiDatabase 的时候，因为配置了UserData，所以UserData脚本执行的时候会调用cfn-init命令，cfn-init的作用就是根据AWS::CloudFormation::Init段的配置，生成文件，安装软件，执行脚本等等，在UserData脚本的最后cfn-hup的crontab被启用。
cfn-push-stats会每分钟向heat-api-cloudwatch发送一个watch为HeartbeatFailureAlarm类型的心跳请求。HeartbeatFailureAlarm其实是一个Ceilometer的Alarm。
根据HeartbeatFailureAlarm的配置，如果60秒没有收到instance WikiDatabase的心跳请求，就会触发AlarmActions OS::Heat::HARestarter，根据Heat对于资源OS::Heat::HARestarter的定义，Heat会删除原先的虚拟机WikiDatabase，然后重新创建一个虚拟机。
对于服务的监控大家可以参考另一个Heat模板WordPress_Single_Instance_With_HA.template

后续思考

对于普通的Web无状态应用，通过OS::Heat::HARestarter删除原有虚拟机，然后重新创建也许适合的，但是如果是数据库之类的有状态应用呢？怎么保证原有数据库中数据的不丢失，后端卷虚拟机？那又怎么保证使用原来的fixed-ip？Heat的HA的基本的思路已经很通畅了，但是在使用的过程中，还是可能遇到种种实践中的问题，需要多多尝试和改进。




本文转载自：http://kiwik.github.io/openstack/2014/03/22/Heat-HA/

不错。但我一些思考就是heat的模板是否太不友好了。还有镜像里面的操作应该由owner自定义吧，这里涉及分工的问题。