RHCA04--系统模块管理与资源限制

一、课前回顾

1. 模块管理概念

• 一切皆模块：Linux认证系统中所有功能都以模块形式存在，包括驱动程序、文件系统、防火墙（如firewalld、SELinux）等。
• 管理方式：系统通过统一的模块机制来管理这些功能组件。

2. 动态加载与卸载

• 动态特性：模块采用动态加载机制，当系统检测到硬件设备时会自动加载对应模块。
• 自动卸载：当设备不存在时，系统会自动卸载相关模块，实现资源的高效管理。

3. 查询已加载模块

• 查看命令：使用lsmod命令可查询系统中所有已加载的模块。
• 输出内容：显示模块名称、占用内存大小和被引用次数三列信息。

4. 模块信息查看

• 详细信息：通过modinfo命令可查看模块的完整信息。
• 包含内容：显示模块文件路径、描述信息、作者、依赖关系以及可调参数等。

5. 模块参数调优

• 调优方法：在/etc/modprobe.d/目录下创建.conf配置文件。
• 配置格式：文件需包含“options 模块名 参数=值”的格式。
• 注意事项：可以直接修改现有配置文件，但需注意升级时可能被覆盖。

6. 启动过程中所需模块

• 特殊模块：系统启动时需要加载根文件系统对应的驱动模块。
• 加载时机：这些模块需要在挂载根文件系统之前就可用。

7. 系统启动流程

• 启动步骤：
  1. BIOS硬件自检
  2. 读取引导设备的引导扇区
  3. 加载GRUB2引导程序
  4. 加载内核和initramfs临时文件系统
  5. 以只读方式挂载根文件系统

8. 根文件系统驱动加载

• 驱动位置：根文件系统驱动通常位于/lib/modules/内核版本/kernel/fs/目录。
• 依赖关系：如xfs模块依赖libcrc32c模块，需同时加载。
• 路径问题：这些驱动存储在根文件系统中，导致“先有鸡还是先有蛋”的加载困境。

9. initramfs文件与驱动

• 解决方案：将关键驱动打包到initramfs镜像文件中。
• 加载过程：
  1. GRUB2读取/boot/initramfs-内核版本.img文件
  2. 在内存中解压该镜像
  3. 临时提供根文件系统所需的驱动模块
• 实际案例：演示了xfs.ko驱动确实存在于initramfs文件中。
• 故障现象：若驱动未正确包含在initramfs中，会导致“Kernel panic”启动失败。

二、系统启动模块及系统资源限制

1. 课程案例分享

（1）瑞丽卡驱动丢失问题

• 系统启动流程:
  • BIOS自检阶段：读取引导设备的引导扇区、读取引导程序。
  • GRUB2阶段：加载/boot分区、加载内核并以只读方式挂载根分区、加载init ramfs内存文件系统。
  • 注意：若根分区使用xfs文件系统，则需要xfs驱动。
• 案例背景:
  • RHEL5.4系统kernel 2.6.18-164.el5.x86_64可正常启动。
  • 客户使用DELL服务器（100多台）基于2.6.27内核进行研发工作。
  • 客户自行升级内核至2.6.27后系统无法启动。

（2）瑞丽卡驱动丢失原因分析

• 问题现象:
  • 系统启动时提示“Volume group not found”。
  • 无法挂载根文件系统。
  • 最终出现“Kernel panic - not syncing”错误。
• 根本原因:
  • 红帽5.4商业版内核包含常用硬件驱动。
  • 2.6.27开源内核缺少LSI 2008 RAID卡驱动。
  • 导致系统无法识别硬盘，进而找不到根分区。

（3）瑞丽卡驱动丢失解决方法

• 驱动获取:
  • 需从LSI官网下载对应驱动（非戴尔官网）。
  • 确认RAID卡型号为LSI 2008。
  • 注意要下载Linux版驱动（Windows驱动不适用）。
• 解决方案流程:
  1. 在虚拟机中安装相同系统版本。
  2. 升级内核至2.6.27（可正常启动）。
  3. 安装LSI 2008驱动获取驱动模块。
  4. 将驱动模块封装到initramfs文件。
  5. 将封装好的文件复制到问题服务器。

