Ceph多节点部署前要确认什么？Ubuntu香港服务器的网络与磁盘规划

很多 Ceph 部署失败，并不是因为命令写错，而是节点之间“看起来能通信”，实际却存在主机名不一致、私网未打通、磁盘混用、时间漂移或端口未放行等问题。对香港服务器 Ubuntu 系统实施 Ceph 分布式存储多节点部署方案时，部署前至少要确认五类条件：节点身份与系统版本、部署权限与软件源、管理网络与存储网络、OSD 磁盘布局，以及故障域和容量余量。

建议先不要急着初始化集群。应先完成节点清单、网络连通性、磁盘健康度和权限验证，再进行 Ceph 引导。下面的示例使用 3 个节点、3 个 MON、每台服务器配置独立 OSD 磁盘的场景，IP 地址和网卡名称均为示例，需要替换为实际环境。

一、先划清 Ceph 网络与磁盘规划边界

1. public_network 不等于公网

Ceph 中的 public_network 是客户端访问网络，也承载 MON、MGR、OSD 的一部分通信，不代表必须使用互联网公网地址。

常见网络划分如下：

如果香港服务器只有一张网卡，也可以让 public_network 和 cluster_network 共用同一网段，但复制和恢复流量会与客户端读写争用带宽。对于写入量较高、恢复时间要求较严格的环境，最好使用独立私网或独立 VLAN。

在云服务器环境中，不要仅凭公网 IP 之间可以互相 ping 就判断网络满足 Ceph 要求。需要确认：

• 节点之间是否具备稳定的私网地址；
• 私网是否允许双向 TCP 通信；
• 云平台安全组、网络 ACL 和服务器本机防火墙是否同时放行；
• MTU 是否在整条路径上保持一致；
• 节点间是否存在丢包、突发延迟或带宽限制；
• 香港服务器所在网络是否能访问所选 Ubuntu 软件源或容器镜像仓库。

2. Ceph 不是两台服务器之间的同步盘

Ceph 的数据可靠性由 MON 仲裁、OSD 副本和 CRUSH 故障域共同决定。

生产环境通常至少准备：

• 3 台 MON 所在节点，形成奇数仲裁；
• 3 台或以上 OSD 主机；
• 每台 OSD 主机使用独立数据盘；
• CRUSH 故障域设置为 host，避免同一主机上的多个副本被当作独立故障域；
• 为恢复、回填、扩容和维护预留容量。

两台服务器也可以构建测试集群，但无法同时获得理想的仲裁冗余和主机级副本保护。若副本数为 3，至少需要 3 个可用的主机故障域；若只有 2 台主机，强行使用副本数 3 通常不符合预期。

还要区分 Ceph 的副本和备份。副本主要解决磁盘、OSD 或主机故障下的在线可用性，不能替代异地备份、历史版本和误删除恢复。

二、部署前确认节点身份、Ubuntu 与权限

1. 统一主机名和地址解析

每台服务器都应有唯一、稳定的主机名。集群初始化后再修改主机名，可能导致编排、证书、SSH 主机记录或监控关系出现问题，因此应在部署前完成。

在每个节点执行：

hostnamectl
hostname -f
ip -br addr
ip route
getent hosts node-a node-b node-c

如果使用内部 DNS，应确保正向解析稳定；如果没有可用 DNS，可以在所有节点维护一致的 /etc/hosts。示例：

10.10.20.11 node-a
10.10.20.12 node-b
10.10.20.13 node-c

写入前先备份文件：

sudo cp -a /etc/hosts /etc/hosts.bak.$(date +%F-%H%M%S)

然后验证：

for host in node-a node-b node-c; do
    getent hosts "$host"
done

验证结果应满足：

• 每个主机名只对应预期地址；
• 所有节点对同一主机名解析结果一致；
• hostname -f 不返回错误或临时云主机名；
• 节点重启后主机名仍保持不变。

2. 确认 Ubuntu 版本、内核和时间同步

Ceph 版本与 Ubuntu 版本存在兼容关系，不要在不同发行版或不同大版本上直接混装。先记录系统信息：

cat /etc/os-release
uname -a
dpkg --print-architecture
systemctl is-system-running

然后确认时间同步：

timedatectl status
timedatectl show -p NTPSynchronized --value

如果使用 Chrony，还可以执行：

chronyc tracking
chronyc sources -v

