仲裁之所以成为关键点，最重要的原因还是在于，从整体上看，存储跨站点双活技术是一个对称式的方案架构，两边一比一配比，中间通过链路（ FC 或者 IP ）连接，其最核心的难点公认是链路这个部分，这点从各家厂商方案披露支持的 RTT （往返延迟）和距离可以看出端倪。链路中断将造成两端健康的存储节点都认为对方挂掉，试图争取 Shared Resource （共享资源），并试图修改集群成员关系，各自组成一个集群，产生 Brain-Split （脑裂）现象，如果没有合理的机制去防范脑裂，将因互相抢夺共享资源自立集群，而导致共享卷数据读写不一致，产生更严重的后果。在存储双活方案，防范脑裂通用的做法就是使用仲裁机制，在第三站点放置仲裁服务器或者仲裁存储阵列。通常有以下三种方式：一是优先级站点方式。这种方式最简单，在没有第三方站点的情况下使用，从两个站点中选一个优先站点，发生脑裂后优先站点仲裁成功。但如集群发生脑裂后，优先站点也发生故障，则会导致业务中断，因此这种方案并非推荐的方案；二是软件仲裁方式。这种方式应用比较普遍，采用专门的仲裁软件来实现，仲裁软件放在第三站点，可以跑在物理服务器或虚拟机上，甚至可以部署到公有云上；三是阵列仲裁盘方式。这种方式是在第三站点采用另外一台阵列创建仲裁盘。这种方式稳定性，可靠性比较高。

本文转载自微信公众号： talkwithtrend

除了仲裁之外，两地三中心（ 3DC ）扩展方案也是企业上存储双活方案考量较多的关键点。所谓 3DC 即两地三中心，即一份数据有 3 份备份（包括自己）且分布在三个不同的地理位置即称之为三数据中心，通常是指生产中心，加上同城灾备中心以及异地灾备中心。近年来，大范围自然灾害时有发生， 3DC 容灾解决方案越来越受到业界重视和认可，企业在选型建设同城存储双活之前，也需要结合企业各项业务系统连续性保护要求，对存储双活方案之上的异地灾备扩展能力进行额外的考量，其考量点主要体现在以下四个方面：一是受银监和人行监管要求，同城存储双活除了需满足业务连续性指标 RTO 和 RPO 的要求之外，还需要在异地建立数据级以上的保护，以防范城市级重大自然灾害；二是所采用的异地灾备机制，是否会对现有生产和同城引入新的风险问题或者性能影响；三是两地三中心整体架构的完整性问题，在生产中心出现问题后，同城灾备中心接管，异地灾备是否具备持续的保护能力的问题，如果不具备持续保护能力，异地灾备接管的 RPO 将在生产站点恢复之前，不断滞后，灾备站点的单点时间将持续延长；四是在两地三中心架构下，异地灾备的资源是否具备被访问的能力，资源能否得到部分利用，提升整体资源利用率。

下面就这五种方案的仲裁方式和特点，以及两地三中心扩展方案一一解析。

一、 华为 HyperMetro

1、 仲裁
（ 1 ）仲裁需求：可选择采用仲裁设备的方式进行仲裁，仲裁设备可以是物理服务器，也可以是虚拟机，或者是公有云上的虚拟机；要求两套双活的存储阵列能够通过 IP 网络访问仲裁设备，网络带宽需大于 2MB/s ；独立的物理服务器或者虚拟机作为仲裁设备时，建议部署在第三方站点，这样可以避免单数据中心整体发生灾难时，仲裁设备也同时故障，导致脑裂问题的发生。

（ 2 ）统一管理：如下图所示，能够实现一套仲裁统一管理 SAN 与 NAS 双活，任何故障场景实现 SAN 和 NAS 在相同站点提供服务。

（ 3 ）双重仲裁模式：提供静态优先与仲裁服务器两种仲裁模式，最大限度保障存储双活方案的高可用。静态优先级模式主要应用在无第三方仲裁服务器的场景，在发生链路中断脑裂现象时，强制使优先的存储节点继续提供服务，一般不建议采用该方式，因为在静态优先存储发生故障时，非静态优先的存储和优先的存储间通讯也中断，按照该模式，主机存储访问将全部中断； HyperMetro 支持按双活 Pair 或双活一致性组（多对双活 Pair ）为单位进行仲裁，仲裁精细度高，通常可配置以业务为粒度进行仲裁（双活一致性组），仲裁之后，业务均衡分布访问两个存储，实现站点间链路故障时，主机就近访问。

2 、两地三中心扩展
华为 OceanStor HyperMetro 方案支持存储双活之上的异地容灾，通过与 OceanStor 统一存储系统的 HyperReplication 特性组合，并结合 BCManager 专业容灾管理软件实现 3DC 容灾。

当生产中心发生灾难，可在同城灾备中心进行接管业务，并保持与异地灾备中心的容灾关系。若生产中心和同城灾备中心均发生灾难，可在异地灾备中心对远程复制进行主从切换，并拉起业务。相对于传统的同步复制 + 异步复制的 3DC 方案，这种双活 + 异步复制的方案具有更好的资源利用率和故障切换速度。双活数据中心实现同城容灾时，可将同一关键业务负载均衡到双数据中心，并且在单数据中心发生故障，业务零中断，数据零丢失。在部署层面，双活数据中心支持平滑扩展为两地三中心，可先期实现同城双活，待异地数据中心建设完成后，再添加异步复制，实现应用异地保护。

另外，在 3DC 方案中，华为 BCManager 能够提供简化管理的容灾拓扑展示与端到端监控功能，直观清晰的展示保护方案的状态与变化，实时监控相关设备部件，实现业务灾难切换前就识别问题与故障并协助用户排除，规避影响业务和增加成本的容灾切换发生。

二、 EMC Vplex

1 、仲裁
（ 1 ）仲裁需求： Vplex Metro 和 Vplex Geo 系统具有专属的仲裁节点： Witness ，在搭建 Vplex 双活时，可根据需要包括或不包括 Witness 。 Witness 只能作为虚拟机部署，且只支持 VMware 虚拟化，并部署在与两个 Vplex 集群不同的故障域中 ( 第三方站点 ) 。在两个 Vplex 集群之间进行仲裁，发生站点故障和集群间通信中断时， Witness 起到仲裁效果，提高业务连续性。

（2） 防脑裂规则： Vplex 有着自己专属的防脑裂规则。第一种是分离规则：分离规则是在与远程集群间的连接中断（例如，链路或远程集群故障）时，确定 I/O 一致性组处理方式的预定义规则。在异常情况下，集群通信恢复之前，大多数工作负载需要获得特定虚拟卷集，才能在一个 Vplex 集群上继续 I/O 访问，并在另一个 Vplex 集群上暂停 I/O 访问。在 Vplex Metro 配置中，分离规则可以设置为静态优选集群，方法是设置： winner:cluster-1 、 winner:cluster-2 或 No Automatic Winner （无自动优胜者）。在没有部署 Vplex Witness 情况下， I/O 一致性组将在优选集群中继续提供 I/O 服务，并在非首选集群中暂停 I/O 服务。

第二种是 Vplex Witness,Vplex Witness 通过管理 IP 网络连接至两个 Vplex Metro 集群。 Vplex Witness 通过将其自身的观察与集群定期报告的信息进行协调，让集 群可区分是集群内故障还是集群间链路故障，并在这些情况下自动继续相应站点上的 I/O 服务。 Vplex Witness 仅影响属于 Vplex Metro 配置中同步一致性组成员的虚拟卷，并且仅当分离规则没有指明集群 1 或集群 2 是一致性组优选集群时才会影响（也就是说，“无自动优胜者”规则生效时， Vplex Witness 才会影响一致性组）。在没有 Vplex Witness 时，如果两个 Vplex 集群失去联系，生效的一致性组分离规则将定义哪个集群继续 I/O 服务以及哪个集群暂停 I/O 服务。

如上所述，如果仅使用分离规则来决定哪个站点是优胜者时，可能会增加站点故障时不必要的复杂性，因为可能需要手动干预才能恢复正常运行的站点 I/O 。而采用 Vplex Witness 则会动态地自动处理此类事件，这也是它成为 Oracle Extend RAC 部署时，绝对必要项的原因。 Vplex Witness 提供了以下几项内容： 一是在数据中心之间自动实现负载均衡；二是两个数据中心为 Active/Active 模式；三是可以实现存储层故障处理完全自动化。

为了让 Vplex Witness 能够正确区分各种故障情况，必须将 Vplex Witness 部署在独立于两个站点集群之外的故障域，并且采用互不相同的网络接口。这将规避单个站点故障同时影响 Vplex 集群和 Vplex Witness 的风险。例如，如果将 Vplex Metro 配置的两个集群部署在同一数据中心的两个不同楼层，则建议将 Vplex Witness 部署在其他楼层；如果将 Vplex Metro 配置的两个集群部署在两个不同的数据中心，则建议在第三个数据中心部署 Vplex Witness 。

2、 两地三中心扩展
Vplex 的两地三中心扩展方案有两种实现方式，第一种是借助 EMC RecoverPoint 设备实现。在 Vplex Metro 双活 +CDP 方案中， Vplex 接受到主机写 I/O 之后，同时写入两个数据中心的存储。此外 Vplex 内部集成 I/O 分流软件， Vplex 将每个主机写 I/O 同步复制到 RecoverPoint 。 RecoverPoint 将每个 I/O 记录下来，采用 CDP 实现任意时间点恢复，如下图 1 所示。在该方案之上还可进阶实现 3DC 方案：站点 2 的 RecoverPoint 通过异步复制将 I/O 复制到站点 3 部署的 RecoverPoint 设备，站点 2 的 RecoverPoint 都将每个 IO 记录下来，实现任意时间点恢复，站点 3 的 RecoverPoint 设备异步记录从站点 2 RecoverPoint 设备传输过来得 I/O ，并落地至后端的存储阵列。站点 2/3 的 RecoverPoint 设备对接的存储需要能够支持 RecoverPoint ，可以是 Vplex Local 集群，也可以是存储阵列，如下图 2 和 3 所示。由 EMC RecoverPoint 、 VPLEX Local （或存储阵列）和 Metro 组成的三个站点拓扑将减少主站点或存储阵列故障相关的停机时间，同时能够快速从应用程序数据损坏、病毒或人为错误中恢复，即具备物理和逻辑性错误的双重防范能力。如果丢失多个 VPLEX 站点或虚拟卷的逻辑损坏，可以通过第三方软件集成 , 自动恢复远程站点（第三站点）到虚拟卷的一致时间点。

图 1 Vplex Metro + RecoverPoint CDP

图 2 Vplex Metro to Vplex Local

图 3 Vplex Metro to Array-based Splitter

第二种是在 Vplex Metro 的基础上，借助 EMC 存储自身的复制技术实现 3DC 方案，即 Vplex Metro+EMC SRDF/A 方案，如下图所示，主站点和同城灾备站点为双活，主站点 Vplex 集群的底层存储为 EMC 存储（需具备 SRDF 复制许可），通过 SRDF 异步将数据传输至异地灾备站点后端的 EMC 存储（也需具备 SRDF 复制许可），实现数据级异地灾备。

三、 IBM SVC

