3par thin provisioning - eliminating allocated but … thin provisioning eliminating allocated but...

3PAR Thin ProvisioningEliminating Allocated but Unused Storage and Accelerating ROI

WHITE PAPER2008

3PAR Thin Provisioning Eliminating Allocated but Unused Storage and Accelerating ROI

2

Table of Contents

Introduction 3

Problem: Unused Allocated Capacity 3

An Understood Problem? 3

Sizing the Problem 4

Behind the Problem: Root Causes 5

Solution: 3PAR Thin Provisioning 6

Summary Business Benefits 9

Reduced Capital Expenditures 9

Lower Operating Expenses 9

Accelerated Return on Investment 9

3PAR Thin Provisioning Architecture 10

3PAR Traditional Virtual Volume Management 10

3PAR Thin Provisioning Volume Management 11

Thin Provisioned Virtual Volumes (TPVVs) 12

Common Provisioning Groups (CPGs) 12

How 3PAR Thin Provisioning Works 13

3PAR Thin Provisioning Alerts 15

Summary 16

About 3PAR 17


3

IntroductIon

Balancing new project demands and limited IT resources is the challenging, often thankless, job

of IT management. IT managers must constantly evaluate the efficiency of tools and processes

used to serve and manage corporate data. Of the many proposals to improve efficiency, few are

actually implemented. Of those, fewer still achieve demonstrable success. 3PAR Thin Provisioning

is a simple proposition that succeeds by saving organizations millions of dollars while letting new

projects be initiated on demand.

This white paper discusses the problem of allocated, but unused, storage —the storage that has

already been assigned to applications and file systems, but has not actually be written to. It also

considers the high tax organizations pay to provision storage in typical environments. 3PAR Thin

Provisioning is then explained and proposed as an alternative to both of these issues. The result

is a dramatic reduction in capital and operating expense, and much greater cost control relative

to project outcome. Return on application investment is also accelerated because IT can quickly

deploy new applications without the delays associated with traditional provisioning. In addition to

the business benefits of this alternative, attention is given to how 3PAR Thin Provisioning works

within the context of the 3PAR InForm Operating System.

Problem: unused AllocAted cAPAcIty

An understood Problem?

Discussions about poor capacity utilization usually focus on the inherent limitations of direct-

attached storage. Storage that is attached directly to a given host is not accessible by other host

servers. This creates pockets of inaccessible and therefore unutilized capacity across organizations.

Networked storage remedies this by creating shared access to storage assets, thus increasing capacity

utilization. But, what about the capacity that has already been allocated to host applications?

U N U S E D A L L O C AT E D C A PA C I T Y

Source: Glasshouse Technologies. From Storage Magazine article ”Integration” by Stephen Foskett, April 2003

gbs hP-uX AIX solaris Windows0

100

200

300

400

500 __________________________________________________

__________________________________________________

__________________________________________________

__________________________________________________

__________________________________________________

__________________________________________________

__________________________________________________

__________________________________________________

__________________________________________________

__________________________________________________

500

450

400

350

300

250

200

150

100

50

0

unallocated to filesystemunused filesystemused filesystem

Fig. 01


4

How well is allocated storage used? That is, what percentage of the storage made available to

applications has actually been written to? For some organizations this is a troubling question.

They know, or worse yet, only suspect there is a problem. For others, the question has not yet

been considered.

Recognized or not, the problem for most companies is alarming. Enterprises report, on average,

that only 25%1 of allocated capacity is actually used by applications. Needless to say, this

is a extraordinary waste of capital resources. Consider a $1M investment in storage capacity.

Expected returns are generated on $250,000 of this investment. But the remaining $750,000 is

lost. Rapid technology cycles and negligible residual values mean little hope of reclaiming this

value. This represents a tremendous disparity between incurred application cost and realized value.

Unfortunately, this problem cannot be addressed simply by networking storage.

sizing the Problem

For companies, the magnitude of this problem stretches beyond poor returns on corporate

assets. Operating expenses are wasted on the futile housing, powering, and cooling of countless

disk drives that are effectively unused. Human resources, whether internal or contracted via

service agreements, are consumed in the maintenance of these exaggerated infrastructures.

Finally, storage related software license fees, which are commonly based on raw capacities,

