作者声明：本文所有命令均在一台全新的 Ubuntu 24.04 云服务器上实际验证通过。软件版本迭代较快，若实际情况与本文描述存在差异，请以官方文档为准。

云服务器到手第一件事——Ubuntu 24.04 安全加固实操

拿到一台新的云服务器，在部署任何业务之前，需要先完成基础的安全加固工作。本文记录了这台服务器从初始状态到具备基本防护能力的完整操作过程，适用于所有需要长期在公网运行服务的 Ubuntu 24.04 主机。

0 为什么拿到服务器的第一件事是加固

一台刚开通的云服务器，公网 IP 分配后的几分钟内就会开始收到扫描流量。这并非针对性攻击，互联网上有大量自动化脚本在持续扫描全网段，发现 22 端口开放就会尝试用弱密码字典爆破 root。开一台新机器，观察一天后查看日志：

1

lastb | wc -l    # 统计失败登录次数

通常能看到成百上千条失败记录。这就是加固需要应对的现实威胁，即无差别的自动化爆破，而不是有针对性的入侵。相应地，本文的加固思路也比较直接，分四层递进：

• 系统更新：先修复已知漏洞，这是所有后续措施的基础。
• SSH 加固：爆破成立的前提是密码有可能被猜中。改为仅密钥登录后，基于服务器密码的在线字典爆破就失去了入口。
• 防火墙：默认拒绝所有入站流量，只放行明确需要的端口，缩小暴露面。
• fail2ban + 自动安全更新：前者封禁反复试探的来源 IP，后者自动安装安全更新，降低漏打补丁的风险。需要重启才能生效的更新仍由管理员安排。

完成这四层之后，可以显著降低自动化扫描、口令爆破和意外端口暴露带来的风险。需要明确的是，这些措施针对的是自动化威胁。如果服务器上存在值得定向攻击的资产，则需要更完整的安全方案。对于个人自用、运行网站或游戏服务端等应用的机器来说，这个防护等级是合理的，且日常维护成本很低。

本文环境：

• 系统：Ubuntu Server 24.04 LTS（云厂商官方镜像）
• 登录方式：初始为 root 密码登录（不同厂商的初始交付方式不同，有的默认提供 ubuntu 用户和密钥，流程需要相应微调）
• 客户端：任意支持 OpenSSH 的终端

另外需要注意，主流云厂商（阿里云、腾讯云、AWS 等）在 VPC 层面还提供一道安全组（Security Group），它与本文配置的 ufw 是两道相互独立的防护，流量需要同时通过两者才能到达服务。建议两道都配置。安全组作用在网络入口，ufw 跟随系统本身，将来更换厂商或迁移镜像时，系统内的防火墙规则不会丢失。本文以 ufw 为主线，安全组的业务端口与 ufw 保持一致即可。安全组还有一个 ufw 示例中未体现的优势，即可以直接限制来源地址。如果有稳定的公网出口 IP，SSH 端口最好只对自己的 IP/CIDR 开放（如 203.0.113.10/32），而不是向 0.0.0.0/0 和 ::/0 全部开放。当出口地址经常变化、无法固定时，才向公网开放该端口，并依赖密钥认证、ufw 与 fail2ban 这几层防护。

1 系统更新

用初始凭据以 root 登录服务器。如果厂商交付的是普通用户，以下命令前需要加 sudo。

1. 更新软件包索引

1

apt update

2. 安装当前可用的软件包升级

1

apt upgrade

新开通的服务器，镜像内置的补丁通常落后当前版本数周到数月，第一次 upgrade 的更新量会比较大。这里是"当前可用"是因为有两类更新不会被立即安装。一类是因依赖变动被保留（held back）的包，apt upgrade 不会强行处理。另一类是 Ubuntu 分阶段更新（phased updates）机制下按比例灰度推送的包，当前机器可能延迟几天才会收到。这两种情况都属正常，不需要强行安装，也不建议在新机器上直接使用可能移除软件包的 full-upgrade。升级过程中如果弹出交互界面询问"哪些服务需要重启"，直接回车接受默认值即可。如果提示配置文件冲突，先按 D 查看差异。确认没有云厂商或个人定制时，可以采用维护者版本。拿不准时优先保留当前版本（N），升级完成后再手工合并。需要注意的是，即使是刚开通的机器，云镜像和 cloud-init 也可能已经修改过网络或 SSH 相关配置，不要仅因为"服务器是新的"就默认覆盖。

3. 如有内核更新，重启一次

1
2

cat /var/run/reboot-required
reboot    # 上一条显示*** System restart required ***时执行

Ubuntu 通过 /var/run/reboot-required 文件标记存在需要重启才能生效的更新，典型情况是内核升级。新机器尚未部署业务，此时重启成本最低，建议在进入后续配置之前完成。等服务上线后再重启，就需要专门安排维护窗口了。

2 创建日常用户，告别 root 直连

root 是暴力破解脚本的首要目标，因为这个用户名必然存在，攻击者只需要猜密码。本节创建一个专用的日常管理用户，平时用它登录，需要提权时使用 sudo，root 的 SSH 登录则在后面彻底关闭。需要说明的是，真正起防护作用的是下一节的 PasswordAuthentication no、PermitRootLogin no 和 AllowUsers 白名单。关闭密码登录之后，用户名是否难以猜测已经无关紧要，因此取名以清晰、便于管理为主。

1. 创建用户

1

adduser deploy

Ubuntu 上推荐使用 adduser 而不是底层的 useradd。adduser 是 Debian 系的交互式封装，会自动创建家目录、复制 skel 模板并调用 passwd 设置密码，一条命令即可完成全部工作。useradd 不带参数时连家目录都不会创建。用户名请替换为你自己的。

这里设置的是本地密码，之后 sudo 提权时需要用到。SSH 登录不会用到它，因为下一节会关闭密码认证。因此设置一个强密码并存入密码管理器即可，不必追求好记。

2. 加入 sudo 组

1

usermod -aG sudo deploy

-a 表示 append（追加），-G 指定附加组。-a 不能省略。单独的 -G 含义是"将附加组列表设置为"，会把用户从其他所有附加组中移除。在新机器上这没有实际差别，但这个习惯值得从一开始就养成。Ubuntu 的 sudoers 默认放行 sudo 组（%sudo ALL=(ALL:ALL) ALL），入组即获得完整的 sudo 权限，无需再修改 sudoers 文件。

3. 验证

保持 root 会话不关，另开一个终端用新用户登录并验证提权：

1
2

ssh deploy@<服务器IP>
sudo whoami    # 输出 root 即成功

"另开终端验证、保留旧会话兜底"的做法贯穿本文。SSH 加固的每一步都可能把自己锁在门外，唯一可靠的保险是始终保留一个已登录的会话。

这里顺带约定后文的权限前提。涉及修改 /etc、安装软件、管理 systemd 服务和配置防火墙的服务器端命令，默认在保留的 root 会话中执行。如果你已经切换到 deploy 会话操作，请自行在这些命令前加 sudo。需要在客户端本地执行的命令会另行注明。

3 SSH 加固

本章是全文的核心。目标状态是：仅允许密钥登录、禁止 root 登录、限制认证重试次数。操作顺序不能乱。

3.1 部署密钥

1. 在客户端（你自己的电脑）生成密钥对

1

ssh-keygen -t ed25519 -C "deploy@my-server"

-t ed25519 指定椭圆曲线算法。它的密钥短（公钥约 80 个字符）、验证速度快，也没有 RSA 在密钥长度上的历史包袱，是当前 OpenSSH 推荐的算法。-C 只是注释，用于日后在 authorized_keys 里分辨这把密钥属于谁、用于什么，建议写成"用户@用途"的格式。提示输入 passphrase 时建议设置，它保护的是私钥文件本身，即使电脑丢失，没有 passphrase 也无法直接使用私钥。配合 ssh-agent 使用，日常并不需要反复输入。

如果提示 id_ed25519 already exists. Overwrite (y/n)?，说明这台电脑上已经存在一把同名密钥。此时不要确认覆盖，该操作会不可逆地销毁旧私钥，所有仍依赖它认证的服务器都会无法登录。接下来有两种选择：

• 复用现有密钥：跳过生成步骤，直接部署现有公钥。个人场景下用一把带 passphrase 的密钥登录多台服务器很常见，管理成本最低。
• 为这台服务器单独生成：用 -f 指定新文件名，避开默认路径：

1

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_myserver -C "deploy@my-server"

两种方式各有利弊。共用一把密钥管理简单，但它一旦泄露会波及所有服务器。按服务器分别生成密钥可以隔离影响范围，泄露后也能单独吊销，代价是多一层文件管理。

如果选择了单独命名，后文所有出现 id_ed25519 的位置都要替换成新文件名，包括部署和验证时的 -i 参数以及客户端 config 中的 IdentityFile。另外，非默认名称的密钥 ssh 不会自动尝试，必须在客户端 config 中通过 IdentityFile 显式指定。

2. 把公钥部署到服务器

1

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@<服务器IP>

ssh-copy-id 会用当前还可用的密码登录一次，把公钥追加到服务器上的 ~/.ssh/authorized_keys，并在需要时创建相关目录和文件，比手工复制更不容易出错。这里显式指定 -i，确保部署的是刚生成的这把公钥。不带 -i 时它会优先使用 ssh-agent 中已加载的密钥，如果 agent 里有多把密钥，可能把其他公钥也一并写入服务器。OpenSSH 默认开启 StrictModes，会检查这些路径的属主和写权限。如果家目录、.ssh 或 authorized_keys 能被其他用户写入，密钥就有被替换的风险，sshd 通常会拒绝使用它。检查的重点是"其他人不可写"和"属主正确"，不要求权限精确等于某个数值，但 700/600 是最稳妥的推荐值，部署后可以核对一次：

1
2
3

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~/.ssh ~/.ssh/authorized_keys    # 确认属主是登录用户本人

如果曾以 root 身份手工动过这些文件，还要检查属主：chown -R deploy:deploy /home/deploy/.ssh。

Linux、macOS、WSL 和 Git Bash 通常自带 ssh-copy-id。Windows 原生 PowerShell 的 OpenSSH 没有这个命令，可以用管道做等价替代：

1

Get-Content "$HOME\.ssh\id_ed25519.pub" | ssh deploy@<服务器IP> "umask 077; mkdir -p ~/.ssh; cat >> ~/.ssh/authorized_keys"

umask 077 保证新建的目录和文件一开始就是收紧的权限，执行后同样做一遍上面的权限核对。

3. 验证密钥登录已生效

1

ssh deploy@<服务器IP>    # 此时应不再询问服务器密码（passphrase 是本地私钥的口令，不是服务器密码）

各平台的 OpenSSH 都会自动尝试默认路径下的 id_ed25519，通常不需要额外参数。如果仍被询问服务器密码，可以显式指定私钥，先排除路径方面的问题。Windows PowerShell 下写作：

1

ssh -i $HOME\.ssh\id_ed25519 deploy@<服务器IP>

Linux/macOS 则是 ssh -i ~/.ssh/id_ed25519 deploy@<服务器IP>。如果显式指定能登录而默认调用不能，说明密钥不在默认路径，或者受到了 agent 干扰，此时可以用 ssh -v 查看客户端实际尝试了哪些密钥。另外，下一节要配置的客户端 ~/.ssh/config 在 Windows 上同样有效，路径为 $HOME\.ssh\config（即 C:\Users\<用户名>\.ssh\config），写法完全一致。配置好之后，登录时就不再需要手动指定 -i。

这一步没通过，绝对不要进行下一节。

3.2 收紧 sshd 配置

