随着信息系统的不断发展,全面优化整合现有存储平台,同时构建一个灵活先进的高可用存储架构,是保障各业务系统运行连续性的基础。我行进行的存储设备升级、整合、扩容项目,将全面优化整合现有存储平台,解决存储单点故障,提升关键数据冗余保护,优化存储系统性能,构建灵活先进的高可用存储架构,保障各业务系统的运行连续性。
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)当前开放平台系统整体架构图如下:
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读写的影响
难点分析:由于主机和存储之间多了一道存储虚拟化网关,增加了一道风险关卡,倘若这道关卡发生致命故障或者软件层面的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:
本项目涉及到一套高端存储(交易类所用)、一套中端存储(管理类所用)、两套存储虚拟化网关(交易类和管理类各一套)、四套SAN光纤交换机(交易类和管理类各两个)、现有DS8100硬盘扩容和现有V7000存储硬盘扩容的设备采购。下面简单说明各设备所需的配置要求:
1、高端存储:
(1)高端存储总容量>=现在交易类业务系统存储总容量*(1+50%(三年存储数据增长率))
即:现在交易类业务系统存储总容量(1+50%(三年存储数据增长率))=11400G1.5=17100G
若该高端存储的磁盘阵列都采用RAID10+HOT SPARE盘的话,假定购买单个磁盘容量为600G,
(2)高端存储总磁盘需求数=高端存储总容量*2/单个磁盘容量+HOT SPARE盘个数,
即:存储总容量2/单个磁盘容量+HOT SPARE盘个数=17100G2/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、需求特征:
该项目的关键设备在于两套交易类存储和两套存储虚拟化网关,对于交易类存储而言,出于对现有存储品牌,现有业务系统主机兼容性、现有维保技术力量,和目前的商业信任情况,更倾向于选择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、易于管理、易于掌握学习,在一个飞康管理控制台中,只要网络环境具备,用户可以通过飞康控制台进行远程管理。
总体架构方案:
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞12
添加新评论1 条评论
2019-04-29 09:47