云计算节点故障自动化运维服务设计

此文已由作者王盼授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验~

现状

• 计算节点发生磁盘损坏等数据无法恢复的异常时，节点上的云主机系统盘无法恢复，导致云主机只能被清理重建

• 计算节点宕机但磁盘数据可用时，重启即可恢复所有云主机的运行

• 计算节点多次宕机（或一段时间内频繁宕机），则需要迁移所有云主机或者直接清理重建，云硬盘需要迁移到其他cinder-volume存储服务节点

一般来说重建过程比较耗时，并且云主机数据盘数据会全部丢失；另外采用本地file镜像启动的云主机离线或者在线迁移比较耗时并大类占用物理机硬盘和网络IO，会进一步加重计算节点负载，增大宕机可能性，实际情况下迁移操作的可执行性大打折扣。

另外有一些对我们自动化恢复流程有利的功能或者设备已经逐步上线到新建机房，因此可以考虑在这些机房实施相关的自动化恢复方案。比如义桥机房服务器已经全部配备远程管理卡，并且基于ceph存储作为系统盘+云硬盘的云主机也已经上线到该机房，这是我们实施该方案的基础。基于ceph存储后端的云主机在异常恢复过程中，没有数据的拷贝，不会占用硬盘和网络IO，因此恢复速度较快，可以做到几秒内在正常节点恢复运行（不包含云主机操作系统启动时间），相比现在的直接下线无法恢复或者数小时的更换硬件耗时，是对云主机SLA相当大的提升。

需求

• 保证异常节点上所有被标记为需要恢复的云主机、云硬盘资源被正确恢复（处理过程中本进程退出其他进程可以继续）

• 把所有被处理的资源记录在案（资源id、所在节点、处理时间、调用nova/cinder服务的request-id、处理状态等）

• 保证异常处理服务本身的高可用

场景

用户创建云主机

用户创建云主机时指定宕机恢复策略，目前有三种：

• null：不做处理，节点下线之后残留在数据库

• 恢复：在其他正常节点恢复重建

• 删除：直接删除

节点首次异常

首次异常之后要尝试重启节点（上面的云主机、云硬盘不做特殊处理），但节点已自动重启的除外，并要分析异常原因，找到原因并可以修复的软硬件异常，则不需要记录到节点异常次数中，否则需要记录在案，用做下次异常时的处理依据，记录前未找到原因，但事后找到的，需要从异常记录中删除该次记录。

节点多次异常

多次异常节点需要做下线处理（多次异常包含首次异常后重启失败的情况），节点上的云主机需要根据创建时指定的宕机处理策略来执行相应的操作，云硬盘则一律迁移到其他正常服务的cinder-volume节点（并不会实际的迁移数据，对用户使用没有任何影响），处理过的云主机、云硬盘要记录在案，便于事后查验。

方案

本方案只是初步想法，还需要在开发过程中继续完善，尤其是服务高可用部分，以及与哨兵系统的交互部分，会对本服务的设计造成较大影响。

依赖

• 被恢复的云主机需使用ceph启动盘+ceph云硬盘

• nova、cinder支持把服务强制设置为down状态（cinder可选，nova必须支持，否则需要等待超时变成down才可以执行云主机的宕机恢复操作）

• 哨兵系统异常主动通知机制（建议），或者哨兵系统提供api供我们轮询节点状态

• 哨兵系统提供接口可强制重启和下电节点

后续

• L3节点宕机自动化处理流程

• 动态资源调度功能：可根据节点负载动态均衡云主机分布

• 节电省成本：可将空闲节点云主机迁移之后下电节点

云硬盘是网易云提供多种硬件介质的块存储设备，用户可以根据实际生产环境，灵活选择云硬盘类型和规格大小，弹性地创建、删除、挂载、卸载、扩容云硬盘。

更多网易技术、产品、运营经验分享请点击。

相关文章：
【推荐】 巧用Scrum与Kanban
【推荐】 关于评审--从思想到落地
【推荐】 微服务化的数据库设计与读写分离