航空公司存储系统架构设计方案课件

1、存储系统架构设计1背景- 2 -2. 用户需求和存储系统架构方案设计- 2 -2.1 存储系统性能需求和方案设计- 2 -2.1.1 业务简介- 2 -2.1.2 需求分析和方案设计过程推演- 4 -2.1.3 具体方案设计- 8 -2.2 存储系统功能需求和方案设计- 9 -2.2.1存储系统架构现状- 9 -2.2.2 当前架构存在的问题（存储系统功能需求）- 11 -2.2.3 存储系统架构优化方案- 12 -2.3 业务系统灾备需求和方案设计- 14 -2.3.1 业务系统灾备方案和架构现状- 14 -2.3.2 灾备方案优化- 15 -3. IBM存储系统解决方案的优势- 16 -4

2、. 方案软硬件采购清单- 17 -附录 参考文献- 18 -1背景信息企业的业务规模和数据量呈现爆炸式的增长,这无疑给支撑业务的后端IT基础设施带来了巨大的挑战,于是各种硬件升级和资源扩容成了每个企业必须面对的课题,而这其中存储的优化却显得尤为重要。这也不难理解，因为CPU、内存和各种内部总线的速度和发展已经远远超越了磁盘存储。另外，虚拟化的大举推进使得I/O变得越来越密集。另一方面，生产系统的数据往往存在多个副本，再加上容灾系统中数据的两中心甚至多中心的复制，所有这些因素都给业务逻辑最末端的存储系统提出了严峻的性能考验。随着企业信息系统的发展，在基础设施升级换代的过程中，数据中心往往存在多个

3、厂牌的高中低端多档次的磁盘阵列。由于前端业务系统到后端的基础设施一般采用“竖井式”的架构设计，随之而来的是信息孤岛的存在。不同阵列间的数据缺乏流动性和资源共享，而且单个盘阵的资源利用率往往不高，同时单盘阵作为一个宏观的整体其本身也是个单点故障。另外不同厂牌的盘阵的数据复制技术各不相同，需要管理人员掌握多项复杂的技术，日常需要繁琐的存储配置，运维效率很低。因此为了提升存储系统的整体利用率和可靠性以及简化存储的管理、提高运维效率，亟需整合数据中心的存储系统。这种整合一方面是存储服务的整合，也就是将数据中心的存储资源进行池化，通过单一的接口对外提供存储服务，另一个维度也是运维管理的统一。2. 用户需

4、求和存储系统架构方案设计2.1 存储系统性能需求和方案设计2.1.1 业务简介前段时间，公司某个核心结算系统在上线前开始出现性能问题。该系统采用典型的B/S架构设计，主要包含作业调度层、应用逻辑层和底层数据库平台。在线数据使用的是ORACLE数据库，近线的历史库使用的是MYSQL数据库，系统逻辑拓扑图如图一所示。图一 业务逻辑拓扑图该系统业务逻辑主要包含以下四类作业：l 每天白天9点-17点的在线数据录入和一些简单查询l 白天逻辑单一的后端计算l 每天19点-次日7点的夜间维护批处理作业l 月末关户作业目前该系统有500左右的用户数，日均销售数据量约12万（年销售量约4000万），日均运输承运

5、数据量约26万（年运输量约9000万）。对于白天在线的OLTP交易类型和单一逻辑计算，尚未收到客户反应慢的问题。但是对于每天的夜维批处理作业和月度末的关户作业已经开始出现性能问题。对此，用户反馈的主要问题如下：l 夜间Daily作业在处理月中后期无法按时（早上7点前）完成，出现推迟到白天工作时段运行，典型作业包括配比MCH_DAILY、运输日作业UPL_COM等业务模块l 运输月关户作业系统运行时间超过原计划的6小时为了保证业务系统的顺利投产，需要尽快解决上述性能问题。2.1.2 需求分析和方案设计过程推演用户反馈的日常夜维作业共计71个作业，编排为8个队列进行作业调度，通过历时三个月对重点耗

