Storage Pool Concepts

Storage is configured in pools that are characterized by their underlying data redundancy, and provide space that is shared across all filesystems and LUNs. More information about how storage pools relate to individual filesystems or LUNs can be found in About Storage Pools, Projects, and Shares.

To understand storage pool concepts, use these topics:

Storage Pool Configuration

Pools can be created by configuring a new pool or importing an existing pool. Importing an existing pool is only used to import pools that were previously configured on Oracle ZFS Storage Appliance. Importing an existing pool is useful in case of accidental reconfiguration, such as when moving pools between controllers, or due to catastrophic controller failure.

Multiple Pools

Each controller can have any number of pools, and each pool can be assigned ownership independently in a cluster. With the ability to control access to log and cache devices on a per-share basis, the recommended mode of operation is a single pool. While arbitrary number of pools are supported, creating multiple pools with the same redundancy characteristics owned by the same cluster head is not advised. Doing so will result in poor performance, suboptimal allocation of resources, artificial partitioning of storage, and additional administrative complexity. Configuring multiple pools on the same host is only recommended when drastically different redundancy or performance characteristics are desired, for example a mirrored pool for databases and a RAID-Z pool for streaming workloads.

Number of Devices per Pool

Drives within all of the chassis can be allocated individually; however, care should be taken when allocating disks from disk shelves to ensure optimal pool configurations. In general, fewer pools with more disks per pool are preferred because they simplify management and provide a higher percentage of overall usable capacity.

While the system can allocate storage in any increment desired, it is recommended that each allocation include a minimum of 8 disks across all disk shelves and ideally many more.

Drive Characteristics and Performance

Follow these restrictions when configuring storage pools:

All data disks contained within a head node or disk shelf must have the same rotational speed (media rotation rate). The appliance software will detect misconfigurations and generate a fault for the condition.
Due to unpredictable performance issues, avoid mixing different disk rotational speeds within the same pool.
For optimal performance, do not combine disk shelves with different disk rotational speeds on the same SAS fabric (HBA connection). Such a mixture operates correctly, but likely results in slower performance of the faster devices.
When creating a new pool, avoid mixing different data disk capacities because all disks are then limited to the smallest capacity disk in the pool. When adding a higher capacity disk to an existing pool, the larger disk's capacity is maintained. However, the system preferentially writes to new disks until they begin to reach the same capacity utilization as the old disks. To maintain performance, add as many new higher capacity disks as the total number of disks in the original pool.
A meta device must be a 3.2 TB (minimum) SSD to support the enhanced data deduplication feature available in software version OS8.7.0 or later.

Storage Pool Capacity

When allocating raw storage to pools, keep in mind that filling pools completely will result in significantly reduced performance, especially when writing to shares or LUNs. These effects become more noticeable as the pool reaches full capacity.

All-Flash Storage Configuration

Oracle Storage Drive Enclosure DE3-24P can be configured as all-flash storage with fully populated flash-based SSD data devices and optional log devices. All-flash storage provides low-latency I/O that increases workload performance.

An all-flash storage pool contains data SSDs and optional log devices. Read flash cache and meta devices cannot be part of an all-flash pool. The remaining lifetime of SSDs can be monitored using threshold alerts.

Storage Pool Reclaimed Space

When deleting a project, filesystem, or LUN, you can view the amount of space to be reclaimed in the storage pool if deferred update Asynchronous Dataset Deletion (OS8.7.0 or later) has been accepted. In the BUI, field Asynchronous Dataset Destroy is displayed during these deletion operations. Similarly in the CLI, property async_destroy_reclaim_space reflects the amount of space to be reclaimed and shows 0 (zero) when the operation has completed. The individual procedures to delete a project, filesystem, or LUN contain a step for monitoring the reclaimed space in a storage pool.

Destroy Prevention and Approval

When the prevent share destruction (nodestroy) property is set to on/true at the storage pool level, shares and projects within the pool cannot be deleted. Share and project snapshots, replication packages within the pool, and the pool itself, are also protected from destruction because of inheritance rules. Protection is also extended to destroying a share through dependent clones. However, it does not affect shares destroyed through replication updates. If a share is destroyed on an Oracle ZFS Storage Appliance system that is the source for replication, the corresponding share on the target will be destroyed, even if this property is set to on/true. The property's default setting is off/false.

The prevent destruction (nodestroy) property is also available at the project level, and all shares within the project inherit this property setting. Shares and projects can be deleted by setting this property to off/false at the share or project level. Similarly, when property prevent share destruction (nodestroy) is set to on/true at the pool level, all shares, projects, snapshots, and replication packages in the pool, and the pool itself, are protected. Furthermore, if additional property destroy requires approver (approve_destroy) is set to on/true, then the delete process requires an extra step. This property is only available at the pool level.

When property prevent share destruction (nodestroy) is set to on/true at the pool level, and not set at the share or project level, the pool-level property's setting is the default setting.

To delete a share, project, snapshot, or replication package (CLI destroy command) when it is protected at the pool level, two different administrators must perform the delete action: One administrator, the approver, sets the prevent destruction (nodestroy) property to off/false at the share or project level. A different administrator deletes the share, project, snapshot, or replication package in the normal manner. The approving administrator's username is recorded in read-only property destroy approved by (destroy_approved_by). In the BUI, the approver's username is displayed in the project's sidebar, along with other static properties, as well as on the pool's properties page. If all projects within the storage pool have been approved for deletion, then the pool itself can be unconfigured.

When the prevent destruction (nodestroy) property is set again to on/true at the project level for the same project, it clears property destroy approved by (destroy_approved_by).