MON 选举、证书校验、日志排序和故障判断都依赖相对准确的时间。若某节点时间持续偏移，应先处理 NTP 或 Chrony 配置，不要把时间同步问题留到集群初始化之后。

还应检查内存、磁盘空间、交换分区和系统负载：

free -h
df -hT
swapon --show
uptime

Ceph MON、MGR、OSD 和容器运行时都会占用内存。不要只按照数据盘容量采购服务器，还要为系统、守护进程、缓存和恢复任务保留内存余量。

3. 确认部署方式和软件源

Ceph 可以通过发行版软件包、cephadm 编排或其他自动化方式部署。实施前必须先冻结以下变量：

• 目标 Ceph 大版本；
• Ubuntu 大版本；
• 使用 APT 软件包还是容器镜像；
• 使用哪一个软件源或内部镜像；
• 是否允许节点访问外部仓库；
• 是否需要提前缓存软件包和镜像。

在使用 cephadm 时，检查工具和容器运行时：

command -v cephadm
cephadm version

podman --version 2>/dev/null || true
docker --version 2>/dev/null || true

检查 APT 软件源和候选版本：

apt-cache policy cephadm ceph-common

这里不应把不同大版本的软件包混在一起安装。若某个节点可以更新，另一个节点无法访问软件源，部署前应先解决软件源、DNS、出口防火墙或内部镜像问题。

4. 确认 SSH 和 sudo 权限

cephadm 通常需要从引导节点通过 SSH 管理其他节点。部署账号应满足目标部署方式要求，例如使用 root，或使用具备无密码 sudo 权限的专用账号。

检查本机 sudo 是否能够非交互执行：

sudo -n true
echo $?

从引导节点测试到其他节点：

ssh -o BatchMode=yes -o ConnectTimeout=5 deploy@node-b 'sudo -n true'
ssh -o BatchMode=yes -o ConnectTimeout=5 deploy@node-c 'sudo -n true'

返回值为 0 才表示 SSH 和 sudo 基本满足自动化要求。若命令提示输入密码，自动化部署通常会在中途失败。

建议使用专用部署账号和专用 SSH 密钥，不要为了省事把所有服务器永久开放密码登录或把 SSH 暴露给任意来源。修改 SSH 配置前应保留当前会话，并准备云控制台或带外登录方式，避免新配置导致远程失联。

三、检查 Ubuntu 香港服务器的网络路径

1. 先确认路由和网卡对应关系

查看网卡、地址和路由：

ip -br link
ip -br addr
ip route

重点确认：

• 管理地址、Ceph public 地址和 cluster 地址没有填反；
• cluster 网卡没有错误地配置默认网关；
• 默认路由只指向应该承担外网或管理出口的网卡；
• 节点之间访问时使用的是私网地址，而不是公网地址；
• 网卡名称在重启后不会变化。

如果需要调整 Ubuntu Netplan，先备份原配置：

sudo cp -a /etc/netplan /etc/netplan.bak.$(date +%F-%H%M%S)

一个双网卡的概念示例：

network:
  version: 2
  ethernets:
    ens3:
      addresses:
        - 10.10.10.11/24
      routes:
        - to: default
          via: 10.10.10.1
      nameservers:
        addresses:
          - 10.10.10.1
    ens4:
      addresses:
        - 10.10.30.11/24

ens3、ens4、网关和地址只是示例。云服务器的网卡名、网关和路由由实际网络环境决定，不能直接复制到生产主机。

远程修改网络时，优先使用：

sudo netplan try

确认新配置后再正式应用。若未在规定时间内确认，Netplan 通常会自动回退。不要在没有控制台、备用 SSH 会话或带外访问的情况下直接覆盖远程服务器的唯一网络配置。

2. 验证节点之间的延迟、丢包和 MTU

从每个节点向其他节点测试 Ceph public 和 cluster 地址：

ping -c 20 -I 10.10.20.11 10.10.20.12
ping -c 20 -I 10.10.20.11 10.10.20.13

如果测试 cluster 网络：

ping -c 20 -I 10.10.30.11 10.10.30.12
ping -c 20 -I 10.10.30.11 10.10.30.13

测试结果主要看三点：

• 是否存在持续丢包；
• RTT 是否突然升高或抖动明显；
• 不同节点之间是否存在显著不对称。

延迟没有一个适用于所有业务的固定合格值。小规模同一私网测试中，若出现持续丢包、周期性超时或明显抖动，应先处理网络；即使平均延迟不高，恢复和回填期间的尾延迟也可能影响客户端写入。