6、时作业的持续监控、反复测试、应用代码和后端基础架构调优，最终将业务窗口缩短到刚好满足系统SLA约束。这其中应用代码调优带来的系统性能提升很有限，最多在10%左右，距离投产的性能要求还相差很远。后续通过进一步的分析，发现存储系统IO是制约整个业务性能提升的瓶颈。该业务系统部署在公司2007年采购的DMX4高端存储上，有限的前端CPU板卡和磁盘资源成了制约IO性能提升的短板，后续通过增加CPU板卡资源和扩充存储池中磁盘的数量，有效提升了系统IO性能。但是这种调整是有极限的，有限的硬件资源处理能力成了IO性能提升的硬件边界。当IO需求随着业务量的增长而进一步攀升时，后端的硬件很快会再次遇到IO瓶颈。

7、因此为了解决长远的性能问题，需要寻求更高的硬件边界。IO调优除了提升后端存储的IO处理能力外，另一个角度就是减少前端业务代码给后端基础架构带来的IO量。应用端通过将耗时作业由夜维窗口转移到白天进行，另外就是减少代码中COMMIT的次数。这些应用端的方案都可以减少IO量，但随之而来的问题是：首先夜维作业调度到日间窗口，虽然近期不会影响上述中OLTP的业务模块，但随着用户数量的增加以及业务量的增长，这种调整长远看势必会影响日间作业模块的正常处理，两者会互相干扰；另外就是减少COMMIT次数，会带来更多的数据库资源消耗以及IT系统故障时更多数据丢失的风险性。由此，我们不难看出，在系统调优的过程中，直

8、接提升后端硬件的处理能力往往能更快速的解决系统性能问题，同时减少耗时又收效甚微的代码改动带来的运维成本增加以及给业务带来的风险性。如果我们深入探究该系统的IO模型，不难看出，首先出现性能问题的是批处理作业和月末的关户作业，两种类型的作业类似于OLAP模型，有大量典型的复杂查询操作。这种查询往往是在大数据量上进行多数据块的并发操作，要求存储系统有更高的对于大IO block SIZE的顺序吞吐能力，同时还能迅速提供特定的IO块，也就是要有很好的对于随机IO的响应能力。再者由于批处理作业有严格的时间先后处理逻辑，同时多个作业流也会带来一定的随机性IO，因此如果能提高存储系统对于大IO的带宽、提高对

9、于随机小IO的IOPS以及降低随机小IO的IO Latency，会对整个业务系统带来显著的性能提升。这对于该结算系统日趋增长的OLTP类型的业务模块也会带来巨大的IOPS和IO Latency容忍能力。我们推荐全闪存阵列，因为全闪存阵列正是极致地优化了上述IO特性，使其具有比基于HDD机械硬盘的传统磁盘阵列更为广泛的业务应用场景。为此，我们特意选了三款业内主流的全闪存阵列进行实地业务测试，分别测试了Netapp的全闪存FAS系列的FAS8060、EMC的一个X-brick的XtremIO以及IBM Flashsystem FS840，其中以IBM FS840全闪存阵列的各方面综合表现最为突出。

10、参测的Netapp和XtremIO全闪存阵列都是满插SSD的盘笼，而FS840仅仅配置了两块2T的Flash卡，但是三款全闪存阵列的业务处理时间却很接近，足见FS840的高效。下面以FS840和用户现有存储实地作业运行时间比对以及FS840和VNX5400性能指标比对来说明FS840给业务系统带来的性能改善以及较之于传统HDD磁盘阵列在各种IO模型下的IO指标提升。下表是该业务在老存储和FS840上业务处理时间的比对。从下表的作业运行时间的比对上可以看出，FS840给该业务带来了巨大的性能提升，效率提升近70%。作业运行时间(分钟)作业名称公司现有磁盘IBM闪存阵列FS840UPL_COM12

11、6.473.1MCH_DAILY126.519.6ADJ_RRP47.215.3总计300.1108表一 生产盘阵和FS840业务处理时间比对考虑到尽量不用生产存储做压力测试，避免给用户业务带来干扰。同时VNX5400比用户现有生产存储DMX4无论是前端口和后端口的速率都要高，同时拥有更大的Cache。另外在历时三个月的性能调优过程中，曾分别在VNX5400、DS5300和DMX4上跑了同样的业务进行测试，耗时基本相近。因此用FS840和VNX5400的IO测试比对也足以说明基于闪存介质的全闪存阵列比基于HDD的传统盘阵带来的巨大IO性能提升。图二是性能测试拓扑图，其中P720一个LPAR通过

