黑科技揭秘:阿里云如何做到从业务宕机到恢复业务运行只用一分半钟时间

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 企业关键业务宕机会带来非常大的损失,而传统的自建容灾方案成本高昂运维复杂,因此高性能的云容灾服务正在成为企业业务持续性保障的优先选择。混合云容灾服务(HDR)-关键业务型的演示完整呈现了将本地服务器上运行的报账系统实时容灾复制到阿里云,并在出现宕机后在云上快速拉起恢复业务的全过程。

2018杭州云栖大会主论坛上,阿里云打造的混合云容灾方案惊喜亮相,并直接在现场进行了全过程的演示,凸显出阿里云技术的强大心智。
image002

整个混合云容灾演示在5分钟内呈现了阿里云秒级RPO,分钟级RTO企业应用容灾的端到端流程,涵盖了一个典型云容灾场景的核心步骤。

众所周知,企业关键业务宕机会带来非常大的损失,而传统的自建容灾方案成本高昂运维复杂,因此高性能的云容灾服务正在成为企业业务持续性保障的优先选择。混合云容灾服务(HDR)-关键业务型的演示完整呈现了将本地服务器上运行的报账系统实时容灾复制到阿里云,并在出现宕机后在云上快速拉起恢复业务的全过程。
image003

整个演示主要分为三个阶段:

1、容灾复制阶段 报账系统在运行业务的时候,工程师一键启动了容灾复制,首先通过快速全量复制将磁盘上的所有数据,包括操作系统,应用,文件等都复制到阿里云的云盘上,且限速35MBps来确保不影响业务正常运行。在全量复制完成后,就进入实时复制状态,RPO达到了5秒左右。

2、业务宕机阶段,现场工程师将服务器硬盘拔出,导致服务器宕机,业务中断。监控系统在几秒内钟探测到服务不可连接,客户端也无法再执行报账任务。

3、容灾恢复阶段,工程师启动云上容灾恢复。混合云容灾服务先在云上创建好与云下服务器配置一致的ECS,然后将复制了本地服务器磁盘数据的云盘挂载到ECS上并启动,当探测到ECS上的服务已经启动后,切换DNS。1分半钟之内,业务在云上恢复了运行,客户端的保障任务继续,实际演练中,RTO达到了90秒左右。

数据是数字化运营的核心
数字经济时代,数据正以超出想象的速度快速增长。短短几年,数据量已经从TB级别跃升到PB乃至ZB级别。

根据相关研究机构调查结果显示,2017 年全年数据总量将超过15.2ZB,同比增长35.7%。到2018 年全球数据总量达19.4ZB。未来几年全球数据的增长速度在每年25%以上,预计到2020年,全球数据总量将接近50ZB。

不可否认的是,数据是数字化运营的核心,数据安全决定企业的生死存亡。

数据中心事故面前,企业面临灾难性危机

2018年8月,某国际云厂商因销售人员在一个存储桶方面没有遵循其规范,导致数据泄露。

2018年7月,某国内云平台被曝出发生过严重故障,直接导致某创业公司数据全部丢失,使该创业公司面临前所未有的业务停摆危机。

2017年5月12日发生全球性WannaCry蠕虫病毒事件,银行的ATM提款机“罢工”,加油站的电脑“停业”,学校即将答辩学生的论文被加密。

2017年1月,某代码托管平台的运维人员在多终端操作切换时,误把生产环境当成测试环境,人为失误的把生产环境的数据库删除。

2014年11月份某金融支付公司出现系统故障,出现了高达近4亿多重复到账。

据IDC统计数据表明,十年间发生过灾难的公司,有55%当时倒闭,剩下的45%中,因为数据丢失,有29%也在两年之内倒闭,生存下来的仅占16%。

根据Gartner报告显示,在经历大型灾难而导致系统停运的公司中有2/5再也没有恢复运营,剩下的公司中也有1/3在两年内破产。

在此背景下,企业数据保护已迫在眉睫。

企业数字化转型,混合云架构灾备方案是首选。过去,传统灾备解决方案是基于容灾中心建设一套与生产中心类似的架构体系,虽然满足生产中心的数据备份和复制需要,但落地周期长、实施不便、设备昂贵、运维复杂等因素对企业造成重重挑战。
image005

那么,相比于传统灾备解决方案,混合云备份容灾解决方案是高效率、高可用、高性价比、免运维的现代化灾备方案,可以帮助客户把文件、数据库、虚拟机乃至整机安全高效地实现本地备份或备份上云。同时,备份上云的应用服务器整机可以在云上以服务器虚机的形式直接拉起运行,满足所需的RPO和RTO保障业务连接性,实现云上容灾。
image007

阿里云混合云备份容灾服务产品

混合云备份(Hybrid Backup Recovery,HBR)服务是一种简单易用且高性价比的在线备份服务,可以帮助客户把桌面机,服务器或者虚拟机的数据备份到阿里云上的备份存储库,为客户数据提供安全、高效的云存储备份管理服务。

