金融行业存储设备升级、整合、扩容项目方案设计

字数 18554阅读 8324评论 1赞 12

## 项目总体目标：
随着信息系统的不断发展，全面优化整合现有存储平台，同时构建一个灵活先进的高可用存储架构，是保障各业务系统运行连续性的基础。我行进行的存储设备升级、整合、扩容项目，将全面优化整合现有存储平台，解决存储单点故障，提升关键数据冗余保护，优化存储系统性能，构建灵活先进的高可用存储架构，保障各业务系统的运行连续性。
## 项目目标细则和策略：
1、	消除开放平台存储单点的安全隐患，保障生产系统的连续性运行。
现状与挑战：自2006年来，我行已先后购置了8台存储设备用于核心后台、13个交易类和8个管理类应用系统开放平台服务器使用， 2台存储设备用于核心后台交易，1台存储设备用于核心数据备份，5台存储设备用于开放平台应用系统，中心机房所有存储设备均为单点，众多关键系统数据只有一份，业务连续性和数据安全完全依赖单台存储的设备可靠性，根本不能避免存储单点故障。存储设备一旦发生无法及时修复的故障或数据丢失，相关业务系统必然遭受重大影响，RTO远远不能满足监管部门要求。
解决目标：对开放平台进行整合，通过新购存储及现有存储设备升级，利用软件或者硬件的方式，将交易类及管理类系统数据存放在2台物理存储设备内并实现存储设备间的实时数据保护，解决存储单点安全隐患，将RTO控制在监管部门要求的范围内。

2、	优化整合开放系统存储平台，提升存储性能和可靠性。
现状与挑战：开放平台现有存储使用散乱、性能不一，由于业务系统上线时间及历史残留问题，交易类业务系统所用存储依旧为低端存储，如DS6800、DS4700和DS3400等，而管理类业务系统所用存储却为中端存储，如DS8100和V7000，导致交易类系统存储性能得不到满足。同时目前运行时间较长的DS6800/4700/等存储的故障率呈先上升趋势，一旦该类存储故障宕机，交易类系统则受重大灾难影响。
解决目标：通过将开放平台按照业务系统类型调整存储分配，迁移交易类/管理类系统至新购或升级存储内，充分发挥各存储性能水平，提高业务系统效率；在现有的存储架构之上，搭建基于存储虚拟化的整体存储架构，便利未来数据迁移、调整等日常工作，优化运维管理工作；充分利旧现有设备，将运行时间较长且故障呈现上升趋势的DS6800/4700等存储将其转作开发测试用途，提升相关业务系统的稳定及可靠性的同时并保障现有投资。

3、	增强交易、管理类业务数据的安全保护，解决缺少数据存储备份的问题。
现状与挑战：目前交易类和管理类业务数据存储只有一份数据，虽然存在集中备份平台每日对主机系
统进行在线备份，但备份的频率仍然较长，且备份覆盖面和覆盖率也有很大限度，无法满足交易类系统对RPO的要求，一旦存储故障宕机，有部分数据将彻底丢失，备份平台的数据恢复也很漫长，RPO较高。
解决目标：利用存储整合技术，实现业务数据在存储层面的数据在线迁移，并构建数据的存储级别冗余保护，保证交易及管理类系统的所有业务数据都在两个不同的存储设备存有拷贝，提升数据的安全保护级别，避免单个存储故障所可能造成的数据丢失风险，满足RPO=0的硬性要求。

4、项目实施过程尽可能保障业务的稳定运行和数据安全。
现状与挑战：因本次项目涉及到交易类和管理类存储数据的整合，牵涉到存储与存储间的存储复制或者同步过程，甚至存在数据由存储迁移至另一存储的过程，因此，在数据迁移过程中，务必需要保证数据的完整性和数据一致性。
解决目标：由于此次项目牵涉绝大部分我行生产交易类系统和重要管理类系统，所以在项目进行过程中，需要提前进行各种测试，尽可能在正式上线前排除隐患和问题。对于可能会遇到的风险点，需要项目实施方专家团队尽可能多的提前进行提示，全力保障业务的稳定运行和数据安全。

5、项目尽可能减少业务系统的中断时间。
现状与挑战：本次项目涉及到我行较多的重要交易类系统，环境复杂，难度高，在项目实施过程中必然需要中断业务系统，需要一定的停机时间窗口，对于银监局和人行重点关注的业务系统，需提前向本地银监局和人行中支进行申请停业报备，但单个业务系统整个停机时间窗口不得大于4小时。
解决目标：我行作为金融企业，需要严格满足银监局关于金融企业业务连续性的要求。因此，为减少业务的中断时间，在项目实施过程中，需尽可能通过各种手段和方式来避免或减少软硬件系统的停顿。对于确实需要停顿系统的操作，需要提前进行合理安排，通过切换备机、一次进行多个操作等手段来；降低业务的中断时间。