12、两个8Gb HBA卡接入两个冗余的SAN Fabric，后端的VNX5400和FS840也是通过冗余的控制器连接到两个Fabric中。VNX5400从三个8+1 RAID5的15K RPM SAS盘构成的Raid Group中划分32*50GB的LUN，FS840从两个2T Flash Module构成的RAID0的Mdisk中划分32*50GB的Vdisk，由于AIX中两种盘阵的多路径软件不同，为了排除干扰因素，两种盘阵分开进行测试。图二 性能测试拓扑图由于上述结算系统跑在ORACLE数据库上，因此选用ORACLE公司开发的ORION测试工具展开测试，能更好地模拟ORACLE软件IO Sta

13、ck的特性，如下是对不同 IO SIZE的性能测试对比，这里面对于小IO，我们关注的是IOPS和IO Latency的表现，而对于大IO，关注的更多的是带宽即Bindwidth。图三 8K 100%随机读性能对比（IOPS）图四 8K 100%随机读性能对比（IO Latency）图五 1M 100%随机读性能对比（BandWidth）图六 DSS类型应用性能对比（BandWidth）通过上面的性能比对，可见FS840在各种类型IO的性能上要明显优于HDD盘阵，另外在高IOPS基础上，IO Latency更加稳定。通过上述分析，IBM的FlashSystem全闪存阵列可以有效解决用户业务系统的

14、性能问题，同时在未来很长时间内能够满足业务系统逐年增长的容量和性能需求。2.1.3 具体方案设计考虑到用户数据中心核心业务系统的数据总量以及需要接入全闪存阵列的服务器规模，另外考虑到Flash System V系列较之于FS系列除了提供全闪存阵列极致的性能外还能提供更多诸如存储系统虚拟化整合、后端存储高可用配置、数据本地和远程复制等高级软件定义存储特性，重要的是，V系列带来SVC高级功能的同时只损失很小的闪存性能。因此建议生产中心配置两个Building Block（BB）的FS V9000，两个BB均配置2.9T的Flash Module，这样经过2D-RAID配置后，两个BB可以提供58T

15、的可用容量，可以满足公司需要迁移至V9000的数据库系统未来3-5年的容量需求。由于V9000具有SVC的功能，因此可以将其透明的加入用户现有的SAN Fabric中，利用SVC数据的在线迁移功能，完成业务系统由现有存储向V9000的透明迁移，而完全不会影响业务的持续在线运行。图七是存储架构变迁对比图。 图七 DMX4迁移至FS V9000示意图2.2 存储系统功能需求和方案设计2.2.1存储系统架构现状目前公司现有生产存储分别是DMX4、VNX5500、VNX5600、DS5300、DS4300、FAS3250以及两台HP P2000磁盘阵列。各存储上的业务部署和空间使用情况如下所示：设备数

16、据保护方式总容量（TB）使用情况（TB）DS5300阵列内部磁盘RAID565国际客运结算系统2国内客运和货运结算系统28其他业务21虚拟化平台5空闲（空闲率）9（14%）DMX4阵列内部磁盘RAID1和RAID529BSP核心系统6BCV卷9国际客运结算系统9空闲（空闲率）5（17%）vnx5500阵列内部磁盘RAID563BSP核心系统21空闲（空闲率）42（67%）vnx5600阵列内部磁盘RAID550空闲（空闲率）50（100%）DS4300阵列内部磁盘RAID58国内货运系统2其他业务2.5临时空间3.5空闲（空闲率）0（0%）FAS3250阵列内部磁盘RAID DP34BSP核心

17、系统NAS空间21空闲（空闲率）12（35%）P2000-01阵列内部磁盘RAID54DMZ环境和生产虚拟化应急4空闲（空闲率）0（0%）P2000-03阵列内部磁盘RAID56生产X86虚拟化平台6空闲（空闲率）0（0%）表二 生产存储资源及业务分布现状图测试磁盘阵列主要是DS4800、VNX5400、DS4300以及一台HP P2000磁盘阵列，业务分布和存储使用情况如下所示：设备数据保护方式总容量（TB）使用情况（TB）DS4800阵列内部磁盘RAID528.5X86虚拟化平台7国际客运结算系统2国内客运和货运结算系统15.5空闲（空闲率）4（14%）DS4300阵列内部磁盘RAID54

