tsm6-migration-suggestions.pdf

Tivoli Storage, IBM Software Group

© 2009 IBM Corporation

Tivoli Storage Manager 6.2 / 6.22 / 6.x

Tricia Jiang

Cyrus Niltchian

Technical Evangelists



Agenda

In this presentation we will discuss TSM 6 Planning

and Performance, TSM 6.2 updates, TSM 6.2.2 and

what was released in TSM 6.3

© 2011 IBM Corporation 2



Agenda

TSM 6 Planning and Performance

TSM 6.2 Updates

TSM 6.2.2 Updates

TSM 6.3

Additional Presentations




TSM 6.1

TSM 6.1

GA 3/27/09

Scalability, Availability and Performance

•Server scalability –upgrade TSM DB

•Data Deduplication

Administration and Reporting

•Administration Center Updates

•New out of the box Reporting / Monitoring

Windows platform Enhancements

•MS Active Directory Item Recovery

•Exchange Item Level Recovery

N series integration

•SnapMirror to Tape integration

•Incremental Backup File Selection enhancement for N series /

NetApp

Other Enhancements

•VCB: Full VM for Disaster Recovery

•MS Windows Longhorn exploitation

•TSM ACS XIV Support and AIX6.1 Support

•Instant restore for XIV for windows (for CS)

•FastBack Configuration wizard added into B/A Client

TSM for SharePoint 6.1

GA 5/8/09

•SharePoint backup and system monitoring dashboard

•Automation of backup job scheduling based upon access

frequency and business importance

TSM HSM for Windows 6.1

GA 5/8/09

•Automatic threshold migration

•Windows Server 2008 (64-bit) support.

• Support for IPv6)

TSM FastBack 5.5.3 and 5.5.4 2Q 2009

Scalability & Performance

Reporting

Various Environment Support enhancements




Current Field Status

Storage requirements for the new database and logs

Memory requirements

CPU requirements

User ID requirements

Upgrade Considerations

Examining database and log operations

Backing up the database




TSM 6 Deployments Are Growing

First TSM 6 GA’d March 2009 with significant new code

and functionality

Early input from technical sales teams, support teams,

and customers suggests:

– TSM 6 adoption is growing, but slightly less than the 5.5 rate

– TSM 6 field reported problems are in line with prior releases

– Customers are hungry for more information about the new

database

• what’s new

• how to configure it







Memory requirements

CPU requirements








TSM V6 Storage Components

TSM Server

Log Mirror

(optional)

Archive Log

Failover

Archive Log

(optional)

TSM DB

TSM STGPools (disk, tape)

Active Log




The TSM Database

Implemented via DB2

Specified as a set of directories

– DB2 spreads the database across all directories

• Tries to maintain equal distribution across the directories

Be generous in size estimates – plan for growth

– If you under allocate, DB2 may need to reorganize the database

• Done transparently, but time consuming

– To add space, you can either

• Add directories

• Make existing directories bigger

– Suggest you start with many smaller directories and make them

bigger as necessary




Size Estimate for V6 Database

Assume 600-1000 bytes per object stored

Deduplication adds 250 bytes per extent per storage pool




Possible Database Layout – DB2 Managed

LUN 1

VG1

/db1

50GB

LUN 2

VG2

/db2

50GB

LUN 3

VG3

/db3

50GB

LUN 4

VG4

/db4

50GB

Assume you estimate 200GB for disk space

4 LUNs, each 50GB, assigned from Disk Array

Each LUN is assigned its own Volume Group on host

Each Volume Group has one File System

DB2 will use separate I/O threads for each directory




Extending the DB – Option 1

LUN 1

VG1

/db1

50GB

LUN 2

VG2

/db2

50GB

LUN 3

VG3

/db3

50GB

LUN 4

VG4

/db4

50GB

Create 2 new 50GB LUNs

Assign to Volume Group and create File System

Assign to TSM

LUN 5

VG5

/db5

50GB

LUN 6

VG6

/db6

50GB

Caution! – DB2 will perform online reorganization

LUN 1

VG1

/db1

50GB

LUN 2

VG2

/db2

50GB

LUN 3

VG3

/db3

50GB

LUN 4

VG4

/db4

50GB

LUN 5

VG5

/db5

50GB

LUN 6

VG6

/db6

50GB




Extending the DB – Option 2

Create 4 new 25GB LUNs

Extend each file system by 25GB

– Can also be done on Windows via “Disk Management”

No need to assign to TSM

No need for DB reorganization

LUN 1

LUN 5

VG1

/db1

75GB

