如果这篇文章对你有帮助欢迎关注我的CSDN账号「来福猿」 有问题可以在评论区留言我会一一回复。1. 背景CentOS 停服生产环境不能再观望CentOS 的停服时间表已经非常明确CentOS 8 在 2021 年底停止维护CentOS 7 也在 2024 年 6 月 30 日全面停止更新。对于仍然大量运行 CentOS 的生产环境来说这意味着漏洞不再修复、安全补丁不再发布、社区仓库逐步冻结系统继续“带病运行”的风险会越来越高。尤其对于金融、政务、能源、制造等对信息安全和合规要求严格的行业操作系统停止维护通常会被安全审计直接判定为不合规项。等保测评、行业监管检查、漏洞扫描平台都会把“EOL 操作系统”列为高危问题。因此CentOS 迁移不是“要不要做”的问题而是“怎么做、什么时候做、如何把业务影响降到最低”的问题。本文结合实际生产环境迁移经历记录从 CentOS 7 迁移到 openEuler 的完整过程重点梳理迁移方案选择、原地升级操作、常见兼容性问题和最终验收经验供同样面临信创国产化改造的团队参考。2. 为什么选择 openEuler在 CentOS 停服之后替换方向主要有三类继续使用 RHEL 商业订阅、切换到 Rocky Linux 等兼容发行版或者迁移到国产操作系统。结合信创要求和长期支持能力openEuler 是当前比较稳妥的选择。对比维度CentOS 7openEulerRocky Linux维护状态已停服社区活跃有长期支持版本社区维护中信创合规不满足满足国产化要求不满足生态支持生态成熟但逐渐收缩适配国产 CPU、数据库、中间件与 RHEL 生态接近迁移工具无提供 x2openEuler 原地升级工具迁移工具相对简单技术支持仅社区历史资料社区与商业发行版支持以社区为主openEuler 的核心优势在于由开放原子开源基金会孵化社区持续迭代对鲲鹏、飞腾、海光、兆芯、龙芯等国产处理器适配较好同时提供了 x2openEuler 迁移工具可以降低从 CentOS 迁移的门槛。对于已经明确要做信创改造的团队选择 openEuler 可以少走很多弯路。3. 迁移前的评估决定整个项目成败很多人一上来就想直接跑迁移工具结果迁移到一半发现存储驱动不兼容、业务依赖缺包、数据库起不来。生产环境迁移的第一原则是先评估再动手。3.1 盘点业务与依赖迁移前需要形成完整的资产清单至少包含以下内容每台服务器的硬件配置、BIOS 版本、RAID 卡型号、HBA 卡型号和网卡型号。操作系统版本、内核版本、已安装的软件包列表。上层的中间件、数据库、消息队列、大数据组件及其版本。第三方 yum 源、自建本地源、pip 源、npm 源等依赖来源。内核模块、自编译驱动、特殊的 systemd 服务或定时任务。建议在每台服务器上先生成软件包清单方便迁移后对照。# 导出已安装的软件包列表 rpm -qa --qf %{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n /root/rpm_list_before.txt 导出已启用的 repo 信息 yum repolist all /root/repolist_before.txt 导出自建 systemd 服务和 crontab systemctl list-unit-files --stateenabled /root/services_before.txt crontab -l /root/crontab_before.txt 2/dev/null || true3.2 识别高风险组件以下组件在迁移时最容易出问题需要单独标记并提前制定替代或验证方案第三方内核模块RAID 卡驱动、FC 存储多路径驱动、安全代理模块。商业软件带 license 绑定的备份客户端、监控 Agent、加密客户端。老版本运行时Python 2、旧版 glibc、32 位兼容库。深度绑定 RHEL 体系的软件部分数据库和中间件对系统版本有强校验。自编译的二进制和脚本中的绝对路径依赖。3.3 明确迁移窗口与回退方案生产迁移必须预留操作窗口并保证可以快速回退。迁移前至少做一次完整的系统盘和数据盘备份必要时做整机镜像。对于核心业务建议先在测试环境和预生产环境完整演练再进入生产变更窗口。4. 迁移方案怎么选重装迁移还是原地升级从 CentOS 到 openEuler常见有两种路线重装迁移和原地升级。方案优点缺点适用场景重装迁移环境干净没有历史包袱配置可控需要重新部署应用、恢复配置工作量大应用标准化程度高、可自动部署的环境原地升级业务中断时间短配置和应用基本保留可能残留不兼容包依赖问题较多老业务、配置复杂、无法快速重建的环境实际项目中通常采用“混合策略”基础镜像统一、应用可容器化的服务器优先重装迁移老旧的、配置复杂且难以快速复现的服务器采用 x2openEuler 原地升级。本文重点记录原地升级的实战过程因为这部分踩坑最多。如果业务已经容器化重装迁移通常更省心先准备好 openEuler 主机再重新部署容器运行时应用镜像基本不用改只需要验证基础镜像的兼容性。对于 Kubernetes 节点还可以采用“新建节点、驱逐 Pod、逐步下线旧节点”的方式滚动替换。5. 原地升级实战x2openEuler 迁移过程openEuler 官方提供了 x2openEuler 工具支持从 CentOS 7 等系统原地升级到 openEuler。工具会先对系统进行升级前检查生成检查报告再执行升级操作。5.1 升级前检查迁移前先安装并运行升级前检查确认系统是否可以升级。# 安装 x2openEuler cd /opt wget https://repo.oepkgs.net/openEuler/rpm/openEuler-22.03-LTS-SP3/contrib/x2openEuler/noarch/Packages/x2openEuler-20.03-1.noarch.rpm rpm -ivh x2openEuler-20.03-1.noarch.rpm 执行升级前检查 x2openEuler pre-upgrade 查看检查报告 cat /opt/x2openEuler/upgrade_precheck.json检查项包括内核版本、glibc 版本、已安装软件包、第三方 repo、文件系统类型、磁盘空间、内核模块等。检查结果会把问题分为阻断项和警告项。阻断项必须先处理否则升级会失败。5.2 常见的升级前阻断项结合实测经验检查阶段最常见的阻断项如下启用了 CentOS 已失效的官方源需要先切换到 vault 源或禁用。安装了某些与 glibc 强绑定的商业软件升级后会无法启动。挂载了非标准文件系统或使用 overlay 等特殊挂载方式。磁盘空间不足一般建议系统盘至少预留 10GB 以上的可用空间。存在第三方内核模块需要提前确认是否有 openEuler 对应版本。5.3 执行升级处理完阻断项后可以执行正式升级。升级过程会替换系统包务必在控制台或带外管理环境中操作避免 SSH 断连导致升级中断。# 建议在 screen 或 tmux 中执行 tmux new -s upgrade 执行原地升级 x2openEuler upgrade 升级完成后重启 reboot升级完成后首次重启需要重点关注系统能否正常引导、文件系统是否挂载成功、网络是否恢复、ssh 服务是否正常。建议保留控制台访问防止网络配置异常导致无法远程登录。6. 生产环境踩坑记录这些坑几乎都会遇到升级成功不代表迁移完成。真正的困难一般在升级后的应用验证阶段以下是实际迁移中遇到的高频问题。6.1 坑一第三方 yum 源残留导致依赖冲突CentOS 上经常配置了 EPEL、ELRepo、Remi 或者公司内部的第三方源。升级到 openEuler 后这些源的元数据仍然存在后续 yum 安装时可能出现依赖冲突甚至把系统关键包替换掉。# 升级后检查并禁用非 openEuler 源 yum repolist cd /etc/yum.repos.d/ grep -r enabled *.repo处理方法是禁用全部第三方源只保留 openEuler 官方源。对于确实需要的软件再按需求在 openEuler 仓库或软件厂商提供的新源中重新寻找。不要在 openEuler 上继续使用 CentOS 时代的 EPEL 等源。6.2 坑二glibc 与老版本软件不兼容CentOS 7 的 glibc 版本较低许多老软件是围绕旧版 glibc 构建的。openEuler 的 glibc 版本更高可能导致部分老二进制无法运行或者商业软件在启动时提示找不到库文件。# 查看当前 glibc 版本 ldd --version 查看应用依赖的库 ldd /opt/app/bin/your_app处理思路是优先由软件厂商提供 openEuler 版本或 arm64/x86_64 新版本包如果暂时无法更换可以评估在容器中运行老版本运行时的兼容方案但不要把 CentOS 的 glibc 包强行混装进 openEuler会造成系统基础库被破坏。6.3 坑三存储多路径与 RAID 卡驱动在物理服务器上RAID 卡、HBA 卡和多路径软件的驱动最容易出问题。重装或升级后可能出现磁盘识别异常、多路径聚合失败、设备名变化等情况。# 检查多路径配置和聚合状态 multipath -ll 查看块设备 lsblk 查看内核是否加载相应模块 lsmod | grep -E megaraid|mpt3sas|hpsa|smartpqi迁移完成后一定要核对 /etc/fstab 中的设备标识。推荐使用 /dev/disk/by-uuid 或 by-id 方式挂载避免设备名漂移导致开机无法挂载。同时检查多路径的 wwid 是否与迁移前一致。6.4 坑四SELinux 与安全基线适配CentOS 上的 SELinux 策略和 openEuler 存在差异。部分服务在 CentOS 上是关闭 SELinux 运行的迁移后如果安全基线要求开启会出现权限拒绝。反之如果沿用原来的关闭配置又可能不满足信创安全要求。# 查看 SELinux 状态 getenforce 临时切换到 permissive 排查问题 setenforce 0 查看拒绝日志 grep denied /var/log/audit/audit.log | tail -20建议先按业务最小权限原则配置 SELinux 策略对确实无法适配的老旧应用使用 permissive并记录为待整改项而不是直接一路 setenforce 0 了事。6.5 坑五容器运行时兼容问题已经容器化的业务虽然迁移成本较低但 Docker、containerd 的版本和依赖也要重新评估。CentOS 7 上的旧版本 Docker 不能直接在 openEuler 上沿用同样的安装源。# 检查容器运行时版本 docker version containerd --version 查看当前使用的存储驱动 docker info | grep Storage DriveropenEuler 上建议使用仓库中提供的 containerd 或 Docker 版本并测试 overlay2、cgroup 驱动等配置。Kubernetes 节点迁移时要特别关注 kubelet 的 cgroup driver 是否与容器运行时一致避免 Pod 反复重启或节点 NotReady。6.6 坑六数据库与中间件的国产化适配信创改造往往不只是操作系统替换数据库也可能是从 MySQL、Oracle 迁移到 openGauss、达梦、人大金仓等。操作系统迁移和数据库迁移叠加时建议分阶段进行先把系统迁移到 openEuler再用原有数据库稳定运行一段时间确认无兼容问题后再考虑数据库替换。对于暂时保留的 MySQL、Redis、Kafka 等组件需要到对应官网或 openEuler 仓库确认是否有 openEuler 版本不要继续使用 CentOS 7 的安装包。部分中间件启动脚本会检查 /etc/redhat-release 或系统版本号需要根据实际情况调整。6.7 坑七时钟同步与监控 Agentchrony 是 CentOS 7 默认的时间同步工具openEuler 同样支持但配置文件路径和默认值可能有差异。迁移后要确认时间同步正常避免因时间偏差影响日志审计、数据库事务和证书校验。# 配置 chrony 并检查同步状态 systemctl enable chronyd systemctl restart chronyd chronyc sources -v chronyc tracking监控 Agent 方面Zabbix、Prometheus node_exporter、公司自研 Agent 都需要重新安装对应版本。部分商业监控 Agent 会对系统发行版做校验迁移后可能上报失败需要在平台侧重新纳管。6.8 坑八开机自启和自定义服务丢失原地升级理论上会保留 systemd 服务但有些依赖不存在或路径变化的服务会启动失败。迁移后要逐个核对开机自启项# 列出所有失败的 unit systemctl --failed 检查开机自启 systemctl list-unit-files --stateenabled 查看某个服务的状态和日志 systemctl status your_service journalctl -u your_service -n 50对于启动脚本里写死 /usr/lib64 下旧库路径的情况要改成 openEuler 中的实际路径。对于已废弃的服务及时清理避免残留影响后续运维。7. 迁移后的验证清单迁移完成后不能只看“系统能开机、ssh 能登录”就结束。建议按照下面的清单逐项验证系统基础内核版本、发行版信息、文件系统挂载、磁盘容量、网络连通性。安全基线防火墙规则、SELinux 状态、SSH 配置、账号权限、审计日志。运行环境Java、Python、Node.js 等运行时版本软件包依赖完整性。业务组件数据库、缓存、消息队列、中间件是否正常启动并保持稳定。监控告警主机监控、日志采集、告警策略是否恢复。备份恢复迁移后重新执行一次备份任务确认备份链路可用。性能基准对关键应用做简单压测对比迁移前后的 CPU、内存、IO 指标。建议以标准化表格记录每台服务器的验证结果形成迁移验收报告方便后续审计和问题追溯。8. 回退与应急策略无论前期准备多充分生产变更都必须有回退预案。原地升级前至少做一次完整的系统盘镜像或快照并将关键业务数据单独备份。升级后如果出现无法快速解决的问题应果断回退而不是在故障状态上继续排查。回退方式取决于迁移方案重装迁移可以切换回旧主机或旧磁盘原地升级可以从镜像恢复。无论哪种方式都建议提前演练一次回退操作并记录回退耗时。回退本身也是迁移方案的一部分不能被忽略。9. 经验总结从 CentOS 迁移到 openEuler本质上不只是换一个操作系统而是对服务器软硬件栈、运维流程、安全策略的一次整体梳理。以下几点是这次项目沉淀下来的经验迁移不是纯技术操作前期评估和业务方沟通至少要占一半精力。先迁移测试环境积累完整的问题清单和解决方案再进入生产环境。能上容器的业务优先上容器可以大幅降低操作系统迁移的耦合度。第三方源、商业 Agent、自编译驱动是三大高危点必须提前识别。迁移后的验证要标准化留下验收记录不能靠“感觉没问题”。回退方案必须真实演练过否则一旦失败会非常被动。信创国产化是大方向但落地需要工程化思维。与其纠结某一条命令不如把评估、演练、验证、回退的流程建立起来。操作系统迁移之后后续的数据库国产化、中间件替换等改造也会更有底气。