使用 tracepath 检查路径和 MTU：

tracepath -n 10.10.30.12
tracepath -n 10.10.30.13

常规 MTU 为 1500 时，可以进行不分片测试：

ping -M do -s 1472 -c 4 10.10.30.12

IPv4 报文的 1472 字节数据加上 20 字节 IP 头和 8 字节 ICMP 头，正好对应 1500 字节 MTU。若环境计划使用 Jumbo Frame，则必须保证云网络、虚拟交换、网卡和所有中间设备的 MTU 一致。只修改服务器本地 MTU，而不修改路径上的其他部分，容易造成大包丢失或连接异常。

3. 验证实际带宽，而不是只看网卡标称速率

在一台节点的 cluster 地址监听：

iperf3 -s -B 10.10.30.11

在另一台节点发起测试：

iperf3 -c 10.10.30.11 -B 10.10.30.12 -P 4 -t 30
iperf3 -c 10.10.30.11 -B 10.10.30.12 -P 4 -t 30 -R

建议对 node-a、node-b、node-c 做两两测试，并分别验证正向和反向流量。-P 4 用于观察多连接时的吞吐，不代表 Ceph 的最终性能。

测试时不要只看带宽数字，还要记录：

• 单连接与多连接差异；
• 正向和反向是否明显不对称；
• 测试过程中是否出现重传；
• 是否会影响线上业务；
• 多节点同时恢复时是否有足够余量。

如果只有公网网络可用，不建议直接把 MON、OSD 和复制流量暴露在公网地址上。公网地址应尽量只用于管理或受控的客户端访问，节点间复制优先使用隔离的私网。

4. 核对防火墙和 Ceph 端口范围

常见端口用途如下：

OSD 动态端口范围可能因 Ceph 版本和配置而变化。不要把表中的示例范围直接开放到公网，应以目标版本和实际配置为准。集群建立后可检查相关配置：

ceph config get osd ms_bind_port_min
ceph config get osd ms_bind_port_max

如果使用 UFW，先查看现状：

sudo ufw status verbose
sudo ss -lntp

修改防火墙前备份规则，并确认已通过控制台或备用会话保留回滚通道：

sudo cp -a /etc/ufw /etc/ufw.bak.$(date +%F-%H%M%S)

放行规则应限制到 Ceph 私网 CIDR，而不是使用 0.0.0.0/0。如果防火墙策略较复杂，也应同步检查云平台安全组和 ACL，因为本机放行并不能绕过云平台的上游拦截。

四、检查 OSD 磁盘、BlueStore 与容量余量

1. 先区分系统盘、缓存盘和 OSD 数据盘

在每台节点执行：

lsblk -e7 -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt
sudo blkid

建议形成类似下面的磁盘清单：

不要根据设备名猜测磁盘身份。云环境中设备名可能因重启、挂载方式或控制器变化而改变，应结合序列号、容量、模型和云平台磁盘 ID 核对。

对于 BlueStore，常见规划是：

• 系统盘只承载 Ubuntu、容器、日志和管理组件；
• 每块数据盘作为独立 OSD；
• HDD OSD 的 RocksDB/WAL 可考虑放到独立 SSD 或 NVMe；
• SSD/NVMe 作为数据盘时，应检查写入寿命和持续写入能力；
• 不要把同一个物理故障域误拆成多个“独立可靠”设备。

是否使用 DB/WAL 独立盘，需要结合随机写、元数据量、SSD 耐久度和故障替换策略判断。把所有 OSD 的 DB/WAL 放在一块没有冗余的 SSD 上，可能形成新的共享故障点。

2. 不要在未确认数据安全前执行擦除

以下操作可能破坏磁盘上的文件系统或已有数据：

wipefs
ceph-volume lvm zap
mkfs
分区表重建

在执行任何擦除或初始化前，必须确认：

• 设备不是系统盘；
• 设备没有挂载业务数据；
• 没有 LVM、RAID、ZFS 或其他上层卷在使用；
• 已完成必要备份；
• 已记录设备序列号；
• 变更范围只包含计划加入 Ceph 的空盘。

若设备用途不明确，应停止操作，先执行只读检查：

lsblk -f
sudo pvs
sudo vgs
sudo lvs
sudo mdadm --detail --scan

不要用“清空所有磁盘”类脚本代替逐盘确认。新集群初始化失败时，优先保留现场和日志，不要立即对所有节点执行 zap 或重新分区。

