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.
Pools can be created by configuring a new pool, or importing an existing pool. Importing an existing pool is only used to import pools previously configured on an Oracle ZFS Storage Appliance, and is useful in case of accidental reconfiguration, such as when moving pools between controllers, or due to catastrophic controller failure.
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.
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.
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.
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.
The 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.
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) 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.
Related Topics