商业银行存储双活20个难点解析 & SVC+全闪存存储双活架构探讨
作者：互联网
存储双活方案设计实施是双活建设中重要且较难的一项，为帮助广大社区会员了解和攻克相关难点，社区陆续组织了多次相关交流和答疑。在最近的探讨活动中，结合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来做双活。
标签：存储,闪存,SVC,站点,仲裁,双活 来源： https://blog.51cto.com/u_15127582/2757048