Tivoli Storage Manager Explained - Oxford University TSM...

1

IBM Software Group

© 2003 IBM Corporation

Tivoli Storage Manager ExplainedDave CannonIBM Tivoli Storage Management DevelopmentOxford University TSM Symposium 2003

IBM Software Group | Tivoli software

Tivoli Storage Manager Explained © 2003 IBM Corporation2

Presentation Objectives

Explain TSM behavior for selected operations

Describe design goals and rationale

Point out tradeoffs

Provide guidance for administrators

2



Topics

Basics

Policy management

Storage of objects

Storage pools

Database and recovery log



Basics

TSM highlights

Architecture

Progressive backup

3



TSM HighlightsAutomated, policy-driven storage management

Distributed, heterogeneous clients

Centralized storage-management servers

Support for numerous storage devices

Comprehensive storage-management functionB Backup/recoveryB Archive/retrieveB Space management (HSM)B Data protection for specific applicationsB Application Programming Interface (API)B Content management



Architecture

Database

Recovery Log

Storage Hierarchy

Backup/archive clientsHSM clientsAPI applicationsAdministrative clients

The server recovery log maintains information about database transactions so can be committed or rolled back atomically, maintaining referential

integrity in the database

TSM Client

The storage hierarchy is a collection of devices in which the TSM server

stores client objects

TSM Server

The server database holds information on users, administrators, policy, and the location of

objects in the storage hierarchy

4



Progressive Backup

Incremental backups

File expiration

Automated space

reclamation

Incremental backups

Initialbackup

Each object backed up only onceB Reduces network trafficB Avoids unnecessary copies of same

dataB Reduces impact to client application

Consolidates client data on few tapesB Reduce storage requirementsB Improve restore performance



Policy Management

Object-level policy management

Constructs for policy management

Inventory management

Versioning and retention

5



Object-level Policy ManagementNot all data is the sameB Some client nodes may be more critical or have different storage

requirements than other nodesB Data types (backup, archive, space-managed) may need to be managed

differentlyB Even for the same node and data type, some objects may have different

requirements than others

Manual management of stored data is expensive and error-prone

TSM provides granular, automated mechanism for administering policyB Node specificity is achieved by assigning node to a policy domainB Data-type specificity is achieved through use of backup/archive copy groups

and HSM policy B Object specificity is achieved by binding each object to a management class

when that object is first stored on TSM • Policy attributes for assigned management class can later be changed• Backup objects can be rebound to a different management class



Constructs for Policy ManagementApplication

servernodes

Workstationnodes

Destination storage poolWhat if file in use?Enforce frequency?Back up only if modified?How many versions?How long to retain?

Destination storage poolWhat if file in use?How long to retain?

Destination storage poolBackup required before migration?Days before migration?Migration technique?

Backup copy group Archive copy groupHSM policy

DomainManagement class

Backup copy group

Archive copy groupHSM policy

Management class

Backup copy group


Management class

Backup copy group


DomainManagement class

Backup copy group


Management class

Backup copy group


Management class

Backup copy group


6



Inventory Management

TSM database contains an inventory (catalog) of "end-user-visible" attributes (node, file space, name, policy) for managed client objects

Objects tracked in the inventory include – Directories

– Files

– File system images

– Delta objects (subfiles)

Each distinct object is assigned a unique 64-bit object identifier that is used for operations on that object

Via expiration, TSM server administers policy rules for retention and versioning of client objects



Versioning of Backup Objects

During backup B If no corresponding object on the server, new object becomes the

active versionB If corresponding object already exists on the server, new object

becomes active version and the existing active version is deactivatedB Extraneous versions are marked for expiration (base date set to 0)

The number of allowed versions of a backup object is determined by the object's management class and copy group

7



Expiration of Objects Based on Versioning or RetentionDuring backup, extraneous versions are marked for subsequent expiration based on

B VEREXISTS (backup object that exists on client system)B VERDELETED (backup object deleted from client system)

Once object has been marked for expiration, it cannot be queried from the client or restored, but database entries are not removed until expiration

During expiration, object is deleted if previously marked for expiration or if retention period of the object has been exceeded

B RETEXTRA (inactive backup object with other versions)B RETONLY (inactive backup object with no other versions)B RETVER (archive object)

