香港物理机替换停更的CentOS 7，AlmaLinux与Rocky Linux如何按兼容性选择？

香港物理机上的 CentOS 7 已于 2024 年 6 月 30 日结束维护，继续运行并不等于服务器立即不可用，但安全更新、软件仓库和厂商支持都会逐步收缩。AlmaLinux 与 Rocky Linux 都属于同一层级的企业 Linux 替代方案，在常见的 RPM、systemd、SELinux、glibc 和服务器软件栈上具有较高延续性，但两者并不存在脱离业务环境的“绝对兼容”差异。

如果业务依赖较老的 PHP、Python、Java、数据库驱动或第三方内核模块，应该先确定目标大版本，再在 AlmaLinux 和 Rocky Linux 之间比较；如果应用已经支持 EL9，通常优先考虑较长维护窗口的 9 系列。如果应用只明确支持 EL8，或者需要借助经过验证的 CentOS 7 到 EL8 迁移路径，则应选择 EL8。发行版名称本身不是第一决策因素，厂商认证、硬件驱动、软件仓库和回滚条件才是香港物理机迁移能否平稳完成的关键。

先统一“兼容性”的判断口径

CentOS 7 停更后的迁移，不应只比较 /etc/redhat-release 中的发行版名称。真正影响业务的兼容性至少分为四层：

AlmaLinux 和 Rocky Linux 在前两层通常有较强的相似性，因此很多基于 EL8 或 EL9 的通用软件包可以在两个发行版上运行。但“软件包能安装”不等于“业务已经兼容”。例如，某个旧版 PHP 扩展可能在仓库中存在，却因为 OpenSSL、编译器或底层库版本变化而在运行时失败。

版本选择应先于发行版选择

CentOS 7 迁移到 EL8 和迁移到 EL9，面对的是两次不同程度的系统变化。可以按以下口径判断：

EL8 与 EL9 的生命周期都应以目标项目当前公告为准。从维护窗口角度看，EL9通常比EL8多出约三年的可用周期，但更长的维护周期不能弥补应用不兼容。如果数据库、控制面板或商业软件只认证到 EL8，强行部署 EL9 可能会把“系统升级”变成“应用重构”。

AlmaLinux 与 Rocky Linux的共同基础

两者都面向企业服务器场景，常见基础能力包括：

• 使用 RPM 软件包体系；
• 以 dnf 作为主要包管理工具，兼容多数 YUM 使用习惯；
• 默认采用 systemd 管理服务；
• 支持 SELinux、firewalld、NetworkManager 等企业 Linux 常见组件；
• 提供适用于物理机、虚拟机和云主机的安装介质；
• 兼容大量面向 RHEL 或 EL 系列构建的软件。

这意味着，原来使用 Apache、Nginx、MariaDB、PostgreSQL、Redis、Podman、Docker、Java、PHP 或常见监控客户端的服务器，通常不需要因为选择 AlmaLinux 或 Rocky Linux 而完全改写应用架构。

但以下内容不能直接从 CentOS 7 原样带过去：

• CentOS 7 上编译的第三方内核模块；
• 依赖 Python 2 的管理脚本；
• 直接调用旧版 OpenSSL 接口的程序；
• 依赖旧版 iptables 行为的防火墙脚本；
• 使用传统 network-scripts 管理网络的自动化脚本；
• 只提供 CentOS 7 RPM 包的商业软件；
• 根据 CentOS 7 仓库路径写死的部署脚本；
• 与特定内核版本绑定的存储、网卡或安全模块。

因此，AlmaLinux 与 Rocky Linux的比较，重点不是判断哪一个“更像 CentOS 7”，而是判断哪一个能让现有应用、硬件和运维链条以较少改造继续工作。

两个发行版的核心差异

软件包和二进制兼容性

两者都围绕 RHEL 兼容性构建，通用 EL 软件通常可以在两个发行版之间迁移。但项目构建流程、仓库标识、签名密钥和个别软件包版本仍可能不同。

