1.介绍
“弹性”是云服务特有的一种高阶能力。弹性伸缩,简称AS(Auto Scaling)。
用户可以根据业务需求和策略设置伸缩规则,在业务需求增长时自动为业务增加虚拟化资源,以保证计算能力。在业务需求下降时自动减少虚拟化资源,可节约成本,也可帮助用户根据负载对业务服务削峰填谷,平衡成本与资源。业务量相对稳定的服务,可使用弹性伸缩实现健康监测以及异常状态的资源自动替换,从而减少人工运维的成本。
2.实际应用场景
2.1 高弹性web应用服务
适用于存在明显波峰波谷的业务,例如短视频服务。用户可以通过设置定时策略,实现稳定的、周期性的扩缩服务,最大化地节约成本。如下图1所示:
图1
2.2 高可用计算密集型服务
适用于存在高可用性,且需要具备随负载的变化动态调整能力的计算服务,例如分布式大数据服务的计算节点。用户设置监控扩缩策略后,系统将根据监控项(例如CPU、使用率等)变化自动扩缩调整集群规模,同时替换健康状态异常的实例,最大化地保障服务稳定性。如下图2:
图2
3.架构
弹性伸缩的整体功能结构包括四个方面,分别是接入层、驱动层、适配层以及操作层。
接入层,即API侧,主要用于接收和处理请求。
驱动层,作为弹性伸缩的核心部分,通过MySQL和Redis将资源管理、定时管理、主机管理、Workflow串联在一起。Redis主要用于为定时任务加锁,保证任务不会重复执行。
适配层用于连接驱动层和操作层,可以视为第三方接口平台,具有可扩展性。通过对接不同的适配层,弹性伸缩能够支持众多类型的云计算服务、支持Promethus或者Open-Falcon等多种类型的监控平台、支持RDS白名单和配置负载均衡等多种功能。
操作层则是具体的操作对象,不同的适配层对应不同的操作对象,例如以OpenStack为代表的云计算。架构图解如下图3。
图3
3.1 工作流模式
扩缩容过程中会涉及多个动作,同时还会涉及多个实例。由于这些动作之间存在相互依赖的关系,为了避免实例在执行动作时相互影响,因此设计了工作流模式。每个实例作为一个对象依次执行各个动作,每个动作按照成功或者失败的结果,会引导实例执行对应的下一个动作,最终保证实例被成功创建并上线或销毁。这种方式能够保证多个实例快速扩缩容并且互不干扰。
3.2 数据关联
弹性伸缩的数据关联如下图4所示,各数据之间以stackId作为外键进行关联。
图4
4.功能
弹性伸缩服务支持的功能可包括扩缩容、自动配置负载均衡、添加RDS白名单、滚动更新等。
4.1 负载均衡/RDS配置
用户根据业务需要按需扩缩容是云上真正有意义的运维场景,但是扩缩容除了创建或者销毁实例外,还应该包含一些其他的动作,来帮助用户将创建或待销毁的实例,自动部署或移出生产环境。这其中就涉及到配置负载均衡LVS及添加数据库RDS白名单功能。扩容时当实例能够正常运行后,需要将实例挂载到LVS上并配置RDS白名单,保证实例正常上线。当缩容时,首先将实例从LVS中卸载,再销毁实例,目的是保证业务流量不受影响。
4.2 扩容/缩容
实例扩容需要经历创建、状态检查、ping检测、配置负载均衡、添加RDS白名单等操作。具体的执行流程图以及逻辑流程图如下图5所示。
图5
如果创建、状态检查、ping检测步骤失败,均会删除实例,并开始重试。连续多次创建失败的情况,会终止扩容过程,发送错误报警提醒排查。如下图6。
图6
选择某北京机房,创建2核4G独享虚拟机,进行性能测试结果如下表1:
表1
缩容流程则与扩容流程相反,实例首先经过修改LVS权重,等待30s,再卸载LVS,最后再销毁实例。目的是保证业务流量不会中断。尤其是等待30s的环节,需要考虑到一种情形:虽然修改权重后,流量不会再打到待缩容的实例上,但若此时立刻卸载LVS,会导致已经发送、但未收到回复的请求失败。因此等待30s,保证所有的请求都能成功收到回复。
同样选择某北京机房,创建2核4G独享虚拟机,进行性能测试结果如下表2:
表2
4.3 滚动更新/发布
除了扩容缩容,弹性伸缩还支持滚动更新以及滚动发布功能。当用户在线上的业务需要更新套餐或者镜像时,可以使用滚动更新/发布功能,自动替换当前实例。
这种功能与容器的滚动发布类似,但OpenStack目前暂不支持类似功能。弹性伸缩通过扩容与缩容的交替进行,实现了该功能。滚动更新默认是扩容一台缩容一台进行更新的。好处是最大可能地保证资源充足完成更新,缺点是更新速度较慢。为了提高更新速度,可设置可变步长,步长取代滚动更新的最大值的一定比率以及10的最小值。提高步长的好处是能够加速更新,缺点是可能会因为资源不足导致更新失败。
同上述测试方案,仍然在北京机房以2核4G独享性实例进行滚动更新,测试结果如下表3:
表3
5.稳定性优化
5.1 版本迭代
OpenStack原生支持弹性伸缩,Heat组件本身支持除虚拟机外的多种虚拟化资源的弹性伸缩。因此本项目开始采用的架构是首先对接Heat组件,再由Heat操作Nova以及其它OpenStack组件实现资源的扩缩。
Heat组件也存在一定的缺点,主要在于它并不支持指定对象缩容,与OpenStack其他的组件交互不足,造成扩缩容不稳定的问题。考虑到弹性伸缩项目主要功能就扩缩容虚拟机,因此将架构改为直接对接Nova组件创建或销毁实例。这种方式可以更灵活地管理实例,减少了Heat组件的维护,降低了运维的成本。
5.2 高可用方案
弹性伸缩的成功率直接取决于资源是否充足,对于资源不足或者实例创建失败的极端情况,服务需要为用户提供几种高可用可替代方案,加以选择,从而极大地提高扩缩容的成功率。具体方案如下:
(1)在同机房同集群下采用其他套餐进行替代(仅适用于资源不足情况)
在资源不足的情况下,可以使用共享型套餐与独享型套餐相互转换,可以使用大量低配套餐代替高配套餐,从而最大可能地在原集群环境下创建实例。
(2)在同机房同集群下采用其他网络模式进行替代(仅适用于实例创建失败情况)
在实例创建失败的情况下,可以选择VLAN网络与VXLAN网络相互转换的方式,最大可能保证在原集群环境下创建实例。
(3)在同城跨集群/跨机房下采用相同套餐创建实例
对于扩容异常情况,可以采用在同城不同集群或者同城不同机房的OpenStack中创建相同套餐的实例,保证顺利扩容。
(4)跨城采用相同套餐创建实例
对于扩容异常情况,可以采用在跨城OpenStack下创建相同套餐的实例,保证顺利扩容。由于跨城实例会出现网络延迟,对于时延敏感的用户则不建议采用这种方案。
(5)扩容其他种类的虚拟化资源进行替代
对于极端特殊情况,例如大量OpenStack集群出现异常,可以选择扩容裸金属,同城Kubevirt或者从其他云厂商扩容实例等方案,保证弹性伸缩的顺利进行。
5.3 巡检与统计
为了提前感知弹性伸缩服务的稳定性,弹性伸缩服务提供自动巡检机器人,周期性、随机性地模拟伸缩活动,提早发现并报告弹性伸缩服务异常情况。机器人也同时会统计机房与集群各个套餐的余量、弹性伸缩的峰谷量等指标,帮助运维者及早感知资源不足的情况,来补充资源。
6.展望
当前弹性伸缩进行扩缩容的方式,采用的是create/force-delete。其实对于OpenStack虚拟机,可采用shelve/unshelve方式,来代替create/force-delete方式,实现性能优化。
shelve/unshelve方式的优点:shelve操作保留实例的volume,但是释放cpu/mem等资源,unshelve则是迅速将实例恢复原样的操作。shelve/unshelve替代create/force-delete的好处在于,可节省后续LVS挂载/卸载,RDS以及其他服务加白的时间,从而加速弹性伸缩服务的整体流程。
以上就是本篇文章分享的全部内容,欢迎留言板评论交流~
以往文章精选:
关注“360智汇云”👆,了解更多前沿云服务技术