做OpenStack运维的人迟早会跟Nova的几十条命令打交道。控制节点挂了可以重建网络节点挂了可以恢复但计算节点上的每一台实例出了问题以后能不能救、怎么救全靠Nova这一层的操作是否熟练。我刚上手OpenStack那会儿最头疼的就是实例状态和操作命令对不上号——明明想暂停却执行了挂起明明只是关机却把实例数据弄丢了。后来把Nova的常见操作按“状态-动作”画成一张图之后整个思路才清晰起来。这篇文章就把我整理过的Nova 16种核心操作完整拆一遍顺便把每个操作背后的原理、适用场景和踩过的坑都交代清楚。无论你是刚接触OpenStack的运维新人还是已经扛着几十台计算节点的老兵这份清单都能帮你少走弯路。1. 先看全景Nova实例状态机与16种操作的关系图1.1 Nova实例的状态先认识这几个关键节点很多人用Nova的时候习惯直接敲命令根本不看实例当前处于什么状态。这就是问题所在。Nova的每个操作几乎都是“状态依赖”的实例处于ACTIVE时你能做的大部分操作到了ERROR状态就全被拒绝。想要真正理解这张操作图必须先认识几个核心状态。BUILD实例正在创建调度器刚把它交给某个计算节点libvirt正在准备磁盘、网络和CPU资源几秒到几十秒内会转到ACTIVE或ERROR。ACTIVE正常运行guest OS已经跑起来对外提供服务。这是实例一生中停留最久的状态。SHUTOFF实例被关机stop或者刚从开机状态关机。注意SHUTOFF不代表实例被删除它的磁盘文件、内存配置都还在计算节点上。PAUSED暂停虚机的CPU被冻结但内存还在物理内存里。这种状态很少见一般只在排障或临时腾资源时用。SUSPENDED挂起内存已经被写到宿主机本地磁盘虚机完全冻结CPU和内存资源全部释放。SHELVED“搁置”虚机关机后把系统盘快照上传到Glance计算节点上的本地文件会被清理实例几乎不占用计算资源。RESCUED救援模式原来的系统盘被挂成数据盘虚机改用救援镜像启动。ERROR出错了。可能是调度失败、镜像拉取失败、磁盘空间不足、网络创建失败等等一句话需要人工介入。VERIFY_RESIZE变配后的等待确认状态需要执行confirm或revert确认变更。MIGRATING迁移进行中虚机还在源节点或目标节点上运行但调度和复制流程已经启动。查看实例状态最直接的方式就是openstack server show server_id里面会显示OS-EXT-STS:vm_state和OS-EXT-STS:task_state两个字段。vm_state是稳定状态task_state是当前正在执行的操作这两个字段配合status字段一起看才能判断实例当前到底在干嘛。1.2 16种操作与状态转换对应总表我把最常见的Nova操作按照“操作目的”归成16类每一类都对应一条或一组命令。下面的表格可以当作日常速查卡来用也是整篇文章的“地图”。操作分类典型命令状态迁移效果适用场景创建实例openstack server createBUILD → ACTIVE/ERROR上线新业务、扩容删除实例openstack server delete任意状态 → 无释放资源、下线业务开机openstack server startSHUTOFF → ACTIVE恢复关机实例关机openstack server stopACTIVE → SHUTOFF计划维护、释放CPU内存软重启openstack server reboot --softACTIVE → REBOOT → ACTIVEguest OS可响应时的重启硬重启openstack server reboot --hardACTIVE → HARD_REBOOT → ACTIVE系统无响应、内核卡死暂停/恢复openstack server pause/unpauseACTIVE ↔ PAUSED短时冻结不落盘挂起/恢复openstack server suspend/resumeACTIVE ↔ SUSPENDED宿主机休眠级维护搁置/恢复openstack server shelve/unshelveACTIVE ↔ SHELVED长期释放计算资源锁定/解锁openstack server lock/unlock状态不变防止误操作创建快照openstack server image create状态不变备份、模板复刻重建openstack server rebuildACTIVE/ERROR → REBUILD → ACTIVE系统盘被搞坏时恢复救援/取消救援openstack server rescue/unrescueACTIVE ↔ RESCUED进救援系统修配置变配openstack server resizeACTIVE → VERIFY_RESIZE调整CPU/内存规格迁移openstack server migrateACTIVE/SHUTOFF → MIGRATING宿主机维护、负载均衡疏散openstack server evacuateERROR → ACTIVE计算节点故障时救命这16类操作基本覆盖了日常运维90%以上的场景。下面我会按“存亡与电源管理”“冻结类操作”“恢复与重建”“迁移与变配”“外部资源联动”五个维度逐个深入拆解。2. 实例的存亡与电源管理创建、删除、开关机、重启2.1 create与delete实例从哪来到哪去创建实例是所有操作的起点。执行openstack server create --flavor flavor --image image --network net name后Nova会先把请求交给调度器Scheduler调度器根据flavor的资源约束、AZ可用域、宿主机负载等策略选出一个合适的计算节点然后通知该节点上的nova-compute去准备虚拟化资源。底层实际操作者是libvirt它根据镜像和flavor配置生成域domain定义创建虚拟磁盘、虚拟网卡最后通过KVM/QEMU把虚机拉起来。创建实例时最容易踩的坑有三个。第一个是flavor的磁盘大小和镜像实际大小不匹配如果系统盘是qcow2稀疏文件明明看镜像只有几百MB创建后却可能膨胀到几十GB磁盘配额不足就会导致创建卡在BUILD状态。第二个是网络选择如果指定了错误的网络虚机起来后网卡一直处于DOWN状态业务根本无法访问。第三个是忘记指定keypair或密码注入方式导致创建完成后登不进去。删除实例openstack server delete远比创建看起来简单但有几个细节很容易被忽略。默认情况下删除实例会连同它的系统盘一起清理如果系统盘是临时盘ephemeral数据彻底丢失无法找回。Cinder数据卷不会自动删除除非卷创建时设置了delete_on_terminationTrue。这个属性在创建实例时指定很多运维习惯把所有数据都放到临时盘上删完才发现数据全没了这种教训我见过太多次。生产环境中删除前一定要先确认是否需要保留系统盘快照不放心的话就先做个snapshot再删。2.2 start与stop关机不等于删除很多刚接触OpenStack的人会把“关机”理解为“停止服务”但Nova里的stop操作实际是向实例发送ACPI关机信号让guest OS正常走系统关机流程。执行openstack server stop后实例的vm_state会从ACTIVE变成SHUTOFFCPU和内存资源被释放宿主机可以腾出资源给其他实例。注意这只是释放计算资源实例的磁盘文件仍然留在计算节点的/var/lib/nova/instances目录下。start操作则是在同一个计算节点上基于原有的磁盘文件重新把虚机拉起来。它比创建新实例快得多因为不需要重新准备磁盘和网络只需要启动QEMU进程加载既有磁盘即可。这里有一个很容易被误解的点关机再开机实例的IP地址会不会变正常情况下不会。因为实例的虚拟网卡信息和端口port是绑定在实例上的只要实例没被删除网卡端口就不会被释放IP也就保持不变。但有一种情况例外如果实例所在的计算节点故障你通过evacuate把实例迁移到别的节点那IP地址虽然在OpenStack层面没变但guest OS里的网络配置可能对不上需要手工调整。关机虽然简单但有个实际问题很多应用没有优雅处理ACPI关机的机制或者guest OS内的acpid服务意外退出了这时候执行stop状态会长时间停留在ACTIVE或者任务超时。解决办法是加--os-stop-hard强制关机或者到计算节点上直接执行virsh destroy instance。但virsh destroy属于“暴力断电”客人机的文件系统可能损坏用之前一定要确认业务已经停止。2.3 reboot软硬之间怎么选重启是运维用得最频繁的操作。Nova的重启分为软重启和硬重启命令分别是openstack server reboot --soft和openstack server reboot --hard。软重启的本质是让guest OS走操作系统自身的重启流程。实现上libvirt会向虚机发送ACPI reset信号内核收到信号后正常关闭所有服务、卸载文件系统、然后重新启动。整个过程和你在机器上执行reboot命令几乎一样。它适合系统还能正常响应、需要清理内存缓存或者应用状态时使用。硬重启则完全不同。它不等guest OS响应直接由hypervisor层把虚机电源切断再重新通电。QEMU进程被强制重启CPU状态重新初始化guest OS会经历一次非正常的断电-通电过程。这种模式适合guest OS完全卡死、网络不可达、软重启一直超时的情况下应急。选择软硬重启有个基本原则能软不硬。硬重启有极小概率导致文件系统损坏特别是在有大量未落盘写入的时候。我遇到过几次实例重启后起不来最后检查发现是mysql的binlog没落盘硬重启导致数据文件不一致只能做InnoDB恢复。所以如果你的实例跑的是数据库这类对一致性敏感的服务尽量先软重启软重启超时后再考虑硬重启。Nova默认的重启策略是软重启如果你确实需要硬重启记得显式加--hard参数。3. 冻结类操作暂停、挂起、搁置、锁定3.1 pause与unpause最轻量的冻结暂停pause是一个被很多人忽略但实际很有用的操作。执行openstack server pause后libvirt调用QEMU的pause命令把虚机的vCPU停止调度但整个虚机的内存仍然保留在物理内存中。实例进入PAUSED状态从guest OS的视角看就像时间被冻结了所有进程原地停滞。这种冻结非常轻量恢复也极快unpause之后虚机立刻从上次暂停的位置继续执行。它适合临时让一个高占CPU的服务让出资源或者做短时间的计算资源腾挪。比如你有几台实例在跑跑批任务白天占用大量CPU但不希望直接关机因为任务进度还在内存里这时候pause一下等夜间再恢复非常合适。但pause有一个必须注意的致命缺陷PAUSED状态不会被持久化。如果计算节点突然断电或者nova-compute服务重启宿主机上的libvirt会重新接管虚机PAUSED状态大概率会丢失虚机可能直接恢复运行也可能进入ERROR。一旦节点故障你甚至无法确定虚机现在处于什么状态。所以涉及长时间冻结优先考虑suspend而不是pause。另外pause不支持跨节点迁移它是纯粹基于本机物理内存的冻结。3.2 suspend与resume内存写到本地盘挂起suspend和暂停pause看起来很像但底层原理完全不同。执行openstack server suspend后nova-compute会调用libvirt的save操作把虚机的完整内存状态写入宿主机本地磁盘默认路径通常是/var/lib/libvirt/qemu/save/写入完成后虚机进程被终止资源完全释放。实例状态变为SUSPENDED。因为内存镜像写到了磁盘上所以suspend状态是持久的。只要宿主机磁盘没坏不管nova-compute重启多少次实例都能恢复。恢复动作openstack server resume直接读取内存镜像文件加载到内存后继续运行。恢复速度虽然比pause慢需要读盘但比reboot快得多因为磁盘状态完全不用重新初始化。suspend最适合的场景是宿主机计划内重启。比如你要对某台物理机做内核升级、换硬件、调整BIOS先把上面所有实例suspend掉等机器重启完成后再批量resume。我之前维护一批计算节点时就是用脚本批量遍历实例执行suspend节点重启后再批量resume整个过程业务中断时间只有几分钟远比一台台关系统再开系统快。使用suspend有个隐藏成本内存镜像文件占的磁盘空间约等于实例的物理内存大小。如果一台宿主机上跑了20台16GB内存的虚机同时挂起的话宿主机本地磁盘会瞬间多出320GB的占用。所以批量挂起前一定要检查宿主机磁盘余量否则挂了一半磁盘写满剩下的实例直接卡在SUSPENDING状态。3.3 shelve与unshelve数据上传Glance资源释放搁置shelve是这三种冻结方式里最“狠”的。执行openstack server shelve后Nova会把实例的系统盘做成镜像上传到Glance然后把计算节点上的实例文件清理掉虚机进程和本地磁盘全部消失只保留镜像和实例元数据。如果还执行了shelve_offload连计算节点上残留的快照文件也会被清掉实例在计算节点上的占用量接近于零。恢复搁置实例要执行openstack server unshelve。Nova会从Glance读取shelve时创建的镜像重新调度计算节点重新创建虚机。整个过程相当于用“备份镜像”重新创建了一台同名同ID的实例。shelve最大的价值在于长期释放计算资源。比如一批测试机周末没人用直接shelve掉等周一再unshelve回来能省下大量内存和CPU资源。如果测试机很多这个操作可以显著降低宿主机资源压力。但shelve有个大坑实例的临时盘ephemeral和本地数据盘不会保留。shelve时只上传系统盘临时盘的内容会丢失。如果你的应用把数据写在本地盘上shelve之后这些数据就没了。因此生产实例除非确认所有数据都已经落到Cinder卷或对象存储否则不建议shelve。另外unshelve之后实例的IP地址在网络层面会保留端口还在但guest OS的配置可能需要重新检查特别是自定义了网卡配置的镜像。3.4 lock与unlock防手滑的保险锁定lock是一个很不起眼但非常实用的操作。执行openstack server lock后实例处于LOCKED状态所有修改型操作reboot、resize、delete、stop、start、rebuild等都会被Nova拒绝只有只读操作和网络查看操作可以执行。这个操作特别适合生产环境。我见过不止一次因为误操作把线上数据库实例给删了或者重启了。在OpenStack里加上lock之后即使有人拿着管理员的OpenRC环境变量误敲了deleteAPI也会直接返回错误相当于给实例上了一道保险。解锁也很简单openstack server unlock。如果你是管理员普通用户锁定的实例你也可以用openstack server unlock --force强制解锁。但要注意lock保护的是OpenStack API层面的操作它挡不住管理员直接登录计算节点执行virsh destroy。换句话说lock是给“正常人”用的锁不是给铁了心想搞破坏的人用的。不过在常规运维流程中给核心数据库、核心业务实例加上lock就是个好习惯成本几乎为零。4. 恢复与重建类操作快照、重建、救援4.1 snapshot操作前先留后路创建快照snapshot是Nova里最值得养成的习惯之一。执行openstack server image create --name snapshot_name server会把当前实例的系统盘制作成一个镜像上传到Glance之后可以用这个镜像创建新实例也可以作为rebuild的底子。快照的底层原理对qcow2系统盘来说是一个在线镜像合并操作。libvirt会发起一个live snapshot先创建一个新的qcow2覆盖层overlay然后把当前系统的所有写入引导到新层同时后台将旧层的所有数据合并上传到Glance。这个过程对运行中的虚机影响很小业务基本无感知。但有一种情况需要注意如果你的系统盘数据量特别大比如200GB的数据库系统盘快照过程会持续很久期间磁盘IO会明显上升应用写入性能可能受到影响。为了保证快照一致性数据库类实例建议先短暂pause快照完成后再unpause。这样能避免系统盘在快照过程中有未落盘的脏页。当然pause会影响业务需要和业务方确认停机窗口。如果没有停机窗口也建议在业务低峰期做快照。快照还有一个非常常见的用途——成为“模板”。我经常通过快照把一台配置好的环境复制成多台测试机比如初始化好的Web环境、装好agent的监控环境快照比从头创建省时间得多。快照占用的存储空间和系统盘实际使用量接近存储不够的话快照很容易失败所以Glance存储的容量规划也要提前做好。4.2 rebuild保留实例身份的系统盘重置重建rebuild是Nova里最“神奇”的操作之一。执行openstack server rebuild --image image server后实例会用指定的镜像重新生成系统盘但实例的ID、IP地址、数据卷保持原样guest OS收到“系统盘被整个替换”的处理方式。rebuild的本质是Nova把实例的元数据保留重新创建一块新的系统盘使用指定的镜像然后把旧系统盘丢弃虚机用新盘重新启动。这和删除重建完全不同——删除重建会换ID、换IP而rebuild不会所以对业务感知来说更像是一次“系统重装”。很多运维会用rebuild来快速恢复被恶意篡改的系统、修复损坏的系统文件、解决启动障碍。rebuild有一个很关键的参数--preserve-ephemeral。如果实例有ephemeral盘默认情况下rebuild会把临时盘也一起清掉加上这个参数后临时盘数据会保留。但即使加了保留临时盘系统盘上所有改动也会丢失所以rebuild前确认系统盘上有没有需要保留的文件如果没有备份先做快照再rebuild。rebuild是最适合“系统盘中毒、配置全乱、内核损坏”这类场景的武器。比如某个实例被勒索软件加密了系统盘直接rebuild回镜像初始化状态比慢慢杀毒修复快得多。只要你的数据都在Cinder卷上rebuild就没什么负担。4.3 rescue进救援模式修系统救援rescue是Nova里最被低估的操作。执行openstack server rescue后Nova会把当前实例关机然后用一个指定的救援镜像默认使用实例原本的镜像启动一个“救援实例”原实例的系统盘作为数据盘挂载到救援实例上。此时原实例状态变为RESCUED你可以通过VNC或者SSH登录救援实例然后挂载原系统盘去修复里面的文件。这个场景太适合“启动不了”的实例了。比如某个实例开机直接进入紧急模式grub损坏或者关键系统服务起不来你可以rescue进去mount原盘删掉有问题的配置文件、修复fstab、重装引导然后执行openstack server unrescue原实例会恢复为ACTIVE状态并再次尝试启动。rescue的默认行为有几个细节需要注意。第一rescue后的救援实例和原实例共享同一个计算节点网卡是新建的IP会变你需要通过openstack server show查看救援实例的IP地址再去登录。第二原实例的系统盘挂载为数据盘路径通常是/dev/vdb或/dev/vdc具体可以执行lsblk查看。第三如果实例处于ERROR状态有时无法直接rescue需要先确认是否能被nova-compute识别。救援模式是我在OpenStack排障里用得最多的功能之一。很多人遇到实例启动失败第一反应是删了重建但这样会丢失IP和本地配置。其实先用rescue进去看一眼十有八九能救回来。5. 迁移与疏散类操作migrate、evacuate、resize5.1 migrate冷迁移与热迁移的取舍迁移migrate是OpenStack运维绕不开的话题。openstack server migrate默认执行冷迁移它要求实例处于SHUTOFF状态Nova会将实例的磁盘文件从源计算节点复制到目标计算节点然后在目标节点重新启动。整个过程业务是中断的但数据完整性最有保障。热迁移live migrate则完全不同命令是openstack server migrate --live target-host或者通过nova live-migration操作。热迁移基于KVM原生的live migration能力先把源节点的实例内存状态持续复制到目标节点当双方内存数据达到同步后瞬间切换网络和磁盘IO业务几乎无感知。整个过程中虚机不关机、不中断非常适合数据库、在线交易这类不能停的服务。热迁移的工作机制是QEMU通过内存预复制pre-copy流程循环迭代地把源节点虚机的内存页面复制到目标节点同时跟踪脏页直到剩余脏页足够小再执行停机拷贝stop-and-copy最后在目标节点恢复运行。如果你的实例内存写入非常频繁比如每分钟几百MB的写入脏页迭代可能永远追不上热迁移直接挂在MIGRATING状态。热迁移还有两个关键前提。第一源节点和目标节点必须能访问同一个系统盘文件最典型的就是共享存储Shared Storage比如把系统盘放在Ceph或者NFS共享目录上。没有共享存储时Nova会启用块迁移block migration把本地磁盘也一并复制过去复制大磁盘会让迁移时间变得不可控。第二网络必须互通虚机的虚拟网卡需要能在目标节点上正常挂载到同一张网桥或虚拟交换机。我做热迁移时最深的体会是迁移前一定先压测或观察实例的内存写频率。如果instance的脏页率太高热迁移很可能永远完不成这时候宁可停机做冷迁移也别一个任务挂在MIGRATING上熬到半夜。另外热迁移完成后记得检查实例的新宿主有时因为目标节点资源不足虚机被调度到意料之外的节点业务架构的拓扑就变了。5.2 evacuate计算节点宕机时的救命操作疏散evacuate是所有OpenStack运维最希望永远用不上、但必须熟练掌握的操作。当某台计算节点物理宕机或网络隔离时它上面运行的所有实例都会进入ERROR状态里面的虚机实际上已经“死亡”了。普通Cold Migrate和热迁移都要求源节点能正常通信一旦源节点失联唯一恢复实例的方法就是evacuate。openstack server evacuate --host target-host server会通知nova-scheduler在其他可用计算节点上重新启动该实例。注意evacuate不是迁移它默认不会保留原来的系统盘数据——除非你用了共享存储。如果系统盘放在Ceph等共享存储上新节点可以直接挂载同一份数据业务恢复后数据完好无损。如果系统盘是本地盘源节点都挂了本地数据根本读不出来evacuate后实例会从镜像重新创建系统盘本地数据等于全部丢失。这就是OpenStack架构设计里一个非常重要的取舍生产环境的系统盘和数据盘到底放本地还是共享存储。我的建议是核心业务一定要走共享存储在Ceph上因为只有这样才能在计算节点故障时做到快速恢复。如果为了省钱把系统盘全放本地一旦宿主机坏了只能和不完整的数据说再见。evacuate的恢复时间取决于镜像大小、目标节点资源、网络复制速度但一般来说比重建快得多操作得当几分钟内就能恢复服务。evacuate有一个常见的坑如果实例配置了admin_pass或者自定义了密码注入evacuate后可能需要重新通过VNC设置密码新节点上的实例可能和旧实例的guest OS状态不一致。所以每次evacuate后建议第一时间检查实例的启动日志console log和网络连通性确认服务真正恢复再切换流量。5.3 resize变配不只是改flavor变配resize是Nova里最容易出问题的操作之一。openstack server resize --flavor new_flavor server会把实例迁移到能承载新flavor的计算节点也可能是同一台节点然后重新定义虚机的CPU、内存和磁盘大小。如果新flavor的磁盘比原来大系统盘会被扩容如果比原来小系统盘文件不变但可能会有多余空间无法利用。resize完成后实例会进入VERIFY_RESIZE状态你需要手动执行openstack server resize confirm确认变更或者openstack server resize revert回滚到原来的flavor。这里有个非常关键的时间窗口如果设置了resize_confirm_window比如24小时超过该时间后Nova会自动confirm如果没有设置实例可能一直停留在VERIFY_RESIZE状态直到你手动确认。resize最坑的一点是默认情况下resize会执行冷迁移意味着实例会关机业务中断时间可能在几分钟到几十分钟不等。你需要在变配窗口内完成全部操作。如果业务不允许中断可以考虑支持在线变配的版本或使用专门的缩扩容方案但OpenStack社区版本默认不提供CPU/内存热插拔。变配之前强烈建议先做快照因为resize过程如果失败原实例的磁盘文件可能被重新调度到别的节点恢复起来非常麻烦。我在生产环境变配时有一个固定流程先看新flavor的磁盘大小是否足够再看实例当前所在宿主机的资源是否满足新flavor有时候Nova不会迁移直接原地调整最后执行resize等VERIFY_RESIZE状态后检查虚机状态和业务确认无误再confirm。如果resize后业务异常就revert回滚。这个流程虽然保守但从来没出过事故。6. 与外部资源联动的操作卷挂载与浮动IP6.1 attach与detach volume数据盘怎么接实例只有一块系统盘很多时候不够用Cinder卷云硬盘就派上用场了。Nova这里对应的操作是attach和detach。命令分别是openstack server add volume server volume和openstack server remove volume server volume。把Cinder卷挂到实例上之后它在guest OS里的表现就是一块新的块设备比如/dev/vdb或/dev/vdc。系统不会自动分区、不会自动格式化、也不会自动挂载到某个目录这一切都需要你进入实例手动完成。很多新手挂载完卷之后以为直接就能用了结果lsblk一查发现根本没出现这是因为块设备需要在系统层面做分区、格式化、挂载。我会在卷挂载完成后用lsblk确认设备已识别然后mkfs.ext4 /dev/vdb格式化如果新卷再mkdir /data mount /dev/vdb /data如果需要开机自动挂载还要配置 /etc/fstab。如果挂载的是启动卷bootable volume你可以直接用这个卷作为实例的系统盘启动。这种情况在需要从快照卷恢复数据或者更换系统盘时特别有用。detach操作看起来简单其实是个危险动作。如果guest OS还在读写这个卷直接detach会导致文件系统损坏或者IO错误。正确的流程是先登录实例执行umount卸载挂载点确认没有进程占用该设备然后再在OpenStack侧执行remove volume。如果实在无法登录实例但又要强制下线数据盘需要在Nova侧强制解绑这种做法有数据损坏风险不到万不得已不要用。卷挂载还有一个常见问题挂载了多块卷之后设备名在重启后可能发生漂移。比如 /dev/vdb 重启后变成了 /dev/vdc。这是因为Linux内核枚举设备的顺序不完全固定。生产环境我建议通过UUID或者标签LABEL来挂载设备不要直接写死/dev/vdb这样可以避免启动后挂载失败的尴尬。6.2 浮动IP的关联与解绑浮动IPFloating IP是OpenStack里让外部网络访问实例的标准方式。实例默认可能只有内网IP外部无法直接访问。执行openstack server add floating ip server floating_ip就把一个公网IP绑定到实例上解绑是openstack server remove floating ip server floating_ip。浮动IP的本质是iptables的DNAT规则在Neutron的路由节点或虚拟路由器上把浮动IP的流量映射到实例的内网IP。实例自身感知不到浮动IP的存在它的网卡配置依然是内网IP。所以解绑浮动IP后实例的内部网络、内网服务完全不受影响只是外部无法再通过那个公网IP访问它。浮动IP关联和云主机本身的“多网卡配置”不要混淆。如果你需要多块网卡、多个内网IP应该创建多个端口port然后附加到实例上。浮动IP只是外网出入口的映射和网卡数量无关。实际运维中我经常用浮动IP做“故障切换”。比如一台Web实例挂了我可以先把浮动IP从故障实例解绑再绑定到备用实例上实现秒级切换。这个操作比改DNS快得多非常适合对中断时间敏感的场景。要注意的是浮动IP解绑后原来实例的外网连接会立即断开如果业务里有长连接比如数据库的外网连接池全部重连的成本也要考虑到。7. 实战速查故障场景操作组合与高频坑位7.1 典型运维场景的操作组合Nova的16种操作很少单独使用实际运维中经常是组合拳。我挑几个高频场景把操作串联起来讲一遍。场景一宿主机计划维护。比如要对计算节点做内核升级。正确做法是先把该节点上所有实例都执行openstack server migrate --live热迁移出去如果热迁移条件不满足或者实例状态不健康就改成suspend等节点维护完再批量resume。这里的决策顺序是先看共享存储是否可用再看实例是否允许短时间暂停。热迁移最推荐因为它对业务影响最小没有共享存储时才退而求其次用suspend。场景二实例系统盘被入侵或损坏严重。首先执行openstack server image create创建快照留作证据或后续分析然后执行openstack server rebuild --image 原镜像快速恢复。如果rebuild后还是起不来再考虑openstack server rescue进入救援模式修复。这个顺序比较重要先保存现场再快速恢复最后才深入修复。场景三实例负载持续增长需要扩大规格。执行openstack server resize --flavor 大规格实例进入VERIFY_RESIZE状态后检查业务是否正常确认无误再执行openstack server resize confirm。如果异常执行openstack server resize revert回滚。变配之前先做snapshot整个过程避免在业务高峰期进行。场景四计算节点宕机。先确认节点确实失联然后用openstack server evacuate --host 其他节点 server把实例一一疏散。如果系统盘在共享存储上数据不会丢如果系统盘在本地要有数据丢失的心理准备。疏散完成后检查实例的console log和网络连通性确认服务恢复后再把流量切回。整个过程中可以利用浮动IP解绑/绑定做流量切换。7.2 高频问题排查速查表故障现象可能原因排查与解决办法实例一直停留在BUILD状态镜像过大、资源不足、调度失败检查计算节点的可用内存/CPU查看nova-compute日志确认镜像下载是否完成关机stop后状态仍为ACTIVEguest OS没有响应ACPI关机信号检查guest内acpid服务或者用--os-stop-hard强制关机实例状态为ERROR但task_state为空磁盘空间不足、镜像损坏、网络插件失败查看nova-compute和neutron日志确认是否磁盘满清理空间后重置状态pause之后计算节点重启实例状态异常PAUSED状态不持久化之后尽量用suspend替代pause做长时间冻结resize后忘记confirm实例卡在VERIFY_RESIZEresize_confirm_window未设置或还没到超时手动执行openstack server resize confirm或者根据业务情况revert热迁移长时间卡在MIGRATING内存脏页率过高迭代无法收敛停止高写入负载等待迁移完成或者取消迁移改为冷迁移evacuate后实例数据丢失系统盘放在本地盘而非共享存储排查源节点是否能恢复数据不能恢复只能从镜像重建后续建议系统盘迁移到共享存储挂载卷后实例内看不到设备卷挂载成功但guest OS未识别或未分区进入实例执行lsblk检查新卷需要分区、格式化、挂载快照成功但新实例创建失败快照时系统盘不一致或镜像元数据损坏检查Glance镜像状态尝试重新创建快照或者基于快照做rebuild验证lock之后还能被强制删除管理员用了--force解锁生产环境通过RBAC权限控制限制普通用户对核心实例的管理权限7.3 最后再分享两个经验写到这里收尾之前我还是想多说几句个人体会。第一个是关于操作习惯。我见过太多人在OpenStack上直接敲命令完全不管当前实例状态结果就是各种奇奇怪怪的操作冲突。其实Nova的命令设计得很“讲道理”大多数操作都有前置状态要求你只要在操作前执行openstack server show看一眼状态绝大多数事故都能避免。我自己现在养成了习惯凡是生产实例操作前必看状态和task_state宁可多花五秒查看也不愿花五小时处理误操作。第二个是关于镜像和备份的执念。Nova再强大也挡不住存储层面的物理故障和逻辑错误。我的原则是所有核心实例至少保留最近一份快照所有数据卷定期做Cinder备份所有配置变更前先出快照。这个习惯救了我太多次甚至有一次整台计算节点的磁盘阵列故障我硬是靠前一天晚上的快照把十几台实例全部恢复到了可用状态。Nova的16种操作只是工具集真正的安全垫永远是备份意识和纪律性。希望这篇整理能帮你把工具用熟也把备份的习惯刻进肌肉记忆里。