# 项目所需的具体需求模型（负载模型）及取值说明
本行的开放平台当前有若干个独立的SAN网络，系统所有数据由DS3400，DS4700，DS6800，DS8100与V7000共同进行承载。为解决以上问题，实现项目目标，拟通过IBM SVC、EMC VPLEX、NETAPP MCC或飞康NSS等存储虚拟化技术，对当前的SAN网络和存储进行整合，利用存储虚拟化网关将数据迁移到新的目标存储上，并利用存储虚拟化的实时同步镜像功能提高存储的高用性。由于虚拟化网关是本次存储升级、整合、扩容项目的核心，因此虚拟化网关本身的冗余性至关重要，在项目实施前需要搭建一整套测试环境，来模拟各种故障场景，以测试虚拟化技术的可行性及先进性。整个存储架构模型具体需求参数如下：
## 需求目标一：
服务器访问的任一存储虚拟化网关的端口的光纤故障，不会导致整体业务系统中断，RTO≈0，RPO=0。
（1）需求原因：用以测验验证存储虚拟化网关节点的光纤线断开对业务系统应用的影响。
（2）模拟测试条件：存储虚拟化网关设备配置完成、主机端多路径软件配置正确、SAN Switch配置正确。
（3）模拟测试方法：
A、	在测试服务器的测试磁盘上启动IO读写。
B、	依次断开/恢复存储虚拟化网关节点的一根光纤线(一共有四根光纤线用于服务测试的服务器)。
（4）需求结果：
A、	存储读写IO短暂中断。
B、	主机端应用不受影响。
C、	主机端磁盘的某些路径failed。
D、	存储虚拟化网关中出现相应的event信息。
## 需求目标二：
任何一个存储虚拟化网关节点发生故障，不会导致整体业务系统中断，RTO≈0，RPO=0。
（1）需求原因：用以测试验证存储虚拟化网关节点关机对业务系统应用的影响。
（2）模拟测试条件：存储虚拟化网关设备配置完成、主机端多路径软件配置正确、SAN Switch配置正确。
（3）模拟测试方法：
A、	在测试服务器的测试磁盘上启动IO读写。
B、	直接关闭一个存储虚拟化网关节点。
C、	再次将存储虚拟化网关节点开机。
D、	直接关闭一个存储虚拟化网关节点的UPS的电源，模拟外部供电故障。
E、	恢复存储虚拟化网关节点的UPS电源。
（4）需求结果：
A、	存储读写IO短暂中断。
B、	主机端应用不受影响。
C、	主机端磁盘的某些路径failed。
D、	存储虚拟化网关中出现相应的event信息。
E、	在存储虚拟化网关的UPS电源关闭时，存储虚拟化网关节点会迅速将缓存中的数据写入硬件，并将存
储虚拟化网关节点关机自我保护数据。
## 需求目标三：
存储虚拟化网关底层任意一台存储发生故障，整体业务系统影响较小，RTO<1分钟，RPO=0。
（1）需求原因：用以测试验证存储虚拟化网关的后台存储发生故障时对业务系统应用的影响。
（2）模拟测试条件：存储虚拟化网关设备配置完成、存储虚拟化网关两份同步镜像已经完成，且数据完全同步、主机端多路径软件配置正确、SAN Switch配置正确。
（3）模拟测试方法：
A、	在测试服务器的测试磁盘上启动IO读写。
B、	直接关闭一台备存储。
C、	将关闭的备存储再次开机。
D、	在SAN交换机上面将存储虚拟化网关与主存储的zone从配置里移除，模拟主存储故障。
E、	将存储虚拟化网关与主存储的zone重新加入配置文件并激活。
（4）需求结果：
A、	存储读写IO短暂中断。
B、	主机端应用不受影响。
C、	存储虚拟化网关中出现相应的event信息。
D、	当备存储恢复时，数据会自动地从主存储同步到备存储上；当主存储恢复时，数据会自动从备存储同
步到主存储上。
## 需求目标四：
整套存储虚拟化网关产生故障，整体业务系统虽受较大影响，但能快速进行恢复，RTO<2小时，RPO=0。
（1）需求原因：用以测试验证当存储虚拟化网关严重故障无法使用时，生产系统是否可以脱离存储虚拟化网关直接使用后台存储的数据。
（2）模拟测试条件：存储虚拟化网关设备配置完成、存储虚拟化网关两份同步镜像已经完成，且数据完全同步、主机端多路径软件配置正确、SAN Switch配置正确。
（3）模拟测试方法：
A、	将存储虚拟化网关集群关机。
B、	在测试服务器上面强行umount文件系统，varyoff vg。
C、	在SAN交换机上面修改zone的配置，使测试服务器直接访问备存储。
D、	在备存储上面修改磁盘的映射关系，将测试服务器的磁盘直接映射给测试服务器。
E、	在服务器上面运行cfgmgr并执行varyonvg, mount文件系统。
（4）需求结果：测试服务器varyonvg成功，mount文件系统成功，数据无丢失。
## 需求目标五：
存储虚拟化网关后台存储镜像关系切换或拆除，不会导致整体业务系统中断，RTO=0，RPO=0。
（1）需求原因：用以测试验证存储虚拟化网关后台存储镜像关系切换或拆除对生产业务系统应用的影响。
（2）模拟测试条件：存储虚拟化网关设备配置完成、存储虚拟化网关两份同步镜像已经完成，且数据完全同步、主机端多路径软件配置正确、SAN Switch配置正确。
（3）模拟测试方法：
A、	在测试服务器的测试磁盘上启动IO读写。
B、	切换主存储和备存储的主备关系。
C、	拆除备存储内的LUN COPY。
D、	拆除主存储内的LUN COPY。
（4）需求结果：
A、服务器数据无丢失。
B、存储读写IO访问正常。
此外，考虑到存储虚拟化在生产环境实施过程中，需要针对性的综合考虑给各类业务系统带来的影响，避免过长的业务中断时间，尤其是交易类、管理类系统的数据不能容忍丢失。根据近期二周的调研，和银监局对商业银行业务连续性的要求（RTO，RPO），列表如下：
![1.png](/home/attachment/201806/07/329939_152835226398654.png)
另外考虑到整个存储优化、整合、扩容项目的复杂性，业务系统停机中断，进行存储架构改造是必不可免的，所以因充分结合上述表格来合理安排时间，停机时间超过上述系统RTO要求的，因提前申请，并向本地银监局和人民银行做停业申请，申请应提前15个工作日。经过调研，本行的停机时间可安排如下：
![2.png](/home/attachment/201806/07/329939_152835234994949.png)
![3.png](/home/attachment/201806/07/329939_152835235040127.png)
# 项目的整体架构以及组成部分说明
为了达到整个项目的总体目标，其中最主要的部分，即利用存储整合技术，来实现业务数据在存储层面的数据在线迁移，并构建数据的存储级别冗余保护，保证交易类/管理类系统的所有业务数据都在两个不同的存储设备存有拷贝，提升数据的安全保护级别，避免单个存储故障所可能造成的数据丢失风险。
（1）当前开放平台系统整体架构图如下：
![4.png](/home/attachment/201806/07/329939_152835241229573.png)
（2）通过升级后开放平台系统整体架构图如下：
![5.png](/home/attachment/201806/07/329939_152835243749581.png)
（3）整体架构方案设计思路：
1、项目前期准备工作
为确保本次项目能够有条不紊地进行，需要在项目实施之前，提前不少于两个月对我行所有相关设备、应用、环境、技术条件等进行充分调研，主要内容涉及以下7个方面：
（1）调研我行外围系统的SAN网络交换机配置使用情况。
（2）调研我行存储空间的使用分配情况。
（3）调研我行存储设备与各类存储虚拟化网关兼容性情况。
（4）调研我行现有数据备份设施情况。
（5）调研我行应用停机情况。
（6）我行新购设备的场地、承重、电源规划等情况。
（7）我行新购设备的布线。
2、硬件安装阶段与原有存储扩容、升级
本次项目存在大量新购设备，原有设备由于容量和微码版本问题也需要进行扩容和升级工作，主要包含以下5项工作：
（1）新购入的中、高端存储的硬件设备上架、安装与配置工作。
（2）新购入的SAN光纤交换机的硬件设备上架、安装与配置工作。
（3）新购入的存储虚拟化网关的硬件设备上架、安装与配置工作。
（4）提前布置好所需的光纤网络。
（5）原有的DS8100和V7000存储的硬件升级工作，包括硬盘扩容，逻辑配置，和微码版本升级工作，以满足存储虚拟化网关的要求。
3、交易和管理类SAN网络架构优化及整合
为确保本次存储整合项目的顺利实施，最为关键的一步即是：对现有SAN网络进行整合配置，接入新购光纤交换机，分别打通交易类和管理类SAN网络，为后续存储整合实施做好基础准备。最终实现核心生产、开放平台交易、管理和开发测试四个独立的SAN网络，互相隔离，便利管理维护。
当前我行一共有各种SAN交换机10台，分为两个SAN网络，其中，第一个SAN网络连接有IBM DS8100, DS3400, V7000, DS6800及N6060等存储，网络拓扑结构如下：
![7.png](/home/attachment/201806/07/329939_152835246568831.png)
第二个SAN网络仅连接有IBM DS4700，其网络拓扑结构如下：
![8.png](/home/attachment/201806/07/329939_152835248837609.png)
计划通过本次SAN网络整合实施，整个开放平台最终SAN网络的拓扑图如下：
![9.png](/home/attachment/201806/07/329939_152835251130957.png)
在后续的当存储虚拟化整合完成后，可以将以前的旧SAN交换机从当前SAN架构中移除，但是保留交易类新购SAN光纤交换机到管理类新购SAN光纤交换机的连线(ISL)，其拓扑图如下：
![10.png](/home/attachment/201806/07/329939_152835253615515.png)
4、交易和管理类业务系统存储虚拟化整合
接着第二个关键步骤即是：对重要性等级高的13套交易类系统，原先所在的DS6800/4700/3400/V7000存储数据，将全部迁移整合至新购的两台存储内（V7000、XIV、华为或者DS8800等两套新购入的存储），通过硬件或者软件的方式，实现两套存储间的实时数据镜像；对管理类系统，原先所在的V7000和DS8100存储数据，将全部迁移整合至升级后的DS8100和V7000存储（利旧）内，通过硬件或者软件的方式，实现存储间的实时数据镜像，从而解决存储单点故障隐患。优化整合完成后，13套交易类系统完全可以避免存储的单点故障，而且，通过存储虚拟化网关整合后，存储管理简单，数据迁移也会非常容易，性能也会改善。需要强调的是，通过该方案进行优化整合后，对目前13套交易类系统的运行方式不会有任何影响，对操作系统或者应用来说，看到的还是一份数据，数据复制是在底层实现的。因此，当其中的一台存储发生故障的时候，切换是自动实时进行的，用户基本没有任何感觉。存储虚拟化网关基本工作原理如下图所示：
![11.png](/home/attachment/201806/07/329939_152835256322481.png)
整合后的交易及管理类平台数据环境如下，实现将交易及管理类系统数据均迁移至存储虚拟化网关整合管理下的高端存储（新购）及中端存储（新购）、V7000（利旧）、DS8100（利旧）等存储设备上，实现存储间的数据冗余保护。
![13.png](/home/attachment/201806/07/329939_152835260513399.png)

