OpenStack云计算平台故障处理能力介绍




概述

网易私有云平台上线近3年来,绝大部分物理节点和云主机都是正常运行的,

$ uptime    # 宿主机运行时长
 16:42:45 up 761 days

$ ll /xx/nova/instances/instance-000000e9/libvirt.xml   # 虚拟机创建时间
-rw-r--r-- 1 nova nova 1.7K Dec 13  2012 /data/nova/instances/instance-000000e9/libvirt.xml

但也有极个别的物理节点和云主机出现一些软硬件故障,例如:

  1. broadcom网卡固件与3.10内核不兼容问题
  2. raid卡故障等导致了一些计算节点出现故障
  3. 网络收发包过程的内核除零bug
  4. 还有一些云主机级别的故障,如系统盘损坏、只读等

要修复这些故障,我们有如下一些技术手段或者故障处理流程,例如针对上述几种故障的解决方案:

  1. 更换Intel网卡
  2. 找服务器供应商排除故障原因并解决
  3. 打内核补丁进行修复
  4. 云主机级别的故障,我们有很多自动化处理方法,下面会详细介绍

因此我们可以保障客户的云主机快速恢复正常,甚至做到故障处理过程用户无感知(也可以称之为“无痛故障处理”)。

物理节点故障处理

云平台中的物理节点大致可分为控制节点、计算节点、网络节点、存储节点,其中控制节点已经实现主主模式的高可用,单台节点故障对云平台没有影响,网络节点目前实现了主备模式的高可用,故障后会导致网络瞬断,为了解决这一问题,网络组相关同事也在开发主主模式的高可用网络节点,届时单台网络节点故障也不会导致断网。

计算节点高可用部署,目前相关的技术还够成熟,不能或者很难实现一台云主机运行在两台计算节点上,举例说明实现方案:

  1. 比如把多台计算节点虚拟成一台计算节点,也就是“多虚一”,化零为整,然后虚拟机无感知的运行在这个“聚合”后的计算节点上,“多虚一”的技术会保证单台计算节点故障,不会影响上面的虚拟机的运行,这种技术软件方案还不够成熟,一般都是采用硬件的冗余容错方案,但是成本太高
  2. 或者实现虚拟机的fault tolerance(FT)容灾,大概意思是,一台虚拟机的热备模式,包括cpu、内存、网络连接的热备,磁盘是共享存储的不需要热备,其实也就是两台虚拟机,分别运行在两台计算节点上,但是两台虚拟机之间是热备的,一台作为主机、另一台是备机,一旦主机挂掉,备机立刻成为主机继续运行,并且所有任务不受影响。这一技术目前只有VMware实现了商用,但是虚拟机的性能肯定大打折扣,只有普通虚拟机的30%~50%,实际云平台中极少应用

综上所述,目前还没办法做到计算节点的高可用,或者说云主机的主主高可用,因此一旦计算节点故障,其上面的云主机必然会停服甚至不可恢复,一般场景和具体后果举例如下:

  1. 硬件故障(非硬盘)并导致节点停机,一般可通过更换硬件来恢复,云主机会停服一段时间,具体时长依赖硬件更换时间,一般为1个小时左右
  2. 硬件故障(云主机本地存储硬盘损坏,数据丢失)并导致节点停机,一般云主机不可恢复,需要在其他计算节点重新创建或者执行宕机恢复操作(具体操作流程后面会介绍)
  3. 硬件故障但是尚未导致节点停机,可以通过迁移云主机来实现故障的短时间停服或者不停服
  4. 软件故障与硬件故障类似,也分为节点停机、不停机两类,软件导致的停机一般重启即可修复,停机时间较短,一般10分钟左右(有时为了定位软件bug会安装kdump等故障现场转储工具,会拉长重启时间到30分钟左右),不停机的软件故障也可以通过迁移云主机来减少停服时间,软件故障一般都是通过解决软件bug来修复

存储节点是跟计算节点共用的,需要说明的是这里提到的存储节点是云硬盘使用的后端存储节点,而不是云主机使用的本地实例存储盘,云硬盘支持多副本,并且多个副本必定不在一台存储节点上,因此可以实现故障的不停服,即使节点下线,也可以在其他节点同步新副本,继续保证云硬盘的多副本数据高可用高可靠。

从上面的分析可以看出,计算节点的故障是常见而且无法通过高可用手段避免的,因此后面着重讨论计算节点和云主机级别的故障处理手段。

云主机快照恢复

使用前提:有云主机系统盘的快照,并且故障云主机系统盘内没有重要数据,可以丢弃(数据放在云硬盘上即可实现)

适用场景:

  1. 计算节点故障且硬盘故障导致数据无法恢复
  2. 云主机系统盘故障导致数据无法恢复(此类故障更建议使用云主机重建功能来处理)

