TSM6 Migration Suggestions PDF

Tivoli Storage, IBM Software Group
Tivoli Storage Manager 6.2 / 6.22 / 6.x
Tricia Jiang Cyrus Niltchian Technical Evangelists
2009 IBM Corporation
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
2009 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
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
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
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
TSM 6 Planning and Performance 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 GAd 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
whats new how to configure it


Memory requirements
CPU requirements

TSM V6 Storage Components

Active Log
TSM Server
TSM DB
Log Mirror (optional)
Archive Log
TSM STGPools (disk, tape)
Failover Archive Log (optional)

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 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
LUN 1 VG1 /db1 50GB
LUN 2 VG2 /db2 50GB
LUN 3 VG3 /db3 50GB
LUN 4 VG4 /db4 50GB

Extending the DB Option 1 Create 2 new 50GB LUNs
Assign to Volume Group and create File System

Assign to TSM
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
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

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
LUN 1 200GB
Disk Array
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 dont 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

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

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
Active Log Log Mirror Archive Log(1) V5 DB V5 Rcvylog
Type
Disk Disk Disk Disk Disk
Same system Media
Same system Network
New system Media
New system Network
32GB 0 100GB 100GB 13GB
32GB 0 100GB 100GB 13GB
32GB 0 100GB 0 0
32GB 0 100GB 0 0
DB2 DB DB Backup
Extract Total Disk Total Seq
Disk Seq Media

Seq Media Disk Seq Media
145GB 200GB
80GB 390GB 280GB
145GB 200GB
0 390GB 200GB
145GB 120GB
80GB 277GB 200GB
145GB 120GB
0 277GB 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

DB Requests Database Manager (tsmuser)
Active Log
TSM DB
TSM Server (tsmuser, root, or Administrator)
Log Mirror (optional)
Archive Log
TSM STGPools (disk, tape) Configuration Files dsmserv.opt, trace, devconfig, volhist
24
Failover Archive Log (optional)
A Look at the Processes Unix

Server
IPC Shared Mem Msg Queues
Database Manager
dsmserv
db2sysc
tsmuser 365186 209986 tsmuser 246764 209986 dsmserv 328786 107714
0 11:13:36 0 11:13:35 0 11:13:34
pts/0
0:00 db2acd 0 0:25 db2sysc 0 0:03 dsmserv
db2sysc is the main database manager process db2acd is the DB2 health monitor
Processes communicate via IPC

A Look at the Service List Windows

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

Contains archives of active log files for database restore
Mirror Log Directory

Mirror of the active log directory same size

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

Full Txn 1 Full Txn 2 Txn 3 Txn 4 S0000099.LOG S0000100.LOG S0000101.LOG S0000102.LOG Full Current
Active
S0000098.LOG S0000099.LOG S0000100.LOG
Archive (Now Full) Failover Archive

S0000101.LOG

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 TSMs SELECT statements to the DB
Improves DB2s 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

1
TSM DB2 Database
TSM Server
3 1 Initiate DB Backup 2 Intercept Inbound Session from DB2 3 Stream DB Backup to Sequential DataStream
Sequential DataStream (Seq Disk or Tape)
4
Volhistory
4 Volume history file is written


TSM6 Migration Suggestions PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TSM6 Migration Suggestions PDF

Uploaded by

Copyright:

Available Formats

Tivoli Storage, IBM Software Group

Tivoli Storage Manager 6.2 / 6.22 / 6.x

Tricia Jiang Cyrus Niltchian Technical Evangelists

2009 IBM Corporation

Tivoli Storage, IBM Software Group

2009 IBM Corporation 2

Tivoli Storage, IBM Software Group

TSM 6 Planning and Performance

TSM 6.2 Updates

2009 IBM Corporation 3

Tivoli Storage, IBM Software Group

TSM for SharePoint 6.1 GA 5/8/09

TSM HSM for Windows 6.1

TSM FastBack 5.5.3 and 5.5.4 2Q 2009

2009 IBM Corporation

Tivoli Storage, IBM Software Group

TSM 6 Planning and Performance Current Field Status

Storage requirements for the new database and logs

2009 IBM Corporation 5

Tivoli Storage, IBM Software Group

2009 IBM Corporation 6

Tivoli Storage, IBM Software Group

TSM 6 Planning and Performance Current Field Status

Storage requirements for the new database and logs

2009 IBM Corporation 7

Tivoli Storage, IBM Software Group

TSM V6 Storage Components

Log Mirror (optional)

TSM STGPools (disk, tape)

Failover Archive Log (optional)

2009 IBM Corporation 8

Tivoli Storage, IBM Software Group

The TSM Database Implemented via DB2

Specified as a set of directories

Be generous in size estimates plan for growth

To add space, you can either

Tivoli Storage, IBM Software Group

Size Estimate for V6 Database

Assume 600-1000 bytes per object stored

2009 IBM Corporation 10

Tivoli Storage, IBM Software Group

4 LUNs, each 50GB, assigned from Disk Array

LUN 1 VG1 /db1 50GB

LUN 2 VG2 /db2 50GB

LUN 3 VG3 /db3 50GB

LUN 4 VG4 /db4 50GB

2009 IBM Corporation 11

Tivoli Storage, IBM Software Group

Extending the DB Option 1 Create 2 new 50GB LUNs

Assign to Volume Group and create File System

Caution! DB2 will perform online reorganization

Tivoli Storage, IBM Software Group

Extending the DB Option 2 Create 4 new 25GB LUNs

Extend each file system by 25GB

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

2009 IBM Corporation 13

Tivoli Storage, IBM Software Group

Possible Database Layout Array Managed

Let the DS8K or other Disk Array manage the LUNs