Hitachi Dynamic Provisioning
You can use Hitachi Dynamic Provisioning (HDP) software to improve your storage utilization. The HDP software uses storage-based virtualization layered on top of RAID technology (RAID on RAID) to enable virtual LUNs (dynamically provisioned volumes, DP-Vols) to draw space from multiple pool volumes. This aggregated space widens the storage bottleneck by distributing the I/O to more disks. The greater distribution insulates the server from the realities of the pool volumes (small capacities of individual disks).
HDP with a NAS server provides the following benefits:
- Improves performance by striping I/O across all available disks
- Supports larger LUs, typically up to 64 TiB
- Reduces the need to use the span-expand command. When HDP thin provisioning is used, an HDP pool can be expanded in small increments any number of times. However, if you expand a storage pool, make the increments as large as the initial size of the storage pool to avoid performance problems.
- File system creation and expansion are safe, even on thinly provisioned HDP pools, because they check the amount of available space.
If you are using HDP, see the Hitachi NAS Platform HDP Best Practices (MK-92HNAS063) for recommendations.
HDP high-level process
The following flow chart shows the high-level process for provisioning storage with HDP:
Understanding HDP thin provisioning
Thin provisioning allows space to be allocated to an application without it being physically mapped on the storage system until it is actually used. Thin provisioning also decouples the logical provisioning of storage to an application from the physical addition of storage capacity to the storage system.
For example, given 30 TiB of physical storage, you can create an HDP pool with 80 TiB of DP-Vols and create an 80 TiB NAS storage pool on those DP-Vols. None of the available space is allocated until you create and expand file systems. Because only 30 TiB of real space is available, the NAS server will not create more than 30 TiB of file systems in the storage pool. If you later add more parity groups or pool volumes to the HDP pool, you can expand the file systems in the storage pool beyond 30 TiB without creating additional DP-Vols or expanding the NAS storage pool.
The ability to expand file systems instead of the storage pool is advantageous because it enhances performance by spreading the storage chunks used to expand a file system across all the SDs and physical disks in the DP pool. In contrast, a storage pool expansion limits performance by restricting the individual chunks to a small number of SDs and physical disks.
The NAS server reads the real space available in a DP pool. When you create or expand a file system, the NAS server checks for available space, then pre-allocates the space needed for that operation. If the DP pool has too little free space for the operation to complete successfully, the NAS server safely aborts the creation or expansion of the file system.
Every new storage pool should use a single stripeset that resides on a thinly provisioned HDP pool. This way, storage can be expanded in small increments without loss of performance, and all I/O will use all DP-Vols (and all their queue depth) and all physical storage media. For more about queue depth, see the sd-queue-depth man page. To use a single stripeset, follow the instructions below.
The process is as follows:
- When provisioning a new NAS server storage pool, use just enough real disk space to meet your immediate needs for performance and capacity.
- Place all your parity groups into a single HDP pool, then create DP-Vols whose total capacity roughly meets your expected needs for the next 18 to 24 months.
NoteIt does not matter if you over-estimate or under-estimate your capacity needs, because you can easily expand the storage pool beyond the total capacity of the original DP-Vols by adding another set of DP-Vols.
- Create a NAS server storage pool on these DP-Vols, placing all the DP-Vols into a single stripeset.
Use enough DP-Vols to provide adequate queue depth in the future, after you have added enough parity groups to match the total capacity of the DP-Vols. Four DP-Vols is the bare minimum, but eight DP-Vols will provide better performance than four, and sixteen DP-Vols will be faster than 8 DP-Vols. In practice, a storage pool usually contains an even number of DP-Vols, and the capacity of each DP-Vol is 8 TiB.
NoteIf using the CLI span-create command, list all the SDs in the initial span-create command. Do not run a single span-create command, then a series of span-expand commands.NoteWhen using an application to create a storage pool, specify all the available SDs when creating the storage pool; do not create a single storage pool on a subset of the available SDs, then expand that storage pool onto the rest of the available SDs.If there are more than 32 available DP-Vols, create the minimum possible number of NAS server stripesets consistent with making all stripesets identical, even if this means creating slightly more or slightly fewer DP-Vols than would otherwise have been created. For example, if you initially estimate that, in two years, you will need 50 8 TiB DP-Vols, you should now create 48 DP-Vols and make 2 stripesets of 24 DP-Vols each.
- To expand the NAS server storage pool beyond the total capacity of the original DP-Vols, simply add another, identical set of DP-Vols (refer to the span-expand man page for more information).
Deciding how far to over-provision storage
When using HDP, you should make a rough forecast of how much data storage capacity will be needed in the next 12 to 24 months, and then configure your DP-Vols to be larger than your estimate. If you overestimated your data storage requirements, not too much space will have been wasted.
The total capacity of the DP-Vols should exceed the total capacity of the parity groups or pool volumes by a factor of 2:1 or 3:1, depending on how far you expect the storage pool to expand. The total capacity of the DP-Vols created when the storage pool was initially set up does not constrain the eventual size of the storage pool.
For example, if you have 20 TiB of storage and the storage pool may need to expand to 50 TiB later on, you should set up 50 TiB of DP-Vols. If you ever need to grow the storage pool beyond 50 TiB, you can always add a second stripeset using the span-expand command, then continue to expand the DP pool in increments as small as required.
Limits on thin provisioning:
- You can make the storage pool capacity larger than the total capacity of the DP-Vols that you created at the outset by adding more DP-Vols later.
- Some storage arrays and systems do not over-commit by more than a factor of ten to one.
- For
HDP, the storage requires an amount of memory that is proportional to the capacity of the large, virtual DP-Vols, rather than to the smaller, real parity groups or pool volumes. Therefore, consider the following:
- Massive over-commitment causes storage to run out of memory prematurely.
- Enterprise storage uses separate boards called shared memory.