18、BSP相关测试2空闲（空闲率）2（50%）VNX5400阵列内部磁盘RAID545BSP测试16空闲（空闲率）29（64%）P2000-02阵列内部磁盘RAID510.4X86虚拟化测试平台9.4空闲（空闲率）1（9.6%）表三 测试存储资源及业务分布现状图同城灾备端的磁盘阵列有FAS3220、DS4300和DS5020，业务分布和存储使用情况如下所示：设备数据保护方式总容量（TB）使用情况（TB）FAS3220阵列内部磁盘RAID DP45.3BSP系统18.3国际客运结算系统5X86虚拟化平台5空闲（空闲率）17（38%）DS4300阵列内部磁盘RAID53.3BSP系统2.8空闲（空闲率

19、）0.5（15%）DS5020阵列内部磁盘RAID57BSP系统1.9国际客运结算系统1.6空闲（空闲率）3.5（50%）表四 灾备端存储资源及业务分布现状图注：上面的三个存储资源统计表中各类结算系统仅包含数据库容量，对应的前端APP和Web服务器基本采用X86虚拟化架构，其容量统计在X86虚拟化平台项中，X86虚拟化用的是VMware vSphere解决方案。按照业务系统的功能分类，存储系统也随应用系统划分为上述的生产、测试和灾备区域。对于每一个特定区域中的磁盘阵列来讲，都是孤立地对前端主机提供存储服务，现行的存储拓扑图如下所示：图八 存储系统当前架构注：由于方案设计并未包含NAS部分，因此

20、图中并未标出Netapp 统一存储的NAS拓扑。2.2.2 当前架构存在的问题（存储系统功能需求）现行的存储架构中，由于前端主机到后端存储都是采用所谓“竖井式”的设计，因此随着数据中心存储规模的扩大，存储阵列之间形成“信息孤岛”，不同时期不同厂牌的高中低端各档次的存储阵列之间缺乏资源共享和灵活的数据流动性，因此各存储阵列资源利用率不均衡，正如上表统计结果显示，各磁盘阵列的空间使用率差异性很大，由此也会直接造成阵列的CPU和Cache资源利用率的不均衡。另外，由于前端主机需要通过SAN Fabric直接接入异构的存储阵列，所以操作系统中需要安装不同存储设备的驱动和多路径软件，而且还要考虑各厂商多

21、路径软件之间的版本兼容性问题。安装驱动和多路径软件，以及实施不同存储对于HBA卡和存储LUN的调优都需要重新引导系统，给业务带来了过多的离线维护窗口。所有这些繁琐的配置在给操作系统带来太多的变更和压力外，也给运维管理带来过多的复杂度。由于孤立的存储阵列之间缺乏联系，因此需要在操作系统的LVM层实现后端存储的沟通，也就是所谓的LV Copy配置，以此规避存储阵列作为一个宏观整体的单点故障，从而实现存储的高可用。但有些操作系统原生的卷管理软件并不支持这种高可用配置，需要额外安装第三方的卷管理软件。另外对于VMware接入外部存储的场景，实现这种存储的高可用设计也没有什么有效的办法。如果抛开操作系统

22、层实现存储高可用设计的各种壁垒，这种LVM层的卷镜像架构会给操作系统层带来额外的CPU和RAM开销，严重时会影响业务系统的性能。另一种相似的场景是实施老存储向新存储迁移，在线的LVM层的迁移方式会给操作系统带来过多CPU、RAM和IO资源开销，影响业务系统性能。而如果采用离线的迁移方式，主机端需要停应用，生产系统海量的数据往往会带来数小时的停机窗口，这对于维护窗口短暂的生产业务显而是行不通的。对于VMware平台的Storage Vmotion、Storage DRS以及虚拟机克隆和虚机磁盘VMDK写零初始化等一系列存储级的操作来讲，由于老旧存储缺乏VMware VAAI的有效API集成，因此

23、所有来自VMware对后端存储的IO操作都会流向VMware的Hypervisor层，一方面IO由于不能直接下沉到底层存储造成效率低下，同时也给Hypervisor层带来额外的性能开销。不同厂商的存储有不同的存储层卷复制技术，即使是同一个厂牌的存储，不同档次的设备在实施卷复制时也会采用不同的软件，换句话说，高中低端的存储操作系统无法做到功能拉齐。由此会造成这种存储层的卷复制不够灵活，只能在同构甚至是同款的磁盘阵列间实施。另外，存储管理员需要掌握多种复杂的卷复制技术，给运维管理增添了复杂度。2.2.3 存储系统架构优化方案对于上述当前存储架构存在的诸多问题，实际上也是存储系统架构需要优化的需求点

