4. 原地升级与迁移方案选型

当一台 RHEL 7 或 RHEL 8 服务器需要进入 RHEL 9 时代时，真正困难的并不是“怎么装一个新系统”，而是“如何让现有业务在可接受的时间窗口内继续运行”。围绕这个目标，业界形成了四条主流路线：Leapp 原地升级、全新安装迁移、容器化封装、虚拟化 P2V/V2V。它们不是互相替代的四个按钮，而是四种不同的风险与成本分配方式。选型的本质，是把停机窗口、人力投入、回退难度、硬件依赖和长期可维护性放在同一张账上权衡。

四条路线的技术本质

Leapp 原地升级是在原操作系统上执行就地替换。它通过 preupgrade 阶段扫描已安装 RPM、第三方仓库、内核模块、被修改的配置文件以及已弃用的组件，生成升级报告；随后在 upgrade 阶段用 RHEL 9 的软件包替换 RHEL 7/8 的软件包，并保留 /home、/etc 等数据与配置。它的最大价值是“业务原地不动”，IP、主机名、挂载点、SELinux 上下文基本延续，适合物理机、无法轻易重建的定制环境。代价是升级过程不可逆性较强，一旦跨过 reboot 进入新内核，回退通常只能依赖升级前快照或备份。

全新安装迁移是新建一台 RHEL 9 主机，重新部署应用、迁移数据、切换流量。它把“系统升级”转化为“业务重建”，因此可以顺手完成架构清理、配置标准化和自动化落地。它的成本主要不在安装，而在应用重新部署、依赖梳理、数据一致性校验和切换演练。适合应用本身已经容器化或配置即代码、数据可在线复制、有负载均衡可灰度切流的场景。

容器化封装并不直接升级操作系统，而是把业务进程及其运行时依赖打包进容器镜像，让容器运行在 RHEL 9 的 Podman 或 OpenShift 之上。旧应用可以继续使用旧版 glibc、旧版 Python 或旧版 JDK，只要内核 ABI 兼容即可。它把“操作系统升级”降级为“运行时隔离”，但要求业务能够接受容器网络、存储卷、日志采集和进程模型的变化，并且镜像需要持续构建与漏洞修复。

虚拟化 P2V/V2V是把物理机或旧虚拟机整体搬迁到新的虚拟化平台。P2V 将物理服务器转换为虚拟机，V2V 在虚拟机之间迁移。它保留完整操作系统与业务形态，只更换底层硬件抽象，因此对应用几乎透明。适合无法改动应用、又希望摆脱老旧物理硬件的场景，但会引入虚拟化层许可、性能损耗和长期“带病运行”的维护负担。

适用条件与成本对照

把四条路线放进同一张决策表，可以更清楚地看到它们各自“贵”在哪里。下表中的时间与人力为示例性估算，用于说明量级差异，实际项目需按应用复杂度重新评估。

一个可执行的选型判断过程

假设有一台 RHEL 7.9 的订单服务主机，运行自研 Java 应用、MySQL 5.7 和若干第三方 RPM，日间峰值 QPS 约 1200，业务只允许凌晨 0:00—4:00 停机。可以按下面的顺序判断：

1. 先做 Leapp 预检。执行 leapp preupgrade，重点看报告中是否有“inhibitor”。若第三方 RPM 无法在 RHEL 9 找到替代、内核模块无源码，则原地升级风险过高。
2. 评估数据层能否解耦。若 MySQL 可以主从复制到 RHEL 9 上的新实例，应用层就具备“新机重建 + 流量切换”的条件，优先考虑全新安装迁移。
3. 评估应用是否适合容器化。若 Java 应用无状态、配置外置、日志走 stdout，可封装为镜像，在 RHEL 9 上用 Podman 运行，停机窗口可压缩到分钟级。
4. 最后才考虑 P2V/V2V。仅当应用完全不可改、又必须更换硬件时使用，并明确它只是“延寿”，不是真正的现代化升级。

混合策略往往比单选更现实

真实环境中，一台主机上常同时存在多种负载。例如同一台 RHEL 7 上既有可容器化的 Web 前端，又有必须保留的旧版报表程序。此时可以拆分处理：Web 前端容器化后迁到 RHEL 9，报表程序用 Leapp 原地升级，数据库用全新安装加主从切换。这样每一部分都选择了成本最低的路径，而不是被整机绑定在一种方案上。

无论选择哪条路线，升级前都应完成三件事：确认备份可恢复、记录当前内核与关键 RPM 版本、准备回退脚本或快照。升级后则要验证服务端口、SELinux 拒绝日志、挂载点、定时任务和证书有效期。只有“升级完成且业务验证通过”，迁移才算真正结束。