2. HPE Alletra存储架构回顾

在讨论异地复制与灾难恢复之前,必须先回到一个更基础的问题:数据从主机写入存储,到最终落到远端阵列,中间究竟经过了哪些硬件与软件环节?HPE Alletra 家族中,Alletra MP(模块化平台,Modular Platform)与 Alletra 9000 是两类典型代表,它们的架构差异会直接影响复制链路的时延、带宽占用、一致性组划分以及故障切换行为。本节不重复产品手册,而是从“复制视角”重新梳理这两类阵列的控制器、缓存、后端磁盘与数据路径。

一、Alletra MP:横向扩展的模块化架构

Alletra MP 采用模块化设计,其核心是“计算节点 + 存储节点”分离的横向扩展(scale-out)架构。一个典型配置由两个或多个计算节点(Controller Node)组成集群,每个节点内部运行 HPE Alletra OS(基于 HPE Primera/Alletra 9000 的软件栈演进而来),对外通过 NVMe over Fabrics(NVMe-oF)或 FC/iSCSI 提供块存储。计算节点之间通过高速低时延互联(如 100GbE 或更高)组成对等集群,共享后端存储资源。

在复制场景中,Alletra MP 的关键特征是:复制源端与目标端可以是不对称的。例如,源端为 Alletra MP 集群,目标端为 Alletra 9000,此时复制软件(如 HPE Peer Persistence 或 Remote Copy)需要处理两端缓存策略、写入确认机制和一致性组语义的差异。Alletra MP 的每个计算节点都拥有本地缓存,写入请求先进入节点缓存,再通过后端互联写入共享存储池。这意味着复制链路的起点不是“单个控制器”,而是“集群中接收写入的那个节点”。如果复制策略配置为“本地确认后异步复制”,则本地节点缓存写入成功即可向主机返回确认,远端复制在后台进行;如果配置为“同步复制”,则必须等待远端阵列确认,此时节点间互联和后端存储的时延都会叠加到主机写入时延中。

二、Alletra 9000:双控制器纵向扩展架构

Alletra 9000 是典型的双控制器纵向扩展(scale-up)架构。两个控制器(Controller Node)以 Active-Active 方式工作,每个控制器拥有独立的 CPU、内存和缓存,通过内部 PCIe 或专用互联共享后端磁盘柜(Enclosure)。主机通过 FC 或 iSCSI 连接到控制器前端端口,LUN 被分配给某个控制器作为“所有者”,但另一个控制器可以接管其 I/O。后端磁盘通常为 NVMe SSD 或 SAS SSD,通过 SAS 或 NVMe 背板连接到两个控制器,形成冗余路径。

从复制角度看,Alletra 9000 的缓存一致性机制非常关键。在同步复制中,主端控制器收到主机写入后,先将数据写入本地缓存,然后通过复制链路发送到远端控制器。远端控制器将数据写入其缓存并落盘(或写入非易失性缓存)后,返回确认。主端收到确认后,才向主机返回写入完成。这个过程涉及四个关键环节:主端前端端口 → 主端缓存 → 复制链路 → 远端缓存 → 远端后端磁盘。任何一个环节的时延或拥塞都会直接反映为主机写入延迟。因此,在规划同步复制时,必须关注控制器的缓存写策略、复制链路的 RTT(往返时延)以及后端磁盘的写入吞吐能力。

Alletra MP 与 Alletra 9000 复制数据路径对比 Alletra MP(横向扩展) 主机 / 应用 计算节点 1 本地缓存 + Alletra OS 前端 NVMe-oF / FC 计算节点 2 本地缓存 + Alletra OS 前端 NVMe-oF / FC 集群互联 共享后端存储池 NVMe SSD / 分布式 RAID 复制链路(异步/同步) 源端节点缓存 → 远端阵列 Alletra 9000(纵向扩展) 主机 / 应用 控制器 A(Active) 缓存 + 前端 FC/iSCSI LUN 所有者 控制器 B(Standby) 缓存 + 前端 FC/iSCSI 故障接管 缓存镜像 后端磁盘柜(Enclosure) NVMe SSD / SAS SSD,双路径 复制链路(同步/异步) 控制器缓存 → 远端控制器缓存 复制起点:接收写入的计算节点缓存 复制起点:LUN 所有者控制器缓存

三、缓存与后端磁盘对复制行为的影响

缓存是复制路径上最容易被忽视、却最影响行为的一环。Alletra MP 的每个计算节点都有本地缓存,写入数据先进入节点缓存,再异步或同步地写入共享存储池。如果复制策略是异步的,本地节点缓存写入成功即可返回主机确认,远端复制在后台排队。此时,如果节点缓存压力过大,复制队列可能积压,导致 RPO(恢复点目标)变大。Alletra 9000 的双控制器缓存则采用镜像机制:控制器 A 的缓存内容会实时镜像到控制器 B,确保单控制器故障时数据不丢失。在同步复制中,主端控制器必须等待远端控制器缓存确认,因此缓存写策略(Write-back 或 Write-through)会直接影响主机写入延迟。

后端磁盘方面,Alletra MP 的共享存储池通常由多个 NVMe SSD 组成,采用分布式 RAID 或纠删码,写入放大和重建行为会影响复制带宽。Alletra 9000 的后端磁盘柜通过双路径连接到两个控制器,单个磁盘故障时重建流量会占用后端带宽,进而影响复制链路的可用带宽。因此,在规划复制时,建议将复制流量与重建流量在时间上错开,或为复制链路预留足够的带宽余量。

四、数据路径与复制模式的选择

理解数据路径后,复制模式的选择就有了依据。同步复制要求主端和远端在写入确认前完成数据交换,因此对 RTT 非常敏感。如果两端阵列之间的 RTT 超过 5ms,同步复制的写入延迟会明显上升,此时更适合采用异步复制或周期性快照复制。异步复制则允许主端在本地缓存写入后立即返回确认,远端复制在后台进行,适合 RTT 较大但 RPO 要求不极端的场景。

此外,Alletra MP 的集群特性允许复制源端和目标端使用不同的节点组合。例如,源端集群中的节点 1 接收写入,复制链路可以绑定到节点 2 的专用复制端口,从而将复制流量与前端 I/O 流量分离。Alletra 9000 则通常将复制端口配置在控制器上,通过 FC 或 iSCSI 端口与远端阵列通信。无论哪种架构,复制链路的带宽、时延和队列深度都是需要持续监控的关键指标。

实践提示:在评估复制方案时,建议先绘制一张“数据路径图”,标注主机 → 前端端口 → 控制器/节点缓存 → 后端磁盘 → 复制链路 → 远端缓存 → 远端磁盘的每一跳,并记录每一跳的时延和带宽上限。这张图比任何参数表都更能帮助定位复制性能瓶颈。

五、小结:架构差异如何影响复制决策