基于SVC+全闪存存储的商业银行存储双活活动总结

字数 6273阅读 1816评论 0赞 3

近年来，在城商行核心等关键业务存储使用上，主要出现了以下几点问题：

1. 传统的城商行在核心关键系统上对分布式存储等技术和产品在成熟度、稳定性、高可用性等方面还存在一定质疑，只能还在传统存储产品内进行小步伐前进，传统非闪存存储的性能目前基本已经无法满足中等城商行在日终批量、日间高并发时的需求，这是技术改革和性能方面的不足；

2. 在现有存储面临超期服役的情况下，更换什么存储，如何更换，在在大限度降低RTO时间的情况下保证数据可用且不丢失，是最为关键的问题，这是存储产品和业务连续性方面的问题；

3. 目前多数城商行关键存储设备可能多套存储，也可能是多家存储厂商的不同型号的存储，各自之间单独管理，没有整合优化，这是在运维角度的问题；

4. 尽管目前各家成熟的存储厂商都推出了先进的存储的两地三中心双活方案，但各自技术成熟度、高可用性、极端情况下的脑裂发生概率等都是重要的技术关注点，这是双活方面；

基于以上几点问题，我们引出今天的主题：SVC+全闪存存储的存储双活架构方案。

全闪存存储的出现，对于IO性能方面来说是一次很大的进步，IOPS从原有存储的十几万提高到现在的近百万，可以说完全满足目前中大型城商行的读写要求。

IBM SVC的出现实现了存储整合优化，一是整合所有异构存储，统一管理调度；二是通过SVC接管存储，极大地降低了在存储更换过程中核心关键业务的计划内RTO时间，同时完全避免了数据丢失风险；三是IBM SVC的Hyperswap技术实现了基于存储的同城双活方案。

SVC+全闪存存储的存储双活架构方案在性能、容灾、运维管理方面是解决了目前城商行在存储使用上的种种问题，是目前最为先进成熟的架构。

因此，为了帮助大家更好地了解基于SVC+全闪存存储的商业银行存储双活方案，我们此次主要从以上几点出发，探讨该技术架构的原理和优势，同时，希望大家踊跃提问和分享，从不同角度，共同探讨这种技术架构。
活动中大家非常积极，踊跃提问，现对本次活动的问题及分享总结如下：

# Q：关于EX RAC和SVC第三方仲裁的选择问题？
A：双活架构中，第三战点仲裁是必不可少的一个因素，而且对链路质量也有一定的要求，所以双活是IT基础架构建设中最烧钱的一个大类别。
落地到SVC，标准的最佳实践中要求是要有第三方的站点存放仲裁盘，这样才可以在发生脑裂的时候通过仲裁机制保证数据不脏；在SVC早期的版本中，仲裁盘还要求必须是FC链路，成本很高，现在的版本也支持通过IP链路进行仲裁盘部署，以节约链路成本；
但是即使这样，在实际的部署中，有第三站点可以放仲裁盘的环境并不算多，考虑到成本等问题，有一些企业在部署双活的时候将仲裁盘放在本地站点，这样一旦发生脑裂，必定是拥有仲裁盘的站点存活，当然这样是有风险的，具体如何部署还是要结合成本和业务上的连续性要求来看。

# Q：存储双活的应用场景？（同机房、同城还是异地）？
A：1、同机房，或同数据中心不同机房，主要用于关键系统的本地高可用，应对盘机故障。
2、同城，用于关键系统的双活，应对盘机故障以及机房级故障。
3、异地一般不会做双活，可以用改技术来做灾备。

# Q：同城双活建设时注意事项有哪些？
A：考虑到双活涉及到应用、网络、数据等多个维度，网络和数据方面容易解决一些，应用上如果是比较老的系统有些不支持分布式部署或域名访问的，所以，整体考虑，核心系统更换或改造时比较适合同步建设同城双活，这样，在前期从应用出发按照双活架构来进行规划设计，后面只需要按规划分阶段实施。
注意事项有以下几点：
1、应用必须支持分布式部署架构，并支持使用域名访问数据库。
2、生产机房和同城灾备机房链路质量要有一定保障。
3、根据监管要求，按照业务等级来规划方案，不同的等级采用不同的保护策略。

