【ESSD技术解读-03】阿里云块存储企业级特性之异步复制

本文涉及的产品
对象存储 OSS,20GB 3个月
日志服务 SLS,月写入数据量 50GB 1个月
对象存储 OSS,恶意文件检测 1000次 1年
简介: 在大数据时代,数据就是企业的核心资产,是企业的生命线。在现实世界中,灾难时有发生,当发生灾难时,容灾能力成为企业能否生存的关键。云上容灾服务,通常称为 DRaaS(灾难恢复即服务)不但能够省去自建容灾中心的开销,还能节省后续运维成本,帮助客户快速建立起跨地域的容灾方案,即买即用,随时释放的特性也为用户提供了极大的弹性。本文介绍了云上容灾产品形态,企业可结合自身特点选择合适的容灾方案,针对异步复制产品解析了传统容灾与云上容灾的技术架构。阿里云块存储也结合自身架构特点实现了块存储的异步复制产品。

前言

数据是企业的生命线

数据异地容灾是企业级客户的一个普适需求,尤其是对于政府,金融等大客户,更是核心需求。在大数据时代,数据就是企业的核心资产,是企业的生命线。在现实世界中,灾难时有发生,当发生灾难时,容灾能力成为企业能否生存的关键。

在美国“911”事件中,美国的双子大楼倒塌,数家银行的数据中心因此毁于一旦。德意志银行,因为在几十公里外做了数据备份,很快恢复了业务,得到用户的好评,而纽约银行因为没有灾备方案,在数月后倒闭。

21 年 3 月份,法国最大数据中心运营商 OVHcloud 机房着火,超 350 万网站受到影响。

在刚刚过去的郑州 720 水灾中,郑州大学第一附属医院河医院区受到连续暴雨影响,整个院区淹水导致停电,医院启动了异地容灾机制,仅用 15 分钟就将核心业务紧急切换至东区核心机房,保证了其他两个院区的正常运转。

云上容灾成为趋势

一个个真实案例警钟长鸣,这也使得企业对数据保护,容灾的投入不断扩大。传统的容灾方案,往往需要企业自建容灾中心,购买专线,以及投入人力进行运维等,投入成本较大。在云计算快速发展的时代,越来越多的企业客户考虑云上容灾。云上容灾服务,通常称为 DRaaS(灾难恢复即服务)不但能够省去自建容灾中心的开销,还能节省后续运维成本,帮助客户快速建立起跨地域的容灾方案,即买即用,随时释放的特性也为用户提供了极大的弹性。 下表中总结了 DRaaS 与传统容灾方案的对比,可以看出 DRaaS 与传统容灾相比具有零基建、少运维、高弹性的特点,因此,在云计算快速发展的时代,DRaaS 也成为容灾的趋势所在。


DR as a Service

传统线下DR

弹性

按需建立,按需释放

提前规划

建设费用

按量计费,仅需云盘和所需带宽费用, 0 基建

一次性买断阵列和网络,初期投资高

容灾数据链路

专用网络

自行铺设专线,租用带宽

最佳实践

Cloud on Cloud 与云上多种组件配合,达到最优模式

自行摸索 + 供应商推荐模式

功能演进

随公有云升级与演进

购买新设备、软件、升级

ESSD 云盘异步复制

阿里云块存储 ESSD 产品是全球领先的旗舰级产品,已经逐渐走向成熟。为了更好的服务企业客户,满足企业客户云上容灾需求,阿里云块存储也推出自己的 DRaaS 产品,云盘异步复制,实现云盘的跨地域异步复制。本文介绍了用户如何选择合适的云上容灾产品,从技术角度解析了不同容灾架构的异同点,然后介绍针对 ESSD 架构我们如何选择容灾架构以及云盘异步复制背后的技术原理。

企业如何选择云上容灾方案

根据 RPO,RTO 选择合适的容灾类型

企业在选择容灾方案时,首先应该根据自己的业务特点确定自己的容灾等级。在容灾领域通常使用 RPO(Recovery Point Objective)来衡量一个容灾系统最多可能丢失的数据的时长,RTO(Recovery Time Objective),来衡量从灾难发生到整个系统恢复正常所需要的最大时长。

