商业银行存储双活20个难点解析 & SVC+全闪存存储双活架构探讨

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了商业银行存储双活20个难点解析 & SVC+全闪存存储双活架构探讨，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含10935字，纯文字阅读大概需要16分钟。

内容图文

存储双活方案设计实施是双活建设中重要且较难的一项，为帮助广大社区会员了解和攻克相关难点，社区陆续组织了多次相关交流和答疑。在最近的探讨活动中，结合SVC+全闪存存储双活架构，继续由社区专家们对存储双活相关难点问题进行了分析解答。以下是由社区专家liqxy根据探讨内容梳理的20个问答，可以为大家提供一些实践经验和思路，供参考。

Q1：存储双活的应用场景是同机房、同城还是异地？

@工行 王军：

1、同机房，或同数据中心不同机房，主要用于关键系统的本地高可用，应对盘机故障。

2、同城，用于关键系统的双活，应对盘机故障以及机房级故障。

3、异地一般不会做双活，可以用改技术来做灾备。

Q2：双活数据中心的建设路线如何来规划和实践？

@工行 王军：

1、首先要确定实施双活的目标，AS、AQ还是AA？RPO？RTO？不同的目标实施方案及成本是完全不同的。

2、其次要梳理实施双活的应用范围，双活可以带来业务连续性的保障，但同时也增加了架构的复杂度和运维的复杂性，不是所以的业务系统都需要做到双活。

3、第三，对需要做双活的业务系统进行架构分析，BS还是CS，有无负载均衡，使用什么数据库等等，分析的结果是要决定在双活架构中如何把这些因素都考虑进去。

4、双活的运维架构，如自动化切换系统，人工触发还是告警系统自动触发？两边的系统如何一体化监控？等等

5、组织架构或管理流程也要同步考虑，双活的两个站点必须要能一体化管理。

Q3：同城双活建设时注意事项有哪些？

@liqxy  bankofluoyang：

考虑到双活涉及到应用、网络、数据等多个维度，网络和数据方面容易解决一些，应用上如果是比较老的系统有些不支持分布式部署或域名访问的，所以，整体考虑，核心系统更换或改造时比较适合同步建设同城双活，这样，在前期从应用出发按照双活架构来进行规划设计，后面只需要按规划分阶段实施。

注意事项有以下几点：

1、应用必须支持分布式部署架构，并支持使用域名访问数据库。

2、生产机房和同城灾备机房链路质量要有一定保障。

3、根据监管要求，按照业务等级来规划方案，不同的等级采用不同的保护策略。

Q4：存储双活对应用层有什么要求，才能实现真正的双活？

@Target 深圳卓优数据：

1、存储双活对应用层没有要求，存储双活从层次上来讲，有几种实现方式。

一：存储层(SAN存储或NAS存储)自身，体现为免网关双活的存储设备；

二：SAN网络层，存储网关，代表性的：vPlex，SVC等；

三：卷管理软件层，代表性的lvm，veritas的SF(现在不叫这个名字了)等，其实广义上，我认为可以将ASM也可以划分为第三种方式，只是这种只适用于有限Oracle DB的场景

2、真正的双活应该是多层次的，分别对应的是容灾的6个级别(中国标准)，国际标准是7个级别的，存储双活只是最底层的，其他的还包括传输层、网络层(含负载均衡)、计算层、应用层、数据库层、安全层等。

Q5：同城双活建设时系统迁移如何进行？

@工行 王军：

1、纳入同城双活的系统，一般是业务连续性要求比较高的系统，比如核心账务系统、网上银行系统等，参照监管部门5级灾备要求确定。

2、本地高可用和同城双活在技术上还是有较大差别，需要重新设计方案的，比如本地HA机制一般需要心跳线来保障，而心跳机制是有网络延时限制的，也就是说有距离的限制，不能适用于同城这样的距离上。