1 Storage Magazine, April 2003. In a survey of 750 host systems at over a dozen small and large enterprises, Glasshouse Technologies found that only 25% of allocated capacity is used. “The average site assigned just 75% of their storage to hosts, left 36% of that unavailable to applications and only used 39% of what was usable. So a typical host might have 500GB of external storage, 375GB in volume groups, 240GB in file systems, and just 93GB used,” noted Glasshouse Technologies.

G L O B A L C O S T O F W A S T E D C A PA C I T Y

2,700 Megawatts in power and cooling*At a cost of $2 billion/year

Equivalent to energy production of 9 average US power plants (coal)

Requires 12 million tons of coal to produce, or

Requires 40 million barrels of oil —2 days of total US oil consumption

Creates 34 billion lbs. of carbon dioxide per year, based on average sources of US electricity (coal, oil, nuclear, hydro, etc.)**

COST TO END USERS

RESOURCE CONSUMPTION

COST TO ENVIRONMENT

33

3

33

3

* –65 watts/drive ** –US EPA All other estimates based on US DOE figures.

Fig. 02


5

exacerbate the problem. For example, a number of Storage Resource Management (SRM) software

titles are licensed this way, as are most software titles from storage array vendors such as EMC,

Hitachi Data Systems, and Hewlett-Packard.

For the global environment, there is also measurable cost. Consider the number of disk drives sold

within multi-disk platforms, such as JBOD enclosures, arrays, and servers with multiple embedded

disk drives. (Only these platforms offer, in practice, the alternative of using fewer disk drives.)

Assuming drives are deployed no longer that 5 years, historical drive shipments and projections

from the Gartner Group2 put this installed base at roughly 74 million disk drives. Using the

Glasshouse Technology figures from above, this translates into roughly 42 million disk drives of

unused allocated capacity in multi-drive platforms. See the table below for the estimated effects of

this “waste.”

behind the Problem: root causes

The “allocated but unused” problem occurs for a number of reasons, both organizational and

technical. These include:

Over-Requests for Capacity: • When sponsoring departments or application administrators

request capacity they account for current needs, as well as anticipated growth. To the

extent expected growth is uncertain, capacity estimates are increased. Wishing to assure

good quality of service for a new application, users may request enough capacity to avoid

any downtime that could result from depleting or augmenting an insufficient amount

of capacity.

Applications that Are Less Successful than Planned:• Sometimes applications are simply not

utilized as originally anticipated, and so little growth actually occurs. Meanwhile significant

storage has already been provisioned and allocated.

Replication of Unwritten Data:• For many applications, additional copies of data volumes

are kept on-line. These may serve to protect data and enable recoveries after corruptions or

disasters. Or these copies may enable more flexible data sharing (e.g., testing, development,

and decision support). Since most data volume copy technologies deployed today do not

distinguish between written versus unwritten portions of the volume, they physically

replicate the base volume in its entirety. Thus any “waste” in a base volume is perpetuated

throughout all of its copies.

2 Sum of disk drives from 1999-2002 from Gartner 2001 Disk Storage Systems WW (Host Attached Internal RAID, Host Attached External RAID, External RAID Controller-based, & NAS).


6

Over-Provisioning to Avoid Future Allocation Complexity and Risk:• Since storage

provisioning is complex and painful, follow-on allocations of capacity can be postponed

or avoided by generous provisioning initially. Typically, provisioning is a manual process

requiring careful planning and coordination by IT management, storage administrators,

system administrators, and application administrators. The process can be characterized by

delay and downtime since numerous people and steps are involved at different layers of the

infrastructure—storage allocation from an identified storage pool; planning, configuring

and export of volumes from storage array to host; switch fabric configuration and zoning

(if necessary), application LUN addition/extension, file system configuration, application

configuration, and backup system configuration.

Existing Technologies are “Dedicate-on-Allocation”:• Traditional storage uses Dedicate-on-

Allocation technology. Customers have to purchase all the storage they want to allocate

up front. The “capacity-on-demand” solutions offered by some vendors do not alleviate

this condition since, again, physical capacity must be installed and configured up front—

only then is it available to be allocated by the customer at some time in the future. These

programs effectively pre-position drive inventory at customer sites while charging customers