LUN 2

LUN 6

VG2

/db2

75GB

LUN 3

LUN 7

VG3

/db3

75GB

LUN 4

LUN 8

VG4

/db4

75GB




Possible Database Layout – Array Managed

Let the DS8K or other Disk Array manage the LUNs

Assign 1 single 200GB LUN to the host

One Volume Group and one File System

DB2 will use separate I/O threads for each directory

Disk 1

50GB

Disk 2

50GB

Disk 3

50GB

Disk 4

50GB

Disk Array

LUN 1

200GB

Host




DB2 Usage of Array Managed Storage

DB2 has parameter to control parallel I/O

– db2set –i <instance> db2_parallel_io

TSM sets this to “*”

– Tells DB2 to assume this directory can handle multiple requests

– DB2 default is to use 6 I/O threads

• If your hardware can handle 12 concurrent I/O requests, then – Login as instance user ID, and issue

– db2set db2_parallel_io=12

• You may need to restart the TSM server for this to take effect




The TSM Log Directories

Log space is more complicated than with TSM V5

– Required Log Directories

• Active Log Directory – Contains all currently active transactions

• Archive Log Directory – Contains all transactions required for DB restore to last backup point

– Optional Log Directories

• Active Log Mirror Directory – Mirror copy of the active log

• Failover Archive Log Directory – Failover directory for archive log

All log directories should be tuned for sequential I/O

– No log directory should reside on the same disk or LUN as any

other log or database directory




Log Size Estimates

Active Log Directory

– Must be large enough to hold all active transactions

– 2GB minimum, but start with at least twice size of V5 log

• If the log fills up, the server halts – don’t underestimate

• You can reduce log size with server restart if you over allocate

– This is the highest priority of any log directory

• Should be on its own dedicated LUN or disk

Archive Log Directory

– Must be large enough to hold all log files generated in 2 days

• Assuming you back up the database daily

• DB Backup removes log files from archive directory

– Performance not as critical




Log Size Estimates

Mirror Log (Active Log Mirror) Directory

– Same size as active log

– Same performance requirements as active log

Failover Archive Log Directory

– Large secondary storage in case archive log directory fills

• Also used if archive log directory unavailable

– Can be a directory in a shared file system (NFS/CIFS)

– If this directory gets used frequently, then archive log too small

– Tune archive log to avoid using failover




Preparation – Sample for 100GB database 80% Utilized

Item Type Same system

Media

Same system

Network

New system

Media

New system

Network

Active Log Disk 32GB 32GB 32GB 32GB

Log Mirror Disk 0 0 0 0

Archive Log(1) Disk 100GB 100GB 100GB 100GB

V5 DB Disk 100GB 100GB 0 0

V5 Rcvylog Disk 13GB 13GB 0 0

DB2 DB Disk 145GB 145GB 145GB 145GB

DB Backup Seq Media 200GB 200GB 120GB 120GB

Extract Seq Media 80GB 0 80GB 0

Total Disk Disk 390GB 390GB 277GB 277GB

Total Seq Seq Media 280GB 200GB 200GB 120GB

Note 1: Archive log consumption changes in V6.1.2







Memory requirements

CPU requirements








Memory Requirements in V6

DB buffer pool moved outside dsmserv process

– Managed by DB2 (db2sysc/db2syscs)

8GB RAM Recommended

– DB2 buffer pool is larger

– DB2 more efficient buffer pool management

– DB pages are larger

IPC facilities used for dsmserv/db2sysc communication

– Make sure you have high system limits on

• Shared Memory regions

• Message Queues







Memory requirements

CPU requirements








CPU Requirements for V6

CPU requirements slightly higher than V5

External Functions requiring more CPU include

– Deduplication

• SHA-1 and MD5 cryptographic functions highly CPU intensive

– Multi-process Expiration

• Trade-off between time and CPU

Internal Functions requiring more CPU include

– DB reorganization

– DB runstats

• Used to optimize database lookups




TSM V6 Storage Components

Log Mirror

(optional)

Archive Log

Failover

Archive Log

(optional)

TSM DB

TSM STGPools (disk, tape)

Active Log Database

Manager

(tsmuser)

Configuration Files

dsmserv.opt, trace,

devconfig, volhist

TSM Server

(tsmuser, root, or

Administrator)

DB

Requests




A Look at the Processes – Unix

db2sysc is the main database manager process

db2acd is the DB2 health monitor

Processes communicate via IPC

IPC

Shared Mem

Msg Queues

Server

dsmserv

Database

Manager

db2sysc

