一致性组解决什么
一致性组（Consistency Group）把一个应用中存在依赖关系的多个卷绑定为一个管理单元，对它做快照、克隆或复制时，组内所有卷共享同一时间点或遵守同一写入顺序。它针对的是跨卷一致性缺陷：数据库的数据文件、日志文件、归档与临时空间往往分散在不同卷上，如果逐卷分别打快照，各卷的时间点互相错位几秒到几分钟，恢复出来的副本可能连实例都启动不了，即使启动也需要长时间做实例恢复甚至人工修复。
基本信息
| 定义 | 多个有依赖关系的卷作为整体的快照或复制单元 |
|---|---|
| 解决的问题 | 跨卷写入顺序与时间点的一致性 |
| 常见成员 | 数据文件卷、日志卷、归档卷、临时空间卷 |
| 操作方式 | 组内卷同时打快照或同步切换复制方向 |
| 与单卷差异 | 单卷只保证卷内一致，组保证卷间一致 |
| 配置前提 | 成员卷通常需位于同一存储系统与同一控制器对 |
典型使用场景
- 数据库整库保护：数据文件与日志卷必须进同一组，否则恢复不自洽
- 虚拟化平台批量快照：多台虚拟机共享同一数据存储时统一取点
- 邮件与协作系统：邮件库、索引库与附件库需要同组保护
- 容灾切换：整组一次性切换方向，避免部分卷先切造成应用不一致
- 测试数据分发：从同一时间点克隆出完整可启动的应用数据集
- 多套业务共用存储：按业务划分组，避免互相影响一致性边界
单卷与组的差异
| 维度 | 单卷快照 | 一致性组 |
|---|---|---|
| 一致性范围 | 仅卷内块级一致 | 组内所有卷跨卷一致 |
| 时间点 | 各卷各自取点 | 组内统一时间点 |
| 依赖管理 | 无显式维护 | 显式维护成员关系 |
| 恢复表现 | 多卷恢复可能互相错位 | 整组恢复保持业务自洽 |
| 容量规划 | 按单卷变化量 | 按组内变化量总和 |
| 变更成本 | 低 | 成员增减需重新评估与验证 |
一致性组通常要求成员卷位于同一存储系统、同一控制器对或同一复制会话中，因为它依赖统一的时间点控制或统一的写顺序控制。跨阵列的组一致性需要产品层面支持特定机制，配置前应先确认能力边界，不要假定任意卷都能加入同一个组。
组一致性不等于应用一致性。存储层只能保证卷之间的时间点与写入顺序对齐，无法感知数据库的事务状态与内存缓存。要得到应用一致的副本，仍需在取快照前让应用进入静默、刷盘或短暂只读状态，并按应用文档要求执行。
配置检查清单
配置检查清单
# 1) 成员卷是否覆盖应用全部依赖卷，有无遗漏临时空间与归档卷
# 2) 组内卷是否位于同一存储系统与同一控制器对
# 3) 取快照前是否会触发应用静默或刷盘动作
# 4) 组内卷变化量总和是否在快照预留空间之内
# 5) 恢复演练是否按整组还原并真正启动过业务