• HyperBDR云容灾深度解析二:自研Boot in Cloud技术,实现高度自动化云容灾


    企业客户在云容灾过程中,会遇到不同的难题:人力堆叠、技术门槛高、一个工具无法实现容灾的整个过程。这些问题都是容灾工具不够智能、自动化导致的。

    HyperBDR云容灾以Boot in Cloud独家技术,实现高度自动化跨平台容灾。

    Boot in Cloud是HyperBDR的底层核心技术之一,类似一个核心引擎,驱动HyperBDR实现各种功能:多云编排,驱动智能适配,无需1:1预启动云端实例,一键云端拉起业务系统到可用状态,直接恢复到操作系统登录页面。

    多云编排

    API(Application Program Interface)被定义为应用程序可用以与计算机操作系统交换信息和命令的标准集。API接口相当于功能权限的访问入口,成功对接云端API接口后,就可以调用API相应的功能。要实现场景下的某个功能,通常需要多个API组合使用,才能达到理想效果,这个过程非常考验产品本身对云对亲和度。虽然各个云商都有开放一定数量的API接口,但完成API对接来实现各种云容灾功能还是有一定的挑战。

    HyperBDR云容灾对接多个云厂商,实现多云编排,目前已覆盖20+云40多个版本。据统计,平均每朵云对接50个API接口以上。

    多云编排能力实现从本地到云、从云到云的数据自由流转,满足多场景下的政企客户个性化容灾需求。

    驱动智能适配

    驱动一般指的是设备驱动程序(Device Driver),是一种可以使计算机和设备进行相互通信的特殊程序。相当于硬件的接口,操作系统只有通过这个接口,才能控制硬件设备的工作,假如某设备的驱动程序未能正确安装,便不能正常工作。

    客户源端的数据中心,往往有多种架构不同系统的主机需要容灾,每种架构系统适配的驱动也是不一样的。在容灾上云时,源端主机需要成功适配云端驱动,才能顺利在云端恢复业务。而异构导致恢复业务时驱动适配失败,无法直接拉起业务的情况屡见不鲜,一旦发生,非常耽误RTO\RPO(容灾恢复指标),让政企客户承受不必要的损失。

    HyperBDR云容灾,通过Boot in Cloud独家技术,实现源端主机智能适配驱动。对虚拟化、超融合都有兼容性适配,支持VMware、OpenStack源端无代理模式备份,架构复杂的传统数据中心轻松容灾上云。

    3 N:1云容灾

    常见的云容灾工具,灾备端(云)是需要和源端一样1:1配备云计算资源。例如客户有100台主机需要云容灾,就需要在云上提前准备好100台云主机。平时不需要进行恢复操作时,这部分云资源的消耗是非常大的的,但事实上,在云容灾项目里,我们常见操作是持续备份,容灾的接管和演练发生几率极低,不需要浪费过多云实例资源。

    HyperBDR云容灾,通过Boot in Cloud独家技术,实现N:1的普惠化云容灾。平时只需要以源端主机数量N:1准备云硬盘,仅需为数据备份消耗的云硬盘付费,不需要在云端1:1预启动实例,只有在恢复业务时才需要启动云主机。HyperBDR 这种N:1云容灾,是一个容灾方式上的革新,为各个政企客户,提供了一个普惠化的容灾新选择。

    总结

    Boot in Cloud,一句话总结就是万博智云HyperBDR内嵌的云端编排能力,实现可在云端一键拉起主机,接管业务到可用状态。Boot in Cloud是HyperBDR云容灾核心能力的体现,让高度智能自动化、跨多平台、普惠的HyperBDR云容灾方案成为可能。

  • 相关阅读:
    【go】字符串切片与字符串出入数据库转化
    Python: 你所不知道的星号 * 用法
    聊聊(微服务之SpringCloud+Boot共11章节)看看你会多少?
    一幅长文细学Vue(七)——路由
    【js奇妙说】如何跟非计算机从业者解释,为什么浮点数计算0.1+0.2不等于0.3?
    Jenkins CI/CD 持续集成专题三 Jenkins 使用shell脚本打包组件配置流程
    穿透组网EasyNTS上云网关添加设备后无法成功保存是什么原因?
    interview3-微服务与MQ
    十九、【文本编辑器(五)】排版功能
    JVM内存模型和结构详解(五大模型图解)
  • 原文地址:https://blog.csdn.net/OneProCloud/article/details/126180508