• No results found

Understanding Disk Storage in Tivoli Storage Manager

N/A
N/A
Protected

Academic year: 2021

Share "Understanding Disk Storage in Tivoli Storage Manager"

Copied!
29
0
0

Loading.... (view fulltext now)

Full text

(1)

Understanding Disk Storage in Tivoli Storage Manager

Dave Cannon

Tivoli Storage Manager Architect

Oxford University TSM Symposium

September 2005

(2)

Disclaimer

ƒ Unless otherwise noted, functions and behavior described in this

presentation apply to Tivoli Storage Manager 5.3, but may differ in past or future product levels

ƒ Description of potential future product enhancements does not constitute a commitment to deliver the described enhancements or to do so in a

particular timeframe

(3)

Agenda

¾ Background

ƒ Random- and sequential-access disk in TSM

ƒ Special considerations for sequential-access disk

ƒ Potential future enhancements for disk storage

(4)

Disk vs. Tape

ƒ Potential disk advantages

– Faster access by avoiding delays for tape mounts and positioning – Reduced management cost (no tape handling)

– Reliability (RAID, no tape robotics or media failures)

ƒ Potential tape advantages

– Removability/portability for off-site storage (disaster recovery) – High-speed data transfer for large objects

– Cost effectiveness (especially for long-term, off-site archiving)

– Reliability (less susceptible to hardware failure or file system corruption)

ƒ Tiered approach with copies on offsite tape exploits strengths of disk and tape

(5)

Industry Trend Toward Increasing Use of Disk

ƒ Lower cost of disk storage (ATA, SATA)

ƒ Promotion of disk-based appliances and solutions (EMC, Network Appliance)

ƒ Virtual tape library (VTL) products comprised of preconfigured disk systems that emulate tape

ƒ Disk-based technologies

– Replication – Snapshots

– Continuous data protection (CDP)

(6)

TSM is Designed for Disk in a Storage Hierarchy

ƒ Disk has been an integral part of the TSM data storage hierarchy since 1993

ƒ Virtualization of disk volumes in a storage pool allows objects to be stored across multiple volumes and file systems

ƒ Automatic, policy-based provisioning of disk storage pool space and allocation of that space during store operations

ƒ Automatic, policy-based migration to tape or other media types in tiered hierarchy

ƒ Incremental backup of objects from primary disk pool to tape copy pool for availability or offsite vaulting

ƒ Objects automatically accessed in copy pool if not available in primary storage pool

Migration Copy

Copy Pool Store Client

DB

TSM database tracks location of files in data storage

(7)

Disk Usage Trend in TSM

Traditional Disk Usage

ƒ LAN-based data transfer between client and disk storage

ƒ Data initially stored on disk to allow concurrent client backups without tape delays

ƒ Backup from disk to tape copy storage pool for availability and disaster recovery

ƒ Most data migrated to tape within 24 hours

Emerging Disk Usage

ƒ Increasing interest in LAN-free transfer between client and disk

ƒ Data initially stored on disk to allow concurrent client backups without tape delays

ƒ Backup from disk to tape copy storage pool (may be main reason for tape)

ƒ Data may be stored on disk

indefinitely

(8)

A Detour on File Aggregation

ƒ TSM server groups client objects into aggregates during backup or archive

ƒ Information about individual client objects is maintained and used for certain operations (e.g., deletion, retrieval)

ƒ For internal data transfer operations (migration, storage pool backup), entire aggregate is processed as a single entity for greatly improved performance

Aggregate reconstruction

a b c d e f g h i j k l m

a b c d e f g h l m

Over time, wasted space accumulates as logical files

are deleted

l m a b c g h

Physical file (non-aggregate) with logical file a

a

Physical file (aggregate) with logical files b - f

b c d e f

(9)

Agenda

ƒ Background

¾ Random- and sequential-access disk in TSM

ƒ Special considerations for sequential-access disk

ƒ Potential future enhancements for disk storage

(10)

Overview of Random- and Sequential-Access Disk

ƒ TSM supports two methods for storing and accessing data on magnetic disk

– Random-access storage pools (also known as DISK pools) – Sequential-access storage pools (also known as FILE pools)

ƒ Random- and sequential-access disk pools differ in how TSM manages disk storage and the operations that are supported

ƒ TSM development views sequential-access disk as strategic

– Current functions on random-access disk supported for the foreseeable future – Future product enhancements involving disk storage may be offered only for

sequential-access disk

(11)

Basics of Random- and Sequential-Access Disk

Not supported Supported

TSM caching

ƒDefine Volume command

ƒSpace trigger

ƒScratch volumes

ƒDefine Volume command

ƒSpace trigger Volume creation

Files Files or raw logical volumes

Storage pool volumes

Supported Supported

Pools spanning multiple file systems

Device class with device type of Predefined device class DISK FILE

Storage pool definition