国家出台了相关标准,把容灾能力分为六个等级,如下图所示

对于企业来说从一级到六级,级别越高,数据丢失的风险越低,但是容灾建设的成本越高。在传统存储行业中,通常数据备份归档类产品可以满足一到二级容灾需求,普通存储阵列的备份功能可以满足三到五级需求,高端存储阵列的异步复制功能可以满足四到五级需求,而高端存储同步复制,双活功能,以及基于应用的复制可以满足五到六级需求。

那么对于云上,各大云厂商也提供了丰富的云产品来满足不同的容灾级别需求,云上灾备中心通常提供跨地域或者跨可用区的云上灾备服务,可以满足一到四级的需求,而异步复制、同步复制产品可以满足五到六级容灾需求。主流的应用,例如数据库业务通常也有自己的容灾产品,最高可以做到 IO 级别的容灾粒度。

从上面的级别可以看出异步复制可以满足四到五级容灾需求,也是银行等金融客户以及政府单位等广泛需要的。

根据系统特点选择合适的容灾服务

从实现方式的角度来分类,现有云厂商的容灾方案大致分配三类:基于应用、基于实例和基于块存储:

基于应用

这类通常是针对某种特定的应用服务进行的容灾方案,例如云数据库,消息队列,对象存储等,使用相关云服务的用户可以根据自己的需要选择对应产品的容灾服务,这种容灾服务的优势是结合业务往往能够做到应用级别的一致性,缺点是普适性不强,只有基于特定的应用的业务才可以使用。

基于云主机

对于只购买了 IaaS 服务,或者有自己的定制化业务,又或者是应用级容灾服务不能满足需求的,可以选择基于云主机的容灾方案,这种方案会做整机的数据一致性保护,或者跨实例的数据一致性保护,容灾端通常除了存储数据的恢复,也进行主机网络的恢复,使用起来比较便捷,这种容灾服务优点是操作简单,普适性强,缺点是在容灾端也需要买好主机资源,成本相对较高。

基于块存储(云盘)

容灾的核心是数据容灾,因此也有部分厂商针对云盘本身推出跨地域复制产品,这种产品形式比较灵活,对应用一般没有限制,复制期间不需要容灾端购买主机,可以降低用户成本,也可以无缝与其他云服务搭配使用,形成应用级容灾类似的效果。同样基于云盘可以做一致性组,对一组云盘的复制数据满足崩溃一致性语义。

ESSD云盘异步复制,简单几步帮你搞定业务恢复

云盘异步复制功能支持 ESSD 产品跨 Region(地域)进行云盘数据的异步复制,RPO 为 15 分钟。用户仅需要简单 3 步就可以完成一个容灾对的创建:首选选择需要复制的云盘,第二选择容灾站点并创建从盘,第三创建容灾对并激活容灾对。容灾对激活后云盘数据就会周期性复制到容灾站点对应的从盘上了,当用户想暂时停止复制时,可以使用容灾对的停止功能来暂时终止复制。

当故障发生时,用户可以使用故障切换功能,完成主备站点的切换,故障切换会断开复制链路,并使得从端设备恢复到上一个复制的一致性点,提供给用户可读可写权限。

当灾难恢复后,用户想将业务恢复到原有生产站点,可以使用反向的恢复功能,将从站点产生的增量数据恢复回主站点。


云上异步复制背后的技术

本章就容灾产品中广泛使用的异步复制技术探讨一下其实现原理以及与传统存储的架构异同。容灾的核心是数据的容灾,块存储容灾是最通用的容灾方案,因此后文的探讨主要针对云盘的异步复制技术。

传统存储的复制架构

传统存储异步复制实现方式大致有三种:

基于存储网关:存储网关位于服务器与存储设备之间,是构架在 SAN 网络上的存储服务技术。存储网可以对进入的 IO 流提供灵活多样的存储服务,存储网关与主机服务器和阵列是分离的,不占用主机和存储端的资源,可以方便的支持异构系统之间的复制,但由于 IO 多了网关链路,所以性能会有一定的损失,不太适合对性能要求高的业务。