混合云备份服务典型的应用场景一:针对不同IT环境的数据保护

满足不同IT环境的数据保护,包括本地数据中心物理机、虚拟化平台,以及阿里云上ECS服务器和其他公有云平台上的服务器

RPO和RTO要求不高,但能够保证数据安全、可恢复能力

image009

混合云备份服务在场景一具有以下优势:
简单易用,服务即开即用,分钟级快速部署,减少学习成本;
采用加密、多副本满足安全可靠的云备份,数据可靠性达到11个9;
采用去重、压缩减少带宽占用和备份成本,同时可以利用非常有限的带宽将数据备份上云;
弹性扩容,存多少算多少,按量付费,同时也有多种折扣套餐可以满足预付费客户的要求;

混合云备份服务典型的应用场景二:多分支机构集中备份+跨区域容灾
image011

不同省市、区域中有多个分支机构,各分支机构有相应的数据需要进行备份;
各个物理机房分别去部署备份设备,管理分散并且复杂,难以保证数据备份成功完成;
基于多区域容灾要求,希望将备份数据的副本保留在其他区域,防止区域性故障导致的数据或服务无法使用;

混合云备份服务在场景二具有以下优势:
各机房无需部署和管理备份存储硬件设备,降低管理复杂度和运维成本
实现数据备份统一管理;
高效的数据源变长重删,高达30:1的重删率,降低网络带宽和存储资源消耗,缩短备份窗口;
客户端数据永久增量备份上云,云备份库每个时间点副本都是全量,提高备份恢复的效率,实现快速恢复;

区别于混合云备份服务,混合云容灾(Hybrid Disaster Recovery,简称HDR)服务是一个为企业应用提供云+本地双备份与云容灾的服务。它可以对服务器整机,文件和应用进行保护,容灾服务器部署于本地数据中心用于快速恢复本地数据,同时备份数据同步上云灾备库用于做云上容灾,可以避免机房故障的同时还能够在云上恢复出业务服务器,满足业务连续性,平时还可以用于灾备演练或者数据分析使用;为了应对大数据集群架构的数据保护,混合云容灾服务发布首个公有云大数据灾备解决方案。

混合云容灾服务典型的应用场景一:核心业务实时复制上云+云上容灾接管

生产环境需要进行实时复制,确保本地机房出现业务故障的情况下能够从云上快速地接管业务;
业务系统由数据库服务器、文件服务器、应用服务器等一整套服务器搭建而成;
image013

混合云容灾服务在场景一具有以下优势:
满足客户对核心业务数据保护的同时,可以利用公有云平台能力实现异地容灾 ;
持续的数据保护和应用一致性保证,使RPO可达秒级水平;
弹性扩展,按需配置,平时云上无需创建ECS服务器,比起基于OS层的传统实时复制方案减少20%以上的成本;
编排式的一键容灾模式,可以预先部署好容灾接管的各个关键步骤,使整体RTO在分钟级完成;

混合云容灾服务典型的应用场景二:本地备份+按需配置上云容灾

生产环境需要进行本地备份,确保本地机房出现数据误删除、磁盘故障的情况下能够从本地快速恢复数据;
本地备份数据要进行异地容灾,确保本地数据中心出现灾难事故时,业务能在容灾中心快速恢复,使业务中断时间较短;
业务系统由数据库服务器、文件服务器、应用服务器等一整套服务器搭建而成;
image015

混合云容灾服务在该场景二具有以下优势:
满足客户本地备份要求的同时,可以按需配置异地容灾,利用公有云平台能力,使客户在无需自建容灾机房的情况下,就可以实现灾难情况下业务快速恢复,节省70%灾备成本;

弹性扩展,按需配置,平时云上ECS不用恢复和启动,客户只需要用到云端的灾备库资源,云灾备库资源支持弹性扩容;

云下数据中心定时备份使数据备份RPO在小时级别,云上或云下整机容灾恢复RTO在小时级别;

高可靠,依托于阿里云的基础架构,确保在需要容灾恢复的时候,业务能安全可靠的数据可以进行及时恢复;

混合云容灾服务典型的应用场景三:本地备份+按需配置上云容灾
本地数据中心Hadoop大数据集群,有百TB级别数据,自建同等规模异地容灾集群会造成大量闲置资源,成本太高;
要求RPO接近0,传统distcp方案无法满足要求;
image017

混合云容灾服务在场景三具有以下优势:
充分利用公有云资源,搭建云上大数据集群;
采用异步实时复制技术,RPO接近0,平滑扩展上云;
云上云下集群双活,两个集群运行不同业务,无资源闲置,TCO低
云上节点弹性扩展,快速稳定的计算资源满足业务量波动需要;

阿里云混合云备份容灾解决方案优势特点

优势一:分级RPO和RTO
支持多层次RPO和RTO满足不同业务的灾备等级需求;
核心业务实时复制,关键业务定时容灾,普通业务定时备份;