5、剩余存储全部转入开发测试环境，保护原有投资。
最后，对于迁移后的DS6800/4700/3400存储，本着充分整合、利旧现有存储，构建虚拟化存储池的原则，考虑到旧存储运行年限较长、故障报错较多、性能较差的情况，将开发测试平台相关系统数据迁移至DS6800/4700/3400等旧存储内，既提升了相关业务系统的可靠性，又保护了原有投资。

# 关键技术难点
难点一：引入存储虚拟化网关技术，如何解决存储风险集中的问题？
难点分析：本次项目前所未有的引入了存储虚拟化网关技术，该技术需要接入在所有存储前端，业务系统的所有IO读写流量均需先通过存储虚拟化网关，再落入后端存储阵列中，当网关可靠性和稳定性不高时，必然带来风险集中的隐患，一旦网关故障，带来的将是全局性灾难后果。所以问题的根源是，存储虚拟化技术是否足够强悍，以高可靠的技术保证，来规避存储网关带来的风险集中问题。一旦该体系架构中的各个环节出现故障风险时，能立即在该体系内完成故障转移，即使造成业务系统暂时中断一段时间，但之后能迅速恢复，满足我行对业务连续性的要求。
解决方案建议：通过多轮基于存储虚拟化的存储架构高可用测试，来验证该技术的可靠性和稳定性。本行针对IBM SVC虚拟化技术进行了多轮测试，来探究是否IBM SVC能够满足我行的要求。
高可用测试案例1、服务器访问的任一SVC的端口的光纤故障。
期待结果：主机端应用不受影响，主机读写IO短暂中断，主机端磁盘的某些路径failed。
第一次测试结果：该SVC端口的其他冗余端口的光纤接管成功，接管时间约为50秒，该结果不满意。后仔细分析原因，发现主机端光纤适配器的FSCSI的参数fc_err_recov设置为：delayed_fail，为满足IO中断时，尽快切换的目标，将该参数设置为：fast_fail。
第二次测试结果：更改主机FCS参数后，该SVC端口的其他冗余端口的光纤接管成功，接管时间缩短为20秒。
高可用测试案例2、SVC集群中的任何一个SVC节点发生故障。
期待结果：主机端应用不受影响，主机读写IO短暂中断，主机端磁盘的某些路径failed，在SVC的UPS电源关闭时，SVC节点会迅速将缓存中的数据写入硬件，并将SVC节点关机自我保护数据。
第一次测试结果：关闭SVC的集群中的node3节点， 同一IOGRP中的node4接管成功，接管时间为65秒。可见接管时间依旧很长，不尽满意，同样也是需要修改主机端光纤卡的FCS参数。
第二次测试结果：更改主机FCS参数后，重启SVC的集群中的node3，同一IOGRP中的node4接管成功，接管时间缩短至28秒。同时观测到，在node3恢复时，读写速度略微降低，但未造成IO中断。
高可用测试案例3、SVC集群架构体系下的任意一台存储发生故障
期待结果：主机端应用不受影响，当备故障存储恢复时，数据会自动地从主存储同步到备存储上；当主存储恢复时，数据会自动从备存储同步到主存储上。
第一次测试结果：
（1）备存储关闭，数据读取无影响，其中，恢复后vdisk mirror并未显示同步至100%，需要更改SVC集群mirrorwriterpriority参数为redunanacy。
（2）调整SAN zone配置剔除SVC与主连接，测试写操作，5分钟后报错退出，分析系由仲裁盘全部在主存储上丢失引起。
（3）加入备存储仲裁盘后，调整SAN zone配置剔除SVC与主存储连接，测试写操作，第一次测试失败，报错退出；第二次测试，约5分钟后恢复，满足不了需求。
第二次测试结果：
更改SVC集群mirrorwritepriority参数为redunancy后：
（1）备存储模拟故障，反复进行几次读写测试。备存储端口禁用后，约60秒钟后，写操作暂停；写操作暂停后1分钟，手动运行detectmdisk约50秒至90秒后写操作恢复，即自写操作暂停至恢复的时长约为120秒，读操作仅在一次测试中出现了短暂中断约40秒，其他几次测试中均未出现中断。
（2）主存储模拟故障，反复进行几次读写测试，主存储zone配置移除后，读操作立刻暂停，写操作约30秒后暂停，1分钟后手动运行detectmdisk，约80秒后，读写操作恢复，即自主存储DS8100调整引起读写暂停后，约2分45秒左右恢复正常。
第三次测试结果：
更改SVC集群mirrorwritepriority参数为latency后：
（1）备存储模拟故障
多次测试，在备存储相关交换机端口禁用后，约半分钟后，主机端读或写操作会出现短暂中断，或速率下降现象，统计结果，读写操作从中断至恢复时间间隔为32秒至43秒，满足要求。
（2）主存储模拟故障
主存储 zone配置移除后，读操作立刻暂停，数秒后自动恢复，写操作未受影响统计结果，读写操作从中断至恢复时间间隔为13秒至35秒，满足要求。
高可用测试案例4、整套SVC产生故障
期待结果：当整套SVC严重故障无法使用时，生产系统可以脱离SVC直接使用后台存储的数据测试服务器varyonvg成功，mount文件系统成功，数据无丢失。
第一次测试结果：通过SVC后端存储直接挂载给测试服务器后，恢复接管成功，但测试服务器在mount文件系统时报错dirty，后通过fsck修复成功。
第二次测试结果：
通过SVC后端存储直接挂载给测试服务器后，恢复接管成功，启动VG/文件系统均无异常。
高可用测试案例5、SVC后台存储镜像关系切换或拆除
期待结果：服务器数据无丢失，IO访问正常。
第一次测试结果：
更改mirrorwritepriority参数设置为redunancy。
（1）切换主备存储角色，包括主存储切换为备存储及回切为主存储整个过程，IO读写均无影响。
（2）拆除备存储的LUN COPY，读操作无影响，写操作无中断，但速率下降到5M/秒[正常时约为170M/秒]，约80秒后恢复。
第二次测试结果：
更改mirrorwritepriority参数为latency。
（1）切换主备存储角色，包括主存储切换为备存储及回切为主存储整个过程，IO读写均无影响。
（2）拆除备存储的LUN COPY，IO读写均无影响。

