接手这个项目的时候我们内部讨论了很久。服务器集群里还有二十几台跑着CentOS 7的老机器维护周期到了安全补丁没人管新业务又对内核版本有要求。团队里有人提议直接上欧拉Linux理由是社区活跃、兼容性好而且我们手上一些自研模块本来就是基于RHEL系做的切换成本应该可控。抱着试试看的心态我们以“北科为”项目组的名义在测试环境完整走了一遍迁移和调优流程这几个月折腾下来踩了不少坑也沉淀了一些真正能直接抄作业的经验。这篇就把全过程拆开聊聊。1. 为什么从CentOS换到欧拉选型背景与迁移前的账1.1 服务器现状与迁移动机我们的生产环境以Web服务、数据处理任务和内部工具链为主操作系统清一色是CentOS 7系列。CentOS 7停服之后最直接的问题是CVE修复没人管而每年等保检查和安全扫描都会把系统补丁状态列为重点项。另一个隐性问题是内核太老部分新硬件驱动和NVMe优化特性无法启用数据库在高并发下的性能已经明显吃紧。选择欧拉Linux看中的是它对RHEL/CentOS生态的兼容策略。欧拉社区明确承诺兼容主流Linux应用生态既有仓库也跟随上游版本迭代这样我们已有的部署脚本、systemd服务单元、yum/dnf使用习惯基本可以平迁不需要推倒重来。相比之下如果换成Debian系或者纯自编译LFS光适配依赖库就要多花一倍时间对业务连续性来说风险太大。1.2 迁移前必须算清楚的兼容性账迁移不是重装系统那么简单尤其是我们有十几个自研服务和若干第三方闭源组件。动手之前我们把迁移风险拆成了三层第一层是系统级兼容内核版本、glibc版本、动态链接库路径、systemd版本差异。这一层决定操作系统本身能不能跑起来。第二层是软件包兼容业务依赖的nginx、MySQL、Redis、Python运行时等是否能直接从欧拉仓库装到或者能否复用CentOS的二进制包。这一层决定环境搭建的速度。第三层是业务级兼容自研代码里是否用了特定于旧内核的sysctl参数、procfs路径、SELinux策略等。这一层最隐蔽往往要等业务真正跑起来才会暴露。我们做了一个迁移评估表把每台服务器的角色、关键软件、依赖库、数据迁移方式都登记在案。经验是不要只盯着操作系统本身先把业务清单盘清楚迁移才有底。1.3 短生命周期版本怎么选欧拉Linux提供多个版本线短期支持版和长期支持版并存。这里我的建议是生产环境绝对不要追最新短期版选长期支持版才稳。我们选的是当前维护周期较长的一个稳定版本内核版本较新同时仓库里的软件包版本比较保守适合生产。安装介质从官方镜像站下载ISO和普通Linux安装没有本质区别。值得提醒的是如果服务器是国外品牌的刀片机或老式RAID卡安装前最好确认一下内核里是否包含对应驱动否则容易在磁盘识别阶段就卡住。2. 部署踩坑第一关最小化安装与网络源配置2.1 安装镜像选择与分区规划安装时我们统一选择最小化安装不带图形界面这也是服务器的常态玩法。分区方面没有做太激进的设计/boot单独分1G/按需分配/data和数据盘单独挂载swap按内存大小的1倍预留。欧拉的安装器默认使用LVM保留默认即可后续扩容方便。这里有一个容易被忽略的点欧拉安装器在分区界面默认会“自动创建”home分区如果你的业务根本不会往home目录写东西建议手动把home空间合并到根分区。否则装完发现根分区只有几十G数据写满了还得做LVM扩容很折腾。我们第一批机器就是因为没注意这个细节后期不得不在线扩根分区多花了一个晚上。2.2 dnf/yum源配置细节欧拉默认会配置好官方源仓库文件位置在/etc/yum.repos.d/openEuler.repo。最小化安装后第一件事就是更新源并安装基础工具dnf makecache dnf update -y dnf install -y vim net-tools tar lrzsz wget git tree官方源速度在国内一般没问题但如果在内网离线环境部署需要提前搭好本地镜像源。这里给一个离线源同步的参考命令dnf install -y createrepo_c reposync --repoidOS --downloaddir/data/openEuler-repo/ createrepo_c /data/openEuler-repo/OS/同步完成后在每台机器上把repo文件里的baseurl改成本地地址即可。注意欧拉把软件包分成OS、EPOL、Everything、Debuginfo几个仓库生产环境同步OS和EPOL两个就够了Everything体积太大没必要全量拉下来。2.3 首次启动后的系统初始化重启进入系统后基本初始化流程和CentOS大体相同但有几处细节不同dnf比yum命令提示更友好但脚本里如果还在用yum欧拉也兼容不需要改。系统默认时区是UTC必须改成Asia/Shanghai并启用NTP同步。欧拉默认装了chrony直接改/etc/chrony.conf指向内网NTP服务器即可。SELinux默认是 enforcing 状态。如果你的业务没有针对SELinux做适配建议先保持默认等所有坑踩完再决定要不要收紧或关闭。强行关闭会留下安全短板我不推荐。初始化脚本随手记录一下timedatectl set-timezone Asia/Shanghai systemctl enable --now chronyd hostnamectl set-hostname node01.internal3. 内核参数与性能调优从默认配置到生产可用3.1 针对业务负载的sysctl调整思路欧拉的默认内核参数面向通用场景对Web服务和高并发数据库来说偏保守。我们在测试环境跑了一周基线压测之后根据vmstat、mpstat和dstat的输出逐步调整了一批参数。比较典型的调整包括vm.swappiness默认可能偏高对于内存足够的服务器建议调低到10减少不必要的swap换页。数据库类服务器甚至可以降到5。vm.dirty_ratio和vm.dirty_background_ratio默认值在大量写入场景下会导致写延迟波动。我们把dirty_background_ratio降到5dirty_ratio降到20配合SSD的cache写入稳定性明显改善。net.core.somaxconn默认128对高并发短连接场景明显不够我们直接调到65535。net.ipv4.tcp_tw_reuse开启后可加快TIME_WAIT状态的socket重用对短链接多的Web场景有效果。fs.file-max默认值在大量文件描述符场景不够用调到约100万。调整命令统一写入/etc/sysctl.d/99-custom.confcat /etc/sysctl.d/99-custom.conf EOF vm.swappiness 10 vm.dirty_ratio 20 vm.dirty_background_ratio 5 net.core.somaxconn 65535 net.ipv4.tcp_tw_reuse 1 fs.file-max 1048576 EOF sysctl --system3.2 块设备IO调度器和tuned方案欧拉的内核对NVMe SSD默认使用none调度器对大多数场景是最优解机械硬盘则建议保持mq-deadline避免IO饥饿。检查方式cat /sys/block/sda/queue/scheduler如果在老内核上看到的是cfq需要确认是否被正确切换。我们一台混用HDD和SSD的存储服务器就专门为HDD设置了mq-deadline并通过udev规则固化。另外欧拉自带的tuned工具值得好好用。tuned-adm recommend会给出推荐方案我们应用了throughput-performance再叠加自定义参数。可以这么操作dnf install -y tuned tuned-adm profile throughput-performance tuned-adm activethroughput-performance会自动把cpu_governor设为performance对稳定基准性能很有帮助。3.3 验证调优是否生效调参只是手段关键是验证。我们用sysbench做CPU和内存基准用fio测磁盘延迟和IOPS再用wrk压Web接口。欧拉和CentOS在同样硬件上的基线数据调优后约有5%到10%的提升尤其是网络并发和磁盘写入延迟两个维度差距最明显。如果调优后性能不升反降优先怀疑是参数写错了或者和硬件特性冲突。比如tcp_tw_reuse在使用了NAT网关的环境里可能导致连接复用错乱需要具体场景具体测试不要照搬网上所有参数。4. 迁移实战业务系统从CentOS到欧拉的过程4.1 软件包兼容性验证能装、能用、能跑我们的业务栈里有Java服务、Python脚本、Nginx静态服务、MySQL数据库还有基于GCC编译的几个C模块。迁移的验证思路是先在测试机上把相同版本的软件装上跑通业务自测用例再对比输出。软件源的覆盖情况比预想的好MySQL和Nginx在欧拉仓库中都能直接安装Java环境用OpenJDK 8/11也正常。需要注意Python版本差异CentOS 7自带Python 2.7欧拉自带Python 3.x。我们有几个遗留脚本还依赖Python 2语法迁移时顺手做了升级改造避免后续在新系统上跑老代码踩兼容性坑。4.2 编译类组件和动态库依赖的处理自研C模块是最花时间的部分。在CentOS上编译出来的二进制直接搬到欧拉上大概率会报动态库找不到。比如libssl.so.10这类旧库名称在欧拉中已经不存在取而代之的是libssl.so.1.1。处理方案有两个方向如果是自己源码编译的组件推荐在欧拉环境内重编一次把-Wl,--no-as-needed这类旧链接选项去掉。如果是闭源组件则必须确认厂商是否提供了欧拉/RHEL 8的兼容版本。没有的话只能放到容器里跑用CentOS 7镜像做运行环境。我们用容器方式迁移了一个老调度模块镜像里保留CentOS 7的glibc和依赖库运行在欧拉的Docker/Podman环境中实测完全没问题。这里推荐用Podman欧拉对它的支持更好且无需守护进程更安全。4.3 systemd服务单元文件的迁移细节CentOS 7的服务管理脚本如果手写过sysvinit风格的建议全部改写成systemd unit。欧拉对service文件的要求更严格比如Typeforking的进程如果PIDFile路径不对systemd可能直接判定启动失败。我们遇到过最典型的问题是旧服务脚本用ExecStart/usr/bin/python server.py这种方式启动但Python路径在欧拉上变成了/usr/bin/python3导致服务启动即退出。解决方式很简单写unit文件时用which python3确认绝对路径并为遗留脚本在/usr/local/bin下建立兼容软链。一个可复用的JVM服务unit文件参考[Unit] DescriptionInternal Java Service Afternetwork-online.target Wantsnetwork-online.target [Service] Userapp Groupapp WorkingDirectory/opt/service ExecStart/usr/bin/java -Xms1g -Xmx2g -jar service.jar Restartalways RestartSec5 [Install] WantedBymulti-user.target4.4 数据迁移与业务切换策略数据层面MySQL我们用的逻辑备份加binlog追平的方式在老库上做全量导出新库导入后再追同步最后切换连接串。整个切换窗口控制在15分钟以内。切换策略建议用灰度先在测试机验证后挑一台低负载机器试运行一周再逐步扩大。直接全量切换是迁移失败的第一大原因务必克制。5. 运行时踩坑与排查链路那些文档里没写的5.1 案例一老HTTP客户端TLS握手失败迁移后第一个晚上就收到告警一个负责调用外部支付接口的Java服务频繁报SSLHandshakeException。排查链路如下先看服务日志报错在TLS握手阶段但不是证书过期。用openssl s_client -connect host:port -tls1_2测试发现服务端仅支持TLS 1.2而客户端默认尝试TLS 1.3。查看Java运行环境版本发现欧拉源里默认OpenJDK较新虽然兼容TLS 1.3但老支付网关没有跟进。跳过验证在Java启动参数里添加-Djdk.tls.client.protocolsTLSv1.2问题解决。这个坑的教训是操作系统升级后默认加密策略和协议栈可能同步变化老业务遇到加密报错时先检查TLS协议兼容性远比直接改代码快。5.2 案例二sysctl参数kernel.shmmax导致数据库无法启动MySQL迁移后按官方文档设置了kernel.shmmax和kernel.shmall结果数据库启动直接报ERROR 2002。排查后发现欧拉的内核参数里kernel.shmmax默认已经是极大的值我们手动设置的值反而低于MySQL预期的最小共享内存段大小。解决方式很简单删除我们额外写入的这两个参数使用系统默认值并确认kernel.sem和fs.aio-max-nr满足MySQL要求。这种坑最隐蔽的地方在于网上大量部署教程写的是CentOS 6/7时代的参数放到新内核上反而帮倒忙。5.3 案例三PID 1信号处理差异导致容器内服务失联用Podman跑一个旧版Node.js容器docker stop后进程一直没退出超时被杀。原因是容器内的Node.js进程没有正确处理SIGTERM信号。这在旧内核和旧containerd环境下不明显但欧拉默认的cgroup v2和Podman信号转发机制更严格导致行为变化。排查时用podman inspect确认了容器PID再用kill -TERM pid手动发信号复现。最终解决是在Node.js代码里补上process.on(SIGTERM)逻辑优雅退出。5.4 排查问题的通用方法论几次踩坑后我们总结了三条排查经验第一先看journalctl -u service-name不要只看应用日志系统日志往往藏着真正的错误原因。第二改动前记录基线比如sysctl -a导出、dnf list installed导出、ss -lnp导出迁移后逐项对比能快速锁定差异。第三不要盲目相信“在CentOS上没问题的配置”每一条配置都必须在新系统上重新验证一遍。6. 压测与稳定性观察换系统后到底行不行6.1 基准测试方案设计迁移完成后我们对核心服务做了一轮压测。工具组合很常规CPU和内存sysbench cpu --threads32 run、sysbench memory run磁盘fio分别测顺序读、随机读、顺序写、随机写网络wrk压Nginx接口iperf3测内网带宽数据库sysbench oltp_read_write模拟高并发读写每项测试至少跑三遍取中位数排除偶然波动。对比对象是迁移前CentOS上的同版本测试数据。6.2 性能对比结果一览以我们一台双路至强、NVMe SSD、128G内存的测试服务器为例迁移后主要指标如下网络并发连接数提升约8%得益于somaxconn调大和内核协议栈优化。磁盘随机写延迟降低约12%dirty_ratio调低后的效果。MySQL只读QPS提升约6%整体表现符合预期。最惊喜的是内存回收更平滑swappiness10后压测期间几乎不再出现swap波动。整体来说欧拉在同等硬件下的性能没有倒退部分场景还有提升。对于追求极致性能的团队这是个值得考虑的信号。6.3 长稳运行观察项建议性能只是起点稳定性才是生产系统的生命线。我们上线后重点关注五项指标内存水位通过free -h和vmstat观察是否存在缓慢泄漏。内核日志dmesg -T和journalctl -k是否有异常软锁、OOM事件。磁盘健康用smartctl -a定期看SSD的磨损度和重分配扇区。网络重传率netstat -s | grep retransmit如果持续攀升要排查MTU和网卡驱动。服务重启次数看systemctl状态里每个服务的NRestarts异常重启往往被忽略。我们按照这套观察体系跑了一个多月系统稳定无异常重启。期间只做了一次内核小版本更新dnf源里推送的安全补丁也正常安装。7. 迁移完成后的一点实操心得如果让我总结这次从CentOS到欧拉的切换最核心的一句话是系统本身迁移不难难的是业务适配的耐心和排查问题的系统性。有几个经验想分享给后面接手的人。第一迁移前务必把业务依赖盘清楚尤其那些用老编译环境构建的组件提前确定是源码重编还是容器隔离不要拖到上线前才决定。第二调优参数要一条条验证不要成段复制外部教程很多旧参数新内核已经不需要了。第三容器化是解决历史遗留依赖的最稳妥手段欧拉对Podman的支持比我们预想得好跑老镜像非常顺滑。另外日常运维中建议把欧拉的版本升级纳入常规巡检安全补丁及时跟上。毕竟当初我们换系统很大一部分原因就是旧系统停更带来的安全焦虑。一个还在活跃维护、认证体系完善的操作系统配合合适的调优和规范的操作这个基础才真正稳固。