This commit is contained in:
+1
-1
@@ -59,7 +59,7 @@ SPIFFE/SPIRE 已按维护者授权补读 #34；LAN DNS 与 Authelia 已按维护
|
||||
| microvm-runner（历史目录名） | 动态 runner 的 homelab 基础设施记录 | 当前项目接口见 [Dynamic Runner](gitea-dynamic-runner.md) | 独立项目已更名并扩展到 Pod/VM，正在积极开发 | `infrastructure/microvm-runner/README.md`、独立项目文档 | 具体启用范围和实现进度以独立项目文档为准 |
|
||||
| [oci](oci.md) | 云主机、网络与站点互联 | `OCI ap-osaka-1` | 有恢复、接管与网络实施记录 | `infrastructure/oci/README.md` | 已有登录、站点网络与维护入口 |
|
||||
| [openbao](openbao.md) | 秘密管理与内部 CA | `bao.ad.ddupan.top` | 有部署与接管记录 | `infrastructure/openbao/README.md` | 已有登录、取密与运维入口指南 |
|
||||
| [proxmox](proxmox.md) | PVE、虚拟化与主机基础设施 | `PVE 管理入口` | 已有基础设施 | `infrastructure/proxmox/ansible/` 与 `README-ha.md` | 已有管理入口；身份与 runner 设计见独立项目 |
|
||||
| [proxmox](proxmox.md) | PVE、虚拟化与主机基础设施 | `PVE 管理入口` | 已有基础设施 | `infrastructure/proxmox/ansible/` 与 `README-ha.md` | 已有管理入口；sandbox LB/根盘恢复流程见服务页；身份与 runner 设计见独立项目 |
|
||||
| [samba-ad](samba-ad.md) | AD 身份、域 DNS 与域成员管理 | `dc1 / 192.168.10.5` | 有部署记录；维护者说明 DNS 部分已完成 | `infrastructure/samba-ad/README.md`、[LAN DNS](lan-dns.md) | 已有入域、目录浏览与日常管理入口 |
|
||||
|
||||
## 集群
|
||||
|
||||
+58
-3
@@ -2,15 +2,16 @@
|
||||
title: Proxmox 日常管理入口
|
||||
lifecycle: active
|
||||
evidence: documented
|
||||
last_reviewed: 2026-09-16
|
||||
last_verified: null
|
||||
last_reviewed: 2026-09-25
|
||||
last_verified: 2026-09-25
|
||||
---
|
||||
|
||||
# Proxmox
|
||||
|
||||
Proxmox 承载 VM/LXC 与相应主机、网络和存储资源。
|
||||
本页依据 homelab-infra 工作区 `infrastructure/proxmox/README.md`、`README-ha.md`
|
||||
及已有 DNS 名称整理使用入口，不检查集群成员、VM、HA 或存储现场状态。
|
||||
及已有 DNS 名称整理使用入口；初轮未检查集群成员、VM、HA 或存储现场状态。
|
||||
2026-09-25 的有限现场验证仅覆盖下文 sandbox 存储恢复与 LB 链路，不代表整套 PVE/HA 验收。
|
||||
源码 README 尚未跟踪，HA 文档有工作区修改；配置已进一步核对 `auth.yml`、`site.yml`、
|
||||
`ha.yml` 与对应 role defaults，不将文档中的历史阶段备注当作当前配置。
|
||||
|
||||
@@ -76,3 +77,57 @@ PVE 主机存储、DRBD 副本和 k3s 的 [OpenEBS](openebs.md) 是不同管理
|
||||
长期配置入口为 `infrastructure/proxmox/ansible/`，并按实际变更选择对应 playbook。
|
||||
|
||||
来源文件的固定版本与工作区差异见[来源追溯](../sources.md#proxmox)。
|
||||
|
||||
|
||||
## Sandbox LB 与根文件系统恢复
|
||||
|
||||
Sandbox 的 VyOS 入口为 PostgreSQL `10.60.0.1:5432`、K3s API
|
||||
`10.60.0.13:6443`、OpenSandbox `10.60.0.13:8080`。数据库只转发到
|
||||
sandbox1 `10.60.0.11:5432`；K3s 转发到两个节点的 `6443`；OpenSandbox
|
||||
转发到两个节点的 `30080`。OpenSandbox `/health` 返回 200 不代表 K3s 控制面可用。
|
||||
配置依据为源码 `infrastructure/sandbox-cluster/README.md`、
|
||||
`infrastructure/proxmox/ansible/roles/vyos_router/` 及本轮 VyOS 现场检查；
|
||||
OpenSandbox 的 LB 条目在现场存在，不能推断旧 Ansible 模板已经管理该条目。
|
||||
|
||||
排障先检查 HAProxy 监听和每个 backend 的状态，再直连后端。若后端拒绝连接，
|
||||
检查 PostgreSQL、K3s 与根文件系统，而不是仅重启 LB。
|
||||
`findmnt -no SOURCE,FSTYPE,OPTIONS /` 即使显示 `rw`，同时出现
|
||||
`emergency_ro` 也不能视为正常可写。
|
||||
|
||||
DRBD 对端失联导致 quorum 丢失时，`on-no-quorum=io-error` 会向文件系统返回
|
||||
I/O 错误；ext4 可能中止 journal 并进入只读。DRBD 后来恢复 UpToDate/quorum
|
||||
并不会自动解除文件系统的故障状态。检查宿主日志时用 `journalctl --utc`，
|
||||
不要直接把宿主本地时间与 guest 的 UTC 时间比较。
|
||||
|
||||
在已获停机恢复授权后，按以下顺序处理：
|
||||
|
||||
1. 用 `pct config <VMID>`、`pvesm path <rootfs-volume>` 和 `drbdsetup status <resource> --verbose`
|
||||
核对容器、卷和副本关系。确认链路稳定、quorum 正常、数据副本 UpToDate，且没有其他节点挂载该卷。
|
||||
2. 正常关闭故障容器，确认 stopped、卷未挂载且无遗留占用。禁止在运行中的根盘执行 fsck。
|
||||
3. 执行 `pct fsck <VMID> --device rootfs --force 1`。本机 PVE 使用 `fsck -a -l -f`；
|
||||
底层返回 1 表示已修复，PVE 仍可能把它显示为命令失败。必须核对完整输出，不能把其他错误码当成功。
|
||||
4. 对同一已停机、未挂载卷执行 `e2fsck -fn <verified-device>`；返回 0 后再启动容器。
|
||||
若自动安全修复未通过，暂停并评估数据恢复，不盲目加 `-y`、清空 WAL 或重建数据库。
|
||||
5. 等待 PostgreSQL 完成 crash recovery；验证主库 `pg_is_in_recovery()=false`、
|
||||
standby 保持 recovery、`pg_stat_replication` 为 streaming/sync，检查 replay lag。
|
||||
不把普通 TCP check 当成数据库可写性证明，也不自动提升 standby。
|
||||
6. 检查两个 K3s 服务、两个直连 API 和 VIP 的 `/readyz`、节点与 Pod Ready。
|
||||
数据库已恢复而某个 K3s 长期停在 activating 时，核对日志与进程；必要时只重启该 K3s 服务。
|
||||
7. 从 VyOS 再核对每个 backend 为 UP，并验证 OpenSandbox `/health`。
|
||||
|
||||
2026-09-25 现场验证范围：sandbox1 根盘离线修复和只读复检通过，重新挂载不再有
|
||||
`emergency_ro`；数据库恢复同步复制，采样 replay lag 为 0；两个 API 与 VIP 的
|
||||
`/readyz` 均为 ok，两个节点及全部 Pod Ready。故障证据为目标 DRBD 对端 PingAck
|
||||
超时、quorum 丢失及紧随其后的 ext4 写入错误；对端连接超时的上游原因尚未确定。
|
||||
本轮未修改 VyOS LB、DRBD quorum 策略或集群网络。此处保存恢复方法及有限验证边界，
|
||||
不代表已经消除存储网络复发风险。
|
||||
|
||||
|
||||
本次进一步复盘将触发线索收敛为：新 PG HDD 数据卷在 17:12 开始的初始同步发生重叠，
|
||||
随后多个既有 DRBD 资源失去 quorum；15:30–15:32 的 etcd rootfs 迁移与后来的新数据卷创建
|
||||
应分开记录。资源争用的具体瓶颈尚未实证。容器 `serial: 1` 和 etcd health 不等于 DRBD
|
||||
同步完成；新卷维护需在创建前建立同步预算，并在允许下一卷前等待所有必要副本同步。
|
||||
目前 PG 创建流程虽已在创建后加限速，仍存在初始未限速窗口，尚未补齐同步完成屏障。
|
||||
|
||||
事故报告由 wiki 统一维护：[2026-09-25 DRBD quorum 抖动与 sandbox 控制面中断](../incidents/2026-09-25-drbd-quorum-sandbox.md)。
|
||||
其中保存统一 UTC 时间线、跨资源影响边界、相关操作会话和后续验收条件；本页保留可复用恢复方法。
|
||||
|
||||
Reference in New Issue
Block a user