3. 计算原始容量、可用容量和恢复余量

容量规划不能直接把所有磁盘容量相加。可以先使用以下估算：

可用名义容量 ≈ 原始容量 ÷ 副本数

例如，3 台节点各有 4 块 3.84 TB 数据盘：

• 原始容量：3 × 4 × 3.84 TB = 46.08 TB；
• 副本数为 3 时，名义容量约为：46.08 ÷ 3 = 15.36 TB；
• 如果为恢复、回填、BlueStore 元数据和近满阈值预留约 20%，日常可规划容量约为：15.36 × 0.8 = 12.288 TB。

这个数值仍不是最终业务容量。实际结果还会受以下因素影响：

• 副本数和 min_size；
• CRUSH 故障域；
• BlueStore 元数据；
• 快照和克隆；
• RBD、CephFS 或对象接口的使用方式；
• nearfull 和 backfillfull 阈值；
• 节点维护时是否需要容纳降级副本；
• OSD 磁盘容量是否完全一致。

如果业务预计长期使用超过名义容量的七八成，应提前规划扩容，而不是等到 HEALTH_WARN 或 HEALTH_ERR 后再加盘。恢复和回填本身会消耗网络、磁盘 I/O 和 CPU，因此“容量刚好够用”并不等于“集群可以安全运行”。

4. 检查磁盘健康度和 I/O 基线

SATA/SAS 磁盘可以使用：

sudo smartctl -a /dev/sdb

NVMe 设备可以使用：

sudo nvme list
sudo nvme smart-log /dev/nvme0

检查内核是否记录了 I/O 错误：

dmesg -T | egrep -i 'error|fail|timeout|reset|nvme|scsi'

已在使用的业务盘不要直接进行压力测试。对空闲盘做基准测试时，应在维护窗口进行，并使用临时文件系统或专门测试文件，不要把裸设备作为 fio 目标。测试后还应确认测试文件和临时挂载没有被误纳入 OSD 规划。

实际判断时，随机读写延迟、持续写入稳定性和异常重置比单次峰值 IOPS 更有参考价值。云硬盘还要确认是否存在突发 IOPS、吞吐封顶或共享存储底层资源争用。

五、把网络和磁盘规划落实到 Ceph 配置

1. 配置 public 与 cluster 网段

如果使用双网络，规划可以表达为：

[global]
public_network = 10.10.20.0/24
cluster_network = 10.10.30.0/24

这段配置说明：

• 客户端和 MON 等公共通信使用 10.10.20.0/24；
• OSD 复制、心跳、恢复和回填使用 10.10.30.0/24；
• 两个网段都必须在所有相关节点可达；
• 网络接口、路由和防火墙必须与配置保持一致。

如果没有独立 cluster 网络，应只规划一个稳定的 Ceph 网络，不要填写一个实际上无法通信的 cluster_network。错误的网段配置可能让 OSD 互相发现失败，表现为集群长时间处于降级或不稳定状态。

配置副本数时，应先确定故障模型：

不要在没有容量和故障模型评估的情况下，直接修改全局 osd_pool_default_size、osd_pool_default_min_size 或恢复并发参数。不同类型的池可能需要不同的副本和恢复策略，应优先按业务池单独设计。

2. 预先建立部署检查清单

可以将以下结果保存为部署记录：

{
    echo "=== identity ==="
    hostnamectl
    hostname -f
    getent hosts node-a node-b node-c

    echo "=== system ==="
    cat /etc/os-release
    uname -r
    timedatectl show -p NTPSynchronized --value

    echo "=== network ==="
    ip -br addr
    ip route
    ss -lntp

    echo "=== storage ==="
    lsblk -e7 -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,MOUNTPOINTS
    df -hT

    echo "=== permission ==="
    sudo -n true && echo "sudo: ok" || echo "sudo: failed"
} | tee preflight-$(hostname)-$(date +%F-%H%M%S).log

这段命令只进行信息采集，不会初始化磁盘或修改网络。各节点的日志应统一收集，重点对比主机名、Ubuntu 版本、网卡地址、时间同步和磁盘序列号。

六、部署后的成功验证

1. 验证集群状态和主机编排

完成引导和 OSD 部署后，先查看整体状态：

ceph -s
ceph health detail
ceph osd tree
ceph df

如果使用 cephadm，再查看：

ceph orch host ls
ceph orch ps
ceph orch device ls

一个基本可接受的结果应包括：

