概述
网易私有云平台上线近3年来，绝大部分物理节点和云主机都是正常运行的，
|
1 2 3 4 5 |
$ 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 |
但也有极个别的物理节点和云主机出现一些软硬件故障，例如：
- broadcom网卡固件与3.10内核不兼容问题
- raid卡故障等导致了一些计算节点出现故障
- 网络收发包过程的内核除零bug
- 还有一些云主机级别的故障，如系统盘损坏、只读等
要修复这些故障，我们有如下一些技术手段或者故障处理流程，例如针对上述几种故障的解决方案：
- 更换Intel网卡
- 找服务器供应商排除故障原因并解决
- 打内核补丁进行修复
- 云主机级别的故障，我们有很多自动化处理方法，下面会详细介绍
因此我们可以保障客户的云主机快速恢复正常，甚至做到故障处理过程用户无感知（也可以称之为“无痛故障处理”）。
物理节点故障处理
云平台中的物理节点大致可分为控制节点、计算节点、网络节点、存储节点，其中控制节点已经实现主主模式的高可用，单台节点故障对云平台没有影响，网络节点目前实现了主备模式的高可用，故障后会导致网络瞬断，为了解决这一问题，网络组相关同事也在开发主主模式的高可用网络节点，届时单台网络节点故障也不会导致断网。
计算节点高可用部署，目前相关的技术还够成熟，不能或者很难实现一台云主机运行在两台计算节点上，举例说明实现方案：
- 比如把多台计算节点虚拟成一台计算节点，也就是“多虚一”，化零为整，然后虚拟机无感知的运行在这个“聚合”后的计算节点上，“多虚一”的技术会保证单台计算节点故障，不会影响上面的虚拟机的运行，这种技术软件方案还不够成熟，一般都是采用硬件的冗余容错方案，但是成本太高
- 或者实现虚拟机的fault tolerance（FT）容灾，大概意思是，一台虚拟机的热备模式，包括cpu、内存、网络连接的热备，磁盘是共享存储的不需要热备，其实也就是两台虚拟机，分别运行在两台计算节点上，但是两台虚拟机之间是热备的，一台作为主机、另一台是备机，一旦主机挂掉，备机立刻成为主机继续运行，并且所有任务不受影响。这一技术目前只有VMware实现了商用，但是虚拟机的性能肯定大打折扣，只有普通虚拟机的30%~50%，实际云平台中极少应用
综上所述，目前还没办法做到计算节点的高可用，或者说云主机的主主高可用，因此一旦计算节点故障，其上面的云主机必然会停服甚至不可恢复，一般场景和具体后果举例如下：
- 硬件故障（非硬盘）并导致节点停机，一般可通过更换硬件来恢复，云主机会停服一段时间，具体时长依赖硬件更换时间，一般为1个小时左右
- 硬件故障（云主机本地存储硬盘损坏，数据丢失）并导致节点停机，一般云主机不可恢复，需要在其他计算节点重新创建或者执行宕机恢复操作（具体操作流程后面会介绍）
- 硬件故障但是尚未导致节点停机，可以通过迁移云主机来实现故障的短时间停服或者不停服
- 软件故障与硬件故障类似，也分为节点停机、不停机两类，软件导致的停机一般重启即可修复，停机时间较短，一般10分钟左右（有时为了定位软件bug会安装kdump等故障现场转储工具，会拉长重启时间到30分钟左右），不停机的软件故障也可以通过迁移云主机来减少停服时间，软件故障一般都是通过解决软件bug来修复
存储节点是跟计算节点共用的，需要说明的是这里提到的存储节点是云硬盘使用的后端存储节点，而不是云主机使用的本地实例存储盘，云硬盘支持多副本，并且多个副本必定不在一台存储节点上，因此可以实现故障的不停服，即使节点下线，也可以在其他节点同步新副本，继续保证云硬盘的多副本数据高可用高可靠。
从上面的分析可以看出，计算节点的故障是常见而且无法通过高可用手段避免的，因此后面着重讨论计算节点和云主机级别的故障处理手段。
云主机快照恢复
使用前提：有云主机系统盘的快照，并且故障云主机系统盘内没有重要数据，可以丢弃（数据放在云硬盘上即可实现）
适用场景：
- 计算节点故障且硬盘故障导致数据无法恢复
- 云主机系统盘故障导致数据无法恢复（此类故障更建议使用云主机重建功能来处理）
使用方法：
- 产品管理员删除故障云主机，并注意保留云主机的附属资源（如各类IP、云硬盘等）不要被其他云主机占用
- 通过快照恢复出新的云主机（创建时指定上面保留的各类IP，以保证IP地址的不变，防止IP变化导致的各种不便，如果IP地址所在的端口已经删除，可以尽快创建新的端口并指定所需的IP地址）
- 挂载保留的云硬盘
- 简单配置云主机内的服务
云主机迁移
又可分为离线、在线两种迁移方式，其中离线是指云主机在迁移前需要关机，等迁移完毕后再开机，而在线迁移则几乎不会导致云主机内部服务停服。
需要说明的是，我们的云平台暂时还不支持在线迁移，原因是云硬盘不支持，并且挂载有云硬盘的云主机也无法在线迁移，如果采用携带本地实例存储盘方式进行云主机的在线迁移，会拉长云主机停服时间，用户体验较差，因此暂未对外提供。云硬盘组相关同事也在积极的开发相关功能。
离线迁移使用前提：
- 云主机可停服
- 云主机所在计算节点还可以提供服务
适用场景：
- 计算节点发生故障但尚未停服，并且实例存储盘数据正常
- 云主机系统盘正常
使用方法：
- 平台管理员执行“离线迁移”云主机操作
- 迁移完毕云主机启动后可能需要手工启动云主机内的服务（没有配置服务自动启动情况）
云主机重建
使用前提：
- 云主机所在计算节点还可以提供服务
- 云主机系统盘故障且无法修复
适用场景：
- 云主机系统盘故障，云主机系统盘中数据可以丢失，云主机相关资源不想变动，比如UUID、IP、云硬盘等
使用方法：
- 产品管理员执行云主机“重建”操作，并指定镜像或快照进行重建
- 重建完毕云主机的UUID、各类IP、挂载的云硬盘均不发生变化，只有系统盘会被替换为指定的镜像或快照
- 启动后可能需要部署云主机内的服务（没有从快照重建情况），云硬盘可能需要重新挂载到云主机内部的相关目录
注：从云硬盘启动的云主机也支持重建功能，但重建之前的云硬盘系统盘在重建过程中会被删除
云主机宕机恢复
使用前提：
- 云主机所在计算节点无法提供服务
- 云主机系统盘中数据可以丢失（从本地实例存储盘启动情况）
适用场景：
- 云主机所在计算节点故障，云主机系统盘中数据可以丢失（从本地实例存储盘启动情况），云主机相关资源不想变动，比如UUID、IP、云硬盘等
- 建议在计算节点出现不可恢复故障场景使用（比如硬盘数据丢失）
使用方法：
- 平台管理员执行云主机“宕机恢复”操作
- 恢复完毕云主机的UUID、各类IP、挂载的云硬盘均不发生变化，只有系统盘会被替换为指定的镜像或快照
- 启动后可能需要部署云主机内的服务（没有从快照重建情况），云硬盘可能需要重新挂载到云主机内部的相关目录
注：本功能支持从云硬盘启动的云主机，此类云主机宕机恢复后系统盘数据不会变化
云主机系统盘修复
使用前提：
- 云主机所在计算节点正常提供服务
- 云主机系统盘故障
- 云主机从本地实例存储盘启动
适用场景：
- 云主机系统盘损坏，并且想尝试修复来恢复其中的数据
使用方法：
- 平台管理员执行云主机“修复”操作
- 执行完毕后，云主机会使用原始基础镜像重新启动云主机，并把损坏的系统盘（原系统盘）作为数据盘挂载到云主机上供修复（一般为/dev/vdb）,可以使用fsck等工具修复，也可以mount后备份数据
- 无论修复是否成功，平台管理员都要执行云主机“解除修复”操作
- 修复失败可以尝试执行“重建”操作
注：本功能不支持从云硬盘启动的云主机
机房网络故障处理
单个节点的软硬件故障都比较容易处理，后果也不会很严重，最多也就是几台云主机暂时不可用，甚至不可恢复，对整个平台带来的影响很有限，或者说故障影响范围很小。
但是一旦遇到了挖掘机，整个机房的网络duang一下就与互联网隔绝了，那后果可是ganggang的，如果你的业务只部署在这一个机房，那你再牛X的的技术也干不过挖掘机，所以说我们最大的敌人是挖掘机。
当然我们也已经开始上线多机房部署，北京机房就是双机房同时服务，即使单个机房整体故障，也还有另外的机房可以提供服务。
云主机部署建议
为了预防上述故障，在部署云主机过程中，需要注意以下几点：
- 尽量分布到多个一级可用域
- 如果无法分布到多个机房，要分布到多个二级可用域
- 一定要使用云硬盘保存重要数据
- 云主机系统盘尽量使用云硬盘（本功能近期会上线）
- 尽量做到服务集群无单点故障，保证单台云主机故障不影响集群服务
- 对重要云主机打快照