1 、仲裁
（ 1 ）仲裁需求：对于 SVC ESC 和 SVC HyperSwap 存储双活方案架构而言，整体呈现的是一种对称式的整体架构，为了防范脑裂，仲裁站点是必需的。在仲裁站点中，基于 IP 的 Quorum 节点和物理 Quorum 磁盘都可以提供脑裂的仲裁服务，存储双活集群最多能够拥有 3 个物理 Quorum 磁盘，也可以选择最多 5 个基于 IP 的 Quorum 节点，这个基于 IP 的 Quorum 节点可以是任何站点的任何服务器，或者公有云的一个虚拟机，在这个服务器内运行一个简单的仲裁 JAVA 程序即可。相较于 Quorum 磁盘，基于 IP 的 Quorum 节点大大提高了仲裁站点的选择方式，节省了企业双活建设成本，只要求 IP 可达，延时在 80ms 之内即可。但是只有物理 Quorum 磁盘的仲裁方式才能够被用来做 SVC ESC 集群的 T3 Recovery ，所有的 SVC 节点都会将节点和集群的相关信息同步至该物理 Quorum 磁盘，当 SVC ESC 整个集群出现无法恢复的故障时，采用 SVC Manage 方式管理的底层存储 LUN ，将无法脱离 SVC 集群直接挂载给主机恢复业务，只能通过第三站点的物理 Quorum 磁盘进行 T3 Recovery 。对于 SVC HyperSwap 双活方案，由于两个站点存在两个互相保护集群，其中一个集群出现故障时，另一个集群可以接管故障，则不存在集群性整体故障无法启动，导致需要第三站点 Quorum 磁盘去做 T3 Recovery 的情景。

（ 2 ）仲裁机制：在 SVC 集群中有一个概念称为 Configuration Node ，即配置节点，是配置 SVC 集群后，系统自动产生的保存着所有系统配置行为的节点，不能人工更改配置节点。当配置节点失效后，系统会自动选择新的配置节点，配置节点十分重要，它对 SVC 节点仲裁胜利起着决定性作用，仲裁胜利的排序规则通常如下： a 、配置节点（配置节点获得仲裁胜利的概率最高）； b 、距离仲裁站点近的节点（探测延时较低的 SVC 节点获得仲裁胜利的概率次之）； c 、距离仲裁站点远的节点（探测延时较低的 SVC 节点获得仲裁胜利的概率最低）。例如，当两站点间光纤链路中断，第三站点仲裁节点活动时，脑裂发生，将通过投票仲裁选举获胜的站点，按照上述的仲裁胜利规则， Configuration Node 位于节点 2 ，选举站点 2 优先赢得仲裁，通过站点 2 恢复业务的正常存储访问。当第三站点仲裁节点不活动时，不影响主机的正常存储访问。但倘若此时，两站点间光纤链路也中断了，发生脑裂，这时因为节点 2 为 Configuration Node ，它所拥有候选的 Quorum 将变为 Active Quorum ，该 Quorum 选举站点 2 为仲裁胜利站点，通过站点 2 恢复业务的正常存储访问。

2 、两地三中心扩展
从存储网关层的角度，基于 SVC 的两种双活方案中只有 SVC ESC 方案具有 3DC

扩展能力，受限于 SVC Metro Mirror 或 Global Mirror 的技术体系，无法进行两个以上的 SVC 集群级联扩展， SVC HyperSwap 的复制核心技术为两个集群间的 Metro Mirror ，无法继续在 MM 之上，继续扩展为三个集群间的 MGM （这点与 IBM DS8000 系列的 MGM 技术体系有所差异）。而 SVC ESC 方案的复制核心技术为 Vdisk Mirror ，为同一 SVC 集群下的镜像技术，在此基础之上可以继续扩展为 VDM+MM 或 GM 的架构。从下图 SVC ESC 扩展两地三中心的架构来看，异地灾备站点既可以部署 SVC+ 兼容的后端存储阵列，也可以直接部署 V7000/V5000 等 IBM 存储（这两款存储和 SVC 具有相同的虚拟化软件），通过 GM 异步和 SVC ESC 集群保持复制关系。

而从底层存储的角度，依靠存储阵列的复制技术，可以是 IBM DS8000 系列的 MM 或者 GM ，也可以是 EMC 的 SRDF/S 或者 SRDF/A ，亦或者是 HDS 的 TrueCopy 或者 Universal Replicator 等等， SVC ESC 和 SVC HyperSwap 均可以实现 3DC 扩展。存储网关层的 3DC 扩展和底层存储层的 3DC 扩展有一个比较重要的区别，如果主机的 SVC 虚拟卷条带化分散在底层存储的不同 LUN 上（ Manage 模式），采用底层存储复制技术实现 3DC 方案，可能会导致异地灾备的存储 LUN 无法挂载给主机使用，这种 3DC 方案显然是不推荐的；而采用存储网关层的 3DC 方案，则可以有效避免这种问题，异地灾备的主机可以顺利挂载 SVC/V7000/V5000 上的虚拟机卷。如果主机的 SVC 虚拟卷和底层存储 LUN 是一一对应的（ IMAGE 模式），采用底层存储复制技术则不会遇到该问题。

四、 HDS GAD

1 、仲裁
（ 1 ）仲裁需求：分布式集群和双活方案都需要仲裁机制防止脑裂，保证心跳故障后，整个集群系统能对外提供数据一致性存储服务。 GAD 的仲裁机制原理是采用仲裁磁盘的方式实现，暂不支持通过 IP 仲裁节点实现；仲裁磁盘是第三站点外部存储系统虚拟化的卷，可以是存储阵列，也可以是受支持的服务器磁盘，用于当链路路径或存储系统发生故障时，确定主机 I/O 应在哪个存储系统上继续访问。主存储和从存储每 500 毫秒检查一次仲裁磁盘的物理路径状态；另外，建议外部存储系统的响应时间尽量小，如果响应时间超过 100 毫秒，需要执行必要的操作以减少响应时间。

（ 2 ）仲裁机制： HDS GAD 具有独特的磁盘仲裁机制，如下图所示，当主存储系统和从存储系统无法通信时，将执行以下操作： a 、当主存储系统无法通过数据路径和从存储系统进行通信时，会将此状态写入仲裁磁盘； b 、当从存储系统从仲裁磁盘检测到发生路径故障时，它将停止接受主机的读写操作 ;c 、从存储系统将与仲裁磁盘进行通信 , 将已停止读写操作的状态通知仲裁磁盘 ;d 、当主存储系统检测到从存储系统无法接受主机读写操作时，主存储系统将挂起 GAD Pair Volume;e 、主存储系统恢复主机读写访问操作。

如果主存储系统在通信中断后的 5 秒内，无法从仲裁磁盘检测到从存储系统不接受主机 I/O 的状态通知，主存储系统将挂起 GAD Pair Volume ，并恢复主机 I/O 访问；如果主存储和从存储系统同时向仲裁磁盘写入通信停止的状态，则认为该通信中断由存储序列号较小的存储系统写入。由该存储系统挂起 GAD Pair Volume ，恢复该存储的主机读写访问操作。如果仲裁磁盘故障，两个存储间的通信中断时，主存储和从存储系统均无法写入通信中断状态到仲裁磁盘，将导致两个存储的全都无法接收主机读写 I/O ，需要强制删除删除 GAD Pair Volume 恢复业务。

针对对应系统（主存储或者从存储）是否能够被检测到已经停止了主机 I/O 访问，有以下两种仲裁机制：

一是在对应系统中检测到主机 I/O 访问停止：当在对应系统中 5 秒内检测到停止时，将根据 GAD Pair Volume 的状态（见下表）来确定停止后将继续接收读写的 Pair Volume 。 a 、当 Pair Volume 的状态为 PAIR 时，将通信中断写入仲裁磁盘的存储卷将恢复主机读写访问； b 、当 Pair Volume 的状态为 INIT/COPY 时， P-VOL 的主机读写访问继续，而对 S-VOL 的主机读写访问将保持停止状态； c 、当 Pair Volume 状态为 PSU 、 PSU 、 SSW 或 SSU 时， I/O 模式为 Local 的卷将恢复主机读写访问， I/O 模式为 Block 的卷将停止主机读写。

二是对应系统中未检测到主机 I/O 访问停止：当对应系统在 5 秒内未检测到中断时，将通信中断写入仲裁磁盘的存储卷在中断后恢复接收主机读写访问。读写处理机制取决于 Pair Volume 状态和未检测到写的 I/O 模式。 a 、当 Pair Volume 的状态为 PAIR 时，两个存储的主机读写访问继续； b 、当 Pair Volume 状态为 INIT/COPY 时， P-VOL 的主机读写访问继续，而对 S-VOL 的主机读写访问保持停止状态； c 、当 Pair Volume 状态为 PSU 、 PSU 、 SSW 或 SSU 时， I/O 模式为 Local 的卷将恢复主机读写访问， I/O 模式为 Block 的卷将停止主机读写。

2 、两地三中心扩展
HDS 存储两地三中心方案有三种成熟的架构，所采用的技术也有所差异，分

为级联三中心拓扑、多目标拓扑和异步复制的存储集群拓扑，如下表所示。相较于其他存储架构方案， HDS 在两地三中心方案上提供了不同层次的数据和业务连续性保护能力。下面一一详细介绍：

（1） 级联三中心拓扑：下图为该拓扑架构图，生产中心和同城灾备中心间保持同步复制关系，同城灾备中心和异地灾备中心保持异步复制关系，在该拓扑下，当同城灾备中心发生故障的情况时，异地灾备中心与其在该时间点接收的数据将被暂时冻结。随后，决策层必须决定是否在不具备持续保护的情况下继续运行 IT 生产系统。如决定继续运行，异地灾备中心的数据差异量将进一步增加，并且如果接下来生产中心发生故障，则可能会导致重大的永久性数据丢失。管理员可以选择停止生产中心，直到同城灾备中心恢复，或可以建立从生产中心到异地灾备中心的链路。在这种情况下，会导致生产恢复时间延长，但可最大限度地降低数据丢失量。对于在较小地理区域内的企业，级联三中心拓扑能使业务开展更加顺利。导致生产中心和同城灾备中心同时发生故障的灾难将可能只对大多数本地客户造成影响。对于跨国企业，尤其是提供关键基础架构服务的企业，级联三中心拓扑可能无法满足更为严格的要求。

（2） 多目标拓扑：下图为多目标拓扑，生产中心和同城灾备中心保持同步复制关系，同时也和异地灾备中心保持异步复制关系，同城灾备中心和异地灾备保持差异数据再同步复制关系。多目标拓扑与级联三中心拓扑和之间的区别在于：在多目标拓扑中，生产中心同时将数据备份到两个中心。这是 HDS 存储最新的技术能力，并且需要非常高性能的控制器来对此流程进行管理。该方案可以确保在生产中心或同城灾备中心丢失时不会出现永久性数据丢失。任一中心可以将数据传送到异地灾备中心，以确保零数据丢失。为确保快速恢复，存储控制器技术必须能使异地灾备中心上的控制器与生产中心或同城灾备中心重新同步，并仅传递更改的数据（增量重新同步）。而在级联三中心拓扑中，如果同城灾备中心关闭，则不能将数据传送到异地灾备中心。多目标架构的主要缺点是三中心链路的成本较高。而主要优势是，如果同城灾备中心中有备份服务器，则可以在生产中心和同城灾备中心之间进行故障切换和故障自动恢复。由此将显著缩短业务恢复时间。此外，还可以在任一备份中心创建和挂载远程快照或克隆，以启用辅助用途。这些用途包括将数据备份到磁带、开发测试使用生产数据或进行生产数据恢复测试等操作，而不会对生产系统的性能或可用性造成影响。

