You are on page 1of 43

Hitachi Dynamic Provisioning

Best Practices
with Applications

23 January 2008

Steve Burr
Solution Architect, Global Solution Services
Hitachi Data Systems

© 2007 Hitachi Data Systems


Presentation Goal

• Discuss best ways of using Hitachi Dynamic Provisioning


software with an emphasis on real applications
– Microsoft Exchange 2003, Microsoft Exchange 2007
– SQL Server 2005
– Oracle 10g, Oracle 11g RAC
• Effective use of over provisioning

2
Hitachi Dynamic Provisioning (HDP)

Host Servers only see Virtual Volumes


Write Data Hitachi Dynamic
Provisioning
Volume shows
Dynamic “Virtual Volume”
Provisioning which doesn’t
Virtual have actual
Volumes storage capacity
(DP-VOLs)

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

Thin provisioning plus Hitachi Virtualization, Tiered Storage, Volume Migration

• 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

1500GB Used 1500GB Free

N N N
V V V
• Actual use: 100GB, 200GB, 800GB
?

2000GB Used 1100GB Used


400GB Free

5
Performance Leveling: Example

Example Small Large


Microsoft Exchange 2007 design: database database
5,000 Mailboxes
400 MB/mailbox (2TB) Low I/O Easy Easy
Workload = 1 IOPS/mailbox
2 Servers
Ä High I/O Problem l Good but
o
Design = 8*RAID-10(2+2) AG area Po needs
design
But
Find that some groups give hotspots so
redesign

Then
Decide to roll out BlackBerrys
New IOPS = 3 IOPS/mailbox
But 2TB is unchanged?

6
Over Provisioning

Allocating more storage space to users than they’ll initially need

No over provisioning (rightsizing)


• No growth benefit but performance and management benefits still apply
Mild over provisioning
• Giving headroom for expansion
Aggressive over-provisioning
• Greatest benefits
• More than you’d want to buy, “Every LUN is 2TB”
• Needs care and safeguards
Aggressive but risk averse, over provisioning
• Over provision aggressively but
• Combine storage, application and OS techniques to remove risk
• Great benefits with safeguards
• Particularly good for early deployments, uncontrolled environments and test
environments

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

• Metadata: management information


• Includes: times, names, directories, pointers to data, maps, label
– inodes, MFT, FAT
– Where is it: start, end, multiplexed, how much touched?
– When created
• Space is not wasted, just prematurely allocated
• Still have management benefits and performance benefits

Metadata Rounded to page size

9
File system metadata

HP-UX JFS (VxFs) Top only

HFS Write by 10MB


Windows 2003 NTFS Top only

Linux OCFS2 Top only


XFS Write by 2GB (2%) With Max AU
Ext2, Ext3 Write every 128MB (30%) At 4K page

Solaris UFS Write by 52MB


VxFS Top only
ZFS Under examination
AIX JFS Write every 64MB (65%) With Max AU
JFS2 Top only
VxFS Top only

10
File system factor 2 – reclaim policy

• If it starts efficient, what happens when it’s used?


• May depend on how you use it.
• Where does “next free block” come from?
• Free space management:
– Table, bitmap or linked list of blocks
– One or multiple lists, multiple levels

MRU – most recently used

LRU – least recently used

Examples…

11
Metadata and reclaim policies
Examples of pool use
600 600 Is this the only good one?
500 500

400 pre-allocate 400 MRU reclaim


UFS ASM
300 300

200 200

100 100

0 0

Used Pre-allocated Used MRU


Pool Used versus “Space Used”
600 600

500 500

LRU reclaim “Leaky”


400 400
NTFS OCFS2
300 300

200 200

100 100

0 0

LRU Used Used Allocated


12
Is reclaim always an issue?
• No – many storage requirements are quite static
• Needs to be addressed:
if application creates and recreates files
and file system doesn’t reclaim well
• Workarounds:
– Don’t over provision
– Use static provisioning
– Administration methods…

13
Controlling space

Dynamic Partition Expansion:


1.Create and map over-provisioned volume
2.But don’t allocate all to partition
3.When top of partition is reached
OS is forced to reclaim
4.If total space gets low
5.Use OS to expand partition
6.Can be scripted
7.Generally easier than hardware add, lun resize etc.
8.Recommended if you51
echo select disk have no detailed guidelines
> diskpart.scr
echo
9.Helps select
with partition
metadata and 1reclaim
>> diskpart.scr
issues
echo extend size=600 >> diskpart.scr
echo detail disk >> diskpart.scr
diskpart /s diskpart.scr

ALTER DISKGROUP VS1DG RESIZE DISK DISKVS1 SIZE 738M;


14
Application testing
• Construct lab with: application, test tools and
Hitachi Dynamic Provisioning software
• Test: volume manager, file system then application
• Monitor “allocated pool” versus “used space”
whilst performing typical actions:
– Initial Creation and Configuration
– Addition, Append, Modify, Deletion
– Force Fragmentation
– Backup and manage
• Analyze and produce guidelines

15
Exchange 2003 and 2007 tests

• Microsoft loadsim and loadgen


