尧图网站建设 
RHEL9.7正式发布之后我接到的第一个生产级部署任务就是把一批新到的物理服务器装上9.7并完成系统层面的基础优化。这篇文章就是这次部署的完整记录从安装规划到内核参数调整从安全加固到性能调优全部是实际执行过的内容可直接作为你自己项目的参考。先说结论RHEL9.7不是一个颠覆性的大版本但它把9系累积的稳定性红利全释放出来了内核、工具链和系统服务都有明显打磨。对于生产环境来说只要把部署后的优化做扎实它会是一台非常省心的机器。下面按照我的实施顺序来拆解。1. 项目概述为什么在生产环境选择RHEL9.71.1 核心需求解析这个标题表面上只有“部署”和“优化”两个动作但落到实际项目里背后是一整套完整的需求链条。首先是系统选型RHEL9.7面向的是需要长期稳定运行的关键业务它继承了9系成熟的技术底座又加入了新的硬件支持和安全补丁所以适合作为数据库、中间件、容器宿主这类核心节点的基座系统。其次是优化这个动作。很多刚接触Linux运维的朋友会觉得装完系统就是结束其实恰恰相反装完才是开始。RHEL默认配置是“兼容优先”为了适配各种环境很多参数设计得偏保守比如内核调度、文件系统预读、网络缓冲区等都不是为特定业务最优的。部署后的优化就是把这些默认值调整为贴合实际负载的配置。第三个隐藏需求是合规和可维护性。生产服务器不是装完能开机就行还要考虑安全基线、日志留存、监控接入、后续审计这些长期维度。这部分在标题里没有明说但任何有经验的工程师在做部署时都会把它算进去。所以这篇博文的最终目标不是“系统跑起来了”而是“跑得稳、扛得住、查得清”。1.2 RHEL9.7的技术变化盘点RHEL9.7相比我之前长期使用的9.3和9.5有几个值得注意的变化点。首先是工具链更新GCC版本提升对现代C标准和底层编译优化支持更好如果你是做原生应用编译的这个升级感受会很明显。其次是内核层面的改进虽然RHEL9全系基于上游5.14内核分支但9.7反向移植了大量修复和新硬件驱动对最新的网络卡、存储卡兼容性更友好。另外9.7对Cockpit管理面板做了增强Web控制台的功能更完整了但如果你的环境不需要图形化管理界面部署时完全可以不启用它。安全层面OpenSSL和OpenSSH都更新到了修复已知漏洞的版本SHA-1签名相关的弱算法默认更严格地被限制。这些更新都没有改变原有操作习惯RHEL9系用户迁到9.7基本没有学习成本。还有一点值得称道的是9.7延续了RHEL的十年支持周期承诺意味着这个系统可以在生产环境中稳定运行很久不需要频繁担心大版本被迫升级的问题。对于金融机构、制造业、政府内网这类对稳定性要求极高的环境这是选型时极大的加分项。2. 部署前的规划与安装实施2.1 硬件选型与分区方案设计安装之前我先把硬件规格和分区方案理清楚了。这个项目使用的是两颗32核的AMD EPYC处理器、512GB内存、两块1.92TB NVMe SSD做RAID1存放操作系统和应用程序、四块16TB SATA磁盘做数据盘。这类配置在当前的物理机部署中很典型分区方案必须提前规划才能避免后续扩容的麻烦。我的分区策略是这样的/boot单独分区1GB用于存放内核文件/boot/efi独立因为新机器默认走UEFI引导/根分区分配200GB作为系统核心文件的位置swap分区分配32GB这个大小我建议根据物理内存而非简单公式来计算待会儿细说。剩下的空间全部给/data数据分区用于承载业务数据。这里重点讲一下swap分区大小的计算。老教程喜欢写“swap等于内存的两倍”这种规则过时了。现代服务器物理内存都是GB级别起步如果分配超大swap反而会因为swap写入过多拖垮整机性能。我的经验是内存在16GB到64GB之间的swap设置为内存的一半到等量内存超过128GB的swap固定给32GB就够用了。关键在于系统OOM时能有一个兜底而不是依赖swap撑性能。分区还要考虑的是NVMe SSD与SATA盘的分工。操作系统和程序跑在NVMe盘上追求低延迟和随机读写性能数据盘用SATA盘组成RAID或直通承载顺序读写为主的大文件业务。这样的分层设计相比把所有磁盘全组一个大RAID单点故障影响更小而且性价比更高。2.2 安装方式选择与自动应答配置RHEL9.7提供两种主流安装路径交互式的图形安装和基于Kickstart的自动化安装。我在这个项目中选择了Kickstart原因很现实服务器不止一台手动点图形安装意味着每台机器都要守着屏幕点完一个又一个配置项效率低且极易出错。自动化安装可以把磁盘分区、root密码、时区、软件包选择全部固化在一个配置文件中一次写好反复使用。写Kickstart文件时要注意几个关键参数。clearpart --all --initlabel会清除目标磁盘上所有分区并重新初始化执行时务必确认是对应正确的磁盘否则后果不堪设想。软件包选择上我直接指定了core和standard两组满足基础设施需要后续需要的软件再用dnf补充安装避免安装一堆用不上的包。安装启动时还需要配置安装源。RHEL官方订阅源在联外网的环境下是首选但考虑到很多生产环境有隔离网络离线安装就必须提前准备好本地YUM源。我的做法是准备一台仓库服务器把RHEL9.7的ISO文件挂载到NFS或HTTP共享出来Kickstart文件里用url --urlhttp://repo-server/rhel9.7来指定。这样整套安装流程不依赖外网内网环境下反复部署也毫无压力。最后别忘了在Kickstart中使用%post段这是部署后可执行自定义脚本的入口。我就在%post里完成了yum源替换、常用工具安装、内核参数预置、时区同步等操作这样安装完成后系统直接进入可用状态省去后续大量手工配置环节也降低了漏配少配的风险。3. 安装后的基础环境优化3.1 内核与引导参数调整系统安装完成后第一件事是检查当前内核版本然后着手调整内核启动参数。grubby命令是RHEL系修改内核参数最直接的工具比如我要为所有内核条目设置默认参数可以使用grubby --update-kernelALL --argsquiet这样的方式完成修改。下面说一个生产服务器上非常关键的调优参数默认的内核参数quiet在生产环境建议保留但额外追加ipv6.disable0来显式启用IPv6同时通过禁用IPv6的自动配置来避免地址冲突。实际上根据业务需要更常见的做法是用net.ipv6.conf.all.disable_ipv61在内核层彻底关闭IPv6在没有IPv6规划的内网环境里这是最省心的选择。另外对于物理服务器建议追加nowatchdog参数它用于禁用硬件看门狗。别小看这个参数在部分服务器上如果不禁用看门狗一旦系统负载异常或卡死自动重启看门狗触发的软锁检测消息会刷爆控制台干扰正常的巡检排查。但这个参数要分级对待如果有专门的硬件监控体系可以保留看门狗否则还是关掉更保险。改完内核参数后要立即验证。grubby --infoALL可以查看当前所有内核条目各自的参数内容也可以直接重启后用cat /proc/cmdline确认实际生效的引导参数。生产环境中改引导参数最忌讳只改不验等下一次真实重启才发现参数不生效那就是事故了。3.2 软件包裁剪与遗留服务治理RHEL9.7作为通用发行版默认安装时即便选择了最小化安装仍然会带入一些生产环境用不到的服务。这些多余服务并非一无是处但每多一个监听端口就是多一个潜在的攻击面。所以安装完成后我会逐个审视systemd服务把不需要的直接禁用。比如postfix邮件服务在生产服务器上几乎没有存在的意义系统告警一般会走独立的监控通道avahi-daemon这个mDNS/DNS-SD发现服务在服务器环境也是典型的无用项还有图形相关的服务、蓝牙服务之类在物理服务器上更是完全多余。对这些服务执行systemctl disable --now后既减少了内存占用也降低了安全隐患。但服务裁剪必须带着判断力做不能一刀切。像sshd、NetworkManager、chronyd这些系统基础设施是绝对不能动的。特别是NetworkManager虽然命令行下用nmcli不像直接编辑配置文件那样“老派”但它在处理网卡热插拔、多网卡绑定、VLAN配置时优势极其明显生产环境中建议保留作为网络管理核心。软件包层面的裁剪我习惯使用dnf remove清理明确不要的安装包但这条命令的破坏力极大有些包之间存在隐性的依赖关系移除一个主包会连带删除十几个依赖包。所以执行前先用dnf remove --assumeno做个预演看依赖结果等确认无误后再实际执行这个习惯可以帮你在生产环境下避开大量麻烦。3.3 关键基础工具补装与时钟同步设置基础工具这块我强烈建议安装sysstat、lsof、nc、tcpdump、bind-utils这几件套。它们堪称服务器上的“瑞士军刀”。sysstat提供mpstat、iostat、sar等系统性能采集命令排查CPU和磁盘问题时几乎离不开它们lsof用于排查进程打开了哪些文件定位“磁磁盘忙但找不到文件”这类诡异问题特别有效。nc和tcpdump则是网络排查的利器。nc用来快速验证端口连通性tcpdump用来做深度的TCP/IP层抓包分析。虽然这些工具在日常工作中用得不多但真正遇到生产故障时缺了它们你连排查方向都找不着。别心疼那几十MB磁盘空间这些工具在关键时刻的救命价值远超占用。时区与时间同步是另一个必须处理的基础项。服务器时区统一设定为Asia/Shanghaitimedatectl set-timezone Asia/Shanghai。然后确认chronyd服务运行正常chronyc sources -v命令可以检查当前的时间同步源状态。时间同步不是小事频繁业务日志的时间戳一旦错乱排查问题时会绕大量的远路。时间同步配置里我见过一个比较隐蔽的坑如果环境所在地与时间服务器之间网络质量差或延迟大chronyd默认的makestep策略可能会导致启动阶段时间未校准成功。建议在/etc/chrony.conf中追加makestep 1 3配置意为前三次时钟更新允许一步校准大偏差之后自动切换为缓慢微调。这个参数既保证了启动时快速对时又不影响运行中的平滑调整。4. 系统安全加固与合规配置4.1 SELinux与防火墙策略落地刚接触RHEL的人第一个想关闭的往往是SELinux因为它确实会带来一些权限上的困惑。但在这个项目中我的原则是无论如何都保持SELinux开启强制模式。RHEL的SELinux策略已经打磨得非常成熟真正导致业务受阻的大多是管理员不熟悉规则、没有为应用配置正确的上下文标签而不是SELinux本身有问题。你会问SELinux开启状态下如果遇到应用起不来的情况怎么办正确办法是排查而不是关闭。先用ausearch -m avc查看是否有SELinux的拒绝日志确认是类型标签错误还是布尔值没有打开然后针对性地修正。比如Web服务要读写非默认目录时用semanage fcontext -a -t httpd_sys_content_t添加文件上下文规则再执行restorecon -Rv应用这类操作在官方文档里都有明确指引。防火墙策略实践上我建议只在服务器上开放真正对外的端口。用firewall-cmd --permanent --add-servicehttp来放行HTTP流量用firewall-cmd --reload让策略生效。修改策略后第一件事就是验证是否能够正常连接——很多运维事故都是防火墙策略改了之后管理通道被切断人还在机房外面只能在控制台里狼狈地恢复这种经历属实不好受。对于需要限制来源IP的端口比如数据库端口或SSH端口建议直接配置富规则。firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.0.0/24 port protocoltcp port5432 accept这样的写法可以把访问范围限制在可靠网段内兼顾安全性和可用性。4.2 SSH加固与口令策略调整SSH是服务器对外暴露最频繁的服务也是暴力破解的头号目标。系统装好后的第一时间我就会编辑/etc/ssh/sshd_config完成以下调整把PermitRootLogin设为no禁止root直接登录把PasswordAuthentication设为no前提是所有管理员都已部署密钥迫使登录过程必须使用密钥认证。这两个改动组合起来能阻挡绝大多数扫描爆破行为。同时修改SSH监听端口也是一种常见做法。虽然不能把安全完全寄托在端口隐蔽上但把22换成高位端口确实能大幅减少扫描器的无效连接数。这需要把Port参数改成自定义端口完成后记得在防火墙里开放新端口并重启sshd服务。重要提示不要在改配置时把22端口的防火墙规则直接删掉先开新端口、确认登录成功后再撤旧规则这是不会切断自己后路的标准操作。口令策略层面我建议直接修改/etc/login.defs和/etc/security/pwquality.conf。前一个文件里调整密码最长使用天数、最短修改间隔、过期前警告天数后一个文件里设置最小密码长度和复杂度要求。不要低估这些基础策略的作用对于等保测评或行业合规检查来说这些配置项都是评分点提前设好能省很多返工时间。修改这些文件后建议用chage -l 用户名命令查看某个账户的密码策略生效情况同时用ssh -o PubkeyAuthenticationyes手动验证一遍密钥登录是否正常。系统安全配置的每一步都讲究“改完即验”千万敛着性子别把验证拖到下次全员登录时才做。4.3 账号权限与审计日志配置账号权限管理的第一原则是最小权限。我给每个需要登录服务器的工程师都创建独立的普通用户账号并把有sudo需求的账号加入wheel组而不是让所有人直接使用root。这样做的好处很明显任何人执行特权操作都会留下审计记录出了安全事故按日志追责清清楚楚同时每个人都有自己的操作凭据不需要共享密码。sudo权限的配置建议不要直接改/etc/sudoers文件而是使用visudo命令编辑。visudo内置语法检查机制哪怕你写错了配置也能及时报错阻止保存避免因为一处拼写错误导致sudo彻底不可用。如果需要对特定账号限制特权命令范围可以在/etc/sudoers.d/下创建独立文件这样管理更清晰。审计方面启用auditd服务是标准动作。RHEL9.7默认安装了auditd但没有配置足够的规则我至少会补充两类监控一是对/etc/passwd、/etc/shadow、/etc/sudoers等关键文件的写操作监控二是对/usr/bin/su、/usr/bin/sudo等特权命令执行的记录。这些规则用auditctl -w命令配合永久规则文件/etc/audit/rules.d/audit.rules一起完成。日志层面的持久化同样是重点。默认的rsyslog会把系统日志记录到/var/log/messages、/var/log/secure等文件但有些服务日志如containerd的日志默认并不会被系统日志集合。建议在rsyslog配置中单独添加规则把重要服务的日志主动采集到统一目录方便后续接入集中日志平台。完成配置后用logger test写入一条测试日志然后tail对应日志文件确认采集链路是通的。5. 性能调优实践5.1 CPU与内存性能相关参数先声明一个原则现代Linux内核的默认CPU调度器如deadline或cfs已经足够优秀绝不要在通用服务器上随便改用performance或powersave之外的cpu频率调节器更不要去动isolcpus这类高级参数除非你非常清楚业务的具体行为特征。盲目的参数修改带来的性能负收益远比正收益常见。不过有两类参数我会做调整一是针对高吞吐业务开启CPU频率调节器的performance模式明确让CPU运行在最高频率档位降低调度延迟。方式是用cpupower frequency-set -g performance命令设置。二是针对NUMA架构服务器尽量让应用绑定在本节点的CPU和内存上运行避免跨NUMA访问造成的内存延迟。配合numactl命令为进程设置CPU亲和性和内存策略能获得明显体感提升。内存方面最重要的一个参数是vm.swappiness。默认值通常是30但对于内存充裕的服务器而言这个值导致内核在内存压力尚不明显时就把冷页面换到swap反而增加了不必要的IO开销。我一般会把它调整为10甚至更低比如sysctl -w vm.swappiness10并写入/etc/sysctl.conf持久化。这样系统会更倾向驻留内存页面减少swap读写频率。另一个与内存相关但经常被忽略的参数是vm.overcommit_memory。对于运行Java或内存型数据库的服务器我建议使用vm.overcommit_memory1始终允许超量分配配合vm.overcommit_ratio来控制超量比例。这样能避免申请大块内存时被内核拒绝的问题。但如果你运行的是稳定性优先的传统应用且内存规划精确保持默认的启发式策略反而更稳妥。5.2 文件系统与磁盘调度优化磁盘层面的性能优化首先要选对IO调度器。NVMe SSD几乎应该无视调度器使用none也就是noop模式而机械硬盘在传统模式下使用mq-deadline或bfq会更合理。查看当前调度器用cat /sys/block/sdb/queue/scheduler修改则通过udev规则或内核参数持久化。/etc/udev/rules.d/60-io-scheduler.rules的写法可以这样ACTIONadd|change, KERNELsd*, ATTR{queue/scheduler}none。但这个写法需要留意机械盘与SSD并存的情况最好用/sys/block/sdb/queue/rotational属性来判断磁盘类型只是udev规则并不能直接读取这个属性所以很多时候我更推荐使用systemd-tmpfiles或直接在内核引导参数中处理。文件系统的挂载参数也需要根据业务场景细调。ext4和xfs是RHEL9.7默认支持度最好的两个文件系统数据盘我推荐xfs。挂载参数上对于存放数据库文件的目录建议加上noatime禁用访问时间更新减少不必要的元数据写入对于要求掉电一致性的场景nobarrier这类参数就要谨慎一般不推荐在生产库上设置。预读值read_ahead_kb是另一个影响文件读性能的参数。默认的128KB对于大文件顺序读偏低我习惯通过blockdev --setra把SSD数据盘的预读调大到8192KB。调整后可以用iostat -x 1观察rMB/s变化来验证效果如果你看到顺序读速率显著提升说明预读配置对业务产生了正向影响。5.3 网络栈参数调优网络优化可能是整个调优环节最难量化的部分但也是最容易出问题的部分。我先把一个非改不可的参数列出来net.core.somaxconn它控制服务器端接受TCP连接请求的队列长度默认值为128在高并发快速连接建立的场景下极容易丢连接。我会调整到4096或更高。再一个常见瓶颈是文件句柄限制。ulimit -n默认的1024对生产环境来说实在太少尤其是作为Web后端或中间件服务器时并发连接一上来就报“Too many open files”错误。我会在/etc/security/limits.conf中把普通用户的nofile设为65535同时调整系统的fs.file-max实现两层兜底。网络内存方面TCP连接的读写缓冲区需要根据网络带宽和延迟适当放大。net.ipv4.tcp_rmem与net.ipv4.tcp_wmem默认的第三档数值对跨机房、跨地域的高带宽连接不够充裕。我建议先通过iperf3做一次基础打流测试根据实际观测到的吞吐量和重传率来确定调整幅度不要盲目把缓冲区设到极大值否则反而增加内存占用和延迟。还有一个容易被忽略的参数是net.ipv4.tcp_tw_reuse对于大量短连接业务启用该参数可以安全复用TIME_WAIT状态的连接。注意这里说的是tcp_tw_reuse而不是tcp_tw_recycle后者在高版本Linux中已经被移除了因为它会引入严重的时间戳混乱问题千万不能用。6. 监控与运维闭环6.1 性能工具链搭建调优效果好不好最终要靠监控数据说话。只调不测等于白调甚至可能导致负优化而不自知。我的做法是在部署优化后立刻使用工具做性能基线采集用mpstat记录CPU使用率分布用iostat记录磁盘IOPS和吞吐用pidstat记录关键进程的资源消耗用sar按天保存历史数据。sar的数据留存能力是非常实用的。只要/etc/cron.d/sysstat定时任务正常运行系统就能自动采集并保存历史性能数据。这意味着调优后隔一周可以拉出昨天的CPU、内存、IO曲线和基线做对比验证优化是否真的带来了改善。凡是不做基线记录的调优都是耍流氓事后根本无法判断某个参数改对了还是改错了。对于需要直观可视化的场景我推荐部署一套轻量的监控栈如Prometheus加node_exporter。node_exporter将RHEL9.7的系统指标以Prometheus格式暴露再配合Grafana模板即可看到CPU、内存、网络、磁盘的实时图表。如果你的环境已有监控体系直接部署node_exporter把数据接进现有平台是最省力的选择。做监控的人要记住一条告警阈值不能照抄模板。每台服务器的硬件和业务形态不同比如内存告警线设在90%对于内存型中间件可能是常态值对于普通业务却可能是危险信号。我习惯根据两周的监控数据来动态调整告警基线把正常波动排除在告警之外。6.2 日志全量采集与管理策略日志是定位问题的第一手素材。生产服务器上我至少会保证覆盖这些日志路径/var/log/messages、/var/log/secure、/var/log/cron、/var/log/audit/audit.log以及数据库、Nginx等业务应用的独立日志目录。日志轮转是必须主动确认的环节。RHEL通过logrotate管理日志切割特别是/etc/logrotate.d/下的应用日志轮转配置有时默认规则不够针对性。例如应用日志量很大时可把daily改为hourly保留7份到14份关键是日志增长速率要匹配轮转频率否则哪天磁盘被日志写满你就知道什么叫“痛”。集中日志平台在这一步可以顺手接入。现在主流方案是filebeat加Elasticsearch加Kibana的组合或者更轻量的Loki。对于不想引入重组件的环境最简单的方案是用rsyslog把各服务器日志转发到一台日志中心服务器再在那台机器上做统一归档与检索。日志集中化最大的价值不在于存储而在于故障发生时能跨系统、跨时间维度地关联分析这对排查分布式问题几乎是刚需。6.3 日常巡检脚本与自动化准备部署完成后我最后会交一套简易巡检脚本给负责运维的同事。脚本基于bash实现用vmstat、iostat、ss这些自带命令采集当前状态判断是否出现CPU软中断过高、内存濒临耗尽、磁盘IO等待过久、端口监听异常等情况如有异常直接输出中英文告警摘要。脚本的逻辑不复杂核心价值在于标准化。把“如何判断一台服务器是否健康”这个经验固化成一套可重复执行的检查项任何值班人员跑一下就能快速了解整机的运行态势。这比依赖某一个老工程师“凭感觉看看”要靠谱得多也能在人员变动时把运维经验留在脚本里而不是只存在于某个人的脑子里。自动化方向我建议将整个部署和优化过程用Ansible固化成playbook。从分区方案、软件安装、内核参数到安全加固、监控部署所有步骤都用代码表达到新机房或新增服务器时一键执行实现“同样的配置可以在任何时候完整复现”。当前团队的节奏来看每台服务器的手工部署已经压缩到30分钟以内后续再用Ansible套上企鹅就彻底解放了人力。7. 部署优化中的避坑实战与自查清单7.1 我实际踩过的坑与排查过程说完顺利的部分必须记录一下这次部署中踩过的三个比较有代表性的坑。第一个坑是内核参数调整后没有做持久化。我在某个节点上执行sysctl -w net.core.somaxconn4096当时测试效果很好连接排队问题明显缓解。但因为我没有把它写入/etc/sysctl.conf等三天后服务器例行重启这个参数又回到了默认的128业务瞬间出现大量连接超时。那次教训让我把“所有运行时参数调整都必须对应持久化文件”列成了铁律。第二个坑是防火墙端口误封导致远程连接中断。在调整SSH端口时我在防火墙里添加了新端口规则但忘了执行--reload随后直接重启sshd。结果新端口没有放行旧端口已经失效连接直接断开。最后只能通过带外管理卡登录恢复。这个问题的核心教训就一条对远程服务的配置变更绝不能在同一个操作序列中断开原有的访问路径。第三个坑是关于设置磁盘IO调度器的udev规则。我给所有sd*设备设置了none调度器结果机械盘和NVMe盘都收到了同一条规则导致机械盘的调度器被错误地改成了none。虽然工作负载下没有立刻产生大问题但这属于该报错却没报错的隐患。从那之后我对udev规则里的匹配条件格外小心一定要精确定位到具体设备类型再套用配置。7.2 部署后的自查清单最后分享一份我在所有RHEL9.7部署完成后都会跑一遍的自查清单适合在项目交付时使用第一组是基础项uname -r确认内核版本符合预期hostnamectl查看主机名、时区和操作系统版本uptime确认机器没有意外重启过df -h确认分区挂载与容量规划一致。第二组是安全项getenforce确认SELinux处于Enforcing状态firewall-cmd --list-all确认端口策略ss -lntp检查监听端口是否有异常服务cat /etc/ssh/sshd_config核对root登录与密码认证状态。第三组是性能项cat /proc/cmdline验证内核引导参数sysctl -p确认sysctl配置全部生效free -h确认内存使用合理iostat -x 1观察无负载时的IO状况cat /sys/block/sda/queue/scheduler确认IO调度器符合预期。这三组检查全部通过后我才会把服务器正式移交业务团队使用。这套清单看起来简单但每次都能真的检查出几个疏漏建议大家也照此操作别嫌繁琐。 RHEL9.7生产环境部署与性能优化实战指南
RHEL9.7正式发布之后我接到的第一个生产级部署任务就是把一批新到的物理服务器装上9.7并完成系统层面的基础优化。这篇文章就是这次部署的完整记录从安装规划到内核参数调整从安全加固到性能调优全部是实际执行过的内容可直接作为你自己项目的参考。先说结论RHEL9.7不是一个颠覆性的大版本但它把9系累积的稳定性红利全释放出来了内核、工具链和系统服务都有明显打磨。对于生产环境来说只要把部署后的优化做扎实它会是一台非常省心的机器。下面按照我的实施顺序来拆解。1. 项目概述为什么在生产环境选择RHEL9.71.1 核心需求解析这个标题表面上只有“部署”和“优化”两个动作但落到实际项目里背后是一整套完整的需求链条。首先是系统选型RHEL9.7面向的是需要长期稳定运行的关键业务它继承了9系成熟的技术底座又加入了新的硬件支持和安全补丁所以适合作为数据库、中间件、容器宿主这类核心节点的基座系统。其次是优化这个动作。很多刚接触Linux运维的朋友会觉得装完系统就是结束其实恰恰相反装完才是开始。RHEL默认配置是“兼容优先”为了适配各种环境很多参数设计得偏保守比如内核调度、文件系统预读、网络缓冲区等都不是为特定业务最优的。部署后的优化就是把这些默认值调整为贴合实际负载的配置。第三个隐藏需求是合规和可维护性。生产服务器不是装完能开机就行还要考虑安全基线、日志留存、监控接入、后续审计这些长期维度。这部分在标题里没有明说但任何有经验的工程师在做部署时都会把它算进去。所以这篇博文的最终目标不是“系统跑起来了”而是“跑得稳、扛得住、查得清”。1.2 RHEL9.7的技术变化盘点RHEL9.7相比我之前长期使用的9.3和9.5有几个值得注意的变化点。首先是工具链更新GCC版本提升对现代C标准和底层编译优化支持更好如果你是做原生应用编译的这个升级感受会很明显。其次是内核层面的改进虽然RHEL9全系基于上游5.14内核分支但9.7反向移植了大量修复和新硬件驱动对最新的网络卡、存储卡兼容性更友好。另外9.7对Cockpit管理面板做了增强Web控制台的功能更完整了但如果你的环境不需要图形化管理界面部署时完全可以不启用它。安全层面OpenSSL和OpenSSH都更新到了修复已知漏洞的版本SHA-1签名相关的弱算法默认更严格地被限制。这些更新都没有改变原有操作习惯RHEL9系用户迁到9.7基本没有学习成本。还有一点值得称道的是9.7延续了RHEL的十年支持周期承诺意味着这个系统可以在生产环境中稳定运行很久不需要频繁担心大版本被迫升级的问题。对于金融机构、制造业、政府内网这类对稳定性要求极高的环境这是选型时极大的加分项。2. 部署前的规划与安装实施2.1 硬件选型与分区方案设计安装之前我先把硬件规格和分区方案理清楚了。这个项目使用的是两颗32核的AMD EPYC处理器、512GB内存、两块1.92TB NVMe SSD做RAID1存放操作系统和应用程序、四块16TB SATA磁盘做数据盘。这类配置在当前的物理机部署中很典型分区方案必须提前规划才能避免后续扩容的麻烦。我的分区策略是这样的/boot单独分区1GB用于存放内核文件/boot/efi独立因为新机器默认走UEFI引导/根分区分配200GB作为系统核心文件的位置swap分区分配32GB这个大小我建议根据物理内存而非简单公式来计算待会儿细说。剩下的空间全部给/data数据分区用于承载业务数据。这里重点讲一下swap分区大小的计算。老教程喜欢写“swap等于内存的两倍”这种规则过时了。现代服务器物理内存都是GB级别起步如果分配超大swap反而会因为swap写入过多拖垮整机性能。我的经验是内存在16GB到64GB之间的swap设置为内存的一半到等量内存超过128GB的swap固定给32GB就够用了。关键在于系统OOM时能有一个兜底而不是依赖swap撑性能。分区还要考虑的是NVMe SSD与SATA盘的分工。操作系统和程序跑在NVMe盘上追求低延迟和随机读写性能数据盘用SATA盘组成RAID或直通承载顺序读写为主的大文件业务。这样的分层设计相比把所有磁盘全组一个大RAID单点故障影响更小而且性价比更高。2.2 安装方式选择与自动应答配置RHEL9.7提供两种主流安装路径交互式的图形安装和基于Kickstart的自动化安装。我在这个项目中选择了Kickstart原因很现实服务器不止一台手动点图形安装意味着每台机器都要守着屏幕点完一个又一个配置项效率低且极易出错。自动化安装可以把磁盘分区、root密码、时区、软件包选择全部固化在一个配置文件中一次写好反复使用。写Kickstart文件时要注意几个关键参数。clearpart --all --initlabel会清除目标磁盘上所有分区并重新初始化执行时务必确认是对应正确的磁盘否则后果不堪设想。软件包选择上我直接指定了core和standard两组满足基础设施需要后续需要的软件再用dnf补充安装避免安装一堆用不上的包。安装启动时还需要配置安装源。RHEL官方订阅源在联外网的环境下是首选但考虑到很多生产环境有隔离网络离线安装就必须提前准备好本地YUM源。我的做法是准备一台仓库服务器把RHEL9.7的ISO文件挂载到NFS或HTTP共享出来Kickstart文件里用url --urlhttp://repo-server/rhel9.7来指定。这样整套安装流程不依赖外网内网环境下反复部署也毫无压力。最后别忘了在Kickstart中使用%post段这是部署后可执行自定义脚本的入口。我就在%post里完成了yum源替换、常用工具安装、内核参数预置、时区同步等操作这样安装完成后系统直接进入可用状态省去后续大量手工配置环节也降低了漏配少配的风险。3. 安装后的基础环境优化3.1 内核与引导参数调整系统安装完成后第一件事是检查当前内核版本然后着手调整内核启动参数。grubby命令是RHEL系修改内核参数最直接的工具比如我要为所有内核条目设置默认参数可以使用grubby --update-kernelALL --argsquiet这样的方式完成修改。下面说一个生产服务器上非常关键的调优参数默认的内核参数quiet在生产环境建议保留但额外追加ipv6.disable0来显式启用IPv6同时通过禁用IPv6的自动配置来避免地址冲突。实际上根据业务需要更常见的做法是用net.ipv6.conf.all.disable_ipv61在内核层彻底关闭IPv6在没有IPv6规划的内网环境里这是最省心的选择。另外对于物理服务器建议追加nowatchdog参数它用于禁用硬件看门狗。别小看这个参数在部分服务器上如果不禁用看门狗一旦系统负载异常或卡死自动重启看门狗触发的软锁检测消息会刷爆控制台干扰正常的巡检排查。但这个参数要分级对待如果有专门的硬件监控体系可以保留看门狗否则还是关掉更保险。改完内核参数后要立即验证。grubby --infoALL可以查看当前所有内核条目各自的参数内容也可以直接重启后用cat /proc/cmdline确认实际生效的引导参数。生产环境中改引导参数最忌讳只改不验等下一次真实重启才发现参数不生效那就是事故了。3.2 软件包裁剪与遗留服务治理RHEL9.7作为通用发行版默认安装时即便选择了最小化安装仍然会带入一些生产环境用不到的服务。这些多余服务并非一无是处但每多一个监听端口就是多一个潜在的攻击面。所以安装完成后我会逐个审视systemd服务把不需要的直接禁用。比如postfix邮件服务在生产服务器上几乎没有存在的意义系统告警一般会走独立的监控通道avahi-daemon这个mDNS/DNS-SD发现服务在服务器环境也是典型的无用项还有图形相关的服务、蓝牙服务之类在物理服务器上更是完全多余。对这些服务执行systemctl disable --now后既减少了内存占用也降低了安全隐患。但服务裁剪必须带着判断力做不能一刀切。像sshd、NetworkManager、chronyd这些系统基础设施是绝对不能动的。特别是NetworkManager虽然命令行下用nmcli不像直接编辑配置文件那样“老派”但它在处理网卡热插拔、多网卡绑定、VLAN配置时优势极其明显生产环境中建议保留作为网络管理核心。软件包层面的裁剪我习惯使用dnf remove清理明确不要的安装包但这条命令的破坏力极大有些包之间存在隐性的依赖关系移除一个主包会连带删除十几个依赖包。所以执行前先用dnf remove --assumeno做个预演看依赖结果等确认无误后再实际执行这个习惯可以帮你在生产环境下避开大量麻烦。3.3 关键基础工具补装与时钟同步设置基础工具这块我强烈建议安装sysstat、lsof、nc、tcpdump、bind-utils这几件套。它们堪称服务器上的“瑞士军刀”。sysstat提供mpstat、iostat、sar等系统性能采集命令排查CPU和磁盘问题时几乎离不开它们lsof用于排查进程打开了哪些文件定位“磁磁盘忙但找不到文件”这类诡异问题特别有效。nc和tcpdump则是网络排查的利器。nc用来快速验证端口连通性tcpdump用来做深度的TCP/IP层抓包分析。虽然这些工具在日常工作中用得不多但真正遇到生产故障时缺了它们你连排查方向都找不着。别心疼那几十MB磁盘空间这些工具在关键时刻的救命价值远超占用。时区与时间同步是另一个必须处理的基础项。服务器时区统一设定为Asia/Shanghaitimedatectl set-timezone Asia/Shanghai。然后确认chronyd服务运行正常chronyc sources -v命令可以检查当前的时间同步源状态。时间同步不是小事频繁业务日志的时间戳一旦错乱排查问题时会绕大量的远路。时间同步配置里我见过一个比较隐蔽的坑如果环境所在地与时间服务器之间网络质量差或延迟大chronyd默认的makestep策略可能会导致启动阶段时间未校准成功。建议在/etc/chrony.conf中追加makestep 1 3配置意为前三次时钟更新允许一步校准大偏差之后自动切换为缓慢微调。这个参数既保证了启动时快速对时又不影响运行中的平滑调整。4. 系统安全加固与合规配置4.1 SELinux与防火墙策略落地刚接触RHEL的人第一个想关闭的往往是SELinux因为它确实会带来一些权限上的困惑。但在这个项目中我的原则是无论如何都保持SELinux开启强制模式。RHEL的SELinux策略已经打磨得非常成熟真正导致业务受阻的大多是管理员不熟悉规则、没有为应用配置正确的上下文标签而不是SELinux本身有问题。你会问SELinux开启状态下如果遇到应用起不来的情况怎么办正确办法是排查而不是关闭。先用ausearch -m avc查看是否有SELinux的拒绝日志确认是类型标签错误还是布尔值没有打开然后针对性地修正。比如Web服务要读写非默认目录时用semanage fcontext -a -t httpd_sys_content_t添加文件上下文规则再执行restorecon -Rv应用这类操作在官方文档里都有明确指引。防火墙策略实践上我建议只在服务器上开放真正对外的端口。用firewall-cmd --permanent --add-servicehttp来放行HTTP流量用firewall-cmd --reload让策略生效。修改策略后第一件事就是验证是否能够正常连接——很多运维事故都是防火墙策略改了之后管理通道被切断人还在机房外面只能在控制台里狼狈地恢复这种经历属实不好受。对于需要限制来源IP的端口比如数据库端口或SSH端口建议直接配置富规则。firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.10.0.0/24 port protocoltcp port5432 accept这样的写法可以把访问范围限制在可靠网段内兼顾安全性和可用性。4.2 SSH加固与口令策略调整SSH是服务器对外暴露最频繁的服务也是暴力破解的头号目标。系统装好后的第一时间我就会编辑/etc/ssh/sshd_config完成以下调整把PermitRootLogin设为no禁止root直接登录把PasswordAuthentication设为no前提是所有管理员都已部署密钥迫使登录过程必须使用密钥认证。这两个改动组合起来能阻挡绝大多数扫描爆破行为。同时修改SSH监听端口也是一种常见做法。虽然不能把安全完全寄托在端口隐蔽上但把22换成高位端口确实能大幅减少扫描器的无效连接数。这需要把Port参数改成自定义端口完成后记得在防火墙里开放新端口并重启sshd服务。重要提示不要在改配置时把22端口的防火墙规则直接删掉先开新端口、确认登录成功后再撤旧规则这是不会切断自己后路的标准操作。口令策略层面我建议直接修改/etc/login.defs和/etc/security/pwquality.conf。前一个文件里调整密码最长使用天数、最短修改间隔、过期前警告天数后一个文件里设置最小密码长度和复杂度要求。不要低估这些基础策略的作用对于等保测评或行业合规检查来说这些配置项都是评分点提前设好能省很多返工时间。修改这些文件后建议用chage -l 用户名命令查看某个账户的密码策略生效情况同时用ssh -o PubkeyAuthenticationyes手动验证一遍密钥登录是否正常。系统安全配置的每一步都讲究“改完即验”千万敛着性子别把验证拖到下次全员登录时才做。4.3 账号权限与审计日志配置账号权限管理的第一原则是最小权限。我给每个需要登录服务器的工程师都创建独立的普通用户账号并把有sudo需求的账号加入wheel组而不是让所有人直接使用root。这样做的好处很明显任何人执行特权操作都会留下审计记录出了安全事故按日志追责清清楚楚同时每个人都有自己的操作凭据不需要共享密码。sudo权限的配置建议不要直接改/etc/sudoers文件而是使用visudo命令编辑。visudo内置语法检查机制哪怕你写错了配置也能及时报错阻止保存避免因为一处拼写错误导致sudo彻底不可用。如果需要对特定账号限制特权命令范围可以在/etc/sudoers.d/下创建独立文件这样管理更清晰。审计方面启用auditd服务是标准动作。RHEL9.7默认安装了auditd但没有配置足够的规则我至少会补充两类监控一是对/etc/passwd、/etc/shadow、/etc/sudoers等关键文件的写操作监控二是对/usr/bin/su、/usr/bin/sudo等特权命令执行的记录。这些规则用auditctl -w命令配合永久规则文件/etc/audit/rules.d/audit.rules一起完成。日志层面的持久化同样是重点。默认的rsyslog会把系统日志记录到/var/log/messages、/var/log/secure等文件但有些服务日志如containerd的日志默认并不会被系统日志集合。建议在rsyslog配置中单独添加规则把重要服务的日志主动采集到统一目录方便后续接入集中日志平台。完成配置后用logger test写入一条测试日志然后tail对应日志文件确认采集链路是通的。5. 性能调优实践5.1 CPU与内存性能相关参数先声明一个原则现代Linux内核的默认CPU调度器如deadline或cfs已经足够优秀绝不要在通用服务器上随便改用performance或powersave之外的cpu频率调节器更不要去动isolcpus这类高级参数除非你非常清楚业务的具体行为特征。盲目的参数修改带来的性能负收益远比正收益常见。不过有两类参数我会做调整一是针对高吞吐业务开启CPU频率调节器的performance模式明确让CPU运行在最高频率档位降低调度延迟。方式是用cpupower frequency-set -g performance命令设置。二是针对NUMA架构服务器尽量让应用绑定在本节点的CPU和内存上运行避免跨NUMA访问造成的内存延迟。配合numactl命令为进程设置CPU亲和性和内存策略能获得明显体感提升。内存方面最重要的一个参数是vm.swappiness。默认值通常是30但对于内存充裕的服务器而言这个值导致内核在内存压力尚不明显时就把冷页面换到swap反而增加了不必要的IO开销。我一般会把它调整为10甚至更低比如sysctl -w vm.swappiness10并写入/etc/sysctl.conf持久化。这样系统会更倾向驻留内存页面减少swap读写频率。另一个与内存相关但经常被忽略的参数是vm.overcommit_memory。对于运行Java或内存型数据库的服务器我建议使用vm.overcommit_memory1始终允许超量分配配合vm.overcommit_ratio来控制超量比例。这样能避免申请大块内存时被内核拒绝的问题。但如果你运行的是稳定性优先的传统应用且内存规划精确保持默认的启发式策略反而更稳妥。5.2 文件系统与磁盘调度优化磁盘层面的性能优化首先要选对IO调度器。NVMe SSD几乎应该无视调度器使用none也就是noop模式而机械硬盘在传统模式下使用mq-deadline或bfq会更合理。查看当前调度器用cat /sys/block/sdb/queue/scheduler修改则通过udev规则或内核参数持久化。/etc/udev/rules.d/60-io-scheduler.rules的写法可以这样ACTIONadd|change, KERNELsd*, ATTR{queue/scheduler}none。但这个写法需要留意机械盘与SSD并存的情况最好用/sys/block/sdb/queue/rotational属性来判断磁盘类型只是udev规则并不能直接读取这个属性所以很多时候我更推荐使用systemd-tmpfiles或直接在内核引导参数中处理。文件系统的挂载参数也需要根据业务场景细调。ext4和xfs是RHEL9.7默认支持度最好的两个文件系统数据盘我推荐xfs。挂载参数上对于存放数据库文件的目录建议加上noatime禁用访问时间更新减少不必要的元数据写入对于要求掉电一致性的场景nobarrier这类参数就要谨慎一般不推荐在生产库上设置。预读值read_ahead_kb是另一个影响文件读性能的参数。默认的128KB对于大文件顺序读偏低我习惯通过blockdev --setra把SSD数据盘的预读调大到8192KB。调整后可以用iostat -x 1观察rMB/s变化来验证效果如果你看到顺序读速率显著提升说明预读配置对业务产生了正向影响。5.3 网络栈参数调优网络优化可能是整个调优环节最难量化的部分但也是最容易出问题的部分。我先把一个非改不可的参数列出来net.core.somaxconn它控制服务器端接受TCP连接请求的队列长度默认值为128在高并发快速连接建立的场景下极容易丢连接。我会调整到4096或更高。再一个常见瓶颈是文件句柄限制。ulimit -n默认的1024对生产环境来说实在太少尤其是作为Web后端或中间件服务器时并发连接一上来就报“Too many open files”错误。我会在/etc/security/limits.conf中把普通用户的nofile设为65535同时调整系统的fs.file-max实现两层兜底。网络内存方面TCP连接的读写缓冲区需要根据网络带宽和延迟适当放大。net.ipv4.tcp_rmem与net.ipv4.tcp_wmem默认的第三档数值对跨机房、跨地域的高带宽连接不够充裕。我建议先通过iperf3做一次基础打流测试根据实际观测到的吞吐量和重传率来确定调整幅度不要盲目把缓冲区设到极大值否则反而增加内存占用和延迟。还有一个容易被忽略的参数是net.ipv4.tcp_tw_reuse对于大量短连接业务启用该参数可以安全复用TIME_WAIT状态的连接。注意这里说的是tcp_tw_reuse而不是tcp_tw_recycle后者在高版本Linux中已经被移除了因为它会引入严重的时间戳混乱问题千万不能用。6. 监控与运维闭环6.1 性能工具链搭建调优效果好不好最终要靠监控数据说话。只调不测等于白调甚至可能导致负优化而不自知。我的做法是在部署优化后立刻使用工具做性能基线采集用mpstat记录CPU使用率分布用iostat记录磁盘IOPS和吞吐用pidstat记录关键进程的资源消耗用sar按天保存历史数据。sar的数据留存能力是非常实用的。只要/etc/cron.d/sysstat定时任务正常运行系统就能自动采集并保存历史性能数据。这意味着调优后隔一周可以拉出昨天的CPU、内存、IO曲线和基线做对比验证优化是否真的带来了改善。凡是不做基线记录的调优都是耍流氓事后根本无法判断某个参数改对了还是改错了。对于需要直观可视化的场景我推荐部署一套轻量的监控栈如Prometheus加node_exporter。node_exporter将RHEL9.7的系统指标以Prometheus格式暴露再配合Grafana模板即可看到CPU、内存、网络、磁盘的实时图表。如果你的环境已有监控体系直接部署node_exporter把数据接进现有平台是最省力的选择。做监控的人要记住一条告警阈值不能照抄模板。每台服务器的硬件和业务形态不同比如内存告警线设在90%对于内存型中间件可能是常态值对于普通业务却可能是危险信号。我习惯根据两周的监控数据来动态调整告警基线把正常波动排除在告警之外。6.2 日志全量采集与管理策略日志是定位问题的第一手素材。生产服务器上我至少会保证覆盖这些日志路径/var/log/messages、/var/log/secure、/var/log/cron、/var/log/audit/audit.log以及数据库、Nginx等业务应用的独立日志目录。日志轮转是必须主动确认的环节。RHEL通过logrotate管理日志切割特别是/etc/logrotate.d/下的应用日志轮转配置有时默认规则不够针对性。例如应用日志量很大时可把daily改为hourly保留7份到14份关键是日志增长速率要匹配轮转频率否则哪天磁盘被日志写满你就知道什么叫“痛”。集中日志平台在这一步可以顺手接入。现在主流方案是filebeat加Elasticsearch加Kibana的组合或者更轻量的Loki。对于不想引入重组件的环境最简单的方案是用rsyslog把各服务器日志转发到一台日志中心服务器再在那台机器上做统一归档与检索。日志集中化最大的价值不在于存储而在于故障发生时能跨系统、跨时间维度地关联分析这对排查分布式问题几乎是刚需。6.3 日常巡检脚本与自动化准备部署完成后我最后会交一套简易巡检脚本给负责运维的同事。脚本基于bash实现用vmstat、iostat、ss这些自带命令采集当前状态判断是否出现CPU软中断过高、内存濒临耗尽、磁盘IO等待过久、端口监听异常等情况如有异常直接输出中英文告警摘要。脚本的逻辑不复杂核心价值在于标准化。把“如何判断一台服务器是否健康”这个经验固化成一套可重复执行的检查项任何值班人员跑一下就能快速了解整机的运行态势。这比依赖某一个老工程师“凭感觉看看”要靠谱得多也能在人员变动时把运维经验留在脚本里而不是只存在于某个人的脑子里。自动化方向我建议将整个部署和优化过程用Ansible固化成playbook。从分区方案、软件安装、内核参数到安全加固、监控部署所有步骤都用代码表达到新机房或新增服务器时一键执行实现“同样的配置可以在任何时候完整复现”。当前团队的节奏来看每台服务器的手工部署已经压缩到30分钟以内后续再用Ansible套上企鹅就彻底解放了人力。7. 部署优化中的避坑实战与自查清单7.1 我实际踩过的坑与排查过程说完顺利的部分必须记录一下这次部署中踩过的三个比较有代表性的坑。第一个坑是内核参数调整后没有做持久化。我在某个节点上执行sysctl -w net.core.somaxconn4096当时测试效果很好连接排队问题明显缓解。但因为我没有把它写入/etc/sysctl.conf等三天后服务器例行重启这个参数又回到了默认的128业务瞬间出现大量连接超时。那次教训让我把“所有运行时参数调整都必须对应持久化文件”列成了铁律。第二个坑是防火墙端口误封导致远程连接中断。在调整SSH端口时我在防火墙里添加了新端口规则但忘了执行--reload随后直接重启sshd。结果新端口没有放行旧端口已经失效连接直接断开。最后只能通过带外管理卡登录恢复。这个问题的核心教训就一条对远程服务的配置变更绝不能在同一个操作序列中断开原有的访问路径。第三个坑是关于设置磁盘IO调度器的udev规则。我给所有sd*设备设置了none调度器结果机械盘和NVMe盘都收到了同一条规则导致机械盘的调度器被错误地改成了none。虽然工作负载下没有立刻产生大问题但这属于该报错却没报错的隐患。从那之后我对udev规则里的匹配条件格外小心一定要精确定位到具体设备类型再套用配置。7.2 部署后的自查清单最后分享一份我在所有RHEL9.7部署完成后都会跑一遍的自查清单适合在项目交付时使用第一组是基础项uname -r确认内核版本符合预期hostnamectl查看主机名、时区和操作系统版本uptime确认机器没有意外重启过df -h确认分区挂载与容量规划一致。第二组是安全项getenforce确认SELinux处于Enforcing状态firewall-cmd --list-all确认端口策略ss -lntp检查监听端口是否有异常服务cat /etc/ssh/sshd_config核对root登录与密码认证状态。第三组是性能项cat /proc/cmdline验证内核引导参数sysctl -p确认sysctl配置全部生效free -h确认内存使用合理iostat -x 1观察无负载时的IO状况cat /sys/block/sda/queue/scheduler确认IO调度器符合预期。这三组检查全部通过后我才会把服务器正式移交业务团队使用。这套清单看起来简单但每次都能真的检查出几个疏漏建议大家也照此操作别嫌繁琐。