# Q：比如华为 vmware的超融合能用svc做双活么？
A：超融合存储方面使用的是本地磁盘，自身是分布式架构，对于上层数据来说就是多个副本分布在不同的计算节点上，如果这个场景里需要做数据双活，也可以单独使用SVC作为共享存储构建双活环境。（这个观点是SVC后端接管的有独立磁盘的情况下）
SVC接管的是磁盘，通过将两个磁盘组建镜像来实现底层存储的高可用，而VSAN和FusionStorage Block都是分布式存储，对Hypervisior提供的是SCSI接口，使用场景是不匹配的，不能做。（这个观点是SVC接管VSAN方式的分布式存储，是不可行的）

# Q：在同城双活模式下，如何避免人为误删除文件或者数据？
A：站在数据库或是存储的角度，都不存在所谓误删除一说，所有的删除动作都是用户发起的合法动作。因此，为应对用户的操作错误，除了定时的备份或快照等机制外，从源头上进行控制也是有必要的，比如运维用户不得拥有高风险命令的执行权限，如必须要执行删除等危险动作，则必须要单独申请权限并双人复核。
双活模式下，也要加强数据备份的管理工作，最好有统一的备份系统，平时做好恢复演练。

# Q：同城双活建设时系统迁移如何进行？
A：1、纳入同城双活的系统，一般是业务连续性要求比较高的系统，比如核心账务系统、网上银行系统等，参照监管部门5级灾备要求确定。
2、本地高可用和同城双活在技术上还是有较大差别，需要重新设计方案的，比如本地HA机制一般需要心跳线来保障，而心跳机制是有网络延时限制的，也就是说有距离的限制，不能适用于同城这样的距离上。
3、应用系统的同城架构建好后，各自承担多少负载要看所建设的双活模式。如果是AS模式，那么同城机房是不承担业务量的。如果是AQ模式，可以把一些纯查询或报表类业务放在同城机房。如果是AA模式，理论上每个机房是可以承担50%的业务量的，当然要看两个机房资源配置是否对等了

# Q：数据层如何避免或者减少跨中心热点数据的竞争，从而减少数据访问过程的数据冲突风险？
A：这是双活系统设计中的一个难点。两个站点同时对一份数据进行频繁地读写，很容易导致数据库为了一致性而牺牲性能。
一种比较简单的方式按区域分片，比如南方片的用户流量导入A中心，北方片的用户流量导入B中心，各自访问自己的记录，这样可以减少一部分数据冲突，但不彻底。
比较好的做法则是需要应用侧精心设计，同一应用在不同中心实际上业务类型不完全一致，比如一个购物系统，商品页面流量全部导入A中心，购物车流量全部导入B中心，访问的是不同表，zhe yang可以最大限度减少数据冲突。

# Q：存储双活在同城Oracle RAC或其它系统（应用）中的成功实施案例？
A：1、存储双活的案例还是很多的，各个公司的产品都有，联系你的供应商让他们提供就行。
2、但结合存储双活实现应用级的双活，特别是真正的双活，案例不是很多。
3、Oracle extended RAC在Oracle官方不太推荐，技术限制也比较多，有些运营商的省级公司有实施案例。

首先，同城一般是指100KM以内的两个站点，然后回到问题上：
1：如楼上王总讲的，存储双活基本上业内的厂商都有对应的产品或者是方案，关键看场景及成功案例，各家的实现方式大相径庭，即使是同一家，也有不同的实现方式，如E家，中端和高端就是一个例子
2：存储双活在同城RAC的场景，因为RAC对时延要求很严格，而光传输的信号衰减与距离的增加成正比，网络因素不好控制，窃以为是存储双活在同城RAC最大的难点所在
3：既然是时延问题，如果所谓其他系统(应用)对时延的要求没有RAC那么高，那么案例还是挺多的，例如VMware。

