Synology SHA集群分区布局差异修复指南：从原因到验证的全流程

在维护Synology SHA（Synology High Availability，高可用）集群时，SHA分区布局差异是导致集群故障切换失败、数据同步中断的高频故障——当两台节点（主节点/备用节点）的硬盘分区结构不一致（如分区大小、分区类型、分区表格式不同）时，SHA集群会判定“节点硬件不兼容”，拒绝执行故障切换，甚至触发集群分裂，影响核心业务连续性。这种差异多源于“更换节点硬盘后未同步分区”“备用节点修复后分区配置错乱”“手动调整分区后未同步”等操作，很多管理员因不了解“分区布局一致性对SHA的重要性”及“官方修复流程”，误将故障归因于硬件故障，盲目更换设备却无法解决问题。本文基于Synology官方技术文档，从“差异原因→修复准备→分场景实操→验证保障”四个维度，提供覆盖DSM 6.x/7.x的完整修复方案，帮你安全恢复SHA集群的分区一致性，确保高可用功能正常运行。

一、先搞懂：SHA集群分区布局差异的核心认知

在开始修复前，需明确“分区布局差异的本质”“触发场景”及“对集群的影响”，避免因认知偏差导致操作失误：

1. 什么是SHA集群的“分区布局”？

SHA集群的分区布局是指两台节点中，用于存储“系统文件、集群配置、数据同步日志”的硬盘分区结构，包含3个核心组成部分，必须完全一致：

- 系统分区：存储DSM系统文件的分区（如`/dev/sda1`），大小固定（通常2GB），分区类型为ext4；

- 集群元数据分区：存储SHA集群配置（如节点通信地址、故障切换规则）的分区（如`/dev/sda2`），大小约512MB，仅SHA集群可见；

- 数据分区：挂载存储池的分区（如`/dev/md0`），大小由硬盘容量与RAID配置决定，分区格式需为Btrfs（SHA集群推荐格式）。

2. 分区布局差异的3大触发场景（官方统计）

| 触发场景                | 具体操作                                  | 差异表现（节点对比）                          |

|-------------------------|-------------------------------------------|-------------------------------------------|

| 1. 节点硬盘更换         | 主节点硬盘故障，更换新硬盘后未同步分区；备用节点单独更换硬盘 | 新硬盘分区大小与原硬盘不一致（如原系统分区2GB，新硬盘分区1GB） |

| 2. 节点修复后配置错乱   | 备用节点因系统崩溃重装DSM，未按主节点分区结构重建 | 分区表格式不同（主节点为GPT，备用节点为MBR）；元数据分区缺失 |

| 3. 手动调整分区配置     | 管理员在单个节点手动扩容/缩容分区，未同步到另一节点 | 数据分区大小不一致（主节点100GB，备用节点80GB）；分区挂载点不同 |

3. 分区布局差异对SHA集群的4大影响

- 故障切换失败：当主节点故障时，备用节点因分区不匹配，无法加载集群元数据，提示“分区布局不一致，无法接管服务”；

- 数据同步中断：集群元数据分区差异会导致节点间通信失败，`/var/log/sha.log`日志中频繁出现“metadata sync failed”错误；

- 集群状态异常：在DSM「High Availability」套件中，集群状态显示“警告（分区不匹配）”，同步进度停滞在0%或报错；

- 服务不可用：依赖SHA集群的业务（如文件共享、数据库服务）会因同步中断，出现“访问超时”或“数据读取错误”。

二、修复前必做：4项核心准备（避免数据丢失与集群崩溃）

SHA分区布局修复涉及分区调整，存在数据风险，必须提前完成以下准备，官方文档明确要求“未完成准备不得执行修复”：

1. 全量数据备份（兜底保障）

- 备份对象：主节点中所有共享文件夹、数据库（如MariaDB）、套件配置（如Synology Drive）；

- 备份工具：使用「Hyper Backup」套件，将数据备份到外接硬盘（如USB 3.0移动硬盘）或第三方存储（如AWS S3），避免备份到备用节点（因备用节点分区可能异常）；

- 备份验证：备份完成后，随机恢复1-2个关键文件（如财务报表.docx），确认数据完整性，避免备份损坏。

2. 确认集群当前状态（判断修复可行性）

1. 登录主节点DSM，打开「High Availability」套件，查看“集群状态”：

- 若显示“正常（警告：分区不匹配）”：可直接执行修复，集群未分裂；

- 若显示“分裂（节点无法通信）”：需先通过「修复集群」功能恢复节点通信（点击套件中「操作→修复集群」），待状态变为“正常（警告）”后再修复分区；

2. 记录节点信息：查看主/备用节点的IP地址、硬盘数量、存储池名称（如“storagepool1”），后续修复需用到。

3. 准备必要工具与权限

| 工具/权限                | 用途                                  | 准备方法                                                                 |

