企业为什么要做应用多活?

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
可观测监控 Prometheus 版,每月50GB免费额度
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 无容灾不上云,应用系统要随时具备对灾难故障的逃逸能力。平稳迁移上云是每位决策者的关键决策点。业务持续发展,架构不断演进,容灾治理解决的是发展中问题。如何实现应用多活的容灾架构和组织协同,也越来越成为更多企业者关心的问题。

容灾成为企业上云和用云的基础要求


2019 年 IDC 发布的《全球云计算 IT 基础设施市场预测报告》显示:2019 年全球云上的IT基础设施占比超过传统数据中心。越来越多企业因为云计算低成本、稳定性而选择在云端构建系统,云已经变成了一个主流 IT 基础设施。近年来,开源技术和云技术保持高速发展,出现种类繁多的产品和服务,技术人员决策权变大,架构更迭速度日益加快。在高速演进的过程中,要谨防人为的不合理故障,同时也要关注自然灾害的影响。一次不恰当业务中断,可能带来严重的品牌、客户、经济损失。


所有的上云企业都把容灾系统能力建设作为最基础目标来要求,并保证投入。只有确保灾难发生时,关键数据不丢失,系统服务尽快恢复运行,企业才能保证长久、平稳的高速发展。


常见的灾难故障


在企业生产实践中,不免会发生大大小小的故障,影响系统的稳定性。有些故障在发生后快速恢复,外部用户无感,有些故障长时间无法恢复,造成外部舆情、资金损失等问题,甚至可能导致公司破产,故障一般有如下几类:


  • 人为操作失误,比如常见的有配置错误、应用发布失败等等;


  • 硬件故障,比如常见的就是网络设备出故障,导致机房或者集群内多台服务器受影响等;


  • 网络攻击,比如 DDoS 等网络攻击等;


  • 断网/断电,比如光缆被挖断等;


  • 自然灾害,比如雷击导致机房电力故障等。


在这些灾难下,常常面临着公网、接入网关、机房等设施中断,会造成流量下跌、网站打不开、故障报警等业务问题,对于企业而言,需要面临着“业务恢复”和“故障恢复”两大难题,最好的方式是将这两类问题进行解耦,在发生故障时,快速切流,优先恢复业务。在业务恢复的前提下,进行故障定位修复。


故障逃逸能力的成长


业界常见的故障定位与恢复涵盖 4 个步骤:发现问题-定位问题-修复问题-业务恢复。明显无法满足“业务恢复”和“故障恢复”解耦处理的需求。更好的应对方式是将这 4 个故障处理步骤升级成"发现问题-切流-业务恢复"的 3 个故障处理步骤,通过“切流”保证业务的快速恢复,将业务恢复的时间从“数十分钟甚至数小时不等”缩短到“分钟级甚至秒级”,提高业务的容灾能力。


为了保证快速切流的实现和在真实场景中“有效”的切流,我们需要建设更高阶的容灾架构技术,还需要增强“基础设施”、“业务系统”、“保障工具”、“生产制度”、“应急人员”的协同。通过架构与组织的协同,实现容灾多活的能力保鲜。


这种能力,不是即刻就可以突破的,是需要不停的优化架构与组织协同,才能促使业务的容灾多活能力螺旋式的上升。


突破地域限制


企业在起步阶段一般选择单地域部署,但随着业务的规模发展,单地域机房将无法满足业务需要。与此同时,单地域的集群化组件随着连接数的爆炸性增长,单集群的容量已无法继续扩展,亟须进行集群的拆分。


但是在做支持跨地域的集群拆分时,需要满足“路由一致性”、“数据一致性”的原则,从而让业务能够突破地域限制,做到跨地域的容量水平扩展,灵活调度流量,从而解决单地域下的容量挑战问题,比如:


  1. 机器容量。多个异地机房对等部署,企业应用可在多地多机房灵活部署业务应用。


  1. 连接容量。机房内集群化组件独立,各自机房连接自有组件,避免连接数无限增长的问题。


灾备容灾的局限性