（3） 异步复制的存储集群拓扑：如下图所示，该架构和多目标拓扑架构类似，差别在于生产中心和同城灾备中心的高可用方式，多目标拓扑为 ACTIVE-STANDBY 模式，而存储集群拓扑为 ACTIVE-ACTIVE 集群模式。该架构为 HDS 的最新技术，有关存储故障恢复能力和数据可用性的最新发展成果都在 GAD 存储集群技术中有所体现。这些功能是 Hitachi Virtual Storage Platform 系列系统的存储虚拟化操作系统的一部分。通过 GAD ，可配备两个生产中心，每个中心均有所有数据的活动拷贝。如任一中心发生故障，则其数据在其他中心是透明可用的，无需执行故障切换或故障将自动恢复。 Universal Replicator 异步复制用于将数据从任一生产中心复制到异地灾备中心。上述有关多目标配置的所有额外优势均适用于此架构。存储集群的 3DC 模型可提供最大级别的数据可用性和故障恢复能力，同时实现零数据丢失。

五、 NetApp MetroCluster

1 、仲裁
（ 1 ）仲裁需求： NetApp MCC 的 MetroCluster 仲裁软件称为 TieBreak ，它支持部署在第三站点的 Linux 的主机上，该软件通过对节点 SSH 的 Session 进行检查，实现对 HA Pair 和集群状态进行监控。 TieBreak 软件能够在 3 到 5 秒内检查到 SSH Session 的故障，重试的时间间隔为 3 秒。仲裁软件的这种方式具有灵活性的优势，第三站点可以选择两个数据中心中的一个，可以选择公有云中的一个虚拟机，也可以选择其他建筑内的任意一台 Linux 虚拟机，保证 SSH 网络可达即可。下图为 NetApp MCC+TieBreak 的拓扑架构。

（2） 仲裁机制： MetroCluster 仲裁的机制有两种，第一种为静态模式，在站点发生故障后， MetroCluster 配置本身不会检测并启动切换。此时不能依靠一个站点去监视另一个站点的故障，因为从一个集群到另一个集群的响应超时可能是由于活动的站点故障引起的，或者可能是由于所有站点间链路的故障引起的，站点间的监视无法发现真实的故障引发原因。在静态模式下，如果站点间所有链路都出现故障时， MetroCluster 配置将继续运行，提供本地 I/O 服务，但无法将写 I/O 同步至远程站点。当站点间一条以上链接线路恢复后，会自动恢复复制关系，并追上异常时产生的数据差异。在这种情况下，不会产生自动切换，因为每个集群都认为另一个集群已经失败，并且两者都可能尝试执行切换，从而导致脑裂场景，造成数据不一致。至于是否需要切换，可以由管理员或领导确定。第二种为仲裁模式， NetApp 提供完全功能支持的 MetroCluster Tiebreaker 软件进行仲裁，该软件安装在第三个站点，并与两个集群中的每个集群建立独立连接。 Tiebreaker 软件的目的是监控和检测单个站点故障和站点间的链路故障。如果发生站点灾难， MetroCluster Tiebreaker 软件可能会引发 SNMP 陷阱。它以观察者模式运行，并且可以在发生需要切换的灾难时检测并发送警报。管理员收到告警后，可以手动发出切换命令进行灾备切换，也可以将 Tiebreaker 软件配置为在发生灾难时自动发出切换命令。

为了创建站点可用性的聚合逻辑视图， Tiebreaker 软件监视节点， HA Pair 和集群级别的相关对象，通过对集群硬件、直接链接和间接链接检查来更新其链接和集群状态。通过不断的更新来判断 Tiebreaker 是否检测到 HA 接管事件、站点故障或所有站点间链路故障等场景。直接链接是通过 Secure Shell （ SSH ）到节点的管理 LIF 。所有到集群的直接链接失败都表示该站点出现故障，其特征是集群停止提供任何数据（所有 SVM 都已关闭）。间接链接确定集群是否可以通过任何站点间（ FC-VI ）链接或集群间 LIF 到达另一个集群。如果集群之间的间接链接失败，而到节点的直接链接成功，则表明站点间链接已关闭，并且集群彼此隔离。在这种情况下， MetroCluster 将按照静态模式继续运行；如果到单个站点节点的直接链接失败，则表明站点可能出现故障。在这种情况下， MetroCluster 将按照仲裁模式，产生告警事件，进行自动或手动切换。

2 、两地三中心扩展
NetApp MetroCluster 采用 SnapMirror 数据复制来实现两地三中心扩展方案，从 ONTAP 9.5 开始， MetroCluster 增加了对 SVM DR 的支持， MetroCluster 配置中的活动存储虚拟机（ SVM ）可用作具有 SnapMirror SVM 灾难恢复功能的源，以获得更高级别的保护，但目标 SVM 必须位于 MetroCluster 配置之外的第三个群集上。如下图所示，可分别为两个站点的不同 SVM 建立相同的异地容灾保护。

然而将 SVM 与 SnapMirror 灾难恢复一起使用时，具有以下要求和限制：

（ 1 ）只有 MetroCluster 配置中的活动 SVM 才能成为 SVM 灾难恢复关系的来源。源可以是切换前的同步源 SVM ，也可以是切换后的同步目标 SVM 。

（ 2 ）当 MetroCluster 配置处于稳定状态时， MetroCluster 同步目标 SVM 不能成为 SVM 灾难恢复关系的来源，因为卷是离线状态，无法读写。也就是说，无法通过 MetroCluster 同步目标 SVM 来继续扩展多数据中心。

下图左显示了在 MetroCluster 稳定状态下的 SVM 灾难恢复架构：

（ 1 ）当同步源 SVM 是 SVM DR 关系的源时，源 SVM DR 关系信息也将复制到 MetroCluster 的 Partner, 这样可以在 MetroCluster 集群切换后，由 Partner 继续维持 SVM DR 架构，主站点故障，同城灾备站点依旧具备完备的灾难恢复能力，如下图中所示：

（2） 在 MetroCluster 集群内部发生切换和切回过程中，到 SVM DR 目标的复制可能会失败。但是在切换或切回过程完成后，将重新建立起 SVM DR 复制关系。

上图右为灾难恢复站点上的 SVM 重新同步架构，在重新同步期间， MetroCluster 配置上的存储虚拟机（ SVM ）灾难恢复（ DR ）源将从非 MetroCluster 站点上的目标 SVM 还原，建立重新同步关系，在重新同步期间，由源 SVM （ cluster_A ）暂时充当目标 SVM 。

（ 1 ）如果在重新同步期间， MetroCluster 集群内部发生非计划性的意外切换，将停止重新同步的数据传输。如果发生意外切换，则满足以下条件： a 、 MetroCluster 站点上的目标 SVM （在重新同步之前是源 SVM ，图中为 cluster_A ）仍然是目标 SVM 。 MetroCluster Partner 集群（图中为 cluster_B ）中的 SVM 依旧保留其子类型并保持不活动状态； b 、必须使用同步目标 SVM 作为目标手动重新创建 SnapMirror 关系； c 、除非执行 SnapMirror 创建操作，否则在幸存者站点切换后， SnapMirror 关系不会出现在 SnapMirror show 的输出中体现。

（ 2 ）当需要对重新同步期间的意外切换，执行回切操作时，必须断开并删除重新同步关系。如果 MetroCluster 配置中有任何 SnapMirror DR 目标 SVM ，或者集群具有子类型 “dp-destination” 的 SVM ，则不允许使用回切。

性能影响问题是存储双活方案的突出问题，因为双活系统在写入数据时，会写两次数据，尤其是通过复制功能写到远端存储的过程，传输链路的性能也会影响整体性能。因此，存储双活不可避免要遇到性能问题，这也是各大厂商存储双活方案标明最大支持 RTT 或者站点间距的原因之一。相比单存储直接提供读写来说，存储双活一定会增加读写响应时间，更别说存储还是跨两个不同数据中心的，随着距离的增加，理论上每增加 100KM ，会增加 1MS 的 RTT （往返延迟时间），通常单个 I/O 总耗时在 1-3MS 左右，就会认为单个存储 I/O 时延处于比较高性能的模式（最大支持的 IOPS 也是存储选型的重要考虑因素），如果加上其他因素，如“数据头处理”和“并发”， 1MS 的“理论”时延增加的影响会成倍增加，将原本处于高性能模式的 I/O 响应时间拉高，对应用或者数据库来说，“变慢”了。所以存储双活的初衷是只是为了高可用性和提高总体并发、吞吐量，并不是为了降低读写响应时间。然而，我们在选型存储双活方案时，依旧需要考虑如何尽量降低双活的存储所带来的性能降低影响，哪种方案会带来较小的性能影响。因此，笔者现就目前国内主流的五种存储双活方案在双活性能上的特点进行解析。

本文转载自微信公众号： talkwithtrend

一、华为 HyperMetro

1 、读 I/O ：针对数据读场景， 华为 HyperMetro 方案架构下， 双活数据中心的业务主机只需要读本数据中心对应的双活存储阵列即可，如下图所示，这样可以有效避免主机跨数据中心读取数据，提升整体读 I/O 访问性能。

2 、写 I/O ：针对数据写场景，业务主机直接写本数据中心对应的双活存储阵列，避免主机跨数据中心转发数据（在转发写模式下，区分主从 LUN ，从 LUN 的写 I/O 将被控制器转发到主 LUN 的控制器处理写 I/O ，并将数据回同步至从 LUN ），充分利用 HyperMetro AA 双活能力，如下图左所示， AA 集群的每个控制器都能够接收写 I/O ，由本地控制器处理本地主机的写 I/O 请求，减少跨数据中心的转发次数，提升方案整体性能。数据写 I/O 过程如下图右所示：

假如数据中心 A 的存储阵列收到写 I/O ，写 I/O 处理流程如下：

（ 1 ）申请写权限和记录写日志：数据中心 A 存储阵列收到主机写请求，先申请双活 Pair 的写权限。获得写权限后，双活 Pair 将该请求记录写日志（保证断点续传）。日志中只记录地址信息，不记录具体的写数据内容。该日志采用具有掉电保护能力的内存空间记录以获得良好的性能。

（ 2 ）执行双写：将该请求拷贝两份分别写入本地 LUN 和远端 LUN 的 Cache 。

（ 3 ）双写结果处理：等待两端 LUN 的写处理结果都返回。

（ 4 ）响应主机：双活 Pair 返回主机写 I/O 操作完成，完成一次写 I/O 周期。

从整个写 I/O 流程可以看出， HyperMetro 为了保证两个数据中心存储的数据实时一致，写操作都需要等待两端存储写成功之后再返回主机“写成功”。双活 I/O 性能因为实时双写导致了一定的时延增加，该写 I/O 流程相较于本地写 I/O 而言，额外增加了以下四个时延点。

（1） 写权限申请时，等待分布式锁产生的时延；

（2） DCL 机制（数据变化记录）产生的时延；

（ 3 ）跨站点将写 I/O 拷贝至远端 LUN Cache ；

