OpenStack-Heat中的Autoscaling - AWS的autoscaling

在Heat中完全使用aws的语法创建一套autoscaling的template。

流程:

Create LaunchConfig (Create basic instance, send mem status to ALARM) ->

Create ASGroup (Define instance num range) ->

Create ScaleUpPolicy (+1 instance when mem_alarm_high) ->

Create MEMAlarmHigh (Monitor mem status) ->

Create ScaleDownPolicy (-1 instance when mem_alarm_low) ->

Create MEMAlarmLow (monitor mem status)

Template模板:

"ASGroup" : {

"Type" : "AWS::AutoScaling::AutoScalingGroup",

"Properties" : {

"AvailabilityZones" : ["nova"],

"LaunchConfigurationName" : { "Ref" : "LaunchConfig" },

"MinSize" : "1",

"MaxSize" : "10"

}

},

"ScaleUpPolicy" : {

"Type" : "AWS::AutoScaling::ScalingPolicy",

"Properties" : {

"AdjustmentType" : "ChangeInCapacity",

"AutoScalingGroupName" : { "Ref" : "ASGroup" },

"Cooldown" : "60",

"ScalingAdjustment" : "1"

}

},

"MEMAlarmHigh": {

"Type": "AWS::CloudWatch::Alarm",

"Properties": {

"AlarmDescription": "Scale-up if MEM > 70% for 1 minute",

"MetricName": "MemoryUtilization",

"Namespace": "system/linux",

"Statistic": "Average",

"Period": "60",

"EvaluationPeriods": "1",

"Threshold": "70",

"AlarmActions": [ { "Ref": "ScaleUpPolicy" } ],

"Dimensions": [

{

"Name": "AutoScalingGroupName",

"Value": { "Ref": "ASGroup" }

}

],

"ComparisonOperator": "GreaterThanThreshold"

}

},

"ScaleDownPolicy" : {

"Type" : "AWS::AutoScaling::ScalingPolicy",

"Properties" : {

"AdjustmentType" : "ChangeInCapacity",

"AutoScalingGroupName" : { "Ref" : "ASGroup" },

"Cooldown" : "60",

"ScalingAdjustment" : "-1"

}

},

"MEMAlarmLow": {

"Type": "AWS::CloudWatch::Alarm",

"Properties": {

"AlarmDescription": "Scale-down if MEM < 30% for 1 minute",

"MetricName": "MemoryUtilization",

"Namespace": "system/linux",

"Statistic": "Average",

"Period": "60",

"EvaluationPeriods": "1",

"Threshold": "30",

"AlarmActions": [ { "Ref": "ScaleDownPolicy" } ],

"Dimensions": [

{

"Name": "AutoScalingGroupName",

"Value": { "Ref": "ASGroup" }

}

],

"ComparisonOperator": "LessThanThreshold"

}

},

"LaunchConfig" : {

"Type" : "AWS::AutoScaling::LaunchConfiguration",

"Metadata" : {

"AWS::CloudFormation::Init" : {

"config" : {

"files" : {

"/etc/cfn/cfn-credentials" : {

"content" : { "Fn::Join" : ["", [

"AWSAccessKeyId=", { "Ref" : "LSFKeys" }, "\n",

"AWSSecretKey=", {"Fn::GetAtt": ["LSFKeys",

"SecretAccessKey"]}, "\n"

]]},

"mode"    : "000400",

"owner"   : "root",

"group"   : "root"

},

"/tmp/stats-crontab.txt" : {

"content" : { "Fn::Join" : ["", [

"MAIL=\"\"\n",

"\n",

"* * * * * /opt/aws/bin/cfn-push-stats --watch ",

{ "Ref" : "MEMAlarmHigh" }, " --mem-util\n",

"* * * * * /opt/aws/bin/cfn-push-stats --watch ",

{ "Ref" : "MEMAlarmLow" }, " --mem-util\n"

]]},

"mode"    : "000600",

"owner"   : "root",

"group"   : "root"

}

}

}

}

},

"Properties": {

"ImageId": "rhel6u4",

"InstanceType": "m1.small",

"KeyName": "poc",

"UserData"       : { "Fn::Base64" : { "Fn::Join" : ["", [

"#!/bin/bash -v\n",

"/opt/aws/bin/cfn-init -s ", { "Ref" : "AWS::StackName" },

" -r VMWARELaunchConfig ",

" --region ", { "Ref" : "AWS::Region" }, "\n",

"crontab /tmp/stats-crontab.txt\n",

]]}}

}

}

},