tsmuser 365186 209986 0 11:13:36 - 0:00 db2acd 0

tsmuser 246764 209986 0 11:13:35 - 0:25 db2sysc 0

dsmserv 328786 107714 0 11:13:34 pts/0 0:03 dsmserv




A Look at the Service List – Windows







Memory requirements

CPU requirements








Preparing for the Upgrade

Read the DB Upgrade Utility README

Obtain the DB Upgrade Utility

– Separate from TSM V6 Product

– Always get the latest available from the FTP site

Obtain the TSM V6 DVDs

– Back up V5 database before installing V6

References:

– DB Server Upgrade Guide (SC23-9554)

– Storage Technical Exchange Website:

– http://www-01.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html




TSM V6 Restrictions

Cannot switch platforms using Upgrade Utility

– Following architecture upgrades supported

• Windows x86 to Windows x64

• Windows IA64 to Windows x64

• HP PA-RISC to HP IA64

• 32-bit to 64-bit on same platform with same endianness – For example, AIX 32-bit to AIX 64-bit

Cannot merge multiple V5 databases during upgrade

Cannot alter the underlying DB2 settings

– Pre-configured by TSM during installation and format







Memory requirements

CPU requirements








The Log Directories (Revisited)

Active Log Directory

– Linear (non-circular) fixed-size log in a single directory

• Performance and availability are very important

– Broken up into 512MB files

Archive Log Directory

– Contains archives of active log files for database restore

Mirror Log Directory

– Mirror of the active log directory – same size

Failover Archive Log Directory

– To handle overflow of archive log directory




How the logs flow

Transaction starts and stops are written to active log

Once an active log file is full, it is immediately copied to

an archive log directory

– If the archive log directory is not writeable, it is copied to the

failover archive log

– If the failover archive log is not writeable, it is not copied

When an active log file has no more active transactions

within it, it is eligible for deletion

– Cannot be deleted until it is archived




How the logs flow

Txn 1

S0000099.LOG S0000100.LOG S0000101.LOG S0000102.LOG

Current Full Full Full

Active

S0000098.LOG S0000099.LOG S0000100.LOG

S0000101.LOG

…

Archive (Now Full)

Failover Archive

Txn 2

Txn 3

Txn 4




Keeping the logs flowing

To keep the active log from filling:

– Make sure the active log is large enough to contain active txns

• Watch out for slow clients pinning the log

• In TSM V6, there is much more log activity than in TSM V5

• If your active log is too small, it will fill and the server will halt

– Make sure the archive log directories have space

To keep the archive log directories from filling:

– Perform regular FULL DB backups

• FULL DB backups will clear the archive log directories

• With TSM 6.2 Incremental backups will also clear the log directories

It may take some time, but if ANY of the log directories

becomes full, the server may halt

– The reason for the halt will be out of active log space




Database Maintenance Tasks

Table Reorganization

– Performed when CPU and I/O activity low

– DB2 optimizes database tables for efficiency

– Generates a lot of active log records

• Can interfere with long-running transactions

ANR0293I Reorganization of table <table_name> started.

ANR0294I Reorganization of table <table_name> ended.

Statistics Updates (runstats)

– Used by DB2 to optimize TSM’s SELECT statements to the DB

• Improves DB2’s ability to use indices to avoid table scans

ANR0136I Table updating statistics performed successfully for n of n.







Memory requirements

CPU requirements








Configuring V6 for DB Backup

V6 database backup uses the TSM client API

– API installed automatically with V6 server

– Uses a special nodename “$$_TSMDBMGR_$$” for backup

• Password MUST be TSMDBMGR

• This node is hidden and can perform only DB backup and restore

– Note: Be careful when canceling sessions. It is possible to cancel

the API session doing the DB Backup

V6 database backup and restore require volumehistory

and devconfig files

If possible, use either instance config or upgrade wizard

– Set the password in TSM.PWD or registry entry

– Sets up dsm.opt, dsm.sys, and DB2 parameters




Processing Flow of DB Backup

TSM

DB2

Database

TSM

Server

Sequential DataStream

(Seq Disk or Tape)

1

1

Intercept Inbound Session from DB2

Stream DB Backup to Sequential DataStream

TSM

DB2

Database

TSM

Server

Sequential DataStream

(Seq Disk or Tape)

2

3

2

3

Initiate DB Backup

4

Volhistory

Volume history file is written 4


tsm6-migration-suggestions.pdf

Documents

ibm software group

log operations backing

logs memory requirements

service list windows

active log file

failover archive log

archive log directories

file system db2