（4）瑞丽卡驱动丢失问题解决流程

• initramfs文件操作:
  • 解压方法（原文未详细说明）
  • 重新封装（原文未详细说明）
  • 验证方法：解压后检查是否存在目标驱动模块（如st.ko.xz）。
• 注意事项:
  • 操作前务必备份原始initramfs文件。
  • 确保内核版本与模块路径匹配。
  • 多封装驱动不影响系统启动（即使无对应硬件）。
  • 该方法同样适用于其他驱动问题（如华为FusionCompute CNA安装）。
• 应用扩展:
  • 可应用于非标准硬件环境安装。
  • 适用于定制ISO镜像制作。
  • 解决各类因驱动缺失导致的启动问题。

2. 资源限制概述

• 应用场景：当一台机器运行多个虚拟机/容器/业务时，需要为重要业务分配更多资源。
• 常见问题：不重要的进程反而占用更多资源，类似“该来的没来，不该来的来了”。
• 限制对象：可限制CPU、内存、IO（磁盘/网络）等资源。
• 实际案例：物理机上运行50个容器时，容器间会互相抢占资源。

3. pam_limits模块

• 模块位置：位于/usr/lib64/security/pam_limits.so。
• 功能原理：通过PAM（可插拔认证模块）实现资源限制。
• 配置文件：
  • 主配置文件：/etc/security/limits.conf。
  • 附加配置目录：/etc/security/limits.d/。
• 配置语法：（原文未详细说明具体语法格式）
• 生效验证：（原文未详细说明验证方法）
• 模块特性：
  • 影响所有用户包括root（uid=0）。
  • 不支持多线程应用调用。
  • 可通过conf=参数指定自定义配置文件。
• 调试选项：使用debug参数可打印调试信息。
• 特殊参数：
  • set_all：为未指定限制设置默认值。
  • utmp_early：兼容提前分配utmp条目的应用程序。

4. pam_listfile模块

• 主要功能：基于任意文件允许/拒绝服务访问。
• 典型应用：限制FTP登录（如vsftpd配置）。
• 配置参数：
  • item：检查项类型（user/tty/rhost等）。
  • sense：匹配时的处理（allow/deny）。
  • file：规则文件路径。
  • onerr：出错时的行为（succeed/fail）。
• 扩展应用：
  • 密码复杂度控制。
  • 登录失败锁定。
  • 密码修改策略。
• 系统集成：各服务通过/etc/pam.d/目录下的配置文件调用PAM模块。
• 常见配置文件：
  • password-auth
  • system-auth
  • sshd
  • login
• 模块查询：所有PAM模块都有man手册，可通过man pam_<模块名>查看详细用法。

三、系统启动模块及资源限制

1. 传统limits

（1）limits.conf文件的语法结构

• 文件作用：设置通过PAM登录用户的资源限制，不影响系统服务的资源限制。
• 配置优先级：/etc/security/limits.d/目录下的配置文件按字母顺序读取，会覆盖本文件中相同或更具体的域设置。
• 基本语法：<domain> <type> <item> <value>。
• domain取值：
  • 用户名（如user1）。
  • 组名（使用@group语法，如@it表示it组）。
  • 通配符*表示默认条目。
  • 通配符%用于maxlogin限制（如%group）。

（2）type的两种取值

• soft限制：可被用户临时突破的限制（如默认打开100个文件，但可临时增加到150）。
• hard限制：绝对不可突破的上限（如最多只能打开150个文件）。
• 生效机制：修改后立即生效，无需重启服务。

（3）常见item设置项

• 核心参数：
  • fsize：文件大小限制。
  • nofile：最大打开文件数（Oracle安装需设置为65536）。
  • as：常驻内存大小。
  • cpu：CPU时间限制。
  • nproc：最大进程数。
  • vmem：虚拟地址空间限制。
  • maxlogins：最大登录次数。
• 单位说明：内存相关参数默认以KB为单位（如102400表示100MB）。

（4）实际应用案例