a price premium for this “service.” Such programs do not address the utilization efficiency

allocated capacity.

In summary, a number of reasons cause allocated storage capacities to far exceed true demand

for written data. Such over-procurement of capacity is made worse in light of falling drive prices.

Organizations that have allocated 300% more than their current need are not effectively leveraging

the 25% to 35% annual decrease in disk drive prices.

solutIon: 3PAr thIn ProvIsIonIng

3PAR Thin Provisioning offers a simple solution to the problem of unused allocated capacity. Thin

Provisioning allows IT departments to safely allocate to an application as much logical capacity as

conceivably needed over its lifetime. Meanwhile, physical capacity is drawn from a common pool

of purchased storage on an as-needed basis. That is, only when application writes occur is physical

capacity drawn from the pool. 3PAR Thin Provisioning is “Dedicate-on-Write,” as opposed to

“Dedicate –on-Allocation.” Physical capacity can be added to the buffer pool non-disruptively at

any time.

R E P L I C AT I O N O F U N W R I T T E N D ATA

(at $0.03 per MB)24TB $720,000

3 T B3 T B 3 T B3 T B 3 T B3 T B 3 T B3 T B 3 T B3 T B 3 T B3 T B

Fig. 03


7

By breaking the traditional link between allocated and purchased capacity, Thin Provisioning allows

application costs to grow in direct accordance with application use and growth. Users can continue

to request, and receive, desired amounts of capacity. But purchasing is now determined by actual

utilization, so costs are less dependent on the ultimate “success” of the application. For IT there is

an important additional benefit: the pain and complexity of provisioning is dramatically reduced.

By allocating “generous” amounts of logical capacity to applications upfront, follow-on provisioning

tasks and workflow are eliminated. Administrators can “allocate once,” safely and economically.

(Mechanisms for monitoring and controlling planned and unplanned growth of data will be

discussed later.)

Fig. 04

Volume

WrittenData

Volume

WrittenData

Volume

WrittenData

Traditional (Fat) Provisioning—Dedicate on Allocation—

T H I N P R O V I S I O N I N G

3PAR Thin Provisioning—Dedicate on Write—

Purchased Physical Capacity

Volume

WrittenData

Volume

WrittenData

Volume

WrittenData

Purchased Physical Capacity

COMMONBUFFER

POOL

TraditionalEffort Required

STEP____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

____________________________________________________________________________________________________

1

2

3

4

5

6

7

8

9

10

11

12

Find an application that’s running out of space or performance

Determine how to add storage (extend a LUN, make new LUN)

Determine how much storage to add

Allocate storage from pool

Set protection (LUN masks) of storage server so app can see it

Set switch zoning if necessary so app can see storage server

Add new storage to app LUN or form new app LUN

Configure O/S file system to handle bigger/new LUN

Configure application to utilize bigger/new LUN

Configure Backup system to back up bigger/new LUN

Replenish pool, if necessary (buy disks, build new RAIDsets)

Traditional(fat)

Provisioning

3PAR Thin

ProvisioningDESCRIPTION

Determine where in pool to obtain additional storage from (taking performance and availability issues into account)

R E D U C E D W O R K L O A D : F O L L O W- O N P R O V I S I O N I N G

Dramatically Simplified Effort

No Effort Required

Fig. 05


8

Leveraging 3PAR’s 3-layer virtualization capabilities, the 3PAR InServ™ Storage Server presents

to hosts storage volumes (LUNs) of any size and service level. Meanwhile, physical capacity is

intelligently dedicated only as the application writes data.

This intelligence is shared across the InServ platform. Therefore, all data copies throughout the

system can also be “Thin Provisioning aware.” For example, 3PAR Full Copy, a software facility

for making full physical copies, will only consume the same physical capacity as the underlying

Thin Provisioned volume. With 3PAR Virtual Copy, a copy-on-write snapshot technology, even

more space is saved for local copies. With Virtual Copy, only the changes to the base volume or

to the copy (subsequent to the creation of the Virtual Copy) consume physical capacity. Typically

this is only a fraction of the capacity of the base volume. Lastly, with 3PAR Remote Copy, copies

mirrored to other InServ Storage Servers (typically at remote sites) are just as space-efficient as the

