深入剖析VIS/HyperMetro双活数据中心存储方案

      华为上一代双活解决方案是通过VIS(Virtual Intelligent Storage)产品实现，VIS是跟SVC非常相像的一个网关产品，可以通过异构虚拟化技术整合不同IP SAN、FC SAN异构存储资源并实现双活。VIS宣传可以支持最大2-16节点集群，跨站点的每个节点间都是Active Active工作模式，从而可以在一定程度避免IO Group带来的可靠性问题。VIS主要通过Stretched VCS集群(一个跨站点集群)和卷镜像功能实现双活，双活整体组网架构图如下。

      VIS产品软件架构(Storage Foundation)如下图所示。其中VxVM和VxDMP是平常在Linux系统中经常遇到的，VxVM是Linux最常用的卷管理软件之一，VxDMP也是兼容性极强的一款多路径软件，通过配置文件的方式支持存储设备；异构虚拟化功能以类Plug-in的方式支持几乎所有主流的企业级存储设备。

      VIS硬件则是采用华为自研的盘古平台，VIS双活方案链路由心跳链路、IP上层主机链路和双活FC数据链路组成，在距离比较近的同城数据中心之间可以采用交换机直连组网。

      当两个数据中心比较远时，就需要采用DWDM设备对光信号进行色散补偿和中继，看上去增加了额外的设备，但此时IP上层主机链路和双活FC数据链路的裸光纤就可以复用。

      关于双活距离，VIS实测Oracle数据库通常支持100km距离，VMware虚拟机支持300km距离(100km实测时延在1.3ms以内)，双活能支持的距离跟网络环境和上层应用对时延的TimeOut和敏感度有关，所以关于双活距离，每个厂商都只提供基于最佳实践的建议参考值。

      VCS集群通常采用3块本地磁盘实现，但在Stretched  VCS双活方案中，也是需要通过第三站点的存储来实现，第三方案仲裁阵列与生产中心之间的链路可采用iSCSI或FC组网方式。

      VIS卷镜像特性跟SVC的非常相似，把两个数据中心的LUN虚拟化成虚拟后向主机呈现成一个设备，主机的写IO会同时写到两个数据中心VIS节点Cache，然后再返回主机，从而保证数据一致性。主机的读IO支持轮循和优先2种可配模式，轮循模式对非顺序IO，使用轮循模式可以实现负载分担，有效的提高了卷的读性能；优先模式则首先从设置为优先的镜像盘进行读取，适用于有明显性能优势的阵列。

      如上图所示，在每个数据中心的镜像卷都会对应一个差一位图卷，当存储、链路等故障发生时，它主要用来记录数据中心之间卷镜像的数据差异，当故障回复后，系统就可以利用差异记录来自动同步有差异的数据。

      由于VIS的所有节点都是ActiveActive模式，当数据中心A中的VIS节点故障，数据中心A中的服务器可以直接由数据中心B的VIS节点在两个数据中心分别写入，实现数据镜像。当数据中心A中的存储故障后，可以通过数据中心A的VIS节点直接把数据写入数据中心B中的存储，不需要转发给数据中心B的VIS节点协助完成，更不需要进行数据中心节点切换。

      VIS和SVC这类存储网关双活可以屏蔽底层存储设备，让不支持双活或增值特性不足的老旧享受存储双活服务，但网关双活也存在一些明显技术和组网等方面的不足，如引入网关就意味着增加设备成本，引入更多的网络故障点；同时随着IO路径的增长，也增加了网络开销和时延。所以近几年存储双活变得越来越流行和普遍，华为最新的双活方案已经从网关切换到自研的HyperMetro方案了。

      HyperMetro是V3/Dorado V3基于存储阵列实现的Active Active双活，两套独立存储阵列组建成跨站点集群，通过UltraPath多路径软件将两台存储阵列上的双活成员LUN聚合为一个双活LUN(两套存储阵列上的双活成员LUN组成一个虚拟双活LUN)，两端阵列的双活成员LUN数据实时同步且同时可读写(真正的Active Active)双活。

      服务器两端能够同时处理应用服务器的I/O读写请求，双活LUN空间上接收到I/O请求后，对于读I/O请求，直接读本地Cache空间，将数据返回应用程序；对于写I/O请求，首先会通过分布式锁技术进行并行访问互斥，获取写权限后，将I/O同时写本地双活成员LUN Cache以及对端的双活成员 LUN Cache，双端写成功后再返回应用程序。

      分布式互斥能力是实现A/A双活的关键能力之一，双活分布式锁模块利用Paxos和CHT(Consistent Hash Table)一致性算法，提供了分布式对象锁和分布式范围锁，从而满足A/A双活的分布式互斥诉求。HyperMetro以主机I/O粒度，对主机I/O访问的LBA区间加分布式范围锁进行并发互斥，从而达到双向实时同步的目的，该方案可省去不必要的阵列间数据传输带宽，并有效的减少数据传输次数。

       在数据写入时，如果站点间的镜像复制链路发生故障或闪断，日志就会临时记录数据差异，故障回复后就可以根据日志差异把数据同步到对端存储，日志在双活中是非常重要的。假如数据中心A阵列收到写I/O，HyperMetro镜像处理流程如下。