Sequential-Access Disk Random-Access Disk

(12)

Space Allocation and Tracking

a b

b a

a c

b

Storage pool volumes

b b

a c

Database

ƒSpace allocated in randomly located 4KB blocks

ƒTSM server tracks volumes and blocks on which each file is stored

ƒBit vector in TSM database tracks allocated and free blocks for each volume

ƒ

011010010010 Bit vector Location of blocks for file a

a b c

ƒFiles written sequentially in FILE volume

ƒTSM database only tracks volume and offset at which each file is stored

ƒTSM has less overhead for space allocation and tracking

Database

Storage pool volume

Location and length of file a

Random Access Sequential Access

+

(13)

Concurrent Volume Access

Random Access Sequential Access

Backup storage pool Restore

Node 1

Restore Node 2

Backup Node 3

ƒDisk volume is locked by a single process or session using that volume

ƒOther operations cannot access the volume until the lock is released, usually when the locking operation has completed all work on the volume

+

Backup storage pool Restore

Node 1

Restore Node 2

Backup Node 3

ƒMultiple TSM sessions or processes can concurrently use the same disk volume

ƒHowever, individual I/O operations for each volume are serialized

(14)

LAN-free Backup/Restore

Random Access Sequential Access

Client / Storage Agent

Server LAN

SAN

Control Data flow Not supported ƒSupported using either of the following to control

shared access to sequential disk volumes –SANergy

–Storage pool volumes on SAN FS (supported in TSM 5.3.1)

ƒReduces CPU cycles on TSM server and moves network traffic from LAN to SAN

+

(15)

Multi-Session Restore

Random Access Sequential Access

Client

Server Session 1

Server Session 1

Session 2

Multi-session restore allows one session per sequential-access volume

Multi-session restore allows only one session for all random-access disk volumes

+

Client / Storage Agent

(16)

Migration

Random Access Sequential Access

ƒHigh/low migration thresholds based on percentage occupancy of the pool

ƒIf node is grouped and target pool is collocated by group, parallel migration processes each work on a different group

ƒOtherwise, parallel migration processes each work on a different node

ƒOptimized for transfer by node and file space, making it an ideal intermediate buffer for

transfer from non-collocated tape to collocated

ƒHigh/low migration thresholds based on percentage of volumes containing data

ƒParallel migration processes each work on a different source volume, possibly dividing work more evenly among processes

ƒCollocated sequential disk can be used as a buffer for transfer from non-collocated tape to collocated tape

(17)

Storage Pool Backup

Random Access Sequential Access

ƒIf node is grouped and target pool is collocated by group, parallel backup processes each work on a different group

ƒOtherwise, parallel backup processes each work on a different node

ƒEach physical file (aggregate or non- aggregated file) must be checked during every storage pool backup

ƒParallel backup processes each work on a different source volume

ƒOptimization: For each primary pool volume and copy pool, database stores offset of volume that has already been backed up (no need to recheck during each backup)

ƒOptimization can be especially important for long-term storage of data on disk

+

(18)

Space Recovery

ƒWhen physical file is moved to another pool (if caching not enabled)

ƒSpace occupied by cached data is recovered as needed

ƒWhen physical file is deleted (for aggregates, all files in aggregate must be deleted)

ƒNo reconstruction of empty space within

aggregates, a disadvantage if aggregated files are stored for long periods of time

ƒSpace is not immediately recovered after movement or deletion

ƒReclamation recovers empty space created by deletion or movement of files

Aggregate reconstruction

a b c d e f g h l m a b c g h l m

a b c d e f g h l m

Random Access Sequential Access

Empty space accumulates until entire aggregate is deleted

+

(19)

Fragmentation

Use of scratch volumes causes fragmentation because

volumes are extended as

needed. Fragmentation can be Fragmentation is usually

minimal because volumes are predefined or created by space File system fragmentation

leading to fragmentation of files

Deletion of physical files results in empty space within volumes, but this is recovered during reclamation.

Volume fragmentation can also occur due to allocation of

multiple extents if client size estimate is too low.

Fragmentation can degrade performance, but is relieved by migration if no TSM caching.

Fragmentation of space within TSM volumes caused by deletion of physical files

Empty space is recovered by aggregate reconstruction during reclamation.

Empty space accumulates in aggregates until all logical files in aggregate are deleted. May result in wasted space for long- term storage on disk.

Aggregate fragmentation caused by expiration of files

Sequential-Access Disk

Random-Access Disk

+

(20)

Database Regression

Random Access Sequential Access

ƒAfter database regression, all volumes must be audited

ƒThis may be time-consuming for large DISK pools (for example, pools used for long-term data storage)

ƒAfter database regression, audit only volumes that were reused or deleted after database backup OR

ƒWith REUSEDELAY set, volume audit can be avoided completely

ƒTime delays for volume audits during critical

+