base thin provisioned volumes.

Note that for both Full Copies and Remote Copies, full physical capacity can be optionally dedicated.

This is commensurate with the allocated logical capacity of the base thin provisioned volume.

D E D I C AT E - O N - W R I T E

600 GB 600 GB 200 GB 200 GB

3PARALLOCATES

APPLICATIONSEES

APPLICATIONWRITES

3PARDEDICATES

Fig. 06

R E P L I C AT I O N O F W R I T T E N D ATA O N LY

THIN PROVISIONEDBASE VOLUME

(at $0.03 per MB)(at $0.03 per MB)

3PAR VITUAL COPY 3PAR REMOTE COPY

. 3 T B. 3 T B . 3 T B. 3 T B

$138,000

Fig. 07


9

In summary, this platform-wide efficiency represents tremendous savings and resolves the technical

issue of replicated unwritten data, a key cause of the “allocated-but-unused” problem. Organizations

may wish to leverage this efficiency by using local and remote copies in connection with more

applications. For example, disaster recovery may now be feasible for applications that could not

be economically protected before.

summAry busIness benefIts

reduced capital expenditures

3PAR Thin Provisioning reduces capital expenditures by eliminating disk expenditures immediately

and by postponing them indefinitely (forever in the case of many applications). For applications

where local or remote on-line copies are used, capital savings are a multiple of the number of

copies. For financial and IT managers, this assures much greater control of capital expenditures and

links them directly to the return from a given application. As physical capacity is purchased and

added over time, users also leverage falling disk drive prices more effectively. Finally, with 3PAR

Thin Provisioning, customers can reduce license fees paid for many storage software products, like

SRM tools.

lower operating expenses

3PAR Thin Provisioning dramatically lowers operating expenses by conserving electricity and

floor space, otherwise expended for powering, cooling, and housing unnecessary disk drives. By

“allocating once,” the IT organization is relieved of repeatedly performing onerous and error-prone

tasks related to follow-on storage planning and provisioning. This results in workload and workflow

reduction for administrators across the IT organization. Note that even the initial provisioning of

application-tailored volumes with the 3PAR platform is a mere matter of seconds. Thus, storage

can be intelligently provisioned for an application, for its lifetime, in a few brief seconds. Lastly,

application downtime traditionally required to perform follow-on allocations, reconfigurations,

and rebooting is eliminated.

Accelerated return on Investment

3PAR Thin Provisioning addresses a final business concern—return on IT investment. As discussed

earlier, Thin Provisioning enables a greater number of projects for less cost. Within a given budget,

Thin Provisioning allows more applications to be deployed, with each one costing significantly less

than before. Just as importantly, applications can be deployed faster. No longer is IT required to

wait until next quarter’s or next year’s budget allocation in order to deploy additional applications

that will generate return for their corporation. Nor are they required to wait until needed storage is

planned, sized, negotiated, procured, and installed before storage can be allocated. By maintaining

a small buffer of physical capacity, IT can quickly and easily deploy new applications as and when

they are needed. In either case, delays are eliminated and ROI is accelerated.


10

Capacity is always available to start new projects, and administrator productivity has no dependency

on storage purchase, planning, or installation. In the end, many more projects with ROI potential

are initiated, and IT’s contribution to the overall business is increased.

3PAr thIn ProvIsIonIng ArchItecture

To understand how 3PAR Thin Provisioning works, it is useful to first understand 3PAR’s approach

to virtualization.

3PAr traditional virtual volume management

The 3PAR InForm Operating System employs a 3-level mapping methodology similar to the

virtual memory architectures of server operating systems. The first level of mapping virtualizes

physical disk drives of any size into a pool of uniform-sized “chunklets” (256 megabytes (MB)

each) and manages the redundant pathing to each chunklet and disk drive. The fine-grained nature

of these chunklets eliminates underutilization of storage assets. Volumes can be sized precisely

and not according to large arbitrary increments. The chunklets’ fine-grained nature also enhances

performance for all applications, regardless of their capacity requirements, by allowing distribution

of chunklets across scores, or even hundreds of disks. Complete system access to every chunklet

means no pockets of inaccessible storage.

The second level of mapping associates chunklets with Logical Disks (LDs). This association allows