3、应用系统的同城架构建好后，各自承担多少负载要看所建设的双活模式。如果是AS模式，那么同城机房是不承担业务量的。如果是AQ模式，可以把一些纯查询或报表类业务放在同城机房。如果是AA模式，理论上每个机房是可以承担50%的业务量的，当然要看两个机房资源配置是否对等了

Q6：如何避免双中心存储双活的情况下发生脑裂的情况？

@ZhuJun2014  IBM：

双活部署在同城跨双中心模式时，中间传输链路故障的发生，是不可避免的事情。

唯一能做的就是，确保仲裁在第3站点是独立部署，确保在脑裂时候，可以正确的选择出其中一个站点存活。

Q7：数据层如何避免或者减少跨中心热点数据的竞争，从而减少数据访问过程的数据冲突风险？

@王军  工行：

这是双活系统设计中的一个难点。两个站点同时对一份数据进行频繁地读写，很容易导致数据库为了一致性而牺牲性能。

一种比较简单的方式按区域分片，比如南方片的用户流量导入A中心，北方片的用户流量导入B中心，各自访问自己的记录，这样可以减少一部分数据冲突，但不彻底。

比较好的做法则是需要应用侧精心设计，同一应用在不同中心实际上业务类型不完全一致，比如一个购物系统，商品页面流量全部导入A中心，购物车流量全部导入B中心，访问的是不同表，zhe?yang可以最大限度减少数据冲突。

Q8：异地备份作为数据中心的第三份数据保护，最常用的有哪些技术？

@liqxy  bankofluoyang：

1、Oracle dataguard，带宽根据数据量大小可选择2MB-20MB专线。

2、第三方备份软件，如veritas NBU的AIR技术可将数据复制到异地机房，带宽根据数据量大小可选择2MB-20MB专线。

3、在生产机房将数据备份到NAS存储介质上，借助NAS存储设备的复制功能将数据同步到异地NAS存储设备上，带宽根据数据量大小可选择2MB-20MB专线。

以上，可根据场景和需求选择相应的解决方案。

Q9：在同城双活模式下，如何避免人为误删除文件或者数据？

@王军  工行：

站在数据库或是存储的角度，都不存在所谓误删除一说，所有的删除动作都是用户发起的合法动作。因此，为应对用户的操作错误，除了定时的备份或快照等机制外，从源头上进行控制也是有必要的，比如运维用户不得拥有高风险命令的执行权限，如必须要执行删除等危险动作，则必须要单独申请权限并双人复核。

@liqxy  bankofluoyang

双活模式下，也要加强数据备份的管理工作，最好有统一的备份系统，平时做好恢复演练。

Q10：发生故障时，应用如何进行切换，切换后的回路逻辑如何规划等等？

@王军  工行：

1、在双活数据中心的实际运行过程，一项很重要的工作是就是要做好各种情况下的应急预案，包括负载均衡类的单台服务器故障、非负载均衡的单台服务器故障、存储故障、交换机故障、整个应用故障、整个站点故障等情况。

2、重点关注的还是类似数据库这样的非负载均衡数据库，切换时要综合考虑，比如从主站点切换到备站点时，要考虑应用服务器连接到数据库服务器的配置变化。

3、CS模式和BS模式切换时会有所不同，BS应用一般采用域名访问，但CS应用一般配置IP地址，在发生切换时要特殊进行处理。

4、此外要注意，切换的方案中真正的故障切换和切换演练会是两套方案。

Q11：存储双活在同城Oracle RAC或其它系统（应用）中的成功实施案例？

@王军  工行：

1、存储双活的案例还是很多的，各个公司的产品都有，联系你的供应商让他们提供就行。

2、但结合存储双活实现应用级的双活，特别是真正的双活，案例不是很多。

3、Oracle extended RAC在Oracle官方不太推荐，技术限制也比较多，有些运营商的省级公司有实施案例。

@Target 深圳卓优数据：

首先，同城一般是指100KM以内的两个站点，然后回到问题上：

1、存储双活基本上业内的厂商都有对应的产品或者是方案，关键看场景及成功案例，各家的实现方式大相径庭，即使是同一家，也有不同的实现方式，如E家，中端和高端就是一个例子

