Article / 文章中心

混合云应用双活容灾最佳实践

发布时间:2022-01-04 点击数:245

作者:远跖


01

前言

Cloud Native


越来越多的企业在数字化转型和上云进程中选择混合云的形态(云+自建 IDC 或云+其他厂商云)来进行容灾建设,一方面不会过度依赖单一云厂商,另一方面还能充分利用已有的线下 IDC 资源。


MSHA 云原生多活容灾解决方案[1],也发布了混合云多活容灾产品能力。本文会通过一个业务 Demo 案例,介绍混合云容灾建设的难点,以及如何基于 MSHA 来快速搭建应用双活架构并具备分钟级业务恢复能力。
02

业务混合云容灾实践

Cloud Native

1 业务背景信息


A 企业是一个零售行业电商交易平台,业务系统部署在自建 IDC 机房,存在以下痛点:
  • 业务仅在 IDC 单机房部署,缺少容灾能力。

  • IDC 容量不足,物理机器升级替换周期长,不足以支撑业务的快速发展。

业务在快速发展过程中,多次遇到的容量不足以及故障问题引起了公司高层的重视,决心进行容灾能力建设。由于自建 IDC 是公司已有资产且稳定使用多年,同时不希望过度依赖于云,因此期望建立 IDC+云 的混合云形态容灾架构。

当前应用部署架构


电商交易平台包含的应用:
  • frontend:Web 应用,负责和用户交互。

  • cartservice:购物车应用,提供购物车添加、存储和查询服务。

  • productservice:商品应用,提供商品、库存服务。