OpenStack-Heat中的Autoscaling - AWS的autoscaling,布布扣,bubuko.com

时间: 2024-12-25 21:19:31

OpenStack-Heat中的Autoscaling - AWS的autoscaling的相关文章

Heat中的AWS::WaitCondition的使用

在heat中,一个instance的创建成功信号是在这个instance状态成为active之后发出的,这时候user-data可能还没有执行.但是heat已经认为这个resource创建成功了,开始调度下一个resource的创建. 如果我们要建立一个webserver,这个webserver需要在databaseServer执行完user-data之后才开始创建,就需要使用AWS的waitcondition通讯机制. 整个流程如下: Create WaitHandler -> WaitHan

【译】OpenStack Heat基础介绍

原文:http://blog.scottlowe.org/2014/05/01/an-introduction-to-openstack-heat/ 本文将简要地介绍OpenStack Heat. Heat项目提供协作服务,允许我们可以自动地创建多个计算实例,逻辑网络,以及对其他的云服务的操作.请注意,这只是一个简要介绍—我不是Heat的专家,我只是想要分享一些基本信息以便读者可以更快的使用Heat. 为了在以下的具体的例子中不至于产生困扰,我们先从术语开始. Stack(栈): 在Heat领域

Nova和Heat中的servergroup

现在nova可以通过命令创建一个server group,在server group中的vm可以指定一些policy. 这些policy包括affinity和anti-affinity.affinity表示尽量把vm都安排到一个host上面,anti-ffinity表示尽量把vm安排到不同的host上面. 创建server-group的命令如下: nova server-group-create group_name anti-afffinity 然后创建vm的时候通过hint指定group名字

一张图理解OpenStack Heat的内部调用逻辑

OpenStack Heat是个很有前景的项目,主要负责在数据中心中利用模板来完成资源的自动化管理. 即,用户定义可读性好(json or yaml)的资源模板,heat负责将这些资源在openstack中进行部署. 其内部主要分heatclient.heatapi.heatengine三层,调用逻辑如下图所示. heat-client,接受输入命令.参数和模板(URL.文件路径或数据),处理信息后转为REST API请求发送到heat-api服务. heat-api服务接受请求,读入模板信息,

openstack resize 中遇到的问题

在openstack环境中更改实例的配置大小,遇到的问题这里做个记录,以便以后遇到同样的问题时查看. 确保各个主机之间能使用nova用户无密码访问,使用key 按照官方手册执行各步骤: source keystone-admin 查看需要resize实例的情况:nova show instance-name 查看云主机类型:nova flavor-list 开始resize: nova resize instance-name/instance-id flavor-name/flavor-id

OpenStack Heat template中类型定义的一个坑

最新的Heat template目前支持string | number | json | comma_delimited_list | boolean等类型. 采用默认的hot格式,yaml文件格式. 定义一个string类型的属性,内容为true或false的时候,会报错. 查看heat engine的log会发现这个属性值默认被转为了boolean类型. 这是为何呢? 查看heat的代码,heat是调用的yaml库来直接load文件的,而对于yaml语言来说,如下的字符串都会被解析为bool

Openstack liberty 中Cinder-api启动过程源码分析2

在前一篇博文中,我分析了cinder-api启动过程中WSGI应用的加载及路由的建立过程,本文将分析WSGI服务器的启动及其接收客户端请求并完成方法映射的过程,请看下文的分析内容: 创建WSGI服务器 在初始化WSGIService对象的过程中,会创建WSGI服务器,如下: #`cinder.service:WSGIService.__init__` def __init__(self, name, loader=None): """ name = `osapi_volume

Openstack liberty中nova-compute服务的启动过程

前段时间撰文分析了"云主机的启动过程"源码,读者应该注意到了nova-scheduler,nova-compute等组件是通过发起rpc.cast, rpc.call调用完成交互的.那今天我打算介绍下nova-compute服务的启动过程,并重点分析下其与AMQP(rabbitmq)链接的建立过程. 在CentOS 7中启动nova-compute服务,执行路径是这样的: systemctl start openstack-nova-compute.service -> /usr

Openstack(Juno)中VPNaaS的配置

vpnaas配置的资料很少,官网目前参考的https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall比较旧,方面配置基本没有讲 经历漫长时间的查找资料.学习,现终于配置成功了,记录下来给大家参考一下,有什么不正确的地方及时留言 1. 配置 1.1 准备 yum install openstack-neutron-vpn-agent libreswan -y vi /etc/sysctl net.ipv4.ip_forward=1 net