Introduction to pools
A pool is a set of drives that provide specific storage characteristics for the resources that use them. For example, the pool configuration defines the types and capacities of the drives in the pool. For physical deployments, the pool configuration also defines the RAID configurations (RAID types and stripe widths) for these drives.
You choose which pool to use when you create a new storage resource.
Pools generally provide optimized storage for a particular set of applications or conditions. When you create a storage resource for hosts to use, you must choose a pool with which to associate the storage resource. The storage that the storage resource uses is drawn from the specified pool. If there are multiple drive types on the system, you can define multiple tiers for the pool. In physical deployments, each tier can be associated with a different RAID type.
Unity supports two types of pools, depending on your Unity model.
All-Flash models running Unity OE version 4.2 and later supports both dynamic and traditional pools. In these models, all new pools created in the Unisphere GUI are dynamic pools. New pools created using the Unisphere CLI or REST API can be dynamic pools (the default) or traditional pools. Although you cannot create traditional pools in the Unisphere GUI, you can use the GUI to manage existing traditional pools.
All-Flash models running Unity OE version 4.1x and earlier, and all hybrid and VSA models support traditional pools only.
In Unity all-Flash models running OE version 4.2.x or later, all new pools created in the Unisphere GUI are dynamic pools, and new pools created in the Unisphere CLI and REST API are dynamic pools by default. Dynamic pools implement advanced RAID technology. In dynamic pools, a RAID group is spread across drive extents in multiple drives. The required spare space is also spread across drive extents in multiple drives. When a drive fails, the extents on the failed drive are rebuilt to spare space extents within the pool.
Dynamic pools have the following advantages over traditional pools:
- Drives are not wasted, because there are no fixed spares. All drives in the system can be added to a pool. This prolongs the life of the drives in the pool, since the load is spread across additional drives.
- Rebuild times are usually much faster than with traditional pools. Since spare capacity for a dynamic pool is spread across multiple drives rather than concentrated in on a single hot spare drive, more drives contribute to the rebuilding process when a drive fails.
- Pools can usually be expanded based on desired capacity. For example, you can add one drive at a time to a dynamic pool, providing provisioning flexibility and cost savings.
You can generally provision a dynamic pool with any number of drives, as long as the minimum drive number is satisfied for each specified drive type/capacity combination. The minimum drive number is the selected stripe width for a drive type/capacity combination plus one additional drive (for example, 6 drives for RAID 5 (4 + 1)).
The following considerations apply to dynamic pools:
- Once a dynamic pool is created, you cannot change its RAID type or stripe width. However, if you expand the pool using a different drive type, the added drives can have a different stripe width.
- You cannot shrink a dynamic pool or change its storage characteristics without deleting the storage resources configured in the pool and the pool itself. However, you can add drives to expand the pool.
- You can mix Flash drives of the same drive type with different capacities when you provision a dynamic pool. However, if you do this, the system might not use the entire capacity of the larger drives. This depends on how many drives of each capacity are in the pool. The unused capacity in a dynamic pool might become available during a future pool expansion.
One drive's worth of capacity equal to that of the largest drive in the pool is set aside as spare space for every set of 32 drives in a dynamic storage pool. For example, a dynamic pool with 1 to 32 drives of a given drive type has 1 drive's worth of spare space, while a dynamic pool with 33 to 64 drives of a given drive type has 2 drive's worth of spare space. At a minimum, there must be the equivalent capacity of one spare drive per pool. Therefore, to minimize the amount of spare capacity required, it is recommended that you create dynamic pools with larger, rather than smaller, numbers of drives of the same drive type.
Dynamic pools can be homogeneous or heterogeneous. All drives in a homogeneous pool have the same drive type, such as SAS Flash 2 or SAS Flash 3 drives. Drives in a heterogeneous pool can include SAS Flash 2 drives, SAS Flash 3 drives, and SAS Flash 4 drives.
Pools created in UnityVSA models, hybrid models, and Unity all-Flash models running OE version 4.1.x or earlier are traditional pools. For Unity all-Flash models running OE version 4.2.x or later, you can create traditional pools using the Unisphere CLI or REST API, but not the Unisphere GUI.
Traditional pools can be homogeneous or heterogeneous. All drives in a homogeneous pool have the same drive type, such as SAS drives or SAS Flash 2 drives. Drives in a heterogeneous pool have a mixture of drive types, such as a mixture of NL-SAS, SAS, and SAS Flash 2 drives. Traditional pools can also be all-Flash or hybrid. A hybrid pool contains a mixture of Flash and non-Flash drives. All supported drive types can be included in a hybrid pool, except for SAS Flash 4 drives, which must be in an all-Flash pool.
In physical deployments, storage in traditional pools is managed in RAID group units, where:
- A drive is consumed by a single RAID group.
- A RAID group is limited to a maximum of 16 drives and is composed of drives of the same type.
- Each tier supports a single RAID type.
Since storage in traditional pools is managed in RAID group units, adding capacity to a pool requires that you add drives in RAID group increments. For example, to add drives to a pool with RAID 5 (4+1), you must add at least 5 drives to the pool. As drive capacity increases, the minimum amount of storage that can be added to a pool and the cost of that storage become increasingly large.
The following considerations apply to traditional pools:
- Once a tier in a traditional pool is created, you cannot change the RAID type or stripe width of the existing drives in the tier. However, if you expand a tier within a traditional pool, you can specify a different stripe width for the newly-added drives. When you add a new tier to a traditional pool, you can specify a different RAID type, stripe width, or both for the newly-added drives.
- You cannot shrink a traditional pool or change its storage characteristics without deleting the storage resources configured in the pool and the pool itself. However, you can add drives to expand the pool.
With traditional pools, the storage system uses dedicated hot spares to replace a drive that has failed or faulted. Any unused drive in the system with the appropriate drive technology and size can be used to replace a failed or faulted drive in a pool. If a spare drive with the same type and size is not available, the system can use a larger drive of the same type. Because spare drives are dedicated hot spares, they cannot be used to improve pool performance or mitigate Flash drive wear. Also, when a drive fails or is faulted, the whole drive must be rebuilt on the spare drive. Therefore, the rebuild time can be very long, because it is limited by the performance of the single drive whose contents is being rebuilt. This can impact performance. It can also increase the chances of encountering additional drive failures during the rebuild process, which can lead to data loss.
The storage tiers available for both physical and virtual deployments are described in the table below.
- For physical deployments, the storage tier is associated with the physical drive type.
- For virtual deployments, the storage tier is associated with the virtual disk's underlying characteristics and must be manually assigned.
- For both types of deployments, if FAST VP is installed on the system, you can create tiered pools to optimize drive utilization. A tiered pool consists of multiple drive types, such as SAS Flash 2 drives and SAS drives.
Default RAID configuration (physical deployments only)
Extreme Performance tier
Solid state extreme performance drives. The following types are supported:
Provides very fast access times for resources subject to variable workloads. For example, databases can achieve their best performance when using SAS Flash drives. SAS Flash drives are more expensive than SAS drives per GB of storage.
SAS Flash 2, SAS Flash 3, and SAS Flash 4 drives can be used together in the Extreme Performance tier. Only SAS Flash 2 drives can be used in the FAST Cache, and only SAS Flash 2 and SAS Flash 3 drives can be used in FAST VP.
RAID 5 (8 + 1).
SAS - Rotating performance drive
Provides high, all-around performance with consistent response times, high throughput, and good bandwidth at a mid-level price point. Performance tier storage is appropriate for database resources accessed centrally through a network.
RAID 5 (4 + 1).
NL-SAS - Rotating capacity drive
Provides the highest storage capacity with generally lower performance. Capacity storage is appropriate for storing large amounts of data that is primarily static (such as video files, audio files, and images) for users and applications that do not have strict performance requirements.
For data that changes or is accessed frequently, capacity tier storage has significantly lower performance.
RAID 6 (6 + 2).
Pool best practices
Using fewer pools reduces complexity and increases flexibility. However, it may be appropriate to configure multiple pools, in order to:
- Separate workloads with different I/O profiles.
- Dedicate resources to meet specific performance goals.
- Separate resources for multi-tenancy.
- Create smaller failure domains.
- (Traditional hybrid pools only) Separate pools where FAST Cache is and is not active.
Pools must maintain free capacity in order to operate properly. By default, the storage system raises an alert if a pool has less than 30% free capacity, and will begin to automatically invalidate snapshots and replication sessions if a pool has less than 5% free capacity. It is recommended that a pool always have at least 10% free capacity.
All-Flash pools provide the highest level of performance in Unity. Use an all-Flash pool for applications that require the highest storage performance at the lowest response time. Note the following about all-Flash pools:
- Compression is only supported in all-Flash pools.
- Snapshots and replication operate most efficiently in all-Flash pools.
- FAST Cache and FAST VP are not applicable to all-Flash pools.
Follow these best practices for dynamic pools:
- Because of the way spare space is reserved for dynamic pools, it is recommended that you create dynamic pools with larger, rather than smaller, numbers of drives of the same drive type. Following this practice minimizes the amount of spare capacity required for a dynamic pool.
- Expanding a dynamic pool by adding multiples of the pool's RAID stripe width plus one allows space to be available faster than if you expand the pool by adding fewer drives. You can see the RAID stripe width for a pool with a single drive type by using the CLI.
For traditional pools, it is recommended that you use a single drive size and a single RAID width within a traditional all-Flash pool.
Hybrid pools typically provide greater capacity at a lower cost than all-Flash pools, but also typically have lower overall performance and higher response times. Use hybrid pools for applications that do not require consistently low response times, or that have large amounts of mostly inactive data.
It is recommended that you provision a Flash tier in hybrid pools. The Flash tier helps enable pool performance efficiencies, and improves response times when using snapshots or replication, or both. The minimum recommended Flash capacity is at least 5% of the pool capacity.
You can improve the performance of a hybrid pool by increasing the amount of capacity in the Flash tier, so that more of the active dataset resides on and is serviced by the Flash drives.
Hybrid pools can have up to three tiers (Extreme Performance, Performance, and Capacity). It is recommended that you use a single drive speed, size, and RAID width within a tier of a hybrid pool.
Spare drive policy (physical deployments only)
The spare drive policy applies only to traditional pools.
Any unused drive in the system with the appropriate drive technology and size, or larger, can be used to replace a failed or faulted drive in a traditional pool. Most of the drive configurations require the use of hot sparing, except for the following:
- If the system has only 8 drives in total, and they are of the same type, you can configure RAID 6 (6+2) with no hot spare.
- If the system has only 12 drives in total, and they are of the same type, you can configure RAID 6 (10+2) with no hot spare.
The spare drive policy follows these rules to determine how many drives are left as spares:
- In general, the system reserves one spare drive for every group of 1-31 drives that have the same type, capacity, and rotational speed (or Flash type). For example, if there are 40 300-GB, 15K-RPM SAS drives in the system, the system reserves two of those drives as spares.
The system does not reserve a spare drive for:
- The FAST Cache.
- A system drive, unless it has user data on it.
- Any unused non-system drive can become a spare drive.
- A system drive that does not contain user data can be a spare drive for a failed system drive that has user data.
- A spare drive can be used to replace a failed or faulted drive in the FAST Cache.
- When a spare drive swaps into a pool, it becomes a permanent member of that pool and cannot be used in another pool.
- When a broken drive is fixed or replaced, it can be a candidate for a spare drive or used in another pool.
Refer to the compatibility and interoperability documentation on the support website for a listing of basic platform and component support for the storage system, including capacity limits.
Considerations for expanding pools
You can usually expand dynamic pools based on desired capacity instead of by adding drives that are multiples of the pool's RAID stripe width plus one. For example, you can add two drives to a RAID 5 pool instead of six drives. The following exceptions apply:
- If you add a new drive type when you expand a pool, you must expand the pool with the minimum amount of drives required for the selected RAID configuration.
- Depending on the RAID configuration and number of drives in the pool, there are certain internal thresholds at which you must expand the pool with multiples of the pool's RAID stripe width plus one. The system tells you how many drives you need to add when you try to expand a pool that has reached one of these thresholds.
Expanding a pool by adding multiples of the pool's RAID strip width plus one allows space to be available faster than if you expand the pool by adding fewer drives. You can see the RAID stripe width for a pool with a single drive type by using the CLI.
You expand a traditional pool by adding drives to the pool's existing tiers, adding new tiers that have available drives, or both. When you add drives, you must add them in multiples of the selected RAID stripe width.
- SAS Flash 4 drives.
- Compression-enabled thin LUNs or thin file systems.
- Compression savings. For example, compression was enabled for a period of time on a resource and then subsequently disabled. The savings for when compression was enabled is still available.