虚拟机疏散本质上是“先停止、再重建”，秒级不停机做不到；OpenStack虚拟机疏散业务不中断的实现路径，是共享存储扛住数据面、预留资源扛住调度面、预案扛住操作面，三者缺一不可。
一个计算节点宕掉,上面几十台虚拟机要像住客一样换楼，这栋楼是租的，换楼时钥匙、家具、门锁都得跟着走，住户还不能察觉换过地方，听起来苛刻，但生产环境里的确有人做得到，差别不在运气，而在基础设施设计。
虚拟机疏散会中断业务吗先对比疏散与热迁移
疏散和热迁移的区别,常常被混为一谈，实际上两者走的是完全不同的技术路线。
热迁移（Live Migration）是两台宿主机上的QEMU进程同时运行，通过内存预拷贝把运行状态一点点同步过去，最后切换网络路径，整个过程业务进程无感知，连接不断，事务不丢，这是真正意义上的“不中断”。
疏散（Evacuation）的前提是原节点已经挂了，nova没办法从宕机节点上拷任何东西，只能在目标节点把实例重新创建出来，实例的CPU状态、内存内容全部丢失，应用相当于一次冷启动。
所以评判OpenStack虚拟机疏散业务不中断的标准,不是“用户无感知”，而是三条：磁盘数据不丢、网络身份不变、恢复时间可控，满足这三条，业务虽然断了一下，但能在较短时间内自动回来，客户感受到的只是应用重启了一次。
多数情况下,一个节点故障后，疏散能否在几十秒到数分钟内完成，取决于目标节点是否有足够资源、共享存储是否在线、以及nova服务自身的健康程度，华北某金融云的实践是，在故障演练中批量疏散一批实例，从触发到业务端口恢复，时间窗口压到了应用探活的容忍范围之内，能做到这一点的前提，恰恰是下面要说的共享存储。
OpenStack虚拟机疏散业务不中断的第一前提：共享存储
没有共享存储,谈疏散业务不中断就是空话。
本地盘环境下,虚拟机的系统盘和数据盘都写在宕机节点自己的磁盘上，节点一宕，nova能捞回来的只有放在数据库里的元数据，磁盘上的文件全部留在原地，后续的疏散动作听起来像搬家，实际上是在新机器上重新买了套家具，原来的东西一件都带不过来。
换成共
享存储之后,整个格局就变了，虚拟机的磁盘文件放在Ceph、SAN或分布式存储上，任何一台计算节点都能挂载同一份数据，原节点宕机，磁盘没有丢，nova只需要在新节点上把实例拉起来，挂载同一块后端卷，数据自然就在那里。
共享存储能发挥作用的另一层,是给网络身份兜底，实例的端口、固定IP、安全组规则都记录在Neutron数据库里，新节点使用同一个端口信息重建实例，浮动IP依然指向这台虚拟机，用户通过原来的IP访问，应用层的数据库连接池重新建立即可，不用改任何网络配置。
行业共识认为,生产环境如果连共享存储都做不到，就别在openstack层面谈单节点故障的业务连续性，那是应用层的事。
疏散实操：怎么把中断窗口压到最短
疏散动作本身并不复杂,复杂的是操作顺序和细节，多数生产事故不是疏散命令执行失败，而是疏散前没检查目标节点资源、疏散后没验证业务状态。
疏散前先做三件事：
- 确认故障节点已隔离，用
nova service-disable把宕机节点设为禁用，避免调度器继续往里发新实例。 - 确认目标节点容量，检查剩余CPU、内存和磁盘，重点看是否有同CPU型号的宿主机，否则某些依赖CPU指令集的业务可能起不来。
- 确认共享存储在线，Ceph集群的health状态、NFS挂载点是否可写，这些检查前置做完，比疏散到一半再排查要省事得多。
疏散命令上,新版OpenStack的 nova evacuate 基本满足需求，如果原节点在nova眼里还是up状态，需要加 --force 参数跳过状态检查，指定目标节点时用：
nova evacuate <server-id> <target-host> --force
对一批实例做疏散时,按业务优先级分批处理，先拉数据库或消息队列这类关键节点，再处理普通应用，批量操作的常见姿势是循环读取实例列表，逐台调用evacuate，每台间隔几秒，避免短时间内对neutron和cinder形成突发压力。
疏散进行中,运维人员盯两个地方：调度器有没有正确分配新主机，实例有没有进入ERROR状态，ERROR状态大概率是目标节点资源不足或镜像下载失败，需要马上换一台目标节点重试。
疏散完成后逐台验证：
nova show确认状态为ACTIVE，host为新的目标节点- 从外部访问浮动IP,确认端口开放
- 登录实例查看关键服务进程是否正常拉起
- 检查持久化数据文件的时间戳,确认与故障前一致
西南某政务云在做节点故障切换演练时,就是靠这套流程把上百台实例有条不紊地搬完，整个过程没有丢数据，也几乎没有触发上层告警。
没有共享存储时，如何兜底业务不中断
本地盘环境确实存在,而且不少规模不大的私有云为了省成本，一直没上共享存储，这类环境下，OpenStack虚拟机疏散业务不中断的思路要换一下：不依赖nova的疏散，靠应用层自身的高可用能力。
具体有几种做法：
- 应用层多副本，数据库做主从复制，消息队列用多副本分组，虚拟机本身宕了没关系，有副本在别的节点上继续服务，客户端连接到VIP，VIP由Keepalived自动漂移到存活副本。
- 整机磁盘镜像，利用qemu的磁盘镜像能力，定期把本地盘数据同步到远端热备机，故障发生时手动或脚本触发漂移，业务中断窗口取决于同步间隔。
- 双活负载均衡，业务无状态化改造，前端加负载均衡器，后端两个节点同时运行，任何一台故障，流量自动切到另一台，虚拟机疏散只是事后把故障节点恢复过来。
这三种方案都不能靠OpenStack本身完成,但换个角度看，它们比疏散更可靠，因为疏散本质上是一次冷启动，应用会不会在启动后自愈，取决于应用自身的健壮程度，而多副本架构从一开始就不允许单点故障影响业务。
本地盘环境中,疏散的意义从“业务保护”退化为“基础设施自我修复”，虚拟机在新节点上重建，数据可能回到故障前某个时间点，但基础设施总算恢复了完整状态，需要明白的是，多一份副本就多一份成本，这个钱花在虚机上还是花在存储上，直接决定了故障时的恢复速度。
疏散前的资源预留与调度兜底
共享存储保住了数据,调度器负责把实例送到安全的地方，计算节点满了，疏散再快也进不去，生产环境一个常见失误是集群算力已经被业务吃满，没有任何富余，故障一来只能等新机器上线。
OpenStack没有原生的资源预留功能,但可以通过两个手段实现：
建立专门的疏散目标主机聚合，把几台不承载常规业务的机器放进单独的aggregate，通过flavor的extra_spec限制只有特定flavor的实例能调度到这些机器上，或者干脆用 aggregate_instance_extra_specs 让常规调度绕过它们，真正发生故障时，手动指定这些机器作为疏散目的地。
维持一定比例的空闲算力，行业惯例是集群规模保留两成左右的余量，用于应付节点故障或发版扩容，这些空闲算力平时看着浪费，关键时候就是业务不中断的底气。
调度层面还有一个细节：确认cinder和nova的多后端配置正常，共享存储如果只有一个后端，存储本身反而成了单点；如果有多套后端，疏散时尽量把实例调回原存储池所在的主机，避免跨存储池迁移。
人算不如天算,预案要提前写，把故障响应步骤沉淀成脚本，比故障发生时再翻文档高效得多，华北某互联网公司的做法值得参考：他们为每个可用区写了一套疏散剧本，包含资源检查、批量疏散、状态验证三个环节，平时月度巡检跑一遍，真出事时执行剧本即可。
关于虚拟机疏散的常见问题
虚拟机疏散和热迁移是一回事吗？
不一样,热迁移不中断业务，疏散几乎必然造成应用重启，疏散依赖共享存储来保住磁盘数据，而热迁移本身就具备数据同步能力，实际运维中，热迁移常用于计划内维护，疏散用于节点宕机后的紧急恢复。
疏散后实例一直卡在ERROR状态，多半是什么原因？
目标节点剩余资源不足、共享存储挂载失败、镜像在目标节点无法访问，这三类原因占了大多数，先查看 nova show 里的故障信息，定位到具体原因后再重试，不要盲目重复执行疏散命令。
没有共享存储的环境，用什么方案能让业务影响最小？
应用层做主备切换和负载均衡,是唯一可靠的路径，数据库用主从复制，前端服务做双活，让业务自己不依赖任何单台宿主机，OpenStack层面的疏散照常执行，但只是恢复基础设施能力，业务恢复交给应用集群自己决策。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/615114.html