例如，迁移后以下内容需要重新核对：

• almalinux-release 或 rocky-release 等发行版识别包；
• BaseOS、AppStream、CRB 等仓库名称；
• 第三方仓库使用的发行版判断条件；
• GPG 密钥和软件包签名；
• 内核版本、内核扩展包和 DKMS 构建结果；
• 自动化脚本中对 /etc/os-release 的判断；
• 软件供应商是否把 AlmaLinux 和 Rocky Linux分别列入支持矩阵。

常见的“EL8 通用仓库”通常比“只针对某一发行版的仓库”更容易迁移。如果某个供应商只提供 centos/7/x86_64 路径，不能简单把路径中的 7 替换成 8 或 9。应先确认供应商是否提供对应大版本的软件包和支持承诺。

社区治理和商业支持

AlmaLinux 由 AlmaLinux OS Foundation 负责项目治理，背后有商业公司参与生态建设；Rocky Linux 则由 Rocky Enterprise Software Foundation 负责社区项目，商业支持通常通过相关服务商提供。两者的组织模式、构建流程、商业支持渠道和社区响应方式并不完全相同。

这类差异对业务的意义是：系统本身可以免费使用，并不代表迁移和运维没有成本。对于有合规、审计或故障响应要求的企业，应重点确认：

• 是否可以购买到满足响应时间要求的支持服务；
• 支持服务是否覆盖内核、仓库、安装和升级问题；
• 供应商是否接受该发行版作为正式运行环境；
• 业务软件的授权是否按 RHEL 兼容系统计算；
• 内部团队是否已经积累了对应的故障处理经验；
• 监控、备份、配置管理和资产平台是否支持该发行版识别。

如果团队已经大量使用 Rocky Linux 镜像、Ansible 变量、内部仓库和运维文档，继续使用 Rocky Linux的迁移成本通常更低。反过来，如果现有支持方、面板或迁移工具对 AlmaLinux提供更明确的路径，则 AlmaLinux更适合。这里的优势属于生态衔接，不等同于基础性能优势。

迁移工具和就地升级路径

AlmaLinux生态中提供过面向跨大版本迁移的工具路径，例如 ELevate 类型的方案，但具体能否从 CentOS 7 迁移到目标版本，仍取决于源系统状态、已安装软件、仓库配置、内核模块和当前工具支持范围。

就地迁移至少会改变以下内容：

• 系统仓库和软件包签名；
• glibc、OpenSSL、systemd 等底层组件；
• 引导加载器和内核；
• 网络、防火墙和 SELinux 策略；
• Python、编译器和系统工具链；
• 服务启动顺序和默认配置。

因此，不能因为某个工具能够执行迁移，就把它视为物理机上的无风险操作。只有在具备带外管理、完整备份、可启动救援环境和明确回滚方式时，才适合评估就地迁移。

Rocky Linux也可以通过重新安装、数据迁移、配置管理重建等方式完成替换。对于生产物理机，更稳妥的路径通常不是在原盘上直接转换系统，而是准备新的系统盘或新的物理机，完成并行验证后再切换业务。

香港物理机需要额外检查什么

香港只代表服务器所在机房和网络位置，不会改变 AlmaLinux 或 Rocky Linux的基础兼容模型。但物理机与云主机不同，硬件、带外管理和服务商交付方式会显著影响迁移风险。

存储和网络硬件

迁移前应记录当前硬件信息，并在目标系统的测试环境中确认驱动状态。可以使用以下只读命令收集基础信息：

cat /etc/centos-release
uname -r
lspci -nnk
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL
findmnt
ip -br addr
nmcli device status
getenforce
systemctl list-unit-files --state=enabled

重点不在于保存命令输出本身，而在于建立迁移前后的对照：

• RAID 卡或 HBA 是否被目标内核识别；
• RAID 阵列是否能正常读取，是否需要厂商驱动；
• 网卡名称是否从 eth0 变为 ens160、enp1s0 等；
• 10GbE、25GbE 网卡的驱动和固件是否匹配；
• NVMe、HBA、多路径和热插拔功能是否正常；
• IPMI、iKVM、串口控制台是否可以使用；
• 服务器是否可以从救援镜像或远程挂载介质启动。

