深入剖析HPE、Dell和Fujitsu双活数据中心存储方案
HPE 3PAR存储有个非常有用的特性叫Storage Federation(存储联邦)，存储联邦特性主要解决多个存储数据敏捷性和流动性，主要包括Peer Motion、Online Import 和 Peer Persistence三个特性，Peer Motion和Online Import都不支持带增值特性的LUN迁移。而Peer Persistence就是3PAR非对称Active Passive双活方案，其组网方式和系统架构如下。
Peer Motion是在多台设备组成一个联邦的基础上，实现资源可以自由移动，支持迁移映射给某个主机的所有LUN，也支持迁移某个LUN映射的所有主机。这样让存储系统不会成为信息的孤岛，应用可以根据需要随时在不同的系统中迁移。PeerMotion支持在3PAR StoreServ存储之间在线非中断Online迁移和Offline数据迁移，数据迁移操作不需要依赖额外的迁移设备，并且支持双向数据流动。
Online Import也是基于Peer Motion实现企业可无中断地将活动数据从现有的EMC VMAX，EMC VNX， EMC CLARiiON CX4，HDS NSC，HDS USP，HDS VSP、IBM XIV Gen2或IBM XiV Gen3等异构主流存储(不仅包括EVA和3PAR系统)在线迁移至新的3PAR StoreServ，支持一致性组迁移。
3PAR除了Peer Persistence(Storage Federation的一个特性)外，还提供了其他几个Persistent特性。Persistent Cache在3PAR StoreServ多控的情况下，如控制器故障可以实现写其Cache重新镜像到其他控制器，保证写缓存不丢失，保证系统的性能。Persistent Ports可以在升级或者维护控制器节点的时候，对主机进行屏蔽，把主机I/O重定向到另个一个控制器节点，主机无需用多路径切换，而且还可以检查端口信号，实现快速端口替换。
Persistent Checksum是对闪存更重要的一个特性，它是采用标准的SCSI T10 PI规范实现数据端到端一致性，防止静态数据损坏的。因为闪存是电子器件，容易受到宇宙射线的影响发生电位翻转和数据静默破坏。
接下来重点讨论下HP 3PAR Peer Persistence，它是一个基于存储双活的扩展集群，在企业数据中心内部或之间进行透明服务器故障切换，从而保持企业用户业务连续性.。对比IBM SVC和EMC VPlex产品优势在于存储本身自带特性，不需要购买虚拟化网关，减少维护和设备采购成本，劣势在于设备必须是相同存储设备(不过目前基于存储的双活都是基于同构产品实现)。
3PAR Peer Persistence是 Active Passive存储双活(同一个双活卷只能在主端同时进行读写)。下面我们以Oracle RAC应用为例对其做一个分析，应用层基于Oracle RAC集群组网，存储通过Peer Persistence组网，数据中心通过FC网络相连。数据中心间组网方式和网络要求跟前期讨论的其他双活技术一样。
Oracle RAC向外提供服务，并通过服务器集群应对可能的物理设备故障，还实现了负载均衡分配；存储双活部分由3par存储和SAN网络交换机以及运行在虚拟机之上的仲裁服务器构成，存储空间通过peer persistence展现给服务器和Oracle RAC软件。与其他存储双活方案一样，3par Peer Persistence通过仲裁机制防止脑裂问题。那么它为什么它不是Active Active双活呢？
这就需要通过IO处理流程来进行分析了，在ActiveActive双活的虚拟磁盘阵列中，主机会把IO根据一定的（比如本地存储优先）策略发送到两个磁盘阵列中去。一个LUN在两个磁盘阵列的双活镜像卷中可以同时处理主机发来的IO，没有主从的区别。Active Active双活LUN在两个阵列上的镜像都可以处理主机IO，它们的WWN是一样的，或通过卷镜像功能向主机呈现一个虚拟卷。
3par Peer Persistence设置的LUN存储有主从区别，主机来的IO都会先到主存储，再由主存储同步到从存储。对于主机，存储路径的管理和切换，通过ALUA协议来实现。下面这张图显示了两者在IO路径上的不同，两条黄色IO路径在正常状态下是非激活状态且没有IO流过；但对于Active Active双活则不然，两条黄色路径处于激活状态，分担部分绿色路径上的IO。
也就是说3par的Peer Persistence没有了黄色路径，那么3PAR又是如何管理主备阵列的呢？它通过多路径的ALUA(异步逻辑单元访问)协议把主阵列设置为主动、优化(Active/Optimized）状态，把从阵列设置为主动、非优化 (Active/Unoptimized) 状态。这样主机自然把IO优先都发送到主阵列上去了。当主阵列出现故障时，Peer Persistence又会反过来把从阵列设置为主动、优化(Active/ Optimized)状态，把主阵列设置为主动、非优化(Active/ Unoptimized)状态。
至此，是否可以说Active Active的双活是否一定优于3par的Peer Persistence双活呢？表面上看是的，由于ActiveActive双活模式下，两个阵列同时处于激活状态且都能接收处理主机IO，均衡负载。切换会很快，理论上主机软件无感知。
如果我们作更深入的分析，针对存储切换速度问题，在正常情况下的手工切换，Active Active双活和Active Passive双活切换速度都非常快，业务应用软件不会有感知。
在正常情况下的自动切换，在使用了远端仲裁服务器仲裁的情况下，在文件拷贝操作试验中，拷贝操作暂停了2—5秒的时间，然后继续进行，操作没有中断。这个延时是由仲裁服务器需要对两个存储状态进行判定必须的代价。所有仲裁服务器为了防止误判，都会需要一段时间延时来判定存储状态。Active Active双活也不例外。
针对均衡负载问题，虽然Active Active双活中，两个阵列可以同时处理主机IO，但是为了保持数据一致，这些IO中的写操作必须同步到另外一个阵列上。也就是说上图中的第2和第3步骤无法节省。只有第1和第4步骤节省了传输时间。但是，双活因为复杂的锁机制带来了阵列内部软件处理时延。这个时延是否能够抵消第1和第4步骤的传输时间节省，还需要是视情况而定。还有一点需要特别注意的是随着系统负荷增长，IO流量越大，处理时延越长。
正如前面双活系列中，我所提到的，一个阵列上往往存有多个应用的数据，把这些应用数据分组，分别设置不同主存储可以达到手工负载均衡的效果，站在整个存储系统层面来看，Peer Persistence也可以针对不同业务在两个存储系统上提供存储业务，对外体现出“Active Active”双活。通常一个应用的多个数据LUN必须设置到一个一致性组里面，保证数据在同步和切换过程中保持一致性。
除了Peer Persistence外，富士通的ENTERNUS DX S3和Dell 的SC系列存储也支持 Active Passive双活，相比之下，富士通和Dell在仲裁机制上并不完备，下面简单讨论下Live Volume和Storage Cluster。
Live Volume是两套Dell SC系列存储基于同步复制内置功能提供的Active Passive双活解决方案功能，两台存储上的Live volume卷将使用相同的设备ID，通过主机上的多路径在完成对设备的封装后，变成一个卷，这个卷同时有到主存储和备存储的路径。一旦主存储发生故障，主机上的IO只是发生路径的切换，整个切换过程应用不会中断，保障业务的连续运行。
Live Volume的复制的链路可以是FC或者是iSCSI。通过Tiebreaker实现第三站点的仲裁。双活实现的原理跟Peer Persistence很类似，通过操作系统多路径软件实现IO选路算法，优先写到Primary LiveVolume里。但如果没有直接的路径到主卷，那么就写到Secondary LiveVolume里，从卷这个时候就是一个Proxy代理，把写请求转发给主卷(通过复制链路)。
这种实现方式比较简单，因为实际上只有主阵列真正去写存储，无需解决锁的问题。但这种方式下从站写I/O不能就近落盘，而需要多一次远程转发。
Storage Cluster 是富士通ENTERNUS DX S3/S4系列存储的双活功能，作为存储集群的一个选项，基于Transparent Failover Volumes (TFOV)进行设置，该特性目前只支持富士通最新的ETERNUS DX S3/S4硬件平台。
目前Storage Cluster Option支持FC链路，需要2台ENTERNUS DX S3/S4的阵列作为主备存储，2台博科的FC交换机，阵列与仲裁之间采用IP网络互联，另外还需要一个Storage Cluster Controller(可以是一个服务器或者虚拟机)来负责监控集群和控制集群的切换，共同完成仲裁机制。ENTERNUSSF软件用来基于TFO(一致性组)，TFOV，Copy组和REC(Remote Mirroring)对来设置优先阵列。Storage Cluster Controller和ENTERNUS SF软件可以部署在一起或单独部署在不同服务器。
在实现原理上就是两台阵列通过同步复制技术来进行数据同步，主存储和从存储采用Channel adapter (CA)进行控制，CA Pair拥有相同的WWPN/WWNN和端口地址，正常情况下，主存储的端口状态处于Link UP状态，从存储的端口状态为Link Down状态；所以IO都是通过主存储来处理，存储端口的状态由Storage Cluster来控制。故障切换的原理是CA端口组共享WWPN/ WWNN来实现，由于对外统一呈现的是逻辑端口信息，所以存储内部端口和阵列切换不会影响主机访问。
当主存储发生故障时，Storage Cluster就会进行故障切换，并把IO转到从存储下发，具体过程如上图所示。
-
首先通过服务发送IO请求到主存储，
-
主存储的CA端口不会相应IO，Storage Cluster Controller将检测到主存储故障并把故障报告给ETERNUS SF。
-
当IO超时后会在主机上进行重试，
-
ETERNUS SF挂起主存储到从存储的REC会话，使得复制链路成为切换后的实际业务数据链路，
-
从存储的CA端口别激活成为Link Up状态，并成为主的CA端口
-
主机IO从从端存储进行处理，应用继续运行，整个切换过程大概需要3秒钟左右。
温馨提示：
请搜索“ICT_Architect”或“扫一扫”下面二维码关注公众号，获取更多精彩内容。
阅读量又能说明什么
只专注做一个有情怀的技术分享平台
