Dell Unity: Dynamic versus Traditional Pools - Key Considerations

Dynamic Pool Enhancements and Considerations Compared to Traditional Pools

Dynamic pools offer greater flexibility and scalability than traditional pools by automatically adjusting resource allocation based on current demand. This helps optimize resource utilization, reduce manual management efforts, and improve overall efficiency during fluctuating workloads.

Key Enhancements

• Automatic Scaling: Resources can be dynamically added or removed based on workload requirements.
• Improved Resource Utilization: Minimizes overprovisioning and underutilization by allocating resources as required.
• Reduced Administrative Overhead: Less manual intervention is required for capacity planning and pool management.
• Enhanced Performance: Workloads can access additional resources during peak demand periods, helping maintain service levels.
• Cost Optimization: Dynamic allocation can reduce operational costs by matching resource consumption with actual demand.

Considerations

• Scaling Latency: Resource provisioning or deprovisioning may not be instantaneous and can impact workload responsiveness.
• Capacity Planning: Underlying infrastructure must have sufficient available capacity to support dynamic growth.
• Monitoring Requirements: Effective monitoring and alerting are essential to ensure scaling behavior aligns with workload needs.
• Configuration Complexity: Initial setup and tuning of scaling policies may require additional planning and testing.
• Workload Suitability: Not all workloads benefit equally from dynamic scaling, particularly those with predictable and stable resource requirements.

Overall, dynamic pools provide a more adaptive and efficient approach to resource management, while requiring thoughtful planning, monitoring, and governance to maximize their benefits.

This information is referenced in Manual 80903033: Dell Unity Family Configuring Pools (Version 5.x).

Dynamic pools

In Unity All-Flash models running OE version 4.2.x or later, all new pools created in the Unisphere UI 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. 

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. 

Traditional pools

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 UI.

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.