基于主机:在 SAN 存储中通常实现在 Initiator 端,在主机端根据 IO 复制要求进行数据分流,典型实现如 DRBD,这种架构对后端的存储阵列没有要求,主机端需要安装相应的软件。做灾备服务的第三方厂商多采用这种架构。

基于存储阵列:多数存储阵列厂商会结合自己的阵列特点实现基于存储阵列的复制架构,这种架构下厂商会根据自己阵列 IO 架构实现在 Target 端,对数据进行追踪和双写。

云上异步复制的两种技术架构

云厂商通常结合自己的产品特点,通常有两种技术架构:

有代理的实现架构:这种方式通常需要在用户虚拟主机中安装插件作为 IO 代理,插件通过截获用户 IO 请求并转发进行复制,这种方案优势在于可以提供应用级别的一致性语义。这种架构对云盘厂商没有特殊要求,容易做到异构系统的容灾,劣势是用户使用时需要部署插件才能使用,对用户操作系统的版本可能有限制。云产品第三方服务商通常采用这种架构。

无代理的实现架构:这种实现方式往往基于底层的存储系统,依托存储系统提供的一致性点以及获取数据差异位图等技术进行全量或者增量数据复制,能为用户提供数据崩溃一致性语义。这种方式的优势是可以结合存储系统进行高效的差异数据复制,并且对用户主机系统无入侵,业务使用方式更简单,劣势是无法做到应用级数据一致性。主流云厂商通常具有自主研发的块存储服务,通常会结合块存储的自身架构特点实现无代理方式的复制架构。

阿里云 ESSD 云盘异步复制架构

阿里云块存储也推出了自己异步复制产品,本章介绍一下阿里云如何结合自身架构实现异步复制产品。

阿里云块存储异步复制功能采用的是无代理的实现方式。系统架构如图所示,容灾管理软件分别在生产站点和容灾站点部署,容灾管控系统周期性的发起复制任务给异步复制 IO 组件,复制组件从云盘存储系统后端获取数据差异并将差异数据复制到目标区域,目前跨区域复制的 RPO 设计目标为 15 分钟。

高可用架构

异步复制技术实现上采用高可用架构。考虑到故障场景下系统依然能做到可用,容灾管理组件会在生产站点和容灾站点同时部署,而不是采用容灾组件部署在单边或者在第三放区域部署的方式。容灾管理的元数据信息会在容灾对的主从都同步一份。这就保证了主站点灾难时,从站点的容灾管理功能仍然可用。此外,容灾管理软件以及复制链路上都分别采用了高可用架构,所有管控节点均采用一主两备方式部署,保证了容灾服务自身的服务连续性。

高效复制

异步复制的复制流程采用增量方式进行复制,能够最大程度的降低复制和传输的数据量,这也提高了复制效率。依托底层存储系统高效的内部获取一致性点技术,能够高效的获取云盘的数据崩溃一致性数据视图,通过存储系统内部索引技术能够高效的获取数据的增量差异。下图给出一个存储系统如何获取一致性点的差异位图。获取到的差异位图会被序列化为数据差异日志,即 DCL(Data Change Log)发送给复制组件,根据差异位图读取相应区域的一致性点数据并写入到从盘。

复制链路也会根据云盘的大小带宽等特性将复制流程进行自动分片,并发复制,从而提升复制的效率,最大程度满足 RPO。下图展示了复制组件获取差异位图和复制任务的过程,云盘会根据大小切分成多个数据分片存储到不同的数据服务器上,复制组件会从存储服务器获取一致性视图的 DCL,根据云盘大小和带宽情况,决定将一个云盘切分为多少个子任务进行复制,以更好的适配复制带宽。下图是复制 IO 组件的工作原理。

主盘性能无损

依托存储系统本身的高效索引系统和高性能一致性点生成技术,异步复制对主站点云盘本身的性能影响很小,可以忽略不计,主盘性能完全满足官方售卖标准。

秒级 RTO

传统的备份业务通常会把数据存储在 OSS 等外部系统上,需要使用时再利用 OSS 快照创建出盘,创盘和加载数据,会使得 RTO 时间较长,通常达到分钟级或者更长。云盘异步复制对从端云盘进行周期性的写入,云盘在复制阶段不可读写,在故障切换后可以瞬间可用,RTO 可达秒级,这得益于从盘数据一直在线的设计和存储系统可快速恢复到一致性点的架构优势。

