在ASA r2 系统中，卷仍然存在，但它们会在创建存储单元时自动创建。存储单元（LUN 或 NVMe 命名空间）直接在存储可用区 (SAZ) 中自动创建的卷内进行配置。这种设计消除了手动卷管理的需要，使 Oracle 数据库等块工作负载的配置更加直接和精简。

相关存储单元（LUN 或 NVMe 命名空间）通常位于同一个存储可用区 (SAZ) 内。例如，一个需要 10 个存储单元 (LUN) 的数据库，通常会将所有 10 个单元放置在同一个 SAZ 中，以简化操作并提高性能。

在ASA r2 中，快照策略和计划是在一致性组级别应用的，一致性组是一个逻辑结构，它将多个 LUN 或 NVMe 命名空间分组，以实现协调的数据保护。由 10 个 LUN 组成的数据集只需要一个快照策略，前提是这些 LUN 属于同一个一致性组。

一致性组确保所有包含的 LUN 上的原子快照操作。例如，如果将底层 LUN 分组到同一个一致性组中，则可以将驻留在 10 个 LUN 上的数据库或由 10 个不同操作系统组成的基于 VMware 的应用程序环境作为单个一致的对象进行保护。如果快照被放置在不同的一致性组中，即使在同一时间安排，快照也可能无法完全同步。

在某些情况下，由于恢复要求，可能需要将一组相关的 LUN 分成两个不同的一致性组。例如，一个数据库可能有四个 LUN 用于数据文件，两个 LUN 用于日志。在这种情况下，包含 4 个 LUN 的数据文件一致性组和包含 2 个 LUN 的日志一致性组可能是最佳选择。原因在于独立可恢复性：数据文件一致性组可以有选择地恢复到较早的状态，这意味着所有四个 LUN 都将恢复到快照的状态，而包含关键数据的日志一致性组将不受影响。

SnapMirror策略和操作与快照操作一样，是在一致性组上执行的，而不是在 LUN 上执行的。

将相关的 LUN 放在同一个一致性组中，可以创建单个SnapMirror关系，并通过一次更新更新所有包含的数据。与快照一样，此次更新也将是一个原子操作。SnapMirror目标位置将保证拥有源 LUN 的单一时间点副本。如果 LUN 分布在多个一致性组中，则副本之间可能一致，也可能不一致。

虽然 QoS 可以有选择地应用于单个 LUN，但通常在一致性组级别设置 QoS 更容易。例如，可以将给定 ESX 服务器中所有客户机使用的所有 LUN 放在一个一致性组中，然后应用ONTAP自适应 QoS 策略。最终结果是，每 TiB 的 IOPS 具有自扩展性，并且适用于所有 LUN。

同样地，如果一个数据库需要 100K IOPS 并占用 10 个 LUN，那么在单个一致性组上设置一个 100K IOPS 限制比在每个 LUN 上设置 10 个单独的 10K IOPS 限制要容易得多。

在某些情况下，将 LUN 分布到多个一致性组中可能是有益的。主要原因是控制器条带化。例如，HA ASA r2 存储系统可能托管单个 Oracle 数据库，此时需要每个控制器的全部处理和缓存能力。在这种情况下，典型的设计是将一半的 LUN 放在控制器 1 上的一个一致性组中，将另一半 LUN 放在控制器 2 上的一个一致性组中。

同样地，对于托管多个数据库的环境，将 LUN 分布在多个一致性组中可以确保控制器利用率的均衡。例如，一个 HA 系统托管 100 个数据库，每个数据库有 10 个 LUN，则每个数据库可能将 5 个 LUN 分配给控制器 1 上的一个一致性组，将 5 个 LUN 分配给控制器 2 上的一个一致性组。这样可以保证在配置更多数据库时实现对称加载。

不过，这些例子都不涉及 1:1 LUN 与一致性组的比例。目标仍然是通过将相关的 LUN 在逻辑上分组到一致性组中来优化可管理性。

1:1 LUN 与一致性组比例的一个合理例子是容器化工作负载，其中每个 LUN 实际上可能代表一个单独的工作负载，需要单独的快照和复制策略，因此需要单独管理。在这种情况下，1:1 的比例可能是最佳选择。