23.10.

2015

IBM Spectrum Protect

Node Replication

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Disclaimer

IBM’s statements regarding its plans, directions, and intent are subject to change or
withdrawal without notice at IBM’s sole discretion.

Information regarding potential future products is intended to outline our general

product direction and it should not be relied on in making a purchasing decision.

The information mentioned regarding potential future products is not a commitment,

promise, or legal obligation to deliver any material, code or functionality. Information
about potential future products may not be incorporated into any contract. The
development, release, and timing of any future features or functionality described
for our products remains at our sole discretion.

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

1
 23.10.2015

Agenda

• Overview
• Preparing for Replication
• Performing a Replication
• Best Practices
• 7.1.3 Enhancements
• Future Enhancements

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Agenda

Overview
• Preparing for Replication
• Performing a Replication
• Best Practices
• 7.1.3 Enhancements
• Future Enhancements

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

2
 23.10.2015

What is node replication

1. Initial replication – all objects are copied to th target server

• Backup, Archive and Space Management Objects
2. Deleted objects are deleted from target server
3. Modified objects are updated on the target server
4. Newly stored objects are copied during next replication

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Node replication for disaster recovery

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

3
 23.10.2015

Node replication for branch office

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Node replication advantages

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

4
 23.10.2015

Characteristics

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

TSM 7.1 Automatic client redirection

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

5
 23.10.2015

TSM 7.1.1 Recovery of damaged files from target

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Recovery of damaged files

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

6
 23.10.2015

TSM 7.1.1 Dissimilar policies

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Dissimilar policies

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

7
 23.10.2015

Replication and Deduplication

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Reconsile processing
● Prior to TSM 7.1.1, replication has always done a reconcile
– Compares complete list of files between the source and target server
– Used to synchronize the source and target servers
● Reconcile in TSM 7.1.1- Examines entire list of files in a file space (much like pre 7.1.1)
– Used during the initial replication between 7.1.1 servers
● Once reconcile completes, change tracking processing takes over during the next replication
– Restartable – remembers where it left off if cancelled or after some catastrophic server event
– Automatically runs following a database restore on the source or target server
– Can run manually using REPLICATE NODE FORCERECONCILE=NO|YES
• Synchronize source/targert files - used like an audit
● Change Tracking in TSM 7.1.1 eliminates need to query target server for its list of files
– New and change files are assigned a change identifier, when it is stored and when metadata is
updated
– Replication only processes files with a change identifier – incremental replication
– Replication picks up where the last replication left off
– Improves performance for fs with lots of files

● Showed a 2-3x improvement. ~200 GB/hr → ~500 GB/hr

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

8
 23.10.2015

File deletion processing

• Processing of files deleted on the source server (prior to 7.1.1)

• With current implementation, files that have been deleted on the source server
are deleted on the target server during replication
• Locking issues can cause delays, especially for deduplicated files
• Processing of files deleted on the source server (7.1.1)
• During replication, source server sends list of files that have been deleted on
source (does not include expired files if dissimilar policies enabled)
• During replication, target server updates its database to indicate deleted files
• Expiration processing deletes indicated files on the target, outside the
replication window
• Processing of files deleted on the target server (7.1.1)
• During replication, target server sends list of files that have been explicitly
deleted on the target
• During replication, source server resends explicitly deleted files to the target

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Agenda

• Overview
Preparing for Replication
• Performing a Replication
• Best Practices
• 7.1.3 Enhancements
• Future Enhancements

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

9
 23.10.2015

Hardware requirements

• CPU/RAM minimum recommendations

• With deduplication, 8 CPU cores, 64GB RAM
• Best practice: 8 CPU cores, 128GB RAM
• Without deduplication, 4 CPU cores, 32GB RAM
• Best practice: 4 CPU cores, 64GB RAM
• Best practices assume complete server replication
• Requirements less if replicating less

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Log and DB requirements

• Active Log
• At least 64GB Active Log
• Reconcile changes in TSM 7.1.1 greatly reduced log requirements
• Database
• A 300GB DB on a source server will require an additional 300GB of DB on the
target server
• In addition to current size of target DB
• Plan DB size and growth appropriately

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

10
 23.10.2015

Tasks

• Create/Verify the server definitions

• Set the replication target for the server
• Determine which nodes, file spaces, and data types are to be replicated
• Assign appropriate rules, or use defaults
• Enable replication for the nodes
• Determine whether dissimilar policies will be used
• Replicate

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Populate target server

Two basic methods to populate target server

• Method 1 – Replicate from scratch

• Best if source and target are in close proximity
• All eligible data is sent
•Could take a long time
• Method 2 – Synchronize and Replicate
• Best for large distances or if bandwidth is limited
• Use media-based Export/Import to populate target
• Replication with SYNC links the source and target objects

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

11
 23.10.2015

Replication terms

Mode
• The replication mode indicates the role for a node (source/target)
• Normal modes
• SEND – the node is the source of replication
• RECEIVE – the node is the target of replication
• Cannot be set directly
• SYNC modes
• SYNCSEND – the node is a synced source
• SYNCRECEIVE – the node is a synced target
State
• The replication state indicates whether replication is enabled
• Used to temporarily stop replicating

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Policies

• Replication does not replicate the policy