（ 4 ）远端 LUN Cache 收到写 I/O 后，将处理结果返回至本地。

这四个时延点中最主要的还是 3 和 4 中组成的 1 倍跨站点往返时延（ RTT ），此外，华为 HyperMetro 设计了一系列 I/O 性能优化方案，以减小对写时延的影响，提升整体双活的业务性能。

（ 1 ）数据零拷贝：在双活镜像数据的初始同步或者恢复过程中的增量同步过程中，差异数据块通常有大量的零数据块，无需逐块复制，该功能叫数据零拷贝。例如，虚拟化场景下，新建虚拟机时会产生大量的零数据块，一个数十 GB 的操作系统盘，实际非零数据块仅 2-3GB 。HyperMetro 零页面识别技术的实现方法如下：通过硬件芯片，对数据拷贝源端进行快速识别，找出零数据，在拷贝过程中，对全零数据特殊标识，只传输一个较小的特殊页面到对端，不再全量传输。相比全量同步，该技术可有效减少同步数据量，减少带宽消耗，缩短整体 I/O 同步时延。

（ 2 ） FastWrite 技术：HyperMetro 通过 FastWrite 功能对阵列间数据传输进行了协议级优化，应用 SCSI 协议的 First Burst Enabled 功能，将写数据的链路传输交互次数减少一半。正常的 SCSI 流程中，写 I/O 在传输的双端要经历“写命令”、“写分配完成”、“写数据”和“写执行状态”等多次交互。利用 FastWrite 功能，优化写 I/O 交互过程，将“写命令”和“写数据”合并为一次发送，并取消“写分配完成”交互过程，将跨站点写 I/O 交互次数减少一半。该技术将单次写 I/O 的 RTT 控制在 1 倍，避免无效交互产生的 RTT 。

（ 3 ）智能的锁预取和缓存策略：本地写 I/O 时，需对主机 I/O 访问的 LBA 区间加分布式范围锁进行并发互斥，通过分布式范围锁，可以避免频繁的锁请求交互，减少跨站点交互交互频率。当 HyperMetro 的分布式锁技术在写权限本地无缓存（范围锁）的情况下，会通过较小的控制报文，向锁权限缓存节点申请写权限，并多预取部分区间的写权限缓存到本地，如下图左所示。后续的连续写 I/O 可快速在本地命中写权限，不需要再跨站点申请写权限，这样将进一步减少交互频率，如下图右所示。

二、 EMC VPLEX

1 、读 I/O ：EMC Vplex 具有读缓存，可以通过写 I/O 的独特机制，实现读 I/O 的加速。Vplex Local/Metro/Geo 架构的读 I/O 流程如下：

（ 1 ）读 I/O 的时候先读 Local Cache ，如命中则直接读取，相较于直接读后端存储阵列，内存较机械硬盘的读取性能有着显著提升，因此，从 Cache 内存中直接命中读 I/O ，将大幅提升读 I/O 性能；

（ 2 ）如果没有命中 Local Cache ，将继续在 Global Cache 中查找，如果命中，则从对应的 Vplex 引擎 Cache 中将其读取到 Local Cache ，因此，两引擎的 VplexMetro/Geo 架构存在 1 倍的跨站点往返时延；

（ 3 ）如果在 Global Cache 中没有命中，则从本地后端的存储阵列中读取到 Local Cache 中，并同时修改 Local 和 Global Cache 中的信息与索引信息（表明其他引擎可以从该引擎 Cache 读取数据），本次读 I/O 加速无效果。

（ 4 ）无论有没有命中 Cache ，最后都将反馈主机读 I/O 结果，本次读 I/O 周期结束。

从整个读 I/O 流程可以看出，相较于常见的后端存储直接读取，由于读 Cache 的存在，对读 I/O 性能的提升是有积极意义的，命中 Local Cache 将提升数倍读响应时间，没有命中 Local Cache 几乎和直接后端存储读取性能一致，在实际联机型应用读写比例大致为 7 ：3 的情况下，提升读 I/O 的效果是显而易见的。

2、 写 I/O ：EMC Vplex 同样也具备“写缓存”， Vplex Metro 没有真实的“写缓存”，实际上是读缓存，用于加速读 I/O ，模式采用的是写直通缓存；Vplex Geo 具有真实的写缓存，模式采用的是回写缓存。其中 Vplex Metro 写 I/O 流程如下图所示：

Vplex Metro/Geo 的写 I/O 步骤如下：

（1） 写 I/O 时先判断是否在 Local 、 Global Cache 中有对应的旧数据，如果没有，则直接写入本地 Local Cache ；

（2） 如果有旧数据，需先废除旧数据再写入 Local Cache 。若通过 Global Cache 查询到 旧数据存在于其他站点 Vplex 引擎中，则需要跨数据中心查询和废除旧数据，通讯具有 1 倍的跨站点往返时延；

（3） 写入 Local Cache 后， Vplex Metro 和 Geo 的处理方式有所区别， Vplex Metro 通过写直通缓存模式将写 I/O 刷入两套后端存储阵列，刷入跨站点的后端存储将引入 1 倍的跨站点往返时延；而 Vplex Geo 通过回写缓存模式将写 I/O 写入引擎控制器的缓存，并异步镜像至另一套 Vplex 集群的引擎控制器的写 Cache 中；

（4） Vplex Metro 待两套存储全部写反馈完成，最后将反馈主机写 I/O 周

期完成，同时 Global Cache 中的索引做相应修改，并在所有引擎上共享该信息，实现分布式缓存一致性；而 Vplex Geo 在镜像异步写发起后，直接反馈主机写

I/O 周期完成，并待两个引擎的 Cache 达到高水位后刷入后端存储。

从整个写 I/O 流程可以看出， Vplex Metro 为了加速读 I/O ，引入了读 Cache ，

为了保证读 I/O 的数据一致性（ AccessAnyWhere ），又引入了 Global Cache ，造成写 I/O 必须要查询本地和其他引擎的 Local Cache 是否有旧数据，以及时废弃旧数据，更新和同步所有引擎的 Global Cache 。这样的机制原理势必牺牲了一定的写 I/O 性能，相较于后端存储直接写，引入了两倍的 RTT 和更新同步 Local 、 Global Cache 过程的时延。其应用场景更适合于查询比例远高于更新比例的联机型应用。

三、 IBM SVC

1、 SVC ESC 方案读 I/O ：针对数据读场景，两个站点的主机对本站点 SVC

节点和底层存储节点的读 I/O 可以实现就近本地读能力，如下图所示，无需跨站点读其他 SVC 节点和存储节点，避免了跨站点往返时延消耗，性能较单站点存储节点直接读取，性能几乎一致；当某个站点的存储出现故障时，该站点的 SVC 节点将激活和另一个站点的存储路径，切换读取该存储的数据。

、 SVC ESC 方案写 I/O ：针对数据写场景， SVC ESC 的方案和 SVC Local 方案略有区别， SVC Local 由一组 I/O Group ，两个 SVC 节点组成，对于存储 LUN 而言，其必然从属于其中一个 SVC 节点，称为优先节点。存储 LUN 的访问只能由优先节点提供；而 SVC ESC 同样是一组 I/O Group ，其两个 SVC 节点的角色是一致的，摒弃了优先节点的概念，主机、 SVC 节点和底层两个存储 LUN 具备站点属性， LUN 优先从属于本站点的 SVC 节点，优先被本站点主机访问。这样则实现了两个站点主机并行写本站点的 SVC 节点和对应的底层存储节点，即本地写的能力。其写 I/O 流程步骤如下：

（ 1 ）本地 SVC Local Cluster 写 I/O ：

a 、主机发送写 I/O 请求至 SVC I/O Group ， SVC 优先节点反馈主机写已就绪，随后主机将写数据发送至优先的 SVC 节点（图示步骤 1 ）；

b 、优先的 SVC 节点将 I/O 写入缓存，并镜像同步至同一 I/O group 的另一个 SVC 节点（图示步骤 2 ）；

c 、该节点收到写 I/O ，将其写入本地缓存，并回反馈至优先的 SVC 节点（图示步骤 3 ）；

d 、优先的 SVC 节点收到反馈后，向主机回反馈，主机端的写 I/O 周期结束（图示步骤 4 ）；

e 、待优先的 SVC 节点缓存达到一定高水位，将所有写 I/O 刷入后端存储 LUN （图示步骤 5 ）。

（ 2 ） SVC ESC Cluster 写 I/O ：

a 、主机发送写请求至本地 SVC 节点， SVC 节点反馈主机写已就绪，随后主机发送写数据至本地 SVC 节点（图示步骤 1 、 2 、 3 ）；

b 、本地 SVC 节点将 I/O 写入缓存，并将写缓存数据镜像到远端 SVC 节点（图示步骤 4 ）；

c 、远端 SVC 节点反馈本地 SVC 节点写完成标识（图示步骤 5 ） ;

d 、本地 SVC 接收到远端反馈后，反馈写完成标识给本地主机（图示步骤 6 ） ;

e 、待本地和远端 SVC 节点写缓存达到高水位，开始刷数据至后端存储，首先发送写请求给后端存储，后端存储反馈 SVC 节点写已就绪， SVC 开始发送写数据（图示步骤 7 、 8 、 9 ）；

f 、待写数据全部刷入，后端存储分别反馈写完成标识给本地和远端 SVC 节点（图示步骤 10 ）；

从整个 SVC ESC 方案的写 I/O 流程可以看出，步骤 1 至 6 对主机写 I/O 时延有影响，但写 I/O 仅传送一次数据到远端，相比本地直接写 I/O ，增加了 1 倍的跨站点往返时延。另外，步骤 7 至 10 是异步操作，对主机时延无影响。

3 、 SVC HyperSwap 方案读 I/O ：假设初始化后， Site1 的卷为 Master 卷，

Site2 的卷为 Aux 卷，这种情况下 Site1 和 Site2 卷的读 I/O 流程是不一样的，如下图所示，其流程步骤如下：

（ 1 ） Site1 主机读 I/O （本地 =Site1, 远端 =Site2 ）：

a 、 Site1 主机向本地 SVC I/O Group1 的任意一个 SVC 节点发送读请求；

b 、本地 SVC I/O Group1 将读请求透传至本地 Storage Pool1 ；

c 、本地 Storage Pool1 反馈读请求，并将读数据传至本地 SVC I/O Group1 ；

d 、本地 SVC I/O Group1 将数据结果反馈至 Site1 主机；

（ 2 ） Site2 主机读 I/O （本地 =Site2, 远端 =Site1 ）：

a 、 Site2 主机向本地 SVC I/O Group2 的任意一个 SVC 节点发送读请求；

b 、本地 SVC I/O Group2 将读请求转发至远端 SVC I/O Group1 ；

c 、远端 SVC I/O Group1 将读请求透传至远端 Storage Pool1 ；

d 、远端 Storage Pool1 反馈读请求，并将读数据传至远端 SVC I/O Group1 ；

e 、远端 SVC I/O Group1 将数据结果反馈至本地 SVC I/O Group2 ；

f 、本地 SVC I/O Group2 将数据结果反馈至 Site2 主机。

从整个 SVC HyperSwap 方案的读 I/O 流程来看， Site1 主机是本地读，直接透穿 SVC I/O Group 读本地底层存储，读性能几乎和主机直接读后端存储一致；Site2 主机的读 I/O 需要通过本地 SVC I/O Group 跨站点转发至 Site1 的 SVC I/O Group ，再读远端的后端存储，因此额外增加了 1 倍的跨站点往返时延。