When do objects "disappear" from client's view?B During backup (extraneous versions)B During expiration (objects whose retention time has elapsed)



Example of Versioning and Retention

Insertion Date Object Id State Expiration Base Date12:00:00 01/01/2002 10 Inactive 014:00:00 01/01/2002 20 Inactive 08:00:00 01/02/200208:00:00 01/02/2002 30 Active None

Object 10 is an extraneous version and would be expired during the next expiration operationObject 20 would be eligible for expiration on 08:00:00 02/01/2002 (30 days after the base date) if it is not versioned before then

VEREXISTS: 2RETEXTRA: 30

8



Delta-Base Versioning and Expiration

Example assumes VEREXISTS=2Once base file is marked for expiration, it cannot be restored by itselfExpiration does not delete base file with dependent deltas (deletion of base may not occur until next expiration process after deletion of last delta)

B

D V2 (active)

V1 (inactive)

2. Backup of delta file

F V1 (active)

1. Backup of entire file

D

B

D

V1 (marked for expiration)

V2 (marked and expired)

V3 (inactive)

D V4 (active)


D

B

D


V3 (marked and expired)V4 (inactive)

B V5 (active)

5. Backup of entire file

D

B

D


V2 (inactive)

V3 (active)

B



B V1 (marked and expired)

D

B

D V6 (active)

V5 (inactive)

V4 (marked and expired)



Storage of Objects

File aggregation

Movement of active files only?

Data validation for stored objects

Database regression and references to stored objects

9



What is 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 many operations, especially internal data transfer, entire aggregate can be processed as a single entity

Aggregate size and number of client objects per aggregate can becontrolled

Physical file (non-aggregate)with logical file a

b c d e fa

Physical file (aggregate) with logical files b - f



Why Aggregate Files? Performance!

Improved storage device performance because data transferred in larger units

With aggregation

ad abcdebce

Without aggregation

abcde

a

ecd

b

Without aggregation With aggregation

Database Database

?

Aggregates can be transferred without examining constituent files

Reduced overhead for database updates during transfer operationsbecause storage information not updated for each logical file (also reduced database size)

10



Logical File Storage and Retrieval

1. Send logical files

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

2. Aggregate and store objects

abcdefgijk hl Database3. Store metadata

Storage

Client

Server

1. Request file hDatabase

2. Get metadata

3. Perform partial-object retrievea b c d e f g h i j k l m

Offset of h

4. Send file hh

Retrieval

Client

Server



Reclaiming Space via Aggregate Reconstruction

Remaining logical files are moved in "regions"

Reconstructed aggregate contains all remaining logical files, without empty space



l ma b c g h

l mg h

Over time, logical files within an aggregate may be deleted, leaving wasted space

a b c

11



a b c d

Problem: Invalidation of Copies

X is available and recoverable from copy

pool

Aggr X (Backup)Aggr X (Primary)Duplication

Aggr Y (Primary)

Reconstruction

Copy does not match

a c d

a b c d

Problem occurs because aggregates in different storage pools are not reconstructed at the same time Since Y not found in the copy pool, should it be backed up?

Y is not available and recoverable from copy

pool



a b c d

Solution: Aggregate Aliases

Aggr X (Backup)Aggr X (Primary)Duplication

Aggr Y (Primary)

Reconstruction

X and Y are aliases

a c d

Aliases are aggregates that contain exactly the same files, but at different offsetsNew backup of Y not required because its alias X already exists in copy poolFiles in X can be accessed if Y is unavailableY can be restored from X

a b c dX is available and

recoverable from copy pool

Y is available and recoverable from copy

pool

12



Benefits of Aggregate Aliases

AggregationCopy StoragePools

Reconstruction

Availability/Recovery Performance

Space Reclamation

Aliases



Movement of Active Files Only?Movement of only active files during internal data-transfer operations (storage pool backup, migration) would eliminate many of the benefits of file aggregation

B Server would need to examine contents of each aggregate to determine if it contains any active files

B Aggregate could no longer be treated as a single entity during transfer operations

B Some aggregates contain a mixture of active and inactive files• Could transfer aggregates that contain at least one active file• This could result in the transfer of many inactive files

What about reorganizing aggregates to segregate the active and inactive files?B Ongoing file deactivation would leave inactive files in the "active"

