本文分为三个部分来介绍，第一个部分主要介绍市场上常见的存储容灾技术和规划的实现方案; 第二个部分以V7000容灾实现的案例，介绍我们在做存储选型的时候需要关注的层面，第三个部分将介绍关于存储容灾的自动化实现的实践案例。

1 存储容灾技术和规划介绍

在今年6月11号，AIX专家俱乐部举办了一次大规模的线上讨论，主题为数据中心的双活实现，提出了很多数据中心双活架构的实现方案。个人认为存储容灾的实现主要包含两大类，一类是双活，另一类是存储底层的卷复制技术。在双活的实现方案里，部分企业会从应用层实现，或者从数据库层面实现，比如数据库层面IBM的DB2 GPFS+GDPC架构，Oracle Golden Gate架构，今天主要谈怎么在存储层实现双活，都有哪些存储双活技术可供选择。

1.1 双活技术

第一类容灾技术是存储间双活，各大厂商都有相关的存储又少产品，例如IBM SVC系列产品，联想公司曾经有一个超大的SVC集群，大部分IBM存储通过SVC映射给主机，好处是实现存储的虚拟化集中管理。IBM近两年另外还有一个较新的技术，逐渐在市场上得到推广，采用PowerHA+Hyperswap+DS8000的架构实现存储的快速切换，严格意义上的，这种技术可能不算是一种双活，而且对存储和系统软件版本要求较高，但发生灾难时，存储切换的时间非常短，且不需要人工干预，在国内一些中小银行系统中，已经逐渐开始尝试这种架构。另外EMC有vplex存储双活技术，我行最近也在做vplex相关的功能和性能测试，环境主要基于vmware+vnx5500的基础上搭建，测试结果表明vplex可以实现较大程度实现存储间的双活，一般来说，如果一个存储宕机，切换时间在十几秒到几十秒之间。还有一个工程师关心的问题是，在vplex双活实现机制上，在vplex层是否存在单点问题，我们测试的结论是，必须要加入第三方站点作为witness节点，witness在一台vplex出现故障时能够选举另一台vplex作为winner节点，这样就能保证在一个vplex站点出现故障时，存储能够完全切换到另一个站点。Vplex使用时另外一个需要注意的问题是一致性组规划的问题，要求根据业务的特点来规划一致性组，作为vplex技术存储切换的基本单位，管理员需要根据应用的特点来规划一致性组的设计，从而实现vplex间的负载均衡。另外类似的还有华为vis技术，netapp的metrocluster技术，都可以实现存储的双活。

1.2 存储卷复制技术

第二类容灾技术是存储的卷复制技术，大部分企业都会广泛用到相关的技术，比如IBM DS8000的pprc容灾技术，EMC VMAX的SRDF技术，HDS的True copy/Universal replicator技术。在中端存储领域，也有EMC VNX系列存储mirrorview容灾方式，同时IBM V7000系列有对应的Metro Mirror/GloabalMirror技术。面对如此多样的存储容灾技术，我们怎样根据企业自身的业务特点，选择一款符合企业自身需求的存储容灾方式呢，在下面的章节中将会谈到该问题。

2 存储容灾技术选型

2.1 技术选型的考虑因素

首先，怎么样去选择一款容灾技术呢，个人觉得需要从以下几个方面去考虑。

1. 首先是企业的业务特点，业务部门，或者监管部门对企业提出的具体需求是什么，RTO/RPO的技术需要满足什么样的值，这些是硬性的规定，尤其是对银行保险等金融行业来说，数据的重要性不容忽视。
2. 其次是业务的关联程度，用于容灾的业务系统间的关系如何，数据的耦合性高低程度如何，对于数据耦合性高的系统之间，在设计存储容灾时，即使对于存储性能的要求不一样，在设计容灾也不能进行分离，以避免在做存储批量切换时出现问题。对于耦合性低的业务系统之间，则可以根据业务特点结合成本选取不同的容灾方式。
3. 第三点需要考虑的是当前系统的环境，当前系统每天产生的数据量有多少，对于IOPS的要求是多少，每天需要消耗的存储空间有多少。
4. 第四点容灾技术当前的市场成熟度，某项容灾技术可能在实验室经过多轮的测试，但进入市场的时间相对较短，如果没有在大量客户环境中使用，某些潜在问题不会凸显出来，不能保证满足业务容灾的需求，需要提前调研该项容灾技术的使用客户和已知问题，全面考虑容灾技术的优缺点。
5. 第五点是企业当前的容灾环境，企业内部的生产中心和数据容灾中心这两个中心之间的距离是多少，租赁带宽为多少，链路质量如何，另外还需要考虑到已有设备的情况，比如交换机是支持万兆还是千兆等，以确定能满足某些容灾技术的带宽要求。
6. 最后是大家都会考虑到的成本问题，存储硬件和软件的采购，licence的采购，后期维护成本，人员实施和培训成本，这些都需要综合考虑，最终权衡决定一款性价比比较高的容灾技术。

