|
社区最近针对城商行如何实现同城数据中心存储双活以及对数据库双活的支持，邀请专家进行问诊及交流。以下是参与交流的社区会员提出的10个典型问题，由专家和同行解答及分享经验。 1、 双活中心一般建议存储异步还是同步，两种模式对于双中心距离要求为多少？ @bbaimm88 某城商行存储架构师： 结合非重要业务与重要业务来看，不然领导觉得你是单纯谈技术，脱离了实际。 两种模式各有特色，性价比与安全性各有特色。 @summit 某城商行系统架构师： 1 、双活分应用级双活还是数据库也实现双活，如果是全双活的话，建议双中心距离不要超过 100KM ，保障裸光纤链路质量不要超过 5ms 延迟。裸光纤链路质量是双活的关键。 2 、如果只是应用级双活的话，存储和数据库的架构决定你采用什么样的复制关系。如果采用 ADG ，一般采用最大性能方式，存储复制的话一般同步和异步都可以，如果裸光纤质量不好就采用异步复制方式。同步方式如果裸光纤发生抖动可能造成 IO 的短暂 hung ，会对业务造成影响。3 、存储复制异步和同步主要依据你双活的实现方式。 @吕峰 戴尔科技金融行业中国西区高级系统工程师： 存储双活有三种块、文件和对象。块和文件双活都是以数据同步为前提的，对象通常是保证 metadata 的同步，底层文件数据做异步传输。 同步模式下主要是看业务对延迟的最大容忍度是多少，通常存储要求往返 5ms 延迟是做块存储双活的底线，距离如果按照光速计算就很远了。实际距离来说，欧洲有超过 500km 的 SAN 双活实施，国内基本都是 50km 以内。主要受制于光纤链路的皮质，包括跳数、熔纤的质量、光纤的摆放等等。 异步模式下，对距离理论上没有限制，因为对象存储大多是存放非结构化数据，通常数据量较大，带宽需要根据写入数据量的规模和能够容忍的 RPO 进行计算。 2、 两地三中心双活系统灾备切换场景和数据补录问题？ @bbaimm88 某城商行存储架构师： 数据的 RPO0 应考虑一份存储级别的双活数据，或者异步复制的数据；不能全部依赖数据库软件高可用（物理 逻辑冗余） 双活测试场景太多了，不同思路不同考虑，运营商链路，单点物理设备，系统级别，站点级别故障都要拉通测试，（分行、网点部分及全面故障）；应用系统分依赖关系（比如加密平台，短信平台失效）；还得同时考虑双中心故障引起东西流量过大的风险。 综合网络链路；各个区域路由；系统隔离级别；应用交付调度策略，从底层一层一层来解决吧！这个太广泛了，几句说不完。 建议数据层：Vplex 双活存储 OracleExtendRAC ADG ；应用 F5 DNS 或者 vsphere 双活存储 网络大二层；双活存储解决了你的数据补录问题。 @huawei851120 某农信系统工程师： 根据我们农信多年的灾备建设和切换经验，向您提出一些建议： 1. 灾备的目的：灾备的目的不是为了备份，更不是为了实现技术上的成就，花这么多的钱根本上是实现银行的业务连续性管理目标。 2. 双活的目的：有次我参加一次讲座，还没讲完，有家银行的领导就问我：“ 切换？你们都双活了还切换个啥？” 这个问题能代表很多人的疑惑。双活这个技术手段为了实现的目标是更快的恢复业务，也就是说为实现更小的 RTO 和 RPO 而已。冷备切换要 2 个小时，双活只需 10 分钟。假如你不演练的话，怎么说明你的双活建设的牛呢？你没有在 10 分钟内切换到灾备接管业务，怎么说明你们银行的钱花的值呢？冷备摆在那不是蛮好的嘛，还省钱。您想想是不是？ 3. 双活怎么切：双活的系统，演练的时候优先切换数据库，再切换应用系统。切换数据库是重点，如果失败就不用再往下切换应用系统了。Oracle 数据库的 ADG 切换效率很高，两三分钟的事情，但是你们要花 10 分钟进行检查（检查工作远比调度切换脚本更重要）。数据库切换没问题的话，再用 DNS 切换流量到灾备中心，生产端的应用根本不用停。如果检查没有问题的话，就把生产端和灾备端的应用交易日志取下来，留作监管单位来审计用。到时候你可以给他们看看， “ 领导您看，这个时候生产端的日志已经不滚动了，灾备端的交易日志还在滚动，灾备还在承接业务，说明我们交易已经成功切换到了灾备中心 ” 。你就这样讲就行了，所以生产端的应用你没有必要停到，正好用来做日志对比说明你们的战果。 4. 数据补录问题：我能熟练背诵很多监管文件，人行、银监、省金融办的文件里只是要求我们演练要以真实业务场景为前提进行切换（杜绝一些银行用桌面演练应付监管审计），从来没有哪一家监管单位要求我们非要做计划外的切换。计划外的切换，我建议你们千万不要做，就算你想做，你们行长同意吗？真出了问题，太严重，尤其现在很多交易都是 24 小时交易，通过自助设备接入完成的。如果数据真的有损失，后果不堪设想，补录非常非常麻烦。 3 、如何降低同城双活存储对广域网的依赖性？当双活存储间的广域网线路抖动或者一些链路报错时，如何排查原因？由于双活存储的延时，如何判断哪些业务支持双活存储应用环境？ @bbaimm88 某城商行存储架构师： 第一问：双活存储主要依赖裸纤 SAN 级联网络， 仲裁网依赖 广域网，也有的双活仲裁采用 fc 网络；仲裁建议部署第三站点来降低依赖与风险。 第二问：广域网线路抖动，也是运管上光纤不稳定吧；一是采用多级光纤线路，二是需要 san 交换机支持 光衰大，不稳定时 自动屏蔽；思科的 san 支持。排查原因主要交给网路链路监控；以及 san FC 监控告警； 第三问：双活存储的延时 一般 2-3ms 以内 业务都可用吧， 要是你的 存储延时很高，恐怕距离太远，或者集成质量很差；这种场景一般要避免；既然存储双活了。理论业务都可以用。 @吕峰 戴尔科技金融行业中国西区高级系统工程师： DWDM 设备能够检测到链路抖动并自动报警。 SAN 光纤交换机配置 “ Port Fencing ” 功能，自动检测链路抖动并关闭 FC 端口，从而隔离链路抖动。 IP 网络设备应用 “ 快速收敛实现检测（ BFD ） ” 技术，自动检测并关闭抖动链路口，从而隔离链路抖动。 存储虚拟化网关的 WAN COM I/O 模块能够自动检测链路抖动并关闭端口，从而隔离链路抖动。 4、存储双活仲裁架构设计的关键点有哪些？ @bbaimm88 某城商行存储架构师： 采用第三站点仲裁最佳；方式有 IP 网络与 FC 网络。 @吕峰 戴尔科技金融行业中国西区高级系统工程师： 主要是两个问题： 1 、仲裁位置的摆放，最好是第三站点，这在极端故障情况下更能够最大限度保障存储可用； 2 、网络问题，双活仲裁有些是通过管理网络实现的，比如 DELLEMC 的双活，只要 IP 网络通就行了，但是有一些是通过存储虚拟化的方式来实现，这就需要 SAN 网络通，当然可以采用 IPSAN 的这折中方式，但是从实际经验看，存储虚拟化方式对带宽的需求略大。有客户处有 DELLEMC 和友商的双活同时跑的情况，同样的带宽大小， DELLEMC 的双活仲裁正常进行，友商的就不断报错，最后通过升级带宽解决了问题。 5、存储双活如何管控，如何制定匹配制度？ @bbaimm88 某城商行存储架构师： 双活管理的确是个难题，我们也存人手不够，通过补充对口技术人才，执行 AB 角互备，数据库、存储、主机、应用负载、网路、安全各司其职；同时我上了一套容灾切换软件专门解决 oracleExtendRAC 切换及 AIX 个别应用容灾切换；释放 DBA 排错压力，专注监控定位，提供指引； 应用切换基于 DNS 不需要太多人工干预；存储双活建有第三站点来保障仲裁；减少疑难场景仲裁人工分析。但也只能仅仅满足现状，无法应对互联网金融业务发展，这个要上 devops ，推行 IAAS 解决方案来释放人力压力 @吕峰 戴尔科技金融行业中国西区高级系统工程师： 灾备建设是一个系统工程，这个工程中最难的不是技术问题，是管理和沟通问题，特别是与非科技背景的高级别领导展示、解释的问题。 就像您说的管理问题，很多行采用了类似的技术架构但是采用了不同的管理方法，为什么？因为每个行的情况都不相同，管理很大程度是跟领导风格相挂钩的，要形成有效的管理不能简单看别人穿什么衣服的问题，大多数时候是需要量体裁衣。这也是为什么很多行在做灾备咨询。除了专业技能，咨询更多的是帮助沟通。 6、存储双活后，备份的数据如何有效的开展定期的恢复验证工作？ @吕峰 戴尔科技金融行业中国西区高级系统工程师： 备份和存储双活是相辅相成的两条线，备份数据主要是聚焦在逻辑故障的恢复。恢复验证需要根据不同的场景指定不同的应对措施，数据库可以通过脚本配合备份软件拉起验证。非结构化数只有人去验证。DELLEMC 的 Datadomain 自身具备数据有效性的算法，内部自动检备份数据是否有效。 @bbaimm88 某城商行存储架构师： 上双活了，建议配套上备份系统，从备份系统抽取数据来循环恢复验证，若没有备份系统，我只能告诉你，你们得自己写脚本来热备或者冷备，这个工程太大了，亏人力。我们使用备份系统，然后配置了数据库自动恢复环境，一键恢复到验证环境，虚拟机及也采用自动恢复，或者立即拉起。大大减少人力，效率大大提高。 7 、 双活环境下，银行夜间批量任务（含数据库全表更新步骤）对交易成功率有较大直接影响，如何调优？ @bbaimm88 某城商行存储架构师： 批量属于 OLAP 业务处理，交易属于 OLTP 业务处理。在跑批期间影响交易，这个从底层 OS 、 DB 是无法完美解决，需要软件的开发来设计，应对高峰的批量业务保障业务进行，很多跑批结算日是自定义日结切换时间，比如核心切换是每天 11 ：30 分，其他业务也随之同步切换日切记账。通过应用逻辑设计来规避数据表竞争，解决表竞争就能很好解决交易业务问题。这个涉及的业务改造就比较大，跑批涉及表可以适当引入分区表适当解决表竞争。 @吕峰 戴尔科技金融行业中国西区高级系统工程师： 个人理解交易成功率降低大概率是数据写入出现了问题，首先采集数据库、主机、网络（主要是双活同步网络）和底层存储的日志，然后分析跑批期间的有没有出现资源利用率过高导致写入受到严重影响的环节，具体分析后才能进行有效的调整。 所有的双活和同步复制都要求写数据在两个设备的一致写入，跑批期间有大量的过程数据写入，都会面临比较大的挑战。我曾经碰到过一家行因为复制链路带宽过低导致大量 IO 拥塞导致出现问题，通过带宽扩容解决了问题。但是，前提还是前面说的，找到问题的原因才能优化。 8 、双中心二层网络必要性？ 【问题描述】银行同城应用级灾备或同城双活级灾备的场景下，在暂时不考虑多活数据中心的前提下，使用网络大二层打通的架构是否合适？这种场景下网络大二层打通是否还是架构的趋势？ @bbaimm88 某城商行存储架构师： 没有全局负载均衡均衡调度的话，大二层还是可以的，双活存储 大二层 vsphere 虚拟化方案，是一种解决方案。 但是网络压力较大，最好还是建设居于 DNS 的双活应用调度。大二层不是趋势，是一种解决方案。 9 、如果想实现 oracle 数据库同城双活和存储同城双活，对 IP 网络和 SAN 网络有哪些硬性要求？通过哪些指标进行评估？ @bbaimm88 某城商行存储架构师： 存储同城双活，硬性要求：1 、建议五大厂商选（推荐带虚拟网关方案例如 vplex ）；2、机房选址不宜过远（ 20KM 以内可保证光延时约 1ms ）；3、建设需要裸光纤（强烈建议）；4、最好自购波分设备，sSAN 网络交换机带光衰检查判断。 Oracle 数据库同城双活，这是个大难题，主要受限于网络延时要越低越好，数据库 TPS 小可以双中心并行跑 RAC ， TPS 高的又要双中心并行跑 RAC 对环境极为苛刻（心跳通信压力很大）这种适合 3-5KM 以内（国外很多这种案例），这种建议选高端成熟解决方案，推荐全闪存。 若建设 ExtendRAC ，实现主中心 Active ，另一中心 RAC 节点 standby ，这个是一个折中选择方案。可以保证 RPO 为 0 ， RTO 分钟级别。 10 、跨中心应用双活 web/app 的具体部署模式？ @bbaimm88 某城商行存储架构师： 你这有 GSLB 实现跨中心分发，应用减少东西流量，尽量保持都是南北流量。双中心间减少 web 与 app 的交叉访问。除非系统故障出现。跨中心交叉访问对跨中心流量堆叠太高，不利于网络管理。 |
|
|