• 所有预期节点都出现在编排列表中；
• MON 形成预期数量的 quorum；
• 所有计划加入的 OSD 状态为 up 且为 in；
• CRUSH 树中的主机层级符合实际故障域；
• 没有长期存在的 HEALTH_ERR；
• ceph df 中的池容量与副本规划一致；
• 没有设备被错误识别为系统盘或已用磁盘。

刚部署完成时可能因池、监控或服务尚未完全创建而出现短暂告警。判断时应结合 ceph health detail 逐条确认，不要只看 ceph -s 的一行状态。

2. 验证读写路径和恢复能力

在专用测试池中完成最小读写验证：

1. 创建或使用专门的测试池；
2. 写入一个已知内容的对象；
3. 读取对象并校验内容；
4. 删除测试对象；
5. 观察 ceph -s、OSD 日志和客户端错误；
6. 确认测试池不会误用生产容量。

不要直接对生产池执行删除池、批量清理或破坏性测试。若需要验证 OSD 故障恢复，应先确认剩余容量和副本数量足够，并在维护窗口内按演练流程执行。模拟故障前必须记录原始状态，避免因为恢复流量过大影响业务。

3. 网络与磁盘验证的判断边界

可以按照以下结果判断是否进入正式部署：

七、失败处理与回滚边界

1. 网络配置失败

如果 Netplan 修改后 SSH 中断，应通过云控制台或带外方式进入服务器，使用已备份的配置恢复。远程环境优先使用 netplan try，不要直接覆盖唯一可用链路。

恢复前先确认：

sudo ls -ld /etc/netplan*
sudo ip -br addr
sudo ip route

确认原配置无误后再恢复，并重新验证默认路由和私网路由。不要通过关闭全部防火墙来“验证网络”，这样可能掩盖安全组、路由或地址配置问题。

2. 端口放行失败

如果节点可以 ping，但 MON、OSD 仍无法建立连接，应按以下顺序检查：

1. 目标地址是否为正确的 Ceph 私网地址；
2. ss -lntp 是否有服务监听；
3. 云安全组是否允许对应端口；
4. 本机 UFW 或其他防火墙是否阻断；
5. Ceph 配置中的端口范围是否与防火墙规则一致。

回滚时只删除本次添加的规则，保留原有管理访问规则。不要直接执行“允许全部端口”或“关闭防火墙”作为长期方案。

3. 磁盘识别错误或初始化中断

如果发现设备序列号、挂载点或 OSD 映射错误，应立即停止后续初始化，保留日志和当前设备状态。不要继续执行 wipefs、ceph-volume lvm zap 或重新格式化。

已经加入生产集群的 OSD，不能简单拔盘后重建。是否可以安全下线，取决于副本状态、剩余容量、池的 min_size 和当前恢复进度。没有容量验证前，不要随意执行 osd out。

4. 部分节点引导失败

新建且没有业务数据的测试集群，可以按照目标 Ceph 版本的官方清理流程撤销初始化；生产集群则应优先修复网络、权限或软件版本，不要因为某个节点加入失败就销毁整个集群。

回滚的基本原则是：

• 未写入业务数据前，可以清理引导状态；
• 已存在业务数据后，优先保留 MON、OSD 和编排信息；
• 不执行未经确认的全局删除或池删除；
• 任何 OSD 清理都必须先确认副本健康、剩余容量和备份状态；
• 记录失败节点、命令、日志和时间，便于重新执行时避免重复破坏。

适用限制

这套检查方式适合在 Ubuntu 香港服务器上部署常规 Ceph RBD、CephFS 或对象存储集群前使用，尤其适合具备私网、独立数据盘和自动化 SSH 权限的多节点环境。

以下情况不建议直接进入正式部署：

• 只有两台服务器，却要求主机级高可用；
• 所有节点只能通过公网互通；
• 没有独立或稳定的私网；
• 系统盘和业务盘无法明确区分；
• 计划使用的磁盘已有未知数据；
• 节点 Ubuntu 版本、Ceph 大版本或软件源不一致；
• 复制网络没有带宽余量；
• 没有备份、控制台或带外回滚入口。

当主机身份、时间同步、私网端口、MTU、磁盘序列号和副本容量都通过验证，并且 ceph -s、ceph osd tree、ceph orch host ls 与实际规划一致时，才适合进入业务池创建和应用接入阶段。只要其中一项仍然依赖猜测，继续部署通常会把问题从“可修正的前置配置”变成“需要数据迁移的集群故障”。