如果物理机使用厂商提供的闭源驱动、硬件监控代理或 RAID 管理工具，不能只测试操作系统安装完成。还要确认目标发行版是否有对应版本，代理是否能采集温度、风扇、电源、阵列健康度和磁盘告警。

网络配置和机房交付能力

香港物理机切换时，最容易被忽略的是网络交付，而不是发行版本身。需要向服务商确认：

• 静态 IPv4、IPv6、网关和反向解析是否可以保留；
• VLAN、额外 IP、BGP 或静态路由是否需要重新配置；
• MAC 地址变化是否会触发交换机侧限制；
• 远程控制台是否支持重装、救援启动和磁盘挂载；
• 机房是否提供独立的备份网络或内网地址；
• 新系统的 DNS、NTP、监控和日志出口是否已放行；
• 防火墙策略切换时，是否可以从管理网继续登录。

如果采用新物理机替换旧物理机，最好提前准备临时管理地址和切换用的 DNS、负载均衡或上游路由方案。不要把“修改公网 IP”作为唯一切换手段，尤其是数据库、支付回调、白名单和固定 IP 授权较多的业务。

CentOS 7应用迁移中的真正风险

OpenSSL 和加密协议变化

CentOS 7时代的应用经常直接依赖旧版 OpenSSL。迁移到 EL8 或 EL9 后，TLS 默认策略、密码套件和库接口都会变化。可能出现的现象包括：

• 与旧数据库、旧支付接口或旧 LDAP 服务握手失败；
• Java、PHP、Python扩展加载失败；
• 自签名证书或过短密钥被更严格的策略拒绝；
• 程序仍能启动，但 HTTPS 请求返回协议错误；
• 依赖旧加密算法的备份或同步工具无法运行。

如果业务必须连接老旧外部系统，应在隔离测试环境中验证完整的请求链路，而不是只执行 curl 查看一个普通网站是否可访问。测试内容应覆盖登录、上传、下载、回调、证书校验和异常重试。

Python、PHP、Java和编译型程序

CentOS 7上常见的 Python 2 脚本，在 EL8 或 EL9 上不一定有完整的系统级运行环境。PHP 和 Java 应用则可能受模块流、JDK 默认版本、扩展编译方式和系统库变化影响。

可以将应用按风险分为三类：

对于自行编译的软件，应保存编译参数、依赖清单和构建脚本。只备份 /usr/local/bin 下的可执行文件，无法证明它能在新系统上运行；需要重新构建时，应在目标系统中验证头文件、编译器、库版本和运行时链接关系。

网络、防火墙和服务管理变化

EL8 和 EL9中的 NetworkManager、firewalld、nftables 和 systemd 行为，与 CentOS 7上依赖旧脚本的环境可能不同。以下迁移问题较为常见：

• 原有 ifcfg-* 文件无法完整表达新网络配置；
• 以接口名写死的监控或防火墙规则失效；
• 旧版 iptables 脚本与 nftables 后端行为不一致；
• 自定义 systemd 服务缺少启动依赖；
• 服务启动顺序改变，导致数据库尚未就绪时 Web 服务已启动；
• SELinux 从宽松模式切换为强制模式后，程序访问目录被拒绝。

这不是 AlmaLinux 与 Rocky Linux之间的主要差异，而是 CentOS 7到新一代企业 Linux的共同迁移问题。两者都需要重新核对网络、服务和安全策略。

两种迁移路径的业务影响

路径一：原机就地迁移

就地迁移的优点是：

• 保留原有磁盘、数据和公网地址；
• 不需要立即采购或租用第二台物理机；
• 配置文件、用户和部分服务状态可以继续保留；
• 对数据量很大的业务，减少一次全量搬运。

但它的风险也集中在同一台机器上：