Ubuntu 24.04 的 /etc/ssh/sshd_config 开头有一行 Include /etc/ssh/sshd_config.d/*.conf。我们不动主配置文件，把加固项写进 drop-in。这样做有两个好处：发行版升级时不会产生配置文件冲突，自己改了什么也一目了然。

1. 先看一眼已有的 drop-in

1
2

ls /etc/ssh/sshd_config.d/
cat /etc/ssh/sshd_config.d/*.conf

云镜像上大概率会看到一个 50-cloud-init.conf，内容是 PasswordAuthentication yes。这是 cloud-init 在初始化时写入的，也是"印象中 Ubuntu 默认关闭了密码登录，实际却还能用密码登录"的原因。不要直接删除它，cloud-init 的某些操作可能重新生成该文件，我们用加载顺序来覆盖它。

2. 新建加固配置

1

vim /etc/ssh/sshd_config.d/10-hardening.conf

1
2
3
4
5
6
7
8

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
AllowUsers deploy

文件名里的 10 不是随手写的。sshd 按字典序读取 drop-in，且对同一配置项首个出现的值生效（first-match wins，这与多数软件"后加载覆盖先加载"的直觉相反）。10- 排在 50-cloud-init.conf 前面，我们的 PasswordAuthentication no 先被读到，cloud-init 那行就成为无效的重复声明。

各项说明：

• PasswordAuthentication no：关闭密码认证。这条生效后，sshd 根本不会走到验证密码这一步，针对密码的字典爆破也就无从下手。
• KbdInteractiveAuthentication no：关闭键盘交互式认证。PAM 可以通过这条通道提供口令、验证码等交互式认证方式。为了避免普通密码经由这条通道继续可用，需要与上一条一起关闭。
• PermitRootLogin no：root 完全不接受 SSH 登录，包括密钥登录。需要 root 权限时用普通用户登录后再 sudo，这一步会在日志中留下 sudo 提权记录，便于后续审计。
• MaxAuthTries 3：限制单次连接内的认证尝试次数。注意客户端每提交一把不匹配的密钥也计一次。ssh-agent 中有多把密钥时，客户端会逐把尝试，可能在轮到正确的密钥之前就达到上限，报 Too many authentication failures。因此收紧这个值的前提是客户端明确指定密钥（见下方客户端配置）。如果不想处理这个兼容问题，保留默认值 6 也完全可以。
• LoginGraceTime 30：连接建立后 30 秒内必须完成认证，否则断开。默认的 120 秒偏长，会让慢速攻击和半开连接长时间占用 sshd 资源。
• X11Forwarding no：服务器没有图形界面，这个转发通道属于多余的攻击面，关闭。
• AllowUsers deploy：白名单，只有列出的用户可以通过 SSH 登录。它和 PermitRootLogin no 有功能重叠，但白名单体现了默认拒绝的思路：以后系统里因为安装软件新增的服务账户，不会意外获得 SSH 入口。多个用户用空格分隔。

配合 MaxAuthTries 3，建议在客户端 ~/.ssh/config 里为这台服务器写一段配置，把提交的密钥限定为这一把：

1
2
3
4
5
6
7

# 客户端 ~/.ssh/config
Host my-server
    HostName <服务器IP>
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    # Port 36022    # 若按 3.3 节修改了端口，再加这行

IdentitiesOnly yes 让客户端只提交 IdentityFile 指定的密钥，不再把 ssh-agent 里的密钥逐个尝试。这样既不会触发服务器的尝试次数上限，也省去了每次输入 IP 和用户名的麻烦，之后用 ssh my-server 即可登录。

你可能注意到配置里没有写 AuthenticationMethods publickey。在 Ubuntu 默认关闭其他认证方式（GSSAPI、host-based 等），且上面已经禁用密码和键盘交互的前提下，公钥实际上已经是唯一可用的登录方式，本文不再额外设置。AuthenticationMethods 的作用是明确限定认证流程或组合多因素，例如 publickey,keyboard-interactive 表示两种方式必须依次通过。PAM 层的 TOTP 走的就是后一条通道，这也是第 7 节提到的 2FA 方案的实现基础。

3. 校验配置语法

1

sshd -t

没有任何输出表示通过。如果报错就停下来修好，此时旧配置仍在运行，不会有任何影响。带着语法错误 restart，是把自己锁在门外的典型原因。

4. 重启 sshd 并验证

1

systemctl restart ssh

这里按 Ubuntu 官方文档的推荐，用 systemctl restart ssh 让 sshd 重新读取配置。默认配置下，已建立的连接由各自独立的 sshd 进程持有，重启负责接受新连接的服务通常不会断开这些连接。但不要把这个行为当成唯一的防锁死保障，保留旧终端、用新终端验证登录，这条纪律仍然必须遵守。另外需要区分一种情况：本节这些认证相关的参数，restart 服务即可生效。如果修改的是监听端口（Port / ListenAddress），还要额外处理 systemd 的 socket 单元。Ubuntu 从 22.10 起，ssh 默认采用 socket 激活，由 ssh.socket 监听端口，有连接进来才拉起 sshd，24.04 延续了这套机制，具体见下一节。

保持当前会话不关，另开终端做两个验证：

1
2

ssh deploy@<服务器IP>                                  # 密钥登录应正常
ssh -o PubkeyAuthentication=no deploy@<服务器IP>       # 强制不用密钥，应直接被拒绝：Permission denied (publickey)

第二条命令是在模拟攻击者的行为：禁用自己的密钥去连接，如果服务器仍然询问密码，说明配置没有生效，需要回头检查 drop-in 的文件名排序和拼写。两个验证都通过，SSH 加固才算完成。

3.3 关于修改 SSH 端口

个人认为全网段的扫描工具遍历全部端口只是时间问题，密钥认证才是真正起作用的防护。改端口的实际收益，是让日志里的爆破记录从每天几千条降到接近零。日志干净了，真正异常的访问才容易被发现。

如果要改，顺序很重要：先放行新端口，再修改配置，验证通过后再关闭旧端口。

1. 先放行新端口。在云安全组放行 36022/tcp。如果此时 ufw 已经处于启用状态（按本文顺序第 4 节还在后面，尚未启用则跳过这条），也先执行：

1

ufw limit 36022/tcp comment 'SSH'

2. 修改配置并应用。在 10-hardening.conf 里加一行：

1

Port 36022    # 1024–65535 之间自选，避开常见服务端口

1
2
3

sshd -t
systemctl daemon-reload
systemctl restart ssh.socket

注意这里多了 daemon-reload，重启对象也变成了 ssh.socket，原因就是上一节末尾提到的 socket 激活：监听端口的是 systemd 的 socket 单元，而不是 sshd 本身。24.04 提供了一个 systemd generator，会在 daemon-reload 时解析 sshd_config 中的 Port 指令并同步给 socket 单元，因此不需要像 22.10/23.04 那样手写 socket 的 override 文件。但 daemon-reload 这一步不能省，只 restart ssh 的话监听端口不会变化。

3. 检查监听：

1
2

systemctl status ssh.socket
ss -ltnp 'sport = :36022'

有一点需要注意：socket 激活模式下，ss 显示的监听进程可能是 systemd 而不是 sshd。监听 socket 本来就由 systemd 持有，这属于正常现象，如果习惯性地用 ss -tlnp | grep ssh 过滤，反而可能看不到结果。

4. 验证后再关闭旧端口。另开终端用 ssh -p 36022 登录，在成功之前保留安全组里旧 22 端口的规则。确认新端口登录无误后，再删除安全组（以及 ufw 里如有）的旧端口规则。

4 防火墙 ufw

ufw（Uncomplicated Firewall）是 iptables/nftables 的前端，Ubuntu 默认自带，规则语法直观。整体策略可以概括为一句话：默认拒绝所有入站流量，按需逐条放行。

1. 设置默认策略

1
2

ufw default deny incoming     # 入站默认拒绝
ufw default allow outgoing    # 出站默认放行

入站默认拒绝是整个防火墙策略的基础。出站保持放行是一个务实的取舍：服务器需要执行 apt 更新、拉取部署文件，fail2ban 也需要查询 DNS，如果逐条管理出站规则，维护成本会远高于它在个人服务器场景下的实际收益。出站管控主要应对主机被入侵后阻止外联的场景，这部分内容不在本文讨论范围内。

2. 放行 SSH（在 enable 之前！）

1

ufw limit 36022/tcp comment 'SSH'    # 端口按实际情况填写，未修改端口则为 22/tcp。若 3.3 节已提前添加，会提示规则已存在，跳过即可

这里使用 limit 而不是 allow：limit 在放行的基础上附带内置限速，同一 IP 在 30 秒内发起 6 次或更多新连接时会被临时拒绝。它与 fail2ban 构成互补的两层防护，limit 在内核层拦截高频连接，开销很低，fail2ban 则在应用层分析日志并执行较长时间的封禁。comment 的作用是为后续维护提供说明，之后执行 ufw status 时可以直接看清每条规则的用途。

3. 启用

1

ufw enable

执行后会警告可能中断现有 SSH 连接，确认上一步的放行规则无误后输入 y。ufw enable 会同时配置开机自启，不需要再单独处理 systemctl。

4. 验证

1

ufw status verbose

输出中应包含默认策略 deny (incoming), allow (outgoing)，以及 SSH 端口的 LIMIT 规则。Ubuntu 默认启用了 ufw 的 IPv6 支持（可用 grep '^IPV6=' /etc/default/ufw 核对），因此通常会看到 IPv4 和 IPv6 各一条规则。如果服务器持有公网 IPv6 地址，这一点尤其重要，只检查 IPv4 规则而忽略 IPv6 侧，会在防护上留下明显缺口。反过来，如果列表中只有 IPv4 规则，应先核对上述开关是否被镜像修改过，而不是怀疑自己的操作有误。

关于业务端口：现阶段不要提前放行任何尚未部署的服务端口（80、443 或其他应用端口）。防火墙规则应当跟随服务走，在服务安装完成、确认需要对外提供访问时，再执行对应的 ufw allow，这是"默认拒绝"原则的自然延伸。

一个预警：如果后续打算用 Docker 部署服务，需要注意 Docker 默认直接操作 iptables，通过 -p 8080:8080 发布的端口会绕过 ufw 直接暴露到公网，即使 ufw 中没有对应的放行规则也无法拦截。这是 Docker 与 ufw 共存时的一个已知问题。届时要么使用 127.0.0.1:8080:8080 绑定回环地址，再由反向代理转发，要么明确接受"Docker 发布的端口交由安全组管理"这一方案。

5 fail2ban

ufw 的 limit 只拦同一 IP 的高频新连接，fail2ban 则真正去读日志。认证失败次数达到阈值的来源 IP 会被防火墙直接封禁一段时间，因此它能处理低于连接限速阈值的慢速尝试。同时也要清楚它的边界，这种按 IP 统计的机制对频繁轮换 IP 或分布式僵尸网络效果有限。fail2ban 只是密钥认证和最小化暴露面之外的补充层，不能替代前两者。

1. 安装

1

apt install fail2ban -y

24.04 的 fail2ban 包已经依赖 python3-systemd（读取 journald 日志的 Python 绑定库），安装时会一并带上，不需要手动指定。sshd 的认证日志走 systemd journal，fail2ban 直接从 journal 读取，相比依赖 rsyslog 落盘的 /var/log/auth.log，少了一层间接依赖，也没有日志轮转的边界问题。

2. 编写本地配置

fail2ban 的配置是分层的。jail.conf 由发行版维护默认值，升级时会被覆盖，永远不要直接改它。本地定制写在 jail.local，同名配置项会覆盖 conf 里的值。

1

vim /etc/fail2ban/jail.local

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# /etc/fail2ban/jail.local
[DEFAULT]

# 初始封禁时长
bantime = 1h

# 统计失败次数的时间窗口
findtime = 10m

# 窗口内允许的最大失败次数
maxretry = 5

# 同一 IP 累犯时封禁时长按 1、2、4、8……倍递增
bantime.increment = true

[sshd]
enabled = true
backend = systemd

# 与实际 SSH 端口一致，默认端口则写 ssh
port = 36022

注意这份配置里的注释全部独立成行，不要图省事写成行内 # 注释。fail2ban 的配置解析中 # 只用于整行注释，行内注释要用前面带空格的 ;。把 # 写在参数值后面，有被当成参数值一部分解析的风险。

参数选择的理由：

• maxretry = 5 / findtime = 10m：10 分钟内失败 5 次即封禁。正常的密钥登录不会产生认证失败记录，私钥 passphrase 在客户端本地验证，输错不会发到服务器，也就触发不了 fail2ban。客户端逐把提交不匹配的密钥，可能在服务器端产生失败记录，或者先触发 MaxAuthTries，3.2 节的 IdentitiesOnly yes 正好可以避免这类问题。爆破脚本则几秒内就会触发阈值。
• bantime = 1h 起步配合 bantime.increment：首犯 1 小时足够让绝大多数扫描脚本放弃并转向下一个目标，顽固的 IP 会被递增机制越封越久。不建议一上来就设置一周这种极端值，长封禁的代价是你自己某天误触发时，解封之前从这个 IP 完全进不来。
• port 必须与实际 SSH 端口一致。fail2ban 封禁时下发的规则针对具体端口，改了 SSH 端口却忘了同步这里，封禁规则会打在无人使用的 22 端口上，形同虚设。

3. 启用并验证

1
2
3

fail2ban-client -t
systemctl enable --now fail2ban
fail2ban-client status sshd

fail2ban-client -t 与前文的 sshd -t 是同一个习惯，先测配置，再启动服务。看到 OK: configuration test is successful 再继续，报错就按输出里的文件名和行号修正 jail.local，不要带着错误配置启动。

实测在输出 OK 之前还会出现一行 WARNING：'allowipv6' not defined in 'Definition'. Using default one: 'auto'。这是 24.04 自带的 fail2ban 1.0.x 的已知提示，不影响功能。它的含义是 IPv6 支持未显式配置，将按 auto 自动检测，配置是否通过仍以最后那行 OK 为准。如果希望输出保持干净，可以把这个默认值显式写出来：

1
2
3
4

tee /etc/fail2ban/fail2ban.local <<'EOF'
[Definition]
allowipv6 = auto
EOF

注意这项写在 fail2ban.local，而不是 jail.local。它属于 fail2ban 守护进程本身的配置（对应 fail2ban.conf），与 jail 规则分属两个文件，分层逻辑与 jail.conf/jail.local 相同：conf 归发行版，local 归自己。写完后重新执行 fail2ban-client -t，WARNING 应消失。

输出里 Currently banned 和 Total banned 一开始都是 0，属于正常。放一天再看，Total banned 的数字会直观反映这层防护拦下了多少东西。如果 sshd jail 启动时报找不到日志，检查 backend = systemd 是否写在 [sshd] 段内，以及 python3-systemd 是否已经安装。

误封自己怎么办：从云厂商的网页控制台（VNC/串口，不走 SSH 也就不受 fail2ban 管）登录，执行 fail2ban-client set sshd unbanip <你的IP>，或者干脆换个出口 IP，比如切到手机热点，绕开封禁。

6 自动安全更新 unattended-upgrades

系统加固不是一次性工作，安全补丁会持续发布。对于不希望每天手动维护的个人服务器，将安全更新交给 unattended-upgrades 自动处理，整体收益大于风险。

1. 确认已安装并启用

1
2

apt install unattended-upgrades -y    # Ubuntu Server 通常已预装
systemctl status unattended-upgrades

2. 检查周期任务配置

1

cat /etc/apt/apt.conf.d/20auto-upgrades

应包含以下两行，没有则补上：

1
2

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

这两项分别表示每天刷新软件包索引、每天执行一次无人值守升级。实际执行由 apt-daily.timer 与 apt-daily-upgrade.timer 调度，并带有随机延迟，以避免大量机器在同一时间访问镜像源，因此不会在每天固定时刻运行。可以通过 systemctl list-timers 'apt-daily*' 查看下一次的执行时间。

3. 核对升级范围

1

vim /etc/apt/apt.conf.d/50unattended-upgrades

默认的 Allowed-Origins 包含当前发行版的基础仓库（${distro_id}:${distro_codename}）、安全更新源 ${distro_codename}-security，以及系统具备 Ubuntu Pro 资格时对应的 ESM 安全源。普通功能更新源 ${distro_codename}-updates 默认保持注释。基础仓库在版本发布后内容基本不再变化，因此日常持续自动安装的实际就是安全更新。功能更新可能改变软件行为，应由管理员在合适的时间手动执行 apt upgrade。具体以机器上这份文件的实际内容为准。

另外确认一项：

1

//Unattended-Upgrade::Automatic-Reboot "false";

保持注释状态，即不自动重启。内核安全更新需要重启才能生效，但对外提供服务的机器在半夜自动重启会直接中断所有在线业务，是否重启应由管理员决定。折中做法是登录时留意 motd 中的 *** System restart required *** 提示，选择低峰时段手动重启。

另一个 24.04 上容易忽略的行为：Automatic-Reboot "false" 只控制整机重启，不控制服务重启。24.04 默认安装 needrestart，它可能在升级完成后自动重启需要重新加载库文件的 systemd 服务，在线业务仍可能出现短暂中断。如果希望改为只提示而不自动重启服务，可以执行：

1
2
3
4

mkdir -p /etc/needrestart/conf.d
tee /etc/needrestart/conf.d/99-local.conf <<'EOF'
$nrconf{restart} = 'l';
EOF

l 表示 list，即只列出需要重启的服务，由管理员自行处理。是否修改需要权衡。自动重启服务可以让补丁及时生效，只提示则把中断时机的控制权留给管理员，但要注意，此时补丁只是写入磁盘，相关进程仍在使用内存中的旧版本，直到手动重启服务后修复才真正生效。对于单人维护、可以接受短暂中断的机器，建议保持默认让 needrestart 自动重启服务。对服务连续性有要求的场景，可以改为 l 并配合固定的维护窗口处理。

4. 模拟运行测试

1

unattended-upgrade --dry-run --debug

--dry-run 只模拟不执行，输出中可以看到识别了哪些源、当前有哪些包会被自动升级，用于确认逻辑符合预期。

7 本文没做什么，以及为什么

• SSH 2FA（TOTP）：带 passphrase 的私钥能降低私钥文件泄露后被直接滥用的风险。需要指出的是，passphrase 只在客户端本地解锁私钥，服务器无法确认它是否存在，因此它并不等同于服务器强制实施的第二因素。对本文面向的个人服务器而言，强密钥配合 passphrase，再加上客户端自身的安全，已经是合理的取舍。有更高需求时，可以再配置 publickey 与 TOTP 的叠加认证，或者改用硬件保护的 FIDO2 安全密钥。
• 端口敲门（port knocking）：隐蔽性带来的收益低于维护成本，对客户端也不够友好。在已经启用密钥认证的前提下，它要解决的问题基本不存在。
• rootkit 扫描器（rkhunter/chkrootkit）：这类工具误报率高，规则更新也不及时，在机器未沦陷的前提下价值有限。如果真的怀疑机器已经沦陷，正确的做法是取证后重装系统，而不是在原地清理。
• SELinux / AppArmor 调整：Ubuntu 默认已启用 AppArmor，并为常见服务加载了配置文件，保持默认即可，无需额外操作。
• 修改内核 sysctl 网络参数：常见加固教程里的不少设置，例如启用 SYN cookies，Ubuntu 默认已经处理。另一些参数（如 rp_filter）的合理取值与网卡数量、策略路由、容器和 VPN 拓扑相关，没有通用的"安全值"。在没有明确威胁模型和业务需求的情况下，不建议机械照抄一整套参数，轻则造成重复配置，重则破坏正常的路由或连接。

8 验证速查

全部做完后，可以用这几条命令快速核对整体状态：

1
2
3
4
5
6
7

sudo sshd -T | grep -Ei '^(port|passwordauthentication|kbdinteractiveauthentication|permitrootlogin|maxauthtries|logingracetime|x11forwarding|allowusers)\b'   # sshd 最终生效配置
sudo ss -tulpn                            # 当前监听端口（TCP + UDP）
sudo ufw status verbose                   # 防火墙默认策略与规则
sudo fail2ban-client status sshd          # 封禁统计
lastb | head                              # 最近的失败登录尝试
last | head                               # 最近的成功登录，确认没有陌生记录
cat /var/run/reboot-required 2>/dev/null  # 是否有待重启的更新

监听端口的检查重点是绑定在 0.0.0.0 和 [::] 上的公网监听。云镜像通常自带监控代理、时间同步等组件，监听列表里不会只有 SSH 一项，这属于正常现象。绑定在 127.0.0.1、::1 或内网地址上的服务，结合用途判断即可。对于无法识别的公网监听，可以根据 ss 输出中的进程名进一步确认它的来源和用途。

sshd -T 需要单独说明。它输出的是所有配置文件合并、first-match 规则应用之后实际生效的完整配置。排查"修改后没有生效"这类问题时，以它的输出为准比直接查看配置文件更可靠。另外，sshd -T 显示的是全局配置，如果配置中包含 Match 段，需要用 -C 指定用户、来源地址等连接条件，才能看到对应连接实际匹配的结果。

结语

至此，我们完成了以下配置：

• 系统补丁更新与重启
• 普通用户 + sudo，root 不再用于日常登录
• SSH 仅密钥登录、禁止 root、限制重试（可选改端口降噪）
• ufw 默认拒绝入站，SSH 端口限速放行
• fail2ban 基于日志的自动封禁
• 安全更新自动化，整机重启由人工安排，服务重启按 needrestart 策略处理

这台服务器现在已经可以放心部署业务了。

这是Ultrastar DC HC620 分析与实战——树莓派 5 驱动主机管理式 SMR 硬盘的续篇。前文提过，Raspberry Pi OS 官方内核的 bcm2712_defconfig 没有启用 CONFIG_BLK_DEV_ZONED，主机管理式叠瓦（Host-Managed SMR，HM-SMR）盘接上以后，内核会直接拒绝为它创建块设备节点。所以想用 HC620，自己编译内核这一步省不掉。

本文的做法是在一台 x86_64 的 Ubuntu Desktop 26.04 虚拟机里交叉编译树莓派内核，打好包传到 Pi 5 上安装。官方内核、设备树和 cmdline.txt 全部原样保留，只在 config.txt 末尾加一行 os_prefix 做启动选择，回滚时删掉这一行重启就行。

环境

分支跟着目标机走，不用特意挑。在 Pi 上执行 uname -r，看当前内核属于哪个系列，目标机为 6.18.34+rpt-rpi-2712，选同系列的分支即可。本文写作时，rpi-6.18.y 的最新版本是 6.18.39 Commit 820b5b663。

1 编译机准备

装工具链和内核构建依赖：

1
2
3

sudo apt update
sudo apt install git bc bison flex libssl-dev make libc6-dev \
  libncurses-dev crossbuild-essential-arm64

crossbuild-essential-arm64 会带上 aarch64-linux-gnu-gcc 全套交叉工具链。

2 获取源码

只要当前分支最新提交，浅克隆省时间省空间：

1
2
3

git clone --depth=1 --branch rpi-6.18.y https://github.com/raspberrypi/linux.git
cd linux
git rev-parse --short HEAD   # 记下提交号，真机结果对应确切源码

3 配置

先应用官方默认配置，再用 scripts/config 脚本修改差异。这种方式比在 menuconfig 中逐项翻菜单更容易复现，后续跟版重编时直接重放这几条命令即可。

1
2
3
4
5
6
7
8
9
10
11
12

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bcm2712_defconfig

./scripts/config \
  --enable  CONFIG_BLK_DEV_ZONED \
  --module  CONFIG_DM_ZONED \
  --module  CONFIG_ZONEFS_FS \
  --module  CONFIG_BTRFS_FS \
  --disable CONFIG_ARM64_16K_PAGES \
  --enable  CONFIG_ARM64_4K_PAGES \
  --set-str CONFIG_LOCALVERSION "-v8-4k-zoned"

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- olddefconfig   # olddefconfig 将其余选项按依赖规则补齐默认值，全程非交互

各项配置的作用如下：CONFIG_BLK_DEV_ZONED 是通用块层的 zoned 支持开关，启用后 SCSI 磁盘驱动中的 ZBC（Zoned Block Commands）支持会随之构建。CONFIG_DM_ZONED 与 CONFIG_ZONEFS_FS 是两条可选的上层使用路径，本文编译为模块，按需加载。btrfs 的 zoned 模式没有单独的配置项，只需启用普通的 CONFIG_BTRFS_FS，本文同样显式设为模块，避免依赖未来版本的 defconfig。

页大小方面，Pi 5 的 bcm2712_defconfig 默认使用 16K 页。启用 zoned block support 本身并不要求改成 4K，本文仍选择 4K 页。除了与前文已验证的 btrfs、dm-zoned 和用户态工具环境保持一致、减少排障时的变量之外，还有两个更实际的考虑。

先看 16K sectorsize 的情况。常规配置的 6.18 系内核中，16K 页下的 Btrfs 支持 4K 和 16K 两种 sectorsize。文件系统一旦使用 16K sectorsize，普通的 4K 页内核就无法直接挂载，发生故障时不能把硬盘接到常见的 x86_64 PC 上直接救援。Linux 6.18 开始提供“block size 大于 page size”的基础支持，启用 CONFIG_BTRFS_EXPERIMENTAL 的 4K 页内核可以处理 16K sectorsize，但这条路径仍属实验功能，存在多项限制，不适合作为常规救援手段。

再看 4K sectorsize 的情况。在 16K 页内核上使用 4K sectorsize 时，普通 Btrfs 会进入 subpage 模式。该模式从 Linux 6.15 起移除了实验性警告，到 6.18 已经相对完整并经过测试，但原生 btrfs zoned 与 subpage blocksize 的组合尚未实现。要让 Btrfs 以原生 zoned 模式运行在 HM-SMR 设备上，sectorsize 仍需与内核页大小保持一致。把 Pi 5 内核改成 4K 页后，既可以走原生的 4K sectorsize 路径，也保留了把硬盘接到普通 4K 页 Linux PC 上直接挂载和救援的能力。

如果走 dm-zoned 路径，Btrfs 面对的是 dm-zoned 暴露出来的普通块设备，不会进入原生 btrfs zoned 模式，此时 16K 页加 4K sectorsize 的普通 subpage 路径在 6.18 中已经可用。不过，为了统一前文的三条实验路径并保留跨机器救援的兼容性，本文统一采用 4K 页。保留默认的 16K 页也可行，但需要根据实际使用的原生 btrfs zoned、dm-zoned 或 zonefs 路径分别做实机验证。

LOCALVERSION 用于给自编内核设置独立名称，使其模块安装到单独的 /lib/modules/<kernelrelease>/ 目录中，不与官方内核模块混用。

修改完成后验证一遍，注意确认 16K 页确实已关闭。

1

grep -E 'CONFIG_LOCALVERSION=|CONFIG_ARM64_(4K|16K)_PAGES|CONFIG_BLK_DEV_ZONED|CONFIG_DM_ZONED|CONFIG_BTRFS_FS=|CONFIG_ZONEFS_FS' .config

预期的关键配置行如下：

1
2
3
4
5
6
7
8

CONFIG_LOCALVERSION="-v8-4k-zoned"
CONFIG_ARM64_4K_PAGES=y
# CONFIG_ARM64_16K_PAGES is not set
CONFIG_BLK_DEV_ZONED=y
# CONFIG_BLK_DEV_ZONED_LOOP is not set
CONFIG_DM_ZONED=m
CONFIG_BTRFS_FS=m
CONFIG_ZONEFS_FS=m

4 编译

1

make -j$(nproc) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image.gz modules dtbs

编译完成后记录完整内核版本号（基础版本 + LOCALVERSION），后续验证环节需要与其对照：

1
2

make -s ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- kernelrelease
# 本文实测：6.18.39-v8-4k-zoned+

在 8 vCPU / 8 GB 内存的虚拟机上，本次编译用时约 17 分钟。

5 打包产物

将自编内核的全部启动产物放入独立的 zoned/ 目录，后续通过固件的 os_prefix 机制按目录整体切换，不覆盖官方内核、设备树、overlays 和 cmdline.txt：

1
2
3
4
5
6
7
8
9
10
11
12

rm -rf dist
mkdir -p dist/firmware/zoned/overlays

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
  INSTALL_MOD_PATH="$PWD/dist" INSTALL_MOD_STRIP=1 modules_install

cp arch/arm64/boot/Image.gz dist/firmware/zoned/kernel_2712.img
cp arch/arm64/boot/dts/broadcom/bcm2712*.dtb dist/firmware/zoned/
cp arch/arm64/boot/dts/overlays/*.dtb* dist/firmware/zoned/overlays/
cp arch/arm64/boot/dts/overlays/README dist/firmware/zoned/overlays/

tar czf pi-kernel-zoned.tar.gz -C dist .

Image.gz 直接改名后即可作为树莓派固件可引导的内核镜像，固件根据文件内容判断压缩格式，不依赖扩展名。镜像命名为 kernel_2712.img，因为这是 Pi 5 固件的默认查找名，配合 os_prefix 使用就无需再添加 kernel= 配置行。INSTALL_MOD_STRIP=1 用于去除模块的调试符号，可以显著减小模块体积。

将压缩包传到 Pi：

1

scp pi-kernel-zoned.tar.gz <树莓派用户名>@<树莓派地址>:~/

6 树莓派上安装

解包并安装。这组命令采用先删后装的方式，首次安装、同版本重编和跟版更新都适用，不会残留旧文件：

1
2
3
4
5
6
7
8
9
10
11

rm -rf dist && mkdir dist
tar xzf pi-kernel-zoned.tar.gz -C dist

KREL=$(basename "$(find dist/lib/modules -mindepth 1 -maxdepth 1 -type d)")
sudo rm -rf "/lib/modules/$KREL"
sudo cp -a "dist/lib/modules/$KREL" /lib/modules/
sudo depmod -a "$KREL"

sudo rm -rf /boot/firmware/zoned
sudo cp -r dist/firmware/zoned /boot/firmware/
sudo cp /boot/firmware/cmdline.txt /boot/firmware/zoned/cmdline.txt

/boot/firmware/config.txt 末尾追加：

1
2

[all]
os_prefix=zoned/

[all] 用于清除 config.txt 中此前可能生效的条件过滤段（如 [cm4]、[pi4]），保证这行配置对 Pi 5 生效。固件会到 zoned/ 目录中按默认名称查找内核、设备树、overlays 和 cmdline.txt，原有的对应文件均保持不变。固件启动时会先检查 zoned/ 中是否存在预期的内核和设备树，关键文件缺失时会忽略该前缀并回退到原有启动文件。这是一层基本保护，但并不等于事务式更新。如果复制中途断掉，缺失的又只是 overlays 或 cmdline.txt，前缀仍可能通过检查，系统会带着不完整的文件启动。因此重启前应当确认关键文件全部就位：

1
2
3
4
5
6
7
8
9
10
11

if test -s /boot/firmware/zoned/kernel_2712.img &&
   test -s /boot/firmware/zoned/bcm2712-rpi-5-b.dtb &&
   test -s /boot/firmware/zoned/cmdline.txt &&
   test -s /boot/firmware/zoned/overlays/README &&
   find /boot/firmware/zoned/overlays -maxdepth 1 -name '*.dtbo' -print -quit | grep -q .
then
  echo "启动文件检查通过"
  sudo sync   # boot 分区是 FAT，写完同步一下再重启更稳妥
else
  echo "启动文件不完整，请勿重启" >&2
fi

有两点需要注意。第一，zoned/cmdline.txt 是安装时复制的快照，之后只要修改了 /boot/firmware/cmdline.txt，例如根分区 PARTUUID、串口控制台、cgroup 或其他内核启动参数，都要重新复制一份到 zoned/。第二，本文测试机从 SD 卡上的 ext4 根分区启动，相关存储与文件系统驱动均为内置，实测不需要额外制作 initramfs。如果根分区使用了 btrfs、LUKS、LVM 或特殊存储控制器，或者现有系统本身依赖 initramfs，则需要为自编内核生成匹配的 initramfs 并放入 zoned/（auto_initramfs=1 时固件按 kernel_2712.img 在同目录查找 initramfs_2712）。

不使用 initramfs 引导还存在一个连带问题。内核直接挂载的根文件系统在 /proc/mounts 中显示为 /dev/root，这并不是一个真实存在的设备节点。Pi OS 默认的 MODULES=dep 模式要求 update-initramfs 能够解析根设备，因此在运行自编内核期间，任何触发 initramfs 重建的 apt 操作，例如安装带有钩子的软件包或更新官方内核，都会报出 mkinitramfs: failed to determine device for / 错误并中断执行，dpkg 会因此停留在未配置完成的状态。解决办法是修改 /etc/initramfs-tools/initramfs.conf，将 MODULES=dep 改为 MODULES=most，然后执行 sudo dpkg --configure -a 完成剩余的配置。这一修改的唯一影响是官方内核的 initramfs 体积会略微增大。

重启：

1

sudo reboot

7 验证

重启完成后，先确认内核版本与页大小：

1
2
3

uname -r              # 应与第4节 kernelrelease 的输出一致
getconf PAGE_SIZE     # 预期为 4096
lsblk -d -o NAME,MODEL,SIZE,ZONED

HC620 应出现在列表中，ZONED 列显示 host-managed。随后针对具体设备做进一步确认。设备名以 lsblk 的实际输出为准，经 USB-SATA 桥接时不一定是 sda：

1
2

cat /sys/block/<设备名>/queue/zoned   # 预期 host-managed
sudo dmesg | grep -Ei 'zoned|zbc|host-managed'

最后确认 dm-zoned 与 zonefs 两个模块的来源：

1

modinfo -n dm-zoned zonefs

输出的两条路径都应位于当前 uname -r 对应的 /lib/modules/<内核版本>/ 目录下，本文实测示例为 /lib/modules/6.18.39-v8-4k-zoned+/。验证完成后，分区与格式化操作与前文一致，直接参照执行即可。

8 回滚

如需恢复官方内核，注释或删除 config.txt 中的 os_prefix=zoned/ 一行并重启即可。官方内核、官方设备树和官方 cmdline.txt 全程未做改动，删除前缀后系统会自动回到原有启动文件，保留 [all] 行没有影响。无论编译配置有误还是新版本存在问题，回滚成本仅为一次重启，这是本方案在可维护性上最大的优势。

如果系统已经无法引导，可将 SD 卡插入其他机器直接修改 config.txt。boot 分区为 FAT 格式，在任意操作系统上均可读写。

9 跟版更新

需要先明确更新机制。用户态软件包仍会通过 apt 正常接收安全更新，apt 也会照常更新官方内核文件（os_prefix 目录之外的部分），但正在引导的自编内核不会随之自动升级。内核的漏洞修复与版本合并需要手动跟版、重新编译并安装。具体流程为重复上述步骤：

1
2
3
4
5
6
7
8
9

cd linux
git fetch --depth=1 origin rpi-6.18.y
git reset --hard FETCH_HEAD   # 重置到刚抓取的提交
git rev-parse --short HEAD

make ARCH=arm64 mrproper   # 清除旧 .config 和构建产物
# 完整重放第 3 节：重新生成新版 bcm2712_defconfig，
# 再应用 scripts/config 差异并执行 olddefconfig
# 之后按原流程编译、打包、传输、安装

必须完整重放上述步骤，包括 bcm2712_defconfig 这一步，不要沿用旧版 .config。官方 defconfig 在新版本中可能存在增删，直接沿用旧配置会偏离“官方默认加少量差异”的原则，配置差异会随版本推移不断累积。

模块目录以完整内核版本号（基础版本 + LOCALVERSION）命名，基础版本从 6.18.39 更新到 6.18.40 后，模块会安装到新目录而非覆盖旧目录。确认旧自编内核不再用于引导后，可手动删除对应的 /lib/modules/ 目录。官方内核的模块目录必须始终保留，回滚操作依赖这些文件。重复构建同一基础版本则无需特殊处理，第六节的安装命令本身采用先删后装的方式，不会残留已从配置中移除的旧模块。

建议将第3至5节的命令整理为脚本并纳入 dotfiles 管理，跟版时执行一次即可完成打包。可定期检查 rpi-6.18.y 分支是否发布了新的补丁版本，遇到安全公告或重要修复时及时重新编译。

结语

到这里，从配置、编译、打包到安装、验证、回滚的完整流程已经完成。整套方案的核心只有两点：用 scripts/config 显式表达与官方 defconfig 的差异，用 os_prefix 把自编内核的启动文件整体隔离。前者保证跟版重编可以逐条复现，后者保证任何环节出问题都能用一次重启退回官方内核。

在二手平台搜索大容量机械盘时，很容易见到这样一类商品：西数（HGST）Ultrastar DC HC620，14TB，氦气企业盘，价格明显低于同容量的普通企业盘，商品描述里通常只带一句含糊的"需专用系统"或"不支持普通电脑"。价格低并非盘本身有故障，而是因为它属于主机管理式叠瓦盘（Host-Managed SMR，HM-SMR）。这类盘接入 Windows 无法识别，接入未启用 zoned 块设备支持的 Linux 内核时，lsblk 中也不会出现盘符，树莓派官方系统的内核恰好属于后者。多数买家因此无法正常使用，二手价格随之维持在低位。

但"系统不直接支持"与"不能用"是两回事。Linux 自 4.10 起引入分区块设备（Zoned Block Device）的核心支持，dm-zoned、zonefs、btrfs zoned 等组件在后续版本中陆续完善。本文的验证平台由一块 14TB 的 HC620、一台树莓派 5 和一块 PCIe 转 SATA 扩展板组成。

这套方案适合冷备份、顺序归档、一次写入多次读取的场景，顺序读写可以接近盘体的标称上限（233 MB/s）。它不适合用作普通 NAS 数据盘、下载盘或任何随机写密集的用途，即便通过 dm-zoned 这类兼容层屏蔽 zone 约束，效果也只是"能用"而非"好用"。如果需求是一块即插即用的仓库盘，更合理的做法是增加预算购买 CMR 盘。

1 SMR 四象限：先分清买的是哪一种

机械盘按记录方式和管理方式可以分成四类，购买二手大容量盘之前需要先分清：

CMR（Conventional Magnetic Recording，传统垂直记录）。磁道互不重叠，任意扇区可随机改写，即通常所说的普通硬盘。

DM-SMR（Drive-Managed SMR，盘管理式叠瓦）。磁道部分重叠以换取存储密度（shingled 即瓦片式堆叠之意），改写一条磁道必须重写一整片。盘内固件在内部处理这些重写，对系统表现为普通硬盘，代价是缓存写满后性能大幅下降。消费级低价大容量盘的性能问题多出在这一类，且系统层面无法直接识别，只能查询型号确认。

HA-SMR（Host-Aware SMR，主机感知式）。介于两者之间，既接受随机写也暴露 zone 接口，市面上很少见。

HM-SMR（Host-Managed SMR，主机管理式）。不向主机隐藏叠瓦结构，而是将其以"区（zone）"的形式直接暴露给主机，通过 ZBC（SCSI）/ ZAC（ATA）命令集管理，只接受符合规则的顺序写入，违规写入直接返回 I/O 错误。数据中心用它换取可预测的性能和最高的存储密度。HC620 属于这一类，也是唯一一类接入后系统不显示盘符的。

识别方法按可靠程度排序：最可靠的是查型号，HC620 的 SATA 型号为 HSH721414ALE6M0（14TB、512e）、HSH721414ALN6M0（14TB、4Kn）及对应的 15TB 型号 HSH721415ALE6M0 / HSH721415ALN6M0，型号以 HSH 开头基本都属于这个家族。其次看商品页关键词，“host managed”、“主机管理”、“需专用系统/服务器”、"不支持个人电脑"都是信号。最后，盘到手后在支持 zoned 的系统上执行一条命令即可定性：

1
2
3
4

cat /sys/block/sda/queue/zoned
# host-managed → HM-SMR
# host-aware   → HA-SMR
# none         → CMR 或 DM-SMR（DM-SMR 对系统不可见，只能查型号）

2 HC620 是一块什么盘

基本规格：3.5 寸、7200 RPM、氦气封装（HelioSeal 第四代）、512MB 缓存、官方标称最高持续传输率 233 MB/s（223 MiB/s，外圈值，向内圈递减，实测见后文）、额定年写入负载 550TB、MTBF 250 万小时。2018 年发布时，15TB 型号是全球第一块 15TB 企业盘。

真正决定使用方式的是它的 zone 布局。整块盘的地址空间划分为若干 256 MiB 的区，分为两种类型：

• 常规区（Conventional Zone）：位于盘的起始位置，容量占比很小（15TB 型号实测为 130GiB 出头），支持随机读写，行为与普通硬盘一致。后文会提到，dm-zoned 和 f2fs 的元数据都存放在这部分常规区。
• 顺序写区（Sequential Write Required Zone）：占据其余全部空间。每个区维护一个写指针（Write Pointer），写入必须精确落在写指针位置并顺序推进。改写已有数据时，只能将整个区**重置（Reset）**后从头写入。随机读不受限制。

具体到容量：14TB 512e 型号共 52156 个区（每区 524288 个 512B 逻辑块），15TB 4Kn 型号共 55880 个区（每区 65536 个 4K 逻辑块），均为 256 MiB。后文执行 blkzone report 时可以核对这个数字。

512e（ALE）和 4Kn（ALN）型号在本文方案下均可使用，物理扇区都是 4K，区别仅在于逻辑扇区大小。二手市场上 512e 更常见，本文以 14TB 512e 为例。

到手后的检测流程与普通企业盘相同，smartctl 可正常工作，重点关注通电时间、Reallocated_Sector_Ct 和 UDMA CRC 错误。注意 Ubuntu Server 没有预装 smartmontools：

1
2

sudo apt install smartmontools
sudo smartctl -a /dev/sda

本盘实测关键字段：整体评估 PASSED，通电 55441 小时（约 6.3 年），Reallocated_Sector_Ct、Current_Pending_Sector、Offline_Uncorrectable、UDMA_CRC_Error_Count 全部为 0，Helium_Level 为 100，盘温 36°C。

数据中心退役盘的通电时间普遍在数万小时，判断健康状态应依据缺陷计数和氦气水平，而不是使用时长。这块盘运行六年多，各项指标仍然全部正常。smartctl 会提示 Device is: Not in smartctl database，HC620 不在其识别库中，这属于正常现象，不影响属性读取。

3 硬件准备

必需：

• 树莓派 5，内存大小不影响本方案，2GB 版本即可满足需求，本文实测使用的是 8GB 版本
• PCIe 转 SATA 扩展板。本文选用微雪 PCIe TO 2-CH SATA HAT+，价格约 100 元，包装内含 16PIN FPC 排线、SATA 数据电源一体线和铜柱。实测主控为 ASMedia ASM1061/1062，PCI ID 为 1b21:0612，提供双 SATA 接口，链路规格为 PCIe 2.0 x1。选型时具体芯片型号不是首要因素，关键是必须支持 AHCI 协议，因为 ZAC 命令需要经内核 libata 层原生传递。ASM1061、JMB582、JMB585、ASM1166 这类标准 AHCI 控制器都满足这一要求。多数 USB 转 SATA 桥接方案无法透传 zone 管理命令，除非产品明确声明支持相关 ZAC/ZBC 命令透传，因此不建议使用 USB-SATA 硬盘盒。ASM1061 与 HM-SMR 组合可能存在 NCQ 兼容性问题，可通过修改内核参数解决，详见第 5 节。预算允许的情况下，选用 JMB585 或 ASM1166 等更新的主控方案会更稳妥。
• 12V 电源。这块扩展板提供 12V DC 输入接口，规格为 4.0mm × 1.7mm，并板载 5V 和 12V 硬盘供电，这是选用它的另一个原因，3.5 寸硬盘所需的 12V 供电树莓派自身无法提供。硬盘启动瞬间 12V 电流普遍在 2A 上下，单盘建议按不低于 3A 留余量，双盘则需相应翻倍。
• HC620 本体（SATA 版）

**可选：**硬盘支架或减震垫（7200 转企业级硬盘的震动和噪音比桌面盘更明显），以及给 SATA 主控芯片贴的小散热片。

1

lspci -nn

1
2
3
4

0001:00:00.0 PCI bridge [0604]: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge [14e4:2712] (rev 21)
0001:01:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1061/ASM1062 Serial ATA Controller [1b21:0612] (rev 02)
0002:00:00.0 PCI bridge [0604]: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge [14e4:2712] (rev 21)
0002:01:00.0 Ethernet controller [0200]: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge [1de4:0001]

SATA 控制器识别为 ASMedia ASM1061/1062，class 0106 即标准 AHCI 控制器，可以正常使用。另外可以看到 Pi 5 的板载千兆网卡走的是另一条 PCIe 链路（RP1 South Bridge），与扩展板互不占用的。

组装过程比较简单。将 FPC 排线连接 Pi 5 的 PCIe 接口和扩展板，注意排线两端锁扣方向，一体线连接硬盘，12V 电源接扩展板 DC 口。然后在 /boot/firmware/config.txt 中启用外部 PCIe。是否需要手动配置与具体设备有关，较新固件检测到设备后会自动启用。

1
2
3

dtparam=pciex1
# ASM1061/1062 是 PCIe 2.0 设备，链路只会协商到 Gen2 x1（约 500MB/s）
# 对这块板设置 dtparam=pciex1_gen=3 没有意义，单盘机械硬盘也远用不满 Gen2 带宽

4 系统选择：为什么原版系统不行

这一节的内容是后续所有工作的前提。HM-SMR 盘要被内核识别为块设备，内核必须启用 CONFIG_BLK_DEV_ZONED（分区块设备支持，Zoned Block Device）。该选项启用后，SCSI 子系统对 ZBC/ZAC 盘的支持和 f2fs 的 zoned 支持会一并开启，dm-zoned 和 zonefs 则还需要各自的选项。

问题在于，Raspberry Pi OS 的官方内核没有启用这些选项。本文核对过 rpi-6.12.y 和 rpi-6.18.y 两个分支，在 arch/arm64/configs/bcm2712_defconfig 中，CONFIG_BLK_DEV_ZONED、CONFIG_DM_ZONED 和 CONFIG_ZONEFS_FS 均未启用。后果是 HC620 接上后，内核在 sd_probe 阶段直接放弃这块盘，dmesg 里只留下一行：

1

sd 0:0:0:0: Unsupported ZBC host-managed device.

此时 lsblk 看不到这块盘，/dev/sda 也不存在。

实测于 Raspberry Pi OS（内核 6.18.34+rpt-rpi-2712）：

1
2

[    1.578469] scsi 0:0:0:0: Direct-Access-ZBC ATA      HGST HSH721414AL T10B PQ: 0 ANSI: 7
[    1.578658] sd 0:0:0:0: Unsupported ZBC host-managed device.

日志显示内核识别出了这是一块 ZBC 设备，随后因不支持而放弃注册，lsblk 中只剩 SD 卡。

解决办法有两条：给 Pi OS 自编内核（见附录 A），或者换用默认带 zoned 支持的发行版。我最终选择了 Ubuntu Server 26.04 LTS（64-bit，树莓派镜像）。这台机器建成后是 7×24 运行的存储机，自编内核意味着每次 apt 更新内核都要重编一遍，或者永久 hold 内核包并放弃安全更新。Ubuntu 的 linux-raspi 内核由 apt 正常维护，zoned 支持不会因更新而丢失。26.04 基于内核 7.0，zoned 相关的代码也足够新。

烧写时在 Raspberry Pi Imager 中选择 Other general-purpose OS → Ubuntu → Ubuntu Server 26.04 LTS (64-bit)，用户名和 SSH 都可以在 Imager 的预配置里填好。Wi-Fi 预配置在 Ubuntu Server 上首启不可靠，cloud-init 应用无线配置的时机偏晚，常见表现是首次开机连不上、重启一次后恢复，5GHz SSID 受首启国家码未生效的影响更容易失败。这台机器本身是常开的存储机，首启建议直接插网线，无线可以等系统起来后再用 netplan 配置。另外还有一个 26.04 特有的情况：按官方发布说明，这一版树莓派镜像采用新的启动流程（A/B 启动布局），要求 Pi 5 的 EEPROM 固件日期不早于 2025-02-11，过旧的固件可能无法启动该镜像。如果 Pi 5 库存时间较久，先在任意能启动的系统里执行：

1
2

sudo rpi-eeprom-update      # 查看当前固件日期
sudo rpi-eeprom-update -a   # 过旧则升级，然后重启

实测本机固件日期为 2025-05-08，满足要求，无需操作（Ubuntu 上 rpi-eeprom-update 由 rpi-eeprom 包提供，可直接使用）。

系统启动后先验证内核配置，这一步的结果决定是否需要参考附录 A 自编内核：

1

grep -E "BLK_DEV_ZONED|DM_ZONED|ZONEFS" /boot/config-$(uname -r)

1
2
3
4

CONFIG_BLK_DEV_ZONED=y
CONFIG_BLK_DEV_ZONED_LOOP=m
CONFIG_DM_ZONED=m
CONFIG_ZONEFS_FS=m

四项全部齐备（实测于 26.04 的 linux-raspi 内核 7.0.0-1009-raspi）：块层 zoned 支持直接编进内核，dm-zoned 和 zonefs 以模块形式提供，本文三种文件系统方案都不需要改动内核。作为对照，同一台 Pi 5 换 Raspberry Pi OS 的卡执行同一条命令，结果是 # CONFIG_BLK_DEV_ZONED is not set。

再确认两个环境信息，后文实测会引用：

1
2

uname -r            # 实测：7.0.0-1009-raspi
getconf PAGE_SIZE   # 实测：4096

5 识盘与 zone 勘察

在带有 zoned 支持的内核上接入硬盘并上电。查看内核日志建议使用 journalctl -k -b 而不是 dmesg。内核环形缓冲区容量有限，一旦出现大量刷屏日志（例如附录 B 中的 AppArmor audit 问题），开机阶段的识盘信息会被挤出缓冲区，此时 dmesg 无法查到这些早期记录，而 journal 保存了本次启动的完整内核日志。

1

sudo journalctl -k -b | grep -iE "ahci|ata[0-9]|sd[a-z]|zbc"

以下为实测输出（节选），其中暴露出一个扩展板兼容性问题：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

ahci 0001:01:00.0: AHCI vers 0001.0200, 32 command slots, 6 Gbps, SATA mode
ahci 0001:01:00.0: 2/2 ports implemented (port mask 0x3)
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1.00: ATA-9: HGST HSH721414ALE6M0, L4GMT10B, max UDMA/133
ata1.00: 27344764928 sectors, multi 0: LBA48 NCQ (depth 32), AA
scsi 0:0:0:0: Direct-Access-ZBC ATA      HGST HSH721414AL T10B PQ: 0 ANSI: 7
sd 0:0:0:0: [sda] Host-managed zoned block device
sd 0:0:0:0: [sda] REPORT ZONES start lba 0 failed
sd 0:0:0:0: [sda] Sense Key : Aborted Command [current]
sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
（libata 错误处理，链路复位重试约 30 秒）
ata1.00: NCQ disabled due to excessive errors
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
sd 0:0:0:0: [sda] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB)
sda: detected capacity change from 0 to 27344764928
sd 0:0:0:0: [sda] 52156 zones of 524288 logical blocks

上述日志的时间线如下。链路正常协商到 6.0 Gbps，内核识别出这是一台 ZBC 设备，但第一条 REPORT ZONES（读取 zone 布局的命令）被盘中止，容量读为 0。libata 反复重试后自动禁用 NCQ，此后同样的命令立即成功，容量和区数（52156 个，一致）全部读出，整个收敛过程约一分钟。该序列每次开机都确定性复现，逐行节奏一致。这是排除接触不良、供电抖动等物理层原因的依据之一，物理层故障通常表现为随机性，不会每次都精确失败在同一条命令上。

证据强烈指向 ASM1061 对 NCQ 编码 ZAC 命令的 AUX 字段处理存在缺陷，理由有三。其一，ZAC 的 zone 管理命令经 NCQ 路径下发时（RECEIVE/SEND FPDMA QUEUED）依赖 FIS 中的 AUX 字段，而内核 drivers/ata/ahci.c 对所有 AHCI 控制器无条件启用该能力，源码注释原文为 “All AHCI controllers should be forward-compatible with the new auxiliary field. This code should be conditionalized if any buggy AHCI controllers are encountered”，即内核开发者已预见到在有缺陷的控制器上会出现此类失败。其二，ASM1061 基于 AHCI 1.2（日志中 AHCI vers 0001.0200），是 2011 年的设计，早于 AUX 字段和 ZAC 规范数年，向前兼容的假设在这类老芯片上最难得到保证。其三，内核的盘型号 quirk 表中没有任何 HC620 条目，该盘已在数据中心大规模部署多年，如果其固件的 NCQ ZAC 实现存在缺陷，理应早已被加入黑名单。日志特征也不符合典型的供电或线材故障。综合来看，现有证据高度指向 ASM1061 在 NCQ ZAC 命令处理上的兼容性问题。需要说明的是，本文未进行控制器 A/B 对照或协议级抓包，因此上述结论应视为有充分依据的故障归因，而非已完全证明的芯片缺陷。

此时硬盘已经可以正常使用，但不应每次开机都依赖约一分钟的错误重试完成收敛，需要将关闭 NCQ 的操作固化到内核命令行。在此之前需要先避开一个 26.04 特有的问题：顶层的 /boot/firmware/cmdline.txt 不是启动时实际读取的文件。26.04 的 A/B 启动布局通过 config.txt 中的 os_prefix=current/ 将固件指向槽位目录，内核、initrd、设备树以及实际生效的 cmdline.txt 都位于 /boot/firmware/current/ 之下。修改顶层文件不会生效，也不会产生任何报错。判断方法很简单，执行 cat /proc/cmdline 查看内核实际收到的参数，如果与所修改文件的内容不一致，就说明改错了文件。正确做法如下：

1
2
3
4

grep os_prefix /boot/firmware/config.txt     # 确认当前槽位，通常为 current/
sudo sed -i 's/$/ libata.force=1.00:noncq/' /boot/firmware/current/cmdline.txt
cat /boot/firmware/current/cmdline.txt       # 确认仍为单行且参数在行尾
sudo reboot

1.00 指 ata1 端口设备 0，即本盘。重启后按顺序验证：

1
2
3

cat /proc/cmdline                            # 参数应已在其中
cat /sys/block/sda/device/queue_depth        # 应为 1
sudo journalctl -k -b | grep -iE "ncq|report zones"   # 应无 failed

实测效果（节选）：

1
2
3
4

kernel: Kernel command line: ... libata.force=1.00:noncq
kernel: ata1.00: FORCE: modified (noncq)
kernel: ata1.00: 27344764928 sectors, multi 0: LBA48 NCQ (not used)
kernel: sd 0:0:0:0: [sda] 52156 zones of 524288 logical blocks

FORCE: modified (noncq) 表示内核已确认应用该参数。识盘过程从链路协商到读出全部 52156 个区在一秒内完成，全程无失败、无重试。与不添加参数时约一分钟的错误收敛过程相比，可以说明固化该参数的必要性。queue_depth 确认为 1。

正常情况下，flash-kernel 会复制 current/cmdline.txt 生成新槽位的 new/cmdline.txt，因此手工添加的 libata.force=1.00:noncq 应当会随内核更新保留。为避免更新流程或人工修改造成意外，每次内核更新后仍建议使用 cat /proc/cmdline 复查。

性能方面的代价：NCQ 主要优化并发随机读的排队，对单流顺序读写基本没有影响。这块盘本身也只适合顺序负载，因此该代价可以接受。选购扩展板时如果希望避开这一问题，可以考虑更新的 JMB585/ASM1166 方案，但任何 AHCI 控制器与 HM-SMR 的组合都建议以实测为准。

接下来从块层核对几个关键属性：

1
2
3
4
5

lsblk -z                                    # ZONED 列：host-managed，ZONE-NR 52156，ZONE-SZ 256M
cat /sys/block/sda/queue/zoned              # host-managed
cat /sys/block/sda/queue/nr_zones           # 实测：52156
cat /sys/block/sda/queue/chunk_sectors      # 实测：524288，即 256 MiB
cat /sys/block/sda/queue/scheduler          # 实测：none [mq-deadline]，默认即选中

lsblk -z 中还有两个值得关注的列。ZONE-OMAX 为 128，表示盘允许同时处于打开状态的区数上限，zoned 文件系统的并发写入布局受其约束。ZONE-APP 32M 是内核为 SATA 盘模拟 Zone Append 的单次写入上限，该能力自 6.10 起随 zone write plugging 提供，SATA ZAC 命令集本身并不包含 Zone Append。

调度器方面存在一条新老内核的分界线。Linux 6.9 及更早版本中，zoned 盘的顺序写约束依赖 mq-deadline 保证写命令不被重排，属于硬性要求。从 Linux 6.10 起，块层引入了 zone write plugging，写入排序由块层原生处理，不再强制绑定特定调度器。本文使用的 26.04 对应 7.0 内核，mq-deadline 已不是必需项，实测默认调度器恰好也选中了它。如有需要，可以通过一条 udev 规则固定（可选）：

1
2
3

cat <<'EOF' | sudo tee /etc/udev/rules.d/99-zoned-scheduler.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/zoned}=="host-managed", ATTR{queue/scheduler}="mq-deadline"
EOF

接下来使用 util-linux 自带的 blkzone 查看盘的实际布局，包括盘首部的常规区、其后大量的顺序写区，以及每个区的写指针位置：

1
2

sudo blkzone report /dev/sda | head -20
sudo blkzone report /dev/sda | grep -c CONVENTIONAL   # 常规区总数

实测输出（节选）：

1
2
3

start: 0x000000000, len 0x080000, cap 0x080000, wptr 0x000000 reset:0 non-seq:0, zcond: 0(nw) [type: 1(CONVENTIONAL)]
...（前 524 个区均为 CONVENTIONAL）
start: 0x010600000, len 0x080000, cap 0x080000, wptr 0x000000 reset:0 non-seq:0, zcond: 1(em) [type: 2(SEQ_WRITE_REQUIRED)]

输出读法：len 0x080000 为 524288 扇区，即 256 MiB。wptr 是相对区起始的偏移量，空区为 0。zcond 是区状态，常规区标记为 0(nw)（无写指针概念），空的顺序写区标记为 1(em)（empty）。常规区实测共 524 个（约 131 GiB），从盘首连续排布，至扇区 0x010600000 处切换为顺序写区。

此时可以做一个实验，直接验证 HM-SMR 的写入约束。注意不要随意挑选扇区号写入，否则即使报错也无法确定失败原因。严谨的做法是先用 blkzone report 找到一个空的顺序写区（zcond: 1(em)），其写指针位于区起始处，然后故意跳过写指针向区中间写入，使失败原因唯一指向写指针规则。以本盘第一个顺序写区（起始扇区 0x010600000 = 274726912）为例，向区内偏移 1 MiB（2048 扇区）处写入：

1
2
3

# 危险操作，仅在空盘上实验
sudo blkzone report /dev/sda | grep -m3 SEQ
sudo dd if=/dev/zero of=/dev/sda bs=512 count=8 seek=274728960 oflag=direct

1

dd: IO error: Input/output error

写入未落在写指针位置，盘按 ZAC 规范拒绝执行。普通文件系统（ext4、xfs、NTFS）的元数据更新全部属于这种原地改写操作，这正是它们无法直接格式化到这块盘上的原因，也是接下来三种方案需要解决的问题。

6 方案一：dm-zoned，模拟成普通块设备

dm-zoned 是内核 device mapper 的一个目标（target），基本思路是用盘首的常规区充当随机写缓冲区和元数据区，把整块盘向上模拟成一个无写入约束的普通块设备，并在后台执行"缓冲区 → 顺序区"的数据搬运与回收。上层可以直接格式化 ext4 使用。

代价同样来自这一原理：随机写全部先落在盘首 100 多 GiB 的常规区内，写入量增大后会触发回收，性能出现明显波动，模拟层还需要占用一部分容量存放元数据。它是三个方案中兼容性最好、使用成本最低的一个，适合只需要一块可正常挂载的大容量盘的场景。

用户态工具 dmzadm 来自 dm-zoned-tools 项目，Ubuntu 官方仓库没有收录，需要自行编译（依赖以仓库 README 为准）：

1
2
3
4
5
6
7
8

sudo apt update
sudo apt install build-essential git pkg-config m4 autoconf automake libtool \
  uuid-dev libblkid-dev libudev-dev libdevmapper-dev libkmod-dev
git clone https://github.com/westerndigitalcorporation/dm-zoned-tools
cd dm-zoned-tools
sh autogen.sh && ./configure && make
sudo make install
command -v dmzadm   # 实测安装在 /usr/sbin/dmzadm，systemd unit 里要用这个路径

初始化并启动映射：

1
2
3
4

sudo modprobe dm-zoned
sudo dmzadm --format /dev/sda --force   # 注意 dmzadm 的选项必须放在设备参数之后，盘上有旧文件系统残留时需 --force
sudo dmzadm --start /dev/sda
ls /dev/mapper/

需要 --force 的原因如下：blkzone reset 只重置顺序写区，常规区的数据不受影响，上一文件系统写在常规区中的超级块会一直残留。本文连续测试多个方案，每次格式化时都会检测到前一文件系统的签名，因此强制格式化属于正常操作。这同时也说明 reset 并不能清空整块盘，如需彻底清除数据，必须对常规区单独覆写。

实际执行 format 时，工具先报告 52156 个区的布局，然后重置全部顺序写区，写入两套互为备份的元数据（主集位于块 0，副集位于块 131072，各含映射表和位图），随后用 --start 建立映射。映射设备名为 dmz-<盘序列号>。

之后按常规流程，把 /dev/mapper/dmz-<盘序列号> 当作普通盘使用：

1
2

sudo mkfs.ext4 /dev/mapper/dmz-<盘序列号>
sudo mount /dev/mapper/dmz-<盘序列号> /mnt/hc620

开机自动挂载需要注意顺序：必须先执行 dmzadm --start 创建映射设备，再检查并挂载映射设备上的 ext4 文件系统。不能直接把 /dev/mapper/dmz-* 写进 fstab，否则启动早期映射设备尚未出现，挂载会失败。

首先取得原始 HC620 的稳定设备路径：

1

ls -l /dev/disk/by-id/ | grep HSH721414ALE6M0

假设实际路径为：

1

/dev/disk/by-id/ata-HGST_HSH721414ALE6M0_<盘序列号>

生成对应的 systemd device unit 名：

1
2

systemd-escape --path --suffix=device \
  /dev/disk/by-id/ata-HGST_HSH721414ALE6M0_<盘序列号>

输出类似：

1

dev-disk-by\x2did-ata\x2dHGST_HSH721414ALE6M0_<盘序列号>.device

然后创建服务：

1
2
3
4
5
6
7
8
9
10
11
12

# /etc/systemd/system/dm-zoned-hc620.service
[Unit]
Description=Activate dm-zoned mapping for HC620
Requires=dev-disk-by\x2did-ata\x2dHGST_HSH721414ALE6M0_<盘序列号>.device
After=dev-disk-by\x2did-ata\x2dHGST_HSH721414ALE6M0_<盘序列号>.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/usr/sbin/modprobe dm-zoned
ExecStart=/usr/sbin/dmzadm --start /dev/disk/by-id/ata-HGST_HSH721414ALE6M0_<盘序列号>
ExecStop=/usr/sbin/dmzadm --stop /dev/disk/by-id/ata-HGST_HSH721414ALE6M0_<盘序列号>

这里不写 [Install]，也不执行 systemctl enable dm-zoned-hc620.service。服务由后面的 fstab 挂载单元按需启动，避免在硬盘未连接时被系统单独启动。

先手动启动一次映射，确认映射设备名称：

1
2

sudo systemctl start dm-zoned-hc620.service
ls -l /dev/mapper/

假设映射设备为：

1

/dev/mapper/dmz-<盘序列号>

在映射设备上创建 ext4 文件系统，然后查询其文件系统 UUID：

1
2

sudo mkfs.ext4 -L HC620_DATA /dev/mapper/dmz-<盘序列号>
sudo blkid /dev/mapper/dmz-<盘序列号>

注意，这里需要记录的是 dm-zoned 映射设备上 ext4 的 UUID，不是原始 HC620 的设备路径或序列号。

创建挂载点：

1

sudo mkdir -p /mnt/hc620

随后在 /etc/fstab 中加入：

1

UUID=<ext4文件系统UUID> /mnt/hc620 ext4 defaults,noatime,nofail,x-systemd.requires=dm-zoned-hc620.service,x-systemd.device-timeout=60s 0 2

各选项作用如下：

• noatime：读取文件时不更新访问时间，减少不必要的写入。
• nofail：硬盘未连接、映射失败或文件系统损坏时，不阻止系统继续启动。
• x-systemd.requires=dm-zoned-hc620.service：挂载前先启动 dm-zoned 映射服务，并等待服务成功完成。
• x-systemd.device-timeout=60s：最多等待映射设备出现 60 秒。
• 最后的 0 2：不做 dump，并允许在启动时对该非根 ext4 文件系统执行 fsck。

修改完成后重新载入 systemd 配置并测试：

1
2
3
4
5
6
7
8

sudo systemctl daemon-reload

# 如果当前已经挂载，先按正确顺序停止
sudo systemctl stop mnt-hc620.mount
sudo systemctl stop dm-zoned-hc620.service

# 只启动挂载单元，验证它能否自动拉起 dm-zoned 服务
sudo systemctl start mnt-hc620.mount

检查服务、映射和挂载状态：

1
2
3
4

systemctl status dm-zoned-hc620.service
systemctl status mnt-hc620.mount
dmsetup ls
findmnt /mnt/hc620

确认无误后再重启测试：

1

sudo reboot

重启后检查：

1
2
3

findmnt /mnt/hc620
systemctl status dm-zoned-hc620.service
journalctl -b -u dm-zoned-hc620.service

dmzadm 官方支持使用底层 zoned 设备执行 --start 和 --stop。默认安装路径为 /usr/sbin/dmzadm，但仍应以 command -v dmzadm 的实际输出为准。

性能实测：

顺序写 98 MB/s，顺序读 148 MB/s，兼容层对顺序流的损耗不大，与 btrfs 处于同一水平，均低于 f2fs 的满速。4K 随机写 1.9 MB/s，约 456 IOPS，平均延迟 17.5ms，99 分位 139ms，长尾拖到秒级（99.9 分位 514ms，最大 1.4s）。这是三个方案中唯一让真实随机写直接落盘的方案：写入直接进入常规区缓冲，不经过追加转换，机械盘随机写的物理规律全部生效。456 IOPS 对 7200 转硬盘而言已经不错（缓冲区域集中在盘首，寻道距离较短），但与追加转换方案相比仍有数量级的差距，延迟长尾也很明显。小文件方面，ext4 的页缓存路径表现正常：内核源码树解压 8.7 秒，删除加 sync 约 2 秒。按第十节的测试方法，180 秒的随机写全部落在 131 GiB 缓冲区之内，未触发大规模回收。回收发生时的性能衰减仅依据机制推断，未做实测。

7 方案二：btrfs zoned，原生支持但有功能限制

btrfs 从内核 5.12 起原生支持 zoned 模式，把块组（block group）直接对齐到 256MiB 的区上。写时复制（CoW）本身不做原地改写，与顺序写约束天然一致。这个方案不需要模拟层，也没有额外的数据搬运开销，是三个方案中最贴近盘本身工作方式的一种。

格式化只多一个 -O zoned 参数，但我的第一次尝试直接失败了。当时盘上还残留着上一任使用者的 f2fs 文件系统，卷标 happy_every_day，说明这块盘此前确实被当作 zoned 盘正常使用过。加 -f 强制格式化时，mkfs.btrfs 在 Resetting device zones /dev/sda (52156 zones) 阶段报 failed to reset device zones: Input/output error 后退出。

排查过程如下。手动对单个顺序写区发重置（blkzone reset -o 274726912 -c 1）成功。blkzone reset /dev/sda 全盘重置同样成功，仅耗时 2.5 秒，内核对整盘范围会走优化路径，即带 ALL 位的单条 RESET WRITE POINTER。重置后全盘扫描（blkzone report | grep -vE "0\(nw\)|1\(em\)"）未发现任何 read-only 或 offline 异常区。而 btrfs-progs 源码里 mkfs 的重置是逐区进行的，每个非空的顺序写区单独发一条 BLKRESETZONE。首次失败时盘上有 f2fs 数据和数千个非空区，失败就发生在这条长命令流中的某一处。单区重置与 ALL 位重置均正常，异常区为零，具体是哪条命令、为何失败，已无法确认。

实用结论：对非空的二手盘，mkfs 之前先手动全盘重置。这样既能绕开逐区重置的长命令流，也能把格式化失败与盘况问题解耦：

1

sudo apt install btrfs-progs

1
2
3

sudo blkzone reset /dev/sda           # 约 2.5 秒，一条命令重置全部顺序写区
sudo mkfs.btrfs -f -O zoned /dev/sda
sudo mount /dev/sda /mnt/hc620

预清空后 mkfs 一次通过，关键输出：

1
2
3
4
5
6
7
8

Zoned device:       yes
  Zone size:        256.00MiB
  Mode:             host managed
Sector size:        4096
Filesystem size:    12.73TiB
Number of devices:  1
  ID  SIZE      ZONES  PATH
   1  12.73TiB  52156  /dev/sda

使用前要清楚 zoned 模式的功能限制，这些限制都源于无法原地更新这个物理事实：

• nodatacow 不可用。没有 CoW 就意味着必须原地改写，物理上不允许，因此给虚拟机镜像或数据库关闭 CoW 这类常见做法在 zoned 模式下不可行。
• fallocate 预分配不可用，部分依赖它的软件（某些下载器、qBittorrent 的预分配选项）需要关闭相应功能。
• 多设备支持仍有限。较新内核配合 raid-stripe-tree 已支持 RAID0、RAID1 等部分配置，RAID5/6 仍不可用，具体能力高度依赖内核与 btrfs-progs 版本。本文只测试单盘，结论不要直接外推到阵列。
• 空间回收的逻辑是先把区内仍然有效的数据搬走，然后才能重置旧区再利用。较新的 btrfs 自带后台 zone reclaim 机制，也可以用 balance 主动整理 block group。长期运行需要持续观察区利用率、回收频率和写放大。

实测结果（方法与参数见第10节）：顺序写 20GiB 为 104 MB/s，带宽在 36–174 MiB/s 间波动，平均延迟 40ms。顺序读 20GiB 为 154 MB/s，与常规区的裸盘读速完全一致，文件系统层几乎无损耗。4K 随机写 180 秒为 7.4 MB/s、约 1800 IOPS，平均延迟 4.4ms，99 分位 9.9ms。内核源码树解压（约 8 万个小文件）7.7 秒，删除加 sync 约 8 秒。

随机写这个数字需要单独解释。7200 转机械盘的原地 4K 随机写物理上限大约是一两百 IOPS，这里测出 1800，是 CoW 在 zoned 模式下把随机写全部转成顺序追加的结果，盘自始至终处于顺序写状态。代价是延后的：每次改写都落在新位置，旧数据成为等待回收的垃圾，180 秒写入的 1.27GiB 全部是新分配。随机写越多，积累待回收的空间越大，随机写的性能优势和回收压力的累积来自同一个机制。

8 方案三：f2fs（日志结构文件系统）

f2fs 本身是日志结构（log-structured）文件系统，追加写入与垃圾回收是其原生工作方式，与顺序写区的约束一致。zoned 支持随 CONFIG_BLK_DEV_ZONED 自动编译，元数据放在盘首的常规区。容量方面需要注意，在常用的 4KiB 块大小与 32 位块寻址实现下，f2fs 单卷上限约 16TiB，14TB 型号格式化后的 12.7TiB 在上限之内，15TB 型号同样可以容纳。

1
2
3

sudo apt install f2fs-tools
sudo mkfs.f2fs -f -m /dev/sda    # -m 即 zoned 模式
sudo mount /dev/sda /mnt/hc620

mkfs.f2fs（f2fs-tools 1.16.0）在识别盘的过程中独立报出了与 blkzone 一致的布局，其中包括 524 个可随机写区，与第5节的常规区计数互相印证：

1
2
3
4
5

Info: Host-managed zoned block device:
      52156 zones, 268435456u zone size(bytes), 524 randomly writeable zones
      65536 blocks per zone
Info: Overprovision ratio = 0.450%
Info: Overprovision segments = 30103 (GC reserved = 29569)

挂载后自动启用 mode=lfs（严格日志结构写入，zoned 盘必需）、active_logs=6 和 discard。实测结果在三方案中最好。顺序写 242 MB/s，顺序读 244 MB/s，达到甚至略超官方标称值，具体成因见第10节的带宽分析。4K 随机写 55.9 MB/s，约 1.36 万 IOPS（99 分位延迟约 3ms），是 btrfs 的七倍以上。这一优势来自 mode=lfs 的追加写转换与多路活跃日志的批量提交机制。回收的代价同样可以直接观察到，随机写 180 秒后 dirty_segments 从 0 增长到 4099（约 8 GiB 待回收段），与写入量吻合。小文件负载是 f2fs 的弱项，内核源码树解压用时 42.0 秒，而 btrfs 只需 7.7 秒。删除加 sync 约 1.7 秒。

9 按需：zonefs

如果想直接使用 zone 这层抽象，内核还有一个极简的 zonefs：每个区暴露为一个文件，顺序写区的文件只能追加（append-only），删除内容等于重置区。它不是通用文件系统，而是给自研归档、日志类工具用的接口。需要时安装 zonefs-tools，用 mkzonefs 创建，此处不展开。

10 性能小结与适用场景

三个方案尽量采用一致的测试参数和空盘初始状态，以提高横向可比性。每次更换文件系统前执行 blkzone reset 全盘重置并重新 mkfs，从全空盘开始测试。fio 统一使用 --direct=1 --ioengine=libaio，顺序读写 bs=1M iodepth=4 size=20G，4K 随机写 iodepth=8 时间制 180 秒。另用解压内核源码树（约 8 万个小文件）测试真实元数据负载。注意 fio 必须加 --fallocate=none，fio 默认用 fallocate 预分配测试文件，在 btrfs zoned 上会直接失败，这与第7节所列的限制一致。裸盘顺序读基线（只读安全）分别测盘首与盘尾各 8G，用于验证外圈到内圈的速度衰减。但 zoned 盘在测量上有一个需要注意的问题：空区（写指针之后）的读取不落盘，由盘的电路直接返回零，测出的是 SATA 链路速度而不是盘片速度（实测空区读出 374MB/s，超出盘片的物理能力）。内圈基线必须先用 fio --zonemode=zbd 合法写入数据再读。随机写结果的解读要注意边界：dm-zoned 的短时随机写基本落在 131 GiB 常规区缓冲内，不触发大规模回收，数据仅代表缓冲未满时的表现。长期回收行为未纳入实测，只作机制层面的说明，受机械盘速度限制，这无法在一轮基准测试的时间内充分覆盖。

裸盘基线（fio 固定 1 MiB、direct）：常规区读 154 MB/s，内圈写/读约 116 MB/s。

三个方案各有侧重。要吞吐和稳定的写延迟选 f2fs，顺序写达到满速，随机写通过 lfs 追加转换获得数量级优势，代价是小文件性能较差和功能相对单薄。要功能生态选 btrfs，快照、校验、send/receive 俱全，小文件最快，顺序写性能有折损。要兼容性选 dm-zoned，上层是普通的 ext4，对软件没有特殊要求，但随机写是三者中唯一回落到机械盘物理水平的，长尾延迟高出一个数量级，且回收开销由设备映射层承担，而不是由文件系统承担。

带宽数据需要结合实测分析。裸盘基线为常规区读 154 MB/s、内圈写读约 116 MB/s，我最初将这一差距归因于关闭 NCQ 的代价。但 f2fs 随后跑出 242/244 MB/s 的顺序写读，达到甚至略超 14TB 型号官方典型持续传输率 233 MB/s（约 223 MiB/s，外圈较快、向内圈递减），说明这条链路在 noncq 下依然可以达到满速。裸设备基线只有 154 MB/s，而 f2fs 文件读写达到 242/244 MB/s，说明瓶颈并非 SATA 链路或关闭 NCQ 本身。差异可能与实际落盘 LBA、请求合并方式、文件系统提交模式以及测试文件的物理布局有关。本文没有通过 filefrag、blktrace 等手段进一步核对请求与物理位置，因此不对具体原因下确定结论。可以确认的是，在本文实际文件负载下，关闭 NCQ 并未限制顺序吞吐接近该盘的官方典型值。btrfs 顺序写 104 MB/s，存在较明显的额外开销。

场景判断：

适合：以大文件、批量、追加写为主的负载。媒体归档、一次写入长期保存的冷数据、备份仓库（restic、borg 的日常备份以追加写为主）。这类负载最容易发挥 HM-SMR 的优势，但"适合"不等于"全程无感"。备份工具的 prune、compact、重建索引阶段会产生删除和元数据改写，rsync 增量同步会改写既有文件，NVR 类软件可能频繁更新索引数据库。这些维护阶段的延迟和写放大需要单独测试评估，只测一轮全量上传是不够的。

不适合：用作日常 NAS 数据盘（家庭 NAS 的写入远比想象中随机）、BT 下载盘（大量乱序写+预分配）、数据库或虚拟机存储。dm-zoned 能让这些场景运行，但回收压力大时延迟波动会非常明显。

总结：它的低价来自负载限制。负载匹配时性价比很高，不匹配时不建议购买。

附录 A：Raspberry Pi OS 自编内核路线

如果这台 Pi 还要承担 Pi OS 生态绑定的任务（比如 libcamera/rpicam 摄像头栈），可以走自编内核路线。基于官方 defconfig 补上以下选项：

1
2
3

CONFIG_BLK_DEV_ZONED=y    # 必需，块层 zoned 支持，f2fs/btrfs 的 zoned 路径随之启用
CONFIG_DM_ZONED=m         # 按需，方案一 dm-zoned
CONFIG_ZONEFS_FS=m        # 按需，zonefs

流程与官方文档的内核编译指南一致：拉取 raspberrypi/linux 对应分支，执行 make bcm2712_defconfig，然后在 menuconfig 中启用上述选项（Enable the block layer → Zoned block device support；Device Drivers → Multiple devices driver support → Device mapper support → Drive-managed zoned block device target support；File systems → zonefs），最后编译安装。完整的编译与长期维护流程（交叉编译环境、config fragment 脚本化、独立内核名安装布局、一行回滚、跟版节奏）我会另文展开。

需要注意的是，自编内核不在 apt 更新体系内，但维护工作可以做得比每次更新后被动重编更有条理。推荐的做法是编译时用 LOCALVERSION 起独立版本名（如 -zoned），内核镜像安装为独立文件（如 /boot/firmware/kernel-zoned.img），并在 config.txt 里用 kernel=kernel-zoned.img 指定加载。这样官方内核更新只覆盖它自己的 kernel_2712.img，与自编内核互不干扰，系统其余部分可以照常 apt full-upgrade。维护由此变成主动决定跟版节奏，例如按月跟进一次，交叉编译约消耗二十分钟机器时间，config 改动固化成 fragment 加构建脚本即可。代价是两次跟版之间内核无法获得安全补丁，因此该方案适合内网存储机，不适合暴露面大的场景。另外需要排除一个看似可行的思路：DKMS 式的模块外挂并不存在。CONFIG_BLK_DEV_ZONED 是编入内核本体的块层核心选项，dm-zoned 和 zonefs 模块都依赖它，因此不存在不重编内核的替代路径。

附录 B：解决 Rust coreutils 的 AppArmor 日志刷屏

Ubuntu 26.04 将 coreutils 替换为 Rust 实现（uutils）。新实现下 who 等命令启动时会读取本地化目录 /usr/share/coreutils/locales/，而配套的 AppArmor profile 没有放行该路径，读取被拒绝后 who 没有任何输出。部分 SSH 客户端的远程监控栏每秒调用一次 who，每次调用都会写入一条 audit 记录，日志因此持续刷屏。解决方法是向该 profile 的 local 覆盖文件追加一条读取规则。使用 local 覆盖而不是直接修改 profile 本体，是因为软件包更新不会改动 local 文件，规则可以长期保留：

1
2
3
4
5
6

sudo apt update && sudo apt upgrade    # 先看是否已有官方修复
sudo aa-status | grep who              # 实测 profile 名即为 who
# Ubuntu 已为每个 profile 预置 local 覆盖文件，直接追加规则即可
echo "/usr/share/coreutils/locales/** r," | sudo tee -a /etc/apparmor.d/local/who
sudo apparmor_parser -r /etc/apparmor.d/who
who                                    # 应恢复正常输出，audit 不再新增

规则生效后 who 输出恢复正常，audit 日志停止刷屏。

附录 C：通过 SMB 共享给 Windows

归档盘只在树莓派本地读写不够方便，这一节用 Samba 把它共享出去，让 Windows 资源管理器直接访问。以下按正文的挂载点 /mnt/hc620 操作。

C.1 固定挂载

共享服务要求盘在开机后自动就位。在 /etc/fstab 追加一行（UUID 用 sudo blkid /dev/sda 查询）：

1

UUID=<UUID占位>  /mnt/hc620  btrfs  noatime,compress=zstd,nofail  0  0

noatime 省去纯读取触发的元数据回写，compress=zstd 能为归档数据节省一部分容量（照片、视频等本身已压缩的数据会自动跳过），nofail 保证盘不在位时系统照常启动。修改后执行 sudo mount -a 验证无报错。

C.2 安装与共享配置

1

sudo apt install samba wsdd2

wsdd2 负责让共享出现在 Windows 的"网络"列表中。现代 Windows 已不再使用 NetBIOS 发现主机，缺少这个组件时共享功能本身正常，但在网络邻居中不可见，这是这套配置里最容易遗漏的一点。

创建共享目录并将属主改为当前用户：

1
2

sudo mkdir -p /mnt/hc620/archive
sudo chown $USER:$USER /mnt/hc620/archive

在 /etc/samba/smb.conf 末尾追加：

1
2
3
4

[archive]
   path = /mnt/hc620/archive
   read only = no
   inherit permissions = yes

设置 Samba 密码（与系统密码独立）并重启服务：

1
2

sudo smbpasswd -a $USER
sudo systemctl restart smbd wsdd2

C.3 Windows 端访问

直接在地址栏输入：

1

\\<树莓派主机名或 IP>\archive

凭据使用上一步的系统用户名和 Samba 密码。首次连接勾选"记住凭据"，之后可右键映射为网络驱动器。

注：Pi 5 连接无线网络下的传输速度

C.4 使用方式

最后提醒一点：这块盘的正确使用方式是整文件拷入、只读取出，共享目录按归档用途使用即可。在共享上直接编辑文件、频繁原地改写，相当于沿用 CMR 盘的使用习惯对待 HM-SMR 加 CoW 文件系统的组合。这样做可以工作，但每次改写都会触发正文介绍过的整段 CoW 开销。

附录 D：定期 scrub 巡检

btrfs 的全数据校验和只在读取时验证，而归档数据的常态是写入后多年不再读取，静默腐坏可能一直潜伏到真正需要那个文件时才暴露。scrub 主动将已用空间完整读取一遍，逐块比对校验和，把被动的"读到才发现"变成主动的定期巡检。单盘没有冗余副本，scrub 无法修复损坏的数据，但会在内核日志中给出损坏文件的具体路径，趁源数据还在手里重新拷贝一份即可。只有发现得早，这个补救手段才成立。

两个文件加一条命令。

/etc/systemd/system/btrfs-scrub-hc620.service：

1
2
3
4
5
6
7

[Unit]
Description=Monthly btrfs scrub on HC620
ConditionPathIsMountPoint=/mnt/hc620

[Service]
Type=oneshot
ExecStart=/usr/bin/btrfs scrub start -B /mnt/hc620

/etc/systemd/system/btrfs-scrub-hc620.timer：

1
2
3
4
5
6
7
8
9
10

[Unit]
Description=Monthly btrfs scrub timer for HC620

[Timer]
OnCalendar=monthly
Persistent=true
RandomizedDelaySec=1h

[Install]
WantedBy=timers.target

启用：

1
2

sudo systemctl enable --now btrfs-scrub-hc620.timer
systemctl list-timers btrfs-scrub-hc620.timer   # 确认下次触发时间

几个参数各有用途。-B 让 scrub 在前台运行，service 的退出状态才等于巡检结果，用 systemctl status btrfs-scrub-hc620.service 即可确认上次巡检是否发现错误。ConditionPathIsMountPoint 在盘未挂载时静默跳过，与附录 C 挂载参数里的 nofail 配套，盘不在位时系统不会报错。Persistent=true 用于补跑关机期间错过的计划，RandomizedDelaySec 把触发时间错开整点，避免集中负载。

查看结果：

1
2

sudo btrfs scrub status /mnt/hc620   # 上次进度、耗时、错误计数
sudo dmesg | grep -i "checksum error"   # 有错误时含具体文件路径

耗时量级：scrub 顺序读取全部已用空间，按本盘外圈两百余、内圈一百余 MB/s 的读速估算，每 1TB 数据约需一小时出头，写满后全盘一轮需要十几到二十小时，这是巡检频率定为每月而非每周的原因。巡检期间盘保持正常可用，读性能会被分走一部分。

身份立住之后，砚行物流这套平台只剩最后一块地基没夯实：时间。它听起来最不起眼，却在上一篇里以一种很隐蔽的方式咬过我们一口——yx-dc01 的 AD CS 在时钟还没同步好时签出的根证书，NotBefore（生效时间）落到了未来，等时间校正回来，vCenter 接 LDAPS 直接报「Certificate is not valid」。那其实不是证书的错，是时间的错。这一篇就把时间这件事正经做完：把整套时间层级理顺到 AD 域控上，收回当初在网络篇为管理网主机访问 OPNsense NTP 开的那条放行规则；再补讲一直推迟到收尾才讲的 vLCM 镜像；最后对这套从物理规划一路走到身份与时间的平台，做一次整体回顾和「实验 vs 生产」的总差距清单。这是本系列的最后一篇。

1 为什么时间是最后一块地基

时间在虚拟化平台里是「隐形的依赖」：平时没人注意，一旦漂了，故障会以各种看不出和时间有关的样子冒出来。上一篇那颗证书的雷是一个例子——表面是证书错误，根子是签发时钟不对。类似的还有很多：Kerberos 认证默认只容忍 5 分钟的时钟偏差，超了域登录就失败；vSAN 对各主机间的时间一致性敏感；vCenter 的 Skyline Health 里专门有一项 Time is synchronized across hosts and VC，时间一对不上它就报红。

所以把时间搞稳，不是锦上添花，而是前面所有东西能稳定运行的前提。这也是为什么我们在身份篇里立 dc01 时，就已经抢先把它的时间钉准了（提升域控、装 CA 之前那一步）——那是为了不让证书踩雷。这一篇把当时只做了一半的事补全：当时只配了 dc01 这个 PDC 对外同步，剩下「其余成员、以及 ESXi 和 vCenter 怎么并进这套时间层级」，留到现在。

2 Windows 域的时间层级：PDC 对外，成员跟域

先把 Windows 域里的时间规则讲清楚，否则很容易配错。AD 域的时间是一套严格的层级：

• 域里持有 PDC 模拟器（PDC Emulator）FSMO 角色的那台域控，是全域的时间权威。在我们这套单域单林里，这台就是 yx-dc01。
• 其余所有成员——yx-dc02、将来任何加域的服务器——默认都跟着「域层级」要时间，一级一级最终跟到 PDC。这个模式在 w32tm 里叫 NT5DS。
• 而 PDC 自己头上没有域层级了（它就是顶点），所以它必须被显式指向一个外部时间源，否则它会找不到上游、回落到本机 CMOS 时钟自己走。

这一段我们在身份篇已经修好了，这里把命令复述一遍作为时间层级的起点（在 dc01 上，管理员 CMD）：

1
2
3
4

w32tm /config /manualpeerlist:"10.0.40.1,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /rediscover
w32tm /query /status

/manualpeerlist 把 PDC 指向外部源、/reliable:yes 把它标成全域可靠时间源。外部源填 10.0.40.1（OPNsense 在 SERVER 网段的接口，它本身经 WAN 跟公网 NTP 同步），不填管理网的 10.0.10.1——理由和 DNS 转发器、LDAPS 一样：网络篇的管理网隔离会把 SERVER 网段主动去管理网的流量挡掉。配完 Source 应从 Local CMOS Clock 变成 10.0.40.1、Stratum 降到个位数（经 OPNsense 一般是 3~4）。

若 w32tm /resync 仍失败，先回 OPNsense 检查 Services → Network Time → General，确认 NTP 服务监听了 SERVER 接口（或监听 All）；同时确认 SERVER 接口规则允许本段访问防火墙自身的 UDP 123。这和身份篇里把 DNS forwarder 改成 10.0.40.1 是一个道理——指对了接口，还得那个接口上的服务真在听、规则真放行。

3 把 ESXi 和 vCenter 的时间也并入

域内时间理顺了，但 ESXi 主机和 VCSA 都不是域成员，它们走的是各自的 NTP 配置。前面几篇里，它们的 NTP 源指的是 OPNsense 10.0.10.1。这一篇把它们一并切到 AD 域控上，让 AD 成为内网统一的时间权威。

三台 ESXi 主机：在 vSphere Client 里，每台 Host → Configure → System → Time Configuration → Edit（Network Time Protocol），NTP 服务器填 10.0.40.10,10.0.40.11，NTP Service Startup Policy 选 Start and stop with host，启动服务。三台都做。

VCSA（yx-vc01）：在 VAMI（https://10.0.10.20:5480）→ Time → Time synchronization，模式选 NTP，服务器填 10.0.40.10,10.0.40.11。注意 VCSA 的时间要么走 NTP、要么走 Host（从 ESXi 同步），二选一别同时开；这里选 NTP 直连域控，逻辑最清楚。

切完之后，ESXi/VCSA 不再向 10.0.10.1 要时间了，于是可以收回网络篇当初为它们在管理隔离里开的那条 123 放行（呼应网络篇的口子）。但收的时候看清楚：要收的是「管理网设备 → OPNsense 10.0.10.1 的 123」这条；别误删 PDC 经 10.0.40.1 出去的那条——dc01 还靠它对外同步，删了 PDC 就又回落 CMOS 了。

4 验证时间已对齐

把时间这块该绿的都绿一遍：

• 域内：dc01 上 w32tm /query /status 的 Source 是 10.0.40.1、Stratum 个位数；dc02 及任何成员上 Source 指向 dc01（域层级）。在任一 DC 上 w32tm /monitor 能看到全域各 DC 的 offset 都很小。
• ESXi：每台 Time Configuration 显示 NTP 服务 running、时间一致；命令行可 esxcli system ntp test（或看 esxcli system time get）确认在跟 DC 走。
• VCSA：VAMI Time 显示已同步。
• Skyline：vCenter 的 Skyline Health 里 Time is synchronized across hosts and VC 一项转绿——这是时间真正对齐的权威信号。

5 补讲 vLCM 镜像：一直推迟到收尾的那块

前面 vCenter 篇、存储篇都把 vLCM（vSphere Lifecycle Manager）推到了收尾才讲，现在补上。它管的是「怎么把整个集群的 ESXi 软件栈保持一致、并统一升级」。

两种模式，以及为什么只剩一条路。 vLCM 有两种管理方式：老的 baselines（基线，前身是 vSphere Update Manager / VUM，逐台打补丁的命令式做法）和新的 Images（镜像，声明式地定义「这个集群所有主机都应该长成这个样子」）。版本现实很清楚：vSphere 8.0 起 baseline 已被弃用、新建集群默认就是镜像模式；到 vSphere 9.0，用 baseline 升级集群/主机被弃用，仍在用 baseline 的集群必须先转成镜像才能升级到 9.x。所以镜像是前进的唯一方向，baseline 只是过渡期的遗留。

一张镜像由什么组成。 base image（ESXi 版本本身，唯一必填项）+ vendor add-on（OEM 厂商的驱动/补丁集合）+ firmware-and-drivers add-on（固件与驱动，需要硬件厂商的 hardware support manager 插件）+ 若干 components（第三方驱动/组件）。镜像把这一整套钉成一个「期望状态」，集群里每台主机都按它对齐。

操作（Cluster → Updates → Image）。 进集群的 Updates → Image：如果它提示你 Setup Image，说明这个集群当前还是 baseline 管理的。8.0U3 起转镜像很省事——不用自己导 ISO 或拼镜像，可以直接采纳「集群里某台主机上已经装着的镜像」（Get Installed Images），Finish Image Setup，跑一次合规检查，再 Remediate。

滚动修复（rolling remediation）。 修复时主机一台一台来：当前主机进维护模式，DRS/vMotion 把上面的 VM 疏散到别的主机（靠我们 HA 篇启用的 Fully Automated DRS 自动完成），打补丁/升级、按需重启，再轮到下一台——全程集群对外不停服。Quick Boot 能跳过固件自检加速重启；8.0U3 的 LivePatch 还能让部分修复免重启免疏散。注意 vLCM 的合规校验和修复依赖 DNS 解析和网络连通——这正好是我们身份篇刚理顺的东西，算是前面几篇给这一步铺好了路。

不过在本实验这套 64 GB 宿主、30/12/12 GB 的紧配置下，别把「滚动修复不停服」理解成必然能实操成功——这和 HA 篇里「VCSA 自我保护在本实验只是概念」是同一类资源现实。yx-esxi01 给了 30 GB（含 VCSA + vSAN），esxi02/03 各 12 GB，而 VCSA Tiny 要 14 GB：一旦 vLCM 要修复的恰好是承载 VCSA 的那台主机，其它两台未必接得住 14 GB 的 VCSA，DRS/vMotion 疏散就会失败，remediation 也无法无中断完成。所以本篇主要演示 vLCM Image 的概念、合规检查与流程；真要执行 remediation，先确认 VCSA 和其它 VM 都能被迁走（或临时把目标主机内存调高、把非必要 VM 关掉腾位）。

6 全系列收尾：砚行物流这套平台回头看

到这里，砚行物流的虚拟化平台从无到有走完了一整条路：从序章的物理与网段规划，到用 OPNsense 把边界和各 VLAN 立起来（环境篇），装三台嵌套 ESXi（ESXi 篇），部署 vCenter 建集群（vCenter 篇），用 vDS 把网络收口（网络篇），用 vSAN 把三台的本地盘聚成共享存储（存储篇），开 HA/DRS 让它能自愈和均衡（HA 篇），立 AD 域控把身份和 DNS 统一（身份篇），最后把时间层级理顺（本篇）。计算、网络、存储、高可用、身份、时间——一套企业虚拟化平台该有的地基，齐了。

这套平台的价值在于「能完整复现一遍企业级架构的搭建逻辑」，但它终究是跑在一台 64 GB 笔记本上的全嵌套实验室。哪些地方是为了能在单机上跑而做的妥协、真要上生产该补什么，这份清单值得收拢成一处——它也是贯穿全系列那些「生产环境对照」框的总账：

把这些差距列清楚，不是给实验室泼冷水，而是让它的价值落到实处：你在这台笔记本上踩过的每一个坑——证书的时间雷、跨网段那些反方向的防火墙口子、PDC 回落 CMOS、嵌套的循环依赖——到了真实生产里都还会以更高的代价重现，而你已经知道它们长什么样、根在哪里。这套平台真正留下的，不是那几台虚拟机，是这份「知道会在哪卡住」的经验。

砚行物流的平台到此就算立住了。从一张网段规划图开始，到现在计算、网络、存储、高可用、身份、时间一层层叠完——这趟从零到一的搭建，就到这里。

到这一篇为止，砚行物流的平台已经把计算、网络、存储、高可用都铺好了，但有一件事一直没动：到现在为止，能登进 vCenter 的只有一个账号——administrator@vsphere.local。这是 SSO 内置域里的本地账号，既不是「公司账号」，也没法和文件服务器、其他系统共用同一套身份。这一篇就把这块补上：在 YX-Server（VLAN40）立起一对冗余域控，建域 corp.yanxing.internal，把内网的权威 DNS 交给 Active Directory，再把 vCenter 以外部身份源的方式接进来。立完之后，YX-Server 端口组也终于迎来它第一批正式住户。

1 为什么先立域：从 administrator@vsphere.local 说起

administrator@vsphere.local 能用，但它是个「孤岛账号」。它只活在 vCenter 自带的 SSO 域里，离开 vCenter 谁都不认；想给同事分权，要么共享这一个超级账号（审计噩梦），要么在 SSO 本地域里一个个手建用户。真实企业不会这么干——身份要有一个统一的、可审计的、能跨系统复用的来源，这个来源在 Windows 生态里几乎默认就是 Active Directory（活动目录，AD）。

把 AD 立起来之后，vCenter 不再自己管人，而是把「这个人是谁、密码对不对、属于哪个组」这件事外包给 AD；vCenter 只负责「这个组能在 vSphere 里做什么」。账号的增删改、离职禁用、组成员调整，全在 AD 那一侧完成，vCenter 这边的权限规则基本不用动。这就是「身份源（identity source）」的价值。

这里有一个必须先讲清楚的版本现实，它直接决定了我们这一篇的接入方式怎么选。历史上 vCenter 接 AD 有两条路：一条是把 vCenter 这台 VCSA 真正加入 AD 域（Integrated Windows Authentication，IWA，域加入法），另一条是不加域、只把 AD 当成一个外部 LDAP 目录来查询（AD over LDAP）。

这一篇的落地顺序是：先立第一台域控 yx-dc01 并建出新林新域，把 AD 集成 DNS 顺势起来；再做 DNS 整合（这是和现状衔接最关键的一步）；然后加第二台域控 yx-dc02 做冗余；最后把 vCenter 以 AD over LDAPS 身份源接进来，用域账号验证登录。

2 部署第一台域控 yx-dc01

2.1 选 ISO 与建虚拟机

操作系统用 Windows Server 2025 Standard 评估版（Desktop Experience，带图形界面）。评估版从 Microsoft Evaluation Center 下载，评估期 180 天，且可以 rearm（重置评估计时）最多 6 次、累计接近 3 年，对实验室完全够用；带 Desktop Experience 是为了有完整 GUI，方便截图和用 Server Manager 点配置。下回来的 ISO 可以上传到 vSphere Content Library；如果前面几篇没有单独建过 Content Library，也可以直接把它放进 vsanDatastore 下的一个 ISO 目录，或在新建 VM 时从本地客户端临时挂载 ISO。下面的截图按 Content Library 路线演示，但它不是本篇的硬性前提，三条路任选其一即可。

VM 规格：2 vCPU、4 GB 内存、60 GB 精简置备磁盘、固件选 UEFI（和我们其他较新的 VM 一致；嵌套环境里 Secure Boot 可开可不开）。网络挂到 vDS 的 YX-Server(VLAN40) 端口组——这是 VLAN40 的第一台正式住户。

2.2 装系统、配静态网络

装完系统、设好本地 Administrator 密码后，先把这台机器从随机机器名改成有意义的名字 yx-dc01（提升域控前改名最省事，提升之后再改名会牵动一堆注册记录），然后配静态网络：

• IP：10.0.40.10，掩码 /24，网关 10.0.40.1（VLAN40 是路由段，网关在 OPNsense 上）
• 首选 DNS：先指向自己，即 127.0.0.1（提升为域控、AD 集成 DNS 起来之前，它先用本机回环占位；提升之后我们再来调整 DNS 指向）

网络配好后、提升域控和装 CA 之前，先把这台机器的时间对齐——这是个必须排在前面的步骤，不是可选项（原因见 2.4：CA 会把签发时的时钟写进证书，时间不对会埋下延迟爆雷）。这台将来要当 PDC 模拟器、是全域的时间权威，所以让它直接跟外部 NTP 同步。管理员 CMD：

1
2
3
4

w32tm /config /manualpeerlist:"10.0.40.1,0x8" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /rediscover
w32tm /query /status

NTP 源填 10.0.40.1（OPNsense 在 SERVER 网段的接口，本身跑着 NTP），别填管理网的 10.0.10.1——理由和前面 DNS 转发器一样，管理网隔离会把 SERVER 网段过去的流量挡掉。/query /status 里 Source 应从 Local CMOS Clock 变成你填的源、Stratum 降到个位数，才算对齐。时间层级的完整收尾（PDC 对外、其余成员跟域层级）留到平台8 讲，这里先把 dc01 的时间钉准，给后面装 CA 铺路。

2.3 装 AD DS 角色、提升为新林新域

打开 Server Manager → Add roles and features，在 Server Roles 一步勾上 Active Directory Domain Services（会弹「Add features required」一并装上）。这一步我们暂时不用单独去勾 DNS Server 角色——升级为新林新域时，向导会自动把 AD 集成 DNS 一起装起来。装完角色后，Server Manager 右上角的旗标里会出现一条「Promote this server to a domain controller」，点它进提升向导。

提升向导的关键选项：

• Deployment Configuration：选 Add a new forest（添加新林），Root domain name 填 corp.yanxing.internal。
• Domain Controller Options：Forest / Domain functional level 都选 Windows Server 2025（全新林、没有旧 DC 要兼容，直接拉到最高）；勾选 DNS server（默认就勾着）；设 DSRM（目录服务还原模式）密码并记牢——这是日后 AD 出问题时进还原模式用的，和域管理员密码是两回事。
• Additional Options：确认 NetBIOS 域名 是 YANXING（向导一般会从 corp 自动取，注意核对成我们锁定的 YANXING，别让它默认成 CORP）。

点 Install，向导跑完会自动重启。重启后登录界面会变成显示域名 YANXING\Administrator，说明这台已经是域控了。AD 集成 DNS 也随之起来：打开 DNS Manager，你会看到正向查找区域里多了 corp.yanxing.internal，里面已经自动注册了一堆以下划线开头的 SRV 记录（_ldap、_kerberos 等），这些是域成员用来定位域控的「路标」。

2.4 启用 LDAPS（在 dc01 上装 AD CS 企业根 CA）

后面 vCenter 接 AD 推荐走 LDAPS（636 端口、SSL 加密），而 LDAPS 需要域控上有一张服务器证书。最省心、也最贴近生产做法的办法，是在 yx-dc01 上装一个轻量的 AD CS（Active Directory Certificate Services）企业根 CA：企业根 CA 装好后，域控会通过自动注册拿到一张可用于 LDAPS 的域控证书，636 端口随即可用，不用手工折腾证书申请。

在 Server Manager 里 Add roles and features 勾上 Active Directory Certificate Services，角色服务选 Certification Authority；装完后在通知旗标里点「Configure Active Directory Certificate Services」，CA 类型选 Enterprise → Root CA，其余走默认即可。配好后等域控自动注册到证书（或重启一次域控触发），LDAPS 就通了。

验证 636 是否在监听、证书是否就位，可以在 dc01 上用 ldp.exe（自带工具）连本机 636 端口，能成功绑定即说明 LDAPS 可用。

导出根 CA 证书备用（5.2 接 vCenter 要用）。 vCenter 信任的是签发链的根，所以导根 CA 证书而不是某台 DC 的证书——这样日后 DC 的 LDAPS 证书续期，vCenter 端不用重配。在 dc01 上管理员 CMD 一条命令导成 Base64：

1
2

certutil -ca.cert C:\yx-rootca.der
certutil -encode C:\yx-rootca.der C:\yx-rootca.cer

要点：格式必须是 Base64（PEM 文本，以 -----BEGIN CERTIFICATE----- 开头），不要 DER（vCenter 上传 DER 会报格式错，导完用记事本打开能看到 BEGIN CERTIFICATE 即对）；只导公钥证书、绝不导私钥。导完把 yx-rootca.cer 拷到操作 vSphere Client 的那台机器上（VLAN40 可达的话走网络共享 \\10.0.40.10\c$（记得在宿主机加路由），或干脆把这段 Base64 文本复制粘贴过去另存即可——证书公钥不是机密）。

3 DNS 整合：把 corp.yanxing.internal 的权威交给 AD

这是整篇里和现状衔接最关键、也最容易把 vCenter 搞挂的一步，单独成节慢慢讲。

现状：在 vCenter 篇里，我们是在 OPNsense 的 Unbound 上，给 yx-vc01 和三台 ESXi 主机配的正/反向解析（corp.yanxing.internal 这个后缀下的名字，当时由 Unbound 以 host override / 本地区域的形式临时充当权威）。现在 corp.yanxing.internal 成了一个真正的 AD 域，AD 集成 DNS 才是这个区域天然的权威持有者。所以要做一次「权威交接」。

我们采用的做法（方案 a）：让域控对 corp.yanxing.internal 做权威解析，对这个域之外的一切（公网、其他内网名字）由 DC 上配的转发器（forwarder）转给 OPNsense 在 SERVER 网段的接口 10.0.40.1 去解（不走管理网的 10.0.10.1，原因见下面步骤 3）；同时把原来在 Unbound 里的 yx-vc01、三台 ESXi 的 A/PTR 记录，在 AD DNS 里重新建出来，并把这些基础设施节点的 DNS 指向改到域控。交接完成后，内网名字由 AD DNS 统一解析，外网名字经 DC 转发器走 OPNsense 出去。

具体步骤：

1. 在 AD DNS 建反向查找区域。正向区域 corp.yanxing.internal 提升时已自动建好；反向区域要手动加。至少建两个：管理网段的 10.0.10.0/24（区域名 10.0.10.in-addr.arpa）和业务网段的 10.0.40.0/24（区域名 40.0.10.in-addr.arpa）。都建成 AD 集成区域，这样第二台 DC 起来后会自动复制一份。

2. 重建基础设施记录。在正向区域 corp.yanxing.internal 里，手动补上 yx-vc01 → 10.0.10.20、yx-esxi01 → 10.0.10.11、yx-esxi02 → 10.0.10.12、yx-esxi03 → 10.0.10.13 的 A 记录（建 A 记录时勾上「同时创建关联的 PTR 记录」，反向就一并有了）。yx-dc01 自己的 A/PTR 在提升时已经有了。

3. 在 DC 上配转发器。DNS Manager → 服务器节点右键 Properties → Forwarders，加上 10.0.40.1（OPNsense 在 SERVER 网段 VLAN40 上的接口地址）。这样 DC 解不出来的公网域名会转给 OPNsense，再由它递归或继续转发出去。注意这里别图省事写 10.0.10.1：网络篇已经做了管理网隔离，下游的 SERVER / CLIENT 网段主动访问 MGMT_NET 会被 block；DC 在 SERVER 网段，去找管理网的 10.0.10.1:53 很可能被你自己的规则拦下。用同网段的 10.0.40.1 既不绕路也不撞规则。前提是 OPNsense 的 Unbound 在 SERVER 接口上监听并允许该网段查询（默认监听 All 或已放行 SERVER 即可）。真要坚持用 10.0.10.1，就得在 SERVER 接口那条 block 规则上方补一条 SERVER_NET → FW_MGMT_IP UDP/TCP 53 pass 例外——不如直接用 10.0.40.1 干净。

4. 改各节点的 DNS 指向：

   • yx-dc01 自己的首选 DNS 从 127.0.0.1 改成指向另一台 DC、回环作备（等 dc02 起来后定为：首选 10.0.40.11、备用 127.0.0.1，这是双 DC 的推荐交叉指法，避免单台 DC 重启时自我解析卡住）。在 dc02 还没起来之前，dc01 可暂时维持 127.0.0.1。
   • yx-vc01、yx-esxi01/02/03 的 DNS 从原来的 10.0.10.1（OPNsense）改成指向域控。此刻 dc02 还没建，先只指 10.0.40.10 这一台；等下一节 dc02 提升完、AD DNS 区域复制好、10.0.40.11 的 53/636 都确认可用之后，再把 10.0.40.11 加为各节点的备用 DNS。别在这一步就把备用 DNS 指向一个还不存在的地址。

4 部署第二台域控 yx-dc02

一台域控是单点：它一挂，全公司认证和这套 AD DNS 全停。所以正经做法是至少两台域控，互为冗余——AD 数据库多主复制、DNS 区域各存一份、谁在线都能认证。

建 yx-dc02 的 VM 规格和 dc01 一样（2 vCPU / 4 GB / 60 GB / UEFI / YX-Server VLAN40）。装好系统、改名 yx-dc02、配静态网络：IP 10.0.40.11/24、网关 .1，首选 DNS 这次要指向已经在跑的 dc01（10.0.40.10）——因为它要先能找到现有域才能加进去。

提升之前，同样先确认 dc02 的时间是对的——和 dc01 一个道理：dc02 提升后也会自动注册一张用于 LDAPS 的域控证书，时钟不对又会埋 NotBefore 的雷。但 dc02 是额外域控、不是 PDC，别给它配 manualpeerlist 去指外部源；它提升入域后会自动跟域层级（即跟 dc01 这个 PDC）同步。所以这里只需保证它当前系统时间大致正确即可：若嵌套 VM 关机后时钟跑飞，先手动把时间设到与 dc01 一致，再提升。提升完成后用 w32tm /query /status 确认它的 Source 指向了域内的 dc01（而非 Local CMOS Clock）。

装 AD DS 角色后进提升向导，这次在 Deployment Configuration 选 Add a domain controller to an existing domain（向现有域添加域控），域填 corp.yanxing.internal，凭据用域管理员、填 UPN 格式 administrator@corp.yanxing.internal；Domain Controller Options 里保持勾选 DNS server（让它也成为 DNS 副本），设 DSRM 密码。装完重启。

重启后回到 dc01 / dc02 任一台，把双 DC 的 DNS 指向定为交叉互指 + 回环备用：dc01 首选 10.0.40.11、备用 127.0.0.1；dc02 首选 10.0.40.10、备用 127.0.0.1。AD 集成 DNS 区域会自动复制到 dc02，前面建的反向区域和手建的基础设施记录都会出现在 dc02 的 DNS Manager 里——这就是把 DNS 也做成了冗余。

dc02 起来后，还要补两件事，否则后面 vCenter 接入时可能踩坑：

• 确认 dc02 的 LDAPS 也通。dc01 装了企业根 CA 后域控会各自自动注册域控证书，但 dc02 若是在 CA 配好之前提升、或先注册了一张时间不对的证书，它的 636 可能虽在监听却没有可用证书——表现为连接建立后立刻 Connection reset by peer（TLS 握手被对端重置；这不是防火墙，防火墙是超时/拒绝）。在 dc02 上 certutil -pulse（必要时 gpupdate /force 后重启一次）触发重新注册，再用 ldp.exe 连 yx-dc02.corp.yanxing.internal:636（勾 SSL）验证能 bind。两台 DC 的 636 都必须可用——5.2 填了主备两个 URL，vCenter 探测时两台都会碰，dc02 没就绪会让整个身份源探测失败。
• 现在才把 10.0.40.11 加为各节点备用 DNS。确认 dc02 的 53/636 都可用后，回到 yx-vc01 和三台 ESXi，把备用 DNS 补成 10.0.40.11（首选仍 10.0.40.10）。至此基础设施节点才真正有了冗余的 DNS 解析。

5 把 vCenter 接入 AD（Active Directory over LDAPS）

域和 DNS 都稳了，现在把 vCenter 接进来。这里全程在 vSphere Client 里用 administrator@vsphere.local 操作。

5.1 准备一个查询账号和一个管理员组

在 dc01 的 Active Directory Users and Computers 里先建好这几样：

• 一个查询账号 svc-vcenter-ldap：长口令、口令永不过期、只需读取/浏览目录的权限（普通域用户默认就够）。vCenter 用它去 AD 查用户和组。切勿拿域管理员当查询账号——它的口令要存进 vCenter 配置，权限越小越好。
• 一个管理员组 grp-vsphere-admins：建成 Global / Security 组（单域环境 Global 足够；必须是 Security 组才能用于授权，Distribution 组不行）。
• 一个你自己的个人域账号，加进 grp-vsphere-admins，日常用它登 vCenter。别拿内置 administrator 当日常账号——它权限过大、日志也分不清是谁干的。这个个人账号不需要塞进 Domain Admins，它的 vSphere 权限来自下面 5.3 对组的授权。权限授组不授人：以后人员变动只在 AD 调组成员，vCenter 侧的授权一个字都不用改。

5.2 添加 AD over LDAP 身份源

路径：Administration → Single Sign On → Configuration → Identity Provider 标签页 → Identity Sources → ADD，类型选 Active Directory over LDAP server。各字段按下表填（UI 字段名保持英文原样）：

• Identity source name：corp.yanxing.internal（起个能认出来的名，一般就用域名）
• Base distinguished name for users：DC=corp,DC=yanxing,DC=internal
• Base distinguished name for groups：DC=corp,DC=yanxing,DC=internal
• Domain name：corp.yanxing.internal
• Domain alias：YANXING（NetBIOS 名）
• Username：查询账号，填 svc-vcenter-ldap@corp.yanxing.internal
• Password：该账号口令
• Connect to：实验里建议手填主/备两个 URL更可控：ldaps://yx-dc01.corp.yanxing.internal:636 和 ldaps://yx-dc02.corp.yanxing.internal:636。也可以选 Connect to any domain controller in the domain（靠 DNS SRV 找 DC），但用它之前要先确认 DNS SRV 记录和两台 DC 的 636 都没问题，否则 vCenter 可能随机命中尚不可用的那台。
• Certificates (for LDAPS)：Browse 选入前面 AD CS 根 CA 的证书（启用 LDAPS 时必填）

填完 Add。回到 Identity Sources 列表能看到 corp.yanxing.internal 出现，就说明身份源加成了。

5.3 把管理员组授予 vCenter 权限

身份源只是让 vCenter「认识」AD 里的人和组，但「认识」不等于「有权限」——权限是在 Global Permissions 里把某个角色（Role）绑到某个组上的那一刻才产生的；组名叫什么不影响权限，授了哪个角色才算数。到 Administration → Access Control → Global Permissions → ADD，Domain 选 corp.yanxing.internal，User/Group 里找到刚建的 grp-vsphere-admins，Role 给 Administrator，勾上 Propagate to children。

然后退出登录，用你那个个人域账号验证：登录页输入 UPN 格式 你的用户名@corp.yanxing.internal和域口令，能进 vSphere Client 且是管理员视图，这条就通了。

6 管理跳板机 yx-jump01

序章规划里还有一台 yx-jump01（管理跳板机，10.0.40.30），到这里正好顺势把它立起来——因为它和 AD、DNS、权限审计是一套逻辑。

先说它是什么、为什么这篇补。 跳板机（jump host，也叫堡垒机 bastion）是一台专门用于进入内网管理面的中转主机：运维人员不再从外部或宿主机直接访问内部资产，而是先登录到这台受控主机，再从它出发去管理 vCenter、ESXi、域控、TrueNAS 等组件。把它放在身份篇补，是因为它应该长在内网里、加入 corp.yanxing.internal 域、用域账号登录，并通过 AD DNS 解析内部主机名——这样从它出发，名称解析、账号审计、访问路径都能纳入同一套体系。

这也正好对照出我们前面一直在用的"土办法"：直接拿宿主机，也就是那台 Windows 笔记本裸连内部环境。宿主机游离在 AD 体系之外，所以一路上会遇到"解析不出 yx-vc01、访问 \\10.0.40.10\c$ 要在宿主加路由、打开 VAMI 只能用 IP"这些别扭。换成一台加了域的跳板机，这些绕路就少很多：它在内部 DNS 体系里，能用域账号登录，也能作为统一的运维入口。

但有一个跨网段的前提必须先开。 yx-jump01 放在 YX-Server（VLAN40 / 10.0.40.0/24）里，而网络篇已经做了管理网隔离，默认阻断 SERVER_NET → MGMT_NET。所以跳板机要管理 vCenter / ESXi，必须在 OPNsense 上单独给它开一条精确例外——这又是本系列反复出现的那类"反方向口子"（和 DNS 的 53、LDAPS 的 636、NTP 的 123 一样，都是下游网段主动访问管理网、方向与隔离规则相反，最容易漏）：

这条 JUMP_HOST → MGMT_NET 的 pass 规则必须放在原来的 SERVER_NET → MGMT_NET block 规则上方，否则会被 block 先命中而失效。端口按需最小放行（443 走 vSphere Client / VAMI / ESXi、5480 走 VAMI、902 走 ESXi 控制台、22 走 SSH），别图省事开 any——这样就形成"普通业务网主机进不了管理网，只有跳板机能作为受控入口"的姿态。

一个轻量部署示例。 在本实验内存吃紧的前提下，跳板机给最小配置即可；甚至可以平时关机，要集中运维时再开：

• 建一台小 VM yx-jump01：2 vCPU、4 GB 内存、UEFI、网络挂到 YX-Server（VLAN40）端口组；操作系统可用 Windows Server 评估版，复用前面的 ISO。这里以 Windows 为例，方便安装图形化管理工具。
• 静态网络：IP 10.0.40.30/24，网关 10.0.40.1，DNS 指向两台域控 10.0.40.10 / 10.0.40.11。
• 加入 corp.yanxing.internal 域：系统属性里改域，用域管理员凭据；凭据建议用 UPN 格式，例如 administrator@corp.yanxing.internal，避开 down-level 格式在未加域机器上偶发的定位问题。
• 安装日常运维工具：RSAT（Active Directory Users and Computers、DNS Manager 等）、浏览器、SSH 客户端，按需再装 PowerCLI。开好上面那条例外规则后，日常管理尽量从这台跳板机进入：浏览器里访问 https://yx-vc01.corp.yanxing.internal/ui、https://yx-vc01.corp.yanxing.internal:5480，或访问三台 ESXi 的 FQDN，而不是继续从宿主机到处用 IP 和静态路由绕进去。

7 验证与检查点

把这一篇该绿的都绿一遍再收工：

• 域账号登录：用 grp-vsphere-admins 里的域账号能登进 vCenter 且为管理员——这是本篇的主目标。
• DNS 正反向：在 yx-vc01 和三台 ESXi 上分别 nslookup 自己的 FQDN 和 IP，正向、反向都对得上；外网名字（如某公网域名）也能经 DC 转发器解析出去。
• 两台 DC 复制健康：在任一 DC 上跑 repadmin /replsummary（汇总无报错、无大 delta）、repadmin /showrepl（各方向 last success 时间新鲜），再跑一遍 dcdiag /v 看各项检查通过。两台 DC 的 DNS Manager 里 corp.yanxing.internal 区域内容一致，说明 AD 集成 DNS 复制正常。
• 集群面板照旧：vSAN / HA / DRS 仍然全绿，Skyline 没有新增红项（嵌套环境固有的 HCL / 监控类预期告警沿用前几篇的判断口径，核心数据面绿即可）。

结语：下一篇把时间对齐

身份立住了，还剩最后一块地基没夯实——时间。AD 域里，PDC 模拟器是整个域的时间权威，域成员都跟着它走；而 vSAN、HA 这些恰恰对时间同步很敏感（Skyline 里就有「主机与 VC 时间是否同步」这一项），时间一漂就会出问题。下一篇（也是本系列最后一篇）会把整套时间层级理顺到域控上，顺手收回当初在网络篇为 OPNsense 开的那条 NTP 放行规则，再补讲一直推迟到收尾才讲的 vLCM 镜像，最后对砚行物流这套从物理规划一路走到身份与时间的平台，做一次整体回顾和「实验 vs 生产」的总差距清单。

到上一篇为止，集群的网络已经成形，但存储还停在一个尴尬的临时状态：vCenter 那台 VCSA 还寄居在 yx-esxi01 的本地盘 esxi01-local 上，esxi02/esxi03 则压根没有任何 datastore——Summary 页那个 No datastores have been configured 的黄叹号一直挂着。集群想往上叠 HA、DRS、vMotion，第一道坎都是同一个：得有一块三台主机都能访问的共享存储。

这一篇就把这块共享存储立起来——不靠外置 SAN，而是用三台主机自己的本地盘聚成 vSAN；建好后顺手把还寄居在临时本地盘上的 VCSA 用 Storage vMotion 迁上 vSAN、回收那块 600 GB 临时盘，闭合上一篇 vCenter 留下的自举（bootstrap）。最后用一台 TrueNAS 做一节外置 iSCSI/NFS 的轻量对照，把「超融合」与「传统外置存储」两条路摆在一起看。

1 为什么是 vSAN：把本地盘聚成共享存储

集群要的共享存储，传统答案是另设一台外置存储（SAN/NAS），主机通过 iSCSI/FC/NFS 去挂。vSAN（VMware 的超融合存储，Hyper-Converged Infrastructure，HCI）换了个思路：把每台 ESXi 主机自己的本地盘聚合成一块横跨集群的分布式数据存储（vsanDatastore），不需要单独的存储设备。计算与存储跑在同一批主机上，这正是「超融合」的含义。

这也正好闭合上一篇的自举：vSAN 要 vCenter 来配，而 VCSA 先前只能临时落在 esxi01-local；现在 vCenter 已就位，我们把 vSAN 建起来，再把 VCSA 迁到 vSAN 这块有冗余的共享存储上，临时盘随之回收。

vSAN 的 OSA（原始存储架构，Original Storage Architecture）是这样组织磁盘的：每台主机贡献一个磁盘组（disk group）= 1 块缓存盘（cache，必须是闪存）+ 1～7 块容量盘（capacity）；vSAN 把各主机的磁盘组汇成一块 vsanDatastore；虚拟机的数据以对象（object）形式、按一条存储策略（含「允许的故障数」FTT）分布到不同主机上，从而获得冗余。

2 OSA 的磁盘画像：给每台主机加盘，并把盘标记为闪存

OSA 每台主机要有缓存盘和容量盘，而三台主机现在只有启动盘。先在 Workstation 里给 yx-esxi01/esxi02/esxi03 每台各加两块精简置备（thin）虚拟盘：

• 一块约 50 GB 作缓存盘；
• 一块约 150 GB 作容量盘。

精简置备意味着这些只是上限，宿主 NVMe 上的实际占用随写入增长，初期很小。yx-esxi01 上原有的 esxi01-local（600 GB，承载 VCSA）暂时保留，等 §5 迁走 VCSA 再回收；本步只是新增 vSAN 用盘，别动 esxi01-local。

加盘后开机，进每台主机。这里有 OSA 嵌套最经典的一个坑：

3 vSAN 网络：给每台主机建 vSAN VMkernel

vSAN 主机之间的数据同步走专用网络。上一篇已在 YX-vDS01 上建好 YX-vSAN（VLAN 30）端口组，这一步给三台主机各建一个启用 vSAN 服务的 VMkernel 适配器接上去。

逐台：主机 → Configure → VMkernel adapters → Add Networking → VMkernel Network Adapter → Select an existing network 选 YX-vSAN → 在 Enabled services 勾选 vSAN → IPv4 settings 用 static，按下表填址：

10.0.30.0/24 是第一篇定的无网关、不路由的纯二层专用段——vSAN 流量只在 VLAN 30 内东西向流动，不出网、也不跨段，所以不填网关。MTU 保持默认 1500。

4 在集群上启用 vSAN（OSA）并认领磁盘

盘和网络都备齐，回到集群开 vSAN。YX-Cluster01 → Configure → vSAN → Services → Configure vSAN，逐页走：

• 第 1 步 vSAN ESA：这一步是个 ESA 开关 + 预检。我们的嵌套环境过不了 ESA 预检（页面会黄条提示 your hardware compatibility or cluster configuration is not eligible for vSAN ESA，并标红 vSphere Lifecycle Manager (vLCM) configuration、Host physical memory compliance check 两项）——这属预期，不用去修。把 vSAN ESA 开关保持关闭，NEXT，向导自动走 OSA 路径。
• 第 2 步 Services：数据服务（去重压缩、加密等）本篇先不开，默认 NEXT。
• 第 3 步 Claim disks：给每台主机把那块 50 GB 闪存盘指派为 Cache tier、150 GB 闪存盘指派为 Capacity tier——每台形成一个磁盘组。核对顶部 Total Claimed 为三台共 6 块、Unclaimed 0 B。
• 第 4 步 Create fault domains：跳过（单站点，三台各为默认故障域）。
• 第 5 步 Review → Finish。

vSAN 启用后会自动生成一块 vsanDatastore，三台主机的磁盘组都并入其中。

启用后到 Cluster → Monitor → vSAN → Skyline Health 看健康。这里要先建立一个判断口径：vSAN 的健康项分两类——核心数据面（vSAN object health、vSAN daemon liveness、Time is synchronized across hosts and VC、Advanced vSAN configuration in sync、磁盘与网络等）必须绿；辅助 / 监控类（SCSI controller is VMware certified、Performance service status、vSAN Build Recommendation、vSAN cluster configuration consistency、Stats primary election 等）在嵌套环境下常黄常红，且多可一键修或静默，不挡存储功能。我们的「磁盘」「控制器」都是虚拟的、本就不在 HCL 上，所以只要核心数据面绿即可。其中 Stats primary election / Stats DB object 属 Performance Service，在拆组重建后尤其常见——RETEST一键修复、或干脆 Cluster → Configure → vSAN → Services → Performance Service 关再开重建统计对象，都能消，不消也不影响。

5 把 VCSA 迁上 vSAN，回收临时盘

vsanDatastore 一就绪，上一篇那条自举临时盘就能闭环了。把 VCSA 从 esxi01-local 在线迁到 vSAN。

迁移前先确认环境稳定：三台主机状态均为 Connected、vSAN Health 核心项为绿，且别在迁移期间同时做其它大规模配置变更——这是控制面（vCenter）给自己搬家，环境越静越好。

右键 yx-vc01 → Migrate → 选 Change storage only → 目标 datastore 选 vsanDatastore、存储策略用 vSAN Default Storage Policy → Finish。这是 Storage vMotion，VCSA 不中断、迁移期间 vCenter 照常可用。

迁完核对：yx-vc01 的 Summary / Datastores 应显示它已落在 vsanDatastore 上、esxi01-local 上不再有它的文件。确认无误后回收临时盘：

1. 先在 vCenter 里把 esxi01-local 这块 datastore 卸载并删除（此时它应是空的）。
2. 再到 Workstation，从 yx-esxi01 这台 VM 上移除那块 600 GB 虚拟盘，宿主 NVMe 上的占用随之释放。

6 外置存储对照：TrueNAS 的 iSCSI / NFS（可选）

vSAN 是「把存储融进主机」，与之相对的是传统的「外置共享存储」。这一节用一台 TrueNAS 简要演示后者，作对照、不展开成完整教程。

准备外置存储端。 部署一台 TrueNAS 虚拟机 yx-nas01（管理口在业务网 10.0.40.20，再给它一块网卡接 YX-Storage / VLAN 50 作存储数据路径），在其上各建一个 iSCSI Target（块存储） 和一个 NFS 共享（文件存储）。

主机端接入。 三台 ESXi 在 YX-Storage（VLAN 50，10.0.50.0/24，同样无网关纯二层）上各建一个 VMkernel 作存储数据路径。若做这节对照，YX-Storage 段的地址可照下表分配：

10.0.50.0/24 仍不设网关、不经 OPNsense 路由，只承载 ESXi 与 TrueNAS 之间的二层存储流量——这也闭合了第一篇「各 vmk 地址在用到的篇章再分配」的约定。建好 VMkernel 后：

• iSCSI：在主机 Configure → Storage Adapters 添加 Software iSCSI 适配器，填 TrueNAS 的 iSCSI 目标地址（10.0.50.20）、Rescan，再把发现的 LUN 格式化为 VMFS datastore。
• NFS：New Datastore → NFS，填 TrueNAS 的 NFS 服务器地址（10.0.50.20）与共享路径，挂为 NFS datastore。

三条路怎么选——这才是本节的重点：

7 验证与检查点

结语

到这里，砚行物流终于有了一块横跨集群、带冗余的共享存储：vSAN 把三台主机的本地盘聚成 vsanDatastore，VCSA 也从临时本地盘搬进了这块有 FTT=1 保护的存储，vCenter 篇欠下的自举就此还清；外置 iSCSI/NFS 的对照则把另一条存储路线摆在了一起。

共享存储一旦到位，集群真正的「高可用」与「调度」就有了根基。下一篇进入 HA 与 DRS：让承载 VCSA 的主机故障时 VCSA 能被自动重启、让负载在三台之间自动均衡与 vMotion——第四篇建好的 YX-vMotion（VLAN 20）专用网，也终于要在那时接上 VMkernel、派上用场。

上一篇把三台嵌套 ESXi 立了起来：评估模式、正反向解析、时间对齐、二层安全策略也提前放开。但此刻它们还是三台各自为政的主机——Host Client 一次只能管一台，集群、HA、DRS、vMotion、vSAN 这些本系列真正要的能力，一个都还谈不上。

这一篇就来补上控制面：部署 vCenter Server（以 VCSA 形式），把三台主机收编进一个数据中心与集群之下。这里有个前三篇没正面处理、却绕不过去的坎——VCSA 要落在哪块存储上：三台主机现在只有 32 GB 启动盘，而 vSAN 又排在更后面，于是出现一个典型的「先有鸡还是先有蛋」。本篇会把它讲透。

1 先认识 vCenter：为什么集群非它不可

把三台 ESXi 串成一个有高可用、能调度的集群，靠的不是主机之间「自发组队」，而是一个统一的控制面——vCenter Server。它持有整套环境的清单（inventory）、单点登录（SSO）、权限、任务与告警，也是 HA、DRS、vMotion、vSAN 这些集群级特性的唯一配置入口。没有它，三台主机就只是三台孤立的 hypervisor。这也正是上一篇坚持用评估模式、而非免费版的根本原因：免费版接不进 vCenter。

本篇落地三件事：部署 VCSA、创建一个数据中心（Datacenter）对象、创建一个集群（Cluster）对象并把三台主机纳入。集群的网络进阶（分布式交换机 vDS）、存储（vSAN）、以及 HA/DRS 的实际调优，分别留到后面第五、六、七篇——本篇先把「骨架」搭起来：数据中心与集群对象先建好，HA、DRS、vSAN 等功能开关暂不启用，等后续对应篇章再逐一打开。

2 部署前扫清三个前提：DNS、时间、存储

VCSA 的安装器对环境是「挑食」的，前提没备齐，它会在中途停下，且报错往往指不到根因。动手前先把下面三件事确认到位。

其一，正反向 DNS。 这是 VCSA 安装失败最常见的单一原因。安装器会校验 vCenter 自身的 FQDN 能否被正向（名字 → 地址）与反向（地址 → 名字）同时解析，缺一不可。yx-vc01（10.0.10.20）这条 A + PTR 记录，第二篇的前置工作里已经在 OPNsense 的 Unbound 上建好了。现在在宿主上复核一遍再开工：

1
2

nslookup yx-vc01.corp.yanxing.internal 10.0.10.1
nslookup 10.0.10.20 10.0.10.1

前者应只返回 10.0.10.20，后者应解析回 yx-vc01.corp.yanxing.internal。

其二，时间。 VCSA 与承载它的主机时钟必须一致，否则证书与服务启动都会出问题。yx-esxi01 的 NTP 在上一篇已指向 10.0.10.1 并同步；VCSA 自己稍后也会在安装阶段配上同一个 NTP 源。这一步无需额外动作，确认 esxi01 的时间正确即可。

其三，存储——本篇真正要解决的坎。 VCSA 即便是最小的 Tiny 规格，标称存储也要约 579 GB；而三台 ESXi 现在每台只有一块 32 GB 启动盘，装完系统分区后几乎不剩可用的 datastore，根本放不下 VCSA。本该承载它的共享存储 vSAN，又排在第六篇——在 vCenter 之后。这就是单机全虚拟环境特有的自举难题：vSAN 要靠 vCenter 来配，vCenter 又要先有地方落脚。

解法是先给 yx-esxi01 单独加一块**精简置备（thin）**的本地盘，起一个临时本地 datastore 把 VCSA 装上去；等第六篇 vSAN 建好，再用 Storage vMotion 把 VCSA 无中断迁到 vSAN 上、回收这块临时盘。

具体操作：在 Workstation 里给 yx-esxi01 这台虚拟机添加一块硬盘，容量 600 GB，模式选精简置备 / 不预分配（即不勾「立即分配所有磁盘空间」）。精简置备意味着这 600 GB 只是上限，宿主 NVMe 上的实际占用会随写入逐步增长，初期只有几十 GB，不会真吃掉 600 GB。

加盘后开机进 esxi01 的 Host Client，Storage → Datastores → New datastore → Create new VMFS datastore，选中刚加的那块约 600 GB 的设备，命名 esxi01-local，文件系统用默认的 VMFS 6、占满整盘，完成。

3 部署 VCSA（两阶段安装）

VCSA 的安装介质与上一篇 ESXi 同源——在 Broadcom 支持门户下载 vCenter Server 的安装 ISO（文件名形如 VMware-VCSA-all-8.0U3*-*.iso），同样需要你账号下的评估 / 个人实验室授权权益。vCenter 部署完成后会自动进入 60 天评估模式，本篇不贴任何 license。

本篇使用VMware-VCSA-all-8.0.3-25413364.iso

把 ISO 在 Windows 宿主上装载（双击挂为虚拟光驱），运行其中的 vcsa-ui-installer\win32\installer.exe，选 Install。安装分两个阶段：先把设备这台 VM 部署出来，再对它做初始化配置。

Stage 1：Deploy（部署设备）

逐页填写，关键项如下（其余保持默认）：

• End User License Agreement：接受。
• vCenter Server deployment target：填承载主机，即 yx-esxi01——ESXi host or vCenter Server name 填 10.0.10.11，HTTPS port 默认 443，User name 填 root、Password 填该主机 root 密码。出现证书指纹警告点 Yes 接受。
• Set up vCenter Server VM：VM name 填 yx-vc01，并为设备本身设置 root 密码（这是 VCSA 这台设备的操作系统密码，与 SSO 管理员密码是两回事）。
• Select deployment size：Deployment size 选 Tiny，Storage size 选 Default。
• Select datastore：选刚建的 esxi01-local，勾上 Enable Thin Disk Mode——这样 VCSA 的虚拟磁盘按精简置备，配合 Workstation 那块精简盘，实际占用降到最低。
• Configure network settings：
  • Network：选主机上的 VM Network（vSwitch0 上的默认 VM 端口组，位于管理网）。
  • IP version：IPv4；IP assignment：static。
  • FQDN：yx-vc01.corp.yanxing.internal
  • IP address：10.0.10.20
  • Subnet mask or prefix length：24
  • Default gateway：10.0.10.1
  • DNS servers：10.0.10.1
• Ready to complete stage 1：核对无误后 Finish，安装器开始把设备部署到 yx-esxi01。

Stage 2：Set up（初始化配置）

Stage 1 完成后接着进入 Stage 2（若中途关了窗口，浏览器访问 https://10.0.10.20:5480 也能续上）：

• vCenter Server configuration：
  • Time synchronization mode：选 Synchronize time with NTP servers，NTP servers 填 10.0.10.1。
• SSH access：选 Activated。一来实验室排错方便；二来它也是启用 vCenter HA（VCHA）的前提——界面会就此给出提示，正呼应 §2 生产环境对照里讲的 VCHA。本系列不配 VCHA，开着也无妨。
• SSO configuration：选 Create a new Single Sign-On domain：
  • Single Sign-On domain name：vsphere.local
  • Single Sign-On user name：administrator（即登录账号 administrator@vsphere.local）
  • 设置 SSO 管理员密码。
• Configure CEIP：客户体验改进计划，按需勾选。
• Ready to complete：Finish，设备开始初始化服务，耐心等其跑完。

完成后，优先用浏览器访问 https://yx-vc01.corp.yanxing.internal/ui，用 administrator@vsphere.local 登录 vSphere Client；https://10.0.10.20/ui 可作为 DNS 排错时的临时访问方式。养成用 FQDN 管 vCenter 的习惯，与前面强调的正反向解析、证书是一脉相承的。

4 组建数据中心与集群

登进 vSphere Client，此刻清单里还空着，只有一个 vCenter 根节点。按「数据中心 → 集群 → 加入主机」的顺序搭起来。

创建数据中心。 右键 vCenter 根节点 → New Datacenter，命名 YX-Datacenter。数据中心是清单里的顶层容器，把同属一处的主机、存储、网络归在一起。

创建集群。 右键 YX-Datacenter → New Cluster，命名 YX-Cluster01。vSphere 8 在这一步会列出几个开关：vSphere HA、vSphere DRS、vSAN，以及 Manage all hosts in the cluster with a single image（即 vLCM 镜像式生命周期管理）。本篇全部保持关闭：

• HA、DRS 留到第七篇专门配置与演示故障切换。
• vSAN 留到第六篇构建。
• 单一镜像（Manage all hosts in the cluster with a single image，即 vLCM image）这一项也先不开。需说明的是，它其实是 vSphere 8 新建集群的默认选项，也是 vSphere 9 起唯一的生命周期管理模式（旧的 baseline / VUM 已被移除）——本系列并非否定它，而是刻意延后到收尾篇统一讲：届时把集群转换为单一镜像、设定期望 ESXi 版本与组件，并演示合规检查与滚动修复。之所以延后，是因为滚动修复要想做得接近生产形态，至少需要共享存储、vMotion 网络与足够的主机资源；DRS 就位后，疏散与放置也更接近真实环境。当前 VCSA 还寄居在 yx-esxi01 的本地 datastore 上，若此时直接演示 remediation，既不优雅，也容易把生命周期管理与自举临时状态混在一起。

集群此刻只是个空壳，开关空着不影响后续逐一启用。

把三台主机加入集群。 右键 YX-Cluster01 → Add Hosts。在 New hosts 里逐台填入 FQDN 与凭据（也可一次性填三台）：

下一步会列出每台主机的证书指纹（Security Alert），确认无误后接受。再下一步 Host Summary 核对三台型号、版本一致，Finish。

主机会逐台加入集群，过程中可能出现重新连接、证书接受、vCenter Agent（vpxa / FDM）安装等任务，属正常。本次实验中，通过 Add Hosts 向导加入后，yx-esxi02、yx-esxi03 显示为 (Maintenance Mode)，而承载着 VCSA 的 yx-esxi01 因其上有开机 VM，未被置入维护模式。加入完成后，分别右键这两台 → Maintenance Mode → Exit Maintenance Mode 退出即可；此时其上无 VM、也未启用 HA / DRS / vSAN，退出无副作用。

若你的界面中主机加入后已经是 Connected 且不带 (Maintenance Mode)，则无需执行退出维护模式这一步。

5 验证与检查点

三台主机入列后，逐项验收：

收尾照例拍快照，但 vCenter 在这件事上有讲究：vSphere 集群的状态是 vCenter 与各主机协同维护的，单独给某一台 Workstation 虚拟机回退快照、而其余不动，容易让 vCenter 清单与主机实际状态对不上。实验室里稳妥的做法是——需要为这一阶段留底时，把承载 VCSA 的 yx-esxi01 连同 esxi02、esxi03 一起、在干净关机后再各拍一张快照（命名如 cluster-formed），尽量作为一组一起回退，而不是只回退其中一台。

结语

到这里，砚行物流的平台第一次有了「集中控制面」：vCenter 已就位，YX-Datacenter / YX-Cluster01 成形，三台主机收编入列。前几篇在 DNS、时间、二层安全策略、以及本篇这块临时本地盘上花的功夫，到此兑现成了一个能登、能管、可继续向上叠功能的集群。

下一篇进入网络进阶：把主机网络从各自的标准交换机（vSS）迁移到一台横跨集群的分布式交换机（vDS），并在那根一直挂着没用的中继干道（vmnic1 / VMnet3）上正式划出 VLAN——上一篇预留的第二块网卡，终于要上场了。