2.2 V7000的特点和容灾特性

我行之前采购了几套v7000的系统，当时考虑的因素主要有以下几点，一是主机和存储的兼容性，因为虽然是行内的核心系统，业务相对重要，但是AIX操作系统的版本较低，因此采购一款中端IBM存储，与低版本的AIX之间能够保持更稳定的兼容性。第二方面是考虑到V7000作为一款中端存储，性能足以应对当前业务的需求，同时V7000的在线卷迁移技术，能够满足我们的业务系统数据从旧存储到目标存储的平滑过渡。同时V7000的MetroMirror容灾技术也能够满足我们的数据高可用需求。

实际上V7000作为中端存储而言，它是一款采众家之长的存储:

1. 首先它的源代码部分很多是来自于SVC的技术，这使得v7000可以支持SVC的集群架构。
2. 其次V7000它可以方便用户的管理，用过V7000的用户都了解V7000图形界面操作的简洁易用性，该界面来自于IBM的另一款网格存储XIV,对于用户来说十分友好。
3. 第三是V7000也引进了在DS8000存储上用到的easy tier存储自动分层技术，能够实现常用数据的快速读取。
4. 在新版的V7000存储中，也开始支持NAS存储，V7000还引入了最新的GPFS Active Cloud Engine技术，同时它还可以实现过期文件的自动处理。
5. 在V7000的其它特性上，比如精简配置，快照，存储在线迁移这些功能，都免费提供给用户。
6. 在容灾特性方面，我们都了解V7000所支持的metromirror,只要距离在300km以内，都可以实现同步的metromirror,对于global mirror异步复制来说，只要距离在4000km以下，延迟在80ms以内，便能满足异步复制的要求。
7. V7000同时也能够做到intracluster集群内部的卷复制，不仅如此，一台v7000还可以同时建立与其它三台v7000的伙伴关系，同时实现一台存储向多台存储数据的复制拷贝。

不过，v7000的限制也比较明显，v7000在不借助其它软件和产品的情况下，不太适合于两地三中心的容灾建设，同时对于大型企业的核心系统而言，v7000仍有自身的性能瓶颈。

2.3 V7000容灾设计案例

用V7000通常会采用一种什么样的容灾架构，下面举两个简单的v7000容灾实现案例。

2.3.1 MM+FlashCopy架构

这种方式是Metromirror+flashcopy的方式，具体实现方式为，在生产存储端创建一份MetroMirror的源卷，在目标存储端创建一份MetroMirrror的目标卷，在目标存储上再创建一份目标卷的flashcopy. 这种架构决定了在做容灾数据验证的时候，有三种方式可以进行验证。

1. 第一种方式为在不停生产业务同时也不停止同步复制关系时，在目标端对目标卷做一份flashcopy, 将flashcopy卷挂载到测试区域进行业务数据验证。
2. 第二种方式为，在不停止生产业务的情况下，断开metromirror的复制关系，在灾备区域挂载目标卷，在灾备区域进行验证，适用于二层网络没有打通的情况。
3. 第三种方式是真实的切换，把生产网络从生产切换到灾备，让灾备承担生产的业务，从而实现整个灾备切换的流程。

这种典型架构在许多客户环境中都会用到。

2.3.2 MM+SVC架构