• 迁移过程中可能无法启动原系统；
• 系统盘损坏时，回滚依赖备份和救援环境；
• 历史仓库、残留软件包和手工修改会影响结果；
• 原有问题会被带入新系统；
• 迁移失败后，恢复时间受机房远程操作速度影响。

适合评估就地迁移的服务器通常具备以下条件：

CentOS 7 迁移到 AlmaLinux 或 Rocky Linux，硬件资源与新系统承载业务的方式同样重要。A5数据提供香港物理服务器租用，覆盖 Xeon Gold 与 AMD EPYC 平台，配有 SSD 或 NVMe 存储，可用于网站、数据库、业务后台和接口服务等场景。不同配置组合为并行部署应用、迁移数据及承载多类业务提供了硬件资源基础。

• 应用和数据库厂商明确支持目标大版本；
• 系统软件包来源清晰，没有大量失效第三方源；
• 没有关键的闭源内核模块；
• 已经完成整机备份，并验证过恢复；
• 服务商提供可靠的 KVM、救援系统或远程介质；
• 可以安排业务窗口，并准备人工值守。

路径二：新盘或新物理机并行迁移

并行迁移更适合生产环境，尤其是香港物理机上承载数据库、文件服务或多个站点时。基本思路是先安装目标系统，再逐项迁移应用和数据，最后通过 IP、DNS、负载均衡或上游配置完成切换。

它的优势包括：

• 原 CentOS 7环境可以继续提供回滚保障；
• 能提前验证 RAID、网卡、监控和备份；
• 可以清理历史软件包和无效配置；
• 切换失败时能够快速恢复到旧机；
• 迁移后的系统状态更容易形成标准镜像或自动化文档。

代价是需要承担一段时间的双机资源、数据同步和配置维护。对于大容量文件服务，数据同步时间可能比系统安装时间更长。

例如，需要同步 500 GB 十进制数据，链路持续速率按 200 Mbps 估算：

1. 500 GB × 8 × 1000 = 4,000,000 Mb；
2. 4,000,000 Mb ÷ 200 Mbps = 20,000 秒；
3. 20,000 秒 ÷ 3,600 = 5.56 小时。

这只是理想传输时间，实际还要考虑磁盘读取、文件数量、校验、增量变化和链路波动。因此，500 GB 数据不应简单承诺“几小时内完成切换”。可以先做全量同步，再在切换窗口内执行增量同步和最终校验，以减少停机时间。

成本与限制不能只看授权费用

AlmaLinux 和 Rocky Linux的基础系统通常不以商业授权费作为主要成本，但迁移总成本仍由以下项目组成：

如果只有一台生产物理机，节省第二台服务器的费用，可能会换来更长的停机窗口和更高的回滚风险。对数据库和文件服务而言，备份恢复演练的价值通常高于单纯比较 AlmaLinux 与 Rocky Linux的免费仓库。

迁移前必须完成的备份

至少应保存以下内容：

• 数据库逻辑备份和必要的物理备份；
• 网站、上传目录、用户目录和对象数据；
• /etc 中的服务配置，但不要把旧配置未经审查直接覆盖到新系统；
• systemd 服务、自定义脚本和定时任务；
• SSL 证书、私钥和证书链；
• 防火墙、路由、DNS、监控和备份配置；
• 软件包清单、仓库清单和应用版本；
• RAID、磁盘和网卡的硬件信息。

涉及覆盖系统盘、修改引导、切换网络或调整防火墙时，必须先确认备份可恢复、影响范围和回滚方式。生产机上不应在没有带外控制台的情况下直接执行可能导致失联的网络或防火墙变更。

用兼容性清单替代“凭经验选发行版”

迁移前可以在旧机上生成基础清单：

rpm -qa | sort > /root/centos7-packages.txt
yum repolist all > /root/centos7-repositories.txt
systemctl list-unit-files --state=enabled > /root/centos7-enabled-services.txt
crontab -l > /root/centos7-root-crontab.txt 2>/dev/null || true
find /etc/cron* -maxdepth 2 -type f -print > /root/centos7-cron-files.txt

