This chapter introduces the concepts and terminology that are related to thin provisioning. It includes a brief overview of the IBM DS8880 thin provisioning implementation and the following topics:

Thin provisioning is one way to help cut costs and reduce your storage footprint. Thin provisioning on volumes allows customers to create and use volumes where the sum of all virtual volume capacity might logically exceed the physical capacity of an extent pool.

However, the volumes allocate only the physical extents that they use, as needed. Thin provisioning allows you to define large volumes when they are created. This feature eliminates the need to go through the procedures to increase volume sizes later, which makes storage management easier.

Thin provisioning applies to shared storage environments. The concept of thin provisioning is to allocate storage (blocks or other elements of storage capacity) when application data is effectively written to a host-attached volume. This difference is the fundamental difference with the traditional, fully provisioned volume, where the volume capacity is entirely allocated at the time the volume is created. In this case, the host to which the fully provisioned volume is attached owns the full capacity, which uses unused storage in the back-end system.

The general differences between full provisioning and thin provisioning are shown in Figure 1-1.

A volume that supports thin provisioning is referred to as a space-efficient volume. When the volume is created, real capacity as required for metadata is physically allocated only. The DS8880 uses specific metadata to manage and determine when capacity must be allocated for write operations.

The volume is created with the full capacity that is requested by the user. However, this capacity is virtual because the allocation occurs only with the first host write to the volume. The sum of all space-efficient volume capacity represents the storage system virtual capacity.

When a space-efficient volume is assigned to a host, the host sees the whole (virtual) capacity of the volume as though it were a fully provisioned volume. All I/O activities that are performed by the storage system to allocate space when needed are fully transparent to the host.

The amount of real capacity in the storage system is shared between all space-efficient volumes. The amount of real capacity is, by definition, less than the total virtual capacity. The ratio between virtual capacity and real capacity represents the storage oversubscription or storage over-commitment.

Thin provisioning allows a more efficient capacity use in the storage subsystem. The automated capacity allocation (when required by applications) facilitates capacity management, as well. Capacity monitoring is still necessary, but can now be changed from a volume-based tracking, which can be done only on a per server basis to the back-end storage subsystem, where the overall view of virtual capacity and real capacity allocation is available.

The thin provisioning model of the DS8880 (independent of any specific host platform) is shown in Figure 1-2. The elements of this common model are described next.

The virtual capacity is the sum of all defined host volumes capacity. The virtual capacity can be large (much larger than the physical capacity). Little real physical capacity is allocated when thin-provisioned volumes are created and only some capacity for the virtual volume’s metadata. You can create as many space-efficient volumes as needed if physical capacity is available for the metadata that is available and you want some space for the actual user data.

The real capacity pool is the sum of all extents that are available in an extent pool in the DS8880. It is the reservoir for physical capacity allocation when it is requested. When capacity allocation occurs, each allocation of real capacity is mapped to the space-efficient volume. The metadata for the virtual volumes also is using some of that capacity.

Space-efficient volumes are usable volumes that can be assigned to any hosts. These volumes do not have any physical capacity (except for their required metadata) when they are created. With the first write operation to the volume, real capacity from the real capacity pool is allocated to the volume.

This section provides some typical usage examples of thin-provisioned volumes.

As a simple example, consider typical user data in a business environment. Such data is normally the same kind for all users and might consist of local mail replica, cached data from web browsers, or other application data that is commonly used by users in a business environment.

In addition, most users have similar capacity requirements for this type of data. However, some users can also have specific applications with different capacity requirements. For example, users who frequently work with documents, spreadsheets, and presentations require less capacity than users who are working with images, other multimedia data, or other binary and scientific data.

Assuming that no user is requesting more than 10 GB of data and that the average of effectively used data is less than 6 GB per user, the storage administrator can decide to allocate 10 GB of virtual capacity for each user (as thin-provisioned volumes). However, in the back-end storage, the real capacity per user only amounts to 6 GB. If 100 users is assumed, the virtual capacity is 1 TB, but only 600 GB of real capacity is available in the storage subsystem. This approach is a valid only because the administrator knows from previous observations that not all users request the whole amount of physical capacity at the same time. Some request only 4 GB or less, and some might request the whole 10 GB. However, the assumption remains that on average they all request no more than 6 GB of real capacity.

It remains the responsibility of the storage administrator to monitor the allocation of real capacity to avoid any out-of-storage condition.

In data centers, a shared storage infrastructure provides storage for many different applications that are running on different servers. The initial storage capacity for those servers is often requested during their deployment phase. The requested capacity is most likely a combination of the initial required storage and an estimation of the growth over the estimated application lifetime.

Looking across all applications in a data center with focus on their storage capacity demand over time, experience shows that some applications grow quickly. However, other applications have almost no change in storage need, or do not even fully use their assigned initial capacity.

From the overall storage management perspective, this circumstance offers the opportunity to improve the use of the shared storage capacity. A policy can be established where assigned but unused capacity can be reassigned to applications that exhibit a more dynamic storage demand. To allow redistribution of capacity in the storage subsystem, the storage allocation must be separated from the storage configuration process. Thin provisioning offers this capability.

The DS8880 supports only Extent Space Efficient (ESE) volumes. The DS8880 treats every volume as an ESE volume regarding the metadata structure whether the volume is full-provisioned or thin-provisioned.

The user chooses between the following FB extent sizes for each extent pool:

For thin provisioning for CKD devices, the following extent sizes are available:

ESE volumes are thin-provisioned volumes that are designated for standard host access.

Thin-provisioned volumes are created with the DS CLI by specifying the space allocation method parameter -sam ese for the mkfbvol or mkckdvol commands or by using the DS GUI by selecting the Advanced Settings icon in the volume creation window and selecting the Extent Space Efficient option for the Allocation Settings, as shown in Figure 1-3.

The allocation of real capacity for ESE volumes occurs with writes to an unallocated address. Before the write is destaged from cache to disk, a new extent is dynamically allocated and assigned to the volume.

The extent must be formatted after the extent is allocated. The extent initialization is done by using the Quick Init process that was introduced with the DS8000 microcode Release 4.3.

The storage administrator has the choice to create extent pools of different extent sizes. The supported extent sizes for FB volumes are 1 GiB or 16 MiB. For CKD volumes, they are one 3390 Mod1 (which is 1113 cylinders) or extents of 21 cylinders. An extent pool cannot have a mix of different extent sizes.

For thin-provisioned volumes, small extents provide a much better capacity utilization. However, small extents cause some more management overhead for the storage system because more extent allocations occur compared to large extents. At allocation time, the write performance might be slightly affected.

The response time for the first write operation might increase, but not significantly. After the extent is allocated and formatted, the ESE volume performs the same as standard logical volumes.