云原生趋势下思考

Posted 2021-07-28 云容灾备份安全治理

云原生（Cloud Native）应用为核心，轻量化基础架构层在系统建设过程中的角色。但是无论如何变化，IT整体发展方向，一定是向着更有利于业务快速迭代、满足业务需求方向演进的。

为什么传统容灾的手段无法满足云原生需求呢？简单来说，二者关注的核心不同。传统的容灾往往以存储为核心，拥有对存储的至高无上的控制权。并且在物理时代，对于计算、存储和网络等基础架构层也没有有效的调度方法，无法实现高度自动化的编排。而基于云原生构建的应用，核心变成了云原生服务本身。当用户业务系统全面上云后，用户不再享有对底层存储的绝对控制权，所以传统的容灾手段，就风光不在了。

构建云原生容灾的解决方案上，要以业务为核心去思考构建方法，利用云原生服务的编排能力实现业务系统的连续性。

数据安全性：

Everything fails, all the time。通过AWS的责任共担模型，我们不难发现云商对底层基础架构负责，用户仍然要对自身自身数据安全性和业务连续性负责。

防止厂商锁定

多云管平台定义中，将迁移和DR作为单独的一项能力。充分说明迁移与容灾在多云环境的的常态化趋势。

云迁移与云容灾的关系

云迁移和容灾，并不是堆人提供的迁移服务，而是强调的高度自动化的手段。目标就是在迁移过程中保证业务连续性，缩短停机时间甚至不停机的效果。这里就借助了容灾的存储级别同步技术来实现在异构环境下的的“热迁移”。现有解决方案里，既有传统物理机搬迁时代的迁移软件，也有基于云原生开发的工具。但无论何种形式，都在不同程度上都解决了用户上云的基本诉求。最大的区别在于人效比。

云迁移方式：物理机到虚拟化、虚拟化到虚拟化、物理机到云平台、虚拟化到云平台。

与上面这张经典的迁移理论相比，我更喜欢下面这张图，这张图更能反应一个传统应用到云原生成长的全过程。

传统的热迁移方案基本分为块级别和文件级别，两者相似之处都是利用差量同步技术进行实现，即全量和增量交叉同步方式。

云原生热迁移方案是指利用块级别差量同步技术结合云原生API接口和资源实现高度自动化迁移效果，同时提供多租户、API接口满足混合云租户自服务的需求。

平台重建（Replatforming）方式

云原生下的容灾发展趋势

传统架构

简单Wordpress + mysql环境为例，传统下部署环境架构

用架构设计一套容灾方案，可以采用方式

负载均衡节点容灾

Web Server容灾

共享文件系统容灾

数据库容灾

案例分析不难看出，传统基础架构下的容灾往往以存储为核心，无论是磁盘阵列的存储镜像，还是基于I/O数据块、字节级的捕获技术，结合网络、数据库和集群的应用级别技术完成高可靠和容灾体系的构建。在整个容灾过程的参与者主要为：主机、存储、网络和应用软件，相对来说比较单一。在传统容灾方案中，如何正确解决存储的容灾也就成为了解决问题的关键。

混合云容灾

云上同城容灾架构

同云异地容灾架构

跨云容灾

云原生容灾以备份为核心，以迁移、恢复和高可靠为业务场景，实现多云之间的自由流转，最终满足用户的业务需求。

作为面向云原生的容灾平台要解决好三方面的能力：

以数据为核心，让数据在多云之间互相流转。数据是用户核心价值，所以无论底层基础架构如何变化，数据备份一定是用户的刚醒需求。对于不同云原生服务如何解决好数据备份，是数据流转的必要基础。

利用云原生编排能力，实现高度自动化，在数据基础上构建业务场景。利用自动化编排能力实现更多的基于数据层的应用，帮助用户完成更多的业务创新。

灵活运用云原生资源特点，降低总体拥有成本。解决传统容灾投入巨大的问题，让用户的成本真的能像水、电一样按需付费。