• Realistic, unlike JetStress
• 10 days: 4.8m transactions, 1.3m messages read,
1.25m delivered, 350K deleted, appointments,
attachments, dlists
• Set zero e-mail retention policy

16
Exchange tests

Exchange Data Use with Dynamic Provisioning

11400

11200

11000

10800

10600

10400

10200 After days of


9:36 14:24 19:12 0:00 4:48 9:36 14:24
testing. 19:12
Gap normal.
daily 0200 mdb No increase
space reclaim over time.

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

Exchange Log Use with Dynamic Provisioning


Partition limit
90,000
80,000
70,000 Defragmentation
60,000 did not help
50,000
40,000
30,000
20,000
10,000
0
18/05 20/05 22/05 24/05 26/05 28/05 30/05 01/06

Online Backup with truncate using


19
Hitachi Protection Manager with VSS
Exchange best practice

• Exchange 2003 and 2007 similar


• Good for Mail Stores (.mdb)
– Mailbox management safe

• Storage Group Log files (.log)


– Unlimited on NTFS, so either:
• don’t over provision,
• use dynamic partition expansion
• or use static provisioning
• Do not defragment

20
SQL Server Tests

• No equivalent to Loadsim; used simple sql scripts


• Create database, table, insert and drop rows:
7M records added/updated, 8M deleted, 3/4GB.
• Investigate initial allocation and growth
• Three data areas:
– Database (.mdf)
– Online Log (.ldf)
– Full and Log backups (.bak .trn)

21
SQL Server Tests

• SQL Server Space Allocation Policy


• Perfect for Hitachi Dynamic Provisioning
• Reduces risk
CREATE DATABASE trusql
ON
PRIMARY ( NAME = trusql1,
FILENAME = 'S:\V\B906\trusql1.mdf',
SIZE = 420MB,
MAXSIZE = 42000,
FILEGROWTH = 42)
LOG ON
( NAME = trulog1,
FILENAME = 'S:\V\B907\trulog1.ldf',
SIZE = 42MB,
MAXSIZE = 10000,
FILEGROWTH = 42)

22
SQL Server Tests

420MB
+Initial FS SQL Server DATA (Large Initial Size)
overhead
800
700
600
500
MB

400 Soon keeps


300 in step.
Insignificant Alignment
200
over use different.
100
0
0 SQL Server 500
does 1000 1500 2000
format space
HDP WIN

23
SQL Server Tests

SQL Server DATA (42MB INCREMENT)

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

HDP WIN MODEL

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

CREATE SMALLFILE TABLESPACE "VS1" DATAFILE '+VS1DG'


SIZE 42M AUTOEXTEND ON NEXT 42M MAXSIZE 1G
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
LOGGING DEFAULT NOCOMPRESS;

CREATE TABLE TESTVS1 (COL1 number(10) NOT NULL, COL3


number(10) NOT NULL)
TABLESPACE “VS1" STORAGE (INITIAL 1M);

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

Pool Archive Redo

32
Oracle without ASM: factors

Far too many choices: A A A A A A A


Database version (20)
Base OS (17+) VM raw FS VM FS CFS
OS version (8+) ASM
Raw
Volume Manager (0-2) LV LV LV LV
File System (0-22) VM VM DG
Oracle configuration
parameters (30+)

DP-Volumes

Switch, Cache, Virtualize, Dynamic Provision

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

Pool Table DG Difference

34
Oracle guidelines
• External redundancy only
• Create tablespace
– minimize initial allocation
• Create table
– minimize initial allocation

• NEXT=growth for a period – day (or week/month)


– Ideally multiples or integer divisor of 42MB page.

35
Replication products

• ShadowImage and Volume Migrator today.


Internal and external storage.
Copy-On-Write, TrueCopy and Universal Replicator in development.
• Works well with Hitachi Dynamic Provisioning.
Some rules, but they’re obvious.
• Useful configuration: HDP to HDP.
• Tested with Hitachi Protection Manager and it works well

36
General recommendations

• Avoid tools which write all the disk:


– low level unix media format or check
– volume level copy tools (dd)
• Don’t software RAID-1 mirror or RAID-5

• Use file level copy


• Defragmentation – not recommended

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

• Hitachi Device Manager


– Create, delete, increase Pools
– Create DP-VOLs, V-VOL Groups Max1%size
Device Details Pool
– Alerts Pool as seen
used Pool 9
Allocated by OS.
• Hitachi Tuning Manager
to Device
– Trending
– Trended alerts Pool
Threshold
– Reports
– Performance and capacity

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:

We have several additional WebTech’s planned this year

06 February: Virtualizing Storage to Gain Maximum Benefit from a VMware


Environment
20 February: Replication Management
19 March: Hot Spot Management with Hitachi Tiered Storage Manager
23 April: Creating Tuning Manager Reports

We will be adding additional sessions based upon participant requests.

• Please go to www.hds.com/webtech next week for the a


link to the recording, presentation, and Q & A in addition
to registering for upcoming WebTechs.
41
Questions/Discussion

42
Thank You

43

You might also like