第二种架构是我行目前采用的一种架构，利用SVC和V7000相结合，我们根据业务的特点，把业务系统数据分成两部分，一部分是对于业务连续性要求高的业务，一部分是对于业务连续性要求低的业务。对业务连续性要求高的存储空间，我们将其存储卷映射给SVC，通过SVC映射给主机，将两台存储同时映射给SVC的卷形成镜像，实现SVC层的双活。对业务连续性相对较低的业务，采用v7000的MetroMirror同步技术，这种方式好处在于，通过对业务进行分层处理，保证了关键业务的稳定运行，同时通过在SVC上设置数据读取的prefer节点可以减轻v7000的IO压力，比如将灾备的V7000设置成读的prefer节点，这样灾备V7000就很好的分担了生产端的IO。

这样的设计方式使得在做灾备数据验证时，需要同时采用两种方式，一种为V7000 MetroMirror的正常切换流程，对于SVC部分的验证，可以采用禁用端口的方式，即将prefer存储节点连接到SVC的交换机端口禁用，验证业务是否受到影响，这样便可以验证灾备数据是否有效，设计体系是否成功。

对于V7000的容灾，我们在做灾备切换时，也可能会遇到一些问题。

1. 有时候遇到存储的IO性能极其缓慢的问题，那么对于这样的容灾环境而言，需要排查问题的环节会很多，因为容灾涉及到的设备和链路很多，包括类似dwdm的波分设备，运营商链路等，这些都需要考虑到，因为是需要各个部门协同解决的问题。
2. 另一个问题是，如果采用异步复制这种容灾方式，在生产端，数据在短时间内发生了大量的变化，类似于GPFS的restripe，以及数据库还原等操作，这样引起生产端数据在短时间内发生大量的变化，导致不能通过异步传输的方式将改变的数据在短时间内传送到目标端存储，这样在目标端存储上，为了保持数据的可用性，就需要保存一份上一个时间点snapshot的数据备份，这份snapshot可能消耗很大的存储空间，此时可能导致目标端存储池被撑满，所以如果有异步复制这种关系存在，需要特别注意在目标端存储的pool的使用空间，如果pool使用率超过80%，则需要立即扩容。
3. 第三个问题是，在平常做V7000的容灾切换时，如果由于流程的设计失误或者操作失误可能会引起一些未知的问题，比如说，有时候会出现在做容灾演练时，灾备端文件系统mount不上的情况，这时候可能是因为之前在断开MetroMirror关系时，存储上执行失败，因为目标端存储为只读状态，vg可以激活，但文件系统无法挂载。

所以，有时候遇到的一些问题，是由于我们的操作失误或者检查不完全导致，这时候，有没有一种方式可以尽量避免操作失误，这是我们下一部分将要讨论的内容，怎么建立存储灾备切换的自动化体系。

3 容灾切换的自动化建设

3.1 容灾切换自动化建设的必要性

为什么要实现存储灾备切换的自动化呢？首先，每个系统或存储管理员都有经验，容灾切换的文档动辙几十页，其中涉及到很多复杂的操作，容灾演练的时间一般是晚上，面对大量的繁冗操作，很难保持清醒的头脑，因此也很难避免操作上的失误。实际上，我个人做客户支持的过程中发现，许多的错误完全可以通过细心谨慎来规避，也就是说很多的错误实际上是由于人为的操作失误和疏忽导致的。另外一个自动化实现的出发点是，针对目前主流的存储容灾技术来讲，由于涉及到存储的切换和主机端的重新挂载，RTO的时间会很高，如果说我们能有一套这样的体系来实现自动化切换，对于容灾体系的建设来说，可以大大缩短RTO的时间。

3.2 自动化实现方案3.2 自动化实现方案

在自动化软件实现这方面，目前也有很多的软件和产品来帮助我们实现，比如IBM的tivoli system automation, 能帮助实现DB2层面自动化切换，比如HP的OO平台，即operations orchestration工具，也可以帮助我们企业来开发自己的工具，autowitch等常用于中小企业，另外还有半自动化的工具，比如华为Oceanstor replication director, 可以安装插件来实现在服务器上的自动化操作。对于很多的银行来说，自动化的工作多为自主开发，是基于某些半成品基础上所做的开发。

那么我们怎样设计一款自己的自动化切换工具呢？一般自动化的实现包括几部分，第一部分是主机操作自动化实现，包括双机起停，卷组激活，文件系统挂载等，第二部分是应用起停自动化，第三部分是存储灾备切换自动化，我们主要关注第三部分的实现。