这些命令只读取或导出信息，不会改变系统状态。清单完成后，不要机械地要求目标系统安装全部旧包，而应按业务分类：

• 必须保留的运行时；
• 可以升级的运行时；
• 仅用于旧任务的工具；
• 已经废弃的服务；
• 由第三方仓库提供的软件；
• 与硬件绑定的驱动或代理；
• 仅存在于旧服务器、但业务已经不再使用的组件。

目标系统上线前，至少应完成以下验证：

1. 服务器可以正常从目标系统启动，并识别全部阵列、磁盘和网卡；
2. 静态 IP、默认路由、DNS、NTP 和 IPv6配置正确；
3. 关键服务能够启动、停止和自动恢复；
4. 数据库可以完成启动、连接、备份和恢复测试；
5. Web、API、后台任务和定时任务能够完整运行；
6. 证书、TLS、第三方接口和回调链路正常；
7. SELinux 在目标策略下不会阻止核心业务；
8. 监控、日志、备份和告警已经接入；
9. 旧机仍保持可回滚状态；
10. 切换完成后，有明确的观察期和退回条件。

不同条件下如何选择

可以按照以下规则做最终判断。

选择 AlmaLinux的情况

更适合优先评估 AlmaLinux的场景包括：

• 现有服务商、面板或商业软件明确支持 AlmaLinux；
• 希望利用 AlmaLinux生态中已经验证过的跨版本迁移工具路径；
• 团队已有 AlmaLinux镜像、仓库和自动化脚本；
• 需要商业支持，并且已找到符合响应要求的服务渠道；
• 目标是从 CentOS 7较平稳地过渡到 EL8，再规划后续升级。

这里的关键是“支持路径已经验证”，而不是认为 AlmaLinux天然比 Rocky Linux更兼容。仍应在目标硬件和完整业务链路上进行测试。

选择 Rocky Linux的情况

更适合优先评估 Rocky Linux的场景包括：

• 内部标准、自动化平台和现有服务器已经以 Rocky Linux为主；
• 软件供应商或运维服务商明确将 Rocky Linux列为支持系统；
• 已有 Rocky Linux的镜像、补丁、基线和监控模板；
• 团队更熟悉 Rocky Linux的仓库、构建和故障处理方式；
• 不需要依赖特定的 AlmaLinux迁移工具或商业支持渠道。

如果新旧服务器都由同一套配置管理系统维护，沿用团队熟悉的发行版，通常比为了追求理论上的细微差异而更换生态更稳妥。

两者都可以时的选择顺序

当应用厂商同时支持 AlmaLinux 和 Rocky Linux时，可以按以下顺序做决定：

1. 先确定使用 EL8还是 EL9，不要先纠结发行版名称；
2. 检查硬件厂商、数据库、面板、监控和备份工具的支持矩阵；
3. 比较第三方仓库是否提供目标版本的软件包；
4. 在香港实际物理机上验证 RAID、网卡、远程管理和网络交付；
5. 选择内部团队更熟悉、回滚条件更清晰的一方；
6. 通过并行迁移完成试运行，再决定是否正式切换。

如果应用仍依赖 CentOS 7特有的旧库、旧加密算法或闭源驱动，AlmaLinux 与 Rocky Linux都不应直接被视为无改造替代品。此时应先让应用供应商确认 EL8或 EL9支持范围，再决定迁移目标。

对于新部署、应用版本较新且希望减少下一次大版本迁移的香港物理机，优先测试 AlmaLinux 9或 Rocky Linux 9；对于老旧但仍有厂商支持的业务，优先选择对应认证的 EL8；对于已有成熟 Rocky Linux或 AlmaLinux运维体系的团队，则沿用现有生态，往往比单纯比较两个发行版的名称更有实际价值。核心判断始终是：哪一个方案能够在目标硬件、应用依赖、运维工具和回滚条件都经过验证后，以可控停机完成切换。