技术栈:
  • SpringBoot。

  • RPC 框架:SpringCloud、Dubbo,注册中心使用自建的 Nacos、Zookeeper。

  • 数据库 Redis 和 MySQL。

    数据库 Redis 和 MySQL

    2 混合云容灾目标


    业务容灾需求归纳如下:
    • 云上云下互容灾,切换 RTO 为分钟级。期望云上云下相互容灾,继续发挥 IDC 的价值,且不 100% 依赖于云。面对 IDC 或云故障场景,关键时刻要敢切换、能切换,且切换 RTO 要求小于 10 分钟。

    • 无数据一致性风险。云上云下的两个数据中心数据强一致,日常态和容灾切换过程中都要避免存在脏写等数据一致性风险。

    • 一站式管控。业务容灾涉及的技术栈框架和云产品,需要统一管控、统一运维、统一切换,操作收敛在一站式管控平台,方便故障场景快速白屏化操作,自动化执行。

    • 实施周期短,改造成本低。业务存在多个产品线,依赖关系复杂、调用链路长,且处于高速发展频繁迭代时期,期望容灾建设不会给业务研发团队带来改造负担。

    3 建设难点



    • 流量管理难度高

      • 若采用 DNS 将流量按权重解析到云上和云下,存在修改 DNS 解析生效时间长的问题(通常为十分钟或小时级,参见 DNS 解析生效时间 FAQ[2]),不能满足容灾切换小于 10 分钟的要求。

      • 业务应用所依赖的 Redis 和 MySQL,IDC内采用开源自建而云上直接使用云产品,要实现开源自建+云产品的容灾切换能力难。

    • 容灾切换数据质量保障难

      • 容灾切换过程中,可能因数据同步延迟导致读到旧数据,以及切换规则推送到分布式应用节点时间不一致等原因可能造成云上云下数据库同时读写而出现脏写的问题,整个切换过程数据质量保障是个关键点,同时也是难点。

    • 无业务代码侵入难

      • 要实现 Redis、MySQL 容灾切换能力,通常需要业务应用配合改造,对业务代码侵入大。

    4 解决方案


    结合业务容灾需求和混合云 IDC+云形态的特点,采用应用双活架构能够较好的满足业务容灾诉求。

    应用双活架构


    架构简图:


    应用双活架构

    架构规范:
    • 选择离 IDC 物理距离<=200km 的云上 Region,网络延迟较低(约 5~7ms)。

    • 应用、中间件云上云下冗余对称部署,同时对外提供服务(应用双活)。

    • 数据库异地主备,异步复制备份。应用读写同一数据中心的数据库,避免考虑一致性问题。

    详细方案

    电商 Demo 首页


    容灾能力
    • RPO:<=1min(依赖于 DTS 同步性能)

    • RTO:<=1min(依赖于 DTS 同步延迟,MSHA 组件实现秒级切换。整体 RTO<=1min)

    7 容灾能力验证


    基于 MSHA 完成应用双活架构建设后,还需验证业务容灾能力是否符合预期。接下来将制造真实的故障,来验证容灾恢复能力。

    7.1 演练准备


    1. 进入 MSHA 控制台,在左侧菜单栏选择监控大盘。页面顶部,下拉选择切换到实际使用的命名空间


    2. 查看页面中的各项监控指标。


    说明:演练前,基于 MSHA 流量监控或其他监控产品,确定业务稳态的监控指标(如日常情况 RT<=200ms,错误率<1%),以便在故障发生时判断故障影响面以及在故障恢复后判断业务的实际恢复情况。

    MSHA 控制台

  • 7.2 应用故障注入


    这里我们使用阿里云故障演练产品,对阿里云-北京商品应用注入故障。
    1. 进入 Chaos 故障演练产品控制台[9],顶部选择切换到相应地域,左侧导航栏选择我的空间


    2. 我的空间选择配置好的演练(50% 概率网络丢包),然后单击执行演练

    阿里云故障演练产品

  • 故障注入成功后,打开电商首页或进行下单,有概率出现访问异常,符合预期。


    切流恢复

  • 7.3 切流恢复


    在北京单元的商品应用故障的情况下,可以通过 MSHA 切流功能,将云上入口流量切 0,快速恢复业务。


    预期


    100% 流量切换到杭州单元后,业务完全恢复,不受北京单元的故障影响。


    MSHA 切流功能

  • 切流操作


    1. 进入 MSHA 控制台,在左侧导航栏选择切流>异地应用双活切流


    2. 在切流页面,对北京单元点击一键切零
  • 异地应用双活切流

    3. 单击执行预检查,在切流检查区域,单击确认,开始切流。



    4. 在切流任务页面的当前状态显示切流完成,表示切流已成功。

    5. 刷新电商 Demo 首页,多次访问均能正常展示,符合预期。


    查看实际流量调用链:流量始终访问到杭州单元,读写北京单元内的数据库。

    读写北京单元内的数据库

    7.4 数据库故障注入


    从上面调用链可以看出,杭州单元内的应用仍然访问的是北京单元的 Redis、MySQL 数据库。我们继续使用 Chaos 故障演练[10]产品对北京单元的 Redis、MySQL 数据库注入故障,制造数据库故障场景。


     Chaos 故障演练

    故障注入成功后,打开电商首页或进行下单始终访问异常,符合预期。

    7.5 切换数据库进行恢复


    在北京单元的数据库故障的情况下,可以通过 MSHA 数据库切换功能,将应用访问的 Redis/MySQL 的连接切换至杭州单元的数据库(切换过程中会等待数据同步追平,期间会短暂禁写)。


    预期


    应用连接的数据库切换到杭州后,业务完全恢复,不受北京单元的故障影响。

    切流操作


    1. 进入 MSHA 控制台,在左侧导航栏选择异地应用双活>数据层配置


    2.在数据保护规则列表中,找到商品、订单、购物车数据库,逐个点击主备切换



  • 数据保护规则列表

    3. 点击主备切换后,会进入预检查页面,确认各检查项状态正常后,点击在确认执行,则进入切换详情页,并自动执行切换流程。


    4. 主备切换详情页,可以看到切换进度和切换结果,任务进度 100% 后,表示切换完成。
  • 电商 Demo 首页或进行下单5. 商品、订单、购物车数据库都主备切换完成后。多次访问电商 Demo 首页或进行下单,发现均已正常,主备切换后业务功能完全恢复,符合预期。03

    总结

    Cloud Native


    在本篇文章中,我们介绍了 MSHA 多活容灾助力企业进行混合云应用双活容灾建设的实践案例,给出了容灾架构建设实践方法,同时利用 Chaos 故障演练产品注入真实故障,来验证故障场景业务容灾能力是否符合预期。