本项目最终解决方案参考：
以上经多场景的反复测试，可以得出结论，经过各类相关参数调整之后，SVC存储虚拟化方案可以较好满足本行的规划需求，即构建基于SVC层面的存储级别镜像，实现数据在线迁移复制。基于本次测试结果，解决该难点的有关SVC存储虚拟化配置的具体建议如下：
1、	主机相关光纤卡参数的修改建议
建议修改主机内FSCSI设备属性，包括dyntrk和fc_err_recov，默认参数配置情况下，模拟SVC端口或节点故障，主机IO暂停时间约为1分钟左右；修改参数配置后，模拟SVC端口或节点故障，主机IO暂停时间缩短至20至30秒，可显著降低对主机IO读写的影响

![123.png](/home/attachment/201806/07/329939_152835276246555.png)
2、	有关SVC内LUN mirrorwriterpriority参数值的设定建议
Mirrorwritepriority该参数用于定义SVC内如何配置mirror write算法的优先级别，共有两个选项值：latency和redundancy。
latency模式开启fast failover功能，SVC会将IO请求同时发送到两份数据拷贝(在我们的测试场景里，一份数据位于DS8100，另外一份位于v7000上)，如果数据的某份copy写延迟了5秒钟以上，SVC则允许暂时放弃对此份较慢写入的copy，只要写入另一份copy数据正常完成，则通知主机端IO写入已经完成，并在SVC内存维护的数据同步位图中标识该份数据未同步，系统等待约5分钟后再尝试对较慢写入的copy重新同步。如果在SVC数据未同步时，拥有最新数据拷贝的存储出现故障，且所有数据无法恢复，则可能会出现数据丢失的情况。
redundancy模式始终保证两份copy的数据完全一致性，即必须将IO同时成功写入后台两台存储，才会通知主机端写IO已经完成(在写入过程中，如果确认某一份数据所在的磁盘已经offline，则取消对该份数据copy的写入)。如果后台两台存储性能差异较大时则可能对应用读写造成影响，拖慢写入效率。但是在redundancy模式下，任一时刻，任一存储发生故障，都不会发生数据丢失的情况。如下为在两种参数设置模式下，相关场景测试的对比情况
![111.png](/home/attachment/201806/07/329939_152835290532385.png)
![32.png](/home/attachment/201806/07/329939_152835299220390.png)
![25.png](/home/attachment/201806/07/329939_152835299784035.png)
结合参数说明和测试结果，选择latency模式下仅在极特殊情况下（某份COPY写入的延迟超过5秒钟）才会出现短暂的LUN Copy数据不同步，正常环境下Vdisk Mirror持续保持同步状态，同时可实现fast failover，存储故障情况下主机端IO影响时间为秒级别；而选择redundancy模式，因需持续保持LUN Copy的同步一致，存储发生故障后IO影响时间较长（2到3分钟）。
考虑到我行的生产环境中，DS8100和v7000，以及即将购买的中高端存储的性能都非常优秀，不会出现写入延迟达5秒以后的情况，综合数据一致性和故障容错性的要求，建议将SVC vdisk的mirrorwriterpriority参数值设定为latency。
难点二：引入存储虚拟化网关技术，如何应急防范存储虚拟化网关整体故障带来长时间的RTO？