2、存储双活在同城RAC的场景，因为RAC对时延要求很严格，而光传输的信号衰减与距离的增加成正比，网络因素不好控制，窃以为是存储双活在同城RAC最大的难点所在

3、既然是时延问题，如果所谓其他系统(应用)对时延的要求没有RAC那么高，那么案例还是挺多的，例如VMware。

Q12：Oracle RAC对存储双活间裸光纤距离的要求？

@王军  工行：

这个跟业务的负载也有关系，如果业务量非常小，TPS在100以下，光纤距离100公里问题不大。如果有10000以上的TPS，那么光纤距离最好不要超过20公里。

Q13：城商行考虑采用SVC+全闪存储双活模式性价比怎么样？

@ZhuJun2014 IBM：

从存储行业的发展趋势看，机械硬盘基本上会很快被淘汰。目前全闪存存储是发展的主要方向。

当前，全闪存存储的性价比基本上和高端+SAS磁盘相当。这主要是由于全闪存引入了压缩和除重功能，使有效容量达到3-5倍的压缩除重比，那么平均每GB的成本，就会和普通SAS磁盘相当。在性能方面，闪存对SAS磁盘基本上是碾压级别的。

另外，引入闪存后，空间和能耗下降，也会带来数据中心消耗成本的下降。综合来看，引入全闪存是一个很好的选择。

全闪存的介质，有写入寿命的限制。当前企业级全闪存的保障，都是7年。这意外着，7年内，任何闪存故障，厂商会进行替换，因此无需考虑写入寿命的问题。

故障率的对比，目前没有实际的对比数据。SAS磁盘是机械设备，闪存盘是电子设备。当前闪存存储的单盘容量很大，普通SAS磁盘的容量相对较小。对比单盘的故障率，可能闪存会更低。

闪存盘的更换流程和普通SAS盘没有明显的区别，这主要是由RAID的模式决定的。坏任何一个盘，RAID会自动rebuild，故障磁盘被隔离出来，然后再进行更换。

Q14：SVC+全闪存储双活模式下两套存储设备有没有主次关系？

@ZhuJun2014 IBM：

在Hyperswap模式下，任何一个卷有主从角色。因此，升级微码时，建议先升级备角色的存储。微码升级时，是单个控制器逐个进行切换升级，对存储整体影响有限。

在SVC+全闪存模式下，后端的全闪存的角色是对等的，因此升级任何一台存储，对上层SVC的影响很小。

如果后端闪存是F900，任何一个控制器的微码升级，上层IO影响几乎感受不到。

Q15：通过SVC进行存储双活对存储和存储链路有什么要求？

@ZhuJun2014 IBM：

如果是跨站点的双活部署，那么中间链路的带宽和响应时间，以及稳定性，对双活就非常重要。

存储层跨站点部署成双活模式，上层应用层如果也可以部署成双活模式，那么就可以确保任一站点故障，应用可以持续运行。

如果应用层部署成主备模式，那么主站点故障，应用在备站点可能需要重启，才能对外提供服务。在这种模式下，应用的RTO时间，就取决于应用的切换时间。尽管此时底层存储已经自动切换，但是上层应用的切换，才是决定RTO的关键因素。

Q16：存储双活仲裁，如阵列出现全局断电，仲裁设备如何为另一个阵列提供服务？

@ZhuJun2014 IBM：

SVC有3个仲裁。其中一个是active仲裁。如果Active仲裁的存储故障，SVC会自动从另外两个仲裁中选择一个成为Active仲裁。这个切换是内部自动选择的，对上层应用IO无影响。

Q17：关于EX RAC和SVC第三方仲裁的选择问题？

@Cid  IBM：

双活架构中，第三战点仲裁是必不可少的一个因素，而且对链路质量也有一定的要求，所以双活是IT基础架构建设中最烧钱的一个大类别。