|--------------------------|---------------------------------------|--------------------------------------------------------------------------|

| SSH工具（PuTTY/FinalShell） | 执行命令行修复（DSM界面无法修复时）    | 从官网下载对应工具，确保支持SSH v2协议；主/备用节点需启用SSH（「控制面板→终端机」勾选“启用SSH”） |

| 管理员账号（admin或同组账号） | 执行修复操作（普通用户无权限）        | 确认账号属于“administrators”群组（「控制面板→用户账户」查看）；重置密码（若遗忘） |

| 分区检测工具（parted）   | 查看分区布局（SSH命令依赖）            | SHA节点默认预装parted工具，无需额外安装，通过`parted -v`命令验证是否可用 |

4. 暂停集群业务（减少修复干扰）

- 通知用户：提前1-2小时通知集群用户“即将进行维护，业务暂停30分钟”，避免修复过程中用户读写数据导致同步冲突；

- 暂停服务：在主节点「套件中心」中，停用依赖SHA的服务（如Synology Drive Server、Surveillance Station），待修复完成后重启。

三、分场景实操：SHA集群分区布局差异修复步骤

根据“是否能通过DSM界面访问集群”，分为“DSM界面修复”（推荐，适合新手）和“SSH命令修复”（适合界面无法操作场景），两种方法均为官方验证，安全有效：

场景1：通过DSM界面修复（DSM 7.x/6.x通用，推荐）

适用于集群状态正常（未分裂）、DSM界面可正常登录的情况，步骤如下：

Step 1：检查分区布局差异（定位问题）

1. 登录主节点DSM，打开「High Availability」套件，点击左侧「集群→节点」；

2. 选中备用节点，点击「操作→检查分区布局」，系统会自动对比主/备用节点的分区结构；

3. 查看对比结果：

- 若显示“分区大小不匹配（系统分区：主节点2GB/备用节点1GB）”：需调整备用节点系统分区大小；

- 若显示“分区类型不匹配（元数据分区：主节点GPT/备用节点MBR）”：需重建备用节点分区表。

Step 2：执行分区布局同步（核心修复）

1. 在「High Availability」套件中，点击「操作→同步分区布局」；

2. 在弹出窗口中，选择“以主节点分区布局为基准，同步到备用节点”（官方推荐，主节点数据更完整）；

3. 系统提示“同步会覆盖备用节点现有分区，可能导致数据丢失”，勾选「我已备份数据，确认执行」，点击「应用」；

4. 等待同步完成：同步进度在套件中实时显示，耗时取决于分区大小（1TB数据分区约需15-20分钟），期间不要关闭DSM界面或重启节点。

Step 3：验证同步结果

1. 同步完成后，再次点击「检查分区布局」，确认结果显示“主/备用节点分区布局一致”；

2. 查看「High Availability」集群状态，警告消失，显示“正常”；

3. 打开「存储管理器」，确认备用节点的存储池状态为“正常”，与主节点容量一致。

场景2：通过SSH命令修复（DSM界面无法访问时）

当DSM界面崩溃或集群处于“半可用”状态时，需通过SSH命令修复，步骤如下（以DSM 7.2为例）：

Step 1：连接主节点SSH并检查分区布局

1. 打开SSH工具（如PuTTY），输入主节点IP（如192.168.1.200），端口默认22，登录管理员账号；

2. 执行命令查看主节点分区布局（以第一块硬盘`sda`为例）：

```bash

parted /dev/sda print

```

记录关键信息：分区编号（Number）、大小（Size）、类型（Type）、文件系统（Filesystem），例如：

- Number 1：Size 2GB，Filesystem ext4（系统分区）；

- Number 2：Size 512MB，Filesystem ext4（元数据分区）；

- Number 3：Size 997.5GB，Filesystem btrfs（数据分区）。

Step 2：连接备用节点并对比分区

1. 通过SSH连接备用节点（IP如192.168.1.201），执行相同命令`parted /dev/sda print`；

2. 对比主/备用节点的分区信息，找出差异项（如备用节点Number 1 Size为1GB，与主节点2GB不一致）。

Step 3：执行分区同步命令（以调整系统分区为例）

1. 在备用节点SSH中，先卸载待调整的分区（如系统分区，需进入维护模式）：

```bash

synoha-maintenance --enable   启用备用节点维护模式

umount /dev/sda1   卸载系统分区

```

2. 调整分区大小（需与主节点一致，以2GB为例）：

```bash

parted /dev/sda resizepart 1   调整分区1大小

```

按提示输入新大小“2GB”，确认执行；

3. 重建文件系统（避免分区调整后文件系统损坏）：

```bash

mkfs.ext4 /dev/sda1   系统分区格式为ext4

```

4. 禁用维护模式，重启备用节点：

```bash

synoha-maintenance --disable

reboot

```

Step 4：验证分区一致性

