在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 的比例可能是最佳選擇。