aggregatesB Aggregate aliases would not work because there would be no

correspondence between the aggregates in different storage pools

If TSM were to provide an option to disable aggregation and allow movement of active files only, performance impact would be significant

13



Consistency of Database and Stored Objects TSM uses its database to locate objects in storage

Data integrity requires that database information be consistent with data stored on storage pool volumes

Inconsistency can occur for reasons such asB Hardware errors B Media damage or degradationB Storage pool volumes have been overwrittenB Database has been regressed to an earlier version

If inconsistencies are detected or suspected, considerB Are the errors permanent (errors written to media) or temporary (data

written correctly, but errors during read)? B Are there duplicate copies of the data?

Audit Volume can be used to check for consistency



Data Validation for Stored Objects

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

Object header prepended before each object Frame headers and trailer for each physical file

Frame headers/trailer for aggregate X

Frame headers/trailer for aggregate Y

Frame headers/trailer for object h

TSM server embeds control information in stored data for integrity checking during client restore/retrieve, aggregate reconstruction, and Audit VolumeOptionally, CRC checking can be enabled by storage poolB CRC is generated and stored with data as it is initially written to storage

pool volumeB During Audit Volume, CRC is generated and compared with stored CRC

valueExample:B Objects a, b, c, d, and e stored in aggregate XB Object f and g stored in aggregate YB Non-aggregated object h

14



Database Regression and References to Stored Objects

DB Backup

DB

Storage pool volumes

2. Movement of files

ab cReclamation

DB Backup

DB


3. Overwriting of storage

ab ce f

d

DB Backup

DB

acb

1. Database backup

BackupDB

acb

Storage pool volume

1. Database backup

Backup

DB Backup

DB


4. Database restore

ab ce f

d

Restore

Regressing database to earlier point in time can lead to incorrect references for overwritten filesReuse delay ensures that empty sequential-access volumes are not overwritten for specified time (should match retention time of database backups)Use Audit Volume to detect inconsistenciesB All random-access volumesB All reused/deleted volumes per volume history file



Storage Pools

Why storage pools?

Storage virtualization

Random-access and sequential-access storage

Copy storage pools

Reclamation of offsite volumes

15



Why Storage Pools?Storage hierarchy exploits attributes of different device typesB Performance B Concurrent accessB CostB Ability to remove media for remote storage

Organization of storage into storage pools supports automatic, policy-based management of stored objects

Migration

Migration

Reclamation

Backup

Storage Pool Hierarchy

Copy Pool



Storage Virtualization

Each object is assigned a surrogate key, a unique 64-bit object IDIf file is aggregated, the object ID is mapped to one or more aggregates, each with a unique aggregate IDID of aggregate or non-aggregated object is mapped to storage locations, each consisting of storage pool, volume, and positionName-location independence allows movement and duplication of objects in storage, transparent to user or application to which data belongs

151619

818286

98

Object Name

ObjectAttributes

ObjectID

15 1016 1019 10

81 8082 8086 80

1010

808080

989898

Object ID

StoragePool

Offset/Length ID

VolumeLocation

Aggr ID

Inventory

Aggregation

Storage

16



Random-access and Sequential-access StorageStorage pools are classified as random-access or sequential-accessSeparate code paths for managing pools, volumes, and stored objectsSome operations are supported for only one access typeB Fundamental differences (e.g., caching supported for random-access only)B To reduce development/maintenance effort (e.g., copy pools are sequential-

access only)Some processes have very different algorithms depending on access type (e.g., to optimize mounting/positioning of sequential-access volumes)

aabc

ca

bb

bc

c

a b c

Primary pools only Block allocationPolicies

B Migration parametersB Cache?B Simultaneous write to copy pool?B Maximum physical file sizeB CRC data?

Random-access Sequential-access

Primary or copy poolsVolume selectionPolicies

B Migration/reclamation parametersB Collocation?B Simultaneous write to copy pool?B Maximum physical file sizeB CRC data?B Maximum scratch volumesB Reuse delay



File-level Duplication Using Copy Pools

Supports incremental backup of storage pool dataExisting copies still valid even if primary volume is reclaimed or data moved to another level in the hierarchyPrimary and duplicate data can have different media/device types or capacities (short tapes)Device and platform independence (no reliance on system copy utilities)Copies can be made synchronously (during creation) or asynchronously (after creation)Performance of file-level duplication improved through file aggregationAvailability/recoverability at various levelsB Damaged physical fileB Primary volumeB Storage pool