4 、 SVC HyperSwap 方案写 I/O ：假设初始化后， Site1 的卷为 Master 卷，

Site2 的卷为 Aux 卷，这种情况下 Site1 和 Site2 卷的写 I/O 流程也是不一样的，如下图所示，其流程步骤如下：

（ 1 ） Site1 主机写 I/O （本地 =Site1, 远端 =Site2 ）：

a 、 Site1 主机向本地 SVC I/O Group 节点发送写 I/O 请求和数据；

b 、本地 SVC 节点将写 I/O 写入本地写缓存；

c 、本地 SVC 节点将写 I/O 同步至同 I/O Group 的另一 SVC 节点缓存，并通过 SVC Metro Mirror 发送写 I/O 至远端 SVC I/O Group 节点；

d 、本地和远端所有 SVC 节点陆续反馈写 I/O 同步已完成；

e 、本地 SVC 节点反馈 Site1 主机写完成；

f 、待本地和远端 SVC 节点写缓存达到高水位，分别将写缓存数据刷入各自站点的后端存储中。

（ 2 ） Site2 主机写 I/O （本地 =Site2, 远端 =Site1 ）：

a 、 Site2 主机向本地 SVC I/O Group 节点发送写 I/O 请求和数据；

b 、本地 SVC 节点将写 I/O 转发至远端 SVC I/O Group 节点；

c 、远端 SVC 节点将写 I/O 写入写缓存中；

d 、远端 SVC 节点将写 I/O 同步至同 I/O Group 的另一 SVC 节点缓存，并通过 SVC Metro Mirror 发送写 I/O 至本地 SVC I/O Group 节点；

e 、本地和远端所有 SVC 节点陆续反馈写 I/O 同步已完成；

f 、远端 SVC 节点反馈本地 SVC 节点的转发响应；

g 、本地 SVC 节点反馈 Site2 主机写完成；

h 、待本地和远端 SVC 节点写缓存达到高水位，分别将写缓存数据刷入各自站点的后端存储中。

从整个 SVC HyperSwap 方案的写 I/O 流程来看， Site1 主机是本地写，直接写 SVC 节点缓存，并同步至两个站点所有 SVC 节点。相比直接存储写 I/O ，增加了一倍的跨站点往返时延；Site2 主机的写 I/O 需要通过本地 SVC I/O Group 跨站点转发至 Site1 的 SVC I/O Group ，该步骤增加了一倍的跨站点往返时延。写到 Site1 的数据必须同步回 Site2 ，来保证两个站点数据一致性，这个步骤又额外增加了一倍的跨站点往返时延，因此，相比直接存储写 I/O ，总共额外增加了 2 倍的跨站点往返时延。

四、 HDS GAD

HDS GAD 的读写 I/O 流程受 GAD 卷的状态所影响， GAD 卷由 PVOL 和 SVOL 成对组成，其状态分为已镜像、正在镜像、暂停、阻塞。在不同状态下，两个站点的主机对 PVOL 和 SVOL 的读写 I/O 步骤和性能是不一样的。

1 、主机写 I/O （ GAD 状态为：Mirrored ）：当 GAD 卷的状态为已镜像时， PVOL 卷和 SVOL 卷的 I/O 模式为镜像。主端和从端都可以进行写操作，正常情况下，任意端存储接收到写 I/O 请求后，都执行双写，待两端存储全部写入成功后，再回复主机写成功，完成写 I/O 周期。如下图所示，其详细写 I/O 步骤如下：

（1） 主机可通过 HDLM 多路径软件来配置优选路径为本地的存储卷，首先发起写 I/O 请求，对 GAD 卷的写数据将写入本地存储卷；

（2） 本地存储卷将接收到的写 I/O 同步镜像至远端存储卷；

（3） 远端存储卷收到写 I/O 后，完成写 I/O ，并反馈结果至本地存储卷；

（4） 两端存储卷全部双写完成后，由本地存储卷反馈主机写完成。

其中，步骤 2 、 3 将引入 1 倍的跨站点往返时延。

2 、主机读 I/O （ GAD 状态为：Mirrored ）：针对读 I/O 场景，两个站点主机可分别读取本站点的主存储和辅助存储系统的数据，主机服务器通过优选路径读取本地存储卷，然后发送到服务器。该场景下，主存储系统和从存储系统之间没有任何通信发生。

3 、主机写 I/O （ GAD 状态为：Mirroring ）：当 GAD 卷状态为正在镜像同步时， PVOL 的 I/O 模式为镜像， SVOL 的 I/O 模式为阻塞。写请求被写入两个对卷，然后写完成的反馈返回到服务器。因为 SVOL 的 I/O 模式是阻塞的，所以它不接受来自服务器的任何 I/O ，但是写入 PVOL 的数据也会由主存储系统同步写入 SVOL ，待 SVOL 写入完成反馈后，才反馈服务器写周期完成，因此本地主机的写 I/O 引入了 1 倍的跨站点往返时延，如下图所示。而远端主机在 SVOL 阻塞时，需要通过多路径跨站点访问 PVOL ，额外又引入了 1 倍的跨站点往返时延。

4 、主机读 I/O （ GAD 状态为：Mirroring ）：正在镜像的主从存储系统，从 SVOL 无法提供访问 I/O 服务，读取请求全部由 PVOL 提供，然后将读取结果反馈到主机。该场景下，主存储系统和从存储系统之间也没有任何通信发生。远端主机需要跨站点访问 PVOL ，引入 1 倍的跨站点往返时延。

5 、主机写 I/O （ GAD 状态为：Suspended ）：当 GAD 卷的状态为暂停时，并且 PVOL 上有最新的数据时， PVOL 的 I/O 模式为本地， SVOL 的模式为阻塞；当 SVOL 上有最新的数据时， PVOL 的 I/O 模式为阻塞， SVOL 的模式为本地。当 PVOL 上有最新的数据时，写入请求被写入 PVOL ，然后写入完成后反馈返回到主机，如下图所示。此时， SVOL 的 I/O 模式是阻塞的，因此它不接受来自服务器的 I/O ，而 PVOL 的 I/O 模式是又本地的，因此写入 PVOL 的数据也不会同步写入到 SVOL 。该状态下，本地主机是本地写，远端主机需要跨站点写，引入了 1 倍的跨站点往返时延， PVOL 和 SVOL 间的数据差异也将累积变大。

6 、主机读 I/O （ GAD 状态为：Suspended ）：当 GAD 卷的状态为暂停时，从 SVOL 无法提供访问 I/O 服务，读取请求全部由 PVOL 提供，然后将读取结果反馈到主机。该场景下，主存储系统和从存储系统之间没有任何通信发生。远端主机需要跨站点访问 PVOL ，引入 1 倍的跨站点往返时延。

7 、主机读写 I/O （ GAD 状态为：Blocked ）：当 GAD 状态为阻塞时， PVOL 和 SVOL 的 I/O 模式全部为阻塞。两个卷都不接受读 / 写处理，主机存储 I/O 中断。

8 、 HNAS+GAD 写 I/O ：如下图所示， HAS 的两个节点 Node1 与 Node2 组成一个 HAS 集群， HNAS 需结合 GAD 双活实现文件系统双活，且 HNAS 节点只有一个主节点提供文件系统读写，其写 I/O 步骤如下：

（ 1 ）本地 HNAS 客户端将 I/O 写入到本地 HNAS 节点的 NVRAM 中；

（ 2 ）本地 HNAS 节点将 NVRAM 中的写 I/O 镜像到远端 HNAS 节点的 NVRAM 中；

（ 3 ）远端 HNAS 节点反馈本地 HNAS 同步完成；

（ 4 ）本地 HNAS 反馈本地客户端写 I/O 完成，完成本次写 I/O 周期；

（ 5 ） 1-6 秒内，本地 HNAS 节点将 NVRAM 里的数据刷到本地后端 GAD 存储， HNAS 节点通过多路径优先选择 PVOL 下盘，实现本地直接下盘操作；

（ 6 ）本地存储通过 True Copy 同步将数据镜像到 SVOL ；

从整个 HNAS+GAD 写 I/O 流程来看，本地站点的 HNAS 客户端能够读写本地 HNAS 和底层 GAD 双活存储，且写 I/O 会引入 2 倍的跨站点往返时延， 1 倍为两个 HNAS 节点 NVRAM 镜像所引入， 1 倍为 PVOL 和 SVOL 的双写 I/O 所引入。而远端站点的 HNAS 客户端则需要跨站点访问 HNAS 节点，并下盘到 PVOL 所在存储，因此将引入 3 倍的跨站点往返时延。

五、 NetApp MetroCluster

1 、读 I/O ：针对数据读场景， NetApp MetroCluster 架构下，站点 A 的主机会优先从本地 Plex0 （ A_LOCAL ）中读数据，远端的 Plex1 （ A_REMOTE ）的读权限需要命令打开（切换场景），默认情况下，远端 Plex1 （ A_REMOTE ）不提供读业务；站点 B 的主机会优先从本地 Plex0 （ B_LOCAL ）中读数据，远端 Plex1 （ B_REMOTE ）默认时不提供读业务。如下图所示：

1、 写 I/O ：针对数据写场景， MetroCluster 使用 SyncMirror ，它可以对集群的两端进行同步写入。作为写入过程的一部分， NVRAM 还在集群互连上进行镜像，以确保不会丢失数据，并且所有写入都将提交到磁盘，以确保在中断期间不会丢失数据。由于该机制， MetroCluster 提供真正的同步写入。这两次写入均由一个控制器执行，它不会将写入传递给远程节点以在该站点执行写入。因此，可以理解为 NetApp MetroCluster 分以下两个同步动作分别实现两个站点控制器和后端存储阵列的写数据一致性：

（ 1 ）第一个同步动作是所有控制器的 NVRAM 数据同步。每个控制器的 NVRAM 都分成 4 个区域，当新请求写操作时，先写到本地 NVRAM ，再同步到本地 HA Pair 的 NVRAM ，以及远端的 DR Pair 的 NVRAM 后，返回成功。对本站点主机而言，同步 NVRAM 将引入 1 倍的跨站点往返时延，对于远端主机而言，远端相同的 Plex 不提供写业务，需要跨站点写至本地 NVRAM ，再同步至 HA/DR Pair 的 NVRAM 中，因此需额外再引入 1 倍的跨站点往返时延。

（ 2 ）第二个同步动作是通过 SyncMirror 在 NVRAM 日志下盘时，实现主从站点的盘的双写。SyncMirror 工作在 Aggregate 层上，镜像的 Aggregate 由 2 个 Plex 组成，来自本地 Pool0 的 Plex0 和远端的 Pool1 的 Plex1 。当有 NVRAM 日志开始刷盘时，写请求会同时写到本地的 Plex0 和远端的 Plex1, 两边同时写成功以后，返回成功。另外值得注意的是，控制器 NVRAM 下盘需通过独特的 FC-to-SAS 设备实现，带来了额外的协议转换开销，也影响了一定的性能，增加了时延。这是由于控制器与磁盘间，由于 SAS 后端存储不能拉远，为弥补该缺陷引入了新的协议转换设备，数据刷盘时会间接影响控制器一定的工作性能。