logical devices to be created with template properties based upon RAID characteristics and the

location of chunklets across the system. LDs can be tailored to meet a variety of cost, capacity,

performance, and availability characteristics, depending upon the service levels required. In addition,

the first and second level mappings taken together serve to parallelize work massively across disks

EXTRAPROJECT

WrittenData

PROJECT

B

WrittenData

PROJECT

B

WrittenData

EXTRAPROJECT

WrittenData

PROJECT

B

WrittenData

PROJECT

A

WrittenData

PROJECT

A

WrittenData

Traditional (Fat) Provisioning

E N A B L E N E W P R O J E C T S A N D R E D U C E P R O J E C T R I S K

3PAR Thin Provisioning

This Quarter(start projects,

purchase storage)

Next Quarter(evaluate projects)

10 TBs 5 TBs

big cost, small return small cost, big/accelerated return

PROVENFAILE

D

FAILED

PROJECT

A

WrittenData

PROJECT

A

WrittenData

PROJECT

B

WrittenData

COMMONBUFFER

POOL

PROVENPROVEN

Fig. 08


11

and their Fibre Channel connections. The third level of mapping associates traditional Virtual

Volumes (VVs) with multiple LDs. VVs are virtual capacity representations that are ultimately

exported to hosts and applications.

With traditional Virtual Volume management, all of these mappings are set at VV creation. Though

changes may be made subsequent to creation (for example, to optimize the chunklet location),

a full mapping exists at all times for all logical capacity of a base VV. Underlying chunklets and

LDs (or portion of LDs) are thus “pre-dedicated” to a given VV, regardless of how much has been

written to that VV.

(Please note that users are not required to manage these layers or associations. The InForm

Operating System handles this automatically. Application-tailored Virtual Volumes are typically

created and exported to hosts in a just a few seconds.)

3PAr thin Provisioning volume management

3PAR Thin Provisioning Volume Management removes the pre-dedication of physical capacity. It

builds on the 3PAR traditional volume management, but adds an intermediate function, known

as a Common Provisioning Group. The CPG function sits between the VV layer and the LD layer.

Unlike traditional 3PAR virtual volume management where VVs are “backed” 100% by LDs, a CPG

effectively creates LDs from free chunklets on an as-needed basis. A CPG then maintains mappings

from its “owned” LDs to VVs that have been associated with it. A base VV that depends on a

V I R T U A L V O L U M E M A N A G E M E N T

logical disks are

pre-dedicated to support the entire logical

capacity of virtual volumes

oltP dW

host serverssee luns with tailored

performance, availability, and capacity

vIrtuAl volumes of any size (1gb to 2tb each)

logIcAl dIsKsintelligent combinations of chunklets for tailored cost, performance, availability

PhysIcAl dIsKsbroken into chunklets

(256mb each)

Fig. 09


12

CPG is known as a Thin Provisioned Virtual Volume (TPVV). Note that just as with traditional

VV management, there is still massive parallelism of work over system resources, with chunklets

distributed across scores, or even hundreds of disks.

thin Provisioned virtual volumes (tPvvs)

Virtual capacity is represented to host servers and applications using TPVVs. Upon TPVV creation,

a fraction of its exported virtual capacity is mapped to LD regions in the CPG. When application

writes are made to the TPVV, the InForm OS allocates space from pre-mapped LD regions in fine-

grained increments to accommodate the write. Over time, as available space in the LD regions

mapped to the TPVV runs low, additional capacity is automatically allocated by mapping new

regions from LDs in the CPG.

TPVVs behave like traditional VVs—the differences are transparent to the host. TPVVs can serve

as base volumes for Virtual Copies, Full Copies, or Remote Copies. As with traditional VVs,

application-tailored TPVVs are created and exported to hosts in a just a few seconds.

common Provisioning groups (cPgs)

As discussed, CPGs provide a buffer pool of LDs with an associated mechanism to automatically

dedicate LD capacity to mapped TPVVs as needed. Key attributes of CPGs include:

T H I N P R O V I S I O N E D V I R T U A L V O L U M E M A N A G E M E N T

host serverssee luns with tailored

performance, availability, and capacity

vIrtuAl volumes of any size (1gb to 2tb each)

