Hitachi Dynamic Provisioning Best Practices Webtech
Hitachi Dynamic Provisioning Best Practices Webtech
Best Practices
with Applications
23 January 2008
Steve Burr
Solution Architect, Global Solution Services
Hitachi Data Systems
2
Hitachi Dynamic Provisioning (HDP)
Dynamic
Provisioning Actual storage capacity
Pools in Dynamic Provisioning
pool is assigned
LDEVs
LDEV LDEV LDEV LDEV LDEV LDEV LDEV LDEV when host writes data
(Pool-VOLs)
to new area of LUN
Disk Drives/Drive Groups
3
Hitachi Dynamic Provisioning
Three Potential Benefits
• Easier management
– Simpler planning (reactive Ä strategic management)
– Avoid or defer tough decisions about LDEV size
– Control, change and optimize: capacity, performance, reliability , cost tier
• Naturally balances performance
– With large pools there are more spindles than static provisioning
– May scale performance by growing pool
• Over provisioning capacity
– Simplify capacity planning
– Reduce need for “urgent change”
– Reduce need for – “disk X on server Y has run out.
We’ll have to re-allocate the whole estate.”
4
Capacity Leveling: Example
An example
• Three Database Applications N N N
V V V
• Initial estimates: 500GB
P
N N N
V V V
• Actual use: 100GB, 200GB, 800GB
?
5
Performance Leveling: Example
Then
Decide to roll out BlackBerrys
New IOPS = 3 IOPS/mailbox
But 2TB is unchanged?
6
Over Provisioning
7
How Dynamic Provisioning will perform with
applications:
Will depend on
• platform factors (particularly file system)
• application factors (particularly storage configuration)
• how it is managed
8
File system factor 1 – Metadata
9
File system metadata
10
File system factor 2 – reclaim policy
Examples…
11
Metadata and reclaim policies
Examples of pool use
600 600 Is this the only good one?
500 500
200 200
100 100
0 0
500 500
200 200
100 100
0 0
13
Controlling space
15
Exchange 2003 and 2007 tests
16
Exchange tests
11400
11200
11000
10800
10600
10400
17
Exchange tests
Don’t
defragment
mdb! Exchange Data Use with Dynamic Provisioning
35000
30000
25000
20000
15000
10000
5000
0
18/05 20/05 22/05 24/05 26/05 28/05 30/05 01/06
18
Exchange tests
20
SQL Server Tests
21
SQL Server Tests
22
SQL Server Tests
420MB
+Initial FS SQL Server DATA (Large Initial Size)
overhead
800
700
600
500
MB
23
SQL Server Tests
1100
1000
900
MB
800
700 Still no
600 deviation
Avg 95MB
500
HDP WIN
24
SQL Server Tests
Remains
SQL Server DATA parallel
3000
2500
2000
MB
1500
1000
500
0
0 2000 4000 6000 8000 10000 12000 14000 16000
Records Added
25
HDP WIN MODEL
SQL Server Tests
Required
steady state.
SQL Server LOG
4500
4000
3500
3000
2500
MB
2000
1500
1000
500
0
0 2000 4000 6000 8000 10000 12000 14000 16000
Records Added
26
SQL Server Best Practice
• Database (.mdf)
– Good, base size on planned initial use
– Increment base on days growth Could be as low as 42MB
• Online logs (.ldf)
– Good, base size on planned initial use
– Increment base on days growth
• Log file backups (.trn)
– Unconstrained, either:
• don’t over provision
• use dynamic partition expansion
• use static provisioning
• None of this is significantly different from normal SQL Server Management
27
Oracle Tests
• Ported SQL Server scripts; added Oracle Physical Schemae
Automatic Storage Management (ASM)
• ASM is both a volume manager and a specialized file system.
Can dynamically add/remove/expand storage objects.
• ASM does not conflict with: Hitachi storage, virtualization or
Hitachi Dynamic Provisioning.
They complement. Some overlap – which gives more options.
• Hitachi/Oracle ASM recommendations for layout
OCFS2
• Oracle Cluster File System – version 2
• Shared file system for RAC
28
Tablespace configuration
CREATE TABLESPACE "VS1“;
DEFAULT: SIZE 100M AUTOEXTEND ON MAXSIZE UNLIMITED
29
ASM: Tablespaces
900
800
700
600
500
MB
400
300
200
100
DG Pool Table
Changed tablespace
to compression on
30
ASM: Tablespaces
Multiple Tables per TableSpace
500
450
400
350
300
MB
250
200
150
100
50
0
DG Multiple
Pool TableSpaces
Table DG per DiskGroup and drop/re-create TableSpaces
500
450
400
350
300
250
200
150
100
50
0
DG Pool Table DG
31
ASM: Archive Redo Logs
3.0
2.5
2.0
GB
1.5
1.0
0.5
0.0
32
Oracle without ASM: factors
DP-Volumes
Pools
33
Oracle Cluster File System – OFCS2
5.0
4.5
4.0
3.5
3.0
GB
2.5
2.0
1.5
1.0
0.5
0.0
34
Oracle guidelines
• External redundancy only
• Create tablespace
– minimize initial allocation
• Create table
– minimize initial allocation
35
Replication products
36
General recommendations
37
Hitachi Dynamic Provisioning Tools
• Raid Manager:
raidvchkdsp –g HDP –v aou
Group PairVol Port# TID LU Seq# LDEV# Used(MB) LU_CAP(MB) U(%) T(%) PID
HDP MDF CL6-B-1 18 35 10044 b906 2814 93750 1 70 9
HDP LDF CL6-B-1 18 36 10044 b907 4032 93750 1 70 9
HDP AUX CL6-B-1 18 37 10044 b908 8442 93750 1 70 9
38
Performance with
Hitachi Dynamic Provisioning
• Generally all good news
• Both modeling and testing seems to show that there is little or no
difference in back-end requirement.
• But can benefit from leveling
• Small reduction in peak front-end performance but is less often a
bottleneck
• Your Hitachi Representative has modeling tools to assist
39
Thank you
• Call to action:
– Hitachi Dynamic Provisioning is easy to understand and use.
– If you have a Universal Storage Platform V or Universal Storage Platform
VM, evaluate it
– Have a go at quantifying the cost savings
• More information:
– “Guidelines for the Use of Hitachi Dynamic Provisioning Software with the
Microsoft® Windows Operating System and Microsoft SQL Server 2005,
Microsoft Exchange 2003 and Microsoft Exchange 2007”
– “Guidelines for the use of Hitachi Dynamic Provisioning Software
with Oracle® Databases and Automatic Storage Management”
– “Oracle Database 10g Automatic Storage Management Best Practices with
Hitachi Replication Software on the Hitachi Universal Storage Platform™
Family of Products”, co-authored by Oracle and Hitachi Data Systems
40
Upcoming WebTech Sessions:
42
Thank You
43