为了更好地了解 MetroCluster 如何将数据写入磁盘的整个工作原理。如下图所示中，列举出了写 I/O 请求进入站点 1 中的存储节点的整个步骤过程：

（ 1 ）本地站点主机发起写请求，并开始将数据写入本地控制器中；

（ 2 ）主机的写请求被写入控制器的 NVRAM 中；

（ 3 ）本地控制器将写 I/O 同步至远端集群互连的控制器 NVRAM ，以确保没有数据丢失，该方式由本地控制器驱动，而不是远端控制器驱动，提升了些许性能（第一个同步动作）；

（ 4 ）本地控制器确认 NVRAM 同步完成，反馈写入的主机写周期完成；

（ 5 ）一旦在本地控制器 NVRAM 中写入了足够多的块，并创建了数据一致性点，数据就会同时写入本地 Plex 中的本地卷和远程站点上的 Plex 镜像，待双刷盘动作完成时，将反馈本地控制器完成写同步（第二个同步动作）。

从整个 MetroCluster 方案的写 I/O 流程来看，当 NVRAM 缓存充足时，两个同步动作中，只有 NVRAM 同步过程会对主机写 I/O 性能产生影响（ 1 倍 RTT ），但两次同步也带来写数据需要在站点间同步 2 次、数据同步效率不高的影响，并且将占用更大网络带宽；当 NVRAM 缓存出现瓶颈时，两次同步的性能影响将被放大，造成主机写 I/O 2 倍 RTT 以上的性能影响。另外值得一提的是，本地两个 HA Pair 控制器间是走的外部 FC 网络（控制器拉开都是该方式），而不是两个控制器物理封装在一起时，通过高速 PCIE3.0 通道通讯，在极限并发时， FC 网络的带宽将被受考验。

双活数据中心解决方案指两个数据中心均处于运行状态，可以同时承担生产业务，以提高数据中心的整体服务能力和系统资源利用率，实现RPO（Recovery Point Objective），RTO（Recovery Time Objective）严苛的要求，将企业业务系统连续性提升至一个更高的台阶。

本文转载自微信公众号： talkwithtrend

目前，端到端双活数据中心解决方案中最核心的技术当属存储双活技术，这也是备受企业关注的双活技术之一，而现有关于存储双活的内容中，普遍都是对存储双活方案的整体概述，以厂商自带的产品为出发点来组织方案内容，很难对企业的存储双活项目实际落地提供有利支持，从而导致项目实施后，容易被厂商绑定。因此，在本次存储双活方案解析的内容中，笔者将从方案特点、第三站点仲裁、两地三中心扩展、读写性能、故障转移、双活能力等多个角度，公正客观地对业界主流存储双活方案进行整体性详细的解析和对比，涉及华为、EMC、IBM、HDS、NETAPP等五种不同存储厂商的存储双活方案，来帮助企业真正解决存储双活建设的落地难题。本文将从五种业界主流存储双活方案的方案特点展开解析。

一、华为HyperMetro

1、双活方案概述
华为存储层双活方案基于OceanStor融合存储系统的HyperMetro特性实现。HyperMetro采用AA双活架构将两套存储阵列组成跨站点集群，实现数据实时镜像。两端阵列的双活LUN数据实时同步，且两端能够同时处理应用服务器的I/O读写请求，面向应用服务器提供无差异的AA并行访问能力。当任何一台磁盘阵列故障时，业务自动无缝切换到对端存储访问，业务访问不中断。

2、方案特点
（1）免网关设计：Hyper Metro双活架构无需额外部署虚拟化网关设备，直接使用两套存储阵列组成跨站点集群系统。最大支持32个存储控制器，即两套16控存储阵列组建双活关系。

（2）I/O访问路径：Hyper Metro在应用主机侧，通过UltraPath主机多路径软件，将两台存储阵列上的双活成员LUN聚合为一个双活LUN，以多路径Vdisk方式对应用程序提供I/O读写能力。应用程序访问Vdisk时，Ultrapath根据多路径模式，选择最佳的访问路径，将I/O请求下发到存储阵列。

根据双活站点部署距离，Hyper Metro提供了两种I/O访问策略供选择。一是负载均衡模式：该模式下可实现 I/O的跨阵列负载均衡，即I/O以分片的方式在两个阵列上下发。分片大小可配，例如分片大小为128M，即起始地址为 0-128M的I/O在A阵列下发，128M-256M在B阵列下发，以此类推。负载均衡模式主要应用于双活业务部署在同一数据中心的场景。在该场景下，主机业务访问两套双活存储设备的性能几乎相同，为最大化利用两套存储设备的资源，将主机I/O按分片方式下发到两套阵列上。

另一种是优选阵列模式：该模式下，由用户在OceanStor UltraPath上指定优选访问阵列，主机业务访问时，I/O只会在用户设置的优选阵列路径上进行负载均衡下发，不产生跨阵列的 I/O 访问。只有当优选阵列出现故障时，才切换到非优选阵列下发 I/O。优选阵列模式主要应用于双活业务部署在距离较远的双数据中心场景。在该场景下，双活数据中心的跨站点访问的代价较高，假如两个数据中心的链路距离为100km，一次往返传输通常需要消耗约 1.3ms 时间。优选阵列模式可以减少跨站点交互次数，从而提升 I/O 性能。针对数据读场景，双活数据中心的业务主机只需要读本数据中心对应的双活存储阵列即可，避免主机跨数据中心读取数据，提升整体访问性能。针对数据写场景，业务主机直接写本数据中心对应的双活存储阵列，避免主机跨数据中心转发数据，充分利用 HyperMetro AA双活能力，AA集群的每个控制器都能够接收写 I/O，由本地控制器处理本地主机的写I/O请求，减少跨数据中心的转发次数，提升方案整体性能。

（3）存储层组网：下图为Hyper Metro双活方案典型组网架构。可搭建阵列与主机、双活镜像、同城互联等三类网络，数据网络与业务网络分离；两套双活存储阵列间通信支持FC或IP链路，推荐使用FC链路，但需满足站点间RTT（往返延迟）小于2ms要求。另外，存储阵列和仲裁服务器之间的链路采用普遍的IP链路。

（4）一体化双活：该方案下的一套双活设备既支持文件数据服务（File Service），也支持块数据服务（Block Service），能够以NFS文件系统和SAN块存储两种方式提供双活功能；SAN与NAS共用一套仲裁，能够确保两个站点间链路故障时，文件存储和块存储由同一站点提供服务，保障仲裁一致性；SAN与NAS共用一种网络，站点间心跳、配置、数据物理链路合一，一种网络即可满足SAN与NAS传输，并且支持业务网络、站点间网络、仲裁网络全IP部署，组网简单。

（5）存储层数据一致性：通过I/O双写确保数据一致性，系统正常情况下，任意应用IO数据下发，都要同时写到两台阵列才返回主机，确保两台阵列数据实时一致；具备分布式锁机制（DLM），确保主机对同一存储地址的数据访问时，由其中一台写入，确保数据一致性；单存储不可用时,具备数据差异处理机制，其中一台存储不可用时，仅写正常存储，同时数据变化记录到DCL（Data Change Log）空间，待阵列修复好后，HyperMetro 将自动恢复双活Pair关系，并通过DCL记录的信息，将数据增量写入修复好的存储。这样的好处是无需全量同步所有数据，整个过程对主机“透明”，不会影响主机业务。

（6）FastWrite技术：传统通用方案两个站点间的写I/O在传输过程要经历“写命令”和“写数据”两次交互，理论上两站点间距100KM时，将带来2次RTT（往返延时），见下图左；为了提升双写性能，FastWrite技术将“写命令”和“写数据”合并为一次发送，跨站点写IO交互次数减少一半，理论上100KM传输链路仅1次RTT，提升整体写IO性能，见下图右。

（7）跨站点坏块修复技术：为了提升数据可靠性，Hyper Metro具备跨站点自动修复坏块技术，无需人为干预，自动完成修复，业务访问不受影响。流程如下（见下图）: 生产主机读取存储A数据-->存储A通过校验发现坏块-->尝试通过重构修复坏块，修复失败（若修复成功，则不进行下述流程）-->存储A检查与远端状态“完整”并发起到远端B阵列读取数据-->读取数据成功，返回生产主机正确数据-->使用远端数据修复本端坏块对应的数据。

（8）RAID2.0技术：存储阵列能够支持多种RAID保护技术，并在此基础之上进一步优化升级，当RAID组中任意硬盘故障，通过RAID2.0技术，能够快速重建RAID，并恢复数据至热备盘，速度相对传统技术大幅提升， 降低了多盘失效风险概率。

二、EMC Vplex

1、双活方案概述
EMC Vplex存储双活方案是基于Vplex网关产品实现，能够将EMC和其他厂商存储异构整合，虚拟化为统一的存储资源池，实现异构存储双活。Vplex双活方案有Vplex Metro和Vplex Geo两种方案，方案由两个站点的两套Vplex集群系统组成，每个站点的Vplex集群都有自己专属的本地存储阵列，通过创建分布式镜像卷为跨集群的镜像卷，提供Vplex Access Anywhere功能，两个站点的Vplex集群各有一个卷，两个卷的ID一样。

2、方案特点
（1）集群配置：如下图所示，每个Vplex集群均包含Vplex Management Console，一个、两个、四个或八个引擎，每个引擎包含一个备用电源。Vplex Local用于使用单个Vplex集群管理数据中心内的数据移动和访问。支持单、双或四配置(分别包含一个、两个或四个引擎)，本地Vplex组成Local集群(4引擎8控制器)，两站点Local集群再组成Metro/Geo远程集群(最大8引擎，16控制器)，形成16个控制节点的AA集群。

（2）同/异步方案：如下图所示，Vplex Metro使用两个包含独特功能的Vplex集群，通过采用写直通缓存（透写）的方式在两个集群之间实时镜像数据，保持后端存储数据的一致性，由于采用实时同步复制，Vplex Metro方案需满足站点间RTT（往返延迟）小于5ms的要求。Vplex Geo用于两个远距离应用集群节点异步使用Access Anywhere访问存储数据，Vplex Geo分布式卷使用回写缓存的方式支持Access Anywhere分布式镜像，该方案最大可支持的站点间RTT（往返延迟）为50ms。另外，Vplex Metro和Vplex Geo方案下部署的集群不要求站点间引擎数量完全一致。

（3）存储层组网：下图为Vplex Metro双活方案主机跨集群连接组网架构。主机与Vplex集群间访问、Vplex集群与后端存储数据传输、Vplex集群间通信网络全部隔离，为保证最高级别的高可用性，每个Vplex Director前端I/O模块和一对SAN光纤交换机之间必须保证2个以上的物理连接，每个主机和每个Vplex引擎的A Director和B Director都需要保持一个以上的路径连接，因此主机和一个Vplex引擎间具有8条逻辑路径。对于每个站点2个、4个引擎的Vplex集群来说，主机连接需要覆盖所有引擎；另外，当主机与本地Vplex集群连接中断时，为保证主机能够跨站点访问另一端Vplex集群，主机需要和其他站点的Vplex集群建立连接，可通过PowerPath多路软件来配置ACTIVE/PASSIVE路径来保证主机优先访问本地的Vplex集群；后端存储阵列通过SAN交换机或者直接连接Vplex引擎的后端IO模块，不需要配置到其他Vplex集群的跨站点连接路径；根据需要选用Witness作仲裁，Witness需部署于两个Vplex集群不同的故障域中(第三方站点)，且只能部署于VMware的虚拟化环境，通过IP的方式连接到两个Vplex集群。

（4）分布式一致性缓存技术：EMC Vplex是一个集群系统，提供分布式缓存一致性保证，能够将两个或多个Vplex的缓存进行统一管理，从而使主机访问到一个整体的缓存系统。当主机向Vplex的一个缓存区域写I/O时，Vplex缓存将锁定这个缓存区域，同一时刻其他主机是无法向这个缓存区域写入I/O的。但是，当主机读取I/O时，Vplex缓存允许多个主机访问一个缓存区域，尤其是主机访问其他Vplex集群中其他Vplex节点所管理的数据时，统一缓存管理会将这个I/O的具体缓存位置告知主机，主机直接跨Vplex集群访问。分布式一致性缓存技术在实现上面，并没有强求所有的Cache都保持统一，而是基于卷缓存目录的形式来跟踪细小的内存块，并通过锁的粒度来保证数据一致性。每个引擎的cache分为本地Cache(Cache Local)和全局Cache(Cache Global)，每引擎的本地Cache只有26GB，其余为全局Cache，见下图。

5）分布式缓存模式：Vplex Local和Vplex Metro采用了写直通缓存模式，当Vplex集群的虚拟卷接收到了主机的写请求时，写I/O直接透写到该卷映射的后端存储LUN（Vplex Metro包含两套后端存储LUN）中，后端阵列确认写I/O完成后，Vplex将返回确认信号至主机，完成本次写I/O周期。写直通缓存模式需要等待后端存储阵列落盘完成，对写I/O时延要求较高。这种写直通缓存模式并适合Vplex Geo方案，该方案最大支持50ms的跨站点往返延迟，采用该缓存模式将对主机产生非常大的性能影响，对于大多数应用而言显然是无法接受的。因此，Vplex Geo采用了回写缓存模式，在该模式下，Vplex收到了主机的写请求后，直接写入引擎控制器的缓存，并将写I/O镜像至引擎另一个控制器和另一套Vplex集群的引擎控制器的内存中，然后向主机确认本次写I/O周期。最后再将数据异步转储到引擎后端的存储阵列中。当出现电源故障时，Vplex引擎自带的备用电源能够保证缓存中的所有未持久化的数据暂存到本地SSD存储上。回写缓存模式无需等待后端存储阵列落盘，即可回响应主机，大幅提升了Vplex双活方案的距离和时延要求。

（6）读I/O加速能力：具有读Cache，写I/O的机制能对读I/O实现加速。为了提升读I/O性能，写I/O的时候先判断是否在Local、Global Cache中有对应的旧数据，如没有直接写入本地Local Cache；如有旧数据，先废除旧数据再写入Local；再通过写直通缓存模式将写I/O刷入两套后端存储阵列（见下图）；最后反馈主机写I/O周期完成，同时Global Cache中的索引做相应修改，并在所有引擎上共享该信息，实现分布式缓存一致性。另外，Vplex该机制下的写I/O额外需增加2次跨站点往返延迟（官方宣称引入1-1.6ms延时），在Vplex Metro方案下，写直通缓存的基础上，额外又牺牲了一定写I/O性能。

读I/O的时候先读Local Cache，如命中直接读取，读I/O加速效果明显；如果在Global Cache中命中，则从对应的Vplex引擎Cache中将其读取到Local Cache，再反馈主机读I/O结果，读I/O加速效果次之；如果在Global Cache中没有命中，则从本地后端的存储阵列中读取到Local Cache中，并同时修改Local和Global Cache中的信息与索引信息，读I/O加速无效果。

（7）支持CDP技术：Vplex只提供存储异构虚拟化和镜像两项功能，快照、复制等特性需要添加EMC自身的RecoverPoint实现，所以Vplex的组网方式常常会考虑配合RecoverPoint一起使用。此外Vplex内部集成I/O分流软件，Vplex将每个主机写I/O同步复制到RecoverPoint，RecoverPoint将每个IO记录下来，采用CDP实现任意时间点恢复。下图为Vplex双活和Vplex双活+RecoverPoint CDP方案的写I/O流程对比，后者将增加写I/O时延，写I/O放大，影响一定的性能。

三、IBM SVC

1、双活方案概述
IBM在SVC存储双活技术上提供了两套不同的方案：Enhanced Stretch Cluster和HyperSwap，均是基于虚拟化存储平台之上的Active-Active数据中心的存储双活解决方案，为上层应用提供存储A-A双活或高可用架构，确保存储层的任一组件故障不会对上层应用产生中断影响。SVC Enhanced Stretch Cluster也就是SVC拉伸式集群架构，就是把同一SVC I/O Group内互为保护模式的双节点跨站点进行拉伸，分散在不同的两个数据中心，它们之间通过光纤链路连接，数据通过Vdisk Mirror技术实时镜像到两个站点上的两个存储上。SVC HyperSwap相较于SVC ESC，它出现的主要目的在于消除本地SVC节点单点隐患，增加主机存储冗余路径，进一步提升SVC双活的高可用性。通过Metro Mirror技术实现数据在两个I/O Group和两套存储之间的实时同步，同时解决单SVC节点故障引起的性能问题及双节点故障导致数据卷无法访问的问题。以上两种方案架构均为对称式架构，在第三站点可配置仲裁，以防止脑裂现象发生。

2、方案特点
（1）整体架构：SVC ESC采用Stretched的拓扑架构（下图一），每个站点最少1个节点，两个站点各1套存储，通过SVC VDM保持实时同步，对主机来说只看到一个Vdisk，主机与两个站点的SVC节点均建立连接路径，实现两个站点主机各自读写本地SVC节点和存储，达到存储Active-Active的目的，两个站点的存储网络通过DWDM间的裸光纤级联；SVC HyperSwap采用HyperSwap的拓扑架构（下图二），每个站点最少1个I/O Group，每个I/O Group配置两个SVC节点，提升了本地SVC节点的冗余度，两个站点各1套存储，通过SVC Metrol Mirror保持实时同步，对于不同站点的主机来说，看到的是不同的LUN，主机与跨站点的两个I/O Group均建立连接路径，提升了路径冗余度。

（2）光纤链路组网和仲裁：两种方案均可通过建立Private和Public两种FC网络进行访问隔离，Private网络用于两个SVC节点间或者两组SVC I/O Group Cache间的数据同步和心跳，Public网络用于主机与SVC节点间、SVC节点与存储间的数据传输，两个站点的FC存储网络通过两对跨站点DWDM（波分复用）间的裸光纤进行级联。仲裁方式上，支持仲裁盘和仲裁服务器两种模式，仲裁盘方式使用FC链路，仲裁服务器方式使用IP链路。

3）I/O访问路径：在SVC ESC方案下，主机需配置到本站点SVC节点和远端站点SVC节点的I/O路径，以保证在本站点节点出现故障时，主机路径可立即切换至远端站点，访问同一I/O Group下的其他SVC节点；而在SVC HyperSwap方案下，跨站点的主机访问节点路径属于可选配置，为避免站点所有存储路径失效（APD）场景下RTO过长，推荐配置跨站点的主机访问节点路径。主机端通过SDDPCM多路径软件，并配置基于ALUA的路径策略，来指明哪个SVC节点是主机的本地节点，避免主机跨站点访问其他SVC节点。当本地路径未全部失效时，主机将优先访问本站点SVC HyperSwap I/O Group的Preferred Node。当本地路径全部失效时，主机将跨站点访问远端SVC HyperSwap I/O Group，但基于ALUA的路径策略并不能识别远端哪个是SVC Preferred Node，因此ALUA策略将变为Round-Robin，轮询访问远端所有SVC节点的端口。

（4）SVC ESC站点感知功能：两个站点的所有对象均具备站点化属性，包括SVC节点、主机、存储等，淡化了SVC Local集群下的I/O Group Preferred Node概念，I/O Group中的两个节点均是平等的，两个站点的主机对同一Vdisk的访问，可通过同一I/O Group的两个SVC节点并行访问。即本地读I/O优化，本地写I/O优化，确保I/O本地化，避免远程I/O访问带来的性能影响。

（5）SVC ESC缓存机制特性：SVC每个节点包含若干容量的缓存，用于实时存放主机I/O数据，减轻了I/O物理落盘带来的性能影响。SVC放置于主机和存储之间，并没有因此加大主机对存储访问的I/O时延，SVC具有扩展低端存储缓存的效果，一定程度上增强了低端存储的性能；SVC ESC的I/O Group的某个节点故障，另一节点接管，写缓存Disable，进入写直通模式，性能略有下降（对比SVC HyperSwap在站点故障场景下，远端I/O Group仍有完整的写缓存保护机制，可避免直接进入写直通模式带来的性能下降）；SVC ESC的一个I/O Group，采用一套缓存表，所以能够实现写I/O的锁互斥机制，实现同一Vdisk的两个SVC节点和存储真正双活,并具有主机读写亲和性；当任意SVC节点的电源出现故障时，SVC内置的电池或者外置的UPS模块可持续供电，直至SVC节点内的缓存数据全部刷入后端存储阵列后，再关闭SVC节点。

（6）SVC HyperSwap主从卷机制：在建立好HyperSwap卷的关系后，两个站点的主机分别映射了Master卷和Aux卷，表示哪个卷正在作为主卷，提供所有I/O服务；具有Master卷的SVC I/O Group，两个站点所有的读写请求必须经过该I/O Group，若Master卷的I/O Group和主机在同一个站点,该站点的主机可以本地读写I/O Group和后端存储阵列。若Master卷的I/O Group和主机不在同一个站点，该站点的主机通过本站点的SVC I/O Group将请求转发至Master卷所在的I/O Group，由它来处理读写请求；HyperSwap会自动比较本地读写的I/O流量和读写转发的I/O流量，来决定是否反转Master和Aux的属性。I/O流量是指扇区的数量而不是I/O数量，在首次创建HyperSwap卷和初始化后，系统自动决定哪个卷为Master。如果连续10分钟以上，AUX卷的I/O流量（读写转发的I/O流量）大于所有I/O流量的75%，Master和Aux卷的属性将反转，通过该方式可避免频繁反转。综上特性，在HyperSwap主从卷的机制下，两个站点的主机可以实现本地I/O Group本地读写，但两套跨站点的存储为ACTVIE-STANDBY模式，Master卷所映射的后端存储阵列为主存储，Aux卷所映射的后端存储阵列为热备存储。

（7）SVC无缝卷迁移技术（NDVM）：能将虚拟卷迁移到不同的I/O Group，实现对节点故障做出迅速反应，将面临单点故障的虚拟卷进行批量自动化迁移，使不同I/O Group不再孤立存在于集群当中，形成多I/O Group之间的冗余保护（下图上、中），会对迁移操作的产生的各种风险进行智能分析，保证迁移过程安全可靠。该技术通过SVC中内置的一个轻量级的应用实现，部署简单，使用方便，系统开销小。另外，可以通过温备节点快速替换故障节点的方式，快速的将集群恢复正常状态（下图下）。

四、HDS GAD