1. 备用节点重启后，重新连接SSH，执行`parted /dev/sda print`；

2. 确认所有分区的大小、类型、文件系统与主节点完全一致；

3. 登录主节点DSM「High Availability」套件，查看集群状态变为“正常”，同步进度100%。

四、修复后必做：3步验证（确保SHA集群恢复正常）

修复完成后，需通过“基础验证→功能测试→压力测试”确认集群无隐患，避免后续故障：

1. 基础状态验证

- 集群状态：「High Availability」显示“正常”，无警告或错误；

- 分区信息：主/备用节点通过`parted`命令查看的分区布局完全一致；

- 日志检查：查看`/var/log/sha.log`，无“partition mismatch”“sync failed”错误。

2. 故障切换测试（核心功能验证）

1. 在主节点DSM「High Availability」中，点击「操作→手动切换主节点」；

2. 系统提示“切换会中断业务约1-2分钟”，点击「确认」；

3. 观察切换过程：备用节点变为“主节点”，原主节点变为“备用节点”，耗时≤2分钟；

4. 切换后验证：用客户端访问SHA集群的虚拟IP，确认文件共享、套件服务正常，数据无丢失。

3. 数据同步测试

1. 在新主节点（原备用节点）中，创建测试文件（如“SHA_test.txt”），存入共享文件夹；

2. 登录新备用节点（原主节点），打开相同共享文件夹，确认测试文件已同步；

3. 删除测试文件，确认两节点均同步删除，无数据残留或同步延迟。

五、高频问题FAQ：SHA分区布局修复的疑难解答

Q1：执行分区同步时提示“权限不足”，怎么办？

原因：1. 登录账号非“administrators”群组；2. 集群处于“分裂状态”，无法执行写操作；3. 备用节点未启用维护模式。 

解决：

1. 切换admin账号登录（或添加当前账号到“administrators”群组）；

2. 修复集群分裂：主节点执行`synoha-cluster --repair`，待状态变为“正常”后重试；

3. 备用节点启用维护模式（`synoha-maintenance --enable`），再执行同步命令。

Q2：同步分区后，备用节点存储池显示“损坏”，数据会丢失吗？

原因：分区调整时文件系统损坏，或同步后未重建存储池元数据。 

解决：

1. 若已备份数据：在备用节点「存储管理器」中，删除损坏的存储池，按主节点存储池配置重建（如RAID 5），再通过备份恢复数据；

2. 若未备份：执行存储池修复命令（Btrfs格式）：`btrfs check --repair /dev/md0`（`md0`为数据分区），修复后重启节点。

Q3：DSM 6.x与7.x修复步骤有差异吗？

核心步骤一致，仅界面位置与部分命令略有不同：

- DSM 6.x：「High Availability」套件中，“同步分区布局”入口在「设置→节点配置」；

- DSM 7.x：入口在「操作→同步分区布局」；

- 命令差异：DSM 6.x维护模式命令为`synoha-node --maintenance on`，DSM 7.x为`synoha-maintenance --enable`，其他命令一致。

Q4：修复后集群仍频繁提示“分区差异”，但手动检查分区一致，怎么办？

原因：集群元数据缓存未刷新，或隐藏分区（如引导分区）未同步。 

解决：

1. 刷新元数据缓存：主/备用节点均执行`synoha-metadata --refresh`；

2. 检查隐藏分区：执行`fdisk -l /dev/sda`，确认引导分区（如`/dev/sda0`）大小一致；

3. 重启整个集群：先重启备用节点，再重启主节点，重建集群连接。

六、预防措施：4个技巧避免SHA分区布局差异

1. 更换硬盘后必同步分区：为SHA节点更换硬盘时，先在主节点更换并重建分区，再将相同分区结构同步到备用节点，避免单独操作备用节点；

2. 禁用手动分区调整：通过DSM「控制面板→用户权限」，禁止普通管理员执行“分区管理”操作，仅保留1-2名核心管理员权限；

3. 定期检查分区一致性：每周通过「High Availability」套件执行“分区布局检查”，或通过脚本自动对比主/备用节点分区信息，发现差异及时处理；

4. 节点修复用克隆工具：备用节点系统崩溃后，用「Synology Assistant」的“系统克隆”功能，从主节点克隆系统与分区，避免手动重装导致差异。

总结：SHA分区布局差异修复的核心逻辑

修复Synology SHA集群分区布局差异的关键是“先备份→再定位→后同步”——备份确保数据安全，定位明确差异点，同步严格以主节点为基准（避免数据丢失）。无论是通过DSM界面还是SSH命令，核心目标都是让两台节点的分区结构（大小、类型、文件系统）完全一致，这是SHA集群实现故障切换与数据同步的基础。通过本文的步骤，企业IT管理员可高效解决分区布局差异问题，恢复SHA集群的高可用能力，保障核心业务的连续性与数据安全性。