怎样去搭建一个适合企业自身的自动化切换平台？主要从以下几个方面考虑。

首先必须全面梳理SAN环境。在SAN环境中可能涉及到多款存储，不同的存储需要借助不同的工具来实现灾备切换，例如DS8000可以借助TPC-R管理软件，它安装在一台windows中转机上，例如EMC SRDF的切换，需要借助solution enabler, 所以在规划自动化实现之前，必须指定一台或多台专门的主机去统一控制各个存储，我们把这台主机叫做存储控制机，保证这台控制机能够通过命令行的方式来控制存储，并实现存储的灾备切换。

另外还必须要规范切换场景，切换场景包括不发生实际切换动作的桌面演练切换，计划内的切换和计划外（模拟真实灾难发生）的切换等。针对每一个场景而言，需要去规范这个场景里面所包含的所有的原子步骤，比如说，做一个容灾数据的验证，在EMC SRDF的环境中，那么原子步骤包含两个，第一步是把SRDF的关系断开，即进行split操作，在数据验证完毕后，再将SRDF关系建立起来，即进行establish操作，其中split和establish这两种操作就被视为原子操作步骤。定义完原子操作后，需要对每一个原子操作编写脚本，即控制它登录到哪台控制机，执行什么样的操作，需要添加什么样的参数，这些都需要脚本来规范和实现。

3.3 容灾自动化切换平台实现举例

以下简单介绍下我们行目前所搭建的容灾切换自动化实现方案，在我们这套架构中包含4个基本组件：

1. 用户友好的前端操作界面，我们叫做灾备指挥平台
2. OO(operations orchestration),即自动化引擎组件
3. SA(system automation)，可以通过该组件登录到目标主机批量执行脚本或命令
4. NA(Network automation)，用来做网络切换

这4个组件组合在一起是怎样的工作机制呢？首先我们从灾备指挥界面选择需要进行切换的系统名称，例如信贷业务系统，再指定切换场景，例如计划内切换，选定完毕后平台将指令下达给OO自动化组件，OO收到指令后，将其转化为相应的标准步骤表，该步骤表包含主机端的原子操作，应用起停的原子操作，存储切换的原子操作，同时步骤表（也叫OO流）作为一个严密的流程，有其内部逻辑，规范了每一个原子操作失败后的自动化动作和跳转、以及是否需要人工干预的步骤。对于存储这部分而言，OO在拿到原子操作的代码后，会从数据库中查找对应的切换系统所需要调用的切换脚本，存储控制机名称，存储ID, 相关参数等信息，并将其拼接成相应的脚本命令，这个命令会转发给python的中间件，python中间件主要负责OO平台和SA主机之间的通信，python中间件将命令转发给SA的主机，对于存储切换部分而言，SA会登录存储控制机执行接收到的脚本命令，将输出的日志返回给python中间件，然后存放到后台数据库中，OO流会不断的循环读取数据库记录，以判断每个原子步骤的执行结果，一旦读取到某个成功关键字，便继续下一个步骤，如果原子步骤执行失败，则按照设计的步骤选择是由人工处理还是重试操作。

针对该平台，有几个关键的部分，一方面是存储脚本的编写，要求脚本逻辑一定要严密，每个操作要细致，对于每一步执行结果的判断要准确，成功和失败都要有对应的处理机制。另一个方面是根据场景所做的规范流程，流程的先后顺序一定不能颠倒，对于存储而言，数据是极其重要的，主到备的复制关系不能随意被打乱，尤其是对于像Netapp的snapmirror复制而言，复制关系需要在命令行中写定，从生产到灾备，或是从灾备到生产，一旦方向写反了，生产数据就可能被灾备数据冲掉。
下面以一个V7000的切换实例来说明灾备切换流程的设计，存储部分主要包括以下原子步骤：

1. Failover之前的检查，检查成功返回一个成功值给下一步
2. Failover拿到返回成功值后进行实际的failover操作
3. Failover之后检查metromirror的状态是否为idle
4. 灾备端的数据验证
5. 数据验证完之后的failback动作
6. Failback之后的存储状态检查