• Oracle安装配置：（原文未详细说明具体配置）
• 内存限制测试：
  • 设置user1用户虚拟内存限制为10MB（软限制）和200MB（硬限制）。
  • 验证方法：切换用户后执行ulimit -a查看限制。
  • 效果验证：当程序尝试分配超过限制的内存时会报“无法分配内存”错误。

（5）软硬限制区别演示

• 测试场景：
  • 设置nofile软限制100，硬限制150。
  • 用户默认只能打开100个文件（软限制）。
  • 可临时调整到120-150之间（ulimit -n 120）。
  • 尝试设置超过150（如160）会失败。
• 关键结论：软限制是默认生效的限制值，用户可在不超过硬限制的范围内自行调整。

（6）传统limits的局限性

• 无法实现的限制：
  • 应用程序级别的内存限制（如限制FTP服务内存使用）。
  • 磁盘写入速率限制（如每秒只能写10MB）。
  • 网络带宽限制。
• 历史背景：在虚拟化技术出现前，这些限制需求较少被考虑。

2. cgroup

（1）cgroup的发展

• 基本概念与安装
  • 默认安装包: 红帽6系统默认安装libcgroup包（label cgroup），安装后系统会自动挂载cgroup文件系统。
  • 文件系统特性: cgroup是一种特殊文件系统，类似于proc和sysfs，在红帽6中直接挂载到/cgroup目录下。
  • 资源控制方式: 通过子资源(sub-system)实现对不同资源的控制，包括block IO、CPU、内存等。
• 资源控制参数
  • block IO控制
    • 性能指标: IOPS（每秒IO操作数）：适用于小IO控制；带宽：适用于大IO控制。
    • 控制维度: 读写分离控制（可单独限制读或写）；其他参数：服务时间、队列、整合等。
  • CPU控制机制
    • 权重分配: 采用cpu.shares参数（默认值1024），通过相对权重分配CPU资源。
    • 示例：设置512表示获得标准权重的一半，2048表示获得双倍资源。
    • 工作原理: 仅在资源紧张时生效，按比例分配CPU时间片。
    • 举例：2.8GHz单核主机运行三台虚拟机，份额分别为1000/2000/4000时，满负载时分配计算能力为400MHz/800MHz/1600MHz。
    • 计算公式：（原文未给出具体公式）
  • 版本差异
    • 红帽6: 挂载点为/cgroup。
    • 红帽8: 挂载点为/sys/fs/cgroup。

（2）cgroup配置文件

• 配置文件位置
  • 路径: /etc/cgconfig.conf。
  • 内容结构: 包含各类资源挂载配置（memory、cpu、blkio等）。
• 配置示例
  • 基本语法: （原文未详细说明）
  • IO限制示例: 限制磁盘读IO为1MB/s，需参考blkio子系统文档确定具体参数写法，值需要用双引号包裹。
• 模板参考
  • 内置模板: 配置文件底部提供各种资源限制的配置模板。
  • 实践建议: 编写新配置时应先参考现有模板格式。

（3）应用案例

• 例题:限制磁盘带宽

  • 设备编号规则：SCSI硬盘主编号固定为8，次编号按分区顺序递增。示例：sda=8:0，sda1=8:1，sdb=8:16，sdc=8:32（每个设备保留15个分区号）。
  • 带宽限制语法：格式为<主编号>:<次编号> <字节数>。
  • 1MB换算：（原文未说明具体换算值）
  • 示例：限制sda每秒1MB读写：8:0 1048576。
  • 配置结构：使用嵌套大括号结构，每个子系统需成对出现，组内可包含多个子系统（如同时限制IO和内存），每行参数末尾必须加分号。
  • 生效验证：需在策略文件中指定应用场景（用户/进程），示例：*:cp:blockio:small_data表示所有用户执行cp命令时应用该IO限制。测试方法：大文件拷贝时观察传输速率是否被限制在1MB/s。

• 例题:限制内存使用

  • 内存限制语法：格式：memory { limit = <数值><单位>; }，单位支持：KB/MB/GB（示例：256M）。
  • 多子系统配置：同一组内可并行配置多个限制参数，示例：同时限制IO和内存时需写在同一个组内。
  • 应用范围指定：通过进程名精确控制（如bigmemory程序），建议使用绝对路径指定目标程序。
  • 测试验证：使用专用测试工具申请内存（如申请512M），当限制为256M时，测试程序应无法超额申请。注意：实际限制值可能存在±1M的误差范围。
  • 配置技巧：组名可自定义（如small_data/ABC等），不同限制策略可分写多个group，服务类程序应限制其主进程内存使用。