• Use EXPORT/IMPORT or Enterprise Configuration
• If using like policies, you should ensure the policies on each server are
the same, important for the case the replication is disabled
• If a policy construct is missing on the target server, the default construct is used
• If using dissimilar policies, you must
• Validate the policies with the command VALIDATE REPLPOLICY
• Enable the function with the command SET DISSIMILARPOLICIES

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

12
 23.10.2015

Restrictions on target server

• A replicated node is Read-Only

• Cannot store new data from a client or application
• Cannot rename the node
• Data can be deleted from target with:
DELETE VOL DISCARDD=YES
AUDIT VOL FIX=YES
DELETE FILESPACE
• Data deleted from target will be sent during next replication

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Removing replication

• REMOVE REPLNODE <nodename>

• Deletes all replication information from the DB
• Can be run on source, target, or both
• Sets the REPLSTATE and REPLMODE to NONE
• Does not delete any data

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

13
 23.10.2015

Planning

• Need to plan for the daily change rate

• Are your RAM, CPU, and disks sufficient?
• How much data needs to be initially replicated to get to the steady state?
• Do you have the time and bandwidth to replicate it from scratch?
• Would it be better to use Export/Import?

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Agenda

• Overview
• Preparing for Replication
Performing a Replication
• Best Practices
• 7.1.3 Enhancements
• Future Enhancements

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

14
 23.10.2015

Performing a replication

• The REPLICATE NODE command accepts:

• Multiple nodes and/or node groups
• Specific file spaces belonging to a node
• The data type to replicate
• The priorities to include in the replication
• REPLICATE NODE starts a single process
• Process ends when ALL nodes and file spaces are complete
• Can be scheduled as part of daily maintenance

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Replication processing

• Each node and file space specified is examined

• Source and target exchange information
• For each node being processed
• Target node is registered, if necessary
• Target file spaces are created, if necessary
• Replication State and Mode are verified
• Verify the node and/or file space is enabled for replication
• Verify source server is in SEND mode, and the target is in RECEIVE mode
• Target node is synchronized to source
• Attributes, including passwords, are replicated

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

15
 23.10.2015

Agenda

• Overview
• Preparing for Replication
• Performing a Replication
Best Practices
• 7.1.3 Enhancements
• Future Enhancements

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Best practices (maintenance plan)

• If not using container pools (7.1.3)

• Allow sufficient time for IDENTIFY to process all data before replicating
• Allows replication to benefit from deduplication
• Replicate the nodes
• If migrating data to tape, wait for replication to finish before migrating
• Expire the inventory
• If migrating from disk to tape with autocopy, migrate the storage pools
• Back up the storage pools
• Reclaim the storage pools

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

16
 23.10.2015

Best practices

• Be sure to test replication throughput

• Adjust MAXSESSIONS
• Network, CPU, and RAM will impact throughput
• Make sure sufficient mount points are available for replication
• For FILE device class, set mount limit to at least the product of
NUMOPENVOLSALLOWED and MAXSESSIONS
• Don’t run all nodes in a single replication
• Replicate nodes with large number of objects by themselves
• With a smaller value for MAXSESSIONS (1 - 3)

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Best practices

• More sessions doesn’t necessarily mean better performance

• It usually does, but lock contention on the target server can slow it down
• Replication batches have 2 phases:
• Phase 1: Sending the data to the target server for the new objects
• Phase 2: Updating the database with the new objects
• File space locks on the target server occur in phase 2
• When the amount of time spent in phase 1 is large relative to the time spent in
phase 2, use more sessions
• When the amount of time spent in phase 1 is relatively small, use fewer
sessions
• Increased distances will add time to phase 1 without affecting phase 2
• Generally speaking, this will benefit from having more sessions

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

17
 23.10.2015

Best practices

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Agenda

• Overview
• Preparing for Replication
• Performing a Replication
• Best Practices
7.1.3 Enhancements
• Future Enhancements

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

18
 23.10.2015

7.1.3 Container pool overview

Container storagepools
– Storage is handled in an automatic fashion such that no direct management of the storage is required
• Philosophy - write once and don’t fuss with it
• NO reclamation, migration, copies, backups, shredding, LAN-free…..
• NO device classes or volumes like legacy random or sequential access storagepools
– Dynamic creation & deletion

Next generation deduplication (NextGen dedupe) uses container storagepools

– Allows for the deduplication of all data from both the client and server
• With the exception of files that have been encrypted on the client side
– Deduplication occurs in-line
• As opposed to legacy TSM server dedupe being done in a separate process following ingest

Goals of container and NextGen dedupe are to provide

– Easier management
– Faster performance
– More scalability

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Container pools attributes

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

19
 23.10.2015

Directory pool compared to File pool

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Protecting data in container pools

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

20
 23.10.2015

Node replication for directory based container pools

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Storage pool protection (new function)

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

21
 23.10.2015

Protect STGPOOL for directory based container pools

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Repair storage pool

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

22
 23.10.2015

Comparison of replication and protect stgpool

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Agenda

• Overview
• Preparing for Replication
• Performing a Replication
• Best Practices
• 7.1.3 Enhancements
Future Enhancements

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

23
 23.10.2015

2016: Unified replication

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

2016: Metadata-only node replication

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

24
 23.10.2015

Future: Node replication with automatic failover/failback

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Future: Always-on node replication

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

25
 23.10.2015

Future: Node replication to multiple target servers

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Future: Node replication with transparent client access

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

26
 23.10.2015

Questions?

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

Thank You

22.10.2015 TSM Symposium Nachlese © 2015 IBM Corporation

27