logIcAl dIsKsintelligent combinations of chunklets for tailored cost, performance, availability

PhysIcAl dIsKsbroken into chunklets (256mb each)

logical disks are created

and dedicated as

needed to support the “written to” portion of

virtual volumes

oltP dW

common ProvIsIonIng grouPs manage the creation and dedication of logical disks

Fig. 10


13

Fine-Grained Capacity Pooling:• CPGs enable fine-grained, shared access to pooled logical

capacity. Instead of pre-dedicating LDs, however small or large, to traditional VVs, a CPG

allows multiple TPVVs to share a buffer pool of LDs. When a TPVV requires more dedicated

capacity, a CPG automatically assigns logical capacity to the TPVV by mapping new regions

from its LD pool. So, while a CPG pool contains dedicated LDs, pooled resources remain

undedicated to TPVVs until needed.

Auto Growth:• By default, a CPG is configured to create new LDs when the amount of

available LD space falls below a configured threshold. The initial buffer pool of LDs starts

off at a fraction of the exported virtual capacity of mapped TPVVs and auto-grows over

time as required by application writes. Effectively logical capacity growth tracks the growth

in actual used capacity, allowing customers to purchase and install physical capacity as

needed over time. LDs can also be manually assigned to a CPG.

Moreover, template LD properties (such as RAID characteristics and the chunklet location)

are specified per CPG and are applied uniformly across the LDs in a CPG. To take maximum

advantage of Thin Provisioning, users may wish to group applications by service levels, which

can then be associated with various CPGs. This not only enables users to meet their application

requirements, but also allows more volumes to share a CPG, and thus share a common amount

of like buffer capacity.

how 3PAr thin Provisioning Works

(1) CPG Creation: To take advantage of Thin Provisioning a user first creates a CPG. Template

LD properties such as RAID characteristics and the location of chunklets across the system

are specified based on application requirements. In addition, the growth increment for LDs

is specified in gigabytes (GB). The growth increment defines the size for initial LD creation

as well as for subsequent growth of LDs as available capacity is used by the application.

Alternatively, the user can manually admit LDs into the CPG and “opt out” of automated

logical capacity growth by configuring the growth increment to zero. This may be desirable

for users who wish to pre-allocate a fixed amount of capacity for TPVVs and utilize the

remainder for traditional VVs. Lastly, allocation warning and allocation limit for the CPG

are specified based on application requirements and internal storage allocation policy.

1 ) C P G C R E AT I O N

LD

Common Provisioning Group

Fig. 11


14

(2) TPVV Creation: To export virtual capacity to the host, the user creates a TPVV and exports

it as a VLUN to the host. During creation, the TPVV is associated with a CPG, which pre-

dedicates minimal logical capacity to it—a fraction of its exported virtual capacity.

(3) Capacity Allocation: As applications write to TPVVs, space is mapped in fine-grained

increments from previously mapped LD regions to accommodate the writes. As the TPVV

space runs low, the CPG prepares for more writes by mapping new regions from LDs in the

CPG to the TPVV.

2 ) T P V V C R E AT I O N

LD

TPVVs

OLTP

------------


Fig. 12

3 ) C A PA C I T Y A L L O C AT I O N

LD


TPVVs

OLTP

New writes

Fig. 13


15

(4) Auto-Growth: Once the available logical capacity in the CPG falls below a pre-configured

threshold, the CPG automatically adds LDs in accordance with the specified capacity growth

increment. A CPG continues to auto-grow LDs, as needed, until either its Allocation Limit

is reached or until sufficient physical capacity is not available to satisfy the requirements of

specified LD characteristics.

3PAr thIn ProvIsIonIng Alerts

3PAR Thin Provisioning provides multiple categories of alerts that notify storage administrators

of important events:

Allocation Warnings – Allocation Warnings provide a mechanism for warning storage •

administrators when a specified logical capacity threshold is reached. An allocation warning

can be specified independently for TPVVs and CPGs.

Allocation Limits – Allocation Limits provide a mechanism to prevent “run away” •

applications—applications that are in an abnormal state and continuously write data to

the storage device—from consuming logical capacity beyond the specified logical capacity

threshold. Allocation limits can be specified independently for TPVVs and CPGs. For a