（4）cgroup策略文件

• 红帽6与红帽7+的服务管理区别

  • 红帽6服务管理方式：
    • 使用service命令管理服务。
    • 通过/etc/init.d/目录下的脚本启动服务。
    • 脚本本质是执行/etc/init.d/service_name start/stop命令。
    • 系统第一个进程是init（PID=1）。
  • 红帽7+服务管理方式：
    • 使用systemctl命令管理服务。
    • 服务配置文件位于/usr/lib/systemd/system/目录。
    • 采用.service文件定义服务属性。
    • 系统第一个进程是systemd。

• systemd服务配置文件详解

  • Unit段：描述服务基本信息，After定义服务启动顺序（如network.target表示网络服务启动后启动）。
  • Service段：
    • Type定义服务类型：forking（后台服务）、simple（前台命令）。
    • ExecStart：服务启动命令。
    • ExecStop：服务停止命令。
  • Install段：WantedBy定义运行级别（如multi-user.target）。

• 自定义服务限制

  • 配置路径：
    • 主配置文件：/usr/lib/systemd/system/。
    • 自定义配置：/etc/systemd/system/service_name.d/。
  • 创建步骤：
    1. 创建.d目录：mkdir /etc/systemd/system/service_name.d/。
    2. 新建.conf文件（如01-limits.conf）。
    3. 编写资源限制参数。
    4. 执行systemctl daemon-reload使配置生效。

• cgroup资源限制配置

  • 内存限制：
    • MemoryAccounting=true：启用内存统计
    • MemoryLimit=256M：限制最大内存使用量
  • CPU限制：
    • CPUAccounting=true：启用CPU统计
    • CPUQuota=50%：限制CPU使用率
  • IO限制：
    • IOAccounting=true：启用IO统计
    • IOWeight=500：设置IO权重

• 服务资源限制原理

  • 限制机制：
    • 服务启动时会读取.d目录下所有.conf文件
    • 限制的是资源分配，不会导致服务直接挂掉
    • 当资源不足时，新请求会被拒绝（如Apache连接数限制）
  • 注意事项：
    • 限制值需大于服务启动最小需求
    • 修改配置后必须执行systemctl daemon-reload
    • 不建议直接修改主配置文件

• 将普通命令转为服务

  • 转换条件：
    • 命令需要持续运行（非一次性命令）
    • 需要开机自启动
  • 实现方法：
    • 创建.service文件
    • 设置Type=simple
    • 在ExecStart中指定命令路径
    • 通过systemctl enable设置开机启动

（5）服务资源限制

• 例题：把功能写成服务
  • 服务化实现方法
    • 脚本创建：在/usr/local/bin目录下创建脚本文件（如cpu_set.sh），内容包含需要执行的命令。
    • 权限设置：通过chmod +x命令给脚本添加可执行权限。
  • 服务配置步骤
    • 服务文件创建：在/usr/lib/systemd/system/目录下创建.service文件（如cpu_set.service）。
    • 服务内容配置：（原文未详细说明具体配置内容）
    • 服务启用：（原文未详细说明启用命令）
  • 服务类型区别
    • 一次性服务：执行完即退出（如配置脚本），服务状态显示为“inactive”。
    • 持续运行服务：需要保持后台运行（如守护进程），服务状态显示为“active (running)”。
  • 验证方法：通过systemctl status查看服务状态，实际检查功能是否生效。
  • 优势对比
    • 与传统方法比较：
      • 红帽6需要编写完整服务脚本（包含启动/停止/状态判断等）。
      • 红帽7/8通过systemd简化服务管理。
    • 配置持久化：避免直接修改系统配置文件，确保重启后设置仍然有效。
    • 管理便捷性：可通过标准systemctl命令统一管理所有服务。
  • 注意事项
    • 脚本调试：建议先手动执行脚本验证功能正常。
    • 路径正确性：确保服务文件中ExecStart的脚本路径准确。
    • 权限问题：注意服务运行时可能需要的特殊权限。
    • 服务类型选择：根据实际需求选择simple/forking等适当服务类型。