难点分析：由于主机和存储之间多了一道存储虚拟化网关，增加了一道风险关卡，倘若这道关卡发生致命故障或者软件层面的BUG，导致整个存储虚拟化网关集群宕机，主机再也无法识别存储，全行所有外围交易类系统都将瘫痪，如果此时继续等待该网关能够修复，所耗费时间也是无法估量，带来的风险后果无法掂量，所以务必需要一种可靠的应急办法，能够在存储虚拟化网关瘫痪时，迅速恢复业务系统对存储的访问。
本项目最终解决方案参考：
倘若我行选择了SVC作为存储虚拟化网关的选择，那么在我行外围交易类和管理类SVC系统的可靠性设计中，当SVC本身发生整体故障时，可以通过修改SAN交换机上的zone配置，使主机直接访问交易类新购的中端存储和管理类v7000，达到快速恢复的目的。所以应提前在SAN交换机和v7000、中端存储上面增加相应的配置，以便SVC故障发生且无法在短时间内修复时，实现快速响应，大幅度缩短RTO时间。包括以下两个步骤：
（1）在SAN交换机中增加应急恢复的zone配置以及cfg文件，但是不激活；
（2）在交易类中端存储和管理类v7000中增加相应主机的定义及映射关系；
方案说明：本方案主要是将在交易类中端存储和管理类v7000上创建主机，并将两套存储上相应的vdisk直接映射给主机，由于SAN交换机上主机与两套存储的zone并未激活，主机并不能真正访问到存储上的LUN；当SVC出现致命故障/BUG时，可直接将SAN交换机上主机与两套存储的zone快速激活，主机可立即识别到存储上的LUN，以达到迅速恢复业务系统的目的。
难点三：存储虚拟化网关后端主存储的选择问题
难点分析：我行的外围系统的管理类应用倘若采用SVC存储虚拟化网关，建设完成后数据存储将分布在一台DS8100和一台v7000，根据原规划，我们原先认为DS8100的配置和性能比v7000更好，推荐将虚拟卷的Primary Copy设置到DS8100上。但是在数据同步测试过程中，我们发现DS8100的性能没有达到预期值，在经过研究后，发现当前DS8100已经发挥了最大性能，但是与v7000相比，是否有性能差距？该如何进行验证和测试？所以究竟如何选择SVC那套后端存储做为主存储是一个难以抉择的问题。
解决方案建议：为了解决该难点，我行采用了IBM Disk Magic工具对当前的DS8100和v7000进行了详细的评估。
（1）DS8100的性能
打开IBM Disk Magic，General页面中，选择IBM DS8100 Turbo型号，内存设置为128G：
![1.png](/home/attachment/201806/07/329939_152835308812566.png)
在Interfaces中，添加8个4Gb的存储端口：
![2.png](/home/attachment/201806/07/329939_152835328425958.png)
再添加8个8GB的主机端口：
![3.png](/home/attachment/201806/07/329939_152835331461516.png)
在Open Disk中，添加一个10个rank的RAID10类型的extent pool:
![4.png](/home/attachment/201806/07/329939_152835334040833.png)
最终添加两个Extent Pool，P0和P1：
![5.png](/home/attachment/201806/07/329939_152835343683055.png)
在Open Workload页面中，按照当前的配置作如下设置：
![6.png](/home/attachment/201806/07/329939_152835346955520.png)
根据以上设置，得出当写带宽到500MB/s时，已经达到当前配置的Host Adapter的极限：
![7.png](/home/attachment/201806/07/329939_152835351082792.png)
再调整如下参数评估DS8100的读性能：
![8.png](/home/attachment/201806/07/329939_152835354013065.png)
根据以上设置，当读带宽达到850MB/s时，基本达到已经达到当前配置的Host Adapter的极限：
![9.png](/home/attachment/201806/07/329939_152835357710232.png)
（2）v7000的性能
打开IBM Disk Magic，General页面中，选择IBM v7000(6.4)型号:
![11.png](/home/attachment/201806/07/329939_152835360816071.png)
在Interfaces页面中，添加8块8Gb的存储卡：
![12.png](/home/attachment/201806/07/329939_152835363698674.png)
再添加8块8Gb的主机端口：
![13.png](/home/attachment/201806/07/329939_152835366449622.png)
根据当前配置，添加10组6块盘的RAID10磁盘(600G/10k):
![22.png](/home/attachment/201806/07/329939_152835384273152.png)
在Open Workload中，按下图进行配置：
![23.png](/home/attachment/201806/07/329939_152835386782172.png)
根据以上配置，当写带宽达到1500MB/s时，基本达到已经达到当前配置的DA卡的极限：
![33.png](/home/attachment/201806/07/329939_152835390967523.png)
在Open Workload中，再按下图进行配置评估读性能：
![44.png](/home/attachment/201806/07/329939_152835393485086.png)
根据以上配置，当读带宽达到1600MB/s时，基本达到已经达到当前配置的硬盘的极限：
![55.png](/home/attachment/201806/07/329939_152835397215387.png)
本项目最终解决方案参考：
根据以上的评估结果，当前配置情况下v7000的读性能和写性能比DS8100都要优秀，因此在SVC里建议设置虚拟卷的Primary Copy为v7000。DS8100和v7000存储读写性能对比图如下：
![66.png](/home/attachment/201806/07/329939_152835399759210.png)
# 关键设备配置算法
本项目涉及到一套高端存储（交易类所用）、一套中端存储（管理类所用）、两套存储虚拟化网关（交易类和管理类各一套）、四套SAN光纤交换机（交易类和管理类各两个）、现有DS8100硬盘扩容和现有V7000存储硬盘扩容的设备采购。下面简单说明各设备所需的配置要求：
1、高端存储：
（1）高端存储总容量>=现在交易类业务系统存储总容量*（1+50%（三年存储数据增长率））
即：现在交易类业务系统存储总容量*（1+50%（三年存储数据增长率））=11400G*1.5=17100G
若该高端存储的磁盘阵列都采用RAID10+HOT SPARE盘的话，假定购买单个磁盘容量为600G，
（2）高端存储总磁盘需求数=高端存储总容量*2/单个磁盘容量+HOT SPARE盘个数，
即：存储总容量*2/单个磁盘容量+HOT SPARE盘个数=17100G*2/600+7（7个ARRAY，每个ARRAY一个热备盘）=64个
（3）同时，高端存储主机头的计算能力不得低于4颗CPU，缓存不得低于64G，以满足并发写入对缓存的需求。
2、中端存储：
（1）中端存储总容量=高端存储总容量，以满足数据镜像的需求。
即：中端存储总容量=17100G
（2）中端存储总磁盘需求数=高端存储总磁盘需求数。
即：中端存储总磁盘需求数=64个
（3）由于中端存储不提供主要的读写需求，只作为写入的镜像复制存储，所以对主机头的CPU颗数和缓存的需求不要求太高，即缓存不低于16G即可。
3、存储虚拟化网关：
根据各存储虚拟化网关提供厂商的不同，配置也有所区别，但必须满足以下四点需求：
（1）存储虚拟化网关的软件版本需兼容所购买的高端存储、低端存储，DS8100存储和V7000存储。
（2）两套存储虚拟化网关的容量License需要分别不低于这四套存储的总容量。
（3）每套存储虚拟化网关的缓存容量大小需要不低于业务高峰并发写总吞吐量*（1+50%（三年增长率））。
（4）每套存储虚拟化网关的IO访问可进行分组，分为两组，每组都具有冗余节点。
4、SAN交换机:
目前所用SAN交换机端口数，除去存储端口，交易类为68个，管理类为58个。
交易类总端口需求数=（68+2（新购两套存储）*8（每套存储8个端口）+4（预计新购四个存储虚拟化网关节点）*4（每个节点4个端口）+4个长波模块端口）*（1+50%（三年增长率）=156个
即：每套SAN交换机的端口数>=交易类总端口需求数/2=78个，所以最好购买80端口以上的SAN交换机2套，用于交易类SAN光纤交换机架构改造。
同理管理类总端口需求数=（58+16+16+4）*1.5=141个
即：每套SAN交换机的端口数>=管理类总端口需求数/2=71个，所以最好购买80端口以上的SAN交换机2套，用于管理类SAN光纤交换机架构改造。
5、现有DS8100存储硬盘扩容：
目前管理类业务系统总存储容量为17700G，按照两年40%的增长量，届时管理类业务系统总存储容量=17700G*1.4=24780G，现有160块300GB硬盘，可增加16块300GB硬盘，以扩容至最终所需的容量。
6、现有V7000存储硬盘扩容：
V7000存储为DS8100的镜像存储，最终所需容量也为24780G，现有56块300GB硬盘，可增加32块600GB硬盘，以扩容至最终所需的容量。