使用方法:

  1. 产品管理员删除故障云主机,并注意保留云主机的附属资源(如各类IP、云硬盘等)不要被其他云主机占用
  2. 通过快照恢复出新的云主机(创建时指定上面保留的各类IP,以保证IP地址的不变,防止IP变化导致的各种不便,如果IP地址所在的端口已经删除,可以尽快创建新的端口并指定所需的IP地址)
  3. 挂载保留的云硬盘
  4. 简单配置云主机内的服务

云主机迁移

又可分为离线、在线两种迁移方式,其中离线是指云主机在迁移前需要关机,等迁移完毕后再开机,而在线迁移则几乎不会导致云主机内部服务停服。

需要说明的是,我们的云平台暂时还不支持在线迁移,原因是云硬盘不支持,并且挂载有云硬盘的云主机也无法在线迁移,如果采用携带本地实例存储盘方式进行云主机的在线迁移,会拉长云主机停服时间,用户体验较差,因此暂未对外提供。云硬盘组相关同事也在积极的开发相关功能。

离线迁移使用前提:

  1. 云主机可停服
  2. 云主机所在计算节点还可以提供服务

适用场景:

  1. 计算节点发生故障但尚未停服,并且实例存储盘数据正常
  2. 云主机系统盘正常

使用方法:

  1. 平台管理员执行“离线迁移”云主机操作
  2. 迁移完毕云主机启动后可能需要手工启动云主机内的服务(没有配置服务自动启动情况)

云主机重建

使用前提:

  1. 云主机所在计算节点还可以提供服务
  2. 云主机系统盘故障且无法修复

适用场景:

  1. 云主机系统盘故障,云主机系统盘中数据可以丢失,云主机相关资源不想变动,比如UUID、IP、云硬盘等

使用方法:

  1. 产品管理员执行云主机“重建”操作,并指定镜像或快照进行重建
  2. 重建完毕云主机的UUID、各类IP、挂载的云硬盘均不发生变化,只有系统盘会被替换为指定的镜像或快照
  3. 启动后可能需要部署云主机内的服务(没有从快照重建情况),云硬盘可能需要重新挂载到云主机内部的相关目录

注:从云硬盘启动的云主机也支持重建功能,但重建之前的云硬盘系统盘在重建过程中会被删除

云主机宕机恢复

使用前提:

  1. 云主机所在计算节点无法提供服务
  2. 云主机系统盘中数据可以丢失(从本地实例存储盘启动情况)

适用场景:

  1. 云主机所在计算节点故障,云主机系统盘中数据可以丢失(从本地实例存储盘启动情况),云主机相关资源不想变动,比如UUID、IP、云硬盘等
  2. 建议在计算节点出现不可恢复故障场景使用(比如硬盘数据丢失)

使用方法:

  1. 平台管理员执行云主机“宕机恢复”操作
  2. 恢复完毕云主机的UUID、各类IP、挂载的云硬盘均不发生变化,只有系统盘会被替换为指定的镜像或快照
  3. 启动后可能需要部署云主机内的服务(没有从快照重建情况),云硬盘可能需要重新挂载到云主机内部的相关目录

注:本功能支持从云硬盘启动的云主机,此类云主机宕机恢复后系统盘数据不会变化

云主机系统盘修复

使用前提:

  1. 云主机所在计算节点正常提供服务
  2. 云主机系统盘故障
  3. 云主机从本地实例存储盘启动

适用场景:

  1. 云主机系统盘损坏,并且想尝试修复来恢复其中的数据

使用方法:

  1. 平台管理员执行云主机“修复”操作
  2. 执行完毕后,云主机会使用原始基础镜像重新启动云主机,并把损坏的系统盘(原系统盘)作为数据盘挂载到云主机上供修复(一般为/dev/vdb),可以使用fsck等工具修复,也可以mount后备份数据
  3. 无论修复是否成功,平台管理员都要执行云主机“解除修复”操作
  4. 修复失败可以尝试执行“重建”操作

注:本功能不支持从云硬盘启动的云主机

机房网络故障处理

单个节点的软硬件故障都比较容易处理,后果也不会很严重,最多也就是几台云主机暂时不可用,甚至不可恢复,对整个平台带来的影响很有限,或者说故障影响范围很小。

但是一旦遇到了挖掘机,整个机房的网络duang一下就与互联网隔绝了,那后果可是ganggang的,如果你的业务只部署在这一个机房,那你再牛X的的技术也干不过挖掘机,所以说我们最大的敌人是挖掘机。

当然我们也已经开始上线多机房部署,北京机房就是双机房同时服务,即使单个机房整体故障,也还有另外的机房可以提供服务。

云主机部署建议

为了预防上述故障,在部署云主机过程中,需要注意以下几点:

  1. 尽量分布到多个一级可用域
  2. 如果无法分布到多个机房,要分布到多个二级可用域
  3. 一定要使用云硬盘保存重要数据
  4. 云主机系统盘尽量使用云硬盘(本功能近期会上线)
  5. 尽量做到服务集群无单点故障,保证单台云主机故障不影响集群服务
  6. 对重要云主机打快照