TPVV, once the allocation limit is reached, the logical capacity allocated to the TPVV stops

growing and new application writes fail. Similarly, for a CPG, once the allocation limit is

reached, the automatic creation of new LDs, if configured, is disabled. New applications

writes to TPVVs mapped to the CPG receive a write failure until the limit is raised.

• Used Physical Capacity – As available physical capacity across the 3PAR InServ Storage Server

is utilized by traditional VVs and/or TPVVs, multiple pre-configured alerts are generated that

provide information about used physical capacity as a percent of total system capacity. For

CPGs configured with default LD characteristics, these alerts serve as an advance warning

to the storage administrator to plan for and add necessary physical capacity. In the unlikely

scenario that effective physical capacity becomes used, the 3PAR InServ Storage Server

naturally prevents new writes from occurring until more capacity is added.

4 ) A U T O - G R O W T H


LD

TPVVs

OLTP

New writes

----

------

LD

Fig. 14


16

These alerts combined with various alert delivery mechanisms (3PAR InForm CLI, 3PAR InForm

GUI, SNMPv2 Traps, and email/page from 3PAR Central) enable storage administrators to manage

3PAR Thin Provisioning in the way that suites them.

summAry

3PAR Thin Provisioning represents a new, cost-effective way to purchase and manage storage.

Thin Provisioning solves the allocated-but-unused problem, saving millions of dollars in base and

replicated capacity, as well as related costs for housing, powering, cooling and software licenses.

It provides a simple and powerful means of linking project cost directly with project outcome

while requiring no behavioral changes from storage requestors. At the same, it directly addresses

the distorting effects of provisioning complexity by eliminating follow-on provisioning tasks and

workflow for administrators at multiple levels.

Since Thin Provisioning creates a storage pool that is “Dedicate-on-Write,” capacity, expense is

not measured by number of projects, as with “Dedicated-on-Allocation” technologies, but rather

by cumulative written data. In this way, not only can organizations leverage falling drive prices

more effectively, they can initiate projects on demand, quickly and easily. Without the financial or

provisioning delays associated with traditional provisioning, more promising applications can be

launched, accelerating ROI.

QUARTER

CU

MU

LAT

IVE

RA

W T

Bs

0 1 2 3 4 5 6 7 8 9

70

60

50

40

30

20

10

0

THIN PROVISIONING

TRADITIONAL PROVISIONING

ALLOCATE & PURCHASE

Allocate once, purchase-as-needed

more projects,same budget

$0.06$0.05

$0.04

T H I N P R O V I S I O N I N G : A N E F F I C I E N T PAT T E R N O F C A PA C I T Y A L L O C AT I O N A N D P U R C H A S I N G

Fig. 14


17

About 3PAr

3PAR® (NYSE Arca: PAR) is the leading global provider of utility storage, a category of highly

virtualized, tightly-clustered, and dynamically-tiered storage arrays built for utility computing.

Organizations use utility computing to build cost-effective virtualized IT infrastructures for flexible

workload consolidation. 3PAR Utility Storage gives customers an alternative to traditional arrays

by delivering resilient infrastructure with increased agility at a lower total cost to meet their rapidly

changing business needs. As a pioneer of thin provisioning—a green technology developed to

address storage underutilization and inefficiencies—3PAR offers products designed to minimize

power consumption and promote environmental responsibility. With 3PAR, customers have reduced

the costs of allocated storage capacity, administration, and SAN infrastructure while increasing

adaptability and resiliency. 3PAR Utility Storage is built to meet the demands of open systems

consolidation, integrated data lifecycle management, and performance-intensive applications. For

more information, visit the 3PAR Website at: www.3PAR.com.

© 2008 3PAR Inc. All rights reserved. 3PAR, the 3PAR logo, Serving Information, InServ, InForm, and InSpire are all registered trademarks of 3PAR, Inc. All other trademarks and registered trademarks are the property of their respective owners.

u.s. corPorAte heAdquArters

3PAR Inc.4209 Technology Drive

Fremont, CA 94538

Phone: 510-413-5999

Fax: 510-413-5699

Email: [email protected]

tp-wp-08.3

3par thin provisioning - eliminating allocated but … thin provisioning eliminating allocated but...

Documents