📚 课程目录第4章 HPE Alletra复制软件栈

4. HPE Alletra复制软件栈

HPE Alletra 的异地复制与灾难恢复能力，并不是由单一功能完成的，而是由一组协同工作的软件组件构成。理解这些组件的分工与调用关系，是后续设计复制策略、规划站点拓扑和制定切换流程的基础。本节围绕三个核心组件展开：Remote Copy 负责跨阵列的数据复制，Peer Persistence 负责主机侧的透明故障切换，三站点复制 则在两者之上提供更高等级的容灾拓扑。

一、Remote Copy：数据复制的引擎

Remote Copy 是 Alletra 存储阵列之间进行数据复制的底层机制。它的基本单位是复制组（Remote Copy Group, RCG），一个 RCG 包含一组需要保持一致的卷（Volume），并绑定源阵列与目标阵列之间的复制链路。RCG 是原子性管理单元：组内所有卷要么一起同步，要么一起切换，从而保证应用数据的一致性。

Remote Copy 支持两种主要模式：

同步复制（Synchronous）：主机写请求必须同时写入主站点和目标站点，两个站点都确认后才向主机返回成功。RPO 为 0，但主机写延迟受站点间 RTT 影响，通常要求链路 RTT 在数毫秒以内。
异步复制（Asynchronous）：主机写先落到主站点，再按周期批量传输到目标站点。RPO 取决于复制周期与链路带宽，适合距离较远、RTT 较大的场景。

在 Alletra 中，Remote Copy 通过 remote-copy 命令族或管理界面进行配置。一个典型的同步复制组创建过程如下（示例参数，非实测结果）：

# 创建远程复制组，指定主站点与目标站点
create remotecopy group RCG_APP01 \
    primary-array Alletra-Primary \
    target-array Alletra-Secondary \
    mode sync

# 将应用卷加入复制组
add volumeto remotecopy group RCG_APP01 volume V_APP01
add volumeto remotecopy group RCG_APP01 volume V_APP02

# 启动复制并查看状态
start remotecopy group RCG_APP01
show remotecopy group RCG_APP01 detail

执行后应重点观察 Status 字段是否为 Started、SyncStatus 是否为 InSync，以及 Lag 是否接近 0。若 SyncStatus 长期停留在 Syncing，通常意味着链路带宽不足或目标站点写入压力过大。

二、Peer Persistence：主机侧的透明切换

Remote Copy 解决了数据层面的复制，但主机如何感知故障、如何切换路径，需要 Peer Persistence 来完成。Peer Persistence 基于 ALUA（Asymmetric Logical Unit Access）与 SCSI-3 PR（Persistent Reservation）机制，让主机通过多路径软件同时看到主站点和目标站点的卷，但只有主站点路径处于 Active/Optimized 状态。

当主站点发生故障时，Peer Persistence 会触发透明故障切换（Transparent Failover）：目标站点卷被提升为 Active/Optimized，主机多路径软件自动将 I/O 切换到目标站点路径，应用无需重启，也无需修改挂载点。这一过程对上层数据库或虚拟化平台是透明的。

Peer Persistence 的关键配置点包括：

主机必须安装支持 ALUA 的多路径软件（如 HPE Multipath、Native MPIO 等）。
复制组必须配置为 Peer Persistence 模式，并启用 auto-failover。
两个站点的卷必须具有相同的 LUN 标识与容量，否则主机无法识别为同一设备。

需要特别注意的是，Peer Persistence 的自动切换依赖仲裁机制。在双站点直连场景中，若站点间链路中断，可能出现“双主”风险。因此 Alletra 通常引入仲裁见证（Quorum Witness），由第三方站点或仲裁设备决定哪一侧保留主角色。

三、三站点复制：更高等级的容灾拓扑

三站点复制是在 Remote Copy 与 Peer Persistence 基础上扩展出的拓扑，通常采用同步 + 异步的组合：主站点与同城站点之间做同步复制，保证 RPO=0；主站点与异地站点之间做异步复制，提供更远距离的容灾能力。三站点拓扑中，Peer Persistence 可以覆盖同城站点，实现同城透明切换；异地站点则作为异步灾备目标。

三站点复制的核心价值在于同时满足两类需求：同城站点应对单阵列故障，异地站点应对区域级灾难。但它对链路、仲裁和复制组配置的复杂度也显著提高，需要明确每个站点的角色（Primary、Secondary、Tertiary）以及切换优先级。

四、组件之间的调用关系与配置要点

从实现角度看，三个组件的关系可以概括为：Remote Copy 负责“数据怎么走”，Peer Persistence 负责“主机怎么切”，三站点复制负责“拓扑怎么摆”。在 Alletra 中配置时，通常先建立 Remote Copy 组并确认同步状态，再启用 Peer Persistence 并验证主机多路径识别，最后根据容灾等级决定是否扩展为三站点。

一个常见的配置顺序如下（示例）：

确认主站点与目标站点之间的复制链路已建立，show remotecopy link 显示 Up。
创建 Remote Copy 组，加入卷，启动复制，确认 InSync。
将复制组模式改为 Peer Persistence，启用 auto-failover。
在主机侧重新扫描磁盘，确认多路径软件同时看到两个站点的路径。
若需三站点，增加异地异步复制组，并配置仲裁见证。

提示：Peer Persistence 的透明切换依赖主机多路径软件的正确配置。若主机只识别到单站点路径，自动切换将无法生效。建议在正式上线前，通过手动触发一次计划内切换（如 failover remotecopy group）验证主机侧路径切换是否正常。

注意：三站点复制中，仲裁见证的可用性直接影响自动切换的决策。若仲裁设备不可达，系统可能进入“需要人工确认”的状态，此时不应盲目强制切换，而应先确认各站点实际状态，避免数据分叉。

总结来说，Remote Copy 是数据复制的基石，Peer Persistence 是主机透明切换的关键，三站点复制则是面向更高容灾等级的组合方案。三者协同工作，才能让 Alletra 的异地复制与灾难恢复真正落地。理解每个组件的职责边界与配置依赖，是后续设计切换流程和演练方案的前提。