总结与展望

本文介绍了云上容灾产品形态,企业可结合自身特点选择合适的容灾方案,针对异步复制产品解析了传统容灾与云上容灾的技术架构。阿里云块存储也结合自身架构特点实现了块存储的异步复制产品,相较于传统的异地容灾方案,块存储的容灾方案有如下优势:

低成本:无需绑定虚拟机使用,用户在容灾站点只需要购买云盘,而无需购买备用虚拟机,在容灾恢复时可根据需要购买虚拟机,从而大大降低运营成本。

易用性:无需用户虚拟机安装代理插件,做到应用无感知,对用户主机操作系统无版本要求。按需购买,操作简单,即买即用,支持一键切换和一键生成容灾演练盘。

高可用:容灾组件均采用高可用区设计,保证在灾难场景下容灾系统能够进行容灾切换操作。

业务快速恢复:提供较低的业务恢复时间,RTO 可达秒级。

极低的性能开销:复制期间主盘性能几乎不受影响。

块存储异步复制产品致力于为用户提供简单高效易用低成本的异地容灾解决方案,后续将持续丰富产品特性,陆续推出一致性复制组,共享盘支持,数据链路压缩与去重等特性,丰富产品的使用场景和降低用户的使用成本,打造可靠易用低成本的 DRaaS 服务,敬请期待。


原创作品:阿里云存储 李玮玮

相关实践学习
块存储快速入门
块存储是阿里云为云服务器ECS提供的块设备产品。通过体验挂载数据盘、分区格式化数据盘(Linux)、创建云盘快照、重新初始化数据盘、使用快照回滚云盘和卸载数据盘等功能,带您快速入门块存储。
相关文章
|
4月前
|
存储 测试技术
阿里云块存储问题之测试不聚焦可能导致测试不稳定如何解决
阿里云块存储问题之测试不聚焦可能导致测试不稳定如何解决
52 3
|
1月前
|
存储 Cloud Native 块存储
EBS深度解析:云原生时代企业级块存储
企业上云的策略,从 Cloud-Hosting 转向 Serverless 架构。块存储作为企业应用上云的核心存储产品,将通过 Serverless 化来加速新的计算范式全面落地。在本话题中,我们将会介绍阿里云块存储企业级能力的创新,深入解析背后的技术细节,分享对未来趋势的判断。
104 2
|
4月前
|
存储
阿里云块存储问题之高效的Code Review可以发现70-90%的bug如何解决
阿里云块存储问题之高效的Code Review可以发现70-90%的bug如何解决
46 1
|
4月前
|
存储 Linux 测试技术
阿里云块存储问题之在编码和提交代码时确保代码提交的原子性如何解决
阿里云块存储问题之在编码和提交代码时确保代码提交的原子性如何解决
45 0
|
4月前
|
存储 Cloud Native Linux
阿里云块存储问题之poison发布阻塞机制实现如何解决
阿里云块存储问题之poison发布阻塞机制实现如何解决
51 0
|
4月前
|
存储 Kubernetes 测试技术
阿里云块存储问题之处理信用分低的测试用例(即不稳定Case)如何解决
阿里云块存储问题之处理信用分低的测试用例(即不稳定Case)如何解决
52 0
|
4月前
|
存储 专有云 测试技术
阿里云块存储问题之块存储选择了主干开发模式,发布模式有哪些种类如何解决
阿里云块存储问题之块存储选择了主干开发模式,发布模式有哪些种类如何解决
49 0
|
4月前
|
存储 Kubernetes 测试技术
阿里云块存储问题之生产代码与测试代码需要同步原子提交如何解决
阿里云块存储问题之生产代码与测试代码需要同步原子提交如何解决
45 0
|
4月前
|
存储 测试技术 块存储
阿里云块存储问题之有顺序依赖的测试导致不稳定如何解决
阿里云块存储问题之有顺序依赖的测试导致不稳定如何解决
36 0
|
4月前
|
存储
阿里云块存储问题之“简洁”并不等同于“代码短”如何解决
阿里云块存储问题之“简洁”并不等同于“代码短”如何解决
42 0
下一篇
DataWorks