24、，是综合分析了业务逻辑层、操作系统层、主机虚拟化层以及后端存储系统如何互相协调，为了实现高效、健壮的整体信息系统架构而对末端存储系统提出的全方位的功能性需求点。显然存储虚拟化技术恰好迎合了这些需求点，推荐使用IBM Spectrum Virtualize产品方案即IBM SVC，当前的存储架构加入SVC方案后可以有效解决上述难题，具体可以带来如下的成效：实施SVC后，可以整合存储资源，将后端异构存储阵列进行池化管理，通过单一的存储虚拟化层，统一对前端主机提供存储服务。一方面可以有效平衡各存储资源的利用率，由此提高整个存储架构的效能。再者由于存储服务接口得以统一，操作系统层只需安装存储虚拟化层的

25、驱动和多路径软件，减轻操作系统的负载、降低运维管理复杂度。通过SVC提供的本地Volume Mirroring即VDM功能，可以实现异构阵列间的高可用方案，规避阵列单点故障。由于这种卷镜像从操作系统层下沉到存储虚拟化层实现，因此可以有效降低操作系统层的资源开销，使得前端主机从过多的IO负载中解放出来专注业务系统的处理。另外通过VDM或者SVC提供的Vdisk迁移功能还可以实现存储的在线、透明迁移而不会影响前端业务系统的持续在线运转，显著降低停机维护窗口。SVC统一的存储操作系统提供的软件定义存储功能接口可以拉齐后端的异构阵列，使老旧存储也可以使用上VAAI、VASA等存储系统和虚拟化Hyper

26、visor集成的功能，从而提高虚拟化平台的IO性能、功能和运维效率。通过Flashcopy功能可以实现后端异构存储多样化的卷复制软件的统一，完成生产卷的PIT即Point In Time的快照拷贝，一方面可以用于生产卷的日常备份，还可以迅速搭建测试环境，另外可以实现本地的容灾，通过不同频率的Flashcopy设置，解决数据库一定时间段内的逻辑故障。由于存储系统当前架构是按区设计的，为了避开不同功能区的性能干扰，建议分别为生产、测试和灾备区部署SVC方案。由于生产区已经部署了IBM FS V9000，实际上是全闪存阵列加SVC方案，因此生产区无需额外设计（参见存储系统性能需求解决方案中的存储架构

27、）。测试区和灾备区各部署一套两节点的SVC集群实现相应功能区存储系统的虚拟化整合。实施SVC后，存储系统架构如下图所示：图九 存储系统优化架构在实施SVC本地生产区VDM存储高可用方案时，按照IBM SVC Volume Mirroring的最佳实践进行Vdisk在不同Storage Pool中的不同后端存储进行两份copy的设置，第一份Primary Copy选择性能好的阵列，这样前端主机的读操作可以获得更好的性能。另外提供两份Vdisk Copy的后端阵列的性能要相近以减小对前端主机写操作的IO Latency。按照上面的高可用设计规则，对于部署在V9000上的业务系统，目前是上述表格中统

28、计的国际客运结算系统（存储容量DS5300中的2T+DMX4中的9T共计11T），可以将两份Copy放置在V9000的不同BB中的Internal Storage（Mdisk）里。对于其他高等级的业务系统主要是存储架构现状统计表中的BSP核心系统，其存储分散在DMX4和VNX5500以及规划中的VNX5600磁盘阵列中，这些磁盘阵列的性能相近，考虑盘阵负载的均衡，可以交叉进行Vdisk Copy的Layout。VNX5600由于是新近采购的盘阵，上面尚未部署业务，可以多承担一些业务系统的IO压力。2.3 业务系统灾备需求和方案设计2.3.1 业务系统灾备方案和架构现状2008年，公司开始启用距

29、离生产中心20公里内的同城灾备中心，生产中心到灾备中心的数据同步建立在两个ISP提供的两条冗余的30Mb Internet线路上。目前，公司有灾备需求的业务系统是BSP核心系统和国际客运系统，由于两套系统对灾难时的RPO和RTO指标约束级别不高，RPO是6小时，而RTO有48小时，所以灾备采用数据库备份磁带定期恢复，平时脚本传输归档并应用日志的方式保证两站点数据库数小时的差异状态。而前端的应用数据通过第三方的同步软件GOODSYNC完成数据的同步。这种容灾方案虽然成本低，但需要过多的人为干预，同时两条Internet线路带宽通常不能被充分利用。另外，随着公司近年来主机虚拟化的推进，尤其是X86

