Introduction Long-lived Proxmox VE installations often accumulate history. A system may begin life on a rack server, later migrate to compact x86 hardware, change storage architecture, replace ZFS with LVM/ext4, and still retain traces of older configurations. A major PVE upgrade can expose that history in logs and disk metadata. …
Introduction A major Proxmox Backup Server upgrade changes several layers at once: The system may boot successfully while still carrying: A structured read-only audit provides a safer way to validate the upgrade before attempting any cleanup. 1. Confirm the Version Stack Start with: A fully migrated PBS 4 system should …
多台闲置或用途不同的 x86 主机，如果 CPU 核心数、内存容量甚至 GPU 型号都不一致，并不意味着它们只能分别运行独立任务。 通过 Linux、Slurm 和 Open MPI，可以将这些机器组织成一个统一管理的异构计算集群。 这种架构不会把几颗物理 CPU 和几组内存透明地变成一块“超级主板”，但可以建立一个统一的资源调度层，让计算任务自动使用整个集群中的空闲 CPU、内存和 GPU。 一、什么是真正的计算集群 假设存在四台规格不同的 x86 主机： 从集群管理角度，可以看到： 但这里的“总计”需要正确理解。 一个普通应用程序仍然只能直接使用自己所在节点的 CPU 和本地 RAM。 例如 Node A 只有 64GB 内存，那么一个完全不支持分布式计算、需要 100GB 连续内存的普通程序，不能因为整个集群拥有 144GB RAM 就自动运行。 真正的分布式计算依赖应用程序本身将任务拆分到多个节点。 Open MPI 是 MPI 标准的开源实现，其核心用途正是让不同节点上的进程通过消息传递协同完成一个计算任务。 二、推荐架构 一个实用的小型集群可以设计成： 显示器 / 键盘 / …
家中或实验环境中经常会逐渐积累多台 x86 主机。这些设备的 CPU、内存和硬盘规格可能完全不同，有的安装了大容量机械硬盘，有的只有 SSD，也有一些设备本身仍然承担桌面或服务器任务。 如果不考虑 CPU、GPU 和内存的联合计算，而只希望把分散在多台主机中的磁盘整合起来，形成一个能够统一挂载、统一管理并具备一定容错能力的存储池，那么分布式文件系统是比传统 RAID 更合适的方案。 对于规模只有几台主机的小型环境，MooseFS 是一个值得考虑的选择。 一、目标架构 假设存在四台通过高速以太网连接的 x86 主机，各自拥有容量不同的数据盘： 高速交换机 ┌────────────┼────────────┐ │ │ │ Node A Node B Node C Node D 4TB+8TB 8TB 4TB 6TB │ │ │ │ └──────── MooseFS Storage Pool ───────┘ │ ▼ /storage 上层看到的是一个统一文件系统： 文件究竟落在哪台主机、哪块硬盘上，不再需要由用户手动决定。 MooseFS 将文件拆分为 chunk，并由多个 …
问题背景 某台 Linux 服务器上运行着一个内部证书申请工具。该工具通过 Web 页面发起 ACME 证书申请，并使用 DNS TXT 记录完成域名验证。 应用采用 Python 编写，通过 Gunicorn 运行，仅监听本机回环地址，再由 Web 服务器进行反向代理。 其目录结构大致如下： 临时目录中可能出现： 证书签发完成后，还可能短暂保存： 这些文件包含证书和私钥，因此不适合长期保存在服务器上。证书下载完成后，应尽快清除服务器副本。 故障现象 服务器重启后，证书工具无法启动。查看 systemd 状态时发现服务不断退出并自动重启： 由于服务配置了自动重启，短时间内重复失败，最终形成了持续的重启循环，累计重启次数达到数万次。 需要注意的是，此时 Gunicorn 和 Python 应用实际上还没有开始执行。 故障发生在 systemd 为服务建立挂载命名空间的阶段。 根本原因 服务的 unit 文件中包含类似配置： 这项配置用于限制服务可写入的位置，是一种合理的 systemd 安全加固措施。 问题在于： 在服务启动前必须已经存在。 /tmp 本身是临时文件系统。系统重启后，其中的自定义目录可能被正常清除。当 systemd 尝试根据 ReadWritePaths= 建立服务的挂载命名空间时，发现目录不存在，于是直接返回： …
小型服务器在同时运行 AI 服务、终端会话、备份任务和其他常驻程序时，偶尔可能出现响应迟缓，甚至完全失去连接。 服务器卡死后再查看日志，往往只能知道系统曾经发生过异常，却难以直观看到卡死前的内存、Swap、CPU 压力、I/O 压力和进程状态。 一种简单有效的办法，是制作一个固定的命令行监控脚本，在单个终端页面中集中显示关键状态，并每隔几秒自动刷新。 本文介绍一种不依赖额外监控平台的实现方式，适用于 Debian、Ubuntu、Arch Linux 等使用 systemd 的 Linux 系统。 监控内容 这个监控页面主要显示以下信息： 相比单独运行 top、free、ps 和 systemctl，单页监控更适合观察系统是否正在逐渐接近卡死状态。 创建固定脚本 以下示例将脚本安装到： 默认监控一个名为： 的 systemd 用户服务。 实际使用时，可以通过环境变量指定需要监控的服务名称。 在具有管理员权限的终端中执行： 这段安装命令会完成以下操作： 运行监控页面 假设需要监控的用户服务名为： 可以这样启动： 页面默认每两秒刷新一次。 退出时按： 修改刷新间隔 刷新间隔通过 SERVER_MONITOR_INTERVAL 环境变量控制。 每秒刷新一次： 每五秒刷新一次： 一般情况下，两秒刷新一次已经足够，同时不会产生明显额外负载。 查看一次静态快照 脚本也支持只输出一次当前状态，不进入自动刷新模式： 这种方式适合： 例如保存当前状态： 页面中的关键指标 Load average uptime …
在维护多台 Linux 主机时，修改配置文件看似简单，真正容易出问题的往往是修改之前的备份。 常见做法是： 或者： 这些方式虽然能够保留内容，但仍存在几个问题： 为了让多台不同发行版、不同用途的 Linux 主机使用同一套规则，可以把备份逻辑封装成一个系统级命令。 备份规则 工具需要遵守以下原则： 核心流程如下： 与普通 cp 备份相比，这种方法有一个重要区别： 因此，历史备份才是真正的原文件本体。 封装成系统命令 工具命令名称已做脱敏处理，例如： 在常规 Linux 服务器和桌面系统中，可安装到： 在部分精简系统或嵌入式发行版中，也可以根据目录布局安装到： 只要安装目录位于 PATH 中，使用方式就完全一致。 当当前目录明确时，优先进入配置文件所在目录，再使用相对文件名： 这种方式比反复输入较长的绝对路径更方便，也降低了人工输入错误。 只有当前目录不明确、跨目录操作或存在歧义时，才需要使用绝对路径： 脚本设计中的安全边界 一个配置文件备份工具不应该承担过多职责。 它只负责： 它不应该： 尤其是符号链接需要谨慎处理。 例如： 如果直接对符号链接执行备份，保存下来的可能只是链接本身，而不是目标文件内容。为了避免产生“看似备份成功，实际没有备份配置内容”的情况，第一版工具直接拒绝符号链接更安全。 为什么要加入回滚机制 备份流程包含两个关键步骤： 如果第二步失败，原路径会暂时不存在。 失败原因可能包括： 因此，脚本需要记录当前执行阶段。 如果原文件已经移动，但工作副本尚未创建成功，就应尝试： 恢复原始状态。 回滚机制不能保证应对所有底层文件系统故障，但至少能够处理大多数普通中断和复制失败。 不同 Linux 系统之间的兼容问题 同一个 Shell 脚本部署到多种 Linux …
一、问题背景 在一台长期稳定运行的 Linux 服务器上，近期观察到以下现象： 初步判断：瓶颈不在 CPU 和内存，而可能在磁盘 I/O。 二、第一步：整体负载判断（top） 通过 top 观察系统整体状态，发现： 这类特征通常意味着： CPU 有空闲，但进程在等待磁盘 I/O 完成。 此时需要进入磁盘层面分析。 三、第二步：磁盘层分析（iostat） 使用： 重点关注以下指标： 关键观测结果 这说明： 磁盘并非被“大流量读写”压满，而是被 高频小块 I/O（IOPS） 打满。 这是数据库 + 元数据密集型负载的典型特征。 四、第三步：进程级定位（iotop） 使用： 该工具可以实时展示 哪些进程在进行磁盘读写。 观察到的主要 I/O 来源 系统级进程（日志、容器运行时等）均处于正常噪音水平。 五、负载模式分析 综合 top、iostat、iotop 的结果，可以得到完整因果链： 这是一个教科书级的磁盘 I/O 瓶颈案例。 六、可能的直接诱因：文件同步行为 进一步结合业务场景，发现一个高度相关的可能性： 用户正在进行文件同步操作（如私有云客户端同步） 这类同步具有以下特征： 其表现形式与当前监控数据完全一致。 …
写在前面 在现代 Linux（systemd 已成为事实标准）的环境下，很多关机命令在结果上是等价的，但在语义、设计出发点和适用场景上仍然存在差异。本文以实际使用为导向，梳理 systemctl poweroff 与 shutdown now 之间的关系与区别。 结论先行：在 systemd 系统中，它们最终走的是同一条关机路径，但入口不同。 一句话结论 systemctl poweroff：systemd 的原生方式 本质 systemd 实际执行流程 特点 适用场景 shutdown now：传统命令的 systemd 实现 在 systemd 系统中发生了什么 在现代发行版中： 也就是说： shutdown 的额外能力 这是它仍然存在的主要原因： 特点 等价关系整理（systemd 系统） 在 Arch / Debian / Ubuntu / RHEL 7+ 等 systemd 发行版中： 最终效果是相同的：系统正常关机并断电。 …
适用对象：使用常见集成型以太网控制器的 Proxmox VE 虚拟化宿主机 问题特征：宿主网络随机掉线、时间不固定；重启 networking 后宿主恢复，但虚拟机仍需 stop/start 才能恢复；虚拟机内部 reboot 无效 结论摘要：关闭网卡 offload + 关闭 EEE（Energy Efficient Ethernet），并进行 systemd 永久化，是当前该问题族成功率最高、代价最低、可复现性最强的解决方案之一。 1. 问题现象（行为级描述） 在长期运行的虚拟化环境中，宿主机会出现随机网络中断，具有如下共同特征： 这些现象往往容易被误判为虚拟机、应用或网络配置问题，但多次验证表明：真正进入异常状态的是宿主机网络路径本身。 2. 架构与关键前提 该问题通常出现在如下环境组合中： 与台式机或服务器上常见的独立 PCIe 网卡不同，集成型以太网控制器在电源管理（EEE / ASPM / C-state）与 CPU之间存在更强的耦合，这一差异是问题产生的重要边界条件。 3. 关键认知纠偏 3.1 虚拟机并非问题源头 当宿主网络路径进入异常中间态时，虚拟机只是最先感知失败的一层。 3.2 为什么重启 networking 只能救宿主 networking 服务的重启会： 但它不会销毁或重建已经存在的： 因此，虚拟机仍然绑定在失效的中间层网络对象上。 3.3 为什么必须 …