落地到SVC，标准的最佳实践中要求是要有第三方的站点存放仲裁盘，这样才可以在发生脑裂的时候通过仲裁机制保证数据不脏；在SVC早期的版本中，仲裁盘还要求必须是FC链路，成本很高，现在的版本也支持通过IP链路进行仲裁盘部署，以节约链路成本；

但是即使这样，在实际的部署中，有第三站点可以放仲裁盘的环境并不算多，考虑到成本等问题，有一些企业在部署双活的时候将仲裁盘放在本地站点，这样一旦发生脑裂，必定是拥有仲裁盘的站点存活，当然这样是有风险的，具体如何部署还是要结合成本和业务上的连续性要求来看。

@ZhuJun2014   IBM

双活架构中，最重要的一点是要有第3站点部署仲裁。

链路的稳定性，要看运营商提供的线路质量。如果线路质量不佳，那么传输带来的抖动会直接影响到生产IO。

在Extended RAC环境中，脑裂时候，会遵从集群节点ID最小的站点存储。因此，部署时，要考虑使SVC的存活站点和Extended RAC规则一致。实际配合中，SVC的仲裁，放在集群ID小的站点，使这个站点可以获得存活权。

Q18：SVC在未来的发展是否会成为存储性能的一个瓶颈？

@ZhuJun2014 IBM：

从纯技术角度看，当前任何一个存储控制器或者虚拟化网关，都会成为闪存存储的瓶颈点。主要因为是现在闪存太快了。

但从应用的角度看，当前闪存存储的性能，达到40-50万IOPS，可以支撑绝大部分客户的需求。

反过来看看SVC的性能，可以提供5.2M随机4K Read Missed的IOPS能力，可以支撑绝大部分客户的需求。

从OLTP业务的典型IO场景看，SVC的实时压缩技术，可以做到对性能的影响很小。但在某些极端场景，比如长时间的密集写入操作，性能是会略有下降。

对于快照，SVC的实现方式是COW，如果是密集写入操作，也是有性能下降。这主要是有技术特性决定的。

引入任何一项技术，很难鱼和熊掌兼得，因此要看具体的取舍。

在大部分场景下，引入实时压缩和快照，可以带来容量的节省，实现基于时间点的保护。在极端的跑批时间点，可能由于密集的写入操作出现性能下降，可能会有一些性能损失。

如果非常在意性能损失，那么建议不要用实时压缩功能，或者在跑批前完成快照的拷贝。不建议在密集写入操作的应用上做基于指针的快照。

Q19：华为 vmware的超融合能用SVC做双活么？

@liqxy bankofluoyang：

超融合存储方面使用的是本地磁盘，自身是分布式架构，对于上层数据来说就是多个副本分布在不同的计算节点上，如果这个场景里需要做数据双活，也可以单独使用SVC作为共享存储构建双活环境。（这个观点是SVC后端接管的有独立磁盘的情况下）

＠Target  深圳卓优数据：

SVC接管的是磁盘，通过将两个磁盘组建镜像来实现底层存储的高可用，而VSAN和FusionStorage Block都是分布式存储，对Hypervisior提供的是SCSI接口，使用场景是不匹配的，不能做。（这个观点是SVC接管VSAN方式的分布式存储，是不可行的）

Q20：hadoop集群怎么做双活？

@ZhuJun2014 IBM：

通常而言，hadoop这样的集群用来跑大数据分析。这样的集群有两个特点，一个是数据可以从别处过来，另外一个是数据量很大。由于hadoop集群的数据不是OLTP类型做对外交易，因此没有做双活的必要性。

另外，hadoop集群通常不用集中存储，因此存储层做双活，和hadoop就谈不上了。如果非要做双活的话，可以考虑用gpfs这样的集群文件系统，通过gpfs来做双活。

内容总结

以上是互联网集市为您收集整理的商业银行存储双活20个难点解析 & SVC+全闪存存储双活架构探讨全部内容，希望文章能够帮你解决商业银行存储双活20个难点解析 & SVC+全闪存存储双活架构探讨所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---