# 设备清单
本项目涉及到新购存储以及服务，主要内容如下：
（1）硬件设备内容
1、硬件设备种类
A、存储，包括中端存储一套、高端存储一套
B、存储虚拟化网关，2套，每套四节点
C、SAN光纤交换机，四套
2、硬件设备配置要求
![1.png](/home/attachment/201806/07/329939_152835448075552.png)
（2）服务类内容
1、存储整合项目整体集成设计服务
提供开放平台系统存储整合项目实施前的调研、规划、测试、项目管理、风险评估、业务影响分析等现场技术支持服务。
2、存储及网络规划实施现场技术支持
新购两套中端、高端存储，现有DS8100的专业安装及升级服务，包括设备安装加电测试、逻辑配置、调通存储网络、微码升级等；存储网络规划实施服务，包括存储SAN网络架构的梳理规划、参数配置、架构调整等。
3、存储虚拟化网关规划实施现场技术支持
存储虚拟化网关专业安装服务，包括设备上架安装、初始化配置、微码升级等；存储虚拟化网关内部zone/cluster等配置规划与实施。
4、系统规划与配置现场技术支持
开放平台系统主机信息梳理，实施规划、配置调整，接入SAN网络及安装配置服务。
5、数据迁移和存储整合现场技术支持
提供基于存储虚拟化网关的系统数据存储间迁移服务，以及建立存储间的同步镜像、数据同步的服务。
6、切换测试及上线演练现场技术支持
搭建提供存储整合方案上线的模拟演练服务，发现偏差和改进方案。
7、开放平台系统存储整合上线现场技术支持
上线前后的全方位7*24小时服务。
8、新产品上线后性能优化调整
新产品使用后根据客户实际情况对产品性能进行跟踪调试，满足客户需求。
注：预计项目组10人左右，项目周期约三个月（含上线后监控及优化一个月）
# 关键设备选型
1、需求特征：
该项目的关键设备在于两套交易类存储和两套存储虚拟化网关，对于交易类存储而言，出于对现有存储品牌，现有业务系统主机兼容性、现有维保技术力量，和目前的商业信任情况，更倾向于选择IBM的存储，作为新购买存储的品牌，选择其他存储品牌，会或多或少增加该项目的难度，将来的存储运维工作也将继续加大，对现有维护人员的技术要求有所提高。所以该项目的最核心的关键设备选择即是：存储虚拟化网关。
2、选型因素：
由于目前国内外的存储厂商，在存储虚拟化网关技术上或多或少都有涉足，造成这类设备的型号和品牌繁多，设备选型难度大，为了减少选型难度，对选型中所需考虑的因素加以固定，主要包含以下三类因素：
（1）费用
分为产品费用、实施费用、存储设备费用、后续升级费用和其他费用等。
（2）功能
分为存储单点消除能力、两地三中心冗余能力、存储虚拟化能力和一些额外功能等。
（3）技术特点
分为实施、维护难度和方案的可靠性等。
3、可选方案：
目前我行所接触的厂家有两家，即IBM和飞康，所提供的方案分别为IBM的SVC存储虚拟化方案和飞康CDP连续性数据保护方案，对于这两种方案在前期均进行了详尽的沟通。
（1）飞康CDP连续性数据保护
设计思想：飞康公司根据现有的连续性数据保护需求，重点考虑了如下的设计思想：
A、最高的性价比。根据应用的实际需求，提供适宜的解决方案，在有限的资金许可范围内，提供符合上述需求的方案，并降低后续的维护成本，从而提高系统的整体性价比。
B、严格的数据一致性。
C、基于WEB、GUI（图形管理）及CLI(命令行)多种管理方式。
D、对应用系统影响最小化；自身故障对应用系统无影响。
E、实施便利，无须对应用作任何调整。
F、广泛的适用性，数据复制和应用类型、数据类型没有任何关系，支持异构的平台和存储设备。
功能目标：飞康NSS/CDP解决方案将为用户实现如下的功能目标：
A、全方位灾难防御，和分钟级数据、OS恢复。机房业务系统中面临的问题将会全面防御，包括逻辑故障。
B、高精度数据恢复能力，可以让用户恢复的数据精度在几秒中内甚至在1秒钟内。
C、生产存储故障的自动接管能力。对于使用SAN架构的两银数据库系统，可以通过飞康NSS提供的双存储功能，实现该故障下的恢复时间（RTO）为0。对于基于SAN架构使用AIX 卷管理或者veritas卷管理的系统，飞康就是作为镜像盘的方式接入的，当生产存储坏了，其镜像关系的飞康盘会马上接替使用，无需停业务。
D、随时随地灾备演练能力。
E、易于管理、易于掌握学习，在一个飞康管理控制台中，只要网络环境具备，用户可以通过飞康控制台进行远程管理。
总体架构方案：
![11.png](/home/attachment/201806/07/329939_152835453433918.png)
（2）IBM SVC存储虚拟化方案
SVC存储虚拟化的特点：
A、灵活的存储架构。对存储需求做出快速响应，存储系统不被限制于特定物理系统。 
B、应用高可用性。实现在线数据迁移，在线实现信息生命周期管理。
存储虚拟化的最大好处是数据卷可以在线方式在不同的后端存储间自由迁移，该操作对主机和应用完全透明。这样做的好处是显而易见的： 
• 比如可以将IO负载较大的应用online迁移到后端FLASH存储上，完成该应用的存储介质升级。 
• 比如A厂商存储过保，将B厂商存储接入SVC后直接在将数据从A厂商存储迁移到B厂商存储完成过保替换。而这一切操作对应用来说皆是透明无感知。 
C、异构平台数据复制。实现数据镜像，异构平台数据复制。
通过存储虚拟化，可以对外提供统一的存储数据复制(Enterprise-level Copy Services functions )功能：比如数据镜像(mirror),快照(flashcopy),克隆(clone),容灾复制等。(不再需要为这些存储单独购软件功能的license。)
D、提高资源利用率。实现存储资源共享，提高存储利用率。
THIN模式供给存储，节省物理空间利用率，存储虚拟化提升整个IT环境中存储空间的总利用率。通过SVC 的存储虚拟化方案(A block-level virtualization solution), 空间使用率可以提升到75%-80%。此时SVC后端存储将其容量空间100%分配给SVC，然后在SVC端利用分散的后端存储空间建立大存储池（POOL）对应用提供存储服务，同时数据卷可以在多个资源池(POOL)间online 进行迁移，从而大幅提升存储空间利用率和运维效率。
E、简化存储管理。一体化的存储管理，减少系统的复杂性，降低管理成本，易于建立多层次的存储系统 统一规划存储资源。
通过将不同品牌和平台块(Block)存储进行统一化管理，从而在架构层面减少单个存储的“孤立”情况。将不通品牌和型号的”孤立“存储一一接入SVC之后，所有日常SAN存储操作只需要在SVC层面统一完成，SVC 通过提供单一、统一的管理方式，从而大幅整合存储资源，提升运维体验和效率。 
总体架构方案：
![22.jpg](/home/attachment/201806/07/329939_152835455798050.jpg)
4、选型考虑因素对比：
经过对这两种方案详尽的沟通、拟定方案、报价，结合上述选型考虑的因素，最终对比如下：
![111.png](/home/attachment/201806/07/329939_152835458579805.png)
5、方案选型建议：
根据上述详尽的对比，下面列出两个方案各自的优缺点：
IBM的SVC存储虚拟化方案
优点：硬件方案，数据复制过程对主机透明，与平台、数据库类型无关，系统架构简明。软件层的功能也较丰富，方便管理。
缺点：无数据录像功能，只能降低数据物理风险，无法规避数据逻辑风险。
飞康CDP连续性数据保护方案
优点：功能丰富，除实现基本数据保护外，具有数据录像功能，可降低数据逻辑风险。
缺点：软硬结合方案，针对不同平台、不同数据库使用不同的保护方式，授权类型繁多，系统较为复杂。AIX操作系统通过主机端LVM对原数据做镜像可能会影响整体写性能。
结合本行的需要，最关注的莫过于不对生产系统主机性能和架构没有影响，对数据逻辑性风险的防范暂时需求没那么迫切，所以IBM SVC的方案更为适合我行目前的真实需求。

存储整合最佳实践存储扩容存储金融行业

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论1 条评论

hut51项目经理andyi
2019-04-29 09:47

写的非常详细，受益匪浅！

Ctrl+Enter 发表

匿名评论

金融行业存储设备升级、整合、扩容项目方案设计

添加新评论1 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料