云监控发布新feature,打通事件中心和函数服务,可以实现秒级故障恢复。
试想这样一个场景:
当ecs宕机时,在几秒内实现eip自动迁移至另一个健康的ecs实例,快速故障恢复,避免损失。
如何做到?
云监控之前推出了事件中心,定位于,将阿里云上发生的对用户有影响的事件,集中起来,统一展示,统一管理;同时,__可以实现在云产品异常事件发生的第一时间,对用户广播通知,同时打通了事件与函数服务,在事件发生时触发函数计算的执行,快速实现诸如eip迁移,slb带宽扩容,slb摘掉故障服务器等操作,以实现故障的快速恢复__。
架构示意图
在这个架构中,云产品提供各类事件,使得整个场景能够有米下锅;云监控在这个链路中,起到了枢纽的作用,有效串联了各云产品的事件和函数计算,再通过函数计算串联到各云产品的管控API,使云产品之间可以有效的联动。
故障发生>云产品事件>云监控广播>触发函数计算>云产品管控api>故障恢复
为什么是事件?
事件具有低延迟,高可靠的特性,相对metric指标来说。
关键组件:云产品异常事件和运维Api
ecs作为先锋产品,率先开放了12个对于用户极其重要的运维事件,使得基于事件的自动故障恢复可行。8月份,ecs还将继续开放更多的事件。
- ECS目前开放的系统事件
事件名称 | 事件含义 | 状态 | 事件等级 |
---|---|---|---|
Instance:InstanceFailure.Reboot | 因实例错误实例重启开始 | Executing | CRITICAL |
Instance:InstanceFailure.Reboot | 因实例错误实例重启结束 | Executed | CRITICAL |
Instance:SystemFailure.Reboot | 因系统错误实例重启开始 | Executing | CRITICAL |
Instance:SystemFailure.Reboot | 因系统错误实例重启结束 | Executed | CRITICAL |
Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启 | Scheduled | CRITICAL |
Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已规避 | Avoided | CRITICAL |
Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启执行中 | Executing | CRITICAL |
Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已完成 | Executed | CRITICAL |
Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已取消 | Canceled | CRITICAL |
Instance:SystemMaintenance.Reboot | 因系统维护实例计划重启已失败 | Failed | CRITICAL |
Disk:Stalled | 磁盘性能受到严重影响开始 | Executing | CRITICAL |
Disk:Stalled | 磁盘性能受到严重影响结束 | Executed | CRITICAL |
更多事件详情:https://help.aliyun.com/document_detail/66940.html
关键组件:云监控
云监控是阿里云的核心基础服务之一,服务了近百万企业用户。
云监控产品的核心目标是,帮助企业用户提升服务可用率。降低MTTR-平均故障时间。
关键组件:函数计算
阿里云函数计算(Function Compute)是一个事件驱动的全托管计算服务。通过函数计算,您无需管理服务器等基础设施,只需编写代码并上传。函数计算会为您准备好计算资源,以弹性、可靠的方式运行您的代码。更棒的是,您只需要为代码实际运行消耗的资源付费 - 代码未运行则不产生费用。
关于可用率
可用率的定义(百度百科):
计算机有效性的表示,它是在一段相当长的时间内, 计算机的可用时间与故障时间,维修时间及可用时间总和比。
简单理解就是:MTTR(平均故障恢复时间)/MTBF(平均故障间隔)的比值。
如何有效提升可用率
如上所示,提升可用率,一是降低MTTR,二是提升MTBF。降低MTBF和提升MTTR的效果一样,但是代价却很不一样。尤其是在云时代,单点的错误非常常见,故障难以避免。一方面用户需要自己设计高可用架构,提供适当的容错,另一方面,也需要快速的故障发现和快速的故障恢复。
如何降低MTTR
1,及时的发现故障,并广播通知
2,在可控范围内,快速的自动化的恢复故障,
通过事件中心的广播,快速发现故障,并广播给用户
云监控作为阿里云的基础服务,推出了事件中心。 产品定位于,将阿里云上发生的对用户有影响的事件,集中起来,统一展示,统一管理,让用户可以方便的了解这些事件,这些事件通常都是对用户有比较严重影响的事件,比如:ecs宕机,hang机,rds主备切换,slb证书过期,slb丢包等。事件发生后,可以在秒级内对外广播通知。让用户及时的了解故障发生,以便作出迅速反应。
故障自动恢复的风险和可行性
自动化的故障恢复通常伴随着相当高的风险,要非常谨慎;但是,通常大部分的故障都有相似性,符合28原则,80%的故障是由于20%的常原因导致, 对于这20%的高度一致的故障,迅速采集自动化的恢复措施,将有助于帮助用户快速的恢复故障。
当然,自定义的可编程的故障恢复将有助于用户定义自己的healing action。基于阿里云的函数计算服务,可以轻松实现这一灵活性。同时,函数计算服务,也会提供诸多标准化的模板,比如,slb带宽调整,eip迁移等,用户只要套用,轻点几下鼠标,即可以轻松实现。完成以下场景的自动化运维:ecs宕机时,几秒内完成eip迁移到另一台ecs;在业务高峰时,迅速的调整带宽,以适应业务的需求。
以上场景,基于'云产品事件>云监控>函数计算'这个链路,可以秒级的完成,从而快速的恢复故障,从而提升用户服务的可用率。
事件中心效果图
说了半天,看一下事件中心的真面目
未来规划:
未来,不只是系统事件,业务自己的异常事件, 也可以支持触发函数计算,这将大大拓展函数服务的价值边界,带
来更多的可能性。
这一切,都是为了更好的可用性。
注:该功能已经灰度上线,感兴趣的同学,可以申请公测。钉钉扫描二维码: