Virtual Provisioning Overview


Symmetrix Virtual Provisioning, also known in the industry as “thin provisioning”, is the ability to present a host and therefore an application, with more storage capacity than is physically allocated to it in the storage array. The physical storage is then allocated to the application “on-demand” as it is needed from a shared pool of storage.


Virtual Provisioning: Benefits


·         Reduce the amount of allocated but unused physical storage

·         Avoid over allocation of physical storage to application

·         Reduces energy consumption and footprint

·         Provision independently of physical storage infrastructure

·         Minimize the challenges of growth and expansion

·         Simplifies data layout

·         Saves costs by simplifying procedures to add new storage

·         Wide striping distributes I/O across spindles

·         Reduces disk contention and enhances performance

·         Maximize return on investment


Virtual Provisioning: Components


·         Thin Device (TDEV)

·         Data Device (DATADEV)

·         Thin Pool


Symmetrix Virtual Provisioning uses a new type of Symmetrix device called a Thin Device. It is called a thin device because no actual data is saved on the device. The thin device is presented to a host like any Symmetrix hyper volume. An application, on the host, can use this thin device just like any symmetrix logical volume and write data to it.


Data does not get written to the thin device. It is written to a collection of symmetrix hyper volumes, called data devices.


The data devices are grouped together into a storage pool called a Thin Pool. A Thin Device must be bound to a Thin Pool before it can be used. This Thin Pool provides the shared storage. The storage capacity in the Thin Pool can be shared among multiple host and applications.


The action of binding a thin device to a thin pool makes the device ready and associates storage with the thin device.



Thin Devices:

·         Consumes no disk space, consists of data structures in cache

·         Mapped and masked to a host like any other device

·         Presents a Not Ready status until bound to a thin pool

·         Can be mapped and masked prior to binding

·         Physical storage is allocated from a thin pool containing data devices

·         Initial allocation of 12 tracks (768 KB) when bound

·         Additional allocation on write or when pre-allocated

·         TDEVS can be replicated (TimeFinder/Snap, TimeFinder/Clone, Open Replicator, and SRDF)


Data Devices:

·         Non-addressable Symmetrix device

·         Provides physical storage for use by a thin device

·         Configured to Thin pool to which the thin devices are associated or “bound”

·         Data devices should be protected

·         RAID-1, RAID-5 or RAID-6 data devices support local and remote replication

·         No support for dynamic sparing


Thin Pool:

·         Data devices assigned to Thin pools

·         Thin pools are user configurable

·         Support tiered storage requirements

·         Work load isolation

·         Data devices dynamically added to or subtracted from pool


Thin pool requirements:

·         Zero or more data devices

·         Need at least one to bind a TDEV

·         Larger pools provide greater efficiency

·         Same protection type (required)

·         Same size (recommendation)


Binding Thin Devices:

·         Unbound Thin Devices are not ready for access

·         Binding makes thin devices accessible and storage capacity useable

·         One device can be bound to one pool only

·         Many thin devices can share a pool


Disabling and Unbinding Thin and Data Devices:

·         Thin Devices can be unbound from pool

·         Must be NR or unmapped before unbinding

·         All data on device is lost

·         Allocation extents on data devices are freed up

·         Data devices may be disabled and removed from pool

·         usually after all thin devices using the pool have been unbound


·         Non-disruptive Removal of Data Devices from Pool

·         Device must be disabled

·         Disabling causes device to drain

·         Used Tracks copied to other data devices


Host Writes to Thin Devices:

·         The initial bind of a thin device to a pool causes 1 thin device extent to be allocated per thin device

·         When a write is performed, if there is no free space in a previously allocated extent, a new thin device extent is allocated from the pool

·         A round-robin mechanism is used to balance the allocation of DATA device extents across all available DATA devices in the pool 

·         A 4 member thin meta would cause 4 extents to be allocated


Host Reads From Thin Device:

·         Thin devices are cache devices and contain only pointers to allocated blocks on DATA devices

·         A read from a thin device, retrieves data from the data device

·         Read to unallocated blocks

·         returns zeros

·         does not trigger storage allocation



·         Bound TDEV capacity is greater than available capacity in the thin pool

·         Considered normal

·         Addresses inefficiency of over
allocation but under utilized storage

·         Over-subscription does create risk

·         If the pool becomes full, writes to the TDEVs fails and an IO error is returned

·         Storage administrator must monitor pool  to prevent “pool full” condition

·         Data devices can be dynamically added to the thin pool

·         Best practice is to add multiple devices to the pool to prevent bottlenecks


