除了 K8S下的 POD 内有状态应用的部署及单 ECS 实例部署方式外，云环境下还存在着分布式应用的部署架构、应用高可用集群如：Windows Failover Cluster、主备应用服务器高可用架构、Oracle RAC 基于共享存储的应用架构，而这些分布式架构同样需要跨云盘及跨节点的数据一致性保护要求。
云计算存储后端往往采用分布式存储架构。在分布式环境下缺少全局逻辑时钟，这就使得实现单 ECS 实例及跨 ECS 实例，K8S 环境下的单 POD 及跨节点的多云盘的一致性组快照不是件容易的事情。要实现快照对 IO 性能影响最低更是富有技术挑战性的。业界针对多盘崩溃一致性快照的实现技术主要分为两大类：
- 采取快照期间阻塞写 IO 的方式，实现基于时间点的跨多盘数据崩溃一致性
- 采取逻辑时钟的定序算法，但依赖于分布式存储实现，实现难度较高。
一致性组快照采取第二种方式，追求快照对 IO 性能无损，实现快照对应用性能影响到最小
实现原理：采取基于 IO 定序算法，快照创建无需写 IO 阻塞。很多用户担心创建快照影响 IO 性能，只在业务低谷期才进行快照数据保护。我们优化提升的多盘一致性组快照算法打破了人们对快照 IO 影响印象，基于写顺序保序机制，主动按照写 IO 到达底层存储的顺序，采取 IO 打标及定序过程。基于快照完成时刻点及 IO 定序来确定快照中应该包含的 IO 数据集合。
由于快照定序过程相对于传统的方式，不会阻止 IO 写入过程；相比于传统的写时拷贝 COW 方式，快照生成过程采取写时重定向 ROW 的写入方式，后台数据集合引用生成过程对 IO 链路无影响，降低快照对 IO 性能的影响最小，对数据库业务的读写场景实现了 IO 性能无损。
对数据库应用使用 2 块盘, 2 个客户端，容量为 4TB，随机写，iodepth=16，jobs=1, 写入块大小 16KB 的测试数据库高 IOPS 场景中，快照创建过程中对 IO 影响测试，友商1及友商2的快照创建过程中对 IO 的性能影响几乎增加了 1 到 3 倍。
应用一致性快照
ESSD 云盘快照数据的一致性类型主要分为崩溃一致性和应用一致性。崩溃一致性要求文件系统及应用程序具有宕机恢复能力，其特点是恢复点目标 RPO 低，业务影响小。但在以下场景无法满足数据备份可靠性高及秒级恢复时间点目标 RTO:
- 原子性缺陷风险：文件系统及数据库应用实现事务原子性的实现具有一定的难度，可能存在缺陷。系统顶级会议 USENIX 上发表的《All File Systems Are Not Created Equal》一文阐释了应用程序及内核保证原子性可能存在实现缺陷。
- 数据丢失风险：主流文件系统默认以性能优先方式工作,崩溃一致性备份存在数据丢失风险。Linux 上 ext4 文件系统默认数据写入模式为 ordered 模式，文件系统校验修复过程存在数据丢失风险；数据库应用配置为性能优先，业务数据有丢失风险。
- 生成时间长及影响大：传统文件级物理备份方式及备份代理方式依赖于逻辑卷快照的生成，耗时长及系统影响大。备份代理需要安装内核驱动，兼容性差及维护成本高；文件备份过程需要读取数据，耗费系统 CPU 及 IO 资源。应用一致性快照仅在生成一致性时间点与应用互通，无增量数据生成及备份读写操作。
实现原理：与传统备份方式相比，应用一致性快照对用户的价值在于提供云原生的无代理应用一致性快照，简化了客户使用传统备份方式所产生的：资源消耗，发布复杂性、软件兼容性，内核开发，软件维护的成本。
采取跨平台插件与专有一致性组件相结合的方式，基于文件系统内核及 Windows 上的 VSS 机制实现快照期间 IO 及应用事务的数据静默，达到企业应用程序在存储快照中的数据一致性要求。所采取的生成协议基于影响时长自动恢复 IO 影响，快照一致性类型取决于创建协议提交结果及应用状态，优化从上层应用到底层存储的链路长度及一致性组件性能，将 IO 影响时长降低到秒级。创建频率间隔可根据业务要求做到文件系统一致性秒级完成创建及分钟级应用一致性快照间隔。