# Q：异地备份作为数据中心的第三份数据保护，最常用的有哪些技术？
A：1、Oracle dataguard，带宽根据数据量大小可选择2MB-20MB专线。
2、第三方备份软件，如veritas NBU的AIR技术可将数据复制到异地机房，带宽根据数据量大小可选择2MB-20MB专线。
3、在生产机房将数据备份到NAS存储介质上，借助NAS存储设备的复制功能将数据同步到异地NAS存储设备上，带宽根据数据量大小可选择2MB-20MB专线。
以上，可根据场景和需求选择相应的解决方案。

# Q：存储双活对应用层有什么要求，才能实现真正的双活？
A：1：存储双活对应用层没有要求，存储双活从层次上来讲，有几种实现方式，一：存储层(SAN存储或NAS存储)自身，体现为免网关双活的存储设备；二：SAN网络层，存储网关，代表性的：vPlex，SVC等；三：卷管理软件层，代表性的lvm，veritas的SF(现在不叫这个名字了)等，其实广义上，我认为可以将ASM也可以划分为第三种方式，只是这种只适用于有限Oracle DB的场景
2：真正的双活应该是多层次的，分别对应的是容灾的6个级别(中国标准)，国际标准是7个级别的，存储双活只是最底层的，其他的还包括传输层、网络层(含负载均衡)、计算层、应用层、数据库层、安全层等。

# Q：发生故障时，应用如何进行切换，切换后的回路逻辑如何规划等等？
A：1、在双活数据中心的实际运行过程，一项很重要的工作是就是要做好各种情况下的应急预案，包括负载均衡类的单台服务器故障、非负载均衡的单台服务器故障、存储故障、交换机故障、整个应用故障、整个站点故障等情况。
2、重点关注的还是类似数据库这样的非负载均衡数据库，切换时要综合考虑，比如从主站点切换到备站点时，要考虑应用服务器连接到数据库服务器的配置变化。
3、CS模式和BS模式切换时会有所不同，BS应用一般采用域名访问，但CS应用一般配置IP地址，在发生切换时要特殊进行处理。
4、此外要注意，切换的方案中真正的故障切换和切换演练会是两套方案。

# Q：存储双活仲裁，如阵列出现全局断电，仲裁设备如何为另一个阵列提供服务？
A：SVC有3个仲裁。其中一个是active仲裁。如果Active仲裁的存储故障，SVC会自动从另外两个仲裁中选择一个成为Active仲裁。这个切换是内部自动选择的，对上层应用IO无影响。

# Q：如何避免双中心存储双活的情况下发生脑裂的情况？
A：双活部署在同城跨双中心模式时，中间传输链路故障的发生，是不可避免的事情。
唯一能做的就是，确保仲裁在第3站点是独立部署，确保在脑裂时候，可以正确的选择出其中一个站点存活。

# Q：通过SVC进行存储双活对存储和存储链路有什么要求？
A：如果是跨站点的双活部署，那么中间链路的带宽和响应时间，以及稳定性，对双活就非常重要。
存储层跨站点部署成双活模式，上层应用层如果也可以部署成双活模式，那么就可以确保任一站点故障，应用可以持续运行。
如果应用层部署成主备模式，那么主站点故障，应用在备站点可能需要重启，才能对外提供服务。在这种模式下，应用的RTO时间，就取决于应用的切换时间。尽管此时底层存储已经自动切换，但是上层应用的切换，才是决定RTO的关键因素。

# Q：SVC+全闪存储双活模式下两套存储设备有没有主次关系？
A：在Hyperswap模式下，任何一个卷有主从角色。因此，升级微码时，建议先升级备角色的存储。微码升级时，是单个控制器逐个进行切换升级，对存储整体影响有限。
在SVC+全闪存模式下，后端的全闪存的角色是对等的，因此升级任何一台存储，对上层SVC的影响很小。
如果后端闪存是F900，任何一个控制器的微码升级，上层IO影响几乎感受不到。