优势二:简单易用,5分钟启动备份服务
不需要任何硬件或者网关设备;
备份空间即买即用,易于扩展;

优势三:高性价比,按需购买
高达30:1的重删压缩比,30个副本只占用原来副本的1份空间;
采用永久增量技术,免去冗余不变的数据重复上传,免专线的情况下体验极速上云;
根据云端存储空间计量计费,而非源端备份数据量,极大地减少了备份费用;
利用公有云平台基础架构,相比传统容灾中心建设减少70%以上的成本;

优势四:安全可靠,多区域容灾
数据多版本备份,每个时间点都是完全副本;
高达12个9的云存储可靠性;
多AZ的备份库容灾,依赖云平台多可用区的支撑,数据多份保障;
可配置的跨区域异地容灾模式,可避免重大区域性故障导致的数据丢失;

优势五:整机灾备,无需业务改造
整机备份,整机恢复,可以在无需变更应用程序和IP地址的情况下,在云上重新恢复出与原来相同的业务系统出来;
整机上云的同时,还支持整机线下机房数据回流,方便在线下机房修复完成后的应用回迁;

优势六:主流平台支持,结构化和非结构化数据保护
操作系统:Windows、Linux;
系统平台:VMWare、Hyper-v、物理服务器;
数据库:SQL Server、Oracle等多种数据库;

混合云备份产品:https://www.aliyun.com/product/hbr
混合云容灾产品:https://www.aliyun.com/product/hdr
国际站:混合云备份产品链接:https://www.alibabacloud.com/product/hbr

了解更多产品降价信息请戳链接
https://yunqi.aliyun.com/2018/hangzhou/product
了解更多阿里云产品请戳链接
https://www.aliyun.com/product/list?utm_code=p_2018090501
专属小游戏,《我和老板,那些不可描述的需求》等你来~
https://yq.aliyun.com/articles/641567

相关实践学习
2分钟自动化部署人生模拟器
本场景将带你借助云效流水线Flow实现人生模拟器小游戏的自动化部署
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
3月前
|
消息中间件 存储 Kafka
【Kafka大揭秘】掌握这些秘籍,让你的消息状态跟踪稳如老狗,再也不怕数据丢失的尴尬时刻!
【8月更文挑战第24天】Kafka作为一个领先的分布式流数据平台,凭借其出色的性能和扩展性广受青睐。为了保障消息的可靠传输与处理,Kafka提供了一系列核心机制:生产者确认确保消息成功到达;消费者位移管理支持消息追踪与恢复;事务性消息保证数据一致性;Kafka Streams的状态存储则适用于复杂的流处理任务。本文将详细解析这些机制并附带示例代码,帮助开发者构建高效稳定的消息处理系统。
43 5
|
11月前
|
前端开发 Cloud Native 大数据
坑爹,线上同步近 3w 个用户导致链路阻塞引入发的线上问题,你经历过吗?
坑爹,线上同步近 3w 个用户导致链路阻塞引入发的线上问题,你经历过吗?
|
vr&ar 开发工具 图形学
Unity引擎更新收费模式:从收入分成转向游戏安装量,将会有哪些影响呢
Unity引擎更新收费模式:从收入分成转向游戏安装量,将会有哪些影响呢
|
缓存 数据挖掘 BI
面试官问你:日亿万级请求日志收集如何不影响主业务?你怎么回复
数据收集 上篇详细讨论了写缓存的架构解决方案,它虽然可以减少数据库写操作的压力,但也存在一些不足。比如需要长期高频插入数据时,这个方案就无法满足,接下来将围绕这个问题逐步提出解决方案。
|
canal 中间件 Java
阿里终面:业务主表读写缓慢如何优化?
阿里终面:业务主表读写缓慢如何优化?
|
XML Java 数据库连接
工作几年了,原来我只用了数据校验的皮毛~
前言 什么是 JSR-303? 添加依赖 内嵌的注解有哪些? 如何使用? 简单校验 分组校验 嵌套校验 如何接收校验结果? BindingResult 接收 全局异常捕捉 spring-boot-starter-validation做了什么? 如何自定义校验? 自定义校验注解 自定义校验器 演示 总结
|
IDE Linux 调度
看完这篇文章,我再也不用担心线上出现 CPU 性能问题了(下)
在上一篇文章中咸鱼给大家介绍了 CPU 常见的性能指标,当生产环境出现 CPU 性能瓶颈的时候,优先观察这些指标有没有什么异常的地方,能解决大部分情况
|
存储 消息中间件 Linux
看完这篇文章,我再也不用担心线上出现 CPU 性能问题了(上)
生产环境上出现 CPU 性能问题是非常典型的一类问题,往往这个时候就比较考验相关人员排查问题的能力
|
缓存 监控 前端开发
项目维护几年了,为啥还这么卡?
前段时间有个客户问我,为啥你们项目都搞了好几年了,为啥线上还会经常反馈卡顿,呃呃呃。。