A pool is a collection of drives within the system arranged into an aggregated group, with some form of RAID protection applied to the drives to provide redundancy. The capacity within the pool, minus the overhead for the RAID protection selected, can be used to provision block, file, or VMware® vSphere® Virtual Volumes™ (vVols) storage resources. Dynamic pools were released in Dell UnityOS version 4.2 for all-flash systems and hybrid flash systems in UnityOS 5.2. This feature increases the flexibility of configuration options within the system with an entirely redesigned pool structure. In Dell Unisphere™, dynamic pools is the default pool type for all-flash systems in UnityOS 4.2 and later and hybrid flash systems in UnityOS 5.2 and later. Dynamic pools can be created, expanded, and deleted like traditional pools, but include other improvements as well.
Within a traditional pool, private pool RAID groups are created based on the RAID protection and width selected at time of pool creation or expansion. These private RAID groups are fixed in width, and drives must be added to the pool in drive-count multiples which match the stripe width selected. Dynamic pools eliminate the need to design a pool based on a multiple of a stripe width. When creating a dynamic pool, once a minimum drive count for a given RAID protection has been selected, the user can select almost any number of drives to place within the pool. This allows planning a pool based on a specific capacity without concern for stripe-width-based multiples of drives counts. When expanding a dynamic pool, since the stripe-width multiple does not apply, the user can also expand by a specific target capacity. In most cases, the user can add a single drive to the pool to increase its capacity. These features provide flexible deployment models which improves the planning and provisioning process. The total cost of ownership of the configuration is also reduced because extra drives needed to fulfill a stripe-width multiple are eliminated.
In systems that use traditional pools, hot spares must be included in the configuration. This requirement increases the cost of a solution for drives that are left unused within the system, and are only used when a drive is failing or has failed. For dynamic pools, space is reserved within the pool to replace drives which may fail or have failed within the pool. This space is considered overhead, and is not part of the usable capacity of the pool. With this, hot spares are not required for dynamic pools, and all drives within a storage system can be placed within a dynamic pool. To fully use the drives within a dynamic pool, the user data and space reserved for drive failures is spread across all drives within the pool. This helps to spread out application I/O across the drives within the pool, and also helps to spread out and mitigate wear across the drives.
As dynamic pools are created without using discreet groups of drives, rebuild operations are different than rebuilds occurring within a traditional pool. When a drive is failing or has failed with a traditional pool, a hot spare is engaged and used to replace the bad drive. This replacement is one-to-one, and the speed of the proactive copy or rebuild operation is limited by the fixed width of the private RAID group and the single targeted hot spare. With dynamic pools, regions of RAID and regions within the pool used for drive replacement are spread across the drives within the pool. In this design, multiple regions of a failing or failed drive can be rebuilt simultaneously. As the space for the replacement is spread across the drives in the pool, the proactive copy or rebuild operations are also targeted to more than one drive. With these features, the amount of time to replace a failed drive is significantly reduced.