在2021年2月7日,中国人民银行发布了《金融信息系统多活技术规范》,将其作为指导金融行业标准。可以说金融业关系国计民生,维护金融信息系统安全是国家信息安全的重点,因发生灾难导致金融服务中断,可能对企业内部管理、公民、法人和其他组织的金融权益甚至国家金融稳定和秩序产生影响。为规范和引导在金融信息系统合理运用多活技术实现业务承载和灾难恢复,有效防范金融信息系统风险,保护金融机构客户的合法权益,特编制这一标准。本文针对这一标准并结合外部实践经验进行探讨。
❖ 冷备
为了解决应用及数据单点问题,最初引入了冷备技术。这里谈到的冷备包含多层含义。原始的需求,就是将数据放在异地进行备份。当主环境出现问题时,可利用异地备份还原数据即可。整个业务恢复时间取决于数据恢复时间及重新部署应用的时间。为了解决应用部署问题,后续将应用在异地进行部署,但不启动,这样解决了应用部署问题。为解决恢复数据时间问题,可通过数据库的主从复制技术,提升数据完整度及故障恢复能力。无论上述如何改进,本质上来说都是冷备技术,备的部分不提供访问能力,存在一定的资源浪费。
❖ 主备
为解决上面资源浪费问题,出现了主备技术。其基本结构上与冷备差异不大,更多是在备角色的使用上面。通过将部分应用部署到备,充分利用备的资源。但受到数据同步限制,无法做到完美一致性,同时是考虑将备充当读取业务的承载,来分担主业务压力的同时,利用备的资源。为了充分利用备的应用能力,可以启用备的写应用,但是数据访问上仍然是访问主的数据。这种方式可以加快故障后的切换速度,同时也能启动一定的验证作用;但这种架构也有一个问题,就在于应对较大范围故障问题存在不足,当发生如机房级故障时无法做到切换。
❖ 多活(双活)
主备架构容灾能力有限,也促生了多活架构。所谓多活架构,简单来说是应用系统与基础架构配合,通过将业务处理单元化实现更大范围的容灾能力。根据实现方式可分为同城双活和异地多活两种方式。这部分是本文的重点,后面会详细说明。下图来自阿里分享案例。
在传统容灾系统设计中,多采用主备方式。但从长期发展来看,其正向多活技术演进,其主要驱动因素有:
对于主备方式,当灾难事件发生后,灾难备份系统接管业务往往需要经过较长的时间,而当前业务的特点对业务连续性提出了更高的要求。特别像金融行业,对可用性要求非常高。
对于主备方式,灾难备份系统在正常情况下并不承载真实业务,其真实接管能力难以有效评估,因对其接管能力的评估主要依赖于灾难恢复预案的制定、管理及演练效果,故一旦灾难发生,灾难备份系统是否可接管真实业务难以保证。
由于各方面的限制,单数据中心的扩展能力往往存在瓶颈,或者持续扩展能力的经济效益降低。
灾难备份系统在正常情况下不承载业务,资源浪费严重。
主备方式是在传统技术架构的背景下提出的,而云计算、分布式等先进技术的成熟和应用推广,为信息系统灾难恢复能力的升级提供了技术支撑。
对于覆盖地理范围较广的业务系统,部分用户业务接入的距离过长,可能由于处理延迟带来用户体验的下降。
解读:何为“多活”
应用系统部署在多个地理节点,各地理节点的位置选择宜综合考虑电力、网络、供水等基础设施的容灾因素,包括独立的空调、电力设施、计算、网络、存储等物理资源。如上图中部署单元,应部署在不同地理节点中。
根据地理节点的相对位置不同,多活系统的布局模式可分为同城多活和异地多活。
各部署单元同时支持业务接入,并支持灵活调整业务接入,部分地理节点灾难故障不影响其他地理节点上部署单元的业务接入。
各部署单元同时支持处理业务逻辑,并支持灵活调整,部分地理节点灾难故障不影响其他地理节点上部署单元的业务处理。
各部署单元同时提供数据存储,且保证其他部署单元存在与业务处理结果一致、可用的数据副本。部分地理节点灾难故障不影响其他地理节点上部署单元的数据存储。
当某个部署单元发生灾难故障时,只有部分业务受到影响并需要分配到其他部署单元进行处理。当发生非区域性灾难时,同城多活部署单元可及时接管业务;当发生区域性灾难时,异地多活部署单元在较短时间内接管业务。
❖ 应用接入要求
❖ 业务接入层要求
❖ 业务处理层要求
❖ 数据存储层要求
部署单元的关键指标包括多活业务集中度、多活同城业务集中度、多活业务接管时间、多活数据恢复点目标、多活接管容量能力,这些关键指标共同决定了多活信息系统应对灾难的能力。
用于衡量业务在各个部署单元之间的分散程度,降低多活业务集中度可降低单一部署单元灾难或故障的业务影响范围。例如:多活业务集中度为 25%,其可能实现方式是部署 4 个部署单元,并且在各部署单元间平均分配业务接入流量、业务处理流量和数据存储量,当任何一个部署单元发生灾难或故障,受影响的业务均不超过全部业务的 25%,其余的业务不受任何影响。
用于衡量业务在各个不受同一区域性灾难影响的地理区域间的分散程度,降低同城业务集中度可降低区域性灾难的业务影响范围。例如:多活同城业务集中度为50%,可能的实现方式是两个地理区域分别部署两个部署单元,并且在四个部署单元间平均分配业务接入流量、业务处理流量和数据存储量;其他可能的实现方式是双活信息系统,两个部署单元部署在不同的地理区域,平均分配业务接入流量、业务处理流量和数据存储量。对于上述两种实现方式,均满足任何一个区域性灾难发生后,受影响的业务不超过全部业务的 50%,其余的业务不受任何影响。
用于衡量灾难发生后,对受到影响的部署单元业务流量重新分配并由其他部署单元接管的时间。降低多活业务接管时间,可减少灾难引起的业务(部分业务)的中断时间。
用于评价当发生灾难或故障时,部署单元中受影响的数据应恢复到的时间点要求。
用于衡量灾难发生后,部署单元承载受影响业务的能力,可用部署单元能承载受影响业务的百分比表示。例如,设定在单一部署单元故障时,其他部署单元可接管 100%的业务;设定对于任何区域性灾难,其他部署单元可接管其 50%的业务。为了达到上述要求,需要合理分配部署单元的冗余容量,同时还要考虑冗余容量在各个部署单元之间的分布,以及冗余容量在不同地理区域之间的分布。
❖ 应用场景分析
向多活演进前提是进行业务影响分析,确定采用多活技术的业务范围及其承载系统,然后评估向多活演进的可行性。
❖ 业务范围分析
在向多活演进的业务范围分析中,重点关注如下内容:
❖ 可行性分析
在向多活信息系统演进的可行性分析中,重点关注如下内容:
根据业务发展的不同阶段对金融信息系统业务连续性和灾难恢复的要求,金融信息系统向多活信息系统的演进路线大致会经历如下几个阶段,如图:
对系统关键数据进行同城或异地备份。数据备份的周期可是实时或者定期。生产中心发生灾难时,在灾备中心临时部署应用系统,加载关键数据,恢复业务服务。
在同城或异地中心部署灾备系统,并在生产中心和灾备中心间建立数据同步,同步周期可实时或定期。日常由生产系统提供服务,生产系统发生灾难时,由灾备系统接管服务。灾备系统启动通常包括启用灾备中心系统环境、启动应用、加载数据、连通性验证等工作。为了提高资源的利用效率,在日常情况下充分利用灾备系统。部分金融信息系统在上述方式的基础上,由灾备系统同时提供查询服务,当发生灾难事件时,由灾备系统接管服务。灾备系统接管服务通常包括暂停数据库异步复制、修改灾备系统数据库状态、启动灾备系统应用环境、流量切换等工作。
从主备阶段向双活或多活演进的过程需要大量的业务梳理、系统能力评估、业务影响分析、风险分析等相关工作,还涉及到应用系统改造,对于不同的业务现状和系统现有架构情况,存在很大的差异。最核心的工作涉及到将原有生产系统上的应用和数据进行拆分,并且根据拆分规则建立新的数据同步关系,同时实现应用并行业务处理相关的改造等,在拆分的过程需要额外注意数据的备份,并且具备出现异常后的回退机制。从架构上看,双活可作为多活架构的一种特例来设计,但对于同城与异地则存在较大差异。下表简单总结两者区别:
下文根据金融行业特点,抽象出若干种场景,分析其多活策略。
流水型系统实现实时支付、证券交易、订单等业务的发起方和接收方之间的转接功能。典型的流水型系统是银行渠道系统、转接清算系统、非银行支付机构的快捷支付(协议支付)系统等。对于此类系统,业务请求和业务请求响应需要实时转发至业务发起方和业务接收方,对系统的实时性有较高的要求,但关键数据(如交易涉及的账户数据)的一致性由业务发起方和接收方保证,流水型系统对业务的流水信息进行记录。流水型系统的幂等性处理是架构设计的重点和难点,可采用多层幂等保障机制,如用户发起业务流量环节幂等、实时业务处理环节幂等、交易对账环节幂等。采用多活技术的流水型系统,可实现业务流水信息(如订单信息、交易信息等)的多点存储和业务的多点转接,各部署单元分担流量,并且在部分部署单元发生灾难或故障时,其他部署单元仍可接管业务流水信息记录和业务转接。对于处于重要业务处理路径上的流水型系统,采用多活技术可避免因流水型系统的灾难或故障造成重要业务的全业务流程中断。
账户型系统主要实现账户信息、用户信息等业务数据的处理和记录。此类系统需要优先保障关键数据的一致性,当灾难或故障发生时,应在达到关键数据一致性的前提下,实现业务可用性。账户型系统的数据一致性是架构设计的重点和难点,应结合业务模型选择解决方案,如关键数据采用同步复制等手段、将只读数据和可写数据分离、业务处理层与数据存储层协调工作等。采用多活技术的账户型系统,可根据需要设计各部署单元的并行策略,将账户拆分到多个部署单元,并行进行账务处理。当故障或灾难事件发生时,只有部分账户受到影响,并将其业务流量变更至其他多活子信息系统。
计算型系统实现清分清算、风险控制、商户结算等相关的计算,还包括金融领域的各种科学、工程、数据分析、音视频处理等相关的计算。此类系统对输入的业务进行计算,并将结果输出至其他系统,计算过程所需数据全部来源于单次计算业务请求或外部系统。此类系统重点保障计算应用的可用性和准确性。采用多活技术的计算型系统,可实现多点计算、多点输出结果。这样可将多个部署单元的输出结果相互核对,提高准确性,还可在部分部署单元灾难或故障时,直接取用其余部署单元的计算结果。在一些场景下,计算所需数据可能分散在分布式系统中,可能会采用多层级计算再汇总计算的方式。
查询型系统实现对用户提供各种用户信息、交易记录、交易行情、订单记录、发布信息等相关查询。此类系统中的查询应用不会对系统存储的数据进行修改(或者查询业务流量比率远远大于有数据写入和修改的业务流量的系统),数据主要由外部系统导入。此类系统重点保障查询应用的可用性,以及被查询数据的多副本存储、被查询数据的多副本之间的一致性,以保证各多活子系统查询结果相同。采用多活技术的查询型系统,可实现多点查询。多个部署单元之间可分担查询流量,并且在部分部署单元出现灾难或故障时,可通过其他部署单元查询信息。
异地多活,是为了保证业务的高可用。所以本质上,还是要看业务的高可用需求。一般情况下,会优先保证核心业务支持异地多活。
异地多活本质上还是通过异地的数据冗余,来保证极端情况下业务也能提供给用户。因此数据同步是异地多活的核心,但完美的数据实时同步是不可能的。业务要求数据可做到实时同步,物理约束又限制数据无法完美同步。虽然可通过搭建高速网络、减少同步规模、减少业务对数据同步依赖等手段来缓解上面问题,但根本上还是需要根据数据业务特征进行差异化处理,实现最终一致性满足业务需求。
数据同步是多活核心,一般存储系统(如数据库)都会有自身同步能力。虽然绝大部分场景下,存储系统自身同步功能是够用的,但在某些极端情况下还是有所欠缺。理想的做法是开拓思路,避免仅使用存储同步功能,将多种手段配合存储系统同步来使用,甚至可不采用存储系统的同步方案,改用自有同步方案。
异地多活无法保证100%业务可用,这是由物理规律决定的,光速和网络传输速度、硬盘写入速度、极端异常情况等,都是无法100%解决的。多活架构,通过单元化处理可满足系统整体上大部分可用,但是要忍受一小部分业务的损失。不存在完美的多活方案,可通过挂公告、事后补偿的方式进行安抚处理。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞8
添加新评论1 条评论
2022-03-11 11:32