Migration

Migration

Reclamation

Backup

Storage Pool Hierarchy

Copy Pool

17



Reclamation of Offsite Volumes

Automated data transfer per policy (steps 1-3 above)Allows space reclamation of volumes at offsite locations without libraryAvoids risking data loss, which could occur if volume were brought onsite for traditional reclamationCan be coupled with reuse delay for protection if database is regressed

DB

2. Copy files from on-site location to new

copy pool volumes

3. Update database to reference new location of files

Server location1. Use database to identify remaining

files on reclaimable volumesReclaimable

off-site volumes

Offsite location

Databasebackup

4. Transport

offsite

5. Transport

onsite



Database and Recovery Log

Database objects and structure

Database buffer pool

Recovery log structure

Recovery log utilization

18



Database Table Objects

Within the database, table structure is a balanced tree (B+-tree), whose nodes are stored as database pages

Internal (non-leaf) node

Root

Leaf node

Key columns

Record

Data columns

From the perspective of a TSM component that uses the database, table schema describes key and data columns for table



Database Bit-vector Objects

From the perspective of a TSM component that uses the database, a bit-vector is a linear array of bits representing allocation of blocks on a disk storage pool volume

Within the database, a bit-vector is stored as linked pages

11111100011111111000000…

19



Database Structure

smp ic dir

Space map page every 4MB (tracks allocated pages)

Image copy header (persistent information for DB backup)Object directory

Bit-vectorTable

root page



Database Buffer Pool

empty

cleanempty

empty

clean

clean

clean

clean

clean

clean

dirty

dirty dirty

dirty dirty

dirty

dirty dirty Checkpoint

Recovery LogBuffer writer

Database

Latch

Memory cache for DBDefers database updatesBufferwriter writes out dirty DB pages making them clean againCheckpointer occasionally records all dirty pages in the recovery log

20



Recovery Log Structure

Log Sequence Number (LSN):64 Bits

Logical segment number : 44 bitsPage : 8 bitsOffset: 12 bits

Displayed as 3 dotted numbers: 23141.153.45

1 MB 1 MB 1 MB 1 MBSegment 25 Segment 22 Segment 23 Segment 24

Segments:Log is composed of segments, each containing 256 4KB pagesLogical segment numbers always increaseLog will wrap

Log Sequence Number

Logical segment numberPage

Offset

Physical Segment 1 Segment 2 Segment 3 Segment 4

Logical



Log Modes and Location of Log Tail

Log TailOldest active transactionLSN for oldest dirty page in buffer poolLast checkpoint record (there MUST be a checkpoint in the activerecord area)Start of currently running DB backup (log tail is pinned during backup)

OROldest transaction since last DB backup if the log is in rollforwardmode

Log Head

Active Records

For n

orm

al m

ode,

log

tail

is o

ldes

t of t

hese

21



Recovery Log Utilization

Tortoise and hare problem: If the log head (hare) overtakes the tail (tortoise), the circular recovery log is full

Active Log Records

Log Head

empty

cleanempty

empty

clean

clean

clean

clean

clean

clean

dirty

dirty dirty

dirty dirty

dirty

dirty dirty

Checkpoint

DB

DB Buffer Pool

Buffer writer

RecoveryLog

Log Tail



Product Changes to Avoid Full Recovery LogIncreased maximum recovery log size

Cancellation of stalled sessions (Throughputdatathreshold / Throughputtimethreshold options)

Enhanced database trigger

Show Logpinned command to determine what is pinning the log

Show Logstats and Show Logreset commands to determine log space consumed by checkpoint records

Autonomic transaction throttling if recovery log approaches full condition

22



Conclusion

TSM provides a comprehensive storage-management solution

We've discussed some of the features that make this possibleB Progressive backupB Object-level policy managementB Aggregation of stored files for improved performance B Storage pools for hierarchical, policy-driven storageB Storage virtualizationB Automated duplication of data and management of offsite volumesB Sophisticated database and recovery log

Tivoli Storage Manager Explained - Oxford University TSM...

Documents

Transcript of Tivoli Storage Manager Explained - Oxford University TSM...