• 1. 申请写权限和记录写日志：数据中心A阵列收到主机写请求，先申请双活Pair的写权限。通过锁机制获得写权限后，双活Pair将该请求记录写日志(记录IO同步差异)。日志中只记录地址信息，不记录具体的写数据内容。该日志采用具有掉电保护能力的内存空间记录以获得良好的性能。

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

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

• 4. 响应主机：双活Pair返回写I/O操作完成。

      下面展示了Hypermetro双活方案典型组网架构。两套双活存储阵列间通信支持FC或IP链路，推荐使用FC链路。另外，存储阵列和仲裁服务器之间的链路采用普遍的IP链路。

      关于仲裁机制，HyperMetro支持按双活Pair或双活一致性组为单位进行仲裁。提供了静态优先级和仲裁服务器两种仲裁模式，静态优先级模式主要应用在无第三方仲裁服务器的场景，一般不建议采用；独立的物理服务器或者虚拟机作为仲裁设备时，建议部署在第三方站点。这样可以避免单数据中心整体发生灾难时，仲裁设备也同时故障。

      HyperMetro在网络上也做了相应优化。正常的SCSI流程中，写I/O在传输的双端要经历“写命令”、“写分配完成”、“写数据”和“写执行状态”等多次交互。

      利用FastWrite功能优化写I/O交互过程，将“写命令”和“写数据”合并为一次发送，并取消“写分配完成”交互过程，应用SCSI 协议的First Burst Enabled功能，将写数据的链路传输交互次数减少一半，SVC也采用了比较相似的技术。

      在双活数据业务场景，两站点的距离也是影响I/O访问性能的关键因素。HyperMetro与UltraPath多路径配合，根据双活站点部署距离提供了负载均衡和优选阵列两种I/O访问策略。优先级阵列策略一般用在不同数据中心，业界主流双活方案普遍支持这种方式。

      负载均衡模式主要应用于双活业务部署在同一数据中心的场景。在该场景下，主机业务访问两套双活存储设备的性能几乎相同，为最大化利用两套存储设备的资源，将主机I/O按分片方式下发到两套阵列上。

      负载均衡模式下实现了I/O的跨阵列负载均衡，即I/O以分片的方式在两个阵列上下发。分片大小可配，例如分片大小为128M，即起始地址为0-128M的I/O在A阵列下发，128M-256M在B阵列下发。

      

      简单总结下HyperMetro双活方案。NAS双活方案也有存储双活和NAS网关双活两种。大多数基于网关实现，HyperMetro和NetApp是属于存储NAS双活，这跟NAS和SAN是否为统一架构有一定的关系。HyperMetro也支持异构虚拟化特性，可以接管客户现网设备，基于HyperMetro双活提升设备的可靠性。但是需要专门的UltraPath多路径软件配合，缺乏SVC双活方案那样灵活和普适性。

      存储双活也分Active Passive和Active Active双活，我个人觉得Active Active也只是针对一个业务(同一个LUN)能否在两个数据中心同时读写而言的，这种情况也要应用层支持Active Active集群才有意义；如果站在存储系统来看，双活系统同时承载不同业务的情况下，不同业务在数据中心间互为Active Passive，整个双活方案的两套存储都向外提供业务，其表现也是“Active Active”双活。

温馨提示：
请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。

听说点赞和分享的朋友都已走上人生巅峰