DB Backup

DB Backup

DB

b a

c

Disk storage pool volume 1. Database backup with references to files a,b,c

Backup

DB Backup DB

DB

d e

f

Disk storage pool volume 2. Files a,b,c deleted and space overwritten by d,e,f

DB Backup DB

DB

d e

f

Disk storage pool volume 3. Database restored with invalid references to a,b,c

Restore

b a c d e f b a c

(21)

Random vs. Sequential Disk: Which is Best?

Sequential offers significant advantages

ƒReconstruction recovers space in aggregates

ƒOptimized storage pool backup

ƒReduced volume fragmentation

ƒMulti-session restore

ƒAvoidance of volume audit Long-term storage of data on disk

Sequential (or possibly VTL) LAN-free data transfer between client and disk

storage

Either random or sequential, depending on requirements

Traditional disk usage

ƒLAN-based storage to disk

ƒDaily migration from disk to tape

Recommendation Disk Storage Usage

(22)

Agenda

ƒ Background

ƒ Random- and sequential-access disk in TSM

¾ Special considerations for sequential-access disk

ƒ Potential future enhancements for disk storage

(23)

Optimizing Space Efficiency

ƒ Scratch volumes

– Volumes are created and extended only as needed

– Space is conserved at the expense of file-system fragmentation

ƒ Non-scratch volumes (created by Define Volume command or space trigger)

– No collocation is more space-efficient – Smaller volumes are more space-efficient

ƒ Reclamation should be performed regularly to recover space

– Efficient because no mount/dismount

– Many volumes can be reclaimed concurrently

lume Size

Space Efficiency

- -

Increased space efficiency

(24)

Reducing Volume Contention

ƒ High-granularity collocation (by node or filespace) reduces contention

ƒ Smaller volume sizes reduce contention

None Group Node Filespace Collocation

Volume Size

+ + - -

Minimizing Volume Contention

Decreased volume contention

(25)

Improving Client Restore Performance

ƒ For no-query restore operations (used for most large restores), database scanning is greatly reduced if data is well collocated

ƒ Multi-session restore operations achieve greater parallelism if data is

spread over multiple sequential-access volumes, indicating that parallelism may be increased by

– Lower-granularity collocation – Smaller volumes

Volume Size

NQR Database Processing

+ -

- - - -

+ + + +

Reduced DB processing

Volume Size

Multi-session Parallelism

+

- -

Increased parallelism

(26)

Avoiding Fragmentation

ƒ Perform reclamation regularly

ƒ Avoid use of scratch volumes

ƒ Predefine volumes using Define Volume command

ƒ Use space trigger to provision additional volumes as needed

(27)

Striking a Balance

ƒ Configuration of sequential-access pools involves tradeoffs, but the following may be a reasonable starting point for most environments

ƒ Define volumes and use space triggers for additional volume provisioning

ƒ Collocate by node

ƒ Use volume size scaled to the size of stored objects

– For file systems, volume size of 500 MB to 10 GB

– For databases and other large objects, volume size of 100 GB

ƒ Set reclamation threshold at 20-60% and allow multiple reclamation processes

(28)

Agenda

ƒ Background

ƒ Random- and sequential-access disk in TSM

ƒ Special considerations for sequential-access disk

¾ Potential future enhancements for disk storage

(29)

Potential Future Enhancements for Disk Storage

ƒ Enhancements specifically for sequential-access disk pools

– Migration thresholds based on percentage occupancy rather than volumes with data – Support for raw logical volumes

– Concurrent read access for volumes

– Performance improvements on z/OS server

ƒ Collocation of active data (probably sequential-access disk only)

ƒ Management of redundant files

ƒ Data shredding (overwrite) as data is deleted from disk

ƒ Additional snapshot support

References

Related documents

For example, the sensor senses the body temperature of the user as an input and illuminates the color of the clothing as an output according to the input.. We have prototyped

This article tests whether context could play a significant confounding role in the measurement of learning preferences using questionnaires and thus potentially leading

The main objective of the Project on College Management System is to manage the details of College, Course, Batch, Faculty, Students.. It manages all the information about

At that time, the array controller will use the data and parity on the remaining disks to calculate the missing information and populate the hot spare.. While the array is running

In addition, given that virtual disks within Dynamic Disk Pools can potentially span very large numbers of disk drives versus tradtional RAID 5 or RAID 6 Disk Groups,

For the NASDAQ-100 E-mini Futures contract, this replacement occurs over a three-day rolling period every calendar quarter, starting three business days before the expiration of the

BENSON® Once-Through Drum Superheater Evaporator • Thick-walled HP drum limits operating flexibility due to high thermal stresses • Natural circulation principle Drum-type HRSG

the Traffic Manager. This mode is useful if all your SIP clients are on the same network as your Traffic Manager and the Traffic Manager is acting as a gateway to the Internet.