在这些基础上,光有高可用还是不够的,我们需要考虑到机房级的、数据中心级的、站点级的灾难导致的对业务的影响。配套的容灾技术,以及对应事件的方案,应运而生。 TiDB 的金融级备份及容灾之道 TiDB 经常这么多年的积累和逐渐完善,在整个分布式数据库的容灾和灾备的领域,我们达到了金融生产级的要求。 以上是我们交付给用户的多种金融生产级的灾备容灾的方案,它背后的支撑是由核心的 TiDB 的 Multi Raft 的高可用机制,以及一系列针对跨中心的调度、数据的调度管理、故障的自动转移判断等这一整套后台的保障技术机制来实现的 能够达到更好的金融级的数据服务的支撑能力水平,依托于我们整个工程研发团队、 QA 测试团队,以及我们所打造和拥有的强大的测试体系、TiDB 产品的容灾灾备一系列高可用及灾备容灾机制,我们能够为银行、保险 、证券等金融客户提供完善的、可靠的、放心的、金融级的分布式数据库服务。
中国金融行业IT系统容灾标准采用六级分类,分为1-6级,对应不同的恢复时间目标(RTO)和数据恢复目标(RPO)。 这些机构的业务连续性和数据安全至关重要,对容灾能力有最高要求。 二级容灾标准: RTO:4小时内 RPO:1小时内 适用于对业务连续性和数据安全有较高要求的金融机构,如中型银行、金融服务公司等。 三级容灾标准: RTO:8小时内 RPO:2小时内 适用于对业务连续性和数据安全有一定要求的金融机构,如小型银行、信用合作社等。 四级容灾标准: RTO:12小时内 RPO:4小时内 适用于对业务连续性和数据安全有较低要求的金融机构,如金融科技公司、支付机构等。 六级容灾标准(最低级别): RTO:48小时内 RPO:24小时内 适用于对业务连续性和数据安全要求相对较低的金融机构,如小型金融服务提供商等。
业务容灾是所有容灾中最复杂的一种场景,涉及到业务应用、中间件、数据库及底层的计算、存储、网络等资源。就云上业务容灾来讲整个容灾覆盖到IaaS、PaaS、SaaS层。 在容灾方案确认并且实施落地之后,就需要进行容灾切换演练工作。下面主要介绍下容灾切换演练的流程及具体操作细节。 image.png 一、确保备区所有相关的应用级中间件组件部署完毕。 先假设整个容灾切换场景在广州四区及六区进行,四区是主区、六区是备区。在六区搭建应用部署环境并先不启动业务。 二、模拟4区故障 采用脚本批量停止4区的应用级各个中间件组件,在必要的话,可以停止网络。经过观察,发下整个4区相关应用,中间件组件均以停止运行,并且4区到六区的网络也不通。 三、执行整个业务容灾的切换步骤 1、应用入口的流量切换。在容灾切换平台上,将系统客户端的流量指向六区。
数据存储容灾建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢? 一般网络抖动都是秒级的,建议重试次数通过退避指数方式来进行,以免造成短时间内机器负载突增。 同时针对使用COS分块上传或者重传,有一个优化技巧,首先COS分块上传以下三步: 1.初始化。 场景三:存储设备故障时间较长业务自愈能力建设 如果存储集群或者访问链路出现秒级的抖动,采用客户端或者应用重试方式是可行的。 如果CBS或者COS分布系统故障时间为分钟级,重试无法解决恢复失效问题,同时会引起机器负载偏高。这里需要针对业务场景来进行设计方案。 方案核心思路主要分为读和写业务。
在至少有一个Leader存在的前提下,进行Zookeeper的在线增量、在线减量、在线迁移 在全过程中ZooKeeper不停止服务
容灾技术背景说明 1).容灾架构演进 最原始的系统架构非常简单,客户端请求进来,业务应用读写数据库,返回结果即可。 此时的架构是没有考虑备份的,原系统出现问题后,无备份环境可用,不具备最基本的容灾能力。 为了解决上述架构的问题,比较简单的方式是提供备份系统。 ❖ 多活(双活) 主备架构容灾能力有限,也促生了多活架构。所谓多活架构,简单来说是应用系统与基础架构配合,通过将业务处理单元化实现更大范围的容灾能力。根据实现方式可分为同城双活和异地多活两种方式。 3).多活架构驱动因素 在传统容灾系统设计中,多采用主备方式。 部分金融信息系统在上述方式的基础上,由灾备系统同时提供查询服务,当发生灾难事件时,由灾备系统接管服务。
云容灾不仅提供数据备份功能,还结合计算、存储、网络等云服务能力,允许企业在云端快速部署容灾环境,并进行自动化业务恢复。二、传统容灾 vs. 云容灾在云容灾出现之前,企业通常采用传统容灾方案,如自建异地灾备中心或租用灾备机房。 相比之下,云容灾基于云计算技术,充分利用云平台的弹性和智能化能力,提供了一种更灵活、高效的灾备解决方案:对比项传统容灾云容灾基础设施自建或租用物理灾备中心依赖云服务,无需额外硬件成本投入高昂的硬件、机房 当业务负载增加时,容灾环境可以根据需求自动扩展计算能力,实现无缝升级。此外,云容灾还支持按需付费,避免了传统灾备方案中资源闲置的问题。3. 例如,企业可以在云端模拟宕机情况,测试系统在不同故障场景下的恢复能力,并优化灾备策略。四、案例分析:某金融企业的灾备升级背景某大型金融企业依赖传统容灾方案,在本地数据中心部署了一套灾备系统。
IDC时代,业务对网络容灾参与较少,主要依赖数据中心网络容灾建设程度;当到了云的时代,云服务商将底层网络能力产品化后,云上客户更多参与网络容灾建设,提升业务稳定性。 本文从云网络概述,云网络容灾复杂度以及典型案例来介绍云网络容灾建设。 1.云网络概述 云网络概述主要分为云服务商基础设施网络架构和云产品两部分,让云上客户更加深入了解云网络,用好云网络。 2)跨区或者跨地域云基础设施容灾能力。 通常云服务厂家数据中心建设均有容灾能力,这里建议还是选择大厂。 3)IDC到云上网络高可用建设。 混合云容灾模式,这里考虑到IDC和云上线路容灾情况,一般建议两条专线接入不同的POP点来进行容灾建设;同时建立VPN或者GRE公网逃生通道来紧急恢复业务。 image.png 3.2 混合云网络容灾 混合云网络容灾分为两个部分: 1)idc和云机房之间线路容灾,主要线路分为专线和VPN。
最为稳固的、保护等级最高,也是成本最高的容灾方案,即“两地三中心”:本地的生产中心和灾备中心相距100km以上,进行应用级或业务级容灾保护,且在 300km 以外的异地建立灾备中心,进行数据级或应用级容灾保护 1.png 随着IT应用的快速发展,金融,银行,政府等越来越多的用户要求核心业务7*24不断网,不断电持续运行,一些大型企业为了尽最大可能减小大自然灾害对业务连续性的影响,而选择两地三中心的容灾方案,这样的方案具备高可用和灾难备份能力 2.容灾级别与能力 容灾系统按保护级别可分为:数据级容灾、应用级容灾、业务级容灾。 2.3业务级容灾 业务级容灾是全业务的容灾,除了必要的IT相关技术,还要求具备全部的基础设施。 4.云容灾级别和能力 参考传统容灾的级别划分,由于云容灾的基础设施采用了云平台,在云容灾的级别划分上,应用级和业务级的区别已经不大了,因此在这里将云容灾的容灾级别分为:数据级容灾、业务级容灾。
为了让企业能更好用好云平台的数据安全能力,本文重点云平台数据备份冷备能力,以腾讯云为例,主要从以下两个维度介绍:同城数据冷备能解决企业什么问题,达到怎么样业务容灾效果? 数据不是实时备份,数据恢复存在不完整性,同时业务恢复无法自动切换,需要人工介入,数据冷备的RPO和RTO为小时级。 同城冷备份方案同城数据冷备方案主要依赖于云平台能力备份能力,对现有业务架构没有任何改造,方案架构如下:图片该方案核心要点说明:数据备份:云侧数据库mysql和redis在控制台设置数据备份参数,数据备份存储在COS,具备地域级别容灾 指标详细说明容灾能力具备同地域(不同可用区)数据备份能力,不具备不同地域的能力。 3.容灾演练能力建设,增加平时运维成本以及自动化工具开发功能。
2.3 数据库备份服务数据库备份服务拥有一套完整的数据备份和数据恢复解决方案,具备实时增量备份以及快速的数据恢复能力,同时具备异地容灾能力。
容灾(Disaster Tolerance)核心目标:保障业务连续性,允许数据最小化丢失实现手段:系统冗余+灾难检测+快速切换技术特征:需应对区域性灾难(如地震、火灾)典型场景:金融系统实时交易、医疗急救平台 灾难恢复(Disaster Recovery)阶段定位:灾难发生后的系统重建与容灾关系:现代容灾系统集成恢复功能二、容灾与备份的协同关系1. 功能互补性2. 典型故障应对案例1:数据库误删操作容灾系统同步删除→需从备份恢复案例2:机房级火灾容灾系统接管业务→备份用于数据追溯三、企业灾备体系规划策略1. 风险评估矩阵2. 政务云建设省级政务云平台:采用中科热备多云灾备方案满足等保2.0三级要求六、灾备体系演进趋势智能化监控:AI预测性维护(中科热备智能运维平台)绿色灾备:液冷技术降低PUE值量子安全:后量子加密技术集成零信任架构 :微隔离技术增强容灾环境安全性结语构建企业级灾备体系需遵循"预防-响应-恢复"的完整闭环,中科热备作为国产化灾备技术领军者,通过持续创新在金融、医疗、政务等领域成功部署超过2000个案例。
容灾系统在企业中给与数据安全系数相当高的保障,但是容灾系统倒是是什么,他们是什么意思?恐怕连正在使用容灾备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释容灾备份到底是什么。 容灾不可少 那么建设了备份系统,是否就不需要容灾备份系统? 容灾不能替换备份 容灾系统会完整地把生产系统的任何变化复制到容灾端去,包括不想让它复制的工作,比如不小心把计费系统内的用户信息表删除了,同时容灾端的 用户信息表也会被完整地删除。 如果是同步容灾,那容灾端同时就删除了;如果是异步容灾,那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份,来恢复被错误删除的信息。 备份系统+异地容灾系统 这是一个较为理想化的容灾系统一体化解决方案,能够在很大程度上避免各种可能的错误。 容灾恢复等级 ? 灾难恢复层次 ? 灾备技术层次 ? 1.1 磁盘阵列灾备技术 ?
本文结合云平台公网能力,从网络平台角度来分析容灾建设可行性。 2.公网出口容灾方案 2.1 IDC和云平台出口互为主备 正常情况下,IDC和云平台公网出口流量是烟囱式,互不交叉;当IDC公网出口异常,流量切换到云平台,同样云平台公网出口异常,流量切换到IDC。 整体公网出口容灾方案如下: image.png 2.1.1 云平台切换方案。 正常情况下,业务流量通过NAT访问公网,如上路绿色线条标识。 2.1.2 IDC容灾切换方案 正常情况下,IDC业务流量通过NAT访问公网,如上路绿色线条标识。 IDC公网出口容灾方案 (推荐) 1.方案简单,更多依赖云平台能力 2.方案落地快捷。 3.人力成本低,不需要自建系统。 4.维护成本低,不需要后续维护系统稳定性。
综上所述,本文从云平台视角出发阐述应用层业务容灾建设,主要分为方案设计考虑纬度、复杂度以及云上客户案例三个方面。 1.应用容灾概述 1.1 应用部署 应用是否满足跨地域/可用区部署? 应用层调用链是否能接受跨区延时,如果业务无法接受跨区,该业务做容灾只能set化部署,这里需要强大中间件团队开发数据同步系统。 应用层调用链能接受跨区延时,一般以试点业务先观察,小步迭代方式逐步构建容灾能力。 容灾切换强依赖于调度系统以及配置系统稳定性。这里稳定性主要包括系统容灾能力和性能;遇到大规模故障,大量信息配置变更请求调度系统和配置系统要能扛住洪峰,是保障这个容灾方案的根基。 2.应用容灾复杂度 计算应用层容灾,主要考虑以下两个方面: 哪些节点执行任务。 这里要区分清楚哪些节点执行核心业务,这里会引入不同的复杂度。
一方面,天翼云借鉴国际国内灾备标准,进一步细化灾备指标,添加库级读写分离、表级双写双读、行级双写双读等能力,让数据库灾备标准更加优化,有法可依。 ,可一键式完成相关高可用集群部署操作; 自动检测、自动切换,无需人工干预; 提供虚IP管理,主从库路由秒级切换; 相比国际标准,提供更细粒度容灾分级-库级读写分离、表级双写双读、行级双写双读能力。 这一要求也达到了金融领域分布式数据库灾难恢复的能力标准。 正是基于金融级高可用能力,天翼云TeleDB从层层选拔中脱颖而出,成功实现了健康码系统主中心和双活中心的切换:当新增资源池间互联电路中断或出现双活中心整体故障时,主中心业务完全不受影响,数据库集群将自动感知到双活中心发生故障 天翼云TeleDB作为云服务“国家队”,不断加快关键核心技术自主攻关,走出了一条引领国产化数据库高速发展之路,其历经十年打磨出的天翼云TeleDB系列产品,核心技术完全自主可控,其容灾方案展现出的金融级高可用标准
同城双活中,数据库技术(如MySQL MGR、Oracle Extended RAC)和存储级复制(如虚拟化存储双活)是常见手段。 共享存储或数据库主从模式 单元化架构(按用户/业务分片) 成本 专线成本较高,但存储配置可能更简单 异步复制带宽成本相对较低,但架构复杂度和改造成本高 主要优势 高可用、数据零丢失(RPO=0)、故障切换迅速 城市级容灾 2、容灾等级要求:同城双活可应对机房级故障。若需防范城市级灾难(如地震、大规模停电),则需异地双活。 3、成本预算:同城双活专线成本较高,但架构相对简单。
为什么要做容灾? 你知道吗?自然灾害、设备故障、人为因素等都会造成业务中断。如今数字化时代,IT系统故障更会对公司业务造成难以估量的巨大经济损失。 3 容灾关键词 RPO(Recovery Point Objective) 数据恢复点目标,主要指的是业务系统最大能容忍的数据丢失量。 容灾体系介绍 1 数据中心 集团公司通过两地建立三个数据中心,通过双活、冷备等方式,实现两地三中心容灾架构。 2 体系建设 系统类型 --- 容灾策略 核心业务系统 --- 两地三活 关键平台系统 --- 同城双活 非关键系统 --- 异地冷备 3 技术方案 异地冷备 恢复能力 RTP≤1h RPO≤5min 容灾演习要求 每年进行容灾演练,所有核心业务与平台系统均要参演。 异地灾备恢复、同城双活切换、一键式自动化启停等恢复方式不断创新,要求演习规模逐年扩大和恢复效率逐年提升。 - End - ----
容我细细细细分析。 原因就是接口挂了,拿不到数据了。那把数据储存起来就可以解决问题。 思考 存哪里? 第一时间反应浏览器本地存储,想起了四兄弟。 接口容灾我们也是刚弄不久,有许多细节与不足,欢迎沟通交流。 接口容灾本意是预防发生接口服务挂了的场景,我们不会很被动。原来是P0的故障,能被它降低为 P2、P3,甚至在某些场景下都不会有用户反馈。
由于该方案只做异地数据实时备份,RTO指标依赖于业务部署能力,通常为分钟级。数据热备有两个关键词分别为“异地”和“实时”,需要在再次强调一下。异地明确数据热备容灾能力,实时明确RPO指标接近于“零”。 2)灾备实例,建议采用云平台的PAAS服务,更好的兼容DTS同步服务。2.2 平台热备方案2.2.1 数据库灾备方案目前数据库对于异地容灾备份能力进行封装,来简化云上客户操作成本,提升RTO。 2.2.3 中间见实时备份方案ckafka云平台在数据同步已支持跨地域容灾,但是对于ckafka版本有要求,为专业版本。 方案关键因素详细说明容灾范围地域级别容灾RPO/RTORPO几乎接近为零;RTO为小时级别,进行1:1业务部署,依赖于业务部署和数据恢复自动化能力。 3.容灾演练能力建设,增加平时运维成本以及自动化工具开发功能。