VP Friendly Environments:

·         Applications with tolerance for performance variability are suitable for VP such as:

·         Document and Media Repositories

·         Test Development and QA

·         Databases that use “auto-extend” capabilities during page formatting or table creation

·         Applications with predictable and controlled growth

·         Flash drives

·         Compared to rotating drives, flash drive performance does not degrade as disks fill up


VP Hostile Environments:

·         Any application that touches storage capacity without using it causes unused space to become fully allocated, such as:

·         File systems (like NTFS) that append data to file system instead of reusing free space

·         Some utilities that copy “raw” data such as “dd” in Unix

·         Administrative operations such as bad block detection or file system checks that cause dense write patterns on all reported storage


Configuring Thin Pools:

·         Different pools for different classes of storage

·         Different pools for different application families

·         All data devices should reside on drives with the same rotational speed

·         All data devices should be spread evenly across as many DAs and drives as possible

·         Data devices should be the same size, if possible

·         Using different sizes could result in uneven data distribution


Pool Expansion Requirements:

·         Managing pool expansion is critical to performance

·         Start with a large pool

·         Expand by same number of disks as original pool

·         Must have same protection as devices in target pool

·         Must have same emulation as devices in target pool


Pool Expansion Recommendations:

·         Should reside on drives with same RPM

·         Should use equal amount of space from underlying drives

·         Should use equal size data drives

·         Spread devices across DA and physical drives

·         To expand effectively:

·         Enable new TDATs on all existing pool drives

·         Will increase capacity with same performance

·         Add a number of drives equal to original pool size

·         Will increase both capacity and performance

·         DO NOT add just a few TDATs to a large pool

·         Pre-allocation of Pool Space

·         Reasons for Space Pre-allocation


Performance Considerations:

·         Extent allocation is striped across all enabled data devices in pool

·         With regular Symmetrix volumes, wide striping can be achieved using striped meta devices

·         Meta member devices striped across physical disks

·         Thin devices are widely striped automatically

·         Makes it easier to avoid hotspots

·         Potential performance improvement for some workloads

·         Potentially different applications could share data devices

·         Pool-based view of storage layout

·         Thin pools should contain storage of a particular class with a defined business purpose

·         Planning consists largely of deciding what class of storage is required and which business group’s resources should be used

·         Storage is viewed at a higher level when planning new devices

·         Think pool, not hyper!


Meta Devices Considerations:

·         Meta devices are normally created for the following reasons:

·         Increase the size of a volume that is presented to a host

·         Maximum Symmetrix device size limit of 262668 cylinders (240 GB)

·         Increase performance (striped metavolumes)

·         Spread workload over more spindles

·         With TDEVs there is no need create Meta devices to spread workload

·         Thin devices already are wide striped across members of the Thin pool

·         The Symmetrix limit on device size still applies to TDEVs, therefore meta devices are appropriate when the host needs to see larger devices

·         Best Practice is to configure concatenated

·         Advantages:

·         Concatenated thin meta devices can be expanded while preserving data


Monitoring Thin Pools:

·         Recommended capacity utilization per pool between 60 and 80%

·         ≈ 2x on “thick” devices

·         Pools should be configured to absorb data from occasional “runaway” applications

·         Monitoring can be done with

·         Symmetrix Management Console (SMC)

·         Solutions Enabler symcfg monitor

·         Best to monitor with event daemon storeventd


Pool Full Condition:

·         Avoid pool full at all costs by monitoring and taking timely action

·         When pool fills up

·         Next write to thin device will fail

·         Data on thin device can still be read

·         Different Operating Systems react differently when pool fills up

·         Details in Host Connectivity Guides on Powerlink


Thin Device Local Replication:

·         Only Thin to Thin replication is supported

·         Support available for all RAID types (1, 5 and 6)

·         TimeFinder/Snap

·         Performed with Thin Devices sources and VDEV targets

·         TimeFinder/Clone

·         Performed with Thin Device STDs and Thin Device targets

·         No support for Thin BCVs hence TF/Mirror not supported


Thin Device Remote Replication:

·         Support available for all RAID types (1, 5 and 6)

·         SRDF (Sync, Async, Adaptive Copy) – thin to thin only

·         Create Thin Devices

·         Assign the Dynamic RDF attribute to the devices

·         Create Dynamic RDF pairs between thin devices

·         Open Replicator

·         Thin devices can act as control or remote device

·         When acting as source, zeroes sent from unallocated space

·         When acting as target, storage space is fully allocated in accordance with size of source