30、平台的VMware技术的充分利用，现行的机械的灾备方案已经愈发不能适应新的虚拟化架构提出的灵活要求，灾备方案需要向自动化演进。2.3.2 灾备方案优化针对现行灾备方案的问题，同时考虑到生产中心和灾备中心均部署了SVC解决方案，因此推荐使用SVC提供的基于Native IP Remote Copy复制功能的Global Mirror With Change Volumes即GM/CV，使用两条冗余的Remote Copy复制链路。一方面该方案可以利用SANslide专利技术充分使用有限的Internet带宽，提高数据传输效率。再者由于GM/CV使用SVC的Flashcopy功能，对于生产卷没有性

31、能影响。同时GM/CV还能和VMware提供的SRM功能完成X86虚拟化平台自动化的容灾方案。考虑到GM/CV方案的Cycling异步数据复制原理，如果在一个Cycling里成功传输生产卷产生的数剧增量，那么灾难发生时最多会丢失两个Cycling的数据。目前两套业务系统每天有80GB的数据变化量，由于业务特性，数据的变化在全天比较均衡，因此平均每小时的差异量有3.33GB。两站点之间的带宽有6MB，理论上每小时可以同步的数据量是21GB。因此按照RPO是6小时的约束，只要Cycling在3小时内都可行，而按照上面的推演显然没有问题。实施基于SVC GM/CV的容灾方案后，可以有效提升容灾架构的

32、自动化程度，免去频繁的数据同步脚本维护以及定期递送生产端数据备份磁带至灾备中心。另外新的容灾架构可以显著增强数据同步稳定性以及深化和主机虚拟化技术的融合。新的灾备架构如下图所示：图十 灾备方案优化架构3. IBM存储系统解决方案的优势IBM的技术始终是先进的而且具有前瞻性，很多存储领域的技术都是由IBM首先提出或实践的，如磁盘RAID技术、存储虚拟化技术以及时下火热的Flash全闪存技术等。所以选择IBM的解决方案可以有效保护用户现有投资，而且技术的稳定性和先进性都有所保证。上述方案中全闪存阵列FS V9000通过和SVC的灵活融合，同样一个Base 6U的占架空间，却比XtremIO提供更丰

33、富的诸如存储虚拟化整合、存储自动分层、不同阵列间的卷镜像、高效的基于单独硬件加速卡的数据压缩功能以及数据复制等高级软件特性。如果拿SVC和EMC VPLEX解决方案比较，也有很多优势，VPLEX只是简单的完成后端阵列的虚拟化整合，而没有SVC所能提供的高级软件定义特性，因此无法实现后端异构阵列的软件功能拉齐。同时通过比对两种方案对后端阵列的兼容矩阵，不难发现SVC兼容的设备更广泛，对于老旧存储有更好的兼容性。再者，VPLEX全盘采用前端主机IO透写即Write Through模式，因此不但对整个存储系统没有性能提升，反倒会因为增加了存储虚拟化层而进一步增大前端主机的IO Latency。加入存

34、储虚拟化层一个显著的好处就是实现后端存储阵列的高可用，遗憾的是VPLEX对卷的两份Copy只能采用RoundRobin方式读取，不能像SVC一样设置Primary Copy，因此读性能会由于后端盘阵的性能差异而有所下降。上述IBM的V9000和SVC解决方案有很多功能比如RTC、Easy Tier等功能并未使用，这些技术可以在日后的存储架构优化中灵活按需部署。另外在SVC解决方案中用到了Flashcopy技术，实际上Flashcopy可以实现系统级的容灾，如果要使应用系统如关系型数据库恢复可用，还需要文件系统以及数据库日志的Log Replay等操作。而如果我们引入IBM Tivoli Storage FlashCopy Manager，可以做到应用感知的Flashcopy操作，减小应用恢复的复杂度以及Flashcopy的管理。另一方面，Flashcopy功能也可以和用户现行的Symantec NetBackup备份软件结合使用，完成Flashcopy卷的备份。日后随着数据中心存储架构复杂度的进一步增加，可以适时引入IBM TPC方案，实现存储架构更高层次的单点统一管理和更丰富的存储系统性能收集、调优等高级功能。所有这些都说明IBM存储系统解决方案有很好的扩展性，同时有良好的兼容性，因此