# Q：城商行考虑采用SVC+全闪存储双活模式性价比怎么样？
A：从存储行业的发展趋势看，机械硬盘基本上会很快被淘汰。目前全闪存存储是发展的主要方向。
当前，全闪存存储的性价比基本上和高端+SAS磁盘相当。这主要是由于全闪存引入了压缩和除重功能，使有效容量达到3-5倍的压缩除重比，那么平均每GB的成本，就会和普通SAS磁盘相当。在性能方面，闪存对SAS磁盘基本上是碾压级别的。
另外，引入闪存后，空间和能耗下降，也会带来数据中心消耗成本的下降。综合来看，引入全闪存是一个很好的选择。
全闪存的介质，有写入寿命的限制。当前企业级全闪存的保障，都是7年。这意外着，7年内，任何闪存故障，厂商会进行替换，因此无需考虑写入寿命的问题。
故障率的对比，目前没有实际的对比数据。SAS磁盘是机械设备，闪存盘是电子设备。当前闪存存储的单盘容量很大，普通SAS磁盘的容量相对较小。对比单盘的故障率，可能闪存会更低。
闪存盘的更换流程和普通SAS盘没有明显的区别，这主要是由RAID的模式决定的。坏任何一个盘，RAID会自动rebuild，故障磁盘被隔离出来，然后再进行更换。

# Q：Oracle RAC对存储双活间裸光纤距离的要求？
A：这个跟业务的负载也有关系，如果业务量非常小，TPS在100以下，光纤距离100公里问题不大。如果有10000以上的TPS，那么光纤距离最好不要超过20公里。

# Q：svc的在未来的发展是否会成为存储性能的一个瓶颈？
A：从纯技术角度看，当前任何一个存储控制器或者虚拟化网关，都会成为闪存存储的瓶颈点。主要因为是现在闪存太快了。
但从应用的角度看，当前闪存存储的性能，达到40-50万IOPS，可以支撑绝大部分客户的需求。
反过来看看SVC的性能，可以提供5.2M随机4K Read Missed的IOPS能力，可以支撑绝大部分客户的需求。

从OLTP业务的典型IO场景看，SVC的实时压缩技术，可以做到对性能的影响很小。但在某些极端场景，比如长时间的密集写入操作，性能是会略有下降。
对于快照，SVC的实现方式是COW，如果是密集写入操作，也是有性能下降。这主要是有技术特性决定的。
引入任何一项技术，很难鱼和熊掌兼得，因此要看具体的取舍。
在大部分场景下，引入实时压缩和快照，可以带来容量的节省，实现基于时间点的保护。在极端的跑批时间点，可能由于密集的写入操作出现性能下降，可能会有一些性能损失。
如果非常在意性能损失，那么建议不要用实时压缩功能，或者在跑批前完成快照的拷贝。不建议在密集写入操作的应用上做基于指针的快照。

# Q：hadoop集群怎么做双活？
A：通常而言，hadoop这样的集群用来跑大数据分析。这样的集群有两个特点，一个是数据可以从别处过来，另外一个是数据量很大。由于hadoop集群的数据不是OLTP类型做对外交易，因此没有做双活的必要性。
另外，hadoop集群通常不用集中存储，因此存储层做双活，和hadoop就谈不上了。如果非要做双活的话，可以考虑用gpfs这样的集群文件系统，通过gpfs来做双活。

# Q：双活数据中心的建设路线如何来规划和实践？
A：1、首先要确定实施双活的目标，AS、AQ还是AA？RPO？RTO？不同的目标实施方案及成本是完全不同的。
2、其次要梳理实施双活的应用范围，双活可以带来业务连续性的保障，但同时也增加了架构的复杂度和运维的复杂性，不是所以的业务系统都需要做到双活。
3、第三，对需要做双活的业务系统进行架构分析，BS还是CS，有无负载均衡，使用什么数据库等等，分析的结果是要决定在双活架构中如何把这些因素都考虑进去。
4、双活的运维架构，如自动化切换系统，人工触发还是告警系统自动触发？两边的系统如何一体化监控？等等
5、组织架构或管理流程也要同步考虑，双活的两个站点必须要能一体化管理。

同城双活存储双活双活

著作权归作者所有

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

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

基于SVC+全闪存存储的商业银行存储双活活动总结

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料