1、双活方案概述
HDS VSP系列存储的Global-Active Device解决方案使用独特的Hitachi存储虚拟化操作系统（SVOS）实现，该方案在G系列（G1500、G1000、G800、G600、G400、G200）和F系列（F1500、F800、F600、F400）存储都得到了支持，能够实现全局存储虚拟化、分布式连续存储、零恢复时间和零恢复目标、简化的分布式系统设计和操作。全局存储虚拟化提供“全局活动卷”。这些存储卷能够在两个存储或站点对同一份数据的两个副本同时读取和写入。这种Active-Active的存储设计在Local或metro集群配置中允许两个存储系统同时运行生产工作负载，同时保持完整的数据一致性和保护。

2、方案特点
（1）I/O访问路径：如下图所示，GAD采用Active-Active架构，支持主从阵列同时读写，所有I/O写操作都是先写主LUN后写从LUN；通过原厂HDLM多路径软件来配置优选路径，可以支持本地优先读写策略，G1000之后版本支持ALUA功能，自动识别本地站点的优选路径，同时也兼容主流OS的第三方多路径；当本地路径全部故障时（APD场景），主机将通过StandBy路径继续跨站点访问远端存储。通常主从站点支持100KM距离，支持FC/IP复制链路，支持8条物理路径和阵列主机交叉组网。在VSP G1000、VSP G1500、VSP F1500之后的版本，最大支持500KM（RTT往返时延20ms）的SAN双活；最大支持32仲裁盘（存储或服务器磁盘），不支持虚拟机或物理机IP仲裁的方式。

（2）存储层组网：GAD的组网相对比较灵活，单机双阵列组网是用在数据中心内，只能实现存储层的双活能力，服务器主机是单点，只能防止存储故障，这种组网方式常用在不支持集群的应用中；双机双阵列组网是比较常见的组网方式，这种组网需要服务器安装集群软件，来实现业务的切换。这种组网在存储层和应用层都可以实现业务双活；交叉组网类似于双机双阵列组网方式，但在网络层实现了交叉冗余，这种方式是推荐的组网方式，也就是服务器都可以看到所有的存储，服务器同时采用集群软件和多路径软件来完成故障的切换，切换的方式更加合理，比如存储故障，服务器集群可以不切换，只需要多路径软件切换存储就可以了；下图为本地模拟跨站点的GAD组网拓扑图，主机访问存储网络、存储间镜像往返网络、主机跨站点存储访问网络、第三站点仲裁网络全部隔离。站点1的主机通过红色路径写站点1的VSP存储，通过站点间ISL的网络将镜像数据同步至站点2的VSP存储。站点2的主机通过蓝色路径写站点2的VSP存储，通过站点间另一对ISL网络将镜像数据同步至站点1的VSP存储。

（3）Virtual Storage Machine(VSM)：HDS在一台物理存储内允许用户按照业务和应用的要求定义多个VSM，VSM与一台存储类似，具备自己的存储ID、设备序列号和端口WWN。通过VSM的定义，能够有效提高存储资源利用率，并实现架构、业务灵活性最大化。VSP最大支持8个VSM，但可以支持63231对双活的GAD卷。HDS GAD技术通过设置SVM的方式使两台存储使用相同的虚拟序列号，让主机把两台物理存储(可能包含多个SVM)看成一台存储。在一台物理存储内允许用户按照业务和应用的要求定义多个VSM。VDKC是VSP上虚拟出来的一个虚拟控制器，它可以将多台存储底层的物理控制器虚拟成同一个控制器，这样主机通过虚拟控制器访问后端磁盘资源时，始终和一个控制器ID交互，无论后台存储如何变化主机都不会有感知，从而实现了双活等特性。

（4）微码实现数据一致性：HDS GAD基于微码实现双活，主机、交换机、存储整个I/O路径不需新增任何设备。HDS GAD技术在主机写I/O过程中不会增加任何的多余步骤，实现方式就是增强的同步复制技术TrueCopy，两边写I/O完成后才返回给主机，全程确保数据完整性，两台主机同时写同一个存储块时，HDS会对写存储块加锁，保证数据的一致性。主机读I/O通过多路径保持站点亲和性，从本地读。

5）HDS 3DC技术：HDS支持“双活+复制”的3DC模式，即HDS GAD+存储异步复制，并且支持SAN和NAS的3DC的三角增量复制。主站点和异地站点的异步复制通过日志方式记录数据差异，双活主从LUN都记录与容灾站点差异数据，差异记录开始时会对齐日志ID ，某个双活节点故障后，另一个节点继续与异地灾备站点继续复制，差量数据可通过查询日志ID获取。

（6）硬件实现支持快照和克隆：HDS的快照和克隆功能基于专用硬件实现，性能高，并且快照对主从节点都可见。

（7）HNAS+GAD双活：HDS通过HNAS网关配合VSP GAD来实现NAS双活，见下图，对外提供SAN块存储服务和NAS文件系统服务。但是NAS双活依赖SAN双活，HNAS目前支持2个HNAS网关集群绑定GAD组成拉远的Active-Passive双活。数据读写在主端完成，但是从端也可以通过配置Cache和CNS情况下，通过Cache支持部分读。整个HNAS文件系统数据保存在GAD双活设备上，HANS节点的主要工作是完成站点间元数据、状态和控制数据同步。

（8）HNAS+GAD双活组网：如下图所示，NAS集群NVRAM数据复制支持100KM 10GE组网，GAD主从站点宣称支持500公里FC组网，最多支持8条物理链路。HNAS节点与GAD支持交叉组网，在APD场景下仅切换I/O路径，不切换HNAS网关；NAS采用仲裁服务器模式，支持GE组网，SAN采用仲裁盘模式仲裁，主从站点与仲裁的连接采用FC链路，SAN和NAS采用独立的两套仲裁系统。网络复杂性上，HNAS需要独立的仲裁网络、管理网络、镜像网络和NAS服务访问接入网络，GAD也需要独立的仲裁网络、管理网络、数据镜像网络和SAN存储服务接入网络，一共需要8类网络，对网络接口需求多，架构和配置比较复杂。

五、NetApp MetroCluster

1、双活方案概述
Clustered Metro Cluster(简称MCC)是Netapp Data Ontap提供的存储双活解决方案，能够增强NetApp硬件和ONTAP存储软件的内置高可用性和无中断运行功能，为整个存储和主机环境提供一层额外保护。通过将1个FAS/V系列存储的双控，利用光纤或光纤交换机将控制器距离拉远，形成异地HA Pair，控制器间通过SyncMirror实现Aggr级别的数据镜像，存储镜像物理分离。为进一步提升本地控制器的冗余度，在本地和异地分别放置两个控制器，本地两个控制器组成一对HA Pair，本地和异地两对集群再形成四节点集群，互相保护。

2、方案特点
（1）存储层组网：Metro Cluster存储层组网非常复杂，主从站点支持300公里FC组网；SAN Cluster最大支持12控，NAS Cluster最大支持8控；在下图的4控制节点组网中，需要同时配置3种网络互联设备，6种网络类型，12套网络设备：包含4套FC-to-SAS转换设备、4套FC交换机、4套10GE交换机；引擎内双控间不支持PCI-E互联，需通过外部10GE/4GE以太网络互联；第三站点仲裁可选择IP链路，可以将TieBreaker仲裁软件直接安装Linux主机上。

Metro Cluster里面涉及几类数据同步，包括两个集群配置同步，NVRAM的日志同步，以及后端磁盘同步，系统里面这3类数据同步采用不同的网络。两集群配置同步网络：通过专用冗余TCP/IP网络，由CRS (Configuration Replication Service)服务实时同步两个集群的配置数据，确保集群一端修改的配置，如新增IP，SVM或者新增、删除用户共享等配置操作，能够自动同步到远端HA Pair集群；NVRAM日志同步网络：使用额外冗余的FC-VI集群适配器连接两个跨站点的主控，FC-VI支持RDMA，支持Qos等功能，用于两个集群间的NVRAM同步和心跳，既能保证心跳的优先级，同时又能减少数据的写I/O的传输次数，因为RDMA支持批量获取一组地址空间技术，批量获取一组地址以后，后面就直接传输数据，将FC协议2次写优化成接近1次；后端数据下盘双写网络：控制器与存储阵列间采用了独特的FC-to-SAS设备，控制器数据传输采用的是FC网络，而后端磁盘阵需要通过SAS进行连接组网，因此需要先进行FC和SAS转换(Fibre Bridge)，用指定思科和博科型号专用交换机连接两个站点控制器与后端磁盘，并完成协议转换。

（2）Metro Cluster集群：Metro Cluster每个控制器的NVRAM都分成4个区域，分别用于存取节点本地日志、HA Pair Partner日志、远端HA Pair Partner日志以及远端HA Pair auxiliary日志（用于切换）。当新请求写操作时，先写到本地，再同步到本地HA Pair的NVRAM，以及远端的DR Pair的NVRAM后，返回成功；当本地控制器故障以后，优先将业务切换到HA Pair节点上；控制器恢复以后，自动切换回来，只有当整个站点都故障时，业务才会切换到远端的站点运行。切换时间控制在120s以内完成，不影响上层业务。

（3）SyncMirror同步：SyncMirror是Netapp双活的核心数据同步技术，在NVRAM日志下盘时，实现主从站点的盘的双写。SyncMirror工作在Aggregate层上，镜像的Aggregate由2个Plex组成，来自本地Pool0的Plex0和远端的Pool1的Plex1。写流程：当有NVRAM日志开始刷盘时，写请求会同时写到本地的Plex0和远端的Plex1, 两边同时写成功以后，返回成功。读流程：数据会优先从本地Plex0读数据，远端的Plex1的读权限需要命令打开，默认情况下，远端Plex1不提供读业务。

Plex在站点内单边故障的时候，通过Aggregate的快照来进行增量恢复，默认Aggregate里面预留空间用于做Aggregate的快照，作为Aggregate重新同步的基准数据。如果没有做快照，一个Plex故障以后恢复，需要做全量同步。

（4）AP架构：NetApp MCC方案是基于磁盘镜像的架构，对上层应用只看到一个LUN/文件系统，通过镜像Aggregate实现双活，正常情况下，读从本地Plex读取数据，写会将数据同步到本地和远端两个Plex。无论是2节点还是4节点的MetroCluster集群，同一时刻，LUN/文件系统还是只能提供给组成集群HA Pair集群的一个节点，只有当这个节点故障以后，HA pair的Partner节点才会接管提供业务，或者当整个站点故障以后，从站点HA pair集群才会接管业务，站点切换可以通过手动执行CFOD命令或者通过TieBreak仲裁软件触发自动切换。因此从其本质上来说，为一套阵列的不同引擎间的双活，并非同一LUN的双活，因此仅仅是Active-Passive模式下的阵列双活。

（5）异构虚拟化：能够接管现网异构存储，但不支持FAS系列本地磁盘与异构存储间双活，支持相同厂商、相同型号，相同FirmWare的两套异构存储之间实现双活；接管异构存储时将破坏原来阵列数据，接管前需要将原阵列数据迁移至别处，接管之后将原来的数据迁移回来。

（6）丰富的增值特性：FAS全系列产品（FAS3240, FAS3210, and FAS3270 ,FAS2xxx除外 ）均支持MetroCluster，且无需单独license，产品基础包已包含该功能；能够同时支持SAN和NAS双活，实现块存储和文件存储一体化双活；其他增值功能支持SSD加速，快照，复制，数据压缩，精简配置，重删等特性。