从CentOS迁移到openEuler 24.03 LTS SP2：我的服务器操作系统切换实战与踩坑记录
当CentOS宣布转向CentOS Stream更新模式后，许多依赖稳定企业级Linux发行版的运维团队开始寻找替代方案。作为一家中型互联网公司的技术负责人，我花了三个月时间评估各种选项，最终决定将公司50多台生产服务器从CentOS 7/8迁移到openEuler 24.03 LTS SP2。这篇文章将完整记录我们的迁移决策过程、技术方案设计、实际迁移步骤以及那些教科书上不会告诉你的"坑"。
1. 为什么选择openEuler：迁移决策背后的技术评估
在决定迁移路径时，我们首先建立了四个核心评估维度：长期支持周期、软件生态兼容性、社区活跃度和企业级功能支持。经过横向对比，openEuler 24.03 LTS SP2在以下方面表现出色：
- 支持周期：提供4年标准维护+2年扩展支持，与CentOS传统模式相当
- 内核特性：基于Linux kernel 5.10 LTS，支持ARM64和x86_64双架构
- 软件仓库：通过EPOL(Extra Packages for openEuler)提供超过20,000个软件包
- 性能优化：针对容器场景的轻量化裁剪版本(22%内存占用降低)
我们特别看重的是openEuler的混合部署能力——它既可以通过dnf命令兼容CentOS的RPM生态，又提供了自己的增强工具链。下表对比了各候选系统的关键指标：
| 评估项 | CentOS 7 | CentOS Stream | openEuler 24.03 | Ubuntu LTS |
|---|---|---|---|---|
| 支持周期 | 2024年终止 | 滚动更新 | 2028年支持 | 5年 |
| 默认文件系统 | XFS | XFS | XFS/Ext4 | Ext4 |
| 容器支持 | 需手动配置 | 原生支持 | 内置iSula引擎 | Snapcraft |
| 中文文档完整度 | 一般 | 较差 | 优秀 | 中等 |
提示：评估时建议用虚拟机同时安装各候选系统，实际测试业务应用的运行情况。我们通过自动化测试发现Nginx在openEuler上的QPS比CentOS 7高出15%。
2. 迁移前的准备工作：环境审计与兼容性测试
正式迁移前，我们花了两周时间进行系统环境审计，开发了专门的采集脚本：
#!/bin/bash # 系统基础信息采集 echo "===== 硬件信息 =====" > audit_report.txt lscpu >> audit_report.txt free -h >> audit_report.txt echo "===== 软件包清单 =====" >> audit_report.txt rpm -qa --queryformat='%{NAME}\n' | sort > installed_packages.list # 服务状态检查 echo "===== 运行中服务 =====" >> audit_report.txt systemctl list-units --type=service --state=running >> audit_report.txt通过分析输出报告，我们发现了三个主要挑战：
- 老旧内核模块依赖：部分设备驱动依赖CentOS 7的3.10内核API
- 自定义RPM包：历史遗留的本地编译软件包缺少openEuler构建环境
- 配置差异：/etc目录下的服务配置文件存在大量手工修改
针对这些问题，我们制定了分阶段解决方案：
- 内核兼容层：对必须保留的驱动使用
kmod-compat包提供ABI兼容 - 软件包重建：使用
mock工具链搭建openEuler构建环境 - 配置迁移：开发Ansible Playbook自动化转换关键配置
3. 实际迁移过程：从双系统并存到完整切换
我们采用渐进式迁移策略，确保任何时候都能快速回退。具体分为四个阶段：
3.1 阶段一：基础环境并行部署
在每台服务器上划分独立分区安装openEuler，与CentOS形成双系统。关键命令：
# 创建新的LVM卷组 pvcreate /dev/sdb1 vgcreate oE_vg /dev/sdb1 lvcreate -L 50G -n oE_root oE_vg lvcreate -L 10G -n oE_home oE_vg # 安装时选择自定义分区 mount /dev/oE_vg/oE_root /mnt mkdir /mnt/home mount /dev/oE_vg/oE_home /mnt/home3.2 阶段二：服务迁移验证
将非核心业务服务逐步迁移到openEuler环境测试，重点关注：
- 网络性能：使用
iperf3对比TCP吞吐量 - 存储IO：通过
fio测试随机读写延迟 - 应用兼容性：特别是依赖glibc版本的Java/Python应用
我们发现MySQL 5.7在默认配置下出现性能下降，通过调整以下参数解决：
# /etc/my.cnf 优化项 [mysqld] innodb_flush_neighbors=0 innodb_io_capacity=2000 innodb_buffer_pool_instances=83.3 阶段三：数据迁移与校验
使用rsync进行数据迁移时，必须注意ACL和扩展属性的保留：
rsync -aAXv --delete /centos/home/ /oE/home/ \ --exclude={".cache",".tmp"}开发了校验脚本确保数据一致性：
import hashlib import os def compare_dirs(src, dst): for root, _, files in os.walk(src): for file in files: src_path = os.path.join(root, file) dst_path = src_path.replace(src, dst) if not os.path.exists(dst_path): print(f"{dst_path} missing!") continue src_hash = hashlib.md5(open(src_path,'rb').read()).hexdigest() dst_hash = hashlib.md5(open(dst_path,'rb').read()).hexdigest() if src_hash != dst_hash: print(f"{src_path} checksum mismatch")3.4 阶段四：网络切换与监控
最后切换网络配置时，我们采用IP接管策略避免DNS缓存问题：
- 在openEuler系统配置原CentOS的IP地址
- 使用
arping广播免费ARP更新交换机MAC表 - 通过Prometheus+Granfana监控迁移后指标波动
4. 那些踩过的坑：非常见问题解决实录
4.1 加密卡驱动兼容性问题
某批戴尔服务器的加密加速卡驱动在openEuler下无法加载，错误日志显示：
AMDI0002: Failed to load microcode ASYM_ACCEL: Unknown symbol crypto_alloc_akcipher解决方案是手动编译安装适配的驱动模块：
# 安装开发工具链 dnf install kernel-devel-$(uname -r) gcc make # 从厂商获取源码包 tar xzf hpe_driver_5.6.2.tar.gz cd hpe_driver_5.6.2 make -j$(nproc) insmod ./hpe_accel.ko4.2 时间同步服务冲突
同时存在chronyd和systemd-timesyncd服务导致时间漂移，解决步骤：
确认当前活跃服务：
timedatectl status | grep "NTP service"禁用冲突服务：
systemctl disable --now systemd-timesyncd优化chrony配置：
# /etc/chrony.conf pool 0.cn.pool.ntp.org iburst makestep 1.0 3
4.3 安全加固导致的性能下降
默认安装的secadvisor安全模块对高频系统调用有监控开销，通过以下调整优化：
# 查看当前安全策略 secconfig --list # 创建自定义profile cat > /etc/secadvisor/rules/myapp.rules <<EOF { "syscall": { "default": "allow", "exception": ["execve"] } } EOF # 应用新规则 secconfig --load /etc/secadvisor/rules/myapp.rules5. 迁移后性能对比与调优建议
经过三个月的生产运行，我们收集到以下关键指标对比：
| 指标项 | CentOS 7 | openEuler 24.03 | 变化率 |
|---|---|---|---|
| 内核编译时间 | 142s | 118s | +17% |
| MySQL QPS | 12,500 | 14,200 | +13.6% |
| 容器启动延迟 | 1.2s | 0.8s | +33% |
| 内存占用(空闲) | 1.8GB | 1.4GB | -22% |
针对高负载场景，我们进一步优化了以下参数：
网络栈调优：
# /etc/sysctl.d/10-network.conf net.core.somaxconn = 32768 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_tw_reuse = 1存储IO优化：
# 调整电梯算法 echo kyber > /sys/block/sda/queue/scheduler # 增大预读缓存 blockdev --setra 4096 /dev/sda迁移过程中最大的收获是建立了完整的基础设施即代码体系。所有系统配置现在都通过Ansible管理，关键服务都有详细的回滚方案。对于考虑类似迁移的团队，我的建议是：先从小规模试点开始，积累足够经验后再全面铺开，同时要预留至少20%的时间用于处理意外问题。