（6）资源限制验证

• cgroup验证方法
  • 路径检查：通过/sys/fs/cgroup/目录验证资源限制，内存限制查看memory子目录，CPU限制查看cpu子目录。
  • 服务状态关联：当服务启动时会在对应cgroup目录下生成服务名文件夹，停止服务后该文件夹消失。
  • 进程ID验证：检查服务进程ID是否出现在对应cgroup的tasks文件中，确认限制生效。
• 内存限制验证
  • 默认配置：全局内存限制文件位于/sys/fs/cgroup/memory/memory.limit_in_bytes，默认无限制。
  • 服务级配置：在/etc/systemd/system/<服务名>.service.d/创建conf文件可单独设置内存限制。
  • 计算示例：256MB内存限制的计算公式为（原文未给出具体公式），对应字节数精确设置。
• CPU限制验证
  • 权重机制：CPU shares默认值为1024，数值越大在资源竞争时获得的时间片越多。
  • 独立配置：通过设置CPUAccounting=yes和CPUShares=2048可使服务脱离全局配置。
  • 验证方法：检查/sys/fs/cgroup/cpu/<服务名>/cpu.shares文件确认当前生效值。

（7）资源使用总结

• 服务资源限制步骤
  1. 安装并启动目标服务
  2. 在/etc/systemd/system/<服务名>.service.d/创建配置文件
  3. 编写限制参数（内存/CPU/IO等）
  4. 执行systemctl daemon-reload重载配置
  5. 重启服务并通过cgroup目录验证
• 容器资源控制
  • 内存限制：docker run -m 200M限制容器内存为200MB。
  • 交换分区：--memory-swap=300M设置内存+swap总和限制。
  • 磁盘IO：--device-write-bps /dev/sda:30MB限制设备写入速度为30MB/s。
  • CPU权重：--cpu-shares=2048设置容器CPU优先级。
• 性能与风险
  • 禁用swap：设置swappiness=0可提升性能但会增加OOM风险。
  • 配置继承：未单独配置的服务继承全局cgroup设置。
  • 技术演进：红帽6→红帽8→容器均采用cgroup技术，配置方式逐渐简化。

四、Linux资源限制

1. 容器资源限制配置

• CPU权重设置：可通过设置权重值（如1024和512）来分配CPU资源，数值越大获得的CPU时间片越长。
• 磁盘IO控制：与CPU权重类似，磁盘IO也可以设置权重值进行资源分配。
• 零值设定：特定参数设为零时表示禁用对应功能（如示例中提到的“设为零”操作）。

2. swap空间作用

• 存在必要性：即使内存容量增大，swap空间仍然必需。
• 核心功能：用于存放暂时不用的数据，防止高并发场景下资源突然耗尽。
• 系统保护：作为内存的缓冲层，避免系统因内存耗尽而崩溃。

3. CPU调度机制对比

（1）CPU与cpuset区别

• 控制范围：
  • CPU：专门控制CPU资源分配。
  • cpuset：管理资源组，可将CPU和内存绑定使用。
• 资源组合：cpuset允许将特定CPU（如0号CPU）与特定内存（如1号内存）组合成资源单元。
• 应用场景：cpuset适合需要CPU和内存绑定的任务，后续CPU调优课程会详细讲解。

（2）优先级机制对比

• nice值：
  • 决定任务运行顺序（先运行/后运行）。
  • 数值范围通常为-20到19，值越小优先级越高。
• cpuset权重：
  • 决定获得的时间片长度。
  • 权重值越大获得的CPU时间越多。
• 优先级关系：cpuset的优先级控制比nice更高效，但CPU消耗极少。

4. 性能影响说明

• 权重设置影响：设置CPU权重后，在CPU繁忙时：
  • 高权重任务的资源利用率会升高。
  • 实际CPU资源消耗增加量非常有限。
• 资源分配原则：权重机制主要影响时间片分配，不会造成显著的额外开销。