灾备容灾建立在数据级容灾的基础之上,常用的实现方式是在备份机房构建一套相同的应用系统,灾难发生时会在约定的时间范围(RTO)内恢复运行,尽可能减少灾难带来的损失。在实际实施时,存在以下几个问题:


  1. 灾备中心平时不提供服务,在切换到灾备中心的关键时刻时无法确定是否可以成功切换。


  1. 灾备中心平时不提供服务,整个灾备资源会处于闲置状态,成本浪费比较高。


  1. 灾备中心平时不提供服务,所以平时提供服务的机房还停留在单地域,当业务体量大到一定程度时,这种模式无法解决单地域资源瓶颈的问题。


应用多活的概念

“应用多活”是“应用容灾”技术的一种高级形态,指在同城或异地机房建立一套与本地生产系统部分或全部对应的生产系统,所有机房内的应用同时对外提供服务。当灾难发生时,多活系统可以分钟级内实现业务流量切换,用户甚至感受不到故障发生。


常见的应用多活架构分为同城多活、异地多活、混合云多活,和传统容灾相比,应用多活具备以下 4 个优势:


  • 分钟级 RTO。 恢复时间快,阿里内部生产级别恢复时间平均在 30s 以内,外部客户生产系统恢复时间平均在 1 分钟。


  • 资源充分利用。资源不存在闲置的问题,多机房多资源充分利用,避免资源浪费。


  • 切换成功率高。依托于成熟的多活技术架构和可视化运维平台,相较于现有容灾架构,切换成功率高,阿里内部年切流数千次的成功率高达 99.9% 以上。  


  • 流量精准控制。应用多活支持流量自顶到底封闭,依托精准引流能力将特定业务流量打入对应机房,企业可基于此优势能力孵化全域灰度、重点流量保障等特性。


到 2025 年,有超过 50% 企业会使用分布式云。公共云服务能力将延伸到边缘计算和 IDC,一朵分布式云实现全场景覆盖。跨云、跨平台、跨地理位置的应用多活场景和技术将开始浮现。无容灾不上云,应用系统要随时具备对灾难故障的逃逸能力。平稳迁移上云是每位决策者的关键决策点。业务持续发展,架构不断演进,容灾治理解决的是发展中问题。如何实现应用多活的容灾架构和组织协同,也越来越成为更多企业者关心的问题。


----以上节选自《应用多活技术白皮书》,点击此处即可下载!


相关文章
|
3月前
|
存储 运维 容灾
应用多活技术问题之应用多活技术实现容灾如何解决
应用多活技术问题之应用多活技术实现容灾如何解决
|
负载均衡 容灾 网络协议
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(上)
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(上)
563 0
|
6月前
|
弹性计算 容灾 网络协议
一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例
阿里云弹性计算团队十三位产品专家和技术专家共同分享云上运维深度实践,详细阐述如何利用CloudOps工具实现运维提效、弹性降本。
551 0
|
监控 容灾 安全
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(下)
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(下)
321 0
|
监控 容灾 安全
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(上)
《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(上)
520 0
|
容灾
《云上容灾交付服务白皮书》——2.容灾技术架构——2.2 容灾技术架构选型
《云上容灾交付服务白皮书》——2.容灾技术架构——2.2 容灾技术架构选型
211 0
|
运维 安全 容灾
《云上容灾交付服务白皮书》——2.容灾技术架构——1.2 行业合规性要求
《云上容灾交付服务白皮书》——2.容灾技术架构——1.2 行业合规性要求
188 0
|
边缘计算 容灾 Cloud Native
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(下)
《云上容灾交付服务白皮书》——2.容灾技术架构——21容灾技术架构简介(下)
645 0
|
容灾
云上容灾交付服务白皮书
云上容灾交付服务白皮书
199 0
|
6月前
|
容灾 NoSQL 关系型数据库
混合云应用双活容灾最佳实践
越来越多的企业在数字化转型和上云进程中选择混合云的形态(云+自建IDC或云+其他厂商云)来进行容灾建设,一方面不会过度依赖单一云厂商,另一方面还能充分利用已有的线下IDC资源。MSHA云原生多活容灾解决方案,支持混合云多活容灾产品能力。本文会通过一个业务Demo案例,介绍混合云容灾建设的难点,以及如何基于MSHA来快速搭建应用双活架构并具备分